Branch Prediction of User Interface in the Workflow

Abstract

Describes systems, methods, and other embodiments associated with branch prediction in a workflow. In one embodiment, a method includes inputting a workflow and proceeding serially in the workflow in a sequence of flow, and in response to the sequence of flow encountering a first decision element in the workflow that includes multiple branch paths: (i) performing a prediction: the prediction predicts a result path of the first decision element to predict a first user interface that may subsequently be encountered as part of a first terminal element in the sequence of flow from among multiple user interfaces; and (ii) pre-building the predicted first user interface before encountering the first terminal element. In response to the sequence of flow reaching the first terminal element, the pre-built first user interface is displayed on a display device.

Description

BACKGROUND OF THE INVENTION

[0001] A workflow is a computerized structure that defines a series of actions to be performed and completed in sequence. Generally, a workflow can be created to correspond to a specific process or task. A workflow can be visually represented as a flowchart or a tree structure that includes multiple branches of possible paths that can be traversed during execution until an end point is reached. A workflow includes decision elements that control the execution of the workflow and control which branch paths are taken. Eventually, the execution path lands on one of many possible workspace elements that initiate or perform an action.

[0002] A user-defined workflow can be arbitrarily complex. The more elements a workflow has, the more complex it is and the more time the workflow takes to complete. The user and the computing device performing the workflow need more time to sequentially traverse the workflow from a starting point to one of multiple end points and perform the programmed actions of the workspace elements.

[0003] In existing systems, the execution and run time of a workflow are limited by decision elements and serial execution along a path. Before any decision can be made, a decision element needs to wait for input data and then continue along the path to the next action element. For example, a decision element can be based on a specific field value on a given data record. Thus, the data record must be retrieved via a network request before the field value can be determined. Based on the result of the decision, the system will generate one or more different user interfaces.

[0004] Accordingly, any element in the path after a decision element cannot be executed until that decision element is executed and serial processing along the path reaches that element. This results in a degradation of the performance of the system as well as the client waiting for the system because a view model or view cannot be constructed until data is retrieved from the data center. In many high-volume environments, such as call centers, the processing of workflows and the subsequent display of recorded values are time-critical. Thus, any reduction in processing time is an improvement to the computer's functionality. SUMMARY OF THE INVENTION

[0005] In one embodiment, a non-transitory computer-readable medium is disclosed that includes computer-executable instructions stored thereon that, when executed by at least one processor of a computer, cause the computer to:

[0006] At least a processor inputs a workflow into a memory and proceeds serially in the workflow in a flow sequence; wherein the workflow is configured with a plurality of execution paths, including a plurality of decision elements for controlling access to different parts of the execution paths, and wherein the plurality of execution paths lead to a plurality of terminal elements associated with a plurality of user interfaces; in response to the flow sequence encountering a first decision element in a workflow including a plurality of branch paths: (i) perform a prediction that predicts the result path of the first decision element to predict a first user interface that may subsequently be encountered as part of a first terminal element in the flow sequence from the plurality of user interfaces; (ii) pre-build the predicted first user interface before encountering the first terminal element;

[0007] In response to the flow sequence reaching the first terminal element, display the pre-built first user interface on a display device; and

[0008] In response to the flow sequence reaching a second terminal element, discard the pre-built first user interface and generate a second user interface associated with the second terminal element.

[0009] In another embodiment, a computing system is disclosed, comprising: at least one processor; at least one memory operably connected to the at least one processor; and a non-transitory computer-readable medium having instructions stored thereon, the instructions causing the processor, when executed by the at least one processor, to:

[0010] At least a processor inputs a workflow into a memory and proceeds serially in the workflow in a flow sequence; wherein the workflow is configured with a plurality of execution paths, including a plurality of decision elements for controlling access to different parts of the execution paths, and wherein the plurality of execution paths lead to a plurality of terminal elements associated with a plurality of user interfaces; in response to the flow sequence encountering a first decision element in a workflow including a plurality of branch paths: (i) perform a prediction that predicts the result path of the first decision element to predict a first user interface that may subsequently be encountered as part of a first terminal element in the flow sequence from the plurality of user interfaces; (ii) pre-build the predicted first user interface before encountering the first terminal element; (ii) pre-build the predicted first user interface before encountering the first terminal element;

[0011] In response to the first decision element outputting a first result path leading to the predicted first user interface, display the pre-built first user interface on a display device; and in response to the first decision element outputting a second result path not associated with the predicted first user interface, discard the pre-built first user interface and generate a second user interface associated with the second result path.

