Graphical user interface and flexible architecture for rule engine

Abstract

One example of the present disclosure may include a system configured to provide a graphical user interface including a set of graphical input elements for receiving selected conditions and selected actions for a new rule. The system may generate a new rule definition for the new rule based on the selected condition and the selected action. The system may store the new rule definition in a rule database. The system may then select a subset of the rule definitions from the rule database. The system may apply the subset of rule definitions to the user data to determine whether the user data matches the subset of rule definitions. If the user data matches the rule definition, the system may perform at least one action associated with the rule definition.

Description

Technical Field

[0001] The present disclosure generally relates to rule engine software that can be executed on a computer. More specifically, but not by way of limitation, the present disclosure relates to a graphical user interface and a flexible architecture for a rule engine that can be used to allocate points to an online account. Background Art

[0002] A rule engine can include executable software that is configured to apply predefined rules to user data to determine whether the user data matches the rules. If the user data matches the rules, the rule engine takes certain predefined actions corresponding to the rules. A single rule can include one or more conditions and one or more corresponding actions to be performed if the conditions are met. The rule engine can apply hundreds of thousands of such rules to user data and perform one or more corresponding actions based on which rules match the user data. Summary of the Invention

[0003] An example of the present disclosure includes a non-transitory computer-readable medium including program code that can be executed by one or more processors to cause the one or more processors to perform operations. The operations can include: providing a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule. The operations can include: generating a new rule definition for the new rule based on the selected conditions and selected actions. The operations can include: storing the new rule definition in a rule database that includes multiple rule definitions for multiple rules. The operations can include: executing a rule engine that is configured to: select a subset of rule definitions from the multiple rule definitions in the rule database, where the subset of rule definitions includes the new rule definition and where the subset of rule definitions corresponds to a subset of the rules among the multiple rules; and apply the subset of rule definitions to user data to determine whether the user data matches the subset of the rules. The operations can include: in response to determining that the user data matches at least one rule in the subset of the rules, issuing a command for causing at least one action associated with the at least one rule to be executed.

[0004] Another example of the present disclosure may include a method involving operations. The operations may include: providing a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule. The operations may include: generating a new rule definition for the new rule based on the selected conditions and selected actions. The operations may include: storing the new rule definition in a rule database that includes multiple rule definitions for multiple rules. The operations may include: executing a rule engine that is configured to: select a subset of rule definitions from the multiple rule definitions in the rule database, where the subset of rule definitions includes the new rule definition and where the subset of rule definitions corresponds to a subset of rules among the multiple rules; and applying the subset of rule definitions to user data to determine whether the user data matches the subset of rules. The operations may include: in response to determining that the user data matches at least one rule in the subset of rules, issuing a command to cause at least one action associated with the at least one rule to be executed. Some or all of the operations may be implemented by one or more processors.

[0005] Another example of the present disclosure includes a system that includes: one or more processors, and one or more memories. The one or more memories may include instructions executable by the one or more processors to cause the one or more processors to perform operations. The operations may include: providing a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule. The operations may include: generating a new rule definition for the new rule based on the selected conditions and selected actions. The operations may include: storing the new rule definition in a rule database that includes multiple rule definitions for multiple rules. The operations may include: selecting a subset of rule definitions from the multiple rule definitions in the rule database, where the subset of rule definitions includes the new rule definition and where the subset of rule definitions corresponds to a subset of rules among the multiple rules. The operations may include: applying the subset of rule definitions to user data to determine whether the user data matches the subset of rules. The operations may include: in response to determining that the user data matches at least one rule in the subset of rules, issuing a command to cause at least one action associated with the at least one rule to be executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 A block diagram illustrating an example of a system for providing a graphical user interface and a flexible architecture for a rule engine in accordance with some aspects of the present disclosure.

[0007] Figure 2A block diagram showing an example of a rule engine in accordance with some aspects of the present disclosure.

[0008] Figure 3 An example of a graphical user interface for adding new rules to a rule set in accordance with some aspects of the present disclosure is shown.

[0009] Figures 4A to 4B A sequence diagram showing an example of a process for securely linking online accounts in accordance with some aspects of the present disclosure.

[0010] Figures 5 to 8 An example of a graphical user interface page for linking online accounts in accordance with some aspects of the present disclosure is shown.

[0011] Figure 9 A flowchart showing an example of a process for providing a graphical user interface and a flexible architecture for a rule engine in accordance with some aspects of the present disclosure.

[0012] Figure 10 A block diagram showing an example of a computing device for implementing some aspects of the present disclosure. DETAILED DESCRIPTION

[0013] Conventional rule engines can be software where a predefined set of rules is hardcoded into the software before compilation or execution of the software. For example, a software developer can program rules directly into the source code of the rule engine. The software developer can also program the order in which the rules are directly applied to the source code. However, this approach may lack flexibility and lead to various problems. For example, every time a rule needs to be modified (e.g., added or removed), the rule engine may need to be shut down, manually reprogrammed by a skilled programmer, recompiled, and then redeployed on a computer system. This process can make modifying rules cumbersome. The resulting downtime when the rule engine is updated and redeployed on a computer system can also be problematic for various reasons.

[0014] In addition to the above challenges, manually programming a large number of rules (e.g., hundreds or thousands of rules) into a conventional rule engine can take a significant amount of time and expertise. Doing so can also significantly increase the length and complexity of the source code, making it more difficult to understand and maintain. Longer and more complex source code can make it more likely that human errors are introduced into the source code, resulting in functional problems in the rule engine. Longer and more complex source code can also increase the time required to compile the source code and the amount of computing resources consumed during the compilation process. Once compiled, larger source code files can also produce larger binary files that consume more memory space.

