Abstract:
There is provided, in one embodiment, a computer implemented method, for providing transaction oriented conflict resolution for an electronic commerce application. The computer implemented method comprising obtaining one or more promotions each having at least one associated policy and creating a context object containing a plurality of objects indicative of an initial state of the system at the time the transaction began. Next is created a control object containing clones of the plurality of objects contained within the context object. Application of the one or more promotions is then made to the created control object. Afterward there is a check for violation of the at least one policy associated with the respective one or more promotions and where no violation has been found then committing the promotion. If a violation was found then the system would be rolled back to a state indicated by the context object and the transaction would end.

Description:
FIELD OF THE INVENTION  
       [0001]     This present invention relates generally to conflict resolution and more specifically to promotion conflict resolution using a transaction oriented technique in electronic commerce environments.  
       BACKGROUND OF THE INVENTION  
       [0002]     Promotion may be defined as a shopping related incentive offered to general or specific customers in order to entice them to make purchases in a store. The promotions, representing the incentives, may be realized through or in conjunction with different marketing reward programs such as price or service discounts, free gifts, coupon, or bonus points in a loyalty program. Promotions play an increasingly more important role in modern retailing. As a result, at any given time, there are usually a large number of promotions in effect in a commerce system. The applicability and combinations of these various promotions is also becoming more and more complex. The process to determine applicability and combinations of various promotions is often referred to as a conflict resolution process in a commerce system. This process is used to determine, in situations where more than one promotion is applicable at the same time, which one or more than one should be applied and in what order, and which ones should not. This problem is further complicated by the situation where most merchants&#39; operating systems that offer promotions to their clients have very different ways of determining the applicability and combinations of promotions. Most commercial systems either provide very little help to address this problem or implement a fixed way of support. Modifying or extending such a system to incorporate any new or slightly different conflict resolution logic is usually a very difficult task.  
         [0003]     Previous instances of using promotions in commerce systems have had a scattered focus that has produced a wide variation in results. In some cases the promotion was non-discriminatory and was displayed to any casual user who happened by the display device. In another example a simple aggregation of a promotion was performed on a single site without mention of any explanation of how to evaluate applicability of the promotion to specific user. Other means of linking a coupon code to a history of purchases retained in a storage means have been tried as well. Capture and use of such history information has been then used previously to determine advertising presentation but not to address determination of promotion allocation. In still another situation much emphasis has been placed on the shopper history or profile without any means of further determining promotions or discounts. Some cases have also dealt with conflict resolution but those have been limited to the area of storage allocation techniques.  
         [0004]     Conflict resolution is therefore very important part of any promotion system. Conflict resolution can be used to detect if any business policies are violated by application of a particular promotion. This conflict resolution process may be a complex process. In the process, multiple policies need to be tested to determine if any policies are violated. In order to determine whether a violation will arise by applying a promotion, the policies need to determine the types of changes caused by applying the promotion to the system, i.e. the “after state”. However, if the changes are made directly to the system, problems may occur when one or more policies determine a violation would have occurred if this promotion were applied. When that such a determination is made, the promotion is eliminated and the “before state” of the system needs to be restored. That may not always possible if the state of the system has been changed permanently. An alternative would be to let an individual policy determine what the effect of applying a promotion is by combining the “before state” of the system with the changes introduced by way of applying a promotion. This process would then become part of a policy&#39;s conflict detection logic. The disadvantage of this approach is that it would elevate the complexity of promotion policies.  
         [0005]     It would therefore be highly desirable to have a capability of reducing the complexity of promotion policies and having a more efficient conflict resolution mechanism.  
       SUMMARY OF THE INVENTION  
       [0006]     Conveniently, software exemplary of an embodiment of the present invention provides a capability for promotion policies to detect conflicts given a state of the system, and how to compute the effects on the system of applying a promotion. In addition, the implementation of policies may also be capable of combining the state of the system with the projected impact from applying a promotion so that the “before state” of the system is preserved and “after state” can be computed.  
         [0007]     Inspired by the transaction model in RDBMS (Relational Database Management System), a technique was devised mimicking a database transaction concept for use in the context of a promotion conflict resolution. As a result, the technique is not only able to preserve the “before state” of the system, but also able to alleviate individual policies from the task of computing the “after state”, all with reasonable efficiency.  
         [0008]     Using the analogy from RDBMS, the process of conflict detection is viewed as a single transaction. The effect of applying a promotion is computed within the context of the transaction, the application of each individual policy is performed within the same transaction after the promotion is tentatively applied. If application of any policy should report a violation, the transaction is deemed to have failed, and all its changes will be rolled back. If no application of policies report any violation, the transaction is deemed successful, and the changes will be committed. That is the promotion will be applied and the “after state” will become the new “before state”.  
         [0009]     This technique may make it possible for the system to preserve the “before state” and at the same time compute the “after state” once for all policies. Application of policies are spared the task of computing the after state themselves and are simplified to a point where all they need to do is to report any violations given a state of the system.  
         [0010]     In one embodiment of the present invention there is provided a computer implemented method for providing transaction oriented conflict resolution for an electronic commerce application, the computer implemented method comprising: obtaining one or more promotions each having at least one associated policy; creating a context object containing a plurality of objects indicative of an initial state; creating a control object containing clones of the plurality of objects contained within the context object; applying the one or more promotions to the control object; checking for violation of the at least one policy associated with the respective one or more promotions and where none is found committing the promotion; otherwise rolling back to a state indicated by the context object and ending the transaction.  
         [0011]     In another embodiment of the present invention there is provided a computer system for providing transaction oriented conflict resolution for an electronic commerce application, the computer system comprising: means for obtaining one or more promotions each having at least one associated policy; means for creating a context object containing a plurality of objects indicative of an initial state; means for creating a control object containing clones of the plurality of objects contained within the context object; means for applying the one or more promotions to the control object; means for checking for violation of the at least one policy associated with the respective one or more promotions and where none is found committing the promotion; otherwise rolling back to a state indicated by the context object and ending the transaction.  
         [0012]     In yet another embodiment of the present invention there is provided an article of manufacture for directing a data processing system to provide transaction oriented conflict resolution for an electronic commerce application, the article of manufacture comprising: a computer usable medium embodying one or more instructions executable by the data processing system, the one or more instructions comprising: data processing system executable instructions for obtaining one or more promotions each having at least one associated policy; data processing system executable instructions for creating a context object containing a plurality of objects indicative of an initial state; data processing system executable instructions for creating a control object containing clones of the plurality of objects contained within the context object; data processing system executable instructions for applying the one or more promotions to the control object; data processing system executable instructions for checking for violation of the at least one policy associated with the respective one or more promotions and where none is found committing the promotion; otherwise rolling back to a state indicated by the context object and ending the transaction.  
         [0013]     Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]     In the figures, which illustrate embodiments of the present invention by example only,  
         [0015]      FIG. 1  is a block diagram of a system in which an embodiment of the invention may be implemented;  
         [0016]      FIG. 2   a  is a block diagram showing example relationships between policies and promotions of an embodiment of the invention of  FIG. 1 ;  
         [0017]      FIG. 2   b  is a tabular view of sample of a promotion execution agenda of promotion and policy relationships of  FIG. 2 ;  
         [0018]      FIG. 3  is a block diagram of classes in support of the sample table of  FIG. 2 ;  
         [0019]      FIG. 4  is a flowchart showing an example of an evaluation process of an embodiment of the invention of  FIG. 1 ;  
         [0020]      FIG. 5  is a flowchart showing an example of a variant of the promotion evaluation process of  FIG. 4 . 
     
    
       [0021]     Like reference numerals refer to corresponding components and steps throughout the drawings.  
       DETAILED DESCRIPTION  
       [0022]      FIG. 1  depicts, in a simplified block diagram, a computer system  100  suitable for implementing embodiments of the present invention. Computer system  100  has a central processing unit (CPU)  110 , which is a programmable processor for executing programmed instructions stored in memory  108 . Memory  108  can also include hard disk, tape or other storage media. While a single CPU is depicted in  FIG. 1 , it is understood that other forms of computer systems can be used to implement the invention, including multiple CPUs. It is also appreciated that the present invention can be implemented in a distributed computing environment having a plurality of computers communicating via a suitable network  119 , such as the Internet.  
         [0023]     CPU  110  is connected to memory  108  either through a dedicated system bus  105  and/or a general system bus  106 . Memory  108  can be a random access semiconductor memory for containing components such as table  315 , code to implement elements of  FIG. 3  and the processes of  FIGS. 4 and 5 . Similarly such components may also reside on storage device  144  until required for use. Memory  108  is depicted conceptually as a single monolithic entity but it is well known that memory  108  can be arranged in a hierarchy of caches and other memory devices.  FIG. 1  illustrates that operating system  120 , may reside in memory  108 .  
         [0024]     Operating system  120  provides functions such as device interfaces, memory management, multiple task management, and the like as known in the art. CPU  110  can be suitably programmed to read, load, and execute instructions of operating system  120 , build components of  FIG. 3 , and load table  315 . Computer system  100  has the necessary subsystems and functional components to implement transaction oriented conflict resolution as will be discussed later. Other programs (not shown) include server software applications in which network adapter  118  interacts with the server software application to enable computer system  100  to function as a network server via network  119 .  
         [0025]     General system bus  106  supports transfer of data, commands, and other information between various subsystems of computer system  100 . While shown in simplified form as a single bus, bus  106  can be structured as multiple buses arranged in hierarchical form. Display adapter  114  supports video display device  115 , which is a cathode-ray tube display or a display based upon other suitable display technology that may be used to depict data. The Input/output adapter  112  supports devices suited for input and output, such as keyboard or mouse device  113 , and a disk drive unit (not shown). Storage adapter  142  supports one or more data storage devices  144 , which could include a magnetic hard disk drive or CD-ROM drive although other types of data storage devices can be used, including removable media for storing components such as relationship table  315 , and other objects from the build operations of  FIG. 3 , such as sequence vector  335 .  
         [0026]     Adapter  117  is used for operationally connecting many types of peripheral computing devices to computer system  100  via bus  106 , such as printers, bus adapters, and other computers using one or more protocols including Token Ring, LAN connections, as known in the art. Network adapter  118  provides a physical interface to a suitable network  119 , such as the Internet. Network adapter  118  includes a modem that can be connected to a telephone line for accessing network  119 . Computer system  100  can be connected to another network server via a local area network using an appropriate network protocol and the network server can in turn be connected to the Internet.  FIG. 1  is intended as an exemplary representation of computer system  100  by which embodiments of the present invention can be implemented. It is understood that in other computer systems, many variations in system configuration are possible in addition to those mentioned here.  
         [0027]     The fundamental problem to be resolved is to find an efficient way to determine if one or more of the applicable promotions from a plurality of promotions are all deemed to be suitable. In attempting to resolve this problem a transaction oriented approach is used to first “test” the application of a promotion and then only if acceptable, commit the resulting changes, thereby safeguarding the system from undesired changes. The transaction oriented technique begins with defining the possible changes the application of a promotion can have on the system, as well as any side effects of applying a promotion&#39;s policies. Currently, a list of possible effects may include the following (this list is not meant to be exhaustive and typically grows with use as the system is being improved) when a promotion is applied: 
        a certain product may no longer be eligible for other promotions     certain monetary values may be changed as a result. For example, the price of an item may be discounted by 20%, or it may be shipped for free     certain other promotions may no longer be applied        
 
         [0031]     The process of promotion conflict resolution can be described as a 3 step process: 1) Determining applicable promotions from a plurality of potentially applicable promotions, and at the same time determining if these selected promotions are subject to any business policies and applying those policies in the form of conflict resolution; 2) Determining the sequence in which the applicability of the promotions selected in the first step should be tested; and 3) In the situation of one or more promotions being applicable, determining if by applying these promotions a conflict situation would arise.  
         [0032]     To fulfil the tasks above, the system organizes promotions into promotion groups and associating promotions with promotion policies that are applicable to them by means of creating a relationship table. It also uses object technology to externalize the process of determining the list of promotions that should be attempted, as well as in which sequence they should be attempted and creates a simple sequence vector of desired promotions. The system also defines a standard interface for business policies so that any additional policies can be added easily into the system. The end result of these efforts is a process that is more flexible and much easier to be extended than a traditional conflict resolution process.  
         [0033]     Terminology used in this section: includes the following terms:  
         [0034]     Promotion: a marketing/merchandising incentive which has conditions that need to be satisfied and offers rewards such as discounts and/or gifts.  
         [0035]     Promotion Group: a mechanism to organize promotions in to clusters. Promotions in the same group shares similar characteristics such as offering similar types of rewards, and having similar limitations.  
         [0036]     Promotion Policy: abstraction of business policies that govern the applicability and combinability of promotions.  
         [0037]     Priority: the importance of promotions, usually determines the order in which two otherwise equal promotions should be attempted, and 
        Invocation template: a preconfigured set of a number of promotion groups in a given order. Callers of a promotion system will specify an invocation template to use, and the system will identify the list of promotions within the set to attempt.        
 
         [0039]     Conflict resolution: determine a relationship between a plurality of situations with constraints and select a solution.  
         [0040]     Referring to  FIG. 2A , three examples of promotion and policy relationships may be seen. The first example shows policy  221  being directly related to promotion  200 -G (if policy  5  as shown in  FIG. 2B  had only one match with promotions  200 ). Next is shown policies  220  related with promotions group  205 . And finally global policy  225  is shown in isolation not directly related to a particular one promotion or group of promotions as global policies are applicable to all promotions.  
         [0041]     Referring to  FIG. 2B , the process begins with the creation of promotions  200  and assignment to promotion group  205  or  210 . Promotion groups  205  and  210  are associated promotion policies  220 . The fact a promotion  200  is a member of a promotion group  205  implies that promotion  200  is governed by all the promotion policies  220  associated with the group. Promotion policies  220  can also be associated with no group at all. In that case, the specific policy  220  is applicable to all promotions in the system as in the case of global policies  225 . When it is time to evaluate which are the applicable promotions  200 , the caller will specify an invocation template (not shown). The Invocation template is then passed to a component of the promotion system called PromotionExecutionAgendaBuilder  305  (of  FIG. 3 ) which builds a table  315  that looks like the following based on the invocation template and promotion organizations.  
         [0042]     Table  315  is referred to as a Promotion Execution Agenda. It provides the specification of the list of promotions that should be attempted during this invocation, and the policies that should be applied to each one of them in the stylized form of a relationship table. As in the sample above, promotions  200  in two groups “Group G 1 ”  205  and “Group G 2 ”  210  need to be attempted in this invocation. That includes promotion  200 -A through  200 -G. Because policies “Policy  1 ” and “Policy  2 ” are part of global policies  225 , they are applicable to promotion  200 -A through  200 -G. Because promotion  200 -A through  200 -E are members of promotion Group “G 1 ”  205 , and policies  3  and  4  are associated with group G 1   205 , they are applicable to promotion  200 -A through  200 -E. Similarly promotion policies  5  through  7  are applicable to promotion  200 -F and  200 -G  
         [0043]     Table  315  is a result of a call to a buildAgenda method of configurable component PromotionExecutionAgendaBuilder  305  of  FIG. 3 . A design pattern called “Builder” was employed to externalize the logic that actually builds table  315  of  FIG. 2 . While a table has been shown it may be appreciated that other suitable means may also be employed such as arrays, sets of vectors, graphs or lists to contain elements and the relationships.  
         [0044]     Referring now to  FIG. 3 , may be seen a class diagram of PromotionEngine  300  showing the pattern for the case of building promotion and policy relationship table called an agenda and the case of building a promotion sequence list. It is the concrete builder&#39;s responsibility to build the agenda, meaning table  315 . The behavior described earlier in this section is the behavior of the DefaultPromotionExeuctionAgendaBuilder  310 , an important mechanism. DefaultPromotionExeuctionAgendaBuilder  310  externalizes the logic to build an agenda and makes it possible for others to customize and extend the behavior of the system.  
         [0045]     Once the agenda (represented by table  315 ) is built, the next step is to determine in which order these promotions will be evaluated. This sequence of evaluation is determined by a call to another configuration component called PromotionExecutionSequenceBuilder  325  as seen in the class diagram of  FIG. 3 . Here again, a builder pattern is employed to externalize the logic that determines the evaluation sequence or list.  
         [0046]     The simple behavior of DefaultSequenceBuilder  330  may be described as follows: if promotion A and promotion B are in different promotion groups, and promotion group A precedes promotion group B in the invocation template, promotion A will be attempted before promotion B. If promotion A and promotion B are in the same group, and if promotion A has a higher priority than promotion B, promotion A will be evaluated ahead of promotion B. When promotion A and B are in the same group and have the same priority, the sequence will be determined at random. This builder pattern makes it possible for the system to be customized or extended. For example, in a system where a “promotion code” may be used, it is usually simple to swap in an implementation of a sequence builder that inherits all the behavior of the default builder but observes one more rule: promotion for which a “code” is entered will be evaluated before promotions for which no “code” is entered.  
         [0047]     The list of promotions  200  that need to be attempted and the order in which they should be attempted are now determined from PromotionExecutionSequenceBuilder  325 . Sequence vector  335  provides a listing of the sequence in which the promotions should be attempted. Sequence vector  335  may not include all of the references as some promotions may have been excluded from the build request. Customization can be used to provide the desired sequence list based on predetermined needs. The system then proceeds to evaluate promotions  200  one by one and applies promotion policies  220  in doing so as shown in  FIG. 4 .  
         [0048]     Referring to  FIG. 4 , for each promotion  200  listed in the sequence obtained from PromotionExecutionSequenceBuilder  325 , the system will evaluate the conditions associated with the promotion. Beginning with operation  400  the evaluation process commences and moves to operation  410  during which is determined the existence of more promotions to evaluate. Evaluation of promotions establishes whether the conditions or constraints of the promotion have been satisfied one or more times. If the conditions have been satisfied more than once, then a promotion execution record is created. The promotion execution record (which may be described as a vector containing promotion entries) will then be tentatively applied to the respective purchase item or object during operation  450 . Upon creation of a promotion execution record applicability of promotions contained within are then known. If it is indicated that there are no more promotions to apply processing will then move to end at operation  500 . If the conditions are satisfied, the system will obtain the next promotion during operation  420  then move to operation  430  during which the promotion is evaluated. The process then determines during operation  440  the applicability of the promotion evaluated during operation  430 . If not applicable, processing returns to operation  410 , otherwise proceeds to operation  450 . During operation  450  all policies applicable to the promotion are obtained using table  315 . It will then apply the list of policies indicated, one by one to the promotion cycling through operations  460 , then  470  and  480 . In the process, if a violation of any policy is detected during operation  480 , the promotion is deemed not applicable, and will be eliminated and processing would then move back to operation  410  and continue as described before. If no violation is detected during operation  480  after all indicated policies are applied, the promotion would then be applied during operation  490 , after which processing would move to end at operation  500 .  
         [0049]     The focal point of this process is promotion policies  220 . A standard interface for all promotion policies is implemented, such as the ones that enforce the number of times a promotion can be applied and whether a promotion can be combined with another promotion. Using this simple yet effective design technique, flexibility needed to introduce new promotion policies  220  and/or changes to existing policies  220  may be more easily obtained.  
         [0050]     Referring now to  FIG. 5  is shown an overall view of the conflict resolution process starting with having now created the table relating promotions and policies during operation  600  as has been described in conjunction  FIG. 5 , a context object is created during operation  605  to capture objects defined by table  315 . During operation  606  begins the actual “transaction” portion, and then during operation  610 , is created a control object which is initialized with the clones of objects from the context object created during operation  615 . This control object serves the same purpose as the log in a RDBMS. Any changes that result from applying a promotion during operation  620  are applied to the control object. The control object then represents the “after state” of the system, while the context object represents the “before state” of the system. Policies  220  work with the control object only, which presents policies  220  with a view of the system “after state”. A determination is made regarding more policies  220  to apply during operation  625 . If more policies  220  are to be applied they are then applied during operation  635  otherwise processing moves to operation  630  in which the changes are committed after which the process ends at operation  645 . If more policies are detected during operation  625 , processing would move to operation  635  as indicated earlier during which policies  220  would have been applied. Having applied policies  220 , processing would move to operation  640  during which a determination would be made regarding any possible violations of policies  220 . If violations were determined then processing would move to end at operation  645 . If no violations were determined then processing would move to operation  625  again with processing to continue as described. When a violation is detected during operation  640 , the control object is then simply discarded and the system remains in the “before state” because the context object has not changed at all. This state then represents a “rollback” operation in the analogy of the RDBMS. If there was no violation detected during operation  640 , the system would retrieve the objects from the control object and replace those in the context object with the retrieved ones during “transaction commit” operation  620 , again using the RDBMS analogy.  
         [0051]     Of course, the above described embodiments are intended to be illustrative only and in no way limiting. The described embodiments of carrying out the invention are susceptible to many modifications of form, arrangement of parts, details and order of operation. The invention, rather, is intended to encompass all such modification within its scope, as defined by the claims.