[0012] In another embodiment, a computer-implemented method is disclosed, which is executed by a computing device and a processor that executes instructions in a memory, where the method performs one or more combinations of functions performed by a computing system. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be appreciated that the element boundaries illustrated in the figures (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of the boundaries. In some embodiments, one element may be implemented as multiple elements, or multiple elements may be implemented as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, and vice versa. Additionally, the elements may not be drawn to scale.

[0014] Figure 1 An embodiment of a computer system associated with branches of a prediction workflow and a pre-built user interface is illustrated.

[0015] Figure 2 An embodiment of a workflow including a decision element configured with branch prediction is illustrated.

[0016] Figure 3 An embodiment of a method associated with branches of a prediction workflow and a pre-built user interface is illustrated.

[0017] Figure 4 An embodiment of a computing system configured with the disclosed example prediction system and / or method is illustrated. DETAILED DESCRIPTION

[0018] Computer systems and methods are described herein that are configured to perform branch prediction in an executing workflow and predict a resulting user interface from multiple possible user interfaces. The user interface is then pre-built before the executing workflow reaches the predicted user interface. The present systems and methods provide faster response times and avoid time delays associated with a serial execution workflow that serially depends on and is limited by decision elements. These decision elements require retrieving and loading data records to determine the result of the decision element, after which serial / sequential processing along the workflow path proceeds to render the end-user interface.

[0019] In one embodiment, the present system and method eliminate the serial dependency between data loading and the rendering of a customized user interface, thus improving computer functionality relative to the prior art by predicting and pre-building the user interface in advance. Additionally, compared to serial dependency processing, the prediction and pre-building functionality reduces processing time and further improves computer functionality. As previously mentioned, in many high-volume environments such as call centers, generating and displaying record values in a user interface by a computing system is time-critical. Therefore, a reduction in processing time (even by a few milliseconds) is an improvement to computer functionality.

[0020] It should be understood that any action or function described or claimed herein is not performed by a human brain and cannot be actually performed in a human brain. An interpretation that any action or function can be performed in a human brain is inconsistent with and contrary to this disclosure.

[0021] Reference Figure 1 , FIG. illustrates an embodiment of a computing device 100 configured with a prediction system for branch prediction in a workflow to predict and pre-build a user interface. The computing device 100 includes at least one processor 110, a memory 120, and a network interface for communicating with remote devices such as a data center database 130 and / or other remote computers (not shown). The prediction system includes a branch predictor 140 that executes on a workflow structure 150 input into the memory. As will be described herein, the branch predictor 140 eliminates the serial dependency between data loading and user interface rendering by leveraging historical data (e.g., decision element history 170) from the previous paths taken at each decision element. The prediction system is configured to learn and then predict the appropriate user interface that may be rendered. The system then begins to pre-build the user interface (e.g., pre-built UI 160) to reduce processing time.

[0022] In software systems with highly complex and configurable logic, different user interfaces are generated and rendered based on complex data models. These data models are retrieved from a data center to generate the associated user interfaces. In one embodiment, the present system and method predict the user interface that will be displayed before retrieving the data model. Thus, once the workflow reaches the point where the user interface is to be displayed and rendered on the display, the present system can display the user interface much more quickly. Prior art did not have a prediction function but simply executed serially and sequentially according to the workflow until the operation terminated at one of the possible user interface elements.

[0023] Reference will be made Figure 2 to the example workflow 200 shown in Figure 3 and the example method 300 shown in Figure 1An example of the operation of a prediction system. Initially, workflow 200 is described below using a set of example elements and how to perform the serial operations of the workflow. Following this example is a method 300 that describes how current branch prediction is implemented into workflow 200 to predict and pre-build the user interface.

[0024] Reference Figure 2 , workflow 200 is configured with multiple decision elements and possible operations, which create the workflow structure. Generally, a workflow such as workflow 200 can be configured to have multiple decision elements (e.g., decision elements 205, 210, and 240) that create multiple paths along the workflow. The workflow can have multiple possible user interfaces (UIs) that can be triggered at the end of one or more paths. The workspace elements at the end of a path are called terminal elements.

[0025] In one example, the computer-implemented workflow 200 is defined to process data records of customer contacts in a call center. An operator handling calls in the call center will execute and navigate the computer-implemented workflow 200. As an overview, the workflow can take multiple paths, each with a series of elements and actions along the path. The various directions of the workflow paths are controlled by decision elements 205, 210, 220, and 240 along the path. Each decision element 205, 210, 220, and 240 includes logic configured to determine a result based on one or more values from the input data.

[0026] For example, decision element 205 is configured to determine whether "last name = Smith". This decision is determined by the operator's action, which will initiate a network request to retrieve the data record from the database. In the call center example, the operator is working with a customer, so a network request is issued to retrieve the data record associated with the customer involved in the workflow. When the data record is retrieved and the data record values are loaded into memory, decision element 205 can then determine whether the "last name" field in the data record is equal to "Smith". The result of the determination will direct the execution flow along the "yes" branch or the "no" branch to the output branch.

[0027] In Figure 2 the example, the output result from decision element 205 can be one of two paths based on whether the decision is "yes" or "no", and leads to decision element 210 or decision element 240, which are the next workflow elements in sequence along the path. Of course, a decision element can have more possible outputs based on the decision conditions and the input values tested at that decision element.

[0028] At some point along the workflow, the operator will navigate along a sequential path and will end up at a terminal element. The terminal element is configured to trigger a user interface as defined by the terminal element. The user interface is associated with what the operator is working on as defined by the navigation sequence in the path leading to the workflow element. In workflow 200, the terminal elements are elements 215, 230, 235, 245, and 250. In this example, the terminal elements are associated with specific customer contacts and have a user interface (UI) based on the corresponding customer contacts. Once the workflow reaches a terminal element, the system knows who the customer is and has retrieved the corresponding data record for that customer. Then a customized user interface is generated and constructed using the record values for that customer. Of course, the present system is not limited to workflows for customer contacts but can be implemented to generate any type of user interface based on any criteria defined by an administrator.

[0029] Referring again to decision element 205, if the decision determines that the data record does in fact include a last name equal to "Smith", then the next decision element 210 determines whether "First Name = Pat". This decision is made by comparing the value in the "First Name" field of the previously retrieved data record. If the first name is "Pat" (the decision is "yes"), then the process proceeds to workspace element 215, which is a terminal element and triggers the user interface (UI) for the workspace contact for Pat Smith.

[0030] In the sequential execution of the workflow, when the operator reaches the end point in the sequence of serial workflow operations, the system generates the corresponding UI. Thus, workflow 200 has a serial dependency between the decision elements (which retrieve and load data to decide which path to take) and the final rendering of the user interface. In addition to waiting for the serial dependency to execute, generating the UI takes additional time because generating the UI is slow relative to the other actions and functions in the workflow. Examples of times are provided below.

[0031] As previously mentioned, the decision elements 205, 210, 220, and 240 in the workflow need to wait for input data before they can make any decision to continue to the next action element along one of their output branches. Thus, in an existing system, any element in the path after the decision element (including the terminal element that generates the UI) cannot be executed until the decision element has been executed and the serial processing along the path has reached the terminal element. Not only is the system response time delayed due to waiting for each network request for the decision element to complete, but generating the final UI is also time-intensive relative to the other actions, adding even more serial processing time.

[0032] Reference Figure 3 shows that by Figure 1An embodiment of a computer - implemented method 300 performed by a branch predictor 140. The method 300 is configured to perform branch prediction at decision elements and pre - construct a user interface (UI). Thus, the method can predict the final UI in advance without waiting for the serial execution of the workflow. When a prediction is made, the method and system start constructing the UI without waiting for the decision elements to complete their processing and without waiting for the operator to complete a series of workflow actions.

[0033] In one embodiment, when initiating a workflow such as Figure 2 workflow 200, the method 300 is initiated and executed to perform branch prediction. At block 310, at least one or more parts of the workflow structure are input into the memory by a processor. In response to user input / action, the processor can proceed serially and navigate through the workflow in a sequence of steps.

[0034] As previously mentioned, the workflow 200 is configured with multiple execution paths, which include multiple decision elements for controlling access to different parts of the execution paths. The multiple execution paths lead to multiple terminal elements associated with multiple user interfaces.

[0035] At block 320, the method and system monitor the workflow to determine when a decision element is encountered in the sequence of steps. For example, in the Figure 2 workflow 200, the first decision element encountered is element 205, which includes multiple branch paths. In response to the sequence of steps encountering the first decision element in the workflow, at block 330, the processor (i) performs a prediction that predicts the result path of the first decision element to predict, from among multiple user interfaces, the first user interface that may be encountered subsequently as part of the first terminal element in the sequence of steps, and at block 340, (ii) pre - constructs the predicted first user interface before encountering the first terminal element. Other details of the prediction and pre - construction functions are provided below.

[0036] For the purpose of discussion, assume that the prediction predicts that the decision element 205 will result in a "yes" branch and the workflow will lead to Figure 2The contact person "Pat Smith" in the middle terminal element 215. In one embodiment, the prediction is (at least partially) based on the previous historical results of the decision element. This will be further described below. The system also pre-builds / generates a user interface associated with the predicted Pat Smith contact. Thus, when the decision element 205 executes its logic to determine whether "surname = Smith" as described above, the prediction and pre-building are executed concurrently and / or in parallel with the decision element logic. Thereby, the serial dependency of the prior art for processing the decision element and rendering the user interface is removed, which improves the computer function by improving the workflow processing time. The decision element logic includes requesting and retrieving database records based on a network request to the database, and determining whether the "surname" field of the retrieved database record has "Smith" or does not have "Smith".

[0037] In one embodiment, when the system predicts the user interface (UI) and starts to build the UI, the UI is not displayed or shown to the user. The predicted UI is built in the memory and queued in a background process. The system cannot start to display the pre-built predicted UI because the predicted UI may ultimately be the wrong UI (e.g., the workflow ultimately appears on a different terminal element with a different UI). The system cannot display the wrong UI on the display screen because this would be handling an error and confusing the user. If the UI is correct, then the information from the corresponding data record is filled into the UI and the UI is displayed.

[0038] Continuing to refer to Figure 3 method 300 in, at block 350, the system determines whether the prediction is correct. This can be determined, for example, by determining which terminal element the workflow sequence ultimately reaches. In response to the workflow sequence reaching the predicted terminal element of the Pat Smith contact 215, the prediction is determined to be correct and the pre-built user interface is displayed and rendered on the display device.

[0039] In the example workflow 200, it is noted that along the "yes" path where surname = Smith, there is a second decision element 210 for "first name = Pat". Any number of decision elements may be encountered in the workflow path. In one embodiment, branch prediction is performed again for the second decision element, which may result in the same prediction or a different prediction.

[0040] Returning to Figure 3In decision box 350, if the flow sequence does not take the predicted path and reaches a different terminal element that was not predicted, then the prediction is incorrect. Method 300 then moves to block 370, where in response to the flow sequence reaching a different terminal element, the processor discards the pre-built predicted user interface. The system then generates a new user interface associated with the terminal element that the workflow actually reaches. For example, in Figure 2 if the terminal element that is actually reached is the JohnSmith contact element 230, then the predicted user interface for the Pat Smith contact is discarded. A user interface associated with the John Smith contact is then generated and rendered on the display screen.

[0041] Building the user interface is one of the more time-consuming operations in the system (e.g., taking approximately 300 ms to 500 ms). Thus, if the prediction is correct, then the final UI has been built (or is nearly built) and is ready to be presented and used when the operator reaches that endpoint in the workflow sequence. This reduces the amount of processing time required by the system compared to serial processing of the workflow. An example time comparison is described below.

[0042] In another embodiment of method 300, the method can predict branch paths and associated actions with one or more data records. For example, the predicted action can create, delete, or otherwise modify data from the predicted data record before the workflow reaches the terminal element. In this case, the user interface is not part of the terminal element, but rather an action is performed on the predicted data record. For example, if the predictor predicts a certain branch at a decision element that leads to a terminal element with a record modification action, then the system pre-executes the record modification action (as described above) in parallel with the processing of the decision element. Pre-execution can include accessing a database to retrieve the associated data record and performing a data modification on the data record. If the prediction is incorrect and the workflow ends at a different terminal element, then the data modification is ignored and not saved in the database. If the prediction is correct, then the modified record is saved and updated in the database.

[0043] Game Predictor

[0044] In one embodiment, Figure 1 the branch predictor 140 and the associated prediction function ( Figure 3 block 330 in

[0045] As previously described, when the workflow reaches a decision element / node, the system triggers the prediction function. For example, the decision node determines the output branch based on the customer name, as in the example of Figure 2 For each decision element in the workflow, a history of the path taken by the decision element is maintained. In one embodiment, the four (4) previous paths taken by the decision element are stored in the predictor history data structure of that decision element. For decision element 205, the path history could be "Yes", "Yes", "Yes", "No". The output paths could also be labeled in other ways, such as Path History A, A, A, B. Of course, any number of previous paths can be stored for the decision element. This path history is maintained in a data structure such as the decision element history 170 shown associated with decision elements 205 and 210.

[0046] Each element in the workflow is assigned a unique ID so that the system can identify and track workflow elements. Each path can also be assigned a unique ID to identify that path from all other paths in the workflow. The predictor history data structure can be arranged to map or associate each decision element ID with its corresponding path history. Thus, when a prediction is requested, the path history of the selected decision element can be identified and retrieved.

[0047] When the workflow reaches a decision element and there is no historical data (meaning the system is at this decision node for the first time), then the decision element is executed without a prediction. This includes: receiving input data, retrieving the corresponding data record (e.g., customer contact record), evaluating the "name" field of the record; and deciding on the output branch based on the name field value. The system then saves the output path taken (e.g., Path "A") in the history data of that decision element. When the historical data is retrieved for that decision element, the historical data represents the last time the workflow was at that decision element and the workflow went to Path "A". After multiple predictions are made for a decision element, the system also stores and maintains the accuracy of the predictions, which are determined based on the actual output paths taken.

[0048] If there are multiple decision elements in a workflow, then the system has multiple occurrence predictions: one predictor for each decision element based on the last four (4) historical paths taken for that decision element. Since each path has an assigned ID and an associated prediction accuracy, the system compares each predictor from the decision elements to each other and determines which predictor is the most accurate. If the first predictor at the first decision element is accurate in the last prediction, then the system trusts that predictor more than an inaccurate predictor. In one embodiment, each predictor is assigned a confidence value corresponding to the degree of accuracy of the previous prediction. For example, the most frequently selected path in the past will be given a greater weight and selected as the next prediction. Thus, if the path history of a decision element is path A, A, A, B, then path A will be the next predicted path because path A is the most frequently selected path between path A and B. The confidence value for path A is 75% (3 out of the last 4 results).

[0049] As previously described, the decisions in the decision elements are based on data records with specified field values. The race predictors for each decision element are implemented to predict the outcome of the decision element and thus the outcome branch path. The predictors also execute in parallel and / or concurrently with the processing of the decision element. Thus, the predictors execute and make predictions about the outcome without waiting for or knowing the actual field values from the retrieved data records.

[0050] In one embodiment, the system implements two types of predictors for attempting to predict the path that will be taken through the workflow: a record-based historical predictor and a global historical predictor. Each decision element in the workflow has been given a unique ID that is associated with the predictor. For each decision element, the following predictors are used to determine the most likely output path to be taken:

[0051] 1) Record-based historical predictors. This type of predictor is specifically designed to store and use historical data for the selected data records. For example, the system generates a historical predictor for the data record of "John Smith" and stores the results of the last X decisions made using this record. For many customers, a given record may be opened many times and behave consistently each time it is opened. When an agent opens the data record (John Smith) during a workflow, the system determines which features in the data record the agent is viewing. Features can include job titles, locations, places, departments, and / or other attributes that may appear in the data record. Each different feature can result in a different user interface being generated using customized data associated with that feature. Suppose the record history of the John Smith record shows that the record has been opened four times and the "Title" data field has been "Director" each time. The next time the record is opened, the predictor forecasts based on the previous history that the Title will still be "Director" and predicts the corresponding output path and user interface based on the feature being "Director".

[0052] As another example, suppose the workflow has a branch path based on the record being created on a certain day and the record being related to a certain topic. These attributes are not likely to change between the times when an agent opens the record. Knowing the path the workflow previously took when processing this record will be a strong predictor of the path the workflow will take again when the record is opened in the workflow the next time.

[0053] 2) Global historical predictors. Instead of using the history of a single data record as in the record-based historical predictor, the global historical predictor looks at the history of many different records, which can include the history of all records in the selected category. For example, the global historical predictor looks at multiple records that have common features and whose history is used to predict the output path at a decision element. The record-based historical predictor may not have any data for a given record, but the global history can provide a prediction of what the agent is typically doing, regardless of the actual workflow assigned to the agent.

