CHANNELS

FIELD OF THE INVENTION

The present invention is enclosed in the technical computer science area, in particularly applying the graph theory, through the use of a directed graph ( digraph) in the definition of workflow models .

The present invention results from the necessity to model any type of j ourney - a j ourney can be characteri zed by a workflow model where it ' s described how the user will perform certain operations by using sequences of user interactions across multiple channels and requesting the execution of tasks - through a given set of channels , being this invention for this reason enclosed also to the Communication Platforms area .

PRIOR ART

The new trend on digital signal processors ( DSPs ) is to of fer a multiple channel uni fied engagement experience , following a multichannel integration approach, allowing users to interact with a seamless and ef fortless , high-quality experiences , that occur within and between contact channels . Users have the ability to choose the channels they prefer to engage and can start an engagement in one channel and end it in another channel . The best user experience could be reached with a personali zed engagement where the user could perform personali zed interactions across and within every channel .

The management o f these j ourneys , in order to be flexible and able to be personali zed to the user, requires the use of workflow engines where is possible to change in runtime the interactions sequences to be followed or which tasks and how they would be executed . Although there are several commercial workflow management systems available in the market today, they are not suited to use in low code solutions because their tools and the workflow management systems are hard to use , expensive , are not easily integrated and the vast maj ority don ' t support workflow changes in runtime .

The workflow management systems can be characteri zed by the wide range of unique features and capabilities of modelling languages , conj ugated with the lack of appropriate standards , di f ferent concepts and paradigms and high cost , explains why choose a workflow management system for low code environments is sometimes a very di f ficult task .

On the other hand, to automate j ourneys (workflow models for managing user interactions and tasks execution) there is often the necessity to speci fy process steps using functionalities available in the workflow management system, reason why business process modeling languages are strongly associated to its workflow management system . The modelling of a workflow model can be performed by the definition of activities ( represented by the nodes of a directed graph) and transitions ( represented by the edges of a directed graph) , in another words , a workflow model is composed of a number of tasks that are connected thus being able the workflow model be represented by a directed graph .

The directed graph has numerous scienti fic and computational applications , from biology ( evolution, family trees , epidemiology) , sociology ( citation networks) , business (process definition) to computation (scheduling) .

In computation science the greatest applicability has been focused on the execution of procedural pipelines, where typically each node or vertex is executed without having great interdependencies.

PROBLEM TO BE SOLVED

The state of art in the business process modeling has problems like the lack of commonly accepted conceptual formal foundations, several proposed standards, lack of support for processes that need to change on-the-fly and proper support for exceptions and finally the tools and workflow management systems are typically hard to use, expensive, not easily integrated and don't support workflow changes in runtime.

The challenge that the present invention tries to solve is related to the modeling any kind of personalized user journey in multiple channels, in which by the very nature of user interactions and how the tasks will be executed requires the use of adaptive workflow models in runtime.

The problem that need to be answered can be characterized by the follow questions that the invention tries to address: 1) how to model any kind of user journey (workflow model) ?, 2) how to support a personalized workflow model, 3) how to ensure that exist separation between the channels heterogeneity and respective protocols from the execution of the journey / desired model?, 4) how to ensure that a workflow model itself can run in asynchronous way?.

However, within existent state of the art, it would not be possible to respond to the problem described previously without changes. The present invention aims to overcome such issues by developing an approach based on digraphs to use adaptive workflow models in runtime.

SUMMARY OF THE INVENTION

The present invention provides a method to model the user's journey personalized behavior, with user interactions that may use different channels in a user engagement context, where modeling the journey behavior define all the information necessary to describe its behavior and allow a workflow engine to be able to correctly execute the journey.

It is proposed a method based on two parts with the purpose to create a journey data model, which represents a data structure to be used to define the user's journey personalized behavior in the low code workflow engine.

