Suche Bilder Maps Play YouTube News Gmail Drive Mehr »
Erweiterte Patentsuche | Abbildungen der Seite | Webprotokoll | Anmelden

Patente

  
[merged small][merged small][merged small][merged small][merged small][merged small][merged small][table][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small]
[blocks in formation]
[merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][graphic][merged small][graphic][merged small][merged small][merged small][merged small][merged small][merged small]
[merged small][merged small][merged small][merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small]

1

INTERACTIVE CONFLICT RESOLUTION
FOR PERSONALIZED POLICY-BASED
SERVICES

FIELD OF THE INVENTION 5

The present invention relates in general to Internet telephony and services where enterprises and end-users have the capability of personalizing their features, and more particularly to detection and resolution of conflicts in telephony 10 services and features described using policy-based (scripting) languages such as CPL.

BACKGROUND OF THE INVENTION

15

IP (Internet Protocol) and related new forms of applications are now incorporating a high degree of personalization. In IP telephony, technologies such as CPL (Call Processing Language) are being defined to allow users to specify their own services and features for controlling the handling of 20 calls. Call processing is currently the domain of experts who thoroughly understand the issue of conflicts among features. Multiple features may interact in ways that create indeterminate behavior. If care is not taken, the addition of a new feature may cause errors in the actions of features that had 25 previously worked flawlessly. New features are evaluated extensively in the design process by experts and tested in conjunction with all other features after the design phase in order to prevent undesired interactions from affecting the end user. 30

With the advent of personalized features, the reliance on expert designers is no longer possible since users are now able to design their own features. In particular, users who are ordinarily unfamiliar with the issues of formal logic expect features to be understood and conflicts to be resolved in ways 35 that they find natural. It is common for an executive to tell his/her secretary that no calls should be put through in the afternoon and also to tell him/her that if an important customer named Terry March calls to put him straight through. What happens if Terry March calls in the afternoon? It might 40 not be difficult for an ordinary user to identify the conflict if these were the only two instructions specified. However, if these were but two of many policies and were specified at different times, it might be difficult for a user more concerned with other matters to identify the conflict at first glance. 45

Accordingly, there is a need in the art for a mechanism to allow an ordinary user to test or validate the overall behavior of all policies that he/she has specified so that he/she will understand and approve of all of the interactions among them. Such a mechanism must be sensitive to how a naive user will 50 tend to specify features and the user's expectation that they will be resolved.

This expectation tends to favor more specific polices over less specific ones. This specificity may address time, people or places. Users could, for example, specify a place such as a 55 particular meeting room and expect it to predominate over a more abstract concept such as policies on all meeting rooms. Specific persons may predominate over more abstract groups, and more specific times may predominate over more abstract time descriptions. 60

As discussed above, prior art communication services such as the AIN (Advanced Intelligent Networks), have been created by expert engineers who have relied on two options for detecting and resolving conflicts or undesirable interactions: 1. At design time (offline): When different services (often 65 created independently) are integrated into the system, conflicts and their resolution may be undertaken before the

2

features are made available to the end-user. Techniques such as testing and proofs based on formal models can be applied at the requirements, design, and code level to detect interactions, and service precedence or tighter service integration can be used to solve them. 2. At run time (online): When not all conflicts or undesirable interactions can be eliminated at design time; service providers can rely on run-time mechanisms that monitor the system used by the customer and react dynamically to resolve a problem once detected.

In both of the above cases, the resolution is the same for all users, whatever their preferences, intentions, context, or understanding of the services.

As indicated above, new types of communication/collaboration services and applications are emerging, enabled by recent IP telephony protocols and languages such as SIP (Session Initiation Protocol) and CPL (Call Processing Language) . These services benefit from the availability of various sources of contextual information (e.g. user's location, presence, schedule, relationships, preferences, etc.) to satisfy a wide variety of requirements. Such services are easily tailored to different vertical markets and are adaptable to changing customer needs and expectations. These services are no longer being defined centrally by expert designers, but rather are being defined at the edge of the network, by-end-users who are not trained in the details of feature design.

In the personalization context addressed herein, end-users have the capability of creating their own services through policies, and are able to define their own solutions to resolving conflicts among these policies. Two main situations can be distinguished:

A. Conflicts among policies of a single user: Such conflicts can be detected at design time, when a user inputs policies in the system. Since the system and the user have knowledge of all the policies of this user, there is an opportunity of resolving conflicts interactively. Moreover, different users have the flexibility to resolve conflicting policies in different ways, which is not the case in traditional prior art systems.

B. Conflicts among policies of multiple users: Since there can be a large number of users, each with their own set of policies, the number of potential conflicts rapidly becomes unmanageable. Design time detection with interactive resolution is inadequate because of the sheer number of conflicts to solve (many of which may never occur if two particular users never call each other) and of the need to negotiate a resolution among multiple users. Conflicts of this type must therefore be detected at run time. U.S. Pat. No. 5,920,618 (Fleischer and Plunkett) entitled Apparatus and Method for Managing Telephony-Based Services describes such a mechanism for Advanced Intelligent Networks (AIN), which uses conflict detection rules described in an expert system. U.S. Pat. No. 6,243,697 (Crowther) entitled Detecting Service Interactions in a Telecommunications Network, also for AIN, makes use of an expert system where interaction rules check services' data parameters for detecting interactions. Conflict resolution can be conventional (resolution mechanisms embedded in the system to provide the same resolution for all users), based on fuzzy logic (e.g. Amer, M., Karmouch, A., Gray, T. and Mankovskii, S. Feature Interaction Resolution Using Fuzzy Policies, in Proceedings of the 6th Feature Interactions in Telecommunications and Software Systems, pp. 94-112, Amsterdam, Netherlands, May 2000. IOS Press), or interactive (e.g. while using the service, the user is prompted when a conflict is detected).

« ZurückWeiter »