[0054] There may also be different workflows that process the same record differently each time it is opened. This could be through an upgrade process that automatically changes the record values, for example. In these cases, the decision element may not repeat the previous path. Recall that different workflows are assigned to an agent based on the type of task the agent is performing or the type of data record that is opened. Each workflow can be configured differently to handle a specific task and will have different workflow elements. For example, if an agent opens a "Contact" data record, then the system will assign the contact workflow to the agent to follow. If an "Event" task record is opened (to process an event report), then the system assigns the event workflow for the agent to follow.

[0055] In one embodiment, each predictor keeps track of its own accuracy. The tournament aspect is to select the prediction path of the predictor with the best historical accuracy as the overall prediction path. Each predictor participating in the tournament prediction scheme can be arbitrarily complex. In another embodiment, more advanced machine learning concepts or pattern matching schemes can be used to build the predictor.

[0056] In another embodiment, for each predictor of a decision element / node, the system maintains two queues. These two queues are stored in the decision element history 170 associated with each decision element (as Figure 1 and Figure 2 shown). If the length of four (4) used above is used again, then the system has one queue that contains the predictions made by the decision element predictor in the last 4 runs, while the second queue maintains the actual paths taken in the last 4 runs. These are used to calculate two things: (1) the path prediction P based on the paths actually taken historically, and (2) the confidence C based on the performance of that particular predictor over the historical window.