The first part of the method developed is related with the way the user's journey behavior can be described using patterns that represents generic workflow constructs used in the control-flow perspective of workflow engines. The second part of the method developed is related with the creation of a journey data model, which represents the data structure used to define the user's journey personalized behavior in the low code workflow engine.

DESCRIPTION OF FIGURES

Figure 1 - Workflow Engine Reference Model, wherein the reference signs represent:

100 - Workflow engine;

101 - Journey (Workflow model) instance; 102 - Task;

103 - Channel;

104 - Work Item;

105 - Application;

106 - Journey data model instance;

107 - Work Item invocation;

108 - Journey configuration upload.

Figure 2 - Task reference model, wherein the reference signs represent:

200 - Task;

201 - Task properties;

202 - Incoming control;

203 - Incoming transition;

204 - Outgoing control;

205 - Outgoing transition;

206 - Recursive control;

207 - Trigger control;

208 - Trigger.

Figure 3 - Illustration of the Journey Data Model with the different information elements.

Figure 4 - Example of a journey for a IVR menu.

DETAILED DESCRIPTION

The present invention provides a method to model the user's journey personalized behavior, with user interactions that may use different channels in a user engagement context, where modeling the journey behavior define all the information necessary to describe its behavior and allow a workflow engine to be able to correctly execute the journey. It is proposed a method based on two parts with the purpose to create a j ourney data model , which represents a data structure to be used to define the user ' s j ourney personali zed behavior in the low code workflow engine .

Part 1 :

The first part of the method developed is related with the way the user ' s j ourney behavior can be described using patterns that represents generic workflow constructs used in the control-flow perspective of workflow engines .

It was applied a patterns-based approach, as defined in the Workflow Patterns Initiative , to identi fy the workflow patterns available by the low code workflow engine in order to execute the di f ferent types of user j ourneys on channels .

These workflow patterns are used to provide a holistic description of a personali zed user j ourney in the issues of task coordination and control- flow of user interactions .

Thus , it was established the premise to identi fy the minimal set of workflow patterns eligible to model any known type of personali zed user j ourneys . This workflow patterns minimal set , defines the workflow engine functional scope available and that requires workflow models to define the j ourney behavior which is controlled from the workflow engine .

The minimal set of workflow patterns belongs to the area of the Control Flow Patterns as defined in the Workflow Patterns Initiative . Control Flow patterns are used to describe the set of activities that composes a business process and the way in which the thread of execution is routed between them . This encompasses the descriptions of the activities and how they are available and the description how execution is routed between these activities .

The list of the eligible workflow patterns to be implemented by the low code workflow management is the following :

• Parallel Split

• Exclusive choice

• Synchroni zation

• Simple merge

• Structured loop

• Recursion

• Sequence

• Persistent Trigger

• Cancel case

Implicit termination

Part 2 :

The second part o f the method developed is related with the creation of a j ourney data model , which represents the data structure used to define the user ' s j ourney personali zed behavior in the low code workflow engine .

For the scenarios where we intend to use a workflow engine to control a personali zed user j ourney, we can assume that user interactions performed on any speci fic channel can be managed by the workflow engine as channel services which are invoked by the workflow engine . Therefore , user interactions can be considered as tasks ( interaction tasks ) and user interactions sequences as tasks sequences . The assumption that user interactions are interaction tasks managed by the workflow engine is the solution to overcome the asynchronous nature and human dependency of user interactions and be able to incorporate them in automated workflows. Another possibility to overcome this problem is supporting of the Persistent Trigger pattern but can present some challenges to model scenarios with parallel branches.

For the scenarios of managing customer engagement activities on channels, one can compare a sequence of activities in a journey with a relay race: an activity corresponds to a leg run; a resource is equivalent to a runner; and the thread of control is the baton. Thus, it can be defined, at the highest level of abstraction, that a journey is a mesh of interconnected activities where the completion of an activity, belonging to a sequence of activities in the journey, allows the start of the next activity in the sequence, by transferring the thread of control to the next task.

