Abstract:
A method and system are described for configuring and presenting softkeys on a device. Softkey profiles are created for assigning a feature to a softkey on a device for each of a plurality of device states; and each such softkey is presented on the device for each of device state. A conflict resolution mechanism is described for resolving any softkey availability conflict between a predetermined feature and a mandatory system softkey for each of device states. A softkey management mechanism is also described for managing presentation of context specific features for each softkey.

Description:
BACKGROUND 
       [0001]    1. Field 
         [0002]    This specification relates generally to communication systems, and more particularly to the presentation and configuration of softkeys on a telephone device. 
         [0003]    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. 
         [0004]    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. 
         [0005]    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. 
         [0006]    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). 
         [0007]    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. 
         [0008]    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. 
       SUMMARY 
       [0009]    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. 
         [0010]    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. 
         [0011]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]      FIG. 1  is a block diagram of an exemplary communication system; 
           [0013]      FIG. 2  shows an exemplary IP phone configured for operation in accordance with an aspect of an embodiment; 
           [0014]      FIG. 3  shows an exemplary trading turret configured for operation in accordance with an aspect of an embodiment; 
           [0015]      FIG. 4  is a flowchart showing method steps for configuring softkeys of the telephone devices shown in  FIGS. 2 and 3 , according to an aspect of an embodiment; and 
           [0016]      FIG. 5 , comprising  FIGS. 5A ,  5 B and  5 C, is a flowchart showing method steps for presenting softkeys on the telephone devices of  FIGS. 2 and 3  that have been configured in accordance with the steps of  FIG. 4 , according to another aspect of an embodiment. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0017]    With reference to  FIG. 1 , an exemplary communication system is shown comprising a communication switch such as an IP PBX otherwise known as an iPBX  1  (e.g. Mitel 3300 ICP or Mitel SX-200 ICP) connected to a local area network (LAN 3) and to the Public Switched Telephone Network (PSTN) (not shown). A plurality of telephone devices such as IP phones  5  and  7  (e.g. model 5220 and 5320 IP phones manufactured by Mitel Networks Corporation), a trading turret  9 , a desktop computer  10  running phone and/or desktop applications, etc. are connected to the LAN 3, as well as an Administrator Console  11 . 
         [0018]    A person of skill in the art will appreciate that the configuration of  FIG. 1  is representative of a typical converged communication network, and that numerous variations in configuration, components, etc. are possible. Also, as discussed below, the principles set forth herein may be extended to systems other than telephony system wherein the feature-providing functionality of iPBX  1  may be performed by any other suitable controller for implementation on any suitable device (i.e. not limited to a telephone device). 
         [0019]      FIG. 2  shows a telephone device (e.g. a model 5220 IP phone manufactured by Mitel Networks Corporation) including a handset  21 , keypad  22 , a plurality of fixed function keys  23 , a plurality of configurable softkeys  24  and a display screen  25 . Each of the softkeys  24  is associated with a behaviour/feature that is indicated by a label or icon on the display  25 . 
         [0020]      FIG. 3  shows a trading turret appliance having a keypad  32 , a plurality of fixed function keys  33 , display screens  35 , and configurable softkeys  34 , a plurality of which may be configured as ‘float keys’ (e.g. the center six softkeys, three on one side of each display  35 ). 
         [0021]    In accordance with an aspect of an embodiment set forth herein, softkey configurations (e.g. for the telephone devices of  FIGS. 2 and 3 ), may be stored in one or more softkey profiles within the iPBX  1 , such as shown in the example of Table 1. The configurations may be user configurable or non-configurable on a selective or system-wide basis. Although not shown in Table 1, the absence of a softkey profile (or a predefined value) for any device indicates that normal system handling applies to the softkeys. 
         [0000]    
       
         
               
             
               
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Multiline IP Set Configuration 
               
             
          
           
               
                 Device Id 
                 Device Type 
                 Number 
                 Line Type 
                 Softkey Profile 
               
               
                   
               
               
                 1 
                 5220 IP 
                 3245 
                 Single Line 
                 1 
               
               
                 2 
                 5320 IP 
                 3272 
                 Single Line 
                 1 
               
               
                 3 
                 Turret 
                 3276 
                 Single Line 
                 2 
               
               
                   
               
             
          
         
       
     
         [0022]    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. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                 Softkey Profile Id = 1 
               
             
          
           
               
                   
                   
                 Management 
                   
               
               
                 Softkey 
                 Behaviour 
                 Algorithm 
                 Conflict Resolution 
               
               
                   
               
               
                 1 
                 Application 
                 application 
                 available for mandatory 
               
               
                   
                 Key 
                 controlled 
               
               
                 2 
                 Music On/Off 
                 system controlled 
                 system softkey ignored 
               
               
                 3 
                 Access 
                 context independent 
                 system softkey ignored 
               
               
                   
                 Voicemail 
               
               
                 4 
                   
                 system controlled 
                 available for mandatory 
               
               
                 5 
                   
                 system controlled 
                 available for mandatory 
               
               
                 6 
                   
                 system controlled 
                 system softkey presented 
               
               
                   
               
             
          
         
       
     
         [0023]    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. 
         [0024]    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. 
         [0025]    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. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 3 
               
             
             
               
                   
               
               
                 Softkey Profile Id = 2 
               
             
          
           
               
                 Softkey 
                 Behaviour 
                 Management Algorithm 
                 Conflict Resolution 
               
               
                   
               
               
                 1 
                 Float key 
                 application controlled 
                 available for mandatory 
               
               
                 2 
                 Float key 
                 application controlled 
                 system softkey ignored 
               
               
                 3 
                 Float key 
                 application controlled 
                 available for mandatory 
               
               
                 4 
                 Float key 
                 application controlled 
                 system softkey ignored 
               
               
                 5 
                 Float key 
                 application controlled 
                 system softkey ignored 
               
               
                 6 
                 Float key 
                 application controlled 
                 system softkey ignored 
               
               
                   
               
             
          
         
       
     
         [0026]    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  FIG. 3 , wherein the remaining six softkeys are configured similarly to the softkeys in Table 3. 
         [0027]    Turning to  FIG. 4 , an exemplary method is set forth for validation of a softkey profile configuration during system softkey allocation of a telephone device. When validating a softkey profile for a particular desired feature to be implemented at a particular softkey position ( 400 ), for example via administrator population of fields in a table system softkey allocation table presented to the administrator on administrator console  11 , the iPBX  1  first dereferences the supported device state list (i.e. Idle, Busy, Ringing, etc.) and system softkey allocation for the device type, and selects a first one of the device states ( 405 ). Upon determining the first device state (i.e. a “Yes” at  410 ), the system determines the first applicable system softkey (if any) for that softkey position when the device is in the first device state ( 415 ). If there is no system softkey for that softkey position and device state (i.e. a “No” at  420 ), the system determines the next applicable device state for the desired feature ( 425 ), and returns to  410 . 
         [0028]    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. 
         [0029]    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. 
         [0030]    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 ). 
         [0031]    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. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 4 
               
             
             
               
                   
               
               
                 System Softkey Allocation (for Device Type i.e. 5220 Family devices) 
               
             
          
           
               
                 Device State 
                 Prefered Softkey # 
                 Behaviour 
                 Mandatory 
               
               
                   
               
               
                 Idle 
                 1 
                 Phonebook 
                 No 
               
               
                 Idle 
                 1 
                 Speak@Ease 
                 No 
               
               
                 Idle 
                 2 
                 Redial 
                 No 
               
               
                 Idle 
                 3 
                 Hotdesk 
                 Yes 
               
               
                 Dialling 
                 1 
                 Back Arrow 
                 Yes 
               
               
                 Dialling 
                 6 
                 New Call 
                 Yes 
               
               
                 Ringing 
                 3 
                 Force Forward 
                 No 
               
               
                 etc . . . 
               
               
                   
               
             
          
         
       
     
         [0032]    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. 
         [0033]    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. 
         [0034]    Presentation of softkeys at the device is determined, as shown in  FIG. 5 , on the basis of the associated softkey profile configuration validated according to the steps set forth in  FIG. 4 . Thus, upon a change of device state the softkey behaviour/feature must be updated at each softkey position. For a given softkey position update ( 500 ), the system dereferences any system softkey allocation applicable to the specific device type (in Table 4) as well as the softkey profile ( 505 ) associated with the device (in Table 1) or otherwise associated (e.g. softkey profile configuration applicable to the specific device type). If the profile does not include any softkey behaviour for the current device state (i.e. a “No” at  510 ), then normal system softkey handling ensues ( 512 ). Otherwise, if the profile does include a softkey behaviour for the current device state (i.e. a “Yes” at  510 ), then if the system softkey allocation indicates softkey behaviour (i.e. a “Yes” at  515 ) and the allocated system softkey is mandatory (i.e. a “Yes” at  520 ), then normal system softkey handling ensues ( 512 ). If no system softkey behaviour is indicated (i.e. a “No” at  515 ), then presentation of the softkey proceeds according to the associated management algorithm ( 530 ). That is, the softkey is displayed according to one of: context independent profile softkey handling ( 535 ), application controlled profile softkey handling ( 540 ) or system controlled profile softkey handling ( 545 ). If softkey behaviour is indicated (i.e. a “Yes” at  515 ), but the allocated system softkey is not mandatory (i.e. a “No” at  520 ), then conflict resolution is performed (see step  440  of  FIG. 4 ), resulting in either presentation of the system softkey (i.e. a “Yes” at  550 ), followed by normal system softkey handling ( 512 ), or presentation of the softkey according to the associated management algorithm ( 530 ). 
         [0035]    Once the resultant softkey has been determined according to the methodology of  FIG. 4 , the managed softkey array (e.g. Tables 2 and 3) is updated for the given device. The softkey to be presented as a result of the methodology of  FIG. 5  is transmitted to the physical/virtual device (e.g. telephone device  5  or  7 , trading turret  9 , desktop phone application at computer  10 , etc) for presentation to the user in a MiNET (or equivalent) message. Additional indications may be provided to the device that can be used, optionally, to provide visual indication that the softkey is under system/user/or application control. 
         [0036]    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. 
         [0037]    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). 
         [0038]    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.