[0057] For example, assume D is a decision node with output paths P ∈ {X, Y, Z}, and let Table 1 below show an example history recorded for three predictors after encountering this decision node four times:

[0058] Table 1 – Predictor History

[0059] Predictor 1

[0060] Actual history: X Y X

[0061] Prediction history: X Y

[0062] Predictor 2

[0063] Actual history: X Z Y Z

[0064] Predicted History: X Z Y

[0065] Predictor 3

[0066] Actual History: X Z

[0067] Predicted History: X Z

[0068] When the system reaches this decision node next time, predictions are calculated for each registered predictor. A prediction consists of two components: an output path P ∈ {X, Y, Z} and a confidence level C ∈ [0, 1].

[0069] P is calculated as the most frequent output of the actual history, and C is calculated as the accuracy of the predictor over the length of the history, comparing its own prediction to the actual result.

[0070] For Predictor 1:

[0071] P = X / / 2 X's and 2 Y's, tie goes to the nearest history which is X

[0072] C = 0.50 / / 2 out of the last 4 correct

[0073] For Predictor 2:

[0074] P = Z / / 2 out of the last 4

[0075] C = 0.25 / / 1 out of the last 4 correct

[0076] For Predictor 3:

[0077] P = Z / / nearest prediction wins in a tie

[0078] C = 0.75 / / 3 out of the last 4 correct