It was defined a Workflow Engine Reference Model, as represented in Figure 1, and based in the Workflow Reference Model from the WFM Coalition, to define a top level architecture for the workflow engine in order to identify the main characteristics, major functional components and interfaces used to support interoperability with other systems.

From the Workflow Engine Reference Model, represented in Figure 1, a journey (101) can be defined as a task-based workflow model that consists of a collection of tasks (102) that are related to each other by its execution sequence and respective constraints, where the workflow engine (100) will invoke (107) work items (104) on channels (103) or applications (105) , through the associated tasks (102) , being the execution of the work items (104) guided by the journey instance (101) information which is collected by the upload (108) of the corresponding journey data model (106) configuration. One can also define a personalized journey (101) as a default workflow model which incorporates numerous variations that adapt to individual customers and also over which in runtime the workflow engine is able to perform dynamic alterations to change the original behavior according to the intended personalization.

The journey workflow model (101) is centered on a description of the control-flow aspects of the user journey which can be represented in the form of a directed graph (digraph) , in which the tasks (102) are nodes, which describe the individual work activities that comprise the journey, are connected by directed arcs indicating the various execution paths available in the user journey. Thus, a digraph can be the foundation for the workflow model of a journey to describe the behavior of the user journey.

The digraph representation is also able to attend the requirements to support personalized user journeys because is easy to incorporate numerous variations that adapt to individual users: 1) through the addition/removing of arcs, changes in condition rules and properties of the tasks; 2) through the addition/removing nodes.

Based on the digraph representation and the Workflow Engine Reference Model interoperability characteristics it can be defined that the main entity of a journey generic workflow model is a task as represented in Figure 2. A task (200) is an abstraction of an activity that contains the following elements: task properties (201) , to characterize how and where the task is executed; incoming control (202) , to merge multiple branches, with incoming transitions (203) , into a single branch; outgoing control (204) , to split a single branch, with outgoing transitions (205) , into multiple branches; recursive control (206) , to a task repeats its last invocation; and trigger control (207) to process triggers (208) in the task.

The journey data model is a formal data structure that will be used to define a journey behavior according to the workflow management capabilities provided by the workflow engine. The journey data model, is represented in Figure 3 and is composed of two main entities types: the journey entity and the task entity.

The journey entity defines the elements that make up a user journey:

• input parameters - list of parameters that may be passed in the journey's instantiation on the workflow engine;

• journey parameters - list of parameters that characterizes the journey type and may be used by tasks or to control journey execution like the journey validity to use it and the maximum duration to complete the journey;

• tasks - list of the tasks that composes the j ourney ;

The task entity defines the elements used to implement a journey's behavior:

• identifier - task identifier;

• task flow - define the role for the sequence flow;

• task mode - define the task execution mode;

• task timeout - define the time limit for the task completion; resource identi fy who perform the task activity;

• recursive behavior- define the behavior for a task that has recursion ;

• trigger - identi fy the trigger to start task execution

• incoming control - define the behavior to synchronize the thread of control for the incoming transitions

• outgoing control - define the behavior to route the thread of control for the outgoing transitions .

The task flow element is used to define the task role on the j ourney tasks sequential flow execution :

• START - the j ourney is initiated with this task;

• REGULAR - some activity is performed in the j ourney by this task;

• END - the j ourney is terminated after the completion of this task .

The task mode element is used define the task type and therefore the mode as the task executes :

• NORMAL - the task executes normally;

• ROUTE - the task does not perform any activity, is only use for routing flow purpose ;

• TRIGGER - when the task receives the thread of control it will wait for a trigger to execute . The task timeout element ( ) is used to limit the time waiting for a task completion and has the following information :

• loop condition - used to evaluate i f the loop continues ;

• timeout to task - identi fier of the timeout next task .

The resource element ( ) is used to identi fy who will perform the task work and has the following information :

