Abstract:
A rules evaluation engine operable to select optimal content for presentation to the viewer at each presentation opportunity. The engine evaluates segmentation rules associated with each particular content item in parallel, and then selects the best content to be presented. Priorities determined during evaluation sort out which content items will be presented. Real time dynamic enrichment of the decision making context occurs by retrieving additional information required to evaluate the rules. Logging and administrative processes for managing the segmentation rules are also realized.

Description:
RELATED APPLICATIONS 
       [0001]    This application claims the benefit of priority to U.S. Provisional Patent Application No. 60/482,487 entitled “System and Method for Dynamically and Specifically Targeting Marketing,” filed on Jun. 25, 2003, and is incorporated herein by reference in its entirety. This application is related to and incorporates by reference U.S. provisional application No. 60/438,972 filed Jan. 9, 2003 entitled, “Method and System for Dynamically Implementing an Enterprise Resource Policy”, and U.S. non-provisional application Ser. No. 10/755,173 filed Jan. 9, 2004 entitled, “System and Method for Dynamically Implementing an Enterprise Resource Policy.” 
     
    
     TECHNICAL FIELD OF THE INVENTION 
       [0002]    The invention relates to a system operable to select optimal content to be presented to a viewer, based upon both the characteristics of the viewer and the viewing situation. 
       BACKGROUND OF THE INVENTION 
       [0003]    Over the last decade, technology has drastically improved the effectiveness of technology-based marketing. CRM systems have brought businesses back to their ancestral roots by providing organizations with a collective memory of every customer and their interactions. Previously, this was cost-prohibitive. 
         [0004]    However, providing the optimal message to a customer is still a very cumbersome and time-consuming process. As a result, corporations have not fully benefited from the promise of real-time customized and personalized marketing. Many customized content and personalization initiatives remain undeveloped because of their prohibitive human and financial costs of implementation. 
         [0005]    With the traditional targeted marketing paradigm, the seller initiates an interaction with the customer by analyzing historical data to segment customers offline and then “pushes” a message out to the customer. The seller then hopes for a response. However, other more proactive methods are desired. 
       SUMMARY OF THE INVENTION 
       [0006]    The present invention provides a system and method to select, from a predefined palette of content items, those items which are best suited for an individual. This selection is based both on the attributes of the viewer and the context in which the contents is viewed. (i.e., at that precise moment in time). The content may involve advertisements, articles, or multimedia, such as animated images, movies, or audio clips. 
         [0007]    More specifically, the present invention provides a centralized system that defines and manages business rules to identify what content is most relevant to the individual viewer&#39;s context. Then upon receipt of the content selection request, a centralized system evaluates the viewer&#39;s characteristics, the situational characteristics (context), and the viewer&#39;s personal history against the coded rules in order to select an optimal content set for display. Then the selected content is returned to a local system that serves the selected content to the viewer. Essentially, a number of diverse content items can be managed by the system, wherein each content item may have one or more coded rules which define the viewer and content in which content would be presented to the viewer. 
         [0008]    In effect, each item of content has a rule which describes a “profile” of what an ideal viewer or presentation opportunity. When the content selection request is made, the coded rules associated with each relevant item are evaluated to determine if an appropriate viewing opportunity exists. If the rule is satisfied, the system then adds the content item, within a prioritized queue, to an aggregated body of content items for this presentation opportunity. The items are then sorted, by descending priority, with the most significant items being returned for presentation. The prioritized list is returned based on the results of evaluating the individual content items against various business rules. This produces a prioritized list of items most suitable for presentation to the viewer in the viewer&#39;s current viewing context. 
         [0009]    Several advantages are provided. First, the ability to perform the evaluation process in real time, at the moment of the request is a significant advantage over existing systems. This allows the content selected to be sensitive to the current presentation opportunity rather than the data warehouse intensive traditional model which selects content days, and even weeks, beforehand. The present invention may also couple to enterprise data sources, customer care systems, and external data sources such as credit scoring bureaus, etc. to provide a very rich palette of information on which to base the content selection rules. 
         [0010]    A detailed log of each request made, along with any/all content items selected for presentation, provides for auditability and effectiveness metrics, as well as inputs for a “feedback loop” in which future presentation opportunities can be made based on prior decisions. For example, a rule could be constructed such that an individual item of content would be highly prioritized under default conditions, but would be deprioritized in favor of other content items after the original item had been presented to a viewer. One implementation may reduce an item&#39;s priority after the item has been viewed three times in a 24-hour period. 
         [0011]    An advantage of the present invention is that the rules defining the optimal presentation opportunity do not need to be maintained in executable code by the administrator or user. The rules are captured in a representative notational format via a rule-builder GUI application, and then stored in an XML encoded structure within repository. As they are not a part of the presentation engine (such as a web server), they can be changed at will without the need to update or test the web server or HTML source for the web pages the content is to be presented in. The items of content are managed in a hierarchical model, with each item inheriting characteristics from its parent to determine who may manipulate or change the rules which determine the rule&#39;s behavior unless a specific rule is established for the individual item. Ultimately, this allows the rules to be administered in a distributed fashion throughout an enterprise, or even to clients (usually advertisers) and business partners if the situation warrants such. 
         [0012]    The invention can be invoked via a number of methods, including a J2EE compliant API library, a procedural interface suitable for linking into legacy applications written in C, COBOL, FORTRAN, etc., a Web Services interface, a C+ interface, or even a custom-developed API for an individual customer&#39;s needs. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numerals indicate like features and wherein: 
           [0014]      FIG. 1  depicts one basic implementation model to provide optimal content item for a particular viewer of a website; 
           [0015]      FIG. 2  provides a logical flow diagram relating to processing a content selection request; 
           [0016]      FIG. 3  is a diagram of the Dynamically Expandable Rules Framework that describes a process, implemented in code, by which invocation of a service can be made both enabled for parallel scaling and tolerant of failure of components in accordance with the present invention; 
           [0017]      FIG. 4  is a logic flow diagram providing a Dynamic Enrichment Process that depicts utilizing the rules engine to determine whether all of the data elements required to evaluate the rule are available; and 
           [0018]      FIGS. 5A and 5B  depict a Parallel Fault Tolerant Architecture that enables the invention to dynamically scale effectively across multiple servers and/or platforms while continuously servicing requests from the users/viewers. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0019]    Preferred embodiments of the present invention are illustrated in the FIGUREs, like numerals being used to refer to like and corresponding parts of the various drawings. 
         [0020]    One potential architecture for the use with the invention is depicted in  FIG. 1 . Here, user or viewer  10  requests a page of content from web server  14 . Viewer  10  may have previously established his identity by authenticating in some fashion with web server  14 . Alternatively, viewer  10  may be treated as having a default or anonymous identity. 
         [0021]    Web server  14  loads page  13  from web page repository  12 . Then web server  14  executes java servlets or other like instructions that are contained within page  13 . The servlets invoke services application programming interface (API) which places a remote procedure call (RPC) into policy manager  16 . This RPC requests content specifically chosen for viewer  10 . Request  11  contains both the identity of viewer  10  and information that defines the set of rules and content items to be selected from a campaign or set of related content items. 
         [0022]    Policy manager  16  uses a name associated with the campaign or set of related content item to retrieve a set of rules  17  from rules repository  18 . Policy manager  16  then examines rules  17  to determine what additional information or data elements are required to evaluate rules  17 . 
         [0023]    Policy manager  16  invokes any/all connectors required, including but not limited to LDAP connector  24 , SQL DB connector  26  and custom connector  28  to retrieve the information or data elements required to evaluate rules  17 . These data elements may be within directory database  30 , HR system database  32  and other data sources  34 . These data sources return the data elements needed to policy manager  16 . 
         [0024]    Policy manager  16  enriches the decision context with the information retrieved. Policy manager  16  then evaluates the rules and creates an aggregated list of the content items associated with any/all rules whose criteria are met. Policy manager  16  then sorts the aggregated list in order of descending priority. The top “n” items of content (“n” being a number of items parameter passed on the ESAPI request), are selected and returned to web server  14  as the resultant of the ESAPI request. The web server then inserts those return content items into page  13 , which may take the form of an HTML document. The customized page is then presented to viewer  10  via a web browser or other like application. 
         [0025]    Event log  36  may track every transaction created and stored within repository  38 . The information within event log  36  can provide the basis of metrics determining system usage and effectiveness as well as providing the inputs and capability on which to modify rules  17 . For example, upon such information may include how many times a particular item has been presented to a specific viewer in a defined time interval. 
         [0026]      FIG. 2  provides a process flow diagram that depicts the logical flow of web content request. The processing of a request to select content items for a viewer. In step  50 , viewer  10  establishes their identity by authentication through a means such as external authentication mechanism  51 . Next, a request is sent to web server  55  for a document in step  52 . 
         [0027]    In step  53 , the document source is retrieved from the source repository, whereupon the web server executes instructions embedded within the document. Those instructions then invoke a services API in step  57  to request content from server  59 . Optimal content is returned to web server  59  in step  56 . Instructions within the document are then replaced with content. Then in step  60 , web server  55  delivers the customized page to the user&#39;s browser for display. 
         [0028]      FIG. 3  depicts dynamically extensible rules management and evaluation framework  70 . Rules evaluation engine is based upon the concept of using a process by which a policy is expressed as a rule, encoded in a machine-independent rules modeling language. The rule can be dynamically loaded from the repository  72  and evaluated upon demand within multiple execution contexts simultaneously. This provides for parallel scaling and fault tolerant capabilities. As the rules are loaded dynamically at evaluation time, rules may be created and/or changed at will, and will take effect upon the next evaluation request. 
         [0029]    In  FIG. 3 , GUI  74  allows administrative users to access rules  17  stored within repository  72 . GUI  74  also facilitates the ability of administrative users to create and modify coded rules based on business rules. GUI  74  interacts with repository  72  through server  76 . The coded rules corresponding to the business rules are stored within repository  72 . These rules  17  determine what content will be eligible to be presented to a viewer as previously described in  FIGS. 1 and 2 . 
         [0030]    Rules  17  are retrieved from repository  72  following receipt of a content selection request that corresponds to query  78  that is received via web server  14  via input from user  10  through web server  14 . Rules  17  are dynamically loaded and interpretively evaluated within process  82  wherein the results of this evaluation are returned to web server  14  or other requesting application in order to present the optimum content to a viewer. 
         [0031]    The concept of dynamic enrichment of the data is available within the decision context depicted in  FIG. 4 . The dynamic enrichment process involves receiving a request in step  80 . In step  82 , in response to the request, a policy set is loaded from repository in step  82 . The policy set is analyzed to determine the required data elements in step  84 . In step  86 , metadata is consulted and data elements are grouped by connector. For each connector a determination is made in step  88  for data for each data element within the connector. This involves determining whether or not each data element already has a value at decision point  90 . If it does, an evaluation is made for the next data element. If not, a determination is made a decision point  92  as to whether or not all required key values for this data element are present. If all the required key values for this data element are present the data element is added to the connector request in step  94 , otherwise, a determination is made for the next data element. In decision point  96 , a determination is made as to whether or not additional data elements are required for this data connector. If additional elements are required the next data element is evaluated returning to step  96 . Otherwise, at decision point  98 , a determination is made as to whether or not any more connectors remain to be processed. Additional connectors are processed as described above. Otherwise, the connectors with unresolved elements are invoked at step  100  in order to retrieve identified additional data elements. At decision point  102 , a determination is made as to whether or not any new values were retrieved. If there were, at decision point  104 , a determination is made as to whether any unfilled data elements remain in which case the process is repeated by returning to step  88  until no unfilled data elements remain as indicated at point  106 . Essentially, feature allows the rules engine to determine when all the data elements required to evaluate the policy are present. If the answer is no, then the rules engine may, through connectors, map to and retrieve all requisite data elements before evaluating the rule. 
         [0032]    A diverse, fault tolerant architecture that enables effectively sealing across multiple servers and/or platforms while continuously servicing content selection requests is depicted in  FIGS. 5A and 5B . This architecture effectively operates even when a multiple server loss occurs. 
         [0033]      FIG. 5A  depicts the process of realm startup. At step  120 , the realm startup process is initiated. In step  122 , all of the configuration files are read and associated processes are initiated. These processes are all registered with the service registry in step  124  after which the monitor performs regular health checks at predetermined intervals in step  126 . If a dead process is found, the monitor deletes the registry and restarts the process in step  128 . 
         [0034]      FIG. 5B  depicts client side fault tolerant wrapper logic. Here, in step  130  a client API wrapper is invoked. At decision point  132 , a determination as to whether or not local cache of handles is required for service. If not required for service, the service handles are retrieved in step  134 . Otherwise, a random handle is selected from an available list in step  136 . Returning to retrieving service handles, decision point  138  evaluates whether or not handles were retrieved. If they were not, a return failure is made to the user in step  140 . Otherwise, we progress to step  136  where the random handles are selected from the list. In step  142 , a service call is initiated, after which at decision point  144 , a determination is made as to whether or not a communication failure is indicated. If no communication failure is indicated, the resultant is returned to the user in step  146 . Otherwise, the monitor is notified of failed service. In step  148 , the dead handles are removed from the registry and reinitiating begins in step  150 , after which the process returns to step  134 . 
         [0035]    The current implementation of this concept is built upon a Java infrastructure, and utilizes a number of fairly obscure features of the Java language to facilitate the service. The two most prominent of these are the concept of a dynamic class loader, and HTTP/XML RPC architecture used to manage the interaction between processes. 
         [0036]    It is important to note that while one embodiment is implemented in the Java language, the concepts that distinguish the present invention are notably not Java specific, and in no way should the claims be restricted to the Java language or the platforms on which it runs. In a procedural language such as C/C++, PL/1, etc. the same concepts could readily be implemented through the use of dynamically shared libraries or through dynamic overlay methods that are well defined and commonplace. 
         [0037]    While the embodiments discussed above focus on serving content to a web server, the present invention may also service other delivery mechanisms such as a Voice Response Unit (VRU), a wireless device such as a pager or cell phone, etc. 
         [0038]    Although the present invention is described in detail, it should be understood that various changes, substitutions and alterations can be made hereto without departing from the spirit and scope of the invention as described by the appended claims.