WO2002041218A2

WO2002041218A2 - Dynamic calculation of prices using pricing engine

Info

Publication number: WO2002041218A2
Application number: PCT/US2001/043082
Authority: WO
Inventors: Lawrence White
Original assignee: Sun Microsystems, Inc.
Priority date: 2000-11-15
Filing date: 2001-11-14
Publication date: 2002-05-23
Also published as: WO2002041218A3

Abstract

A system and method for dynamically determining a set of relevant rule instances based on a set of context attribute values comprising a context provider configured to provide a context comprising an application configuration parameter and the set of context attribute values, an attribute data store having a hierarchical structure configured to receive the set of context attribute values and provide, based on the set of context attribute values, a set of hierarchically relevant contest attribute values, and a rules engine configured to receive a context from the context provider, provide the set of context attribute values to the attribute data store and receive the set of hierarchically relevant context attribute values from the attribute data store, and determine, based on the hierarchically relevant context attribute values from the attribut data store, a set of relevant rule instances.

Description

DYNAMIC CALCULATION OF PRICES USING PRICING ENGINE

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to a system and method for dynamically determining a transaction price using a pricing engine, and more particularly to a

system and method for dynamically determining a transaction price based on one or

more rules established between a buyer and a seller relating to a particular good or

service.

Discussion of the Related Art A number of conventional systems and methods are available for statically

pricing goods and services. These systems and methods enable providers of goods

and services to establish fixed prices on various goods and services. Additionally, conventional systems and methods may enable a provider to establish a

predetermined pricing rule for a particular good or service. For example, a

conventional system and method may enable all buyers to receive a predetermined

rebate on any product provided by seller. However, these systems and methods

have shortcomings. For example, they are inflexible in the types of rules that may

be implemented and they have slow performance. Furthermore, these systems do not offer enhanced rule instances as described in greater detail below. SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a dynamic rule

determination system and method that substantially obviates one or more of the

problems due to limitations and disadvantages of the related art.

An object of the present invention is to provide a dynamic rule determination

system and method that provides increased flexibility and efficiency over the

related art.

Another object of the present invention is to provide a dynamic rule

determination system and method that uses rule instances for dynamically

determining the price of a good and/or service.

Yet another object of the present invention is to provide a dynamic rule

determination system and method that determine the price of a good and/or service

transaction when there are competing rules relating to the transaction.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the

invention will be realized and attained by the structure and method particularly

pointed out in the written description and claims hereof as well as the appended drawings.

In one embodiment, a dynamic rule determination system and method enables an organization to buy and/or sell products and/or services with increased efficiency using a dynamic pricing model. Specifically, the dynamic rule determination system and method enables a buyer and seller to complete a

transaction in which the transaction price is based at least partially on an identity

