CA2299639C - Adaptive rule-based mechanism and method for feature interaction resolution - Google Patents
Adaptive rule-based mechanism and method for feature interaction resolution Download PDFInfo
- Publication number
- CA2299639C CA2299639C CA002299639A CA2299639A CA2299639C CA 2299639 C CA2299639 C CA 2299639C CA 002299639 A CA002299639 A CA 002299639A CA 2299639 A CA2299639 A CA 2299639A CA 2299639 C CA2299639 C CA 2299639C
- Authority
- CA
- Canada
- Prior art keywords
- features
- conflicting
- feature
- indeterminate
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
- H04Q3/0041—Provisions for intelligent networking involving techniques for avoiding interaction of call service features
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42136—Administration or customisation of services
- H04M3/4217—Managing service interactions
Abstract
An adaptive rule-based mechanism and method to resolve conflicting feature interactions includes the steps of determining conflicting features available for execution in response to an event; examining the conflicting features to determine whether one of the conflicting features takes priority over other conflictin g features; if one of the conflicting features takes priority, selecting that conflicting feature for execution; and if one conflicting feature does not take priority, prompting the user to make a selection to resolve the conflicting feature interaction.
Description
ADAPTIVE RULE-BASED MECHANISM AND METHOD
FOR FEATURE INTERACTION RESOLUTION
Field Of The Invention The present invention relates to an adaptive rule-based mechanism and method for resolving conflicting feature interactions.
S Background Of The Invention Current communication systems provide users with a significant number of features, such as for example, call forwarding, call waiting, call hold, speed dialing etc. New features are continually being offered by telephone companies and private branch exchange (PBX) suppliers. With the availability of technology to allow features to be customized for each user, the number of actual features available to users can be nearly arbitrary. This of course makes the task of managing conflicts between features very difficult.
Indeterminacy conflicts between features occur when two or more non-mutually compatible features available to a user are to be invoked simultaneously in response to an event. For example, consider call forwarding busy (CFB) and call waiting (CW) features. Both of these features are extensions of a terminating call (TC) feature. During normal execution of the TC feature, an incoming call is rejected if an existing call is in progress. The CFB and CW features however define deviations to this incoming call handling procedure. During execution of the CFB
feature, an incoming call is forwarded to another extension if an existing call is in progress. During execution of the CW feature, a warble is generated when an incoming call is received and an existing call is in progress. If a user subscribes to both the CFB and CW features and an incoming call is received when an existing call is in progress, a conflict occurs since the incoming call cannot be forwarded to another extension and answered by the called party at the same time.
The problems associated with feature interactions have been considered. See for example:
N. Griffeth, and Y. Lin, "Extending Telecommunications Systems:
The Feature-Interaction Problem", Computer, 14-18, August 1993.
E. Cameron et al., "A Feature Interaction Benchmark for IN and Beyond", Feature Interactions in Telecommunications Systems, 1-23, IOS Press, 1994
FOR FEATURE INTERACTION RESOLUTION
Field Of The Invention The present invention relates to an adaptive rule-based mechanism and method for resolving conflicting feature interactions.
S Background Of The Invention Current communication systems provide users with a significant number of features, such as for example, call forwarding, call waiting, call hold, speed dialing etc. New features are continually being offered by telephone companies and private branch exchange (PBX) suppliers. With the availability of technology to allow features to be customized for each user, the number of actual features available to users can be nearly arbitrary. This of course makes the task of managing conflicts between features very difficult.
Indeterminacy conflicts between features occur when two or more non-mutually compatible features available to a user are to be invoked simultaneously in response to an event. For example, consider call forwarding busy (CFB) and call waiting (CW) features. Both of these features are extensions of a terminating call (TC) feature. During normal execution of the TC feature, an incoming call is rejected if an existing call is in progress. The CFB and CW features however define deviations to this incoming call handling procedure. During execution of the CFB
feature, an incoming call is forwarded to another extension if an existing call is in progress. During execution of the CW feature, a warble is generated when an incoming call is received and an existing call is in progress. If a user subscribes to both the CFB and CW features and an incoming call is received when an existing call is in progress, a conflict occurs since the incoming call cannot be forwarded to another extension and answered by the called party at the same time.
The problems associated with feature interactions have been considered. See for example:
N. Griffeth, and Y. Lin, "Extending Telecommunications Systems:
The Feature-Interaction Problem", Computer, 14-18, August 1993.
E. Cameron et al., "A Feature Interaction Benchmark for IN and Beyond", Feature Interactions in Telecommunications Systems, 1-23, IOS Press, 1994
-2-D. Keck, and P. Kuehn, "The Feature and Service Interaction Problem in Telecommunications Systems: A Survey", IEEE Transactions of Software Engineering, 779-796, October 1998 To deal with feature interaction conflicts, in some state of the art S communication systems, features are assigned priorities a priori by the communication system developer. In most cases, these priorities are hardcoded into software programs. As a result, each feature must explicitly account in some part of its code, for each possible interaction with another feature. This of course requires complete knowledge of other features with which an interaction may occur.
Writing code for features to account for all other features is not only a highly a complex task but virtually impossible to achieve, especially in the presence of features developed by third parties that are added to an existing communication system. This problem is exemplified by the trend towards open. component-based communication systems that allow users to develop and add their own features.
In some communication systems, precedence has been used to specify feature selection in the event of a conflicting feature interaction based on the feature with the highest priority. For example, U.S. Patent No. 4,695,977 to Hansen et al.
discloses a telecommunication system for the switching of voice and data controlled by a computer executing a nonprocedural language that allows for the explicit control of interaction between features by the program scripts executing the programs.
During run time of the system, a script, whose triples implement a particular feature, can control whether or not features of lower precedence are allowed to be implemented. However, this approach does not take into account features that specialize other features. This approach also does not allow precedence lists to be established for each user reflecting that user's preferences for resolving conflicting feature interactions.
It is therefore an object of the present invention to provide a novel adaptive rule-based mechanism and method for resolving conflicting feature interactions.
Writing code for features to account for all other features is not only a highly a complex task but virtually impossible to achieve, especially in the presence of features developed by third parties that are added to an existing communication system. This problem is exemplified by the trend towards open. component-based communication systems that allow users to develop and add their own features.
In some communication systems, precedence has been used to specify feature selection in the event of a conflicting feature interaction based on the feature with the highest priority. For example, U.S. Patent No. 4,695,977 to Hansen et al.
discloses a telecommunication system for the switching of voice and data controlled by a computer executing a nonprocedural language that allows for the explicit control of interaction between features by the program scripts executing the programs.
During run time of the system, a script, whose triples implement a particular feature, can control whether or not features of lower precedence are allowed to be implemented. However, this approach does not take into account features that specialize other features. This approach also does not allow precedence lists to be established for each user reflecting that user's preferences for resolving conflicting feature interactions.
It is therefore an object of the present invention to provide a novel adaptive rule-based mechanism and method for resolving conflicting feature interactions.
-3-Summary Of The Invention According to one aspect of the present invention there is provided in a system where two or more indeterminate features can be executed in response to an event resulting in a conflicting feature interaction, an adaptive rule-based method for resolving said conflicting feature interaction comprising the steps of determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, prompting a user to select one of said indeterminate features for execution thereby to resolve said conflicting feature interaction.
1 S According to another aspect of the present invention there is provided a telephony communication system wherein a service is to be performed in response to an event, said system including a plurality of executable conflicting features representing available options which can be performed to complete said service, an adaptive rule-based method to resolve feature conflicts during performance of said service comprising the steps of:
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one of said conflicting feature does not take priority, prompting a user to select one of said conflicting features for execution to resolve said conflicting feature interaction and executing the selected conflicting feature thereby to complete said service.
According to yet another aspect of the present invention there is provided an adaptive rule-based mechanism to resolve conflicting feature interactions
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, prompting a user to select one of said indeterminate features for execution thereby to resolve said conflicting feature interaction.
1 S According to another aspect of the present invention there is provided a telephony communication system wherein a service is to be performed in response to an event, said system including a plurality of executable conflicting features representing available options which can be performed to complete said service, an adaptive rule-based method to resolve feature conflicts during performance of said service comprising the steps of:
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one of said conflicting feature does not take priority, prompting a user to select one of said conflicting features for execution to resolve said conflicting feature interaction and executing the selected conflicting feature thereby to complete said service.
According to yet another aspect of the present invention there is provided an adaptive rule-based mechanism to resolve conflicting feature interactions
-4-when a plurality of conflicting features can be executed simultaneously in response to an event, said mechanism comprising:
means for determining conflicting features available for execution in response to said event;
means for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
means for selecting the conflicting feature that takes priority for execution, if it exists; and means for prompting a user to make a selection to resolve said conflicting feature interaction if a conflicting feature taking priority does not exist.
According to yet another aspect of the present invention there is provided in a system where two or more indeterminate features can be executed in response to an event resulting in a conflicting feature interaction, an adaptive rule-based method for resolving said conflicting feature interaction comprising the steps of determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, comparing levels assigned to the indeterminate features with the level assigned to a user associated with said event, if the level assigned to at least one indeterminate feature is above the level of the user, automatically selecting one of the indeterminate features to resolve the conflicting feature interaction; otherwise prompting the user to make a selection to resolve the conflicting feature interaction.
According to still yet another aspect of the present invention there is provided in a telephony communication system wherein a telephone call completion service is to be performed in response to a telephone call, said system including a plurality of executable conflicting features representing available options which can
means for determining conflicting features available for execution in response to said event;
means for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
means for selecting the conflicting feature that takes priority for execution, if it exists; and means for prompting a user to make a selection to resolve said conflicting feature interaction if a conflicting feature taking priority does not exist.
According to yet another aspect of the present invention there is provided in a system where two or more indeterminate features can be executed in response to an event resulting in a conflicting feature interaction, an adaptive rule-based method for resolving said conflicting feature interaction comprising the steps of determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, comparing levels assigned to the indeterminate features with the level assigned to a user associated with said event, if the level assigned to at least one indeterminate feature is above the level of the user, automatically selecting one of the indeterminate features to resolve the conflicting feature interaction; otherwise prompting the user to make a selection to resolve the conflicting feature interaction.
According to still yet another aspect of the present invention there is provided in a telephony communication system wherein a telephone call completion service is to be performed in response to a telephone call, said system including a plurality of executable conflicting features representing available options which can
-5-be performed to complete said service, an adaptive rule-based method to resolve feature conflicts during performance of said service comprising the steps of prompting a calling party to select one of a number of options;
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over the other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one conflicting feature does not take priority, examining rules associated with a policy governing feature selection to determine if the policy rules remove one or more features from the conflict; prompting a user to make a selection from the remaining conflicting features to resolve said conflicting feature interaction;
and executing the selected feature thereby to complete said service.
According to still yet another aspect of the present invention there is 1 S provided a computer readable medium including computer program code for resolving conflicting feature interactions comprising:
computer program code for determining conflicting features available for execution in response to an event;
computer program code for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
computer program code for selecting said one conflicting feature for execution if one of said conflicting features takes priority; and computer program code for prompting a user to select one of said conflicting features for execution if one of said conflicting features does not take priority thereby to resolve said conflicting feature interaction.
The present invention provides advantages in that after the adaptive rule-based mechanism is invoked, feature interactions are resolved allowing services to be performed. If desired, rules can be established to govern feature selection when the same services are to be performed in the future. Since feature interactions are resolved in an adaptive manner, different users can establish their own preferences.
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over the other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one conflicting feature does not take priority, examining rules associated with a policy governing feature selection to determine if the policy rules remove one or more features from the conflict; prompting a user to make a selection from the remaining conflicting features to resolve said conflicting feature interaction;
and executing the selected feature thereby to complete said service.
According to still yet another aspect of the present invention there is 1 S provided a computer readable medium including computer program code for resolving conflicting feature interactions comprising:
computer program code for determining conflicting features available for execution in response to an event;
computer program code for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
computer program code for selecting said one conflicting feature for execution if one of said conflicting features takes priority; and computer program code for prompting a user to select one of said conflicting features for execution if one of said conflicting features does not take priority thereby to resolve said conflicting feature interaction.
The present invention provides advantages in that after the adaptive rule-based mechanism is invoked, feature interactions are resolved allowing services to be performed. If desired, rules can be established to govern feature selection when the same services are to be performed in the future. Since feature interactions are resolved in an adaptive manner, different users can establish their own preferences.
-6-Brief Description Of The Drawings Embodiments of the present invention will now be described more fully with reference to the accompanying drawings in which:
Figure 1 is a schematic diagram of a communication system including a plurality of user locations;
Figure 2 shows user level priorities in the communication system of Figure 1;
Figure 3 is a use case diagram showing a terminating call feature extended by call forwarding busy and call waiting features;
Figure 4 illustrates the steps performed during a handle incoming call service for terminating call, call forwarding busy and call waiting features;
Figures Sa to Sc are flow charts illustrating the steps performed during execution of an adaptive rule-based mechanism for resolving conflicting feature interactions in accordance with the present invention;
Figure 6 is a flow chart illustrating steps performed during filtering of conflicting feature interactions;
Figure 7 illustrates user selectable icons representing conflicting features; and Figure 8 is a pop-up dialog box presented to a user during execution of the adaptive rule-based mechanism for resolving conflicting feature interactions.
Detailed Description Of The Preferred Embodiment The present invention relaxes to an adaptive rule-based mechanism and method for resolving feature interactions in environments where two or more available indeterminate features can be invoked simultaneously in response to an event resulting in a conflict. The present invention is based on a separation between the policy and mechanism of feature execution. The policy provided by the feature execution environment detects and resolves known or potential feature interactions.
The policy is generic inasmuch as it requires no internal knowledge of the mechanisms. It only requires that features implement a common set of methods or functions by which the policy can ask a feature, for example, whether it is applicable in a given situation, and which features extend it. A system with policy-mechanism _7_ separation can accordingly deal with the requirements of an open evolving system.
For the sake of clarity, an embodiment of the adaptive rule-based mechanism in accordance with the present invention implemented in a telephony communication system will now be described.
Referring to Figure 1, a communication system is shown and is generally indicated to by reference numeral 10. In this example, communication system 10 includes a business location 12 having a plurality of personal computers 14, two of which are shown for illustrative purposes, connected to a telephony server 16 over a local area network. Telephony server 16 is connected to a telephone network 18 such as a public switched telephone network (PSTN). Personal computers 20 at customer locations are also connected to the telephone network 18. Each personal computer 14 and 20 is equipped with the necessary communication hardware and software to allow telephone calls with other communication devices to be established.
The hardware and software resources of the personal computers 14 and 20, which allow them to function as desktop feature telephone devices, provide users with telephone features offering enhanced functionality. These features may be programmed by users of the personal computers, or established by the administrator of the business location 12 or developer of the communication system 10. The features available to each personal computer are listed in precedence and compatibility matrices stored in memory. At the business location 12, the precedence and compatibility matrices are stored in telephony server memory while at the customer locations, the precedence and compatibility matrices are stored in resident memory within the personal computers 20. The precedence and compatibility matrices define rules governing the selection of features to deal with conflicting and compatible features thereby to allow services to be performed in response to events.
Specifically, entries in the precedence matrix determine a user's preference when two or more conflicting features are available to the user that can be executed at the same time in response to an event. Entries in the compatibility matrix determine mutually compatible features, which are to be executed simultaneously in response to an event.
Different levels of rules corresponding to different levels of users in the communication system 10 (most common at business locations) can exist as shown in Figure 2. In this case, rules created by a user of a higher priority cannot be _g_ overridden by a user of lower priority. Rules use an if then representation and may include simple arithmetic operators. 'lariables are indicated by the "?"
prefix and every other symbol is a terminal. The execution model for rules follows that of a typical forward chaining expert system such as OPS-5. The only extension made is that rules are to be executed in phases where indicated. The rules in phase 1 are applied before those in phase 2, etc., until no more rules can be found. The execution then proceeds to the next phase. In this way, the result of the application of the set of rules from one phase is "piped" into the set of rules from the subsequent phase.
The personal computers allow features to be plugged into the communication software framework at design time and run time. Since users can plug new features into the communication software framework, new features can be added, which conflict with existing features. A conflicting feature interaction is flagged when more than one feature can be executed in response to an event and the feature execution outcome is potentially indeterminate. Usually, the precedence and compatibility matrices will not have entries defining rules to resolve conflicts arising as a result of features added by end users. If the feature interaction cannot be resolved by the defined rules, an adaptive rule-based mechanism is invoked, which prompts the user of the personal computer to make a feature selection.
In the present embodiment, the feature extension concept is based on a representation of features as condition-action rules. In a condition-action rule, each condition defines a precondition for applying a feature. Extensions are similar to specializations in object-oriented programming where a subclass extends the behavior of a superclass by adding attributes and operations. In the present invention, an extension defines an alternative flow of execution of a feature.
Extensions are defined by assertions having a syntax similar to Prolog and generally take the form:
assertion(argl,arg2,. . .,argl~
Assertions defining extensions take the form:
extends(feature2,feature 1 ) where feature 2 extends feature 1 and is executed instead of feature 1.
Assertions defining mutually compatible features take the form:
compatible(feature3,feature 1 ) where feature 3 and feature 1 are compatible and are executed in conjunction in response to an event.
For example, consider the terminating call (TC), call forwarding busy (CFB) and call waiting (CW) features. Each of these features can be invoked in response to an incoming call event and triggers on the same precondition, namely "no connection available". The CFB and CW features are both extensions of the TC
feature and define alternative actions to be taken when an incoming call event occurs and no connection is available instead of performing the typical reject call procedure.
The CFB and CW features take the form:
extends(CFB,TC) extends(CW,TC) Figure 3 illustrates the concept of "extension" between use cases. Each feature is represented by a use case, shown as an ellipse. Both CW and CFB
features are shown to extend the TC feature (the "extends" arrow points at the feature being extended). The TC use case describes the normal flow of behavior for processing an incoming call. The CW and CFB use cases describe exceptional flows to pursue when certain preconditions are satisfied in the TC use case.
Each extension applies at a specific point (or checkpoint) in the extended use case. At this point, a precondition associated with the extension is tested and, when satisfied, the corresponding exceptional flow is followed. When an exceptional flow is completed, it resumes the normal flow of the extended use case from the checkpoint. At this stage, a check for a postcondition is made to ensure successful completion of the exceptional flow. The unsuccessful completion of an exceptional flow may trigger another exceptional flow, in turn. As extensions to use cases can themselves be extended, features can further extend other features that themselves extend features. The last feature in the extension chain receives relative priority over the others.
Figure 4 illustrates the situation where all three actions prescribed by the TC, CFB and CW features can be pursued. The normal action in response to receiving an incoming call when no connection is available is to reject the call following execution of the TC feature (action 4). If the CFB and the CW
features are active, the incoming call can be handled either by forwarding the call (action 6) or announcing the call to the user through a warble (action 8). Only one of these later two actions should be pursued since their effects conflict with each other.
The incoming call cannot both be forwarded and announced at the same time.
As mentioned above, typically entries in the preference and compatibility matrices define the rules, which determine the feature or features to be executed in the event of a feature conflict. An example of a precedence matrix is shown below for the CFB and CW features. In this preference matrix, a "1"
entry signifies that a feature precedes another feature while a "0" entry signifies a feature that is preceded by another feature. Thus, in this example, the CFB feature precedes the CW feature.
CFB CW
... ... ...
CFB ~ ... - 1 ...
CW ~ ... 0 - ...
... ... ...
Accordingly, this precedence matrix defines the precedence rule:
precedes(CFB,CW) Also as mentioned above, features may be mutually compatible in which case they are expected to be executed in conjunction. Although not shown, the compatibility matrix is of a form similar to the precedence matrix. Entries therein define rules establishing features that can be executed in conjunction. For example, a billing feature can be executed in conjunction with the TC, CFB and CW features since the billing feature executes in a service different than the handle incoming call service. In this example, the compatibility matrix defines the compatibility rule:
compatible(?any,billing) As will be appreciated, the rules defined by the precedence and compatibility matrices governing how features are to be handled, can be different for different users depending on their' preferences.
When an event occurs and two or more conflicting features can be executed in response to an event, the adaptive rule-based mechanism is invoked to resolve the conflict. In the communication system 10, telephony server 16 invokes the adaptive rule-based mechanism when a conflicting feature interaction in one of the personal computers 14 is determined. 'The personal computers 20 invoke the adaptive rule-based mechanism when a conflicting feature interaction is determined at the customer locations.
Turning now to Figures Sa to Sc, the steps performed by the adaptive rule-based mechanism to resolve conflicts are shown. As can be seen, the adaptive rule-based mechanism implements a three-phase process to resolve conflicting feature interactions. At phase 1 (see Figure Sa), conflicts between features are determined.
Initially, a conflict set and an executable set are opened (block 100). The features associated with the service to be performed in response to the event are then examined to determine if they are applicable to the service to be performed (block 102). If the feature is applicable to the service, the feature is added to the conflict set (block 104).
This process is performed until all of the of the features have been examined (block 106).
Once execution of phase 1 has been completed, phase 2 of the adaptive rule-based mechanism is executed (see Figure Sb). At phase 2, the conflict set is examined to determine if more than one feature is in the conflict set (block 110). If more than one feature is in the conflict set, each feature in the conflict set is examined to determine if it extends other features in the conflict set (block 112). If a feature e~ctends other features, the extended features are removed from the conflict set (block 114). If features in the conflict set exist that are not extended by another feature, the precedence rules are examined to determine if any feature precedes other features in the conflict set (block 116). Features preceded by a feature are removed from the conflict set (block 118). If features in the conflict set exist that are not extended or preceded by another feature, the compatibility rules are examined to determine if features in the conflict set are compatible with other features in the conflict set (block 120). If features are compatible with other features, they are removed from the conflict set (block 122) and are added to the executable set (block 124).
Once the above steps have been performed for all of the features in the conflict set, phase 2 is complete and phase 3 of the adaptive rule-based mechanism is commenced (see Figure Sc). At phase 3, the conflict set is examined to determine if more than one feature exists (block 130). If only one feature exists, the feature is added to the executable set (block 132). The adaptive rule-based mechanism is then exited and the feature or features in the executable set are executed to complete the service to be performed. If more than one feature exists in the conflict set, a pop-up dialog box 200 (see Figure 8) showing a list of the features in the conflict set is presented to the user. The pop-up dialog box 200 allows the user to select a feature in the conflict set and indicate that it precedes the other features) by selecting the "precedes" button 202 or indicate that the features are compatible by selecting the "compatible" button 204 (blocks 134a, 134b and 134c). The user can also indicate whether the selection is to be learned for future use by selecting the "Learn"
checkbox 206.
If the user selects a feature to precede the other feature(s), the selected feature is added to the executable set (block 136). The user can add a precedence rule to the precedence matrix corresponding to the selected feature by selecting the Learn checkbox 206 (block 138). If a precedence rule is to be added, the precedence matrix is updated (block 140) and the adaptive rule-based mechanism is exited. The feature or features in the executable set are then executed to complete the service to be performed. If the user decides not to add a precedence rule to the precedence matrix, the adaptive rule-based mechanism is exited. The feature or features in the executable set are then executed to complete the service to be performed.
If the user indicates that the features are compatible, the conflict set is added to the executable set (block 146). The user can add a compatibility rule to the compatibility matrix corresponding to the selection by selecting the Learn checkbox 206 (block 148). If a compatibility rule is to be added, the compatibility matrix is updated (block 150) and the adaptive rule-based mechanism is exited. The features in the executable set are then executed to complete the service to be performed.
If the user decides not to add a compatibility rule to the compatibility matrix, the adaptive rule-based mechanism is exited. The features in the executable set are then executed to complete the service to be performed.
The feature interaction resolution process described above with reference to Figures Sa to Sc is also shown in Appendix A.
As will be appreciated, if the user adds precedence and compatibility rules to the precedence and compatibility matrices, the next time a conflict is encountered between the conflicting features, the new rule will be applied and it will not be necessary to prompt the user for assistance. The adaptive rule-based mechanism will have "remembered" the user's preference without requiring explicit programming by the end user.
An example of the above-described process to resolve conflicts will now be described for a handle incoming call service where the TC, CFB and CW
features are all part of the service and where the billing feature is compatible with the features in the service. The assertions set forth below define the above:
service(handle-incoming-call, {TC, CFB, CW, billing}) extends(CFB, TC) extends(CW, TC) compatible(?any, billing) The assertions below describe the situation when an incoming call is placed by a user Joanne to a user Michael and there is no connection available:
user(Michael) user(Joanne) terminal(terminal-1 ) terminal(terminal-2) attached(terminal-l, michael) busy(terminal-1 ) attached(terminal-2, Joanne) busy(terminal-2) incoming-call(joanne, michael) The following rules describe the features of the handle incoming call service that are activated by a busy condition:
;; Terminating Call if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then reject-incoming-call(?source, ?destination) ;; Call Forwarding Busy if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then forward-incoming-call(?source, ?destination) ;; Call Waiting if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then announce-incoming-call(?source, ?destination, warble) Since the CFB and CW features conflict, the adaptive rule-based mechanism is invoked to resolve the conflict. During the conflict resolution process, the following intermediary results will be observed after the completion of each phase:
Phase 1:
After applying the "applicable" rule (block 102):
?conflict-set = {TC, CFB, CW, billing}
?executable-set = { ~
-1$-Phase 2:
After applying the "extends" rule (blocks 112 and 114):
?conflict-set = {CFB, CW, billing}
$ ?executable-set = { }
After applying the "precedes" rule (blocks 116 and 118):
?conflict-set = {CFB, CW, billing}
?executable-set = { }
After applying the "compatible" rule (blocks 120 and 122):
?conflict-set = {CFB, CW}
?executable-set = {billing}
1$ Phase 3:
After applying the "size" rule (block 130), the user is then asked to select the feature in the conflict set {CFB, CW} which precedes the other (there could of course be more than one other feature) or to indicate that the features are mutually compatible.
If the user selects the CFB feature at block 134b and the learn option at block 138 to signify that the feature selection should be remembered, the following assertion is generated:
user-selection({CFB, CW}, precedes, CFB, learn) After applying 'the "user-selection" assertion:
2$ ?conflict-set = { }
?executable-set = {billing, CFB}
The following rule is then generated and added to the precedence matrix:
precedes(CFB, CW) As will be appreciated, after the adaptive rule-based mechanism is invoked, feature interactions are resolved allowing services to be performed.
If desired, rules can be established to govern feature selection when the same services are to be performed in the future. Since feature interactions are resolved in an adaptive manner, different users can establish their own preferences.
Rather than presenting the list of features in the conflict set to the user in a pop-up dialog box, and prompting the user to select whether a feature precedes other features or is compatible with other features at blocks 134a, 134b and 134c, alternatives are available. For example, before presenting the list of features in the conflict set to the user, the list of features in the conflict set can be filtered using the level assigned to the user (see Figure 2) to determine if there are features in the conflict set that have a level above that assigned to the user. For example, in the case of the billing feature, end users are typically not permitted to modify preference rules that involve this feature whereas the system administrator typically is.
Figure 6 shows an extension of the flow chart of Figure Sc illustrating the steps performed to filter the features in the conflict set in this manner.
If at block 130, more than one feature exists in the conflict set, the level assigned to each feature 1 S is compared with the level assigned to the user (block 180). If the levels assigned to the features in the conflict set are equal to or below the level assigned to the user, the conflict resolution process proceeds as described previously enabling the user to resolve the conflict completely (block 182). However, if one or more of the features in the conflict set have levels above that assigned to the user, the adaptive rule-based mechanism selects one of the features randomly to precede the other features and adds the feature to the executable set (block 184). The adaptive rule-based mechanism then generates a report for the system administrator (block 186) before exiting.
Once exited, the feature or features in the executable set are executed to complete the service to be performed.
In an alternative embodiment, at blocks 134a, 134b and 134c the list of features in the conflict set is converted to a voice message and presented audibly to the user rather than visually via the pop-up dialog box. It has been found that users often lack the technical sophistication to select a feature from a list. The features in the conflict set can be presented either to the user of the feature telephone device or an external party, such as for example a customer calling into a call center, with appropriate prompts to select a feature by pressing a number key on the user's feature telephone device to generate a DTMF tone. When the features are presented to the user of the feature telephone device, the voice message prompts are similar to the features in the conflict set. For example, the voice message prompts may take the form:
Press 1 to select call forward when busy Press 2 to select call waiting Press 3 to select call forward to voice mail When the features are presented to the external party, it is preferred that the voice message provides meaningful information rather than using the technical names of the features. For example, the voice message prompts to the external party may take the form:
Press 1 if you want to be forwarded to another service representative Press 2 if you want to be forwarded to voice mail.
When the user of the feature telephone device or the external party selects a feature by entering the appropriate digit thereby to generate the DTMF tone, the feature is selected by the adaptive rule-based mechanism and added to the executable set. The adaptive rule-based mechanism then proceeds as described previously.
In yet another embodiment, rather than presenting the features in the conflict set in a list within the pop-up display box, the list of features in conflict set can be presented as user selectable icons (see Figure 7). As can be seen each icon provides a visual representation of the associated feature. Preferably, the icons flash forcing the user to select an icon to resolve the conflicting feature interaction. The use of icons over a list is likely to be more manageable and intuitive to the end user.
However, in order for the icons to present visual representations of the associated features, conflicting feature interactions must be anticipated during design.
In still yet another embodiment, features are mapped to canned message fragments presented audibly to an external party to encode a policy to deal with message types. The mapping in this case is represented as set of production rules similar in form to the rules previously described. For example, in the case of business location 12, there may be a policy to ensure personal calls routed to a call center agent do not interrupt customer calls and to ensure customer calls are not routed to voice mail. In this case, when an external party calls the business location, the external party is presented with the following canned messages:
Press 1 if this is a personal call Press 2 if this is a business call Based on the selection made by the external party, the production rules are used by the adaptive rule-based mechanism to resolve conflicting features in a manner which follows the encoded policy. In the above example, production rules to ensure personal calls do not interrupt business calls and to ensure business calls do not get routed to voice mail take the form:
If includes(?conflict-set, call-forwarding-busy) And user-selection(?x) And message-fragment(?x, "if this is a personal call") Then remove-from-conflict-set(?conflict-set, call-forwarding-busy) If includes(?conflict-set, voicemail) And user-selection(?x) And message-fragment(?x, "if this is a business call") Then remove-from-conflict-set(voicemail) These production rules test if a certain feature is in the conflict set, and if the external party has selected an option corresponding to a specified message fragment (as determined by the DTMF tone). If the condition part of a rule is satisfied, the feature is removed from the conflict set thereby to enforce the stated policy.
Although the present invention has been described with particular reference to the resolution of conflicting feature interactions in a telephony communication system, those of skill in the art will appreciate that the adaptive rule-based mechanism is not limited to this domain. The present adaptive rule-based mechanism can be extended to virtually any kind of software system where features conflict. For example, the adaptive rule-based mechanism can be incorporated into a word processing application including multiple services such as spell-checking, formatting etc, or a World Wide Web browser.
The adaptive rule-based mechanism can be embodied as computer readable program code on a computer readable medium. The computer readable medium is any data storage device that can store data, which thereafter can be read by a computer system. Examples of the computer readable medium include ROM, RAM, CD-ROM, magnetic tape and optical data storage devices.
Those of skill in the art will also appreciate that variations and modifications may be made to the present invention without departing from the spirit and scope thereof as defined by the appended claims.
APPENDIX A
;; Phase 1 if applicable(?feature) then add-to-conflict-set(?conflict-set, ?feature) ;; Phase 2a if extends(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) ;; Phase 2b if precedes(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) ;; Phase 2c if compatible(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) and add-to-executable-set(?executable-set, ?featureB) ;; Phase 3 if size(?conflict-set) = 1 then merge(?executable-set, ?conflict-set) and clear(?conflict-set) if size(?conflict-set) > 1 then ask-user-to-select(?conflict-set, ?feature) if user-selection(?conflict-set, precedes, ?feature, learn) then add-to-executable-set(?executable-set, ?feature) and for all ?x <> ?feature in ?conflict-set:
add-rule (precedes(?feature, ?x)) and APPENDIX A (Con't) clear(?conflict-set) if user-selection(?conflict-set, precedes, ?feature, only-once) then add-to-executable-set(?executable-set, ?feature) clear(?conflict-set) if user-selection(?conflict-set, compatible, ?feature, learn) then merge(?executable-set, ?conflict-set) for all ?x o ?feature in ?conflict-set:
add-rule (compatible(?feature, ?x)) and clear(?conflict-set) if user-selection(?conflict-set, compatible, ?feature, only-once) then merge(?executable-set, ?conflict-set) clear(?conflict-set)
Figure 1 is a schematic diagram of a communication system including a plurality of user locations;
Figure 2 shows user level priorities in the communication system of Figure 1;
Figure 3 is a use case diagram showing a terminating call feature extended by call forwarding busy and call waiting features;
Figure 4 illustrates the steps performed during a handle incoming call service for terminating call, call forwarding busy and call waiting features;
Figures Sa to Sc are flow charts illustrating the steps performed during execution of an adaptive rule-based mechanism for resolving conflicting feature interactions in accordance with the present invention;
Figure 6 is a flow chart illustrating steps performed during filtering of conflicting feature interactions;
Figure 7 illustrates user selectable icons representing conflicting features; and Figure 8 is a pop-up dialog box presented to a user during execution of the adaptive rule-based mechanism for resolving conflicting feature interactions.
Detailed Description Of The Preferred Embodiment The present invention relaxes to an adaptive rule-based mechanism and method for resolving feature interactions in environments where two or more available indeterminate features can be invoked simultaneously in response to an event resulting in a conflict. The present invention is based on a separation between the policy and mechanism of feature execution. The policy provided by the feature execution environment detects and resolves known or potential feature interactions.
The policy is generic inasmuch as it requires no internal knowledge of the mechanisms. It only requires that features implement a common set of methods or functions by which the policy can ask a feature, for example, whether it is applicable in a given situation, and which features extend it. A system with policy-mechanism _7_ separation can accordingly deal with the requirements of an open evolving system.
For the sake of clarity, an embodiment of the adaptive rule-based mechanism in accordance with the present invention implemented in a telephony communication system will now be described.
Referring to Figure 1, a communication system is shown and is generally indicated to by reference numeral 10. In this example, communication system 10 includes a business location 12 having a plurality of personal computers 14, two of which are shown for illustrative purposes, connected to a telephony server 16 over a local area network. Telephony server 16 is connected to a telephone network 18 such as a public switched telephone network (PSTN). Personal computers 20 at customer locations are also connected to the telephone network 18. Each personal computer 14 and 20 is equipped with the necessary communication hardware and software to allow telephone calls with other communication devices to be established.
The hardware and software resources of the personal computers 14 and 20, which allow them to function as desktop feature telephone devices, provide users with telephone features offering enhanced functionality. These features may be programmed by users of the personal computers, or established by the administrator of the business location 12 or developer of the communication system 10. The features available to each personal computer are listed in precedence and compatibility matrices stored in memory. At the business location 12, the precedence and compatibility matrices are stored in telephony server memory while at the customer locations, the precedence and compatibility matrices are stored in resident memory within the personal computers 20. The precedence and compatibility matrices define rules governing the selection of features to deal with conflicting and compatible features thereby to allow services to be performed in response to events.
Specifically, entries in the precedence matrix determine a user's preference when two or more conflicting features are available to the user that can be executed at the same time in response to an event. Entries in the compatibility matrix determine mutually compatible features, which are to be executed simultaneously in response to an event.
Different levels of rules corresponding to different levels of users in the communication system 10 (most common at business locations) can exist as shown in Figure 2. In this case, rules created by a user of a higher priority cannot be _g_ overridden by a user of lower priority. Rules use an if then representation and may include simple arithmetic operators. 'lariables are indicated by the "?"
prefix and every other symbol is a terminal. The execution model for rules follows that of a typical forward chaining expert system such as OPS-5. The only extension made is that rules are to be executed in phases where indicated. The rules in phase 1 are applied before those in phase 2, etc., until no more rules can be found. The execution then proceeds to the next phase. In this way, the result of the application of the set of rules from one phase is "piped" into the set of rules from the subsequent phase.
The personal computers allow features to be plugged into the communication software framework at design time and run time. Since users can plug new features into the communication software framework, new features can be added, which conflict with existing features. A conflicting feature interaction is flagged when more than one feature can be executed in response to an event and the feature execution outcome is potentially indeterminate. Usually, the precedence and compatibility matrices will not have entries defining rules to resolve conflicts arising as a result of features added by end users. If the feature interaction cannot be resolved by the defined rules, an adaptive rule-based mechanism is invoked, which prompts the user of the personal computer to make a feature selection.
In the present embodiment, the feature extension concept is based on a representation of features as condition-action rules. In a condition-action rule, each condition defines a precondition for applying a feature. Extensions are similar to specializations in object-oriented programming where a subclass extends the behavior of a superclass by adding attributes and operations. In the present invention, an extension defines an alternative flow of execution of a feature.
Extensions are defined by assertions having a syntax similar to Prolog and generally take the form:
assertion(argl,arg2,. . .,argl~
Assertions defining extensions take the form:
extends(feature2,feature 1 ) where feature 2 extends feature 1 and is executed instead of feature 1.
Assertions defining mutually compatible features take the form:
compatible(feature3,feature 1 ) where feature 3 and feature 1 are compatible and are executed in conjunction in response to an event.
For example, consider the terminating call (TC), call forwarding busy (CFB) and call waiting (CW) features. Each of these features can be invoked in response to an incoming call event and triggers on the same precondition, namely "no connection available". The CFB and CW features are both extensions of the TC
feature and define alternative actions to be taken when an incoming call event occurs and no connection is available instead of performing the typical reject call procedure.
The CFB and CW features take the form:
extends(CFB,TC) extends(CW,TC) Figure 3 illustrates the concept of "extension" between use cases. Each feature is represented by a use case, shown as an ellipse. Both CW and CFB
features are shown to extend the TC feature (the "extends" arrow points at the feature being extended). The TC use case describes the normal flow of behavior for processing an incoming call. The CW and CFB use cases describe exceptional flows to pursue when certain preconditions are satisfied in the TC use case.
Each extension applies at a specific point (or checkpoint) in the extended use case. At this point, a precondition associated with the extension is tested and, when satisfied, the corresponding exceptional flow is followed. When an exceptional flow is completed, it resumes the normal flow of the extended use case from the checkpoint. At this stage, a check for a postcondition is made to ensure successful completion of the exceptional flow. The unsuccessful completion of an exceptional flow may trigger another exceptional flow, in turn. As extensions to use cases can themselves be extended, features can further extend other features that themselves extend features. The last feature in the extension chain receives relative priority over the others.
Figure 4 illustrates the situation where all three actions prescribed by the TC, CFB and CW features can be pursued. The normal action in response to receiving an incoming call when no connection is available is to reject the call following execution of the TC feature (action 4). If the CFB and the CW
features are active, the incoming call can be handled either by forwarding the call (action 6) or announcing the call to the user through a warble (action 8). Only one of these later two actions should be pursued since their effects conflict with each other.
The incoming call cannot both be forwarded and announced at the same time.
As mentioned above, typically entries in the preference and compatibility matrices define the rules, which determine the feature or features to be executed in the event of a feature conflict. An example of a precedence matrix is shown below for the CFB and CW features. In this preference matrix, a "1"
entry signifies that a feature precedes another feature while a "0" entry signifies a feature that is preceded by another feature. Thus, in this example, the CFB feature precedes the CW feature.
CFB CW
... ... ...
CFB ~ ... - 1 ...
CW ~ ... 0 - ...
... ... ...
Accordingly, this precedence matrix defines the precedence rule:
precedes(CFB,CW) Also as mentioned above, features may be mutually compatible in which case they are expected to be executed in conjunction. Although not shown, the compatibility matrix is of a form similar to the precedence matrix. Entries therein define rules establishing features that can be executed in conjunction. For example, a billing feature can be executed in conjunction with the TC, CFB and CW features since the billing feature executes in a service different than the handle incoming call service. In this example, the compatibility matrix defines the compatibility rule:
compatible(?any,billing) As will be appreciated, the rules defined by the precedence and compatibility matrices governing how features are to be handled, can be different for different users depending on their' preferences.
When an event occurs and two or more conflicting features can be executed in response to an event, the adaptive rule-based mechanism is invoked to resolve the conflict. In the communication system 10, telephony server 16 invokes the adaptive rule-based mechanism when a conflicting feature interaction in one of the personal computers 14 is determined. 'The personal computers 20 invoke the adaptive rule-based mechanism when a conflicting feature interaction is determined at the customer locations.
Turning now to Figures Sa to Sc, the steps performed by the adaptive rule-based mechanism to resolve conflicts are shown. As can be seen, the adaptive rule-based mechanism implements a three-phase process to resolve conflicting feature interactions. At phase 1 (see Figure Sa), conflicts between features are determined.
Initially, a conflict set and an executable set are opened (block 100). The features associated with the service to be performed in response to the event are then examined to determine if they are applicable to the service to be performed (block 102). If the feature is applicable to the service, the feature is added to the conflict set (block 104).
This process is performed until all of the of the features have been examined (block 106).
Once execution of phase 1 has been completed, phase 2 of the adaptive rule-based mechanism is executed (see Figure Sb). At phase 2, the conflict set is examined to determine if more than one feature is in the conflict set (block 110). If more than one feature is in the conflict set, each feature in the conflict set is examined to determine if it extends other features in the conflict set (block 112). If a feature e~ctends other features, the extended features are removed from the conflict set (block 114). If features in the conflict set exist that are not extended by another feature, the precedence rules are examined to determine if any feature precedes other features in the conflict set (block 116). Features preceded by a feature are removed from the conflict set (block 118). If features in the conflict set exist that are not extended or preceded by another feature, the compatibility rules are examined to determine if features in the conflict set are compatible with other features in the conflict set (block 120). If features are compatible with other features, they are removed from the conflict set (block 122) and are added to the executable set (block 124).
Once the above steps have been performed for all of the features in the conflict set, phase 2 is complete and phase 3 of the adaptive rule-based mechanism is commenced (see Figure Sc). At phase 3, the conflict set is examined to determine if more than one feature exists (block 130). If only one feature exists, the feature is added to the executable set (block 132). The adaptive rule-based mechanism is then exited and the feature or features in the executable set are executed to complete the service to be performed. If more than one feature exists in the conflict set, a pop-up dialog box 200 (see Figure 8) showing a list of the features in the conflict set is presented to the user. The pop-up dialog box 200 allows the user to select a feature in the conflict set and indicate that it precedes the other features) by selecting the "precedes" button 202 or indicate that the features are compatible by selecting the "compatible" button 204 (blocks 134a, 134b and 134c). The user can also indicate whether the selection is to be learned for future use by selecting the "Learn"
checkbox 206.
If the user selects a feature to precede the other feature(s), the selected feature is added to the executable set (block 136). The user can add a precedence rule to the precedence matrix corresponding to the selected feature by selecting the Learn checkbox 206 (block 138). If a precedence rule is to be added, the precedence matrix is updated (block 140) and the adaptive rule-based mechanism is exited. The feature or features in the executable set are then executed to complete the service to be performed. If the user decides not to add a precedence rule to the precedence matrix, the adaptive rule-based mechanism is exited. The feature or features in the executable set are then executed to complete the service to be performed.
If the user indicates that the features are compatible, the conflict set is added to the executable set (block 146). The user can add a compatibility rule to the compatibility matrix corresponding to the selection by selecting the Learn checkbox 206 (block 148). If a compatibility rule is to be added, the compatibility matrix is updated (block 150) and the adaptive rule-based mechanism is exited. The features in the executable set are then executed to complete the service to be performed.
If the user decides not to add a compatibility rule to the compatibility matrix, the adaptive rule-based mechanism is exited. The features in the executable set are then executed to complete the service to be performed.
The feature interaction resolution process described above with reference to Figures Sa to Sc is also shown in Appendix A.
As will be appreciated, if the user adds precedence and compatibility rules to the precedence and compatibility matrices, the next time a conflict is encountered between the conflicting features, the new rule will be applied and it will not be necessary to prompt the user for assistance. The adaptive rule-based mechanism will have "remembered" the user's preference without requiring explicit programming by the end user.
An example of the above-described process to resolve conflicts will now be described for a handle incoming call service where the TC, CFB and CW
features are all part of the service and where the billing feature is compatible with the features in the service. The assertions set forth below define the above:
service(handle-incoming-call, {TC, CFB, CW, billing}) extends(CFB, TC) extends(CW, TC) compatible(?any, billing) The assertions below describe the situation when an incoming call is placed by a user Joanne to a user Michael and there is no connection available:
user(Michael) user(Joanne) terminal(terminal-1 ) terminal(terminal-2) attached(terminal-l, michael) busy(terminal-1 ) attached(terminal-2, Joanne) busy(terminal-2) incoming-call(joanne, michael) The following rules describe the features of the handle incoming call service that are activated by a busy condition:
;; Terminating Call if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then reject-incoming-call(?source, ?destination) ;; Call Forwarding Busy if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then forward-incoming-call(?source, ?destination) ;; Call Waiting if busy(?terminal) and incoming-call(?source, ?destination) and terminal(?terminal) and user(?source) and user(?destination) and attached(?terminal, ?destination) then announce-incoming-call(?source, ?destination, warble) Since the CFB and CW features conflict, the adaptive rule-based mechanism is invoked to resolve the conflict. During the conflict resolution process, the following intermediary results will be observed after the completion of each phase:
Phase 1:
After applying the "applicable" rule (block 102):
?conflict-set = {TC, CFB, CW, billing}
?executable-set = { ~
-1$-Phase 2:
After applying the "extends" rule (blocks 112 and 114):
?conflict-set = {CFB, CW, billing}
$ ?executable-set = { }
After applying the "precedes" rule (blocks 116 and 118):
?conflict-set = {CFB, CW, billing}
?executable-set = { }
After applying the "compatible" rule (blocks 120 and 122):
?conflict-set = {CFB, CW}
?executable-set = {billing}
1$ Phase 3:
After applying the "size" rule (block 130), the user is then asked to select the feature in the conflict set {CFB, CW} which precedes the other (there could of course be more than one other feature) or to indicate that the features are mutually compatible.
If the user selects the CFB feature at block 134b and the learn option at block 138 to signify that the feature selection should be remembered, the following assertion is generated:
user-selection({CFB, CW}, precedes, CFB, learn) After applying 'the "user-selection" assertion:
2$ ?conflict-set = { }
?executable-set = {billing, CFB}
The following rule is then generated and added to the precedence matrix:
precedes(CFB, CW) As will be appreciated, after the adaptive rule-based mechanism is invoked, feature interactions are resolved allowing services to be performed.
If desired, rules can be established to govern feature selection when the same services are to be performed in the future. Since feature interactions are resolved in an adaptive manner, different users can establish their own preferences.
Rather than presenting the list of features in the conflict set to the user in a pop-up dialog box, and prompting the user to select whether a feature precedes other features or is compatible with other features at blocks 134a, 134b and 134c, alternatives are available. For example, before presenting the list of features in the conflict set to the user, the list of features in the conflict set can be filtered using the level assigned to the user (see Figure 2) to determine if there are features in the conflict set that have a level above that assigned to the user. For example, in the case of the billing feature, end users are typically not permitted to modify preference rules that involve this feature whereas the system administrator typically is.
Figure 6 shows an extension of the flow chart of Figure Sc illustrating the steps performed to filter the features in the conflict set in this manner.
If at block 130, more than one feature exists in the conflict set, the level assigned to each feature 1 S is compared with the level assigned to the user (block 180). If the levels assigned to the features in the conflict set are equal to or below the level assigned to the user, the conflict resolution process proceeds as described previously enabling the user to resolve the conflict completely (block 182). However, if one or more of the features in the conflict set have levels above that assigned to the user, the adaptive rule-based mechanism selects one of the features randomly to precede the other features and adds the feature to the executable set (block 184). The adaptive rule-based mechanism then generates a report for the system administrator (block 186) before exiting.
Once exited, the feature or features in the executable set are executed to complete the service to be performed.
In an alternative embodiment, at blocks 134a, 134b and 134c the list of features in the conflict set is converted to a voice message and presented audibly to the user rather than visually via the pop-up dialog box. It has been found that users often lack the technical sophistication to select a feature from a list. The features in the conflict set can be presented either to the user of the feature telephone device or an external party, such as for example a customer calling into a call center, with appropriate prompts to select a feature by pressing a number key on the user's feature telephone device to generate a DTMF tone. When the features are presented to the user of the feature telephone device, the voice message prompts are similar to the features in the conflict set. For example, the voice message prompts may take the form:
Press 1 to select call forward when busy Press 2 to select call waiting Press 3 to select call forward to voice mail When the features are presented to the external party, it is preferred that the voice message provides meaningful information rather than using the technical names of the features. For example, the voice message prompts to the external party may take the form:
Press 1 if you want to be forwarded to another service representative Press 2 if you want to be forwarded to voice mail.
When the user of the feature telephone device or the external party selects a feature by entering the appropriate digit thereby to generate the DTMF tone, the feature is selected by the adaptive rule-based mechanism and added to the executable set. The adaptive rule-based mechanism then proceeds as described previously.
In yet another embodiment, rather than presenting the features in the conflict set in a list within the pop-up display box, the list of features in conflict set can be presented as user selectable icons (see Figure 7). As can be seen each icon provides a visual representation of the associated feature. Preferably, the icons flash forcing the user to select an icon to resolve the conflicting feature interaction. The use of icons over a list is likely to be more manageable and intuitive to the end user.
However, in order for the icons to present visual representations of the associated features, conflicting feature interactions must be anticipated during design.
In still yet another embodiment, features are mapped to canned message fragments presented audibly to an external party to encode a policy to deal with message types. The mapping in this case is represented as set of production rules similar in form to the rules previously described. For example, in the case of business location 12, there may be a policy to ensure personal calls routed to a call center agent do not interrupt customer calls and to ensure customer calls are not routed to voice mail. In this case, when an external party calls the business location, the external party is presented with the following canned messages:
Press 1 if this is a personal call Press 2 if this is a business call Based on the selection made by the external party, the production rules are used by the adaptive rule-based mechanism to resolve conflicting features in a manner which follows the encoded policy. In the above example, production rules to ensure personal calls do not interrupt business calls and to ensure business calls do not get routed to voice mail take the form:
If includes(?conflict-set, call-forwarding-busy) And user-selection(?x) And message-fragment(?x, "if this is a personal call") Then remove-from-conflict-set(?conflict-set, call-forwarding-busy) If includes(?conflict-set, voicemail) And user-selection(?x) And message-fragment(?x, "if this is a business call") Then remove-from-conflict-set(voicemail) These production rules test if a certain feature is in the conflict set, and if the external party has selected an option corresponding to a specified message fragment (as determined by the DTMF tone). If the condition part of a rule is satisfied, the feature is removed from the conflict set thereby to enforce the stated policy.
Although the present invention has been described with particular reference to the resolution of conflicting feature interactions in a telephony communication system, those of skill in the art will appreciate that the adaptive rule-based mechanism is not limited to this domain. The present adaptive rule-based mechanism can be extended to virtually any kind of software system where features conflict. For example, the adaptive rule-based mechanism can be incorporated into a word processing application including multiple services such as spell-checking, formatting etc, or a World Wide Web browser.
The adaptive rule-based mechanism can be embodied as computer readable program code on a computer readable medium. The computer readable medium is any data storage device that can store data, which thereafter can be read by a computer system. Examples of the computer readable medium include ROM, RAM, CD-ROM, magnetic tape and optical data storage devices.
Those of skill in the art will also appreciate that variations and modifications may be made to the present invention without departing from the spirit and scope thereof as defined by the appended claims.
APPENDIX A
;; Phase 1 if applicable(?feature) then add-to-conflict-set(?conflict-set, ?feature) ;; Phase 2a if extends(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) ;; Phase 2b if precedes(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) ;; Phase 2c if compatible(?featureA, ?featureB) then remove-from-conflict-set(?conflict-set, ?featureB) and add-to-executable-set(?executable-set, ?featureB) ;; Phase 3 if size(?conflict-set) = 1 then merge(?executable-set, ?conflict-set) and clear(?conflict-set) if size(?conflict-set) > 1 then ask-user-to-select(?conflict-set, ?feature) if user-selection(?conflict-set, precedes, ?feature, learn) then add-to-executable-set(?executable-set, ?feature) and for all ?x <> ?feature in ?conflict-set:
add-rule (precedes(?feature, ?x)) and APPENDIX A (Con't) clear(?conflict-set) if user-selection(?conflict-set, precedes, ?feature, only-once) then add-to-executable-set(?executable-set, ?feature) clear(?conflict-set) if user-selection(?conflict-set, compatible, ?feature, learn) then merge(?executable-set, ?conflict-set) for all ?x o ?feature in ?conflict-set:
add-rule (compatible(?feature, ?x)) and clear(?conflict-set) if user-selection(?conflict-set, compatible, ?feature, only-once) then merge(?executable-set, ?conflict-set) clear(?conflict-set)
Claims (29)
1. In a system where two or more indeterminate features can be executed in response to an event resulting in a conflicting feature interaction, an adaptive rule-based method for resolving said conflicting feature interaction comprising the steps of:
determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, prompting a user to select one of said indeterminate features for execution thereby to resolve said conflicting feature interaction.
determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, prompting a user to select one of said indeterminate features for execution thereby to resolve said conflicting feature interaction.
2. The method of claim 1 wherein during said examining step, rules are examined to determine if one of said indeterminate features takes priority over other indeterminate features.
3. The method of claim 2 wherein said rules are user programmable.
4. The method of claim 3 wherein during said prompting step, said user is prompted either to select one indeterminate feature for execution or indicate that the indeterminate features are compatible, if said indeterminate features are indicated as being compatible, all of said indeterminate features being selected for execution in conjunction.
5. The method of claim 4 further comprising the step of prompting said user to decide if a rule is to be established corresponding to the selected one indeterminate feature or the feature compatibility indication.
6. The method of claim 5 wherein during said determining step, said indeterminate features are placed in a conflict set, when one of said indeterminate features is determined to take priority over the other indeterminate features, the other indeterminate features are removed from said conflict set.
7. The method of claim 6 wherein during said examining step, said conflict set is examined to determine:
features;
whether any of the indeterminate features extend other indeterminate whether any of the indeterminate features take precedence over other indeterminate features in accordance with a set of precedence rules; and whether any indeterminate features are compatible with other indeterminate features in accordance with a set of compatibility rules, indeterminate features extended and preceded by other indeterminate features being removed from said conflict set and indeterminate features compatible with other indeterminate features being removed from said conflict set and placed in an executable set.
features;
whether any of the indeterminate features extend other indeterminate whether any of the indeterminate features take precedence over other indeterminate features in accordance with a set of precedence rules; and whether any indeterminate features are compatible with other indeterminate features in accordance with a set of compatibility rules, indeterminate features extended and preceded by other indeterminate features being removed from said conflict set and indeterminate features compatible with other indeterminate features being removed from said conflict set and placed in an executable set.
8. The method of any one of claims 1 to 7 wherein said indeterminate features represent executable options to be performed to complete a service.
9. The method of claim 8 wherein said service relates to a procedure performed during a telephone communication session
10. The method of any one of claims 1 to 9 wherein during said prompting, said indeterminate features are represented as user selectable icons presented to said user on a device.
11. The method of claim 10 wherein said user selectable icons flash.
12. The method of claim 10 wherein said device is a computer telephone device having a monitor with a display screen.
13. In a telephony communication system wherein a service is to be performed in response to an event, said system including a plurality of executable conflicting features representing available options which can be performed to complete said service, an adaptive rule-based method to resolve feature conflicts during performance of said service comprising the steps of:
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one of said conflicting feature does not take priority, prompting a user to select one of said conflicting features for execution to resolve said conflicting feature interaction and executing the selected conflicting feature thereby to complete said service.
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one of said conflicting feature does not take priority, prompting a user to select one of said conflicting features for execution to resolve said conflicting feature interaction and executing the selected conflicting feature thereby to complete said service.
14. The method of claim 13 wherein during said examining step, rules are examined to determine if one of said conflicting features takes priority over other conflicting features.
15. The method of claim 14 wherein said rules are user programmable.
16. The method of claim 15 wherein during said prompting step, said user is prompted either to select one conflicting feature for execution or indicate that the conflicting features are compatible, if said conflicting features are indicated as being compatible, said conflicting features being executed in conjunction.
17. The method of claim 16 further comprising the step of prompting said user to decide if a rule is to be established corresponding to the selected conflicting feature or feature compatibility indication.
18. The method of any one of claim 13 to 17 wherein during said prompting, said conflicting features are presented to said user in a voice message.
19. The method of claim 18 wherein said conflicting features are selectable by dialing digits to generate corresponding DTMF tones.
20. The method of claim 19 wherein said service is the completion of a telephone call from a calling party to a called party and wherein said voice message is presented to said calling party.
21. The method of claim 19 wherein said service is the completion of a telephone call from a calling party to a called party and wherein said voice message is presented to said called party.
22. An adaptive rule-based mechanism to resolve conflicting feature interactions when a plurality of conflicting features can be executed simultaneously in response to an event, said mechanism comprising:
means for determining conflicting features available for execution in response to said event;
means for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
means for selecting the conflicting feature that takes priority for execution, if it exists; and means for prompting a user to make a selection to resolve said conflicting feature interaction if a conflicting feature taking priority does not exist.
means for determining conflicting features available for execution in response to said event;
means for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
means for selecting the conflicting feature that takes priority for execution, if it exists; and means for prompting a user to make a selection to resolve said conflicting feature interaction if a conflicting feature taking priority does not exist.
23. The mechanism as defined in claim 22 wherein said examining means examines rules to determine if one of said conflicting features takes priority over said other conflicting features.
24. The mechanism as defined in claim 23 further including means for adding a rule corresponding to the selection made by said user.
25. In a system where two or more indeterminate features can be executed in response to an event resulting in a conflicting feature interaction, an adaptive rule-based method for resolving said conflicting feature interaction comprising the steps of:
determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, comparing levels assigned to the indeterminate features with the level assigned to a user associated with said event, if the level assigned to at least one of the indeterminate features is above the level of the user, automatically selecting one of the indeterminate features to resolve the conflicting feature interaction; otherwise prompting the user to make a selection to resolve the conflicting feature interaction.
determining indeterminate features available for execution in response to an event;
examining said indeterminate features to determine whether one of said indeterminate features takes priority over other indeterminate features;
if one of said indeterminate features takes priority, selecting said one indeterminate feature for execution; and if one of said indeterminate features does not take priority, comparing levels assigned to the indeterminate features with the level assigned to a user associated with said event, if the level assigned to at least one of the indeterminate features is above the level of the user, automatically selecting one of the indeterminate features to resolve the conflicting feature interaction; otherwise prompting the user to make a selection to resolve the conflicting feature interaction.
26. The method of claim 25 further comprising the step logging a report when an automatic feature selection is made.
27. The method of claim 26 when said indeterminate feature is randomly selected during said automatic selection.
28. In a telephony communication system wherein a telephone call completion service is to be performed in response to a telephone call, said system including a plurality of executable conflicting features representing available options which can be performed to complete said service, an adaptive rule-based method to resolve feature conflicts during performance of said service comprising the steps of prompting a calling party to select one of a number of options;
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over the other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one conflicting feature does not take priority, examining rules associated with a policy governing feature selection to determine if the policy rules remove one or more features from the conflict; prompting a user to make a selection from the remaining conflicting features to resolve said conflicting feature interaction;
and executing the selected feature thereby to complete said service.
determining the conflicting features available for execution;
examining said conflicting features to determine whether one of said conflicting features takes priority over the other conflicting features;
if one of said conflicting features takes priority, executing said one conflicting feature thereby to complete said service; and if one conflicting feature does not take priority, examining rules associated with a policy governing feature selection to determine if the policy rules remove one or more features from the conflict; prompting a user to make a selection from the remaining conflicting features to resolve said conflicting feature interaction;
and executing the selected feature thereby to complete said service.
29. A computer readable medium including computer program code for resolving conflicting feature interactions comprising:
computer program code for determining conflicting features available for execution in response to an event;
computer program code for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
computer program code for selecting said one conflicting feature for execution if one of said conflicting features takes priority; and computer program code for prompting a user to select one of said conflicting features for execution if one of said conflicting features does not take priority thereby to resolve said conflicting feature interaction.
computer program code for determining conflicting features available for execution in response to an event;
computer program code for examining said conflicting features to determine whether one of said conflicting features takes priority over other conflicting features;
computer program code for selecting said one conflicting feature for execution if one of said conflicting features takes priority; and computer program code for prompting a user to select one of said conflicting features for execution if one of said conflicting features does not take priority thereby to resolve said conflicting feature interaction.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9905156A GB2347579B (en) | 1999-03-05 | 1999-03-05 | Adaptive rule-based mechanism and method for feature interaction resolution |
| GB9905156.7 | 1999-03-05 | ||
| GB9919941.6 | 1999-08-23 | ||
| GB9919941A GB2353916B (en) | 1999-08-23 | 1999-08-23 | Adaptive rule-based mechanism and method for feature interaction resolution |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2299639A1 CA2299639A1 (en) | 2000-09-05 |
| CA2299639C true CA2299639C (en) | 2005-11-01 |
Family
ID=26315231
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002299639A Expired - Lifetime CA2299639C (en) | 1999-03-05 | 2000-02-28 | Adaptive rule-based mechanism and method for feature interaction resolution |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6639980B1 (en) |
| CA (1) | CA2299639C (en) |
| DE (1) | DE10010870B4 (en) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7042857B2 (en) | 2002-10-29 | 2006-05-09 | Qualcom, Incorporated | Uplink pilot and signaling transmission in wireless communication systems |
| FR2853790A1 (en) * | 2003-04-14 | 2004-10-15 | France Telecom | Telecommunication system for managing telephonic call, has service control point connected to access switches, where one switch acts as connection switch to release control point during arrival of call at equipment destination |
| US7260205B1 (en) * | 2003-07-21 | 2007-08-21 | Aol Llc | Call waiting using external notification and presence detection |
| JP4435578B2 (en) * | 2004-01-05 | 2010-03-17 | 株式会社リコー | Image processing apparatus, data search method, and data search program |
| EP1787219A4 (en) * | 2004-01-15 | 2009-07-29 | Resonant Software | Adaptive process systems and methods for managing business processes |
| EP1583339A1 (en) * | 2004-03-31 | 2005-10-05 | France Telecom | Method and server for telephone call routing |
| US7804947B2 (en) * | 2004-05-21 | 2010-09-28 | Avaya Inc. | Method and apparatus for validation and error resolution of configuration data in a private branch exchange switch |
| US8891349B2 (en) | 2004-07-23 | 2014-11-18 | Qualcomm Incorporated | Method of optimizing portions of a frame |
| US8831115B2 (en) | 2004-12-22 | 2014-09-09 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
| US7720049B1 (en) | 2005-03-03 | 2010-05-18 | Veraz Networks, Inc. | Semantic service broker for telecommunications networks |
| US10769686B2 (en) | 2008-01-31 | 2020-09-08 | Bill.Com Llc | Enhanced invitation process for electronic billing and payment system |
| US10043201B2 (en) | 2008-01-31 | 2018-08-07 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
| US20100031236A1 (en) * | 2008-07-30 | 2010-02-04 | Telcordia Technologies, Inc. | System and Method to Unify Multiple Service Environments to Optimize the Delivery of Telecommunications Services |
| US20100153695A1 (en) * | 2008-12-16 | 2010-06-17 | Microsoft Corporation | Data handling preferences and policies within security policy assertion language |
| US8917844B2 (en) * | 2009-01-19 | 2014-12-23 | Avaya Inc. | Mid-call detection and resolution of feature interactions |
| US8300558B2 (en) * | 2009-01-19 | 2012-10-30 | Avaya Inc. | Feature interaction detection in multi-party calls and calls with bridged appearances |
| CN102474369B (en) * | 2009-06-29 | 2015-12-02 | 阿瓦雅公司 | Web enable and call out reciprocation between relevant feature and detect |
| WO2011088898A1 (en) | 2010-01-22 | 2011-07-28 | Telefonaktiebolaget L M Ericsson (Publ) | Verification of compatibility among telecommunication network features |
| US8819789B2 (en) | 2012-03-07 | 2014-08-26 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
| US20150012399A1 (en) * | 2013-03-14 | 2015-01-08 | Bill.Com, Inc. | System and Method for Enhanced Access and Control for Modification of Auto-Learned Conflict Resolution and Related Rule and Value Replacements |
| US10115137B2 (en) | 2013-03-14 | 2018-10-30 | Bill.Com, Inc. | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
| US10410191B2 (en) | 2013-03-14 | 2019-09-10 | Bill.Com, Llc | System and method for scanning and processing of payment documentation in an integrated partner platform |
| US10417674B2 (en) | 2013-03-14 | 2019-09-17 | Bill.Com, Llc | System and method for sharing transaction information by object tracking of inter-entity transactions and news streams |
| US9367289B2 (en) | 2013-03-15 | 2016-06-14 | International Business Machines Corporation | Method and apparatus for enabling agile development of services in cloud computing and traditional environments |
| US10572921B2 (en) | 2013-07-03 | 2020-02-25 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
| GB2528479A (en) * | 2014-07-23 | 2016-01-27 | Gamma Telecom Ltd | Session handling in a communications network |
| CA2998129A1 (en) | 2015-09-18 | 2017-03-23 | Sony Corporation | Transmission apparatus, reception apparatus, and data processing method |
| US11232096B2 (en) * | 2018-09-06 | 2022-01-25 | Optumsoft, Inc. | Automatic generation of an efficient rule set implementation |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE2708885A1 (en) * | 1977-02-25 | 1978-08-31 | Heliowatt Werke | Programme-controlled electronic timer clock - operates with output relay for each switching point and semiconductor programme store |
| US4695977A (en) * | 1985-12-23 | 1987-09-22 | American Telephone And Telegraph Company And At&T Bell Laboratories | Control of real-time systems utilizing a nonprocedural language |
| DE4142046C1 (en) * | 1991-12-19 | 1993-05-06 | Siemens Ag, 8000 Muenchen, De | |
| US5337351A (en) * | 1992-02-28 | 1994-08-09 | Nec America, Inc. | Feature interaction arbitrator |
| EP0588101A3 (en) * | 1992-09-14 | 1995-03-08 | Rolm Co | Message storage and retrieval systems employing selective caller processing. |
| US5448631A (en) * | 1992-10-13 | 1995-09-05 | U S West Advanced Technologies, Inc. | Apparatus for handling features in a telephone network |
| US5404396A (en) * | 1993-08-27 | 1995-04-04 | Telefonaktiebolaget Lm Ericsson | Feature interaction manager |
| US5657451A (en) | 1994-01-24 | 1997-08-12 | Telefonaktiebolaget Lm Ericsson | System for determining whether to accept new supplementary services based upon identified types of supplementary service interactions and identified supplementary service interaction criteria |
| EP0667722A1 (en) * | 1994-02-09 | 1995-08-16 | Koninklijke KPN N.V. | Method of detecting service interactions in intelligent networks |
| US5522026A (en) * | 1994-03-18 | 1996-05-28 | The Boeing Company | System for creating a single electronic checklist in response to multiple faults |
| DE4433878C2 (en) * | 1994-09-22 | 1997-03-06 | Siemens Ag | Method and arrangement for handling performance feature interactions in a communication system |
| GB9501716D0 (en) | 1995-01-28 | 1995-03-15 | Plessey Telecomm | Service interactions |
| GB9502182D0 (en) * | 1995-02-03 | 1995-03-22 | Plessey Telecomm | Telecommunications service interactions |
| AU704869B2 (en) * | 1995-03-09 | 1999-05-06 | Nokia Telecommunications Oy | Method of communication and connection control |
| US5717747A (en) * | 1996-05-31 | 1998-02-10 | Lucent Technologies Inc. | Arrangement for facilitating plug-and-play call features |
| JPH11513214A (en) * | 1996-06-26 | 1999-11-09 | ベル コミュニケーションズ リサーチ，インコーポレイテッド | Managing extended function interactions in telecommunication systems such as intelligent networks |
| EP0833526A1 (en) | 1996-09-26 | 1998-04-01 | BRITISH TELECOMMUNICATIONS public limited company | Detecting service interactions in a telecommunications network |
| FI103845B1 (en) * | 1996-11-14 | 1999-09-30 | Nokia Telecommunications Oy | Call setup via intelligent network |
| DE69732132T2 (en) | 1996-11-19 | 2005-12-15 | British Telecommunications Public Ltd. Co. | SERVICE MANAGEMENT SYSTEM FOR APPLICATION IN COMMUNICATION SYSTEMS |
| US6445782B1 (en) * | 1996-11-19 | 2002-09-03 | British Telecommunications Public Limited Company | Service management system for use in communications |
| US5920618A (en) * | 1996-11-29 | 1999-07-06 | Sbc Technology Resources, Inc. | Apparatus and method for managing telephony-based services |
| SE9604601L (en) * | 1996-12-16 | 1998-06-17 | Ericsson Telefon Ab L M | Device, system and method of access to and control of telecommunications |
| JP2001521701A (en) * | 1997-04-18 | 2001-11-06 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | Network integrating computer and telephone |
| GB9725866D0 (en) * | 1997-12-05 | 1998-02-04 | Orange Personal Comm Serv Ltd | Mobile communications |
| US6201860B1 (en) * | 1998-02-18 | 2001-03-13 | Telefonaktiebolaget L M Ericsson (Publ) | Interaction handler for telephone subscriber services |
| US6167126A (en) * | 1998-11-04 | 2000-12-26 | Northern Telecom Limited | Method for flexibly provisioning switching devices and a switching device incorporating the same |
-
2000
- 2000-02-28 CA CA002299639A patent/CA2299639C/en not_active Expired - Lifetime
- 2000-03-03 US US09/518,555 patent/US6639980B1/en not_active Expired - Lifetime
- 2000-03-06 DE DE10010870.9A patent/DE10010870B4/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE10010870B4 (en) | 2015-01-15 |
| US6639980B1 (en) | 2003-10-28 |
| DE10010870A1 (en) | 2000-11-02 |
| CA2299639A1 (en) | 2000-09-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2299639C (en) | Adaptive rule-based mechanism and method for feature interaction resolution | |
| US6411697B1 (en) | System and method for providing customer personalized and modifiable subscriber services | |
| CA2443337C (en) | Interactive conflict resolution for personalized policy-based services | |
| US10127020B2 (en) | Paradigm in multimedia services creation methodology, and new service creation and service execution environments | |
| US6058175A (en) | Method and device for managing services in a telecommunications network | |
| JPH09509023A (en) | Generic service coordination mechanism | |
| US5819046A (en) | System for invoking in computer application associated with second user connected to the computer and subject to any active conditions associated with the second user | |
| JPH09135303A (en) | Interaction of routing function in telephone system | |
| JPH09504145A (en) | How to avoid unwanted interference between services | |
| GB2353916A (en) | Feature interaction arbitration | |
| US5974118A (en) | System for coordinating on-line updates of call flows, functions and voice prompts of a telephony applications | |
| US6570972B2 (en) | Telephony control mechanism | |
| EP1026871B1 (en) | Interactive voice response system with general-purpose blocks | |
| Buhr et al. | Applying Use Case Maps to multi-agent systems: A feature interaction example | |
| GB2347579A (en) | Feature interaction arbitration | |
| US8448159B2 (en) | Method and system for policy enabled programming | |
| EP0940047B1 (en) | A service management system for use in communications | |
| WO2010077131A1 (en) | Expression conflict resolution in communication network tailoring | |
| Bouma et al. | Formalisation of properties for feature interaction detection: Experience in a real-life situation | |
| Chentouf et al. | Service interaction management in SIP user device using Feature Interaction Management Language | |
| CN111147366B (en) | Method, device and system for automatic line switching | |
| Fife | Feature interaction-how it works in telecommunication software | |
| Elammari et al. | Applying use case maps to multi-agent systems: a featureinteraction example | |
| Rizzo et al. | A Negotiating agents model for the provision of flexible telephony services | |
| WO2001076267A1 (en) | System and method for modelling system interactions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20200228 |