[0015] These problems occur not only during the programming of a conventional rule engine, but also during the runtime of the rule engine. For example, hard-coding rules into the source code can result in the same rules being applied in the same way every time, which is inflexible and may unnecessarily consume computing resources (e.g., processing power and RAM) by applying unrelated rules. This brute-force approach, where all rules are applied in the same way every time, consumes computing resources and produces sub-optimal results.

[0016] Some examples of the present disclosure can overcome one or more of the above problems by providing a graphical user interface and a flexible architecture for a rule engine, which can simplify the process of adjusting the rules for the rule engine. Using the graphical user interface and the flexible architecture, rules can be dynamically adjusted during the runtime of the rule engine without having to shut down, reprogram, or recompile the rule engine itself.

[0017] In some examples, the graphical user interface can include a set of graphical input elements through which a user can define the parameters of a rule. Examples of graphical input elements can include text boxes, radio buttons, check boxes, etc. The parameters can include the conditions of the rule and the corresponding actions to be taken if those conditions are met. The graphical user interface can enable non-programmers to easily define rules using a simple graphical interface. The system can then convert the user's selections into a rule definition that can define the parameters of the rule in a format compatible with the rule engine. The rule definition can then be stored in a rule database that is separate from but accessible by the rule engine. The rule database can be dynamically adjusted during the runtime of the rule engine to add or remove rules. Storing the rules in a separate rule database can increase the flexibility of the rule engine. And since the rules are maintained in a separate rule database (instead of being hard-coded into the rule engine), the length and complexity of the source code of the rule engine can be reduced, making the rule engine faster to update, compile, and run, and less susceptible to human errors.

[0018] At runtime, the rule engine can access the rule database, select a subset of rules to apply to a given user data set, and apply the rules. The rule engine can select a subset of rules to apply to the user data set through an intelligent filtering process that can be designed to reduce the total number of rules applied to the user data. Compared to the brute-force approach of traditional rule engines, this can help save computing resources and result in faster execution and improved performance.

[0019] A rule engine can be used to perform a variety of tasks. For example, the rule engine can be configured to apply point adjustments to a user's online account. In some such examples, each user can have an online account with respect to an entity such as a company. Users can perform various operations linked to their online accounts. For example, a user can participate in an interaction (e.g., a transaction) linked to their online account. In some such examples, the rule engine can receive data every minute about thousands of such interactions performed by thousands of users. The rule engine can receive and analyze each interaction. The analysis can be performed substantially in real time. For example, the rule engine can use an intelligent filtering process to select a subset of rules from a rule database to apply to a given interaction. The rule engine can then analyze the interaction data against the subset of rules to determine which rules (if any) match the interaction. If a rule matches the interaction, the rule engine can perform a corresponding action. The action can include adjusting the point total of the online account of the user participating in the interaction. For example, the rule engine can add points to or remove points from the point total associated with the user's online account. If multiple rules match the interaction, the rule engine can distinguish priorities among the corresponding actions based on their characteristics and perform some or all of the corresponding actions. This process can be repeated for each interaction until all interactions have been analyzed.

[0020] These illustrative examples are given to introduce the general subject matter discussed here to the reader and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the accompanying drawings, in which like reference numerals indicate like elements, but like the illustrative examples, should not be used to limit the present disclosure.

[0021] Figure 1 A block diagram of an example of a system 100 for providing a flexible rule engine in accordance with some aspects of the present disclosure is shown. System 100 includes a first computer system 102 operated by a first entity 104. The first computer system 102 can include any number of networked computing devices (e.g., physical servers or virtual servers) and combinations thereof.

[0022] The first computer system 102 may include a rule engine 106 configured to apply rules to user data 122. Rule definitions 120 stored in a rule database 108 may be used to define the rules. Rule definitions may be used to describe each rule, which includes one or more conditions and one or more corresponding actions to be performed if the conditions are met. User data 122 may be stored in a user data database 110. The rule engine 106 may retrieve the rule definitions 120 from the rule database 108, apply them to some or all of the user data 122, and perform one or more corresponding actions based on which rules match the user data 122. For example, the rule engine 106 may load some or all of the rule definitions 120 into local memory (e.g., RAM or cache memory). The rule engine 106 may also load some or all of the user data 122 into local memory. The rule engine 106 may then select a piece of the loaded user data for analysis against the loaded rule definitions. The rule engine 106 may apply some or all of the loaded rule definitions to the piece of user data to detect any matches. If a match is detected, the rule engine 106 may perform the actions corresponding to the matching rule definition. Additionally or alternatively, the rule engine 106 may issue commands to a second computing system 130 to cause the second computing system 130 to perform actions.

[0023] The rule definitions may be formatted for use by the rule engine 106. For example, the rule definitions may be stored in JavaScript Object Notation (JSON) format, eXtensible Markup Language (XML) format, or another predefined format such that the rule definitions can be easily interpreted and applied by the rule engine 106. The rule engine 106 may be configured to accept rule definitions in such a predefined format and understand the syntax of the format.

[0024] Because rule definitions may not be easily interpretable or draftable by humans, especially if the rule definitions are long and complex, a graphical user interface 112 may be provided to simplify the process of creating new rules. More specifically, the rule engine 106 may provide the graphical user interface 112 to an administrator 114 for adding new rules to the rule database 108. The administrator 114 may operate a client device 116 to access the graphical user interface 112 via a network 118 such as the Internet. Examples of the client device 116 may include a laptop computer, a desktop computer, a mobile phone, a tablet computer, an e-reader, or a wearable device such as a smartwatch. The graphical user interface 112 may be output on a display of the client device 116.

