HIERARCHICALLY APPLIED RULES ENGINE ("HARE")

• US 20100063903A1
• Filed: 03/09/2009
• Published: 03/11/2010
• Est. Priority Date: 03/10/2008
• Status: Abandoned Application

• Current Assignee: David Taylor, Pamela F. Galligan, Thayne Whipple
• Original Assignee: David Taylor, Pamela F. Galligan, Thayne Whipple
• Inventors: Taylor, David, Whipple, Thayne, Galligan, Pamela F.
• Application Number:
  US12/400,514
• Publication Number:
  US 20100063903A1
• Time in Patent Office: Days
• US Class Current: 705/30
• CPC Class Codes: G06F 16/24564 Applying rules; Deductive queries
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 20/405 Establishing or using transaction specific rules
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03
• CPC Class Codes: G06Q 40/12 Accounting

Abstract

An electronic transaction decision module is provided that includes a dynamic rules engine, processing system and interfaces to enable various participants in an electronic payment environment to establish and modify the rules, condition values, fees and rewards associated with electronic transactions. Participants in electronic financial or other economic transactions are authorized and enabled to define multiple rules, condition values, fees and rewards within which they either authorize or deny the consummation of a financial transaction and define its impact upon various participants, and to dynamically and efficiently modify those rules, condition values, fees and rewards when desired. Rules, condition values, fees and rewards may be set and evaluated hierarchically based on the participant'"'"'s relative authority with respect to each attribute. Embodiments of the invention enable the rapid deployment and real-time management of card and mobile payment programs and provide access to card program functions not only by card issuers and program managers, but also by individual cardholders.

Claims

1. A computerized electronic transaction processing system for processing a requested transaction that involves a plurality of participants, comprising:

a database management system including a database in which data records can be stored and retrieved;

a transaction module for receiving a request for an electronic transaction in a standardized message format from a banking association network, and wherein said transaction module is configured to interact with a transaction database to verify account information, parse said request into parsed data components, input said parsed data components into a record in said database, and communicate the identity of said database record;

a decision module for receiving from said transaction module the identity of said database record associated with said request, said decision module configured to channel all communication with said banking association network through the transaction module, and wherein said decision module is configured to access said identified database record and to retrieve rules and associated conditions and condition values from said transaction database related to said requested transaction and to apply said rules, conditions and condition values to generate a result that relates to an approval or disapproval decision concerning said requested transaction; and

wherein said decision module is further configured to determine one or more response codes applicable to said approval or disapproval decision concerning said requested transaction;

a first interface mechanism associated with said decision module for communicating said one or more response codes applicable to said approval or disapproval decision to said transaction module; and

at least one additional interface mechanism associated with said decision module for communicating with at least one of said plurality of participants to enable said at least one participant to said input rules, conditions and condition values into said transaction database for use by said decision module.

2. The electronic transaction processing system of claim 1, wherein

said a requested transaction can have one or more rules applicable to said approval or disapproval decision;

said rules are adapted to be able to have one or more conditions associated with each rule; and

said conditions are adapted to be able to have one or more condition values associated with each condition.

3. The electronic transaction processing system of claim 2, wherein more than one participant can input conditions or condition values relating to the same rule, and wherein a hierarchical relationship is defined with respect to at least some of said plurality of participants for at least some of said conditions and rules to establish levels of authority among said plurality of a participants for inputting or modifying said condition values, conditions and rules;

wherein an electronic security mechanism is associated with said at least one additional interface mechanism for authenticating a participant attempting to access said at least one transaction database; and

wherein said decision module further comprises;

business logic for accessing said transaction database in response to a requested transaction to retrieve information defining the hierarchical relationship between each participant that inputted or modified any of said identified and retrieved conditions, condition values and rules related to said requested transaction; and

business logic for electronically applying said retrieved rules to said retrieved condition values in accordance with said hierarchical relationship between participants to determine whether to approve or disapprove said requested transaction.

4. The electronic transaction processing system of claim 3, further comprising:

business logic for accessing said transaction database in response to a participant attempting to input or modify a rule, condition or condition value in said transaction database, to retrieve information defining the hierarchical relationship between each participant that inputted or modified said rules, conditions and condition values; and

business logic for validating the propriety of a rule, condition or condition value being input or modified by a participant in accordance with said hierarchical relationship between participants.

5. The electronic transaction processing system of claim 3, wherein said at least one additional interface mechanism is able to input or modify rules, conditions and condition values in real time, whereby said business logic for electronically applying retrieved conditions, condition values and rules is able to apply a newly inputted or modified rule, condition or condition value to a requested transaction promptly after it is introduced into said transaction database.

6. The electronic transaction processing system of claim 1, wherein said conditions comprise one or more of the following:

account balance, account limits, transaction limits, account type, customer identity, geographic location of customer, geographic location of merchant, date, time of day, IP address of participant, category or identity of electronic shopping cart, transaction routing, distribution of funds, and settlement terms.

7. The electronic transaction processing system of claim 1, further comprising:

a set of rules established in said transaction database by one or more of said participants relating to fees to be incurred and earned as a result of a requested transaction.

8. The electronic transaction processing system of claim 6, wherein said fees comprise one or more of the following:

transaction fees, issuance fees, periodic fees, inactivity fees, load fees, interest rates, card replacement fees, fund transfer fees, and revenue sharing.

9. The electronic transaction processing system of claim 1, further comprising:

a set of rules established in said transaction database by one or more of said participants relating to customer or merchant rewards to be earned as a result of a requested transaction.