[0079] Now, the system has a race selection among each predictor, where it takes the predictor with the highest confidence. Predictor 3 wins with its highest confidence of 75%, and the overall result is a path prediction of Z. The reason each of these predictors can have a different actual history is that they can be registered for different ranges where they may not apply to all the same cases as others, thus being exposed to different scenarios and recording different histories.

[0080] In one embodiment, in the case where the confidence levels are equal between two predictors predicting different paths, the system performs an implicit ranking based on which types of predictors are considered to provide more accurate results particularly within the associated product domain.

[0081] Result

[0082] In one embodiment, the exemplary performance results are measured by enabling this branch prediction system at a service cloud test site. During testing, the test opens the same record 5 times and records the average time to display the resulting user interface so that the test system can monitor for performance regressions. This particular test has a workflow that has decision elements based on whether a service request has been closed. The system assumes that agents should not open as many "closed" requests as they open "active" requests, so the system automatically makes this prediction (without prior knowledge of the actual workflow). Based on the prediction, the system pre-builds the predicted user interface, which ultimately results in rendering the user interface. The completion time is measured with and without prediction (e.g., serial processing). The prediction system is able to reduce the time to open an active service request and render the corresponding user interface from approximately 5 seconds (for serial processing) to approximately 3 seconds (when using the prediction system).

[0083] Generate / Pre - build User Interface

[0084] The following is an example embodiment of the operations performed to generate / pre-build the user interface as described above. Referring Figure 2 to the workflow 200 in, the terminal workspace contact elements 215, 230, 235, 245, and 250 trigger different user interfaces, depending on which branch is taken along the workflow, and these user interfaces can be presented to the user / agent.

[0085] In one embodiment, when making a prediction at a decision element, the system constructs the user interface as a web page as follows:

[0086] The structure or framework of the web page is defined according to HTML, and the content of the page is defined according to the data bound to that framework. There are many steps involved in combining these and actually drawing the visible elements onto the display screen, but this is handled by the browser's rendering engine and is outside the scope of this disclosure.

[0087] The construction of the user interface is performed prior to the actual rendering step. The step of the browser rendering the user interface on the web page is separate from the construction of the user interface. To construct the user interface, the system uses:

[0088] (1) A fully-expanded HTML tree that describes the layout of a given workspace (e.g., the workflow structure and the elements representing the different UIs shown Figure 2 in the workflow 200). Since the workspace is fully configurable, each element therein, i.e., text fields, buttons, images, tables, etc., is defined by a unique block of HTML. To have the browser render the workspace, the system places all the parts in an object.

[0089] (2) Second, the system uses a corresponding data structure that matches the HTML tree and holds the content to be displayed. That is, HTML defines the text boxes we want to display, and this data structure tree defines the content we actually display in those text boxes. We call these supporting data structures view models, and we need to build the same composite tree of HTML and view models that defines the structure and content of the UI we want to display.

[0090] The workspace elements can be arbitrarily complex. The user is able to add any number of fields, controls, and even custom extensions to their workspace. In some systems, when building the presentation design pattern, each item displayed on the workspace is built using the MVVM design pattern (Model-View-ViewModel MVVM). This means there are views and view models of the model that can be bound back to the original data. Building the views and view models is somewhat expensive in terms of time and computational resources, and significant performance improvements can be achieved by starting these operations faster through prediction. Using the present invention, views and view models can be created and then bound to the view model at a later point in time.

[0091] In one embodiment of the system for building both components (1) and (2) above, the system uses a workspace definition (our data representation that contains what the customer wants to see for their UI). For example, Figure 2 the contact workspace element in workflow 200 shows the different terminal elements that can be reached in workflow 200. One objective of this prediction system is to allow the construction of the two trees described in (1) and (2) above before the system is actually certain which workspace the user will ultimately reach when navigating serially along workflow 200.

[0092] In one embodiment, these workspace definitions are defined on the browser client, so the system can build any one of them when triggered. The system doesn't know which one until the actual data record (as part of the decision element) is retrieved to identify what the agent / user is trying to access and view. This prediction system is implemented and executed at this point in the workflow to predict which possible workspaces and associated user interfaces the system should attempt to build in advance. The prediction and pre-building of the user interface are performed concurrently while the system waits for a network request to retrieve the data record from the database and determine the result of the decision element.

[0093] Process Comparison

[0094] For comparison, the serial processing of the decision element is performed as follows:

[0095] 1) Send a network request to the database to obtain the record(s) that the proxy / user wants to view;

[0096] 2) The system waits for the record(s) to be returned via network communication and then loads the record(s) and their field values into memory. Then, the decision element determines the result of its decision based on the selected field values. The result corresponds to an output branch in the workflow that leads to the construction of the result user interface;

[0097] 3) Construct an HTML and a view model tree for the result user interface;

[0098] 4) Send the user interface to the browser engine to be rendered.

[0099] With this prediction system, when encountering a decision element, instead of waiting for the network requests from steps one and two to complete, the system sends the same requests. However, while waiting for the records to be returned, the system predicts the user interface in parallel and starts pre - constructing the user interface (e.g., constructing the HTML and view model based on the prediction).