[0025] The graphical user interface 112 may allow an administrator 114 to easily add new rules to the rule database 108. For example, the graphical user interface 112 may include a form having a set of graphical input elements such as text boxes, radio buttons, and check boxes. The administrator 114 may interact with the graphical input elements to define the parameters of the new rule. The parameters may include one or more conditions of the rule and one or more corresponding actions to be performed if those conditions are met. For example, the administrator 114 may interact with the graphical user interface 112 to select a date from a calendar, select an account type from a drop-down menu, and select a service type from another drop-down menu. These may be conditions of the rule, e.g., the rule is triggered by a user having an account of the selected type and accessing the selected service on the selected date. The administrator 114 may also interact with the graphical user interface 112 to select at least one action to be performed if the conditions of the rule are met. For example, the graphical user interface 112 may include a drop-down menu indicating the different types of actions that may be performed. Some actions may be configured to be performed by a remote computing system such as the second computing system 130. The graphical user interface 112 may also include input boxes for defining the details of the selected type of action. The administrator 114 interacts with the drop-down menu and the input boxes to, for example, select to award a specific number of points to a user account that meets the rule conditions. Once the administrator 114 has made the appropriate selections, the administrator 114 may press a button to submit the form.

[0026] The first computer system 102 may detect that the form has been submitted, interpret the form data, and generate a rule definition based on the form data. The rule definition may be a set of content that defines a new rule. For example, the rule definition may include one or more conditions and one or more actions selected by the administrator 114. As described above, the rule definition may be formatted for use by the rule engine 106, which will ultimately access and apply the rule. After generating the new rule definition (i.e., the rule definition for the new rule), the first computer system 102 may store the new rule definition in the rule database 108. The first computer system 102 may also store additional metadata about the new rule, such as the creator and creation date of the new rule. Through this process, one or more administrators 114 may easily add new rules to the rule database 108.

[0027] In some examples, the graphical user interface 112 may also allow the administrator 114 to easily remove existing rules from the rule database 108. For example, the graphical user interface 112 may automatically populate some or all of the existing rules in the rule database 108 into a list. The graphical user interface 112 may also include one or more filtering options by which the administrator 114 can identify one or more existing rules that match the filtering criteria. For example, the administrator 114 may filter rules by the rule creator, creation date, condition, action, or any combination thereof. After identifying the rule to be deleted, the administrator 114 may select the option to delete the rule. In response, the first computer system 102 may remove the corresponding rule definition from the rule database 108. In some examples, instead of completely deleting the rule, the administrator 114 may select the option to suspend the application of the rule. This may allow the administrator 114 to easily resume the application of the rule at a later time without having to recreate the rule from scratch. If the administrator 114 selects the suspend option, the first computer system 102 may mark the corresponding rule definition as "suspended" in the rule database 108. The rule engine 106 may be configured to ignore suspended rules when evaluating user data 122. At a later point in time, the administrator 114 may reactivate the rule via the graphical user interface 112, at which time the first computer system 102 may remove the "suspended" mark from the corresponding rule definition in the rule database 108.

[0028] The graphical user interface 112 may be generated at least in part by a software program running on the client device 116. For example, the software program may be a native application, and the graphical user interface 112 may be built into the native application. As another example, the software program may be a web browser, and the graphical user interface 112 may be part of a website presented in the web browser. In some examples, the graphical user interface 112 may be generated at least in part by the first computer system 102. For example, the first computer system 102 may generate web page code (e.g., HTML, CSS, or JavaScript) and transmit it to the client device 116, where the web page code defines some or all of the graphical user interface 112. The client device 116 may receive the web page code and use a web browser to render the web page code, thereby generating some or all of the graphical user interface 112.

[0029] Administrator 114 can be any suitable person. For example, Administrator 114 can be an employee operating the first computer system 102 in the first entity 104. Alternatively, Administrator 114 can be an employee of the second entity 124, where the first entity 104 is different from the second entity 124. The first entity 104 can offer different types of market offerings (e.g., products and services) from the second entity 124. For example, the first entity 104 can be a coffee company, while the second entity 124 can be an airline. In some cases, multiple administrators from multiple different entities 104, 124 can access the graphical user interface 112 to add new rules to the rule database 108.