• resource access - used to access the resource ;

• resource type - used to typi fy the resource ( ex : channelweb, application, etc ) ;

• resource invocation attributes - used to speci fy the attributes passed during the invocation of the task work in the resource ) ;

• resource return attributes - used to speci fy the attributes passed in the return of the task completion in the resource .

The l oop element is used to control a task execution sequence and has the following information :

• loop condition - used to evaluate i f the loop continues ;

• loop iterations - used to limit number of loop iterations ;

• loop time exceeded - used to limit the loop duration . Evaluated after task completion;

• loop to task - identi fier of the loop next task . The Recursi ve Control element is used to implement the recursion behavior in the task and has the following information :

• recursion condition - used to evaluate i f the recursion continues ;

• recursion iterations - used to limit number of loop iterations ;

• recursion time exceeded - used to limit the loop duration . Evaluated after task completion .

The Trigger Control element is used to identi fy the trigger content and the task behavior, and has the following information :

• start j ourney - indicates that this trigger starts the j ourney;

• trigger message - used to speci fy the trigger' s message and attributes ;

• trigger condition - defines the condition to activate the task .

The Incoming Control element is used to define the behavior on incoming transitions and has the fol lowing information :

• control type - indicates the type of synchroni zation; o SEQUENCE - a single incoming transition with immediate task execution; o AND - merge all incoming transitions to synchroni ze all ; o XOR - merge of all incoming transitions to synchroni ze j ust one transition; • list incoming transitions - origin task identi fier used to define the incoming transitions .

The Outgoing Control element is used to define the routing behavior on outgoing transitions and has the following information :

• control type - indicates the type of synchronization; o SEQUENCE - a single outgoing transition with immediate trans fer of the thread of control ; o AND - split all outgoing transitions to paralleli ze all ; o XOR - split all outgoing transitions to trans fer the thread of control to j ust one of the outgoing transition;

• outgoing data - speci fies the information used to be evaluated in the outgoing transitions , the information can be j ourney input parameters , j ourney parameters , resource return attributes or a mixed of all ;

• list outgoing transitions - destination task identi fier used to define the outgoing transitions ; o transition condition - only applicable in the XOR control type , defines the condition to be matched for this transition be selected; o Loop - to speci fy the loop behavior when exists . Therefore, it is proposed a method to model any type of journey over a given set of channels using a methodology based on workflow models which includes the following steps: i. capture the journey information according three perspectives :

• control-flow - which identifies the journey activities and how its execution is routed between these activities;

• data - captures the information that is required on the activities during the execution of a journey;

• resources - identifies the channels and applications that carry out the journey and their interfaces; ii. characterize the journey activities execution routing in terms of the workflow patterns supported by the workflow engine; iii. model the journey behavior according to the journey data model representation; iv. define the entire journey by filling the journey data model information structure.

In order to illustrate how to apply the journey data model, let's consider that it is intended to model an IVR menu (this will be our journey) that is partially illustrated in Figure 4.

First step. It is used a IVR channel as one the journey's resources which provide several services (ACCEPT_CALL, PLAYANNOUNCEMENT J1OMPOS I TE, IVR_MENU) that can be invoked to control voice calls and can send signals (INCOMING CALL - event signaling reporting a new call, CALL_D IS CONNECT - event signaling reporting the end of the call) to report specific conditions about the voice call. The IVR channel when receive the indication of a new call will request the creation of a new journey with the objective to perform some initial validations and when the signal INCOMING CALL arrives it must be performed an acceptance to the call (invocation of ACCEPT CALL service) , after the service confirms the call establishment (ACCEPT_CALL_COMPLETED) it is requested to play an announcement (invocation of PLAYANNOUNCEMENTjCOMPOSITE service) . After the confirmation the announcement playing is complete it is requested to play the first level of the IVR menu (invocation of IVR_MENU service) and when the service IVR_MENU returns the digit pressed

( IVR_MENU_COMPLETED& & 1 ) it will be requested to play branch "1" at level 2 of the IVR menu (invocation of IVR_MENU service) and so on. It is considered that when is received the signal CALL_D IS CONNECT the journey must send a SMS.

Second step. It was not identified loops or recursions but it was identified the INCOMING_CALL as trigger for the initial activity and the CALL_D IS CONNECT as a trigger to terminate the journey.

Third step. It was identified the use of the workflow patterns: sequence, persistent trigger and exclusive choice.

Fourth step. It should be used the following tasks to model the behavior:

• a starting task as a routing task with a sequence transition;

• a task, that is triggered by the

INCOMING_CALL, to perform the call acceptance with a sequence transition; • a task to play the announcement with a sequence transition;

• a task to play the IVR menu with exclusive choice transitions , the transition is selected based on the return digit pressed in the IVR menu;

• a task, that is triggered by the CALL_DISCONNECT , to send a SMS with a sequence transition .

Fi fth step . Configuration of the tasks previously identi fied :

• configuration of a task 1 : as a starting and routing task; create a sequence outgoing control element with a single outgoing transition addressing task 2 ;

• configuration of task 2 : as regular and trigger task; create a trigger element to receive events from the IVR channel that triggers the task by matching INCOMING_CALL ; create a resource element to perform the call acceptance in the IVR channel ; create a sequence incoming control element with a single incoming transition addressing task 1 ; create a sequence outgoing control element with a s ingle outgoing transition addressing task 3 ;

• configuration of task 3 : as regular and normal task; create a resource element to play an announcement in the IVR channel ; create a sequence incoming control element with a single incoming transition addressing task 2 ; create a sequence outgoing control element with a single outgoing transition addressing task 4 ;

• configuration of task 4 : as regular and normal task; create a resource element to play a IVR menu in the IVR channel ; create a sequence incoming control element with a single incoming transition addressing task 3 ; create a XOR outgoing control element , that uses information returned in the execution IVR menu, with outgoing transitions that contains a match condition and the identi fier for the next task;

• configuration of task 5 : as regular and trigger task; create a trigger element to receive events from the IVR channel that triggers the task by matching INCOMING_CALL ; create a resource element to perform the send a SMS in the SMS channel ; create a sequence outgoing control element with a single outgoing transition addressing task x ;

DESCRIPTION OF THE EMBODIMENTS

In the following an embodiment of the present invention being related to a method to model any type of j ourney over a given set of channels using a methodology based on workflow models will be described . Said method is comprised of the following steps :

1 . collect the j ourney information, identi fy the j ourney activities and how its execution is routed among them, retrieve the information required for those activities and identi fy the resources (channels and/or applications) used and their interfaces; identify the existence of loops, activities recursions or triggers that condition a straightforward execution sequence; identification of the various workflow patterns, existing in the journey, as supported by the workflow engine; model the journey behavior according to the journey data model representation, in particular, identification of all the tasks required and their main characteristics; define the entire journey properties by filling the journey data model information structure: a. in Trigger type tasks is required to fill the Triger Control element to define the trigger behavior; b. in tasks with recursive behavior is required to fill the Recursive Control element to define the recursion behavior; c. in tasks that invokes work items execution is required to fill the Resource element to define how to invoke the execution in the resource; d. it is necessary to fill the Incoming Control element to define the task behavior regarding incoming transitions, in particular for the cases that require synchronization of the thread of control; e. it is necessary to fill the Outgoing Control element to define the task behavior regarding outgoing transitions, in particular for the cases that require paralleli ze or routing the thread of control among a list of outgoing transitions . To route the thread of control is necessary to define the source of the data that will be use in the match condition used to select the outgoing transition; f . in the scenarios where exist loops is necessary to add a filled Loop element in the outgoing transitions that will trans fer the thread of control to tasks that run previously .