Method and system for constructing personalized result sets6587849Abstract A computer systems includes a rule engine, one or more repository interfaces, and corresponding repositories. The repositories typically contain content or profile information about users. The rule engine provides rules in a uniform format which can be translated, through use of the repository interfaces, into queries specific for the corresponding repositories. Before translating the rules, context objects referenced in the rules are resolved and the corresponding attribute values are inserted into the rules. The resulting rule is simplified where possible because of the attribute values, so that only those queries that need to be made to a repository are made. Claims What is claimed is: Description FIELD OF THE INVENTION
<ruleset>
<!-- accept rules -->
<accepts>
<rule op=and>
<rule op=eq>
<valueof target="available">
<valueof constant="true">
</rule>
<rule op=eq>
<valueof target="author">
<valueof bean="Profile.favoriteAuthor">
</rule>
</rule>
</accepts>
<!-- reject rules -->
<rejects>
<rule op=and narne="Rated R">
<rule op=lt>
<valueof bean="Profile.age">
<valueof constant="17">
</rule>
<rule op=eq>
<valueof target="rating">
<valueof constant="R">
</rule>
</rule>
<rule op=and name="Rated X">
<rule op=lt>
<valueof bean="Profile.age">
<valueof constant=" 18">
</rule>
</rule op=eq>
<valueof target="rating">
<valueof constant="X">
</rule>
</rule>
</rejects>
<!-- sorting directives -->
<sortby>
<sortbyvalue value="lastModified" dir=descending>
<sortbyvalue value="name" dir=ascending>
</sortby>
</ruleset>
As this example illustrates, "rule" tags can be nested. Preferably, at most a single "accepts" tag and at most a single "rejects" tag is used, each containing one or more "rule" tags. In addition to the "accepts" and "rejects" sections, a rule set may have an "includes" section. The "includes" tag is used to include one or more rule sets within another rule set. The syntax for using an "includes" tag is: <includes> <ruleset src="{rule set name}"> </includes> Multiple "ruleset" lines may be included within the "includes" section. Similarly, individual rules can be included in the "accepts" or "rejects" sections by referencing the name of the rule. The syntax for including a previously named rule is: <rule src="{rule name}"></rule> Preferably, if no value is included in the target (that is, the target has a null value), such as because a user did not provide his or her age or the author of a work was not provided, the repository item is not included in the targeting results because it is not known whether the item meets the criteria. However, a rule can test whether the value of a target is a null value. By using an appropriate OR operation, items with null values can be included in the results. As the above example also illustrates, context objects have their own attributes, which can be referenced within the rule syntax. The rule engine resolves the names and retrieves the appropriate values of the context object when the rule is processed and places those values into the rule data structure for evaluation. If personalization is to be used when returning content, then one of the context objects may resolve to the user accessing the application, with attributes corresponding to the information in the user's profile. Another context object may be the user's shopping cart. If the personalization will be based in part on the number of products in the user's shopping cart, then a rule may involve a comparison to the corresponding attribute. For example, one line of the resulting rule might read: <valueof bean="ShoppingCart.numProducts"> The rule engine executes a rule definition within an appropriate context and transforms the business rule into a query that can be executed against the data store to return the dynamic result set. In a preferred embodiment, the rule engine performs the following steps in order to process a business rule. First, as shown in FIG. 2, the rule engine fetches (step 100) the complete rule data structure, which represents the desired business rule. Then, the rule engine transforms the data structure by recognizing and resolving context objects (step 105), fetching the indicated attribute values (step 110), and inserting ("inlining") the retrieved values into the data structure (step 115). Preferably, after context object values have been resolved, the rule data structure is optimized, by determining which sub-parts of the rule can be processed immediately without accessing the content repository. For example, if part of the rule does a comparison test between a context value and a constant, both values are known at this point. Thus, the comparison operation can be performed. Preferably, to do this the rule engine examines (step 120) each sub-part of the rule, and determines (step 125) whether all of the values have been resolved. Alternatively, at step 125, the rule engine needs only to determine whether sufficient values have been resolved to process the sub-part. Where the sub-part's operation can be performed, the rule engine performs that operation (step 130). This optimization process continues until the entire rule has been analyzed (step 135). At step 140, the result of the comparison may allow the rule data structure to be pruned further or cause the complete execution to be stopped immediately. If, for example, a portion of the rule involves an AND operation, where one element of the operation is resolved to be false based on context object values and the other element of the operation is dependent on values obtained from the content repository, then the AND operation necessarily will be false. Therefore, it is unnecessary to invoke that portion of the rule, and accessing the content repository for the information in that portion of the rule can be avoided. This example is illustrated below, where the rule returns a set of items whose author matches the user's favorite author (an attribute of the user's profile), but the information is available only to members, as opposed to guests, to a web site. If the user is not a member, it is unnecessary to search for items by the user's favorite author.
<rule op=and>
<rule op=eq>
<valueof target="author">
<valueof bean="Profile.favoriteAuthor">
</rule>
<rule op=eq>
<valueof bean="Profile.member">
<valueof constant="true">
</rule>
</rule>
When the rule is defined, the user is unknown and therefore the Profile attribute values that will be used are unknown. However, at runtime, the Profile values can be inserted into the data structure. For example, if the user's favorite author is William Shakespeare, but the user is not a member, then the rule translates to:
<rule op=and>
<rule op=eq>
<valueof target="author">
<valueof constant="William Shakespeare">
</rule>
<rule op=eq>
<valueof constant="false">
<valueof constant="true">
</rule>
</rule>
In this example, the second part of the AND operation is false, and therefore the entire portion of the rule is false and can be omitted from further processing. However, if the rule involved an OR operation between this portion and other portions, then the other portions might still need to be processed. After the rule has been optimized, the resulting data structure is translated (step 145) into a query that can be sent to the repository and will return the correct content elements. If, in the above example, the user was a member, then the resulting optimized rule would be:
<rule op=eq>
<valueof target="author">
<valueof constant="William Shakespeare">
</rule>
The optimized rule is translated from this rule data structure into a new data structure that the repository understands and can use to send the query to the repository. A repository interface is written for the particular repository for which it will interface, to perform the translation of the rule data structure into the native query language for the repository. This permits the rule engine to have a single rule syntax that is independent of the different systems to which it is applied, and allows the same rules to be reused with different legacy systems. For example, if the repository is based on a relational database that is accessed with a Stuctured Query Language (SQL) statement, the above rule might result in the following SQL statement: SELECT * FROM items WHERE author=`William Shakespeare` After the rule engine has performed the translation, using the repository interface, it takes the new query data structure and forwards it to the repository. The repository then executes the query (step 150) against the contents (such as a database), gathers the results, and returns the results to the rule engine. The rule engine, in turn, returns the results to the user or to another application (step 155). Optionally, the rule engine performs transformations on the results before returning the results. If, for example, the results are content, they may be inserted into an HTML document that is returned to the user's browser. If each item has a unique identifier, then the identifiers of objects that are found in response to a query can be used to retrieve the object at a later time. For example, a rule might return a set of promotions that a user can receive. To "give" these to the user, the unique identifier of each promotion object can be saved in the user's profile. Subsequently, the promotions can be used by loading them from a promotions repository using the saved identifiers in the user's profile. In addition, the identifier could be used to access a specific repository item and determine if it matches certain criteria. For example, the promotion may only be available at certain times or days of the week, as specified by attributes in the promotions repository. This rule structure also permits items contained in a data store, or repository, to be segmented according to their own attributes. For example, a content management system may hold documents, where each document has a "type" attribute that is part of its meta-data. The document types may include "marketing" and a variety of technical types, such as "operating systems" or "computer graphics." The rule structure can be used, in this example, to construct marketing and white papers segmentations. The following rule syntax would create a marketing segmentation.
<rule op=eq>
<valueof target="type">
<valueof constant="Marketing">
</rule>
Similarly, the following rule syntax could be used to create a white papers segmentation, which includes documents directed to operating systems or computer graphics.
<rule op=or>
<rule op=eq>
<valueof target="type">
<valuedf constant="Operating Systems">
</rule>
<rule op=eq>
<valueof target="type">
<valueof constant="Computer Graphics">
</rule>
</rule>
This rule could be modified easily, if desired, to include or remove specific categories of technical documents. Similarly, segmentation may be performed by user. If a repository is used to define all users of a web site, then a marketer can create business rules that segment the users into specific demographic segments. For example, to define a business rule that segmented all New Englanders the following rule could be used.
<rule op=or>
<rule op=eq>
<valueof target="State">
<valueof constant="CT">
</rule>
<rule op=eq>
<valueof target="State">
<valueof constant="MA">
</rule>
<rule op=eq>
<valueof target="State">
<valueof constant="ME">
</rule>
<rule op=eq>
<valueof target="State">
<valueof constant="NH">
</rule>
<rule op=eq>
<valueof target="State">
<valueof constant="RI">
</rule>
<rule op=eq>
<valueof target="State">
<valueof constant="VT">
</rule>
</rule>
Executing this rule would return all users who resided in New England. This, in turn, could be used as part of a broader rule. For example, users who resided in New England might receive content relating to that region. To simplify this process, new attributes can be defined. For example, the attribute livesInNewEngland might be based on the above rule. Then, the above rule could be used as part of a larger rule by including the following simpler rule.
<rule op=eq>
<valueof target="livesInNewEngland">
<valueof constant="true">
</rule>
This segmentation mechanism can be applied in combination with a context object to match a user or the current conditions with a user repository. For example, the following rule would match a user to people who have one or more favorite sports in common.
<rule op=includesAny>
<valueof target="favoriteSports">
<valueof bean="Profile.favoriteSports">
</rule>
While there have been shown and described examples of the present invention, it will be readily apparent to those skilled in the art that various changes and modifications may be made therein without departing from the scope of the invention as defined by the appended claims. For example, the above rule structure can be used in different targeting contexts. For example, it can be used with content accessed over the world wide web and to create targeted electronic mail. Rules can be inserted into an e-mail message template, so that, for example, the resulting message is personalized based on the recipient's profile. Also, although a specific rule syntax and specific rule constructs are described above, the invention is not limited to any specific syntax or rule construct. Accordingly, the invention is limited only by the following claims and equivalents thereto.
|
Same subclass Same class Consider this |
||||||||||