[0030] In some examples, the action associated with a rule can involve adjusting the points associated with an account. For example, user 126 can have an online account 128 with the first entity 104. The online account 128 can be hosted on the first computer system 102. User 126 can operate the user device 132 to access the online account 128. For example, user 126 can operate the user device 132 to connect to the first computer system 102 via the network 118 to access the online account 128. Examples of user devices 132 can include laptop computers, desktop computers, mobile phones, tablets, e-readers, or wearable devices such as smartwatches. The online account 128 can have a total number of points 134. The points can be non-monetary rewards issued by the first entity 106a and / or the second entity 124. Due to various reasons (such as the user data 122 associated with user 126 matching one or more rules defined in the rule database 108), points can be added to or removed from the total number of points 134. Examples of user data 122 can include attributes of user 126 (e.g., the user's age, location, or other characteristics), attributes of the first online account 128 (e.g., the type, priority, age, level, or account history associated with the online account 128), or any combination of these.

[0031] As a specific example, user 126 can participate in an interaction with second entity 124. User 126 can choose to link the interaction to their online account 128. For example, user 126 can use user device 132 to log in to their online account 128 and initiate the interaction using user device 132, which can cause the interaction to be linked to (e.g., associated with) online account 128. Participating in the interaction can involve user 126 interacting with second computer system 130 of second entity 124. For example, user 126 can operate user device 132 to send a command to application programming interface (API) 142 of second entity 124, where the command can facilitate the interaction. Based on the interaction, second computing system 130 or user device 132 can generate interaction data 140. Interaction data 140 can be considered a type of user data 122. Interaction data 140 can include various details about the interaction, such as its date and time, a unique identifier of second entity 124, a unique identifier of user 126, and a unique identifier of an offering associated with the interaction. Interaction data 140 can be sent in a data communication to first computer system 102. Rule engine 106 can receive and analyze interaction data 140 to match one or more rule definitions 120. For each matched rule definition, rule engine 106 can perform a corresponding action and / or issue a command for a remote computing system to perform a corresponding action. For example, rule engine 106 can determine that interaction data 140 triggers a specific rule based on the date, offering, and entity associated with the interaction. Rule engine 106 can then perform a corresponding action, which can, for example, involve increasing total points 134 by a predetermined amount. In this way, user 126 can automatically receive a reward for participating in the interaction. Alternatively, other rule definitions can include actions that decrease total points 134.

[0032] If multiple rules match the user data 122 associated with a given user 126, the rule engine 106 can prioritize among the corresponding actions and perform some or all of the corresponding actions. For example, the rule engine 106 can determine that two rules match the interaction data 140 associated with user 126. The rule engine 106 can identify the actions corresponding to the matching rules and prioritize among the actions using a predefined prioritization policy. The prioritization policy can assign priorities to different actions based on the characteristics of the different actions. Using this policy, the rule engine 106 can determine a prioritized execution sequence that defines the order in which the actions will be performed. The rule engine 106 can then execute the prioritized execution sequence such that the actions are performed in the appropriate order. If two actions conflict with each other, the rule engine 106 can select one of the two actions to perform based on the prioritization policy and ignore the other action. For example, the two actions may conflict when they grant different points for the same set of conditions. In some such examples, the larger reward can be selected relative to the smaller reward.

[0033] In some examples, the rule database 108 can include a large number of rule definitions. For example, the rule database 108 can include thousands of rule definitions associated with dozens of entities. Thus, it may be desirable to perform some kind of intelligent filtering to reduce the total number of rules applied to the user data 122, thereby reducing the system's wait time and computational overhead. For example, certain rules can be associated with certain entities. As a specific example, a particular subset of the rule definitions 120 can be triggered only for interactions associated with a second entity 124 and thus may not be triggered for interactions with other entities. Other entities can similarly have their own unique sets of rules. In some such examples, the rule engine 106 can select which rule set to apply based on the entity associated with the user data 122 being evaluated (e.g., interaction data 140). This can significantly reduce the total number of rules applied to the user data 122 and thus reduce the computational overhead associated with evaluating that user data 122.

[0034] In some examples, the user 126 can have both a first online account 128 with respect to a first entity 104 and a second online account 136 with respect to a second entity 124. The second online account 136 can be hosted on a second computing system 130 of the second entity 124. In some such examples, if the user's first online account 128 is linked to the second online account 136, the rule engine 106 can apply only the rule definitions associated with the second entity 124. To link the first online account 128 to the second online account 136, the system 100 can perform an account linking process. This will be referred to later with reference to FIGS. 4 to Figure 8An example of the account linking process is described in more detail. The links generated via the account linking process can be saved in the account link data store 144. The rule engine 106 can access the account link data store 144 to determine whether the first online account 128 is linked to the second online account 136. If so, the rule engine 106 can apply the rule definitions associated with the second entity 124 to the user data 122. If the first online account 128 is not linked to the second online account 136, the rule engine 106 can skip the rule definitions associated with the second entity 124. By only applying the rule definitions related to the linked online accounts, the total number of rules applied to the user data 122 can be significantly reduced. This can be considered another type of intelligent filtering.

[0035] Although Figure 1 A certain number of components and their arrangements are shown for simplicity, but this is intended to be illustrative rather than restrictive. Other examples may include more components, fewer components, different components, or different component arrangements compared to Figure 1 those shown. For example, other examples may involve thousands of users interacting with thousands of entities distributed worldwide. Those entities can stream user data about the interactions to the first computer system 102 for analysis by the rule engine 106. Some or all of those users may have their respective online accounts with respect to the first entity 104, and those online accounts are linked to other online accounts associated with other entities (e.g., the second entity 124).

[0036] Figure 2Shows an example of the internal workings of a rule engine according to some aspects of the present disclosure. As shown, the rule engine 106 may include any number of nodes 202a to 202n (e.g., physical servers or virtual servers) and combinations thereof. The nodes 202a to 202n may communicate with each other via a network 206 such as a local area network, the Internet, or both. The nodes 202a to 202n may be part of a distributed computing environment (e.g., a cloud computing environment or a computing cluster). Each of the nodes 202a to 202n may execute rule engine services 204a to 204n, which are configured to perform at least some of the above-described rule matching. The rule engine services 204a to 204n may be any suitable type of software service, such as a microservice or a serverless function. The rule engine services 204a to 204n may each access a rule database 108, retrieve one or more rule definitions from the rule database 108, and store the rule definitions in the local memory of the corresponding node. Examples of local memory may be RAM or a cache. Storing the rule definitions in local memory may allow the nodes 202a to 202n to avoid repeatedly fetching the same rule definitions, thereby reducing bandwidth consumption and latency in the system.

[0037] The rule definitions may be divided and distributed among the nodes 202a to 202n such that, for example, each of the nodes 202a to 202n may process a substantially equal number of rule definitions. This may help achieve load balancing among the nodes 202a to 202n. Since each rule definition may be applied independently of other rule definitions, the nodes 202a to 202n are able to process user data in parallel to achieve increased speed. Depending on the amount of user data and the amount of rule definitions, the number of nodes 202a to 202n may be dynamically and automatically scaled up or down to meet the demand.

[0038] In some examples, user data may be stored in a queue 208 for evaluation. An example of the queue 208 may be an Apache queue. The queue may be a first-in-first-out queue or another type of queue. The rule engine 106 may organize user data in one or more queues. The rule engine 106 may automatically and dynamically scale the number of queues based on the amount and type of user data to be evaluated.

[0039] The rule engine services 204a through 204n can work together to retrieve user data from the queue(s) 208, partition and process the user data, and perform any actions triggered by the matching rules. In some examples, a node 202a (e.g., its rule engine service 204a) can retrieve user data from the queue 208, determine that the user data does not correspond to any of the rule definitions stored in its local memory, and transmit the user data to another node 202b that may have one or more rules associated with the user data. For example, the first node 202a can store all the rules related to a first entity, and the second node 202b can store all the rules related to a second entity. If the user data pertains to the second entity and not the first entity, the node 202a can skip the evaluation process and forward the user data to the second node 202b for evaluation. Alternatively, if the user data pertains to both the second entity and the first entity, the node 202a can perform its evaluation process and then forward the user data to the second node 202b for additional evaluation. In this way, the nodes 202a through 202n can pass user data between each other for evaluation as needed.

[0040] Turning now to Figure 3 , an example of a graphical user interface 112 for adding a new rule to the rule database 108 is shown in accordance with some aspects of the present disclosure. This example is intended to be illustrative and not restrictive. Other examples may include more graphical features, fewer graphical features, different graphical features, or different configurations of graphical features as compared to those shown in Figure 3 .

[0041] As shown, the graphical user interface 112 can include a first graphical element 304 (e.g., a button) that can be selected to add a new conditional field 302 to the form. The user can select the first graphical element 304 any number of times to add any number of conditional fields 302 to the form. Each time the first graphical element 304 is selected, the graphical user interface 112 can dynamically add another conditional field 302 to the form.

[0042] In this example, there are seven condition fields corresponding to the seven conditions of a single rule. The seven conditions are of different types - the first condition is a date range condition, the second condition is a time condition, the third condition is an entity condition, the fourth condition is a market offering condition, the fifth condition is a first user attribute condition, the sixth condition is a second user attribute condition, and the seventh condition is an account attribute condition. Alternatively, depending on the user's selection from a drop-down menu, other examples can involve more, fewer, or different types of conditions. For each condition field, the user can select the condition type from a drop-down menu of available condition types and enter the corresponding condition parameters. The form can also include radio buttons for selecting the binary operator ("and" or "or") associated with the condition field pair. The user can also rearrange the order of the condition fields, for example, by dragging a condition field to a new sequence. If the user accidentally adds a condition field or wants to remove a condition field, the user can select the delete button 310 to remove the corresponding condition field from the form.

[0043] The graphical user interface 112 can also include a second graphical element 308 that can be selected to add a new action field to the form. The user can select the second graphical element 308 any number of times to add any number of action fields 306 to the form. Whenever the second graphical element 308 is selected, the graphical user interface 112 can dynamically add another action field 306 to the form.

[0044] In this example, there are two action fields corresponding to the two actions of a single rule. The two actions are of different types - the first action is a points increase action, and the second action is an account upgrade action. Alternatively, depending on the user's selection from a drop-down menu, other examples can involve more, fewer, or different types of actions. For each action field, the user can select the action type from a drop-down menu of available action types and enter the corresponding action parameters. The user can also rearrange the order of the action fields, for example, by dragging an action field to a new sequence. This can control the order in which the rule engine executes the actions. If the user accidentally adds an action field or wants to remove an action field, the user can select the delete button 312 to remove the corresponding action field from the form.

[0045] Once the user makes a selection, the user can select the submit button 310 to submit the rule parameters (e.g., conditions and actions) to the rule engine. The rule engine can then convert the rule parameters into a rule definition and store the rule definition in the rule database. The rule engine can then apply the rule definition against the user data to determine whether the user data matches the rule.

[0046] As previously described, rules can relate to specific entities. For example, condition 3 of the graphical user interface 112 requires that the interaction involve a specific entity to match the rule. In some such examples, the rule engine can apply the rule only if the user's online account is linked to another online account associated with that entity. This can help reduce the total number of rules applied. The following refers to Figures 4A to 4B an example of a process for linking online accounts. Of course, other examples can involve more steps, fewer steps, different steps, or a different order of steps compared to those shown in Figures 4A to 4B .

[0047] Now referring to Figure 4A , a sequence diagram showing an example of a process for linking a first online account and a second online account is shown. The process can start at step 1, where the client device 116 transmits a first set of login credentials to the first computer system 102 to log in to a first online account hosted by a first entity. The first set of login credentials can include one or more login credentials. Examples of such login credentials can include a username, password, biometric marker, PIN code, or any combination thereof. The first set of login credentials may have been previously selected by the user, such as when registering the first online account. At step 2, the first computer system 102 can verify the first set of login credentials. If the first set of login credentials is valid, then at step 3, the first computer system 102 can transmit a first authentication approval to the client device 116.

[0048] At step 4, the client device 116 can transmit a request to link the first online account to a second online account of the user, where the second online account is hosted by a second entity. At step 5, the first computer system 102 can present a login page for the second online account to the client device 116. The login page can be used to receive a second set of login credentials for accessing the second online account. The second set of login credentials can include one or more login credentials, such as a username, password, biometric marker, PIN code, or any combination thereof. The second set of login credentials may have been previously selected by the user, such as when registering the second online account. At step 6, the client device 116 can transmit the second set of login credentials to the second computer system 130 hosting the second online account for accessing the second online account.

[0049] At step 7, the second computer system 130 may verify the second set of login credentials. If the second set of login credentials is valid, then at step 8, the second computer system 130 may transmit a second authentication approval to the client device 116. The second computer system 130 may also generate an authentication code and provide it to the client device 116. The authentication code may be a numeric code, an alphanumeric code, or another type of code generated using a code generator. The authentication code may be unique for a session initiated between the second computer system 130 and the client device 116.

[0050] At step 9, the client device 116 may provide the authentication code to the first computer system 102. At step 10, the first computer system 102 may receive the authentication code and forward it, along with the primary authentication credentials, to the second computer system 130. The primary authentication credentials may be different from the first set of login credentials and the second set of login credentials at least because the primary authentication credentials are not associated with a user. Instead, the primary authentication credentials are dedicated to the first computer system 102 for authentication with the second computer system 130. The primary authentication credentials may have been previously set by the first computer system 102 or the second computer system 130. Compared to the primary authentication credentials of the first computer system 102, the first set of login credentials and the second set of login credentials may be considered secondary authentication credentials.

[0051] At step 11, the second computer system 130 may verify the primary authentication credentials and the authentication code. If the primary authentication credentials and the authentication code are valid, then the second computer system 130 may generate an access token. The access token is different from the authentication code, the first set of login credentials, the second set of login credentials, and the primary authentication credentials. In some examples, the second computer system 130 may use a token generator to produce the access token, which may be different from the code generator used to generate the authentication code. At step 12, the second computer system 130 may transmit a third authentication approval, along with the access token, to the first computer system 102. Then, the process may continue as Figure 4B shown.

[0052] Now referring Figure 4B , at step 13, the first computer system 102 transmits the primary authentication credentials, the access token, and a request to link the first online account and the second online account. The second computer system 130 may receive the primary authentication credentials, the access token, and the request. At step 14, the second computer system 130 may verify the primary authentication credentials and the access token.

[0053] If they are valid, at step 15, the second computer system 130 may generate an external ID (exID). This external account identifier may be a unique identifier of a second online account generated by the second computer system 130, which is different from the internal account identifier used by the second computer system 130 to identify the second online account. The second computer system 130 may use the exID to refer to the second online account 130 when communicating with an external computing system such as the first computing system 102. This may prevent the second computer system 130 from exposing sensitive information, such as the internal account identifier, to other entities. At step 15, the second computer system 130 may also link the two accounts, for example, by storing a link between the two accounts in an account link data store.

[0054] At step 16, the second computer system 130 may transmit the user's exID to the first computer system 102. The first computer system 102 may receive and save the exID. At step 17, the first computer system 102 may also link the two accounts, for example, by storing a link between the two accounts in an account link data store.

[0055] Although Figures 4A to 4B the process shown involves linking two online accounts together, this process can be used to link any number and type of online accounts together. For example, the techniques described herein can be used to link a first online account to two or more other online accounts. And although in the above example the second computer system 130 generated the exID, in other examples, the first computer system 102 may generate the exID and provide it to the second computer system 130.

[0056] The process described above employs multi-layer authentication to enhance security - a first layer where the user authenticates the first computer system using a first set of login credentials; a second layer where the user authenticates the second computer system 130 using a second set of login credentials; and a third layer where the first computer system 102 authenticates the second computer system 130 using an authentication code and a primary authentication credential. The computer systems 102, 130 may also employ other security mechanisms, such as a list of authorized Internet Protocol (IP) addresses that are allowed to submit commands to their APIs. Such a multi-faceted security architecture may prevent malicious actors from abusing the system, for example, by requiring that all commands originate from an authorized IP address (which has been authenticated using the primary authentication credential).

[0057] Figures 5 to 8An example of a graphical user interface page for linking online accounts in accordance with some aspects of the present disclosure is shown. However, it should be understood that these examples are intended to be illustrative and not restrictive. In other examples, GUI 112 may have more pages, fewer pages, different pages, or a different order of pages than those shown. Also, each GUI page may have graphical elements different from those shown.

[0058] Referring now to Figure 5 , an example of a first GUI page 502 displayed on user device 132 is shown. The first GUI page 502 may be a login page through which a user can log in to a first online account. The user may enter their first set of login credentials into input boxes 504, 506. In this example, the first set of login credentials includes a username and a password. After entering the first set of login credentials, the user may press the login button 508 to access the first online account.

[0059] Once logged in, the user may choose to link the first online account to a second online account. The user can select the second online account via a second GUI page. Figure 6 An example of a second GUI page 602 is shown in

[0060] Figure 7 . As shown, the second GUI page 602 may include graphical objects representing various entities. Examples of graphical objects may include icons, logos, or text content representing various entities. Each entity may provide an online account that can be linked to the first online account. The second GUI page 602 may also indicate a total number of points 606 assigned to the first online account. Points may be added to or subtracted from the total number of points 606 by a rules engine based on various rules. The user may select a graphical object 604 corresponding to a target entity, at which point the GUI may transition to a third GUI page. Figure 8 An example of a fourth GUI page 802 is shown.

[0061] The combination of the above features can allow users to easily link their online accounts together and allow administrators to easily formulate rules to be applied to the linked accounts. Since if the online accounts are linked together, the rule engine can apply only certain rules, users can control to some extent which rules are applied by choosing which online accounts to link together. The result can be a flexible rule architecture that can be at least partially controlled by the user and at least partially controlled by the administrator.

[0062] Now turning to Figure 9 , a flowchart of an example of a process for providing a graphical user interface and a flexible architecture for a rule engine in accordance with some aspects of the present disclosure is shown. Other examples may involve more operations, fewer operations, different operations, or a different order of operations compared to Figure 9 that shown. The operations are described below with reference to the components of Figure 1 . Figure 9 .

[0063] At block 902, the computer system provides a graphical user interface 112 that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule. An example of the computer system can be Figure 1 the first computer system 102. The new rule can be a rule to be added to the rule database 108 and may not yet exist in the rule database 108.

[0064] At block 904, the computer system generates a new rule definition 120 based on the selected conditions and selected actions. The new rule definition 120 is a rule definition for the new rule. Generating the new rule definition can include converting the selected conditions and selected actions into the new rule definition 120. For example, the computing device can include a predefined rule template. The rule template can include pre-existing information and empty fields into which the selected conditions and selected actions can be inserted to produce the rule definition 120. In some examples, the rule definition 120 can be a string or an array that is configured to be quickly ingested and processed by the rule engine.

[0065] At block 906, the computer system stores the new rule definition 120 in the rule database 108. The rule database 108 can be internal or external to the computing device. The rule database 108 can include one or more other rule definitions 120 for one or more other rules, which may or may not have been created using the graphical user interface 112.

[0066] At block 908, a computer system (e.g., rules engine 106 executing on a computer system) selects at least one rule definition 120 from rule database 108. For example, the computer system may select a subset of rule definitions from among multiple rule definitions in the rule database. The selected subset of rule definitions may or may not include new rule definitions. The selected subset of rule definitions may correspond to a subset of rules. The computer system may then apply at least one rule to user data 122, which may correspond to a single user or multiple users.

[0067] The computer system may select at least one rule definition based on any number of factors and combinations thereof. For example, the computer system may select a subset of rule definitions based on the content of user data 122. In some such examples, user data 122 may relate to a transaction with a particular entity (e.g., first entity 104 or second entity 124), for which a corresponding set of rules may be stored in rule database 108. Based on user data 122 relating to that particular entity, the computer system may select the corresponding set of rule definitions from rule database 108. As another example, the computer system may select a subset of rule definitions based on which of a user's online accounts are linked. The computer system may select those rule definitions only when certain rule definitions are associated with the linked online accounts. As another example, certain rules may apply only to online accounts having certain attributes. Thus, the computer system may select a subset of rule definitions based on the attributes of a user's online accounts. As yet another example, certain rules may apply only to users having certain attributes. Thus, the computer system may select a subset of rule definitions based on the attributes of the users. Some or all of these may be implemented to intelligently reduce the total number of rules applied.

[0068] At block 910, the computer system issues a command configured to cause at least one action associated with at least one rule to be performed. The computer system may issue the command in response to determining that user data 122 matches at least one rule. In some examples, the computer system may issue a command to its own software to cause at least one action to be performed on the computer system. In other examples, the computer system may issue a command to a remote computing device to cause the remote computing device to perform at least one action. For example, the computer system may transmit the command over a network to the remote computing device to cause the remote computing device to perform at least one action. The at least one action may involve increasing or decreasing a total number of points 134 associated with an online account (such as first online account 128 or second online account 136).

[0069] Figure 10FIG. shows a block diagram of an example of a computing device 1000 that can be used to implement some aspects of the present disclosure. In some examples, the computing device 1000 can correspond to Figure 1 the first computer system 102, the second computer system 130, the client device 116, or the user device 132. Additionally or alternatively, the computing device can correspond to the computer systems described above with respect to Figure 9 . The computing device 1000 can include a server, a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable device, and the like.

[0070] The computing device 1000 includes a processor 1002 communicatively coupled to a memory 1004 via a bus 1006. The processor 1002 can include one or more processors. Examples of the processor 1002 can include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a microprocessor. The processor 1002 can execute instructions 1008 stored in the memory 1004 to perform operations, such as any of the operations described herein. The instructions 1008 can include processor-specific instructions generated by a compiler or interpreter from code written in any suitable computer programming language, such as C, C++, C#, Java, or Python.

[0071] The memory 1004 can include one or more memory devices. The memory 1004 can be volatile or non-volatile (which can retain stored information when power is removed). Examples of the memory 1004 can include electrically erasable programmable read-only memory (EEPROM), flash memory, or cache memory. At least some of the memory 1004 includes a non-transitory computer-readable medium from which the processor 1002 can read the instructions 1008. The computer-readable medium can include an electronic, optical, magnetic, or other storage device capable of providing the instructions 1008 or other program code to the processor 1002. Examples of the computer-readable medium include a magnetic disk, a memory chip, a ROM, a random access memory (RAM), an ASIC, a configured processor, and an optical storage device.

[0072] The computing device 1000 further includes an input component. An example of the input component can include a user input device 1010, which can include one or more user input devices. Examples of such user input devices can include a mouse, a keyboard, a touchpad, and a touchscreen display. Another example of the input component can include a sensor 1012, which can include one or more sensors. Examples of such sensors can include a GPS unit, a gyroscope, an accelerometer, an inclinometer, and a camera.

[0073] The computing device 1000 also includes an output component. An example of an output component may include a display 1014, which may include one or more displays. Examples of such displays may include a liquid crystal display (LCD) or a light emitting diode (LED) display. The computing device 1000 may also include an audio output component such as a speaker, a haptic output component such as a haptic actuator, or another type of output component. However, for simplicity, these other output components are not shown in Figure 10 the figure.

[0074] Although Figure 10 the various components (e.g., the processor 1002, the memory 1004, the user input device 1010, and the display 1014) are depicted inside a single housing, in other examples, the components may be distributed and communicate with each other either wired or wirelessly. For example, the display 1014 may be a computer monitor that is separate from and communicates with the computing device 1000 that performs the main processing. And although Figure 10 a certain number of components and their arrangement are depicted, this is for illustrative purposes and not intended to be limiting. Other examples may include more components, fewer components, different components, or Figure 10 a different arrangement of the components shown.

[0075] The above description of certain examples, including the examples shown, is presented for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Modifications, adaptations, and uses thereof will be apparent to those skilled in the art without departing from the scope of the disclosure. For example, any of the examples described herein may be combined with any other example.

Claims

1. A non - transitory computer - readable medium, the non - transitory computer - readable medium including program code that can be executed by one or more processors to cause the one or more processors to perform operations, the operations including: Providing a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule; Generating a new rule definition for the new rule based on the selected conditions and the selected actions; Storing the new rule definition in a rule database that includes multiple rule definitions for multiple rules; Executing a rule engine that is configured to: Select a subset of rule definitions from the multiple rule definitions in the rule database, where the subset of rule definitions includes the new rule definition, and where the subset of rule definitions corresponds to a subset of rules among the multiple rules; and Applying the subset of rule definitions to user data to determine whether the user data matches the subset of rules; and In response to determining that the user data matches at least one rule in the subset of rules, issuing a command to cause at least one action associated with the at least one rule to be executed.

2. The non-transitory computer-readable medium according to claim 1, wherein, The at least one action includes adjusting a total number of points associated with the user's account.

3. The non-transitory computer-readable medium according to claim 2, wherein, The account is hosted on a computer system of a first entity, the user data describes an interaction between the user and a second entity different from the first entity, and the non - transitory computer - readable medium further includes program code that can be executed by the one or more processors to cause the one or more processors to: receive the user data from the second entity in a data communication via a network.

4. The non - transitory computer - readable medium according to claim 3, further including program code that can be executed by the one or more processors to cause the one or more processors to: Receive the selected conditions and the selected actions from the first entity.

5. The non - transitory computer - readable medium according to claim 3, further including program code that can be executed by the one or more processors to cause the one or more processors to: Receive at least one rule among the multiple rules from the second entity.

6. The non - transitory computer - readable medium according to claim 3, further including program code that can be executed by the one or more processors to cause the one or more processors to: Select the subset of rule definitions from the multiple rule definitions in the rule database based on the subset of rules associated with the second entity.

7. The non-transitory computer-readable medium according to claim 2, wherein, Adjusting the total number of points includes increasing the total number of points by a predetermined amount.

8. The non-transitory computer-readable medium according to claim 2, wherein Adjusting the total number of points includes decreasing the total number of points by a predetermined amount.

9. The non - transitory computer - readable medium according to claim 1, further including program code that can be executed by the one or more processors to cause the one or more processors: Receiving, from the rules engine, an output indicating that the user data matches at least two rules in a subset of the rules, the at least two rules being associated with at least two actions; Determining a preferred execution sequence that defines an order in which the at least two actions will be executed, based on a predefined priority scheme; And Executing the preferred execution sequence.

10. A method, comprising: Providing, by one or more processors, a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule; Generating, by the one or more processors, a new rule definition for the new rule based on the selected conditions and the selected actions; Storing, by the one or more processors, the new rule definition in a rule database that includes multiple rule definitions for multiple rules; Executing, by the one or more processors, a rules engine that is configured to: Select a subset of rule definitions from the multiple rule definitions in the rule database, wherein the subset of rule definitions includes the new rule definition, and wherein the subset of rule definitions corresponds to a subset of rules among the multiple rules; and Applying the subset of rule definitions to user data to determine whether the user data matches the subset of rules; and In response to determining that the user data matches at least one rule in the subset of rules, issuing, by the one or more processors, a command to cause at least one action associated with the at least one rule to be executed.

11. The method according to claim 10, wherein, The at least one action includes adjusting a total number of points associated with the user's account.

12. The method according to claim 11, wherein The account is hosted on a computer system of a first entity, the user data describes an interaction between the user and a second entity different from the first entity, and the method further includes: receiving the user data from the second entity in a data communication via a network.

13. The method according to claim 12, further comprising: Receiving the selected conditions and the selected actions from the first entity.

14. The method according to claim 12, further comprising: Receiving at least one rule among the multiple rules from the second entity.

15. The method according to claim 12, further comprising: Selecting the subset of rule definitions from the multiple rule definitions in the rule database based on the subset of rules associated with the second entity.

16. The method according to claim 12, wherein, The account is a first account, and the method further includes: Determining that the user's first account with respect to the first entity is linked to the user's second account with respect to the second entity; and In response to determining that the first account is linked to the second account, selecting the subset of rule definitions from the rule database based on the subset of rules associated with the second entity in the rule database.

17. The method according to claim 11, wherein Adjusting the total number of points includes increasing the total number of points by a predetermined amount.

18. The method according to claim 11, wherein Adjusting the total number of points includes decreasing the total number of points by a predetermined amount.

19. The method according to claim 10, further comprising: Receive, from the rules engine, an output indicating that the user data matches at least two rules in a subset of the rules, the at least two rules being associated with at least two actions; Determine that the at least two actions conflict with each other; And Based on determining that the at least two actions conflict with each other, perform a first one of the at least two actions and ignore a second one of the at least two actions.

20. A system, comprising: One or more processors; And One or more memories, the one or more memories including instructions executable by the one or more processors to cause the one or more processors to perform operations, the operations including: Provide a graphical user interface that includes a set of graphical input elements for receiving selected conditions and selected actions for a new rule; Generate, based on the selected conditions and the selected actions, a new rule definition for the new rule; Store the new rule definition in a rule database that includes multiple rule definitions for multiple rules; Select a subset of rule definitions from the multiple rule definitions in the rule database, wherein the subset of rule definitions includes the new rule definition, and wherein the subset of rule definitions corresponds to a subset of rules among the multiple rules; and Apply the subset of rule definitions to user data to determine whether the user data matches the subset of rules; and In response to determining that the user data matches at least one rule in the subset of rules, issue a command to cause at least one action associated with the at least one rule to be performed.

Images