10. The electronic transaction processing system of claim 1, wherein said transaction database maintains auditable records of each requested transaction and the results of applying said business logic to said retrieved rules, conditions and condition values.

11. A method of operating an electronic transaction processing system involving a plurality of participants, comprising:

establishing at least one database for storing electronic data relating to said participants and condition values and rules relating to electronic transactions;

providing an interface mechanism for at least a plurality of said participants that enables each of said plurality of participants to electronically interact with said at least one database to input or modify condition values and rules in said database;

assigning an authorization level to selected ones of said participants to define a participant'"'"'s ability to input or modify condition values and rules in said at least one database;

authenticating a participant attempting to access said at least one database to determine said participant'"'"'s authorization level;

receiving an electronic message including information relating to a requested transaction;

directing said electronic message to a decision module for deciding whether a requested transaction should be permitted to proceed to completion;

applying business logic in said decision module to access condition values and rules from said at least one database;

applying business logic in said decision module to electronically analyze authorization levels of participants to said requested transaction; and

applying business logic in said decision module to electronically analyze condition values and rules from said first set of rules in response to receipt of said electronic message and consistent with the authorization level of each participant that inputted or modified said condition values and rules, to determine whether said requested transaction should be permitted to proceed to completion.

12. The method as set forth in claim 11 wherein said interface mechanism is able to input or modify condition values and rules in real time, whereby said business logic for electronically applying retrieved condition values and rules is able to apply a newly inputted or modified condition value or rule promptly after it is introduced into said at least one database.

13. The method as set forth in claim 11 wherein said set of condition values comprises one or more of the following:

account balance, account limits, transaction limits, account type, customer identity, geographic location of customer, geographic location of merchant, date, time of day, IP address of participant, category or identity of electronic shopping cart, transaction routing, distribution of funds, and settlement terms.

14. The method as set forth in claim 11 further comprising:

establishing a set of rules in said at least one database by one or more of said participants relating to fees to be incurred and earned as a result of a requested transaction.

15. The method as set forth in claim 14 wherein said fees comprise one or more of the following:

transaction fees, issuance fees, periodic fees, inactivity fees, load fees, interest rates, card replacement, fund transfer fees, and revenue sharing.

16. The method as set forth in claim 11 further comprising:

establishing a set of rules in said at least one database by one or more of said participants relating to customer or merchant rewards to be earned as a result of a requested transaction.

17. The method as set forth in claim 11 wherein more than one participant can input condition values relating to the same rule in said set of rules and wherein said decision module further comprises:

establishing a hierarchical relationship for condition values input by different participants relating to the same rule;

executing business logic to apply said same rule in a manner consistent with said hierarchical relationship.

18. The method as set forth in claim 11 wherein said database maintains auditable records of each requested transaction and the results of applying said business logic to said retrieved condition values and rules.

19. A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for operating an electronic transaction processing system involving a plurality of participants, the method comprising:

establishing at least one database for storing electronic data relating to said participants and condition values and rules relating to electronic transactions;

providing an interface mechanism for at least a plurality of said participants that enables each of said plurality of participants to electronically interact with said at least one database to input or modify condition values and rules in said database;

assigning an authorization level to selected ones of said participants to define a participant'"'"'s ability to input or modify condition values and rules in said at least one database;

authenticating a participant attempting to access said at least one database to determine said participant'"'"'s authorization level;

receiving an electronic message including information relating to a requested transaction;

directing said electronic message to a decision module for deciding whether a requested transaction should be permitted to proceed to completion;

applying business logic in said decision module to access condition values and rules from said at least one database;

applying business logic in said decision module to electronically analyze authorization levels of participants to said requested transaction; and

applying business logic in said decision module to electronically analyze condition values and rules from said first set of rules in response to receipt of said electronic message and consistent with authorization level of each participant that inputted or modified said condition values and rules, to determine whether said requested transaction should be permitted to proceed to completion.

20. The method as set forth in claim 19 wherein said interface mechanism is able to input or modify condition values and rules in real time, whereby said business logic for electronically applying retrieved condition values and rules is able to apply a newly inputted or modified condition value or rule promptly after it is introduced into said at least one database.

21. The method as set forth in claim 19 wherein said set of condition values comprises one or more of the following:

account balance, account limits, transaction limits, account type, customer identity, geographic location of customer, geographic location of merchant, date, time of day, IP address of participant, category or identity of electronic shopping cart, transaction routing, distribution of funds, and settlement terms.

22. The method as set forth in claim 19 further comprising:

establishing a set of rules in said at least one database by one or more of said participants relating to fees to be incurred and earned as a result of a requested transaction.

23. The method as set forth in claim 22 wherein said fees comprise one or more of the following:

transaction fees, issuance fees, periodic fees, inactivity fees, load fees, interest rates, card replacement, fund transfer fees, and revenue sharing.

24. The method as set forth in claim 19 further comprising:

establishing a set of rules in said at least one database by one or more of said participants relating to customer or merchant rewards to be earned as a result of a requested transaction.

25. The method as set forth in claim 19 wherein more than one participant can input condition values relating to the same rule in said set of rules and wherein said decision module further comprises:

establishing a hierarchical relationship for condition values input by different participants relating to the same rule;

executing business logic to apply said same rule in a manner consistent with said hierarchical relationship.

26. The method as set forth in claim 19 wherein said database maintains auditable records of each requested transaction and the results of applying said business logic to said retrieved condition values and rules.