[0100] When the requested record(s) are returned and their field value(s) are analyzed, the prediction system confirms whether the prediction is correct based on the result of the decision element. If the prediction is correct, then the system simply continues and completes the construction of the user interface that has already started (if not already completed). Thus, the system effectively reduces the perceived load time by the time taken to issue the network requests and load the retrieved records. If the prediction is incorrect, then the pre - constructed user interface is discarded / deleted, and the system resumes processing at step 2 as before. Note that since the prediction processing is done in parallel, the penalty for an error is essentially nil.

[0101] Some estimated time figures can give some context. For a standard user interface to be generated and rendered, on a computer with an appropriate network connection speed, it may take 300 ms to 500 ms (milliseconds) to perform all the work of constructing the HTML and view model after the data record is retrieved and the decision element is complete. The network request may take approximately 100 ms to 200 ms to obtain the data record that tells the system what user interface to build. Adding this time, the serial processing method requires network round - trip + processing time = 400 ms to 700 ms. With this system and method that executes these steps in parallel using the novel prediction technique, the system is only bounded by the 300 ms to 500 ms processing time for constructing the user interface. Thus, this is an improvement over computer capabilities and prior art processing.

[0102] The timing can depend on many factors, but regardless of the Internet and computer speeds, the end result is that the system can eliminate the serial dependencies of operations by implementing predictive techniques. The predictive techniques allow concurrent execution of operations that could not be performed in previous serial-dependent techniques.

[0103] Cloud or Enterprise Example

[0104] In one embodiment, Figure 1 the prediction system / branch predictor 140 and / or the configured computing device 100 shown in is a computing / data processing system that includes applications for an enterprise organization or a collection of distributed applications. The applications and the computing system 100 can be configured to operate with or implemented as a cloud-based networking system, a software as a service (SaaS) architecture, or other types of networked computing solutions. In one embodiment, the branch predictor 140 and / or the method 300 is a centralized server-side application that at least provides the functions disclosed herein and is accessed by many users via a computing device / terminal communicating with the computing system 100 (acting as a server) through a computer network.

[0105] In one embodiment, one or more components described herein are configured as program modules stored in a non-transitory computer-readable medium. The program modules are configured with stored instructions that, when executed by at least one processor, cause the computing device to perform the corresponding function(s) as described herein.

[0106] Computing Device Example

[0107] Figure 4 An example computing device is illustrated that is configured and / or programmed as a dedicated computing device having one or more of the example systems and methods and / or equivalent forms described herein. The example computing device can be a computer 400 that includes a processor 402, a memory 404, and input / output ports 410 operably connected by a bus 408. In one example, the computer 400 can include prediction logic / module 430 that is configured to facilitate Figure 1 the prediction systems of the computing device 100 and the branch predictor 140 shown in, and Figure 3 the method 300 shown in. In different examples, the logic 430 can be implemented in hardware, a non-transitory computer-readable medium having stored instructions, firmware, and / or a combination thereof. Although the logic 430 is shown as a hardware component attached to the bus 408, it should be appreciated that in other embodiments, the logic 430 can be implemented in the processor 402, stored in the memory 404, or stored on the disk 406.

[0108] In one embodiment, the logic 430 or the computer is a component (e.g., structure: hardware, non-transitory computer-readable medium, firmware) for performing the described actions. In some embodiments, the computing device can be a server operating in a cloud computing system, a server configured in a software as a service (SaaS) architecture, a smart phone, a laptop computer, a tablet computing device, etc.

[0109] The computer 400 and the prediction logic 430 are structures for providing components (e.g., hardware, non-transitory computer-readable medium storing executable instructions, firmware) for executing this prediction system.

[0110] Generally describing an example configuration of the computer 400, the processor 402 can be various different processors, which are configured to operate and be controlled by the prediction logic 430, including dual microprocessors and other multi-processor architectures. The memory 404 can include volatile memory and / or non-volatile memory. The non-volatile memory can include, for example, ROM, PROM, etc. The volatile memory can include, for example, RAM, SRAM, DRAM, etc.

[0111] The storage disk 406 can be operatively connected to the computer 400 via, for example, an input / output (I / O) interface (e.g., card, device) 418 and an input / output port 410 controlled by at least an input / output (I / O) controller 440. The disk 406 can be, for example, a disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash card, a memory stick, etc. In addition, the disk 406 can be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD ROM, etc. For example, the memory 404 can store the process 414 and / or the data 416. The disk 406 and / or the memory 404 can store an operating system for controlling and allocating resources of the computer 400.

[0112] The computer 400 can interact with input / output (I / O) devices via the I / O interface 418 and interact with the input / output ports 410 via the input / output (I / O) controller 440. The input / output devices can be, for example, a keyboard, a microphone, a pointing and selection device, a camera, a video card, a display, the disk 406, a network device 420, etc. The input / output ports 410 can include, for example, serial ports, parallel ports, and USB ports.

[0113] The computer 400 can operate in a network environment and can thus be connected to a network device 420 via the I / O interface 418 and / or the I / O port 410. Through the network device 420, the computer 400 can interact with the network. Through the network, the computer 400 can be logically connected to a remote computer. Networks with which the computer 400 can interact include, but are not limited to, LANs, WANs, and other networks.

[0114] Definitions and Other Examples

[0115] In another embodiment, the described method and / or its equivalent is implemented with computer-executable instructions. Thus, in one embodiment, a non-transitory computer-readable / storage medium is configured to have computer-executable instructions for an algorithm / executable application stored thereon, the instructions, when executed by one or more machines, cause the one or more machines (and / or associated components) to perform the method. Example machines include, but are not limited to, processors, computers, servers operating in a cloud computing system, servers configured with a software as a service (SaaS) architecture, smart phones, and the like. In one embodiment, a computing device is implemented with one or more executable algorithms configured to perform any of the disclosed methods.

[0116] In one or more embodiments, the disclosed methods or their equivalents are performed by any of the following: computer hardware configured to perform the method; or, computer instructions implemented in a module stored on a non-transitory computer-readable medium, where the instructions are configured as an executable algorithm, and the executable algorithm is configured to perform the method when executed by at least one processor of a computing device.

