WO1999056193A2 - Method and system for routing data based on a business rule stored in a relational database - Google Patents
Method and system for routing data based on a business rule stored in a relational database Download PDFInfo
- Publication number
- WO1999056193A2 WO1999056193A2 PCT/US1999/009318 US9909318W WO9956193A2 WO 1999056193 A2 WO1999056193 A2 WO 1999056193A2 US 9909318 W US9909318 W US 9909318W WO 9956193 A2 WO9956193 A2 WO 9956193A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- business rule
- component
- record
- target component
- operator
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Definitions
- the present invention relates to a method and system for routing data based on one or more business rules that are stored in a relational database.
- a business typically operates according to a number of business processes, which may be made up of one or more tasks.
- a computer manufacturer may procure materials indirectly through channels in order to fulfill its Maintenance, Repair, and Operations ("MRO") requirements.
- MRO Maintenance, Repair, and Operations
- the computer manufacturer may implement a computer-based MRO procurement approval process to obtain the materials, which process may include tasks such as creation of a purchase order document, submission of the document to a purchasing department, etc.
- a business rule is logic that is used to control the routing of data so that tasks for a particular business process can be executed. For example, within an MRO procurement approval process, a business rule may dictate that a purchase order document must be routed from a purchasing agent to his supervisor for final approval before being transmitted to a supplier. In another scenario, the business rule may include conditional task execution. Thus, another business rule may state that if the amount of the purchase order is less than some predetermined amount, then the purchase order may be routed from a purchasing agent directly to a supplier without the need for a supervisor's final approval.
- U.S. Patent No. 5.734,837 describes a software-based method and system for building business process applications in terms of the tasks that make up the business process.
- the software system has two functional sets. The first is a set of graphical tools that can be used by a developer or business analyst to map out a business process. The second is a set of tools that can be used to document and specify the attributes of each task.
- the business process and task definition structures are stored in a definitions database.
- U.S. Patent No. 5,799,297 describes workflow software, which handles processing by routing items and managing workflow based on a set of user-defined organization-specific rules.
- the rules are configured such that an activity is associated with a variable and constant by way of a comparison operator.
- a workflow engine routes tasks to one or more workers.
- a rule evaluator which is operatively coupled to the workflow engine, evaluates a plurality of organization-specific rules and provides instructions to the workflow engine for routing the tasks in a predetermined sequence.
- the rule evaluator is operatively coupled to an external program execution mechanism to execute a program instruction external to the workflow management system. In this way, the functionality of the workflow management system can be extended beyond a core workflow management feature set in the workflow engine.
- the input of complex or nested business rules typically mandates the entry of more basic business rules.
- the basic business rules are typically entered multiple times - that is, one time for each complex business rule of which they are a part. These multiple entries significantly increase the probability of erroneous input and complicate the implementation of the business process.
- the prior art typically uses complicated data processing protocols for adjudging compliance with a business rule. This tends to result in less than optimum data processing speeds and increased memory storage space requirements.
- a first aspect of this invention is directed to a method for facilitating the routing of data.
- the method includes the step of creating a record in a first table for storing a business rule.
- the business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component.
- the method also includes the steps of receiving the source component of the business rule; storing the source component of the business rule in the record of the first table; receiving the target component of the business rule; storing the target component of the business rule in the record of the first table; receiving the operator of the business rule; and storing the operator of the business rule in the record of the first table.
- a second aspect of the present invention relates to a system for facilitating the routing of data.
- the system includes a memory comprising a first table having a record for storing a business rule, wherein the business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component.
- the system also includes a processor in communication with the memory, wherein the processor is operative to receive the source component of the business rule; store the source component of the business rule in the record of the first table; receive the target component of the business rule; store the target component of the business rule in the record of the first table; receive the operator of the business rule; and store the operator of the business rule in the record of the first table.
- a third aspect of this invention is directed to a method for facilitating the routing of data.
- the method includes the step of reading a first business rule from a first record of a first table, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component.
- the method also includes the steps of evaluating the first source component of the first business rule; evaluating the first target component of the first business rule; determining whether the relation between the first source component and the first target component indicated by the operator exists; and transmitting a result indicating the determination.
- a fourth aspect of this invention relates to a system for facilitating the routing of data.
- the system includes a memory comprising a first table having a first record for storing a first business rule, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component.
- the system also includes a processor in communication with the memory, wherein the processor is operative to read the first business rule from the first record of the first table; evaluate the first source component of the first business rule; evaluate the first target component of the first business rule; determine whether the relation between the first source component and the first target component indicated by the operator exists; and transmit a result indicating the determination.
- a fifth aspect of the present invention is directed to a method for routing data.
- the method includes the steps of creating a first table having a plurality of records for storing business rules; storing a first business rule in a first record of the first table; storing a second business rule in a second record of the first table; storing a third business rule in a third record of the first table, wherein the third business rule references the first and second business rules; reading the third business rule from the third record of the first table; reading the first and second business rules from the first and second records of the first table, respectively; evaluating the first business rule; evaluating the second business rule; evaluating the third business rule based on the evaluation of the first and second business rules; and routing the data based on the evaluation of the third business rule.
- FIG. 1A depicts an exemplary business rule BRO that may be used to route data in connection with a business process.
- FIG. IB is a diagrammatic representation of a business process that includes the exemplary business rule BRO depicted in FIG. 1A.
- FIG. 2A illustrate embodiments of Tables 1 and 2 for storing attributes and business rules, respectively.
- FIG. 2B illustrates embodiments Tables 1 and 2, which have been populated with data and configured in a relational manner.
- FIG. 3 is a flow chart depicting a process for storing attributes in a table.
- FIG. 4 is a flow chart depicting a process for storing an embodiment of a basic business rule in a table.
- FIG. 5 is a flow chart depicting a process for storing another embodiment of a basic business rule in a table.
- FIG. 6 is a flow chart depicting a process for storing an embodiment of a complex business rule in a table.
- FIGS. 7A and 7B are flow charts depicting a process for evaluating complex and basic business rules, respectively.
- FIG. 8 depicts an exemplary e-commerce system architecture. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
- the present invention provides a novel and unique method and system for routing data based on one or more business rules that are stored in a relational database. In so doing, the method and system facilitates input of such business rules with minimal effort by a user and employs programming techniques of limited complexity for evaluating such rules.
- basic business rules and “complex business rules.”
- an “attribute” is data that is considered in the conduct of a business process.
- a “business rule” is logic that governs the routing of data in a business process.
- a “basic business rule” is a business rule that does not reference another business rule.
- a “complex business rule” is a business rule that references at least one other basic business rule and/or complex business rule.
- This process may be used by a computer manufacturer to procure materials indirectly through channels in order to fulfill its Maintenance, Repair, and Operations ("MRO") requirements.
- MRO Maintenance, Repair, and Operations
- the computer manufacturer may use an e-commerce system architecture, such as that shown in FIG. 8.
- This exemplary e-commerce architecture includes a plurality of workstations WS1-WSN and a server S, each of which communicate with the Internet 1 in a well-known manner.
- Server S communicates with a relational database management system
- RDBMS Remote Database System 3
- Server S is programmed with work router software that allows a processor within server S to communicate with RDBMS 3 so as to execute the functionality of the present invention.
- the business rules may be programmed by a user using a workstation WS. Although not shown, a supplier of materials to the computer manufacturer is also connected to the Internet 1.
- FIG. 1 A depicts an exemplary complex business rule BRO that may be used to route data (e.g., a purchase order document) in connection with the procurement approval process.
- complex business rule BRO references complex and basic business rules BR1 and BR2, respectively, wherein complex business rule BR1 references basic business rules BR3 and BR4.
- business rule BRO states that supervisor approval of a purchase order must be obtained if: (i) the Unit Price of the item to be purchased is greater than $1000.00; or (ii) the Quantity of the item(s) to be purchased is greater than 100 units; or (iii) the Purchase Amount (i.e.. Unit Price * Quantity) is greater than the Approval Limit of the employee making the purchase.
- FIG. IB is a diagrammatic representation of the procurement approval process.
- Block 10 represents an employee who prepares and submits a purchase order.
- the purchase request typically would include a description of an item to be purchased, a unit price for the item, and a quantity of the item.
- Decision block 20 represents the work router software run by server S that determines how to route the purchase request based on complex business rule BRO.
- the routing of the purchase request may be based on a name of an employee or a person's role in the organization (e.g., Purchasing Manager), each of which may be stored in RDBMS 3 or other memory of server S.
- business rule BRO is not TRUE.
- the purchase order would be processed as not requiring supervisor approval, and may be transmitted to the purchase department by the employee directly as represented by block 30.
- the purchasing department may take appropriate action (e.g., issue the purchase order to a supplier over the Internet 1).
- complex business rule BRO is determined to be TRUE at decision block 20
- the purchase order is transmitted to a supervisor of the employee for approval (or rejection) as represented by block 40.
- the supervisor approves the purchase order, which is then submitted to the purchasing department for appropriate action (block 30) as described above.
- BR3 and BR4 are basic business rules that are stored in a table of a relational database according to the process of FIG. 4; BR2 represents a basic business rule that is stored in a table of a relational database according to the process of FIG. 5; and BR1 represents a complex business rule that is stored in a table of a relational database according to the process of FIG. 6.
- the business rules are evaluated according to the process of FIGS. 7A and 7B.
- the relational database includes Table 1 and Table 2 as shown in FIG. 2.
- Table 1 illustrates an embodiment of a table that stores data representing one or more attributes. Referring to header R0, each row (or record) of Table 1 has an Attribute ID column that stores an identifier (e.g., a number) that uniquely identifies an attribute; an Attribute Name column that stores the name of the attribute; and an Attribute Data Type column that stores the type of the attribute stored in the Attribute Name column.
- identifier e.g., a number
- Attribute Data Type column that stores the type of the attribute stored in the Attribute Name column.
- the number and various types of attributes that may be stored in Table 1 are numerous.
- an attribute “Cost” may be stored, which has a data type equal to a value (e.g., "100"), a minimum value (e.g., "> 100"), or a maximum value (e.g., " ⁇ 100”).
- an attribute “Size” may be stored, which has a data type equal to a descriptor, such as "small,” “medium.” or "large.”
- records of Rl - R4 of Table 1 include the "Unit Price” "Quantity” “Purchase Amount,” and “Approval Limit” attributes, each of which have data types “Numeric.” While the attributes are used for business rule BRO, they may also be used for other business rules that may be stored in Table 2, without requiring re-entry of such attributes.
- Table 2 illustrates an embodiment of a table that stores data representing one or more basic and/or complex business rules.
- a business rule has a source component, a target component, and an operator component indicating a relation between the source component and the target component. These three components may be illustrated as follows: ⁇ Source> ⁇ Operator> ⁇ Target>.
- a business rule that would route data to a particular person if the cost of goods exceeds $100.00 may be represented as ⁇ Cost> ⁇ GREATER THAN> ⁇ 100>.
- a row (or record) of Table 2 has a Business Rule ID column that stores an identifier (e.g., a number) that uniquely identifies a business rule.
- Table 2 also includes a Source ID column that identifies a source component of the business rule and a Source Type column that indicates the type of source component.
- the Source Type column may identify the source component as an attribute, basic business rule, or complex business rule.
- the Source ID column refers to the Attribute ID (Table 1) of the attribute.
- the Source ID of record Rl 1 stores the value "1," which indicates the "Unit Price” attribute of record Rl of Table 1.
- the Source ID column refers to the Business Rule ID (Table 2) of the business rule.
- the Source ID of record R15 stores the value "3,” which indicates the basic business rule of record R13.
- Table 2 also includes a Target ID column that stores a target component of the business rule and a Target Type column that indicates the type of target component.
- the Target Type column may identify the target component as an attribute, basic business rule, complex business rule, or value.
- the Target ID column refers to attributes and business rules in a manner similar to that of the Source ID column.
- An Operator column stores an operator that defines a relationship between the data stored in the Source ID and Target ID columns.
- the Operator may be an arithmetic or logical operator as described above.
- FIG. 3 is a flow chart illustrating an embodiment of a process for storing an attribute in Table 1. The process is executed by the work router software of server S.
- a user operating a workstation WS inputs (enters text, selects or otherwise indicates) a name and data type for the attribute to be stored in Table 1. For example, to store the attribute of record Rl in Table 1, the user would enter "Unit Price" and "Numeric" as the name and data type, respectively.
- the software generates a unique identifier for the attribute to be stored in Table 1.
- the software stores the generated unique identifier, and the name and data type for the attribute in the Attribute ID, Attribute, and Attribute Data Type columns of Table 1 , respectively.
- the "Quantity,” “Purchase Amount,” and “Approval Limit” attributes may be stored in a similar manner. Rows R1-R4 of FIG. 2 illustrate the state of Table 1 after this process is executed for the attributes of business rules BR3, BR4, and BR2.
- FIG. 4 there is shown a flow chart of an embodiment of a process for storing a basic business rule in Table 2.
- the basic business rule has the form ⁇ Attribute> ⁇ Operator> ⁇ Value>.
- the process illustrated in FIG. 4 is executed by the work router software of server S.
- a user operating a workstation WS inputs a source attribute for the basic business rule to be stored in Table 2.
- the source attribute is processed and stored in the Source ID column of Table 2.
- the software stores the value "Attribute" in the Source Type column.
- the user may enter or otherwise indicate (e.g., by pointing and clicking) "Unit Price.”
- the software determines and stores the corresponding Attribute ID (e.g. "1 ”) in the Source ID column. In this case, the software also stores the value "Attribute" in the corresponding Source Type column.
- a user inputs an operator for the basic business rule to be stored in Table 2.
- the software determines whether the operator is compatible with the source attribute inputted at step 210. If it is compatible, then the operator is stored in the operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator. For example, to store business rule BR3 (FIG. 1) in record Rl 1 of Table 2, the user may enter the greater than sign " >.” The software determines that this is a compatible operator and stores the greater than sign " > " in the operator column of record Rl 1 of Table 2.
- a user inputs a target value for the basic business rule to be stored in Table 2.
- the software determines whether the target value is compatible with the source attribute and operator inputted at steps 210 and 220, respectively. If it is compatible, then the target value is stored in the Target ID column of Table 2. If it is not compatible, then the user may enter another target value. The software stores the value "Value" in the Target Type column.
- the user may enter " 1000" in response to the prompt.
- the software determines that the value " 1000" is compatible and stores it in the Target ID column. In this case, the software also stores "Value” in the corresponding Target Type column.
- the software At step 240, the software generates a unique identifier for the basic business rule.
- the software processes and stores the basic business rule. This process may be repeated to store other basic business rules having the form ⁇ Attribute> ⁇ Operator>
- FIG. 5 there is shown a flow chart of an embodiment of a process for storing a basic business rule in Table 2.
- the basic business rule has the form ⁇ Attribute> ⁇ Operator> ⁇ Attribute>.
- this form of basic business rule is defined by specifying a first attribute, an operator that is compatible with the type of the attribute, and a second attribute against which the first attribute will be compared.
- the process illustrated in FIG. 5 is executed by the work router software of server S.
- a user operating a workstation WS inputs a source attribute for the basic business rule to be stored in Table 2.
- the source attribute is processed and stored in the Source ID column of Table 2.
- the software stores the value "Attribute" in the Source Type column.
- the user may enter "Purchase Amount.”
- the software determines and stores the corresponding Attribute ID (here, "3") in the Source ID column. In this case, the software also stores "Attribute” in the Source Type column.
- a user inputs an operator for the basic business rule to be stored in Table 2.
- the software determines whether the operator is compatible with the source attribute inputted at step 310. If it is compatible, then the operator is stored in the operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator.
- the user may enter the greater than sign " > " in response to the prompt.
- the software determines that this is a compatible operator and stores the greater than sign " > " in the operator column of Table 2.
- a user inputs a target attribute for the basic business rule to be stored in Table 2.
- the software determines whether the target attribute is compatible with the source attribute and operator inputted at steps 310 and 320, respectively. If it is compatible, then the target attribute is stored in the Target ID column of Table 2. If it is not compatible, then the user may be prompted to enter another target attribute.
- the software stores the value "Attribute" in the Target Type column.
- the user may enter "Approval Limit.”
- the software determines that the "Approval Limit” is compatible and stores the Attribute ID for this attribute (here, "4") in the Target ID column. In this case, the software also stores "Attribute” in the Target Type column.
- the software At step 340, the software generates a unique identifier for the basic business rule.
- the software processes and stores the basic business rule. This process may be repeated to store other basic business rules having the form ⁇ Attribute> ⁇ Operator> ⁇ Attribute>.
- FIG. 6 there is shown a flow chart of an embodiment of a process for storing a complex business rule in Table 2, wherein the Complex Business Rule has one of the following forms: (i) ⁇ Basic Business Rule> ⁇ Operator> ⁇ Basic Business Rule>; (ii) ⁇ Basic Business Rule> ⁇ Operator> ⁇ Complex Business Rule>; (iii) ⁇ Complex Business Rule> ⁇ Operator> ⁇ Complex Business Rule>; or (iv) ⁇ NOT> ⁇ Basic/Complex Business Rule>.
- the storage of form (i) is now described.
- the storage of forms (ii) and (iii) is similar to the storage of form (i), as is the storage of form (iv) except that it does not utilize a source component.
- the process illustrated in FIG. 6 is executed by the work router software of server S.
- a user operating a workstation WS inputs a source business rule to be stored in Table 2.
- the source business rule is processed and stored in the Source ID column of Table 2.
- the software stores the type of business rule in the Source Type column.
- the user may enter Business Rule ID 1.
- the software determines and stores this Business Rule ID 1 in the Source ID column of record R14.
- the software also stores "Basic Business Rule" in the Source Type column.
- a user inputs an operator for the complex business rule to be stored in Table 2.
- the software determines whether the operator is compatible with the source business rule indicated at step 410. If it is compatible, then the operator is stored in the Operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator.
- the user may enter the operator "OR” in response to the prompt.
- the software determines that this is a compatible operator and stores the operator "OR” in the corresponding Operator column.
- a user inputs a target business rule for the complex business rule to be stored in Table 2.
- the software determines whether the target business rule is compatible with the source business rule and operator inputted at steps 410 and 420, respectively. If they are compatible, then the target business rule is stored in the Target ID column of Table 2. If it is not compatible, then the user may be prompted to enter another target business rule.
- the user may enter or otherwise indicate Business Rule ID 2 in response to the prompt.
- the software determines and stores this Business Rule ID 2 in the Target ID column. In this case, the software also stores "Basic Business Rule" in the Target Type column.
- FIGS. 7A and 7B are flowcharts illustrating a process for evaluating complex and basic business rules. The process uses recursion, a technique well known in the art, to break any complex rule into its basic components and to evaluate the components to arrive at a result. Of course, other non-recursive techniques may be used as desired.
- the work router software reads each of the records storing the business rules to be evaluated from Table 2.
- the work router software reads the record storing the current business rule and breaks it down into its source and target components.
- the source and target components are the left and right hand sides of the current business rule, respectively.
- the work router software reads the Source ID and Target ID fields, respectively, from the current record storing the current business rule.
- the work router software determines whether the source component of the current business rule is a complex business rule. To accomplish this, the work router software reads the Source Type field from the current record storing the current business rule. If the source component is a complex business rule, then processing continues at step 515. If it is not, then processing proceeds to step 530.
- the source component of the current business rule is set as the current business rule.
- the source component is passed back to step 510 for processing.
- the recursive process of steps 510, 515, and 520 eventually results in a source component of the then current business rule being a basic business rule.
- the work router software evaluates this basic business rule at step 530 according to the flowchart of FIG. 7B.
- the software obtains a value from a user for the attribute on the left side (source component) of the basic business rule.
- the software determines if the right side (target component) of the basic business rule is an attribute or a value. If the right side is an attribute, then processing continues at step 615. If the right side is not an attribute, then processing continues at step 620.
- the software obtains a value from the user for the attribute on right side of the basic business rule.
- the software evaluates the basic business rule using the value for the source component obtained at step 605 and the value for the target component (that is, either the value read from Table 1 or the value obtained at step 615). If the basic business rule evaluates to be "true,” then processing continues at step 630 where the software returns the result of the basic business rule (here, TRUE). If the basic business rule evaluates to be "false,” then processing continues at step 625 where the software returns the result of the basic business rule (here, FALSE). In both TRUE and FALSE situations, processing returns to step 533. At step 533.
- the work router software reads the target component of the current business rule.
- the work router software determines whether the target component of the current business rule is a complex business rule. To do so, it reads the Target ID field from the record storing the current business rule. If the target component is a complex business rule, then processing branches to step 535 for processing. If it is not, then process continues at step 545.
- the target component of the current business rule is set as the current business rule.
- the target component is passed back to step 510 for processing.
- the recursive process of steps 510, 515, and 520 eventually results in a source component of the then current business rule being a basic business rule.
- the work router software evaluates this basic business rule at step 530 according to the flowchart of FIG. 7B.
- the work router software evaluates this basic business rule according to the process depicted in FIG. 7B as described above.
- the software evaluates the source and target components of the current business rule (the values obtained and steps 530 and 545) in view of the current operator, which is obtained from the Operator field of the record storing the current business rule.
- the result of the evaluation at step 555 is returned.
- the result of the first business rule may be used to route data in connection with the business process of which business rule is a part. In the procurement approval process of the described example, the processes of
- FIGS. 7A and 7B are executed such that the work router software initially reads complex business rule BRO stored in record R15.
- the software evaluates the source component of record R15, which is embodied in the basic business rule of record R13, according to the process of FIG. 7B.
- the software determines, for a purchase order that is part of this process, whether the purchase amount is greater than the approval limit.
- the Target Type of record R15 indicates that the target component is a complex business rule.
- the complex business rule of record R14 is evaluated, which entails evaluating the business rules of records Rl 1 and R12.
- the business rule of record R14 is evaluated.
- the business rule of record R15 can be evaluated.
- the result of the complex business rule of record R15 may be used to route data in connection with the procurement approval process as described with reference to FIG. IB.
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- Human Resources & Organizations (AREA)
- General Physics & Mathematics (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Educational Administration (AREA)
- Development Economics (AREA)
- Game Theory and Decision Science (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US8371698P | 1998-04-30 | 1998-04-30 | |
US60/083,716 | 1998-04-30 | ||
US29166699A | 1999-04-14 | 1999-04-14 | |
US09/291,666 | 1999-04-14 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO1999056193A2 true WO1999056193A2 (en) | 1999-11-04 |
WO1999056193A9 WO1999056193A9 (en) | 2000-07-20 |
WO1999056193A3 WO1999056193A3 (en) | 2000-09-14 |
Family
ID=26769636
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1999/009318 WO1999056193A2 (en) | 1998-04-30 | 1999-04-29 | Method and system for routing data based on a business rule stored in a relational database |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO1999056193A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8131749B2 (en) * | 2006-01-12 | 2012-03-06 | Sony Computer Entertainment Inc. | Dynamic data hierarchies |
US8566231B2 (en) | 2004-06-17 | 2013-10-22 | Visa International Service Association | Method and system for providing buyer bank payable discounting aggregation services |
US10055202B2 (en) | 2013-02-13 | 2018-08-21 | Sandhills Publishing Co. | Business process workflow system |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5745901A (en) * | 1994-11-08 | 1998-04-28 | Kodak Limited | Workflow initiated by graphical symbols |
-
1999
- 1999-04-29 WO PCT/US1999/009318 patent/WO1999056193A2/en active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5745901A (en) * | 1994-11-08 | 1998-04-28 | Kodak Limited | Workflow initiated by graphical symbols |
Non-Patent Citations (4)
Title |
---|
GARDNER S: "The Quest to Standardize Metadata" BYTE, vol. 22, no. 11, November 1997 (1997-11), pages 47-48, XP000728722 * |
HAY ET AL: "GUIDE - Business Rules Project - Final Report" WWW.BUSINESSRULESGROUP.ORG/BRAGTV.HTM, October 1997 (1997-10), XP002140052 iNTERNET * |
STICKEL E: "Competitive Product Development in the Financial Services Industry - A Knowledge-Based Approach" INTERNATIONAL JOURNAL OF INTELLIGENT SYSTEMS IN ACCOUNTING, FINANCE AND MANAGEMENT, vol. 4, no. 4, December 1995 (1995-12), pages 273-287, XP000914011 * |
YALÇINALP ] ET AL : "Quintus WorkPro(R) Architecture: A Guide for Building Business Applications" PROCEEDINGS OF THE 2ND INTERNATIONAL CONFERENCE ON PRACTICAL APPLICATION OF PROLOG, 27 - 29 April 1994, pages 581-591, XP000913997 * |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8566231B2 (en) | 2004-06-17 | 2013-10-22 | Visa International Service Association | Method and system for providing buyer bank payable discounting aggregation services |
US8571977B2 (en) | 2004-06-17 | 2013-10-29 | Visa International Service Association | Method and system for providing seller bank receivable discounting aggregation services |
US8571978B2 (en) | 2004-06-17 | 2013-10-29 | Visa International Service Association | Method and system for providing assurance and financing services |
US8606697B2 (en) | 2004-06-17 | 2013-12-10 | Visa International Service Association | Method and system for providing buyer bank payable discounting services |
US8131749B2 (en) * | 2006-01-12 | 2012-03-06 | Sony Computer Entertainment Inc. | Dynamic data hierarchies |
US10055202B2 (en) | 2013-02-13 | 2018-08-21 | Sandhills Publishing Co. | Business process workflow system |
Also Published As
Publication number | Publication date |
---|---|
WO1999056193A3 (en) | 2000-09-14 |
WO1999056193A9 (en) | 2000-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6519578B1 (en) | System and method for processing knowledge items of a knowledge warehouse | |
JP3892987B2 (en) | Message broker data processing apparatus, method, and recording medium | |
US7584192B2 (en) | Collection and analysis of document traffic in an electronic marketplace | |
US6292894B1 (en) | System, method, and medium for retrieving, organizing, and utilizing networked data | |
US10031938B2 (en) | Determining Boolean logic and operator precedence of query conditions | |
US7603300B2 (en) | Collection and analysis of trading data in an electronic marketplace | |
US8046297B2 (en) | User interface, system and method for performing a web-based transaction | |
US7640222B2 (en) | Rules base systems and methods with circumstance translation | |
US7509328B2 (en) | Customizing software applications that use an electronic database with stored product data | |
US20050289158A1 (en) | Identifier attributes for product data stored in an electronic database | |
US20050120021A1 (en) | Metadata driven intelligent data navigation | |
US20040078776A1 (en) | System and method for browser-based arbitration in classification workflows | |
US7444344B2 (en) | Method to increase subscription scalability | |
US20060020520A1 (en) | Systems and methods for processing electronic documents in a computer network | |
US6629096B1 (en) | System and method for performing a mindflow process | |
CN102831122A (en) | Data storage method, inquiring method and inquiring device for workflow table | |
JP2009110197A (en) | Purchasing practice system, purchasing practice processing method, and purchasing practice processing program | |
KR20000012750A (en) | Method for Automatic Shopping Agent in Internet Shopping Intermediate Service | |
WO1999056193A2 (en) | Method and system for routing data based on a business rule stored in a relational database | |
US8671120B1 (en) | Method and system for manually maintaining item authority | |
US20030028443A1 (en) | Online transactions ledger | |
JP2000172770A (en) | Inter-system linking device and method | |
JP2006072884A (en) | Business project processing system | |
US6519590B1 (en) | System and method for performing a mindflow process using a mindflow document archive | |
US20020010644A1 (en) | B2B e-commerce system for plant construction implemented on web server and method thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): CN IN JP RU |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: C2 Designated state(s): CN IN JP RU |
|
AL | Designated countries for regional patents |
Kind code of ref document: C2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
COP | Corrected version of pamphlet |
Free format text: PAGES 1-18, DESCRIPTION, REPLACED BY NEW PAGES 1-17; PAGES 19-28, CLAIMS, REPLACED BY NEW PAGES 18-27; PAGES 1/3-3/3, DRAWINGS, REPLACED BY NEW PAGES 1/2-2/2; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE |
|
AK | Designated states |
Kind code of ref document: A3 Designated state(s): CN IN JP RU |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
122 | Ep: pct application non-entry in european phase |