Patent Application
20080021758
Embodiments of the present invention provide systems and methods for automatically determining, at run time, the agent responsible for a particular task. A task description describes a task to be performed. The task description may be constructed by a task constructor using a task grammar. A task grammar may include arbitrary elements that may be predefined or defined at run time, leading to the definition of limitless numbers of tasks. A rule maps task descriptions with the agents who are responsible for performing the described task. A request description contains the description of a proposed task in a responsibility request, the request serving as a mechanism to query the system to determine the responsible agent for the particular proposed task. The task description of the various rules may be constructed using the task grammar. A task constructor may predefine, or construct at run time, arbitrary task descriptions and request descriptions using the elements of the task grammar. The update processor combines a rule task description with a responsible agent, leading to the definition of limitless numbers of rules at run time. A rules engine matches a request description of a proposed task with the various rule task descriptions of the various responsibilities rules to locate an agent responsible for performing the received task. In this way, a flexible system and method is contemplated that allows tasks to be defined generally at run time and automatically resolves to rules that define the agents responsible for performing the associated tasks.
Description of the present invention begins with a description of a task grammar. A task grammar may include elements and grammar rules. Grammar rules define the structure of the task. Elements make up the individual building blocks that are assembled according to the grammar rules to make up either a task description or a request description. A user may define, at run time, arbitrary numbers of elements, thereby allowing for the construction of any arbitrary task. This flexibility permits the system to describe and process any task without predefining the tasks ahead of time. Of course, in practice, the system may include predefined task elements that may permit a task constructor to begin constructing tasks right out of the box.
Task grammar rules may be of arbitrary complexity, leading to complete flexibility in the types of tasks that may be described. A task grammar rule describes the way that grammar elements may be combined. In one embodiment, a rule may define that a task description or request description may be constructed by combining any triple of elements together. In another embodiment, another rule may allow a series of elements to be concatenated such that the first element of any series is element 1. In other words, rules may be arbitrary and may state that elements may be grouped and ordered in any appropriate fashion. Rules may be implemented in various ways, but unless stated, their implementation is immaterial to the description of this invention.
Grammar elements may be grouped into types, further adding to a grammar's flexibility. Grammar rules, in addition to being applied to elements, may be applied to types at the same time. To illustrate, for a grammar with 150 elements, a first type may include elements 1-100. A second type may include elements 101-150. A rule may be defined which allows any element of the first type to be paired with any element of a second type. Another rule may define that a task description or request description includes an arbitrary number of element pairs, just described, to be concatenated together. Yet another rule may state that element 1 may be paired with any element of the second type. Types and rules may be implemented in various ways, but unless stated, their implementation is immaterial to the description of this invention.
A task description or request description may be an actual set of task parameters, or elements, that define the task. Any particular parameter, as described, may contain a range of values. For example, a “Country” parameter may contain the possible values “U.S.” or “Canada.” A “Day of the Month” parameter may contain possible values ranging from 1 to 31. A task description may be constructed by appropriately selecting among the possible values for the parameters and verifying that the end result conforms to the grammar rules.
In practice, any grammar of arbitrary complexity may suffice that can be used to describe tasks. In one simple embodiment, the grammar may include fields and values. Values may be grouped together into groups and given a label. All of the labels of the value groups may themselves be grouped together to form a field group. A task description or request description may be constructed by forming a series of field/value pairs in which the field corresponds to the label of the value group that the value is a part of.
The table below depicts an exemplary set of fields and values for a task grammar of the present invention describing tasks for a corporation.
In the current embodiment, a number of field/value pairs may be combined to define a task. For example, one task description or request description may be ([Activity Type=Accounting], [Accounting Payroll=Distribute Pay Checks]). Another task description or request description may be ([Activity Type=Hiring], [Hiring Computer Systems Task=Create Password]). In practice, any number of field/value pairs may be combined together according to the definition of the grammar elements. Also, in practice, the actual task descriptions and request descriptions may be represented in any appropriate format, including as an array of field/value pairs, as a text string of field/value pairs, etc.
Complex grammars may also be used. In one embodiment, the English language may be used to define grammars. The task constructor may allow the user to type in a natural language task description or request description and may use grammar rules to insure that the task description fulfills the rules of the English language. In this case, individual words may be the grammar elements. Parts of speech may be used to group grammar elements. Grammar Rules may include various levels of specificity. For example, the first level may combine sentences into paragraphs. Next, sentences may combine clauses. Finally, clauses may combine parts of speech. In this way, a task may be described arbitrarily by the use of the English language. Another exemplary grammar may be computer programming languages.
Tasks may be associated with data necessary to carry out the task. A task constructor may receive data to be processed by one responsible for a particular task. The task constructor may then formulate a task description or request description based on a task grammar and associate the task with the data to be processed.
Task data may be arbitrary. In one embodiment, task data for the ([Activity Type=Hiring], [Hiring Computer Systems Task=Create Password]) request description may be the name of the new employee, employee's user name, and the employee's identification number. The task data for the ([Activity Type=Accounting], [Accounting Bookkeeping=Audit Books]) request description may be all files and ledgers associated with accounting for that year. Still further, some tasks require no task data at all. For example, the ([Activity Type=Accounting], [Accounting Payroll=Distribute Pay Checks]) request description may not require any data to be processed.
In yet another embodiment, task descriptions and request descriptions may include a responsibility context and responsibility data. A responsibility context may be any arbitrary grouping of related tasks. For example, an international web retailer may need to confirm shopping carts of varying values from different countries. One individual may be designated to confirm shopping carts from Germany less than 10,000. Another may confirm shopping carts from Germany greater than
10,000. Another may confirm U.S. carts between $2,000 and $8,000. Finally, another may confirm U.S. carts from any territory outside of the 50 states, regardless of the value. A responsibility context may be the general task of confirming shopping carts while the specific parameters of the task may be the responsibility data. In another example, as part of a task scheduling suite, tasks may be organized into groups based on the amount of time it takes to perform the tasks. A first responsibility context may include all tasks that require five minutes or less to complete. The scheduling suite may schedule the responsible agents to perform these short tasks to fill small gaps in a schedule to achieve maximum efficiency.
A responsibility context may be thought of as a classifying mechanism that creates a subset of rules that is applicable to the task being described. Each particular rule may contain data that further specifies the task within the responsibility context. For example, A “manufacturing” responsibility context in a request description may permit the rules engine to exclude rules not concerning manufacturing from its search to match the request description with the appropriate task description. Existence of the “manufacturing” responsibility context in effect allows the rules engine to classify all manufacturing rules together.
Multiple layers of responsibility contexts may be constructed to further categorize tasks. Each successive specific responsibility context permits the rules engine to categorize rules in increasingly finer ways. For example, the manufacturing responsibility context may contain a subcontext for “site logistics” and “production.” Within cite logistics, the task types may include “move equipment” and “perform diagnostics.” The production subcontext may include task types “set up” and “deliver materials.” The precise number of levels of specificity depends on the particular implementation of the invention and is immaterial to this description. Each level of specificity may permit the rules engine to narrow the scope of its search, thereby returning the matching result more quickly.
The user may employ a task constructor 30 to formulate task descriptions or request descriptions. A task constructor may be a separate computer program module (as shown in
For the user front end constructor 30, the user interface may allow a user to specify each subpart of the task description or request description. In one embodiment, a front end may include an input text box. The user may enter text using a keyboard. The constructor 30 may receive the inputted text and verify that it conforms to the format of the grammar. The English grammar may be used here. Each word may be categorized into parts of speech, and the constructor may apply grammar rules of the English language to check if the text is a well formed sentence.
In another embodiment shown in
Turning back to
The responsibility rules engine 12 may include a rule processor 18 adapted to receive incoming requests 16 and to query a database 20 to perform the responsibility determination. In practice, various architectures may exist for rules engine 12. The responsibility rules engines may exist as separate computing platforms, each with their own databases 20. In this case, the databases 20 may contain additional data synchronization features to insure that each database contains the same information as the other databases. Alternatively, there may be a single database 20 which serves data for all of the responsibility rules engine 12. Still further, instead of existing as separate servers across a computing network, the responsibility rules engine 12 may be computing components that exist as part of the calling applications themselves.
The database 20 may include various responsibilities tables 21. The rules processor 18 may receive a request description and search the tables 21 to look for a matching task description. Upon finding a match, the rules processor may retrieve the responsible agent listed for the task description and return it to the calling application 14.
Tables 21 may be organized in arbitrary ways, and matching may be done arbitrarily as well. Tables 21 may include entire task descriptions and their associated responsible agents or may be organized to facilitate searching. In one embodiment, tables 21 may include a single table that includes one field representing the task description and one field representing the responsible agent. An exemplary table is shown below.
A search using the single responsibilities table may attempt to match the entire request description with each task description in the first field of the table. Alternatively, in practice, an arbitrary number of tables may be used. For example, task descriptions may be inherently grouped such that the rules processor need to simply search the table corresponding to the task group to which the task description belongs.
Tables may be organized in other ways that may facilitate searching. In another embodiment, tables may be organized in a hierarchical way, such that each subpart of the task description may exist as a separate table with pointers to other tables that include information for other subparts. An exemplary table is shown below.
Given that the request description task is ([Activity=Accounting], [Accounting Bookkeeping=Audit]), the system may first look in table one to match the first subpart of the request description, [Activity=Accounting]. Instead of a responsible agent in the accompanying table field, the table may include a pointer, such as the table pointing to Table 2 in the example above. In practice, implementation of the format of task descriptions and the tables 21 may be performed in to best way to suit the specific system implemented and are immaterial for the purposes of this description.
A match algorithm of the rules processor 18 may depend on the format of the task description. For the embodiment described above, a pair by pair matching scheme may be employed where the field and values must correspond in order for the individual pairs to be equal. If the task descriptions are textual (as represented in the examples employing the English grammar above), a text string comparison function may be used. Where task descriptions are represented in data structures, task description functions may be employed to match the request descriptions with the task descriptions in the tables 21. For example, task descriptions may consist of an array data structure of field/value pairs. In this illustration, the request description and task description may be equal even though the ordering of pairs in the array differs. Therefore, in comparing a request description against one of the task descriptions in the tables 21, the comparison function must search for each of the pairs of the request description in turn.
In other embodiments, matching may also employ fuzziness. Using fuzziness allows a request description and task description to be matched despite them not being strictly equal. The matching algorithm may contain thresholds under which matches that differ may be deemed to be equal. For example, a match algorithm may receive a request description and a task description, the request description and task description differing only that the request description contains a field/value pair not found in the task description. The request description and task description may be deemed to be equal. In another example, a match algorithm may receive both a request description and task description in the English language in accordance with an embodiment described above. The matching algorithm may allow for spelling errors by augmenting each word with a set of common misspellings taken from a preselected misspelling dictionary. Then, the matching algorithm may compare each augmented list of words in the first sentence with all augmented words in the second sentence. In practice, the implementation of matching algorithms may vary as appropriate and are immaterial for purposes of this description.
Furthermore, in other embodiments, matching may look to see whether the request description meets the condition of the responsibility rules. In this embodiment, a responsibility rule may contain a condition to be satisfied. The matching algorithm may see whether the data of the request description meets the rule. The condition of a responsibility rule may require that certain data fall within a particular range of values or that certain data have a specific value. The data of the request description would be checked to see whether it either falls within the acceptable range or has the value required by the rule. To illustrate, a rule may state that an agent can process all purchase orders between $1,000 and $10,000. The range may be specified in the “Purchase Order Value” field of the rule condition. An incoming request description may contain data indicating a purchase order of $2,000, specified in the “Purchase Order Value” field. The matching algorithm may select these two fields and determine that the request description data falls within the range specified by the rule. In practice, matching request description data against responsibility rule conditions may be implemented in any suitable way; implementation level detail is immaterial to the description of this invention.
Once the rules processor 18 locates the responsible agent(s) 24 responsible for the request description in the request 16, the agent or agents may be returned to the calling application 14. The task data associated with the request 16 may then be forwarded to the responsible agent(s).
In one embodiment, shown in
In yet another embodiment, a responsibility table 21 may contain responsibility data needed to further specify which task within a responsibility context to perform. For example, responsibility data for the responsibility context “confirm shopping carts” may consist of “Germany, <10,000” or “U.S., any territory outside the 50 states”.
The responsibility table 21 may also associate a responsible agent 24 with the responsibility data of the responsibility rule. The responsible agent may be the individual designated to handle all tasks within the responsibility context for the specific responsibility data. For example, employee 1 in 10,000.
Returning to 8,800, the calling application may seek the responsible agent responsible for processing the shopping cart. Exemplary responsible agent requests are shown in
10,000”.
Upon receiving the responsible agent request 16, rules engine 12 may use the responsibility context found in the responsible agent request 16 as an index to select the correct responsibility table. Tables 21 may include an index table which contains mappings between responsibility contexts and pointers to the tables that contain rules for that responsibility context. The rules engine 12 may perform a look up into the index table with the received responsibility context and receive a pointer to the appropriate table to be searched. The rules processor 18 may then query that table to match the responsibility data with a rule in that table. The responsibility rules engine 12 may return the responsibility agent associated with the responsible agent request 16 upon matching the responsibility data in the request 16 with the responsibility data in the responsibility table. The calling application 14 may then forward the shopping cart related to the responsible agent request 16 to the responsible agent for processing.
In an alternate embodiment, referring to
To illustrate, the calling application 14 may seek a responsibility agent to process an incoming shopping cart. The shopping cart may contain the customer's name, street address, and city (Munich for example), but may lack the country. Without the country, it may be impossible to properly route the shopping cart for processing. A request may be sent to the rules engine 18 containing a request description with the information known. Upon receiving the request description the rules engine 18 may send the request to the enrichment processor 50. The enrichment tables 52 may contain a rule that specifies that the city Munich is in the country Germany. The enrichment processor 50 may examine the received request description to see if it includes Munich in the portion corresponding to a city location. The enrichment processor 50 may enrich the responsibility data by filling in the country of Germany. In addition to automatic enrichment, the enrichment processor may use human intervention to augment the request description. In one embodiment, the user may be presented with a display showing the request description. A front end similar to one used in the task constructor may be used. In practice, various methods of augmentation may be used, either automatic or with human input; implementation level detail is immaterial to the description of this invention.
In an alternate embodiment, responsible agent requests may proceed in a forward or reverse direction. In the forward direction, the calling application may request the agent responsible for a specific task. In the reverse direction, the calling application may request all specific tasks that an agent is responsible for. The reverse query may occur, for example, when a company wishes to temporarily assign an agent's responsibilities to another person while the agent goes on vacation. In this case, the responsibilities request 17 may contain the responsible agent.
Upon receiving the responsibilities request 17, the rules engine 12 may initiate a look up in the database 20 for all entries containing the responsible agent. The rules engine 12 may select each responsibility table in turn and select any rule which contains the responsible agent in the responsible agent field. The rules engine may send back all associated task descriptions where the responsible agent matches the received responsible agent.
In yet another embodiment, the database 20 may contain responsibility tables which contain all responsibility rules associated with a particular agent. In this case, the responsibility tables may exist in the form depicted in
In another embodiment, each rule may contain a default agent who is responsible for the specific task. In one embodiment, one table of database 20 may contain every responsibility rule found in the system 10. This table may designate an agent who will be returned as the responsible agent if the rules engine is unable to find a responsible agent for the rule in the responsible agent request. In another example, the table shown above may be augmented to include a default agent responsible at each level of the responsibilities rule hierarchy for all tasks in that level.
In yet another embodiment, the rules engine 12 may perform a series of look up sequences to locate an appropriate responsible agent. Upon receiving a responsible agent request 16, the first look up sequence may locate the responsible table corresponding to the responsibility context of the request. Finding no responsible agent, the rules engine 12 may execute a fallback sequence. The rules engine may maintain a preselected set of look up sequences for each rule. For example, unable to find the responsible agent to confirm a shopping cart from Germany of 8,800, the rules engine may next search to find the agent responsible for confirming shopping carts less than
10,000 for the neighboring countries of Germany, such as Austria. Finding nothing, the rules engine 12 may then search for anyone responsible for confirming shopping carts from any country in the European Union.
In another embodiment, late hierarchy resolutions may be used. In late hierarchy resolution, the responsibilities for all organizational subunits may be determined at query time, instead of explicitly recording them in the database. For example, a low level employee may perform the daily task of filling out purchase order forms in a purchasing department. Final responsibility to sign off on all purchase orders may, however, lie with the purchasing manager. A query in the “purchase order fulfillment” responsibility context for an agent responsible for purchases for new computers may yield the low level employee who is responsible for completing the forms. Along with this responsible agent, the database entry may contain a pointer to the individual up the chain of command who reviews the purchase orders. The reviewing agent entry may further contain a pointer to yet another higher level manager responsible for some aspect of the computer purchase order. Finally, queries up the chain of command may yield the purchasing manager, who is ultimately responsible for the purchase order.
Several embodiments of the present invention are specifically illustrated and described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