[0117] Although, for purposes of simplicity of explanation, the methods illustrated in the figures are shown and described as a series of blocks of an algorithm, it should be recognized that these methods are not limited by the order of the blocks. Some blocks may occur in a different order than shown and described and / or may occur concurrently with other blocks. Also, example methods may be implemented with fewer blocks than all of the blocks illustrated. Blocks may be combined or divided into multiple actions / components. Additionally, and / or alternatively, additional actions not illustrated in the blocks may be employed in the disclosed methods.

[0118] The following includes definitions of selected terms employed herein. The definitions include various examples and / or forms of components that fall within the scope of the term and that may be used to implement it. The examples are not intended to be limiting. Both the singular and plural forms of the terms may be within the definitions.

[0119] References to "an embodiment", "embodiments", "an example", "examples", etc., indicate that the (one or more) embodiments or (one or more) examples so described may include a particular feature, structure, characteristic, property, element, or limitation, but not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element, or limitation. Further, repeated use of the phrase "in an embodiment" does not necessarily refer to the same embodiment, but may.

[0120] As used herein, a "data structure" is an organization of data stored in a memory, storage device, or other computerized system in a computing system. A data structure can be, for example, any one or combination of data fields, data files, data arrays, data records, databases, data tables, graphs, trees, linked lists, etc. A data structure can be formed by many other data structures and contain many other data structures (e.g., a database includes many data records). According to other embodiments, other examples of data structures are possible.

[0121] As used herein, a "computer-readable medium" or "computer storage medium" refers to a non-transitory medium that stores instructions and / or data configured to perform one or more of the disclosed functions when executed. In some embodiments, the data can serve as instructions. A computer-readable medium can take forms including but not limited to non-volatile media and volatile media. Non-volatile media can include, for example, optical disks, magnetic disks, etc. Volatile media can include, for example, semiconductor memories, dynamic memories, etc. Common forms of a computer-readable medium can include but not limited to floppy disks, flexible disks, hard disks, magnetic tapes, other magnetic media, application specific integrated circuits (ASICs), programmable logic devices, compact discs (CDs), other optical media, random access memory (RAM), read only memory (ROM), memory chips or cards, memory sticks, solid state storage devices (SSDs), flash drives, and other media that a computer, processor, or other electronic device can operate on. If each type of medium is selected for implementation in an embodiment, it can include stored instructions of an algorithm configured to perform one or more of the disclosed and / or claimed functions.

[0122] As used herein, "logic" refers to a component implemented using computer or electrical hardware, a non-transitory medium having stored executable application or program module instructions, and / or a combination of these, to perform any function or action disclosed herein, and / or to cause a function or action from another logic, method, and / or system to be performed as disclosed herein. Equivalent logic can include firmware, a microprocessor programmed with an algorithm, discrete logic (e.g., an ASIC), at least one circuit, an analog circuit, a digital circuit, a programmable logic device, a memory device containing instructions of an algorithm, etc., any of which can be configured to perform one or more of the disclosed functions. In one embodiment, the logic can include one or more gates, a combination of gates, or other circuit components configured to perform one or more of the disclosed functions. In the case of describing multiple logics, it is possible to combine the multiple logics into one logic. Similarly, in the case of describing a single logic, it is possible to distribute that single logic among multiple logics. In one embodiment, one or more of these logics are corresponding structures associated with performing the disclosed and / or claimed functions. The choice of which type of logic to implement can be based on desired system conditions or specifications. For example, if higher speed is considered, hardware will be selected to implement the function. If lower cost is considered, stored instructions / executable applications will be selected to implement the function.

[0123] An "operable connection" or the connection by which an entity is "operably connected" is a connection through which signals, physical communication, and / or logical communication can be sent and / or received. An operable connection can include a physical interface, an electrical interface, and / or a data interface. An operable connection can include different combinations of interfaces and / or connections sufficient to allow operable control. For example, two entities can be operably connected to transmit signals to each other directly or through one or more intermediate entities (e.g., a processor, an operating system, logic, a non-transitory computer-readable medium). A logical communication channel and / or a physical communication channel can be used to create an operable connection.

[0124] As used herein, "user" includes, but is not limited to, one or more individuals, computers or other devices, or a combination of these.

[0125] Although the disclosed embodiments have been illustrated and described in considerable detail, it is not intended to limit or in any way define the scope of the appended claims to such details. Of course, it is not possible to describe every conceivable combination of components or methods for the various aspects of the subject matter. Accordingly, the present disclosure is not limited to the specific details or illustrative examples shown and described. Thus, the present disclosure is intended to cover variations, modifications, and changes that fall within the scope of the appended claims.

[0126] To the extent that the term "comprising" is used in the detailed description or claims, it is intended to be inclusive in a manner similar to the way the term "including" is interpreted when used as a transitional term in claims.

[0127] To the extent that the term "or" is used in the detailed description or claims (e.g., A or B), it is intended to mean "A or B, or both". When the applicant intends to indicate "only A or B but not both", then the phrase "only A or B but not both" will be used. Thus, the term "or" is used inclusively herein, rather than in an exclusive sense.

Claims

1. A non-transitory computer-readable medium including computer-executable instructions stored thereon, the instructions, when executed by at least one processor of a computer, cause the computer to: At least input a workflow into a memory by the processor and serially proceed in the workflow in a sequence of flow; Wherein the workflow is configured with a plurality of execution paths including a plurality of decision elements for controlling access to different parts of the execution paths, and wherein the plurality of execution paths lead to a plurality of terminal elements associated with a plurality of user interfaces; In response to the sequence of flow encountering a first decision element in a workflow including a plurality of branch paths: (i) Perform a prediction that predicts a result path of the first decision element to predict a first user interface that may subsequently be encountered as part of a first terminal element in the sequence of flow from the plurality of user interfaces; and (ii) Pre-build the predicted first user interface before encountering the first terminal element; In response to the sequence of flow reaching the first terminal element, display the pre-built first user interface on a display device, mark the prediction as correct to maintain the accuracy of the prediction of the first decision element, and associate the prediction with a history of the path taken by the first decision element; and In response to the sequence of flow reaching a second terminal element, discard the pre-built first user interface and generate a second user interface associated with the second terminal element.

