Patent Application
20090129574
1. Field
This specification relates generally to communication systems, and more particularly to the presentation and configuration of softkeys on a telephone device.
2. Description of the Related Art As used herein, “telephone device” includes analog telephones, digital telephones, IP phones, mobile phones, PC desktop phone applications (i.e. softphones), trading turret appliances, and any other similar communication device.
It is known in the art to present softkeys on telephone devices to provide context specific behaviours/features to a telephone device user. The position of a softkey that has been programmed for a specific behaviour/feature is pre-determined to ensure that it does not interfere or conflict with different uses of the key and to ensure that the position is consistent with conventional telephone usage. Each device state (e.g. Idle, Busy, Dialing, etc.) may be associated with different configurations of softkeys to provide context specific behaviours/features. Consistent positioning of softkeys to provide context specific behaviours/features allows for predictable system operation and provides for commonality of telephone user interface (TUI) operation for different device types and users.
It is also conventional to use a single softkey position for multiple behaviours/features that are associated with the softkey according to a prioritized ordering related to device state. For instance, a number of IP phones manufactured by Mitel Networks Corporation provide ‘Phonebook’ and ‘Speak@Ease’ features, each of which is associated with the same softkey position when the set is in the Idle state. The ‘Speak@Ease’ softkey is only presented if the feature is available and a user preference has been configured for it. Otherwise, the ‘Phonebook’ softkey is presented at the identical softkey position when the IP phone is in the idle state.
Additionally, a user (or the communication system itself) may configure a telephone device so as to override the softkeys provided as system defaults. When overridden, alternate softkeys are usually provided (typically user configured). Once overridden, the system does not provide context sensitive softkeys but instead provides the alternate softkeys. For example, a ‘Personal Idle Softkeys’ feature is supported on the model 5235 telephone device manufactured by Mitel Networks Corporation. This feature allows a user to configure the presentation of desired softkeys when the telephone device is in the Idle state (instead of presenting default context specific behaviour/feature softkeys normally provided by the system).
Since the number of softkeys that may be presented on a telephone device is limited (based on the device type), it is advantageous to avoid reserving positions for features/behaviours that are not available to a specific user/device when the device is in a specific state (i.e. always blank), so that the positions may be used for other features/behaviours appropriate to the specific device state. Also, in some device states feature conflicts may preclude presentation of softkeys for certain desirable behaviours/features. Additionally, some features/behaviours for which it may be desirable to associate context sensitive softkeys may not be available unless managed by the system.
The foregoing limitations are particularly acute in the context of “float keys” on a “trading turret” appliance, such as the model 5560 telephone device manufactured by Mitel Networks Corporation, which is a specialized telephone device often used by stock and bond traders. “Float keys” are used on trading turrets to provide access to ringing calls (without requiring the trading turret to have a physical key for each line). Typically, six dedicated keys are configured on the turret appliance for use as “float keys”, while the softkeys are left blank or are reserved for features that are not important on a trading turret. A hardware redesign is necessary in order to increase the number of available float keys on a turret appliance.
It is an object of an aspect of this specification to set forth a method of configuring personal softkeys with context specific behaviours/features by a user/application, while identifying and selectively overriding configuration conflicts. According to one aspect, the configuration of shared softkeys is coordinated between user/applications configuration and system context specific features/behaviours, thereby ensuring availability of mandatory system-provided context specific behaviour/features and context sensitive behaviour/features configured by the user/applications. According to another aspect, device state dependent and/or a call-by-call capability is provided to change softkey behaviour/features.
In an exemplary embodiment, a softkey profile is associated with a user, a device type, a device state and/or any combination thereof. The softkey profile identifies the configuration of each softkey and a softkey management algorithm to be applied, thereby managing the presentation of context specific features on available softkeys. Additionally, a softkey conflict resolution mechanism is set forth.
The foregoing and other aspects and advantages are more fully hereinafter described and claimed, reference being had to the accompanying drawings, wherein like numerals refer to like parts throughout.
With reference to
A person of skill in the art will appreciate that the configuration of
In accordance with an aspect of an embodiment set forth herein, softkey configurations (e.g. for the telephone devices of
Softkey profiles may be administrator configurable for each device and/or groups of devices to provide available programmable keys and/or system and/or application features, as shown in the examples of Tables 2 and 3.
The softkey profile specifies a behaviour, management algorithm and conflict resolution for each softkey position. The softkey management algorithm is executed for classifying each available softkey as being one of either context independent, system controlled or application controlled. Thus, in Table 2 (applicable to configuration of softkeys for IP phones 5 and 7), the softkey profile specifies that the first softkey position functions as an Application Key, for launching an application (e.g. an application on desktop computer 10). Thus, the management algorithm for control of that softkey is “application controlled”, because the iPBX 1 does not control the feature behaviour but rather passes control to an application that has registered with the iPBX 1 for control of the feature. The conflict resolution for that softkey is “available for mandatory”, indicating that the first softkey position is available for allocation to a required system feature (e.g. the “cancel” function), and will displace the application key if no other softkey positions are available for the required system feature.
The softkey profile of Table 2 specifies that the second softkey position functions as a Music On/Off key, for enabling or disabling music (e.g. music played through a speaker). The management algorithm for control of the softkey is “system controlled”, because the iPBX 1 controls the feature behaviour. The conflict resolution for that softkey is “system softkey ignored”, indicating that in the event of a conflict between the desired system-controlled behaviour (i.e. Music On/Off) and any higher priority behaviour not already assigned to a softkey, the higher priority behaviour will displace the desired behaviour at that softkey position and the system will not attempt to find a new softkey position for the desired system-controlled behaviour.
The fourth, fifth and sixth softkey positions in the example of Table 2 are blank, indicating that those softkey positions are available for system control. The conflict resolution method specified for the sixth softkey position is “system softkey presented”, which indicates that in the event of a conflict between the desired system-controlled behaviour and any higher priority behaviour not already assigned to a softkey, the desired system-controlled behaviour will be presented.
In Table 3 (applicable to configuration of softkeys for the trading turret 9), all of the softkey positions are indicated as being application controlled float keys, with various specified conflict resolution methods (i.e. system softkey presented, available for mandatory or system softkey ignored). It should be noted that whereas Table 3 shows only shows six softkeys, a total of twelve such keys are available on the turret device of
Turning to
If there is an applicable system softkey (i.e. a “yes” at 420), but the system softkey is not mandatory for the indicated device state (i.e. a “Yes” at 430) then the system checks the next available system softkey feature applicable to that softkey position and device state (435) and 420 is then repeated.
If the system softkey is, in fact, mandatory for the indicated device state (i.e. a “No” at 430) then conflict resolution is performed (i.e. apply one of either system softkey presented, available for mandatory or system softkey ignored) to determine whether to allocate the mandatory system softkey (i.e. a “Yes” at 440), or indicate (445) that a validation failure has occurred (450) because of a conflict between the desired feature allocation and mandatory system softkey.
Once all of the device states and system softkeys have been considered (i.e. a “No” at 410), then validation of the desired feature allocation to the particular softkey position is deemed to have been successful (455).
An exemplary system allocation table is shown in Table 4 for specifying the behaviour of the various softkeys on a particular device (i.e. the model 5220 IP phone 5) in different device states. It will be noted that the first softkey position is shown as being allocated to two different features in the Idle device state (Phonebook and Speal@Ease). However, since that softkey position does not require a mandatory system feature then, as discussed above, iPBX 1 resolves the conflict by presenting the ‘Speak@Ease’ softkey (thereby overriding and displacing the Phonebook feature) if the ‘Speak@Ease’ feature has been configured. Otherwise, the ‘Phonebook’ softkey is presented at the identical softkey position when the set is in the Idle state.
From the foregoing it will be appreciated that, for each device state one or more system softkey tables is maintained to identify each potential context specific behaviour/feature and its associated softkey position as well as an indication of whether the behaviour/feature is mandatory or optional. For example, in the Dialing state ‘←’ (Back Arrow) is mandatory whereas ‘Phonebook’ is optional.
Identification of mandatory/optional behaviours/features is pre-determined for each device type (or group of device types) based on existing support and/or during feature development. In making such a determination of mandatory softkeys, consideration must be given to the availability of equivalent behaviours/features using other capabilities for a given device type (e.g. hard keys) and TUI usability issues. While configuration control of mandatory/optional softkey identification is possible, this is not normally considered to be desirable because telephone operation may be unintentionally impacted.
Presentation of softkeys at the device is determined, as shown in
Once the resultant softkey has been determined according to the methodology of
Once the device has been updated with all applicable softkeys, pressing of a softkey on the physical/virtual device is handled in a well known manner for the associated behaviour/feature identified in the managed softkey array for the device.
The foregoing description of a preferred embodiment is not intended to be limiting. Other embodiments, variations and applications are possible. For example, it is contemplated that an application may control the device softkeys statically and/or dynamically via the configured softkey management algorithm (with a value identifying the controlling application). The iPBX 1 may act as a proxy for the application or provide indication to the device in the softkey message that an application has control until the next softkey update. Any combination of device state/softkey profile/softkey configuration can be used to increase (or decrease) configuration flexibility (e.g. designating a single softkey profile to apply regardless of device state). It is also contemplated that additional and/or alternative conflict resolution methods may be implemented (i.e. to permit moving behaviours between different softkey positions and thereby allow more flexibility when handling mandatory softkey conflicts), as well as additional and/or alternative management algorithms. Also, the principles set forth herein may be extended to programmable line keys (for example, making the first page of programmable line keys on the turret appliance 9 into managed softkeys, primarily for use as “float keys”). The principles set forth herein may also be extended to management of context specific choices where more than one behaviour/feature is appropriate for a single selection interface (e.g. control panel interfaces for a multi-room multi-source stereo system with a limited number of buttons providing access to a considerably larger number of context specific and context independent behaviours/features).
Many features and advantages will be apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to impose any limitation to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope of the claims.
