Abstract:
The present disclosure provides methods and apparatuses for building and executing natural language policies. Using the methods and apparatus herein, users can easily program policies in a natural language intuitive manner. The user can program the natural language policy without needing to have technical knowledge of the underlying systems and without the assistance of a technical specialist.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application claims benefit to U.S. Patent Application No. 60/890,764, METHOD AND APPARATUS FOR BUILDING AND EXECUTING NATURAL LANGUAGE WORKFLOW FUNCTIONS, filed on Feb. 20, 2007; and U.S. Patent Application No. 60/939,985, METHOD AND APPARATUS FOR BUILDING AND EXECUTING NATURAL LANGUAGE WORKFLOW FUNCTIONS, filed on May 24, 2007, and the entire contents of each are incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    Businesses use a variety of policies in relation to their operations. Policies help determine what actions entities are able to take. For example, an external policy may be to only provide services to customers that have a certain credit score. Policies can apply to the internal employees of a business or to the external customers, computer systems, government agencies, suppliers of a business, etc. For example, an internal policy may be to only allow certain employees to alter customer orders. A policy is comprised of interrelated rules, entities and workflows. 
         [0003]    Through the use of technology, businesses can now model their policies programmatically. However, programming a policy into a computer system typically requires a policy designer to have a technical understanding of the underlying computer systems or to rely on a technical specialist. A policy must be constructed in the underlying computer systems which can be time consuming and difficult for the policy designers, who generally do not have the necessary technical expertise. 
       SUMMARY 
       [0004]    The present disclosure provides methods and apparatuses for building and executing natural language policies. Using the methods and apparatus herein, users can easily construct policies in a natural language intuitive manner. The user can construct the natural language policy without needing to have technical knowledge of the underlying systems and without the assistance of a technical specialist. 
         [0005]    Additional features and advantages are described herein, and will be apparent from, the following Detailed Description and the figures. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0006]      FIG. 1  is a high level block diagram of an example design system. 
           [0007]      FIG. 2  is a more detailed block diagram showing one example of a designer terminal. 
           [0008]      FIG. 3  is a more detailed block diagram showing one example of a policy server. 
           [0009]      FIG. 4  is a flowchart of an example process for building and executing a natural language policy. 
           [0010]      FIG. 5  is an example of a grammar design screen. 
           [0011]      FIG. 6  is an additional example of a grammar design screen. 
           [0012]      FIG. 7  is an example of a policy design screen. 
           [0013]      FIG. 8  is an additional example of a variable selection screen. 
           [0014]      FIG. 9  is an additional example of a policy design screen. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]    A high level block diagram of an exemplary design system  100  is illustrated in  FIG. 1 . The illustrated system  100  includes one or more designer terminals  102  (the designer terminal  102  may be a policy designer terminal, grammar designer terminal, function designer terminal, a single terminal for the different design needs or any other combination thereof), one or more policy servers  104 , and one or more policy databases  106 . Each of these devices may communicate with each other via a connection to one or more communications channels  108  such as the Internet or some other data network, including, but not limited to, any suitable wide area network or local area network. It will be appreciated that any of the devices described herein may be directly connected to each other instead of over a network. 
         [0016]    The policy server  104  stores a plurality of files, programs, and/or web pages in one or more policy databases  106  for use by the designer terminals  102 . The policy database  106  may be connected directly to the policy server  104  or via one or more network connections. The policy database  106  preferably stores policy data, rules, functions, entity definitions, etc. 
         [0017]    One policy server  104  may interact with a large number of designer terminals  102 . Accordingly, each policy server  104  is typically a high end computer with a large storage capacity, one or more fast microprocessors, and one or more high speed network connections. Conversely, relative to a typical policy server  104 , each designer terminal  102  typically includes less storage capacity, a single microprocessor, and a single network connection. 
         [0018]    A more detailed block diagram of a designer terminal  102  is illustrated in  FIG. 2 . The designer terminal  102  may include a personal computer (PC), a personal digital assistant (PDA), an Internet appliance, a cellular telephone, or any other suitable communication device. The designer terminal  102  preferably includes a main unit  202  which preferably includes one or more processors  204  electrically coupled by an address/data bus  206  to one or more memory devices  208 , other computer circuitry  210 , and one or more interface circuits  212 . The processor  204  may be any suitable processor, such as a microprocessor from the INTEL PENTIUM® family of microprocessors. The memory  208  preferably includes volatile memory and non-volatile memory. Preferably, the memory  208  stores a software program that interacts with one or more of the other devices in the system  100  as described below. This program may be executed by the processor  204  in any suitable manner. The memory  208  may also store digital data indicative of documents, files, programs, web pages, etc. retrieved from one or more of the other devices in the system  100  and/or loaded via an input device  214 . 
         [0019]    The interface circuit  212  may be implemented using any suitable interface standard, such as an Ethernet interface and/or a Universal Serial Bus (USB) interface. One or more input devices  214  may be connected to the interface circuit  212  for entering data and commands into the main unit  202 . For example, the input device  214  may be a keyboard, mouse, touch screen, track pad, track ball, isopoint, and/or a voice recognition system. 
         [0020]    One or more displays, printers, speakers, and/or other output devices  216  may also be connected to the main unit  202  via the interface circuit  212 . The display  216  may be a cathode ray tube (CRTs), liquid crystal displays (LCDs), or any other type of display. The display  216  generates visual displays of data generated during operation of the designer terminal  102 . For example, the display  216  may be used to display web pages received from the policy server  104 . The visual displays may include prompts for human input, run time statistics, calculated values, data, etc. 
         [0021]    One or more storage devices  218  may also be connected to the main unit  202  via the interface circuit  212 . For example, a hard drive, CD drive, DVD drive, and/or other storage devices may be connected to the main unit  202 . The storage devices  218  may store any type of data used by the designer terminal  102 . 
         [0022]    The designer terminal  102  may also exchange data with other network devices  220  via a connection to the network  112 . The network connection may be any type of network connection, such as an Ethernet connection, digital subscriber line (DSL), telephone line, coaxial cable, etc. Users of a designer terminal  102  may be required to register with the policy server  104 . In such an instance, each user of a designer terminal  102 , may choose a user identifier (e.g., e-mail address) and a password which may be required for the activation of services. The user identifier and password may be passed across the network  108  using encryption built into the designer terminal  102  browser. Alternatively, the user identifier and/or password may be assigned by the policy server  104 . 
         [0023]    A more detailed block diagram of a policy server  104  is illustrated in  FIG. 3 . Like the designer terminal  102 , the main unit  302  in the policy server  104  preferably includes one or more processors  304  electrically coupled by an address/data bus  306  to a memory device  308  and a network interface circuit  310 . The network interface circuit  310  may be implemented using any suitable data transceiver, such as an Ethernet transceiver. The processor  304  may be any type of suitable processor, and the memory device  308  preferably includes volatile memory and non-volatile memory. Preferably, the memory device  308  stores a software program that implements all or part of the method described below. 
         [0024]    In particular, the memory  308  preferably stores a designer module  312  and a policy interpretation module  314 . The designer module  312  may interface with the designer terminal  102  to create the different elements of a policy. The policy interpretation module  314  may interface with the policy database  106  to store and retrieve policy information and execute policies during system runtime. 
         [0025]    The designer module  312  allows the designer at designer terminal  102  to create the necessary components for a policy. For example, the designer terminal  102  allows a designer to program a function, create a rule, create a policy, etc. The designer module  312  allows for the development of a number of layers of elements. For example, the designer module  312  may allow a function designer to create functions that interface with a legacy system layer, a complementary system layer, etc. A function may be a section of code. The function may receive variables as inputs. The function designer or grammar designer may set the scope of a variable so that the variable may be used across multiple functions. For example, a “&lt;Product&gt;” variable may be scoped so that a “&lt;ProductCondition&gt;” and “&lt;ProductPrice&gt;” function use both contain the same “&lt;Product&gt;” variable. When a policy designer sets the object to be used as the “&lt;Product&gt;” variable, that object may used in both the “&lt;ProductCondition&gt;” and “&lt;ProductPrice&gt;” functions. 
         [0026]    The designer module  312  may have a function editor section that aids in the creation of functions based on the legacy system layer, complementary system layer, etc. The designer module  312  may store created functions into the policy database  106  or any other suitable storage media. 
         [0027]    The designer module  312  also allows a grammar designer to utilize the functions created by a function designer, or other pre-existing functions to create grammars through a graphical user interface. An example graphical user interface for a grammar designer is shown in  FIG. 5 . A grammar designer may contain an interpreter that recognizes a syntax, the syntax being the native executable parts that the interpreter may execute to do calculations on data or to direct the flow of logic. The syntax may support the execution of functions as well as static methods in third party assemblies. Functions and static assembly methods may be included in syntax expressions that the interpreter executes. 
         [0028]    Grammars may comprise rules that utilize functions in a user friendly, understandable manner. Rules include logical connections between functions. Rules may contain operators and variables that the grammar designer can set options for. For example, a rule in a grammar may be “if &lt;ProductCondition&gt; then &lt;Statement&gt;” an example of the rule in the example graphical user interface is provided in  FIG. 6 . The grammar designer may specify the options that may be selected for “&lt;ProductCondition&gt;” and “&lt;Statement&gt;.” For example, the “&lt;ProductCondition&gt;” may be bound so that only a Product&#39;s legal age requirement for purchasing is selectable during policy design. By binding the variables, a grammar designer may create a domain specific Rule, where the domain specific rule&#39;s variable is limited by the options available in a specific domain or execution environment (e.g., to one of a predetermined set of variables names and/or a specific numeric range). A grammar designer may bind a variable to multiple layers of functions or other rules. For example, the grammar designer may bind the variable “&lt;ProductCondition&gt;” so that only another function or rule may be selected for that variable. Rules may then be stored in the policy database  106  or any other suitable storage device. 
         [0029]    The designer module  312  allows a policy designer to utilize a business process workflow, a function created by a function designer or a rule created by a grammar designer, to create policies. For example, the designer module  312  may provide a graphical user interface for incorporating elements into a policy. An example graphical user interface for a policy designer is shown in  FIG. 7 . The policy designer may choose from a rule created by the grammar designer or from common pre-existing rules from the policy database  106  or any other suitable storage device. The policy designer may then select the option for a variable in a rule, as shown in  FIG. 8 . For example, using the rule “if &lt;ProductCondition&gt; then &lt;Statement&gt;,” the policy designer may utilize the rule and select the ProductCondition (e.g., legal age purchasing requirement is met) and Statement (e.g. allow a sale) which may be limited to certain options by the grammar designer. For example, the grammar designer may limit “&lt;ProductCondition&gt;” to a purchaser meeting the legal age requirement or the purchaser having appropriate credit. As the policy designer selects rules and options, the graphical user interface may incorporate the changes into the view of the policy. For example, by selecting the “&lt;ProductCondition&gt;” option, the graphical user interface may change a display of “if &lt;ProductCondition&gt; then &lt;Statement&gt;,” to “if the purchaser is over the state legal limit for purchasing alcohol then &lt;Statement&gt;.” In this manner the designer module  312  may present the policy designer with an interface to design a policy in a natural language manner. The graphical user interface updates the display to present a more intuitive environment for policy design based on the rule or variable value selection. The policy designer may then store the policy in the policy database  106 , or any other suitable storage device. 
         [0030]    The policy interpretation module  314  analyzes the stored policies in the policy database  106 , or any other suitable storage device. The policy interpretation module  314  may translate a policy into a declarative model (e.g. XML format). The policy module  314  may ensure that the declarative model conforms to the bindings that are supported for the rule, grammar or function. For example, the policy interpretation module  314  may ensure that only the proper objects are bound to the variables as defined by the grammar designer. 
         [0031]    The policy interpretation module  314  also tracks changes made to a policy. The policy interpretation module  314  may track two types of changes, major changes and minor changes. For example, changes to a function interface or bindings may be major changes and internal logic changes may be minor changes. For example, changing “if a customer&#39;s age is less than 21” to “if a customer&#39;s age is greater than 21” may be a minor change and the change may be tracked via a versioning system. In this way, a policy designer is able to determine what policy was in place at any given time and execution of the policy. The policy interpretation module  314  may also ensure that major changes are propagated through the system when necessary. For example, the policy interpretation module  314  may detect a change to a function and ensure that proper procedures are followed to update any rules or policies that utilize the function. Additionally, the policy interpretation module  314  may ensure that a policy designer is informed before a major policy replaces the older existing policy. 
         [0032]    The policy interpretation module  314  may execute the policy at runtime. For example, the policy interpretation module  314  may translate the declarative model into code and create an instance of the policy in memory. The policy interpretation module  314  sets the variable bindings of the policy using values from the client application. For example, the “Product” value in the client application may be used as the input for functions in a policy requiring a “Product” variable. The policy interpretation module  314  evaluates the policy using the variable inputs and returns the results to the calling client application. 
         [0033]    A flowchart of an example process  400  for building and executing a natural language policy is shown in  FIG. 4 . Preferably, the process  400  is embodied in one or more software programs stored in one or more memories and executed by one or more processors. Although the process  400  is described with reference to the flowchart illustrated in  FIG. 4 , it will be appreciated that many other methods of performing the acts associated with process  400  may be used. For example, the order of many of the acts may be changed, and some of the acts described may be optional. 
         [0034]    In this example, the function designer creates a function (block  402 ). For example, the function designer at designer terminal  102  may create a function using a graphical user interface. The function designer may create the function by allow a user to enter code in a C, C++, JAVA, etc. programming language or graphically using components from the graphical user interface. For example, the function may be a function to retrieve a condition associated with a product. For example, a Product object may have a legalAge attribute, and a function may take the Product object and return the legalAge attribute. 
         [0035]    In block  404 , a grammar designer creates a domain specific rule. For example, using a graphical user interface, an example of which is show in  FIGS. 5 and 6 , the grammar designer may create a rule to perform processing if a certain condition of a product is met. A rule may have functions as components and incorporate workflow processes, statements or entity properties. For example, a rule may be “if &lt;ProductCondition&gt; then &lt;Statement&gt;” where &lt;ProductCondition&gt; and &lt;Statement&gt; are functions from the policy database  106 . The grammar designer may set limits on the types of entities that can satisfy the variables in the rule. For example, the grammar designer may specify the types of entities that can be selected for the &lt;ProductCondition&gt; function. The grammar designer may specify that only an alcohol object entity can be selected for the &lt;ProductCondition&gt; function. In this way, the grammar designer may tailor the rule for a given domain. 
         [0036]    In block  406 , a policy designer creates a policy. For example, the policy designer may use a graphical user interface to create a policy from rules and other elements stored in the policy database  106 , or any other suitable storage device. The policy designer may select a rule and an option available for a variable within the rule. For example, the rule may state that a &lt;CustomerVariable&gt; is required, and the policy designer can select that the Customer&#39;s age would be used for the rule. The rules may be in a natural language so that the resultant policy is in a natural language as well. The natural language aspect of the rule and policy allow a non-technical policy designer to construct policies without needing to know complicated technical information about the low level systems that the policy relies upon. 
         [0037]    In block  408 , the process may store the policy. For example, the designer module  312  may store the policy into policy database  106 , or any other suitable storage device. 
         [0038]    In block  410 , the process executes the policy. For example, the policy interpretation module  314  may retrieve all existing policies associated with the particular environment from the policy database  106  and incorporate the code representing the policies into the runtime environment. When the runtime environment is instantiated the policies may be included and executed. 
         [0039]    It should be understood that various changes and modifications to the process described herein will be apparent to those skilled in the art. For example, the function designer, grammar designer and policy designer may be the same individual or a group of individuals. 
         [0040]    A screenshot of an example grammar design screen  500  is presented in  FIG. 5 . Although the example grammar design screen  500  is described in reference  FIG. 5 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0041]    The grammar design screen  500  includes graphical representations  502  of various elements that comprise a grammar. For example, functions (e.g. retrieve a product condition) may have a particular graphical representations and logic elements (e.g. if statement) may have another graphical representation. The grammar design screen  500  may also have a listing of elements  504  that may be used in the rule. For example, a rule may allow for the drag and drop insertion of a function, rule, data, etc. 
         [0042]    A screenshot of an additional example grammar design screen  600  is presented in  FIG. 6 . Although the additional example grammar design screen  600  is described in reference  FIG. 6 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0043]    The additional grammar design screen  600  includes a graphical representation  602  of a rule and the rule&#39;s elements. For example, a completed rule may be displayed with the individual logic elements, functions, etc. that comprise the rule displayed. 
         [0044]    A screenshot of an example policy design screen  700  is presented in  FIG. 7 . Although the example policy design screen  700  is described in reference  FIG. 7 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0045]    The policy design screen  700  provides a listing of elements  702  that may be used to construct the policy. For example, a policy may comprise inputs (e.g. a sales tax), entities (e.g. a liquor product), rules, workflow processes, etc. The policy designer may be able to drag and drop elements into the workspace. 
         [0046]    A screenshot of an example variable selection screen  800  is presented in  FIG. 8 . Although the example variable selection screen  800  is described in reference  FIG. 8 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0047]    The variable selection screen  800  provides a selection box  802  for variables in a rule. For example, when a rule requires a certain variable to be passed to the underlying function, the designer module  312  may allow the policy designer to select from appropriate variables as set by the grammar designer. 
         [0048]    A screenshot of an additional example policy design screen  900  is presented in  FIG. 9 . Although the additional example policy design screen  900  is described in reference  FIG. 9 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0049]    The additional example policy design screen  900  may provide a workspace  902  that displays a policy in natural language with the variables of the policy highlighted for ease of use. 
         [0050]    It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.