2. The non-transitory computer-readable medium according to claim 1, wherein the instructions for pre-building the predicted first user interface further include instructions that cause the processor to perform the following operations: Generate a structure and associated data of the first user interface in the memory; and Maintain the first user interface in the memory without rendering the first user interface on the display device until the processor confirms that the sequence of flow reaches the first terminal element that triggers the first user interface.

3. The non-transitory computer-readable medium according to claim 1 or 2, further including instructions that, when executed by at least the processor, cause the processor to: In response to the workflow reaching a second decision element, perform a prediction and predict a second result user interface at least partially based on a history of the path taken from the second decision element; and If the second result user interface is different from the predicted first user interface, then discard the pre-built first user interface and generate the second result user interface.

4. The non-transitory computer-readable medium according to claim 1 or 2, further including instructions that, when executed by at least the processor, cause the processor to: For each decision element in the workflow, maintain a history of the paths taken at the corresponding decision element during a previous workflow execution; and Based on the history of the paths taken, generate confidence values for each branch path from the corresponding decision element.

5. The non-transitory computer-readable medium according to claim 1 or 2, further including instructions that, when executed by at least the processor, cause the processor to: Wherein each decision element is configured to determine a result based on a decision condition of one or more input values, and the one or more input values control the result that causes progress along an output branch path in the workflow; One or more input values are received by making a network request to a database and retrieving data records, loading the data records and associated values into a memory from the data records, and parsing decision conditions based on the associated values.

6. A computing system, comprising: at least one processor; at least one memory operably connected to the at least one processor; a non-transitory computer-readable medium having instructions stored thereon that, when executed at least by the processor, cause the processor to: input a workflow into the memory at least by the processor and proceed serially in the workflow in a sequence of flow steps; wherein the workflow is configured with multiple execution paths, including multiple decision elements for controlling access to different parts of the execution paths, and wherein the multiple execution paths lead to multiple terminal elements associated with multiple user interfaces; in response to the sequence of flow steps encountering a first decision element in a workflow including multiple branch paths: (i) perform a prediction that predicts a result path of the first decision element to predict a first user interface that may subsequently be encountered as part of a first terminal element in the sequence of flow steps from the multiple user interfaces; and (ii) pre-build the predicted first user interface before encountering the first terminal element; in response to the first decision element outputting a first result path leading to the predicted first user interface, display the pre-built first user interface on a display device, mark the prediction as correct to maintain the accuracy of the prediction of the first decision element, and associate the prediction with a history of the path taken by the first decision element; and in response to the first decision element outputting a second result path not associated with the predicted first user interface, discard the pre-built first user interface and generate a second user interface associated with the second result path.

7. The computing system of claim 6, wherein the instructions for pre-building the predicted first user interface further include instructions that cause the processor to: generate a structure and associated data of the first user interface in the memory; and maintain the first user interface in the memory without rendering the first user interface on the display device until the processor confirms that the sequence of flow steps reaches the first terminal element that triggers the first user interface.

8. The computing system of any one of claims 6-7, further comprising instructions that, when executed at least by the processor, cause the processor to: in response to the workflow reaching a second decision element, perform a prediction and predict a second result user interface based at least in part on a history of the path taken from the second decision element; and if the second result user interface is different from the predicted first user interface, then discard the pre-built first user interface and generate the second result user interface.

9. The computing system of any one of claims 6-7, further comprising instructions that, when executed at least by the processor, cause the processor to: for each decision element in the workflow, maintain a history of the path taken at the corresponding decision element during a previous workflow execution; and Generate confidence values for each branch path from the corresponding decision element based on the history of the path taken.

10. The computing system according to any one of claims 6 to 7, further comprising instructions that, when executed at least by a processor, cause the processor to: wherein each decision element is configured to determine a result based on a decision condition of one or more input values, the one or more input values controlling the result that causes progress along an output branch path in the workflow; wherein the one or more input values are received by initiating a network request to a database and retrieving a data record, loading the data record and associated values from the data record into a memory, and parsing the decision condition based on the associated values.

11. A computer-implemented method executed by a computing device and a processor executing instructions in a memory, the method comprising: inputting at least a workflow into a memory by the processor and proceeding serially in the workflow in a sequence of flow; wherein the workflow is configured with a plurality of execution paths, including a plurality of decision elements for controlling access to different parts of the execution paths, wherein the plurality of execution paths lead to a plurality of terminal elements associated with a plurality of user interfaces; in response to the sequence of flow encountering a first decision element in a workflow including a plurality of branch paths: (i) perform a prediction that predicts a result path of the first decision element to predict a first user interface that may be encountered subsequently as part of the first terminal element in the sequence of flow from the plurality of user interfaces; and (ii) pre-build the predicted first user interface before encountering the first terminal element; in response to the sequence of flow reaching the first terminal element, display the pre-built first user interface on a display device, mark the prediction as correct to maintain the accuracy of the prediction of the first decision element, and associate the prediction with the history of the path taken by the first decision element; and in response to the sequence of flow reaching a second terminal element, discard the pre-built first user interface and generate a second user interface associated with the second terminal element.

12. The method according to claim 11, wherein pre-building the predicted first user interface further comprises: generating a structure and associated data of the first user interface in a memory; and maintaining the first user interface in the memory without rendering the first user interface on the display device until the processor confirms that the sequence of flow reaches the first terminal element that triggers the first user interface.

13. The method according to claim 11 or 12, further comprising: in response to the workflow reaching a second decision element, perform a prediction and predict a second result user interface at least in part based on the history of the path taken from the second decision element; and if the second result user interface is different from the predicted first user interface, then discard the pre-built first user interface and generate the second result user interface.

Images