Browse Prior Art Database

A Method for Smart Invocation of Service Operations Using Forward-Chaining Inference Engine

IP.com Disclosure Number: IPCOM000145741D
Original Publication Date: 2007-Jan-24
Included in the Prior Art Database: 2007-Jan-24
Document File: 8 page(s) / 314K

Publishing Venue

IBM

Abstract

Disclosed is a computer-implemented system for dynamically invoking service operations in a provider environment (e.g., a call center) which allows a user to be guided automatically to his target without going through predetermined structure during the user interaction, wherein execution of a call flow invokes options or choices via reasoning inference engine logic that operates from a set of facts and deduces new facts.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 28% of the total text.

Page 1 of 8

A Method for Smart Invocation of Service Operations Using Forward -Chaining Inference Engine

Our invention solves the problem of intelligently determining when a system should call various service operations via an enterprise service bus (ESB) in a complex call center environment. One defining characteristic of a call flow process is the need for retrieving and analyzing information from the requestor to enable the request handler to navigate a path through a call flow process. In a typical call center, each incoming request requires the collection of a wide variety of often inter-related information. For example, a customer name or ID is often sufficient data for retrieving other associated information such as contact information, serviceable products, or entitlement status. Thus, retrieving one piece of data may often lead to the opportunity for other data to be retrieved as well. An ESB system is a viable means of retrieving such data. However, given the generic nature of modern call flow system, there exists a challenge in determining at runtime which service operations offered via the ESB should be called. This challenge creates the problem addressed by this invention, as lost time and productivity result from exhaustive collection of data. Additionally, often a call flow process itself may pursue irrelevant logical avenues, due to not having knowledge of certain data. For instance, if a customer name can reveal a requestor's product path or entitlement status, branch conditions downstream in the call flow may be satisfied (and the flow of the process diverted) by knowledge of this associated information. This too can result in lost time and productivity as unnecessary paths in call flow are executed to completion.

One known solution is to hardcode the ESB calls in a user-interface (UI) application. The drawbacks of the alternative are as follows: 1) The UI application cannot be reused for another call flow without substantial reprogramming effort; 2) the UI application is difficult to maintain due to its complexity; 3) the presentation layer (UI) gets cluttered with the controller logic; 4) each UI application (e.g., browser based, eclipse based) needs to reimplement the same code; and 5) sometimes a caller may provide more information than might be asked for at a given juncture in a callflow. This information might be required further downstream and need not be ignored early on. Current systems, with service invocations wired in at specific points, are not able to handle the extra but useful information and tend to ignore that.

Another known solution is to make a UI application leverage the Custom Call Flow (CCF) framework and hardcode the conditions of service operation invocation in the flowchart of the call flow. Although this solution simplifies the UI application, it shifts the complexity to the call...