of the buyer, an identity of the seller, and an identity of the object (e.g., the

transaction's product or service).

In another embodiment, a dynamic rule determination system and method enables an organization to buy and/or sell products and/or services using

perturbation rules. In one embodiment, whether these perturbation rules apply is at least partially determined by a buyer identity, a seller identity, and an object

identity. Accordingly, these perturbation rules are hereinafter referred to as rule

instances. For example, such a rule may establish that all members of team 1 of

Company A receive a 5% rebate on item B from Company C, whereas another rule may establish that all members of team 2 of Company A receive a 10% rebate on

item B from Company C. As can be seen, the rule instances have a buyer

component, a seller component, and an object component. Each of these components represent a node or a branch on a tree structure. The object component

relates to a product, a service, a right, a combination thereof, or other valuable consideration that is being transferred from the seller to the buyer. A particular

transaction may invoke a plurality of rules, and the system may determine which of

the rules applies to a particular transaction, apply all rules to a transaction, or use some other form of rule resolution. In one embodiment, rules reflect agreements made between a buyer and a seller.

In another embodiment, the present invention comprises a system for

dynamically determining a received transaction price based on an identity of a

buyer, an identity of a seller, and an identity of an object comprising a buyer data store, a seller data store, an object date store comprising an object having an object

base price, a rules engine that determines an applicable buyer-seller-object rule and

a price perturbation, and a conversion engine that determines the received

transaction price based on the object base price and the price perturbation.

In yet another embodiment, the present invention comprises a method for dynamically determining a transaction price comprising, determining a buyer

identity, determining a seller identity, determining an object identity, determining,

based upon the object identity, an object base price, determining a relevant buyer- seller-object rule at least partially based upon the buyer identity, the seller identity,

and the object identity, determining a price perturbation based at least partially on

the relevant buyer-seller-object rule, and determining the transaction price based

on the object base price and the price perturbation.

In another embodiment, the present invention comprises a system for dynamically determining a received transaction price based on an identity of a

buyer, an identity of a seller, and an identity of an object comprising means for

storing information relating to a buyer, means for storing information relating to a seller, means for storing information relating to an object, wherein the object has an object base price, pricing means that determines an applicable buyer-seller-object rule and a price perturbation, and a conversion engine that determines the received

transaction price based on the object base price and the price perturbation.

In still another embodiment, the present invention comprises a computer

program product, comprising a computer readable medium having computer code embodied therein for determining a received transaction price based on an identity

of a buyer, an identity of a seller, and an identity of an object, said computer

program product comprising computer readable program code devices configured as

a buyer data store, computer readable program code devices configured as a seller data store, computer readable program code devices configured as an object date store comprising an object having an object base price, and computer readable

program code devices configured as a rules engine that determines an applicable buyer-seller-object rule and a price perturbation, and computer readable program

code devices configured as a conversion engine that determines the received transaction price based on the object base price and the price perturbation.

It is to be understood that both the foregoing general description and the

following detailed description are exemplary and explanatory and are intended to

provide further explanation of the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a further

understanding of the invention and are incorporated in and constitute a part of this

specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. In the drawings:

FIG. 1 shows a diagram of a dynamic rule determination system in

accordance with the present invention;

FIG. 2 shows a diagram of a three hierarchical data stores, a buyer tee, a seller tree, and an object tree with operational identifiers;

FIG. 3 shows a diagram of a buyer tree, a seller tree, and an object tree with

unique identifiers;

FIG. 4 shows a flow chart of a dynamic rule determination method in

accordance with the present invention;

FIG. 5 shows a flow chart of a rules analysis process in accordance with the

present invention; and

FIG. 6 shows a diagram of a rules engine in accordance with the present

invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to a first embodiment of the present

invention, examples of which are illustrated in the drawings. In a one embodiment, dynamic rule determination system determines a rule value for a received context. For example, the dynamic rule determination system

may determine a discount for an item based on a received context, wherein the

context includes a buyer identity, a seller identity, an item identity, and an application configuration parameter (ACP)(i.e., rule name). To implement this and

other functions, dynamic rule determination system 100 may be configured as

shown in FIG. 1. In one embodiment, dynamic rule determination system 100

comprises a plurality of data stores. For the purpose of providing an example by which to explain the present invention, three types of data stores have been

selected: buyer data store 110, seller data store 120, and object data store 130. It is understood that different types of data stores and different numbers of data stores

may be used in accordance with the present invention.

Each of these data stores may be managed by operationally independent

organizations, such as a service-provider organization and a client organization.

Additionally, each of these data stores may be managed by an organization approved by the buyer and seller to manage rule instances. In one embodiment,

each of the data stores may be implemented as a directed acyclic graph.

Additionally, dynamic rule determination system 100 includes rules engine 140 and context provider 150. Each of these components is described in greater detail below.

Data stores 110, 120, 130, alternatively referred to as attribute data stores, comprise hierarchically structured data stores as shown in FIGS. 2 and 3. In one embodiment, data stores 110, 120, 130 are configured to receive a set of context attribute values. For example, the set of context attribute values may comprise a

buyer identity, a seller identity, an item identity. Based on these received context

attributes, data stores 110, 120, 130 may determine a set of hierarchically relevant

context attribute values. For example, as disclosed in greater detail below, if a first

context attribute value is received, a data store may determine the ancestors of the

received context attribute value and provide a set of hierarchically relevant context

attribute values including the received context attribute value and each of its ancestors.

Rules engine 140 is configured to receive a context from a context provider.

Additionally, rules engine 140 is configured to transmit context attribute values to

the corresponding attribute data store. For example, rules engine 140 transmits a buyer context attribute value to buyer data store 110, a seller context attribute

value to seller data store, and an object context attribute value to an object data

store. Furthermore, rules engine 140 is configured to receive a set of hierarchically

relevant context attribute values from attribute data stores 110, 120, 130 based on

context attribute values provided thereto. Rules engine 140 is additionally configured to determine, based on the hierarchically relevant context attribute

values from the attribute data store, a set of relevant rule instances, as explained in

greater detail with respect to FIG. 5. Context provider 150 may comprise an application, process, service or other resource that provides a context. In one embodiment, context provider 150 may also

receive an ACP value from the rules engine 140 based on the provided context. In

one embodiment, context provider 150 comprises an electronic commerce

application. Context provider 150 and rules engine 140 may be physically remote or

may be co-located. Rules engine 140 and context provider 150 may also be implemented on a single machine. The communication paths between each of the

components of FIG. 1 may be any suitable physical or logical communication channels, paths or methods, including a system bus, a network connection, and a

wireless connection.

FIG. 2 shows a diagram of a buyer tree, a seller tree, and an object tree with

operational identifiers. Specifically, FIG. 2 shows buyer organization chart 2100,

seller organization chart 2200, and object catalogue 2300. Trees 2100, 2200, 2300 may be represented, for example, in an LDAP server, in a relational database, an

XML document, or in another type of hierarchical data structure. Additionally,

trees 2100, 2200, 2300 may be dynamically generated when a transaction is

received by rules engine 140.

By way of example, buyer organization chart 2100 depicts an organization for

Buyer 2101. Buyer 2101 has two divisions, Division (1) 2110 and Division (2) 2120.

Division (1) 2110 has three teams 2112, 2114, and 2116. Additionally, some or all of the teams may have individuals associated with the team (not shown). Similarly, Division (2) 2120 may have additional teams, individuals, or other nodes and/or leafs, which are not shown. In one embodiment, buyer organization chart 2100 is

managed entirely by Buyer 2101, such that a system in accordance with the present

invention receives updates to buyer organization chart 2100 from Buyer 2101.

5 Similarly, seller organization chart 2200 is managed entirely by Seller 2201, such

that a system in accordance with the present invention receives updates to seller

organization chart 2100 from Seller. Additionally, object catalogue 2300 may be managed by Seller 2200. However, as noted above, object catalogue 2300 may be

managed by an organization other than Seller 2200.

Lθ In one embodiment, a transaction between a buyer and a seller for a

particular object may invoke one or more hierarchically broader rule instances. Rule instances represent agreements made between a buyer and seller relating to

an object. A buyer-seller-object rule may establish a rebate available to a buyer

when a particular object is purchased from a seller. Because buyers, sellers, and

,5 objects may have several nodes and leaves as show in FIG. 2, rule instances may be

created and managed for some or all of these nodes and leaves in accordance with the present invention.

In one embodiment, rule instances may be stored in rules engine 140.

Additionally, rule instances may be stored elsewhere in 100 and transmitted to

!0 rules engine 140 at the time of a transaction. Dynamic rule determination system 100 may contain a plurality of rules relating to different buyer seller object combinations. For example, organization 1 may have rule instances established with organizations 2 and 3, and organization 2 may have rule instances established

with organizations 1, 3 and 4.

In one embodiment, a transaction between a buyer and a seller for a

particular object may invoke one or more hierarchical rule instances. In one

embodiment, all matching and hierarchically broader rule instances may apply to a

received transaction. For example, a transaction between Team (1) 2112 and

Division (2) 2220 for Object (C) 2316 may invoke a hierarchically broader buyer- seller-object rule between Division (1) 2110 and Division (2) 2220 for any object in

Category (A) 2310. The broadest buyer-seller-object rule for the hierarchies

depicting in FIG. 2 is between Buyer 2101, Seller 2200, and Catalogue 2300.

FIG. 3 shows a block diagram of a buyer tree, a seller tree, and an object tree

with unique identifiers. In one embodiment, each organization has a global unique

identifier within the system. These unique identifiers may be managed by the

manager of pricing engine 140, by a third party, such as Data Universal Numbering

System ("DUNS"), by a combination thereof or by any method that uniquely identifies an organization. The system may also associate a unique identifier with

organizations other than individual companies, such as associations, joint ventures, all buyers (e.g., a unique identifier to indicate that a rule is relevant to all buyers),

or other organizations. Additionally, each operational limit of an organization may

be assigned a local unique identifier which may be used in conjunction with unique identifier of the organization. Similarly, objects in object catalogue 2300 preferably

have unique identifiers that identify the object independent of the company that

makes the product and/or provides the service. Examples of such unique identifiers

are Universal Product Codes ("UPC") and International Standard Book Numbers

5 ("ISBN"). Additionally, the system may create its own unique identification system,

as depicted in FIG. 3.

FIG. 4 shows a flow chart of a dynamic pricing method in accordance with the

present invention. In overview the process is initiated at step 400. At step 410, a

context is received. At step 420, the rules engine determines context values for the

L0 received context. At step 430, the rules engine determines hierarchically relevant

context values for the received context. At step 440, the rules engine determines

relevant rule instances. At step 450, the rules engine resolves relevant rule

instances to a rule value. At step 460, the rules engine provides the rule value to

the context provider. The process terminates at step 470. Each of these steps is

L5 described in greater detail below.

At step 410, a context is received. This context may be received by rules

engine 140. In one embodiment, the system receives a context from an electronic

commerce application. For example, returning to the example of a system

comprising a buyer, seller and object data store, the rules engine may receive a

0 context comprising an application configuration parameter, a buyer attribute, a

seller attribute, and an object attribute. This context could be generated when a buyer has requested an object from a seller. For example, a member of Team 1 from Division 1 of Buyer may be purchasing one Object (e.g., A.A.C) from Division 1 of

Seller.

In one embodiment, the received transaction may include other information. For example, the transaction may include a number of objects involved in the

transaction, an aggregate value of objects, a combination thereof, or other information. This other information may comprise a fixed quantity (e.g., 100), or a

determinable quantity (e.g., 100 objects if the cost per object is $100 or greater, 200

objects if the cost per object is less than $100). For an example of a possible

physical and/or logical structure of a received transaction, see received transaction

650 of FIG. 6. This record may be received as a recordset, an XML document, or by other data communication methodology.

At step 420, the rules engine determines context values for the received

context. For example, using the above context, the rules engine may determine that

the received transaction was submitted by entity 1.1.1 for an object A.A.C. from 2.1. From this received transaction, the rules engine may determine that the submitting

entity was the leaf of node 1.1, and that 1.1 is similarly related to 1. These logical

tree relationships may or may not relate to which rules are relevant, which is discussed in greater detail with reference to step 430. In addition to determining

the buyer, seller, and object identities, the rules engine may determine other transaction parameters, such as an object base price. At step 440, the rules engine determines relevant rule instances. In one embodiment, all matching and hierarchically broader rule instances are relevant

rules. A hierarchically broader rule is any rule that has attribute values that are in

the set of hierarchically relevant context values, as determined in step 430. In the 5 present example, each of the following rules would be relevant as hierarchically

broader rule instances:

1.1.1, 2.1, A.A.C=Received Transaction

1.1, 2.1, A.A.C=Broader (Parent of 1.1.1)

1, 2.1, A.A.C=Broader (Grandparent of 1.1.1) .0 1.1.1, 2, A.A.C=Broader (Parent of 2.1)

1.1.1, 2.1, A.A=Broader (Parent of A.A.C)

1, 2, A=Broadest Rule (Grandparent of 1.1.1 and A.A.C, Parent of 2.1)

There are additional, unlisted, hierarchically broader rules. In addition to filtering

rules based on rule instances, other parameters ma be used. For example, if the L5 transaction has an effective date value, the rules engine may filter out all those

rules in which the received transaction does not match the effective date criteria.

In determining which rule instances are relevant, the rules engine may In one embodiment, the rules engine may retrieve all rules relating to a relevant

buyer and a relevant seller from rules data store 600 and perform additional rules 10 analysis in memory, thereby reducing the number of database accesses. In one embodiment, rules may be stored in rules data store 600, as depicted

in FIG. 6. Rules data store 600 may comprise a rule instances schema that defines

the content of data store 600. This schema may be the same or different than that

used with received transaction 650. If different, data store 600 may convert the

received transaction 650 schema such that it matches the rule instances schema.

Additionally, data store 600 may comprise a plurality of rule instances 620, 630,

640. These rules may identify the parameters by which a particular rule instances

is determined to be relevant.

For instance, using the example above, rule instances 620 and 640 may be

relevant to received transaction 650, while buyer-seller-object rule 630 may be not

relevant. Specifically, buyer-seller-object rule 640 is relevant because the received

transaction buyer, seller, and object identity are equal to the buyer-seller-object rule

640 buyer, seller, and object identity. Buyer-seller-object rule 620 is relevant

because buyer-seller-object rule 620 is a hierarchically broader rule than buyer-

seller-object rule 640 (1 is the grandparent of 1.1.1, 2 is the parent of 2.1, and A is

the grandparent of A.A.C). Buyer-seller-object rule 630 is irrelevant because buyer-

seller-object rule 630 is not hierarchically broader than buyer-seller-object rule 640

(2.2 is the sibling of 2.1).

FIG. 5 shows a flow chart of a process in accordance with the present

invention. Specifically, FIG. 5 shows a process in accordance with the present

invention in which the system In one embodiment, the present invention may be implemented using object-

oriented design patterns and an object oriented programming language.

Accordingly, the sequence of acts implemented by the present invention may be

modified without departing from the scope of the present invention. By way of specific example, the system may determine which analysis framework is applicable

at any time after the transaction has been received.

It will be apparent to those skilled in the art that various modifications and

variations can be made in the present invention without departing from the spirit or

scope of the invention. Thus, it is intended that the present invention cover the

modifications and variations of this invention provided they come within the scope

of the appended claims and their equivalents.

Claims

We claim:

1. A system for dynamically determining a set of relevant rule instances based

on a set of context attribute values comprising:

a context provider configured to provide a context comprising an application

configuration parameter and the set of context attribute values;

an attribute data store having a hierarchical structure configured to receive

the set of context attribute values and provide, based on the set of context attribute

values, a set of hierarchically relevant context attribute values; and

a rules engine configured to receive a context from the context provider,

provide the set of context attribute values to the attribute data store and receive the set of hierarchically relevant context attribute values from the attribute data store,

and determine, based on the hierarchically relevant context attribute values from

the attribute data store, a set of relevant rule instances.

2. The system of claim 1, wherein the hierarchically structured attribute data

store comprises a lightweight database application protocol compliant directory

server.

3. The system of claim 1, wherein:

the hierarchically structured attribute data store comprises a buyer data store, a seller data store, and an object data store.

4. The system of claim 3, wherein: the buyer data store is managed by a buyer organization;

5 the seller data store is managed by a seller organization that is operationally

independent from the buyer organization; and the object data store is managed by an object organization.

5. The system of claim 4, wherein buyer data store and the seller data store

LO comprise information relating to a plurality of organizations, wherein each organization has a unique identifier within the system.

6. The system of claim 5, wherein the buyer data store and the seller data store

further comprise information relating to a plurality of organization divisions, such

L5 that each organization division has a unique identifier within the system.

7. The system of claim 1, wherein the context provider comprises an electronic commerce application.

9. The system of claim 1, wherein the rules engine is configured to filter out

rules which have an attribute value that is not among the set of hierarchically

relevant context attribute values.

10. The system of claim 9, wherein the rules engine is configured to filter out

rules which have an application configuration parameter that is different than the

application configuration parameter of the context.

11. A method for dynamically determining a set of relevant rule instances based on a set of received context attribute values comprising:

receiving a context; determining a set of context values for the received context;

determining, based on the set of received context values, a set of

hierarchically relevant context values; and determining, based on the set of hierarchically relevant context attribute

values from the attribute data store, a set of relevant rule instances.

21. A system for dynamically determining a received transaction price based on an identity of a buyer, an identity of a seller, and an identity of an object

comprising: means for storing information relating to a buyer; means for storing information relating to a seller;

means for storing information relating to an object, wherein the object has an

object base price;

pricing means that determines an applicable buyer-seller-object rule and a

5 price perturbation; and

a conversion engine that determines the received transaction price based on

the object base price and the price perturbation.

22. A computer program product, comprising a computer readable medium

LO having computer code embodied therein for determining a received transaction price

based on an identity of a buyer, an identity of a seller, and an identity of an object,

said computer program product comprising:

computer readable program code devices configured as a buyer data store;

computer readable program code devices configured as a seller data store;

L5 computer readable program code devices configured as an object date store

comprising an object having an object base price; and

computer readable program code devices configured as a rules engine that

determines an applicable buyer-seller-object rule and a price perturbation; and

computer readable program code devices configured as a conversion engine

.0 that determines the received transaction price based on the object base price and

the price perturbation.