E-COMMERCE REAL TIME DEMAND AND PRICING SYSTEM AND METHOD
Cross-Reference to Related Application
This application is based on and claims priority to and the benefit of U.S. Provisional
Patent Application Serial No. 60/118,684, filed February 5, 1999, is a continuation-in-part of
U.S. Patent Application Serial No.09/390,015 filed September 3, 1999, and is a continuation-in-
part of U.S. Patent Application No. 09/565,226 filed May 4, 2000.
Technical Field
The invention relates to optimally pricing a product or service based on the real-time
demand, competitors pricing, inventory, cost of goods and the merchant pricing strategy.
Background
Electronic commerce is a rapidly growing field of business. The opportunity for
customers and for merchants to make known what they require and what they can supply,
respectively, has been greatly enhanced by the availability of communication via the Internet.
To place this development in historical perspective: in conventional commercial activity as
practiced prior to the advent of the Internet, vendors typically advertise in print media and in
electronic media such as radio and television by means of commercial messages that are
broadcast to an entire populace at large.
Customers seeking a good deal are forced to visit or call merchants to determine price and
availability of items that they wish to purchase, which can be both tedious and time consuming.
Customers can additionally place want ads in various print media that are disseminated to the
general populace, but this is typically a very inefficient process.
Today, a customer can use a personal computer to locate on the Internet or the World
Wide Web (hereinafter "the web") online storefronts and/or advertisements posted by vendors
who have specific products for sale. Readily available and easily accessible information can in
principle create a nearly perfect market where consumers can always choose the deal that suits
them best from a wide variety of offerings and suppliers can reach all prospective customers
without the need for a middleman. However, in practical experience, there are barriers on the
road to such a perfect marketplace. One barrier is information overload created by the sheer
volume of information that can be located. Another barrier is information accuracy based on the
fact that this information is highly dynamic and can change quickly in time.
There are many thousands of web sites on the Internet offering merchandise in a large
variety of categories. This merchant community is growing very rapidly. Market place (i.e.,
venues where buyers and sellers can interact) services that help users find their way through this
vast array of information are available. Examples of such services include Bottom Dollar
(www.bottomdollar.com), my Simon (www.mysimon. com), Jango (www.jango.com) and others.
Such services allow users to specify a product or service they are looking to buy and a price
range they would like to buy it at. Market place services attempt to find as many deals as
possible offered on the Internet that fall within the user specified range.
Even as the wealth of information is addressed by the market place services, or "shopping
bots" described above, no adequate solution is provided with regard to the dynamic nature of the
information. The market place services provide information that represents a "snapshot" of the
available deals as of a particular time. With the advent of selling techniques such as auctions,
classifieds and special sale events of short duration that have greatly proliferated over the
Internet, a "snapshot" provides inadequate information in real time.
A problem particular to merchants of market place services is the inability to precisely
assess customer demand for particular goods or services. Consumer demand is important to
merchants because it is an important element that drives merchant pricing, in addition to
competition, cost of goods, profit margin, inventory and market share. The reason merchants
cannot assess consumer demand is because the merchants each have only one price data point
for a given product: their own price.
The above described e-commerce market place models have made it increasingly difficult
for on-line merchants to assess the demand, and consequently, the optimal price of their goods
and services. This is true because of both the number of different types of e-commerce consumer
transactions available, as well as the speed and volume at which these transactions are
consummated.
A need thus exists for a real time demand system and method by which on-line merchants
can assess the demand of goods or services in e-commerce transactions in order to more
accurately assess the optimal price of these goods or services.
Summary of the Invention
The present invention includes a real time demand system by which on-line merchants
can assess demand for goods or services in e-commerce transactions to more accurately assess
the fair optimal price of these goods or services. The system has components for acquiring the
price data of aparticular product offered by a plurality of merchants through Internet web sites,
for acquiring the price data of a particular product actually purchased by consumers through
Internet web sites, for acquiring the price data of that product offered by a client merchant, for
acquiring the cost data of that product to the client merchant, for acquiring pricing rules from the
client merchant on which the product price can be modified, for modifying the product price
based on the above data and rules in real-time, and for applying the modified price to the web
site of the client merchant.
The present invention also includes a real time demand method by which on-line
merchants can assess demand for goods or services in e-commerce transactions to more
accurately assess the optimal price of these goods or services. The method includes acquiring
the price data of a particular product offered by a plurality of merchants through Internet web
sites, acquiring the price data of a particular product actually purchased by consumers through
Internetweb sites, acquiring the price data ofthat product offered by a client merchant, acquiring
the cost data of that product to the client merchant, acquiring pricing rules from the client
merchant on which the product price can be modified, modifying the product price in real-time
based on the above data and rules, applying the modified price to the web site of the client
merchant.
Brief Description of the Drawings
In the drawings, like reference characters generally refer to the same parts throughout the
different views. Also, the drawings are not necessarily to scale, emphasis instead generally being
based upon illustrating the principles of the invention.
FIG. 1 is a schematic overview of an embodiment of an e-commerce system showing the
interrelationships between and among the system and the end users or customers, the certified
merchants, and the remainder of the Internet;
FIG. 2 is a schematic overview of an e-commerce system;
FIG. 3 is a schematic diagram of system hardware and software that can provide
functionality to an e-commerce system;
FIG. 4 is a block diagram of the upper level hardware of the subject invention;
FIG. 5 is a block diagram of the hardware functionality of the subject invention;
FIG. 6 is a flow chart of the product purchase history data gathering program;
FIG. 7 is a flow chart of the merchant product price data gathering program; and
FIG. 8 is a flow chart of the rules engine and pricing engine programs.
Detailed Description of the Preferred Embodiments
One embodiment of the invention involves a web site on the World Wide Web with the
address www.DealTime.com (hereinafter, "DealTime.com"). The invention can be employed
in conjunction with both systems and methods for conducting demand-driven e-commerce. The
systems and methods embodied in DealTime. com enable users to exploit fully and efficiently the
dynamic, information-rich nature of the Internet generally and the World Wide Web particularly.
The systems and methods embodied in DealTime.com feature the ability to aggregate demand
by collecting user requests for products and/or services and creating economies of scale that
benefit both consumers and merchants.
In order to facilitate the above dynamic pricing methodology, in one embodiment, the
customer communicates his or her purchase requirements to the system, which stores these
requests in a computer database. In this embodiment, another portion of the database search and
track relevant merchants for offers of sale items that satisfy those requirements.
The existence of a repository of customer product requirements, traffic to merchants and
transaction information for atime period creates an opportunity to identify demand for any given
product by a number of customers, and to leverage such demand to the advantage of both
merchants and customers.
FIG. 1 is a schematic overview of an embodiment of an e-commerce system showing the
interrelationships between and among the system and the end users or customers, the certified
merchants, and the remainder of the Internet. SinceDealTime.com is aweb site, communication
between customers and DealTime.com and between certified merchants and DealTime.com
occurs over the Internet. The term "the remainder of the Internet" refers to Internet users and
web sites that are neither "customers" nor "certified merchants." Both the terms "customer" and
"certified merchant" will be described in more detail below. The DealTime Service 10 indicates
an embodiment of the methods and systems of the present invention.
The DealTime Service 10 accepts requests from customers or end users 20. A user of the
web becomes a customer by visiting the DealTime.com web site and registering a request with
the DealTime. com web site. In the following discussion, the term "desired purchase" is intended
to refer to some good or service or other thing of value that one may wish to obtain. Examples
of "desired purchases" can include but are not limited to a home appliance such as a television
that customer wishes to buy, an obj ect such as an automobile that a customer wishes to lease, or
a service such as transportation or entertainment that a customer wishes to enjoy by purchasing
a ticket or making a reservation. Other examples of benefits that a customer might seek to obtain
through the use of the invention include the provision of information that is accessible via the
Internet, such as news or financial data. A request can include a description of a desired purchase
of a customer 20, a maximum price the customer 20 is prepared to pay, a target point in the future
by which the customer 20 wants to complete the transaction, and other relevant information that
the customer 20 may provide, such as quantity required. In another embodiment, the customer
20 may provide a request based on a product or service described on the DealTime Service 10
web site. Such communications by a customer 20 are denoted in FIG. 1 by the arrow labeled
Product Selection.
FIG. 1 further depicts the interaction of the DealTime Service 10 with the remainder of
the Internet 40 or the web. The DealTime Service 10 includes a plurality of web crawlers, which
will be described in more detail below. A web crawler is a computer program or computer
process that can contact other web sites and can explore the information presented at a contacted
site. A web crawler can have the ability to search for specific information on the web, and can
both catalog the location of the information of interest that it finds, as well as downloading a
copy of some or all of the content of interest that is located.
As depicted in FIG. 1 , the DealTime Service 10 can by this web crawler capability obtain
information relating to goods and services that are available on the remainder of the Internet, and
information relating to the vendors of such goods and services. The information that can be
obtained can include offers available through online stores (e.g., vendors such as amazon.com),
offers available through auctions (e.g., offers presented via online auctioneers such as ebay.com),
and offers available by classified postings on the web. The information so obtained can be
communicated to a customer 20 who is interested in the specific good or service that is offered.
FIG. 2 is a schematic overview of the DealTime Alert Service. At the left of FIG. 2 are
depicted some of the kinds of information that is available on the web, including online auctions,
person to person auctions, classifieds, last minute deals, and sale/closeout offers. Many of these
kinds of transactions are time-sensitive. As already noted, such information relating to the offer
of goods and services can be located by one or more web crawlers 11 that are depicted as a part
of the DealTime Service 10.
The information retrieved by a crawler 11 can be stored in a Deals database 12 that is
maintained by the DealTime Service 10. The Deals database 12 contains aggregated information
from e-commerce sites. This information is sorted by the specific attributes of each product or
service. For example, desktop computers can be sorted by their manufacturer, model number,
amount of hard disk and RAM as well as other features. As a crawler 11 obtains more current
information, or new information, the Deals database 12 can be updated or augmented as
appropriate. The crawlers 11 periodically scan targeted auction, classified ad, Internet merchant
and service provider sites and bring information about new deals into the Deals database 12.
The Deals database 12 stores the product offers that are available to the online user
searching for a product. The number of offers and the level of detail are both of great
importance. The deal data is sorted into a set of Deals * tables based on product type (e.g.
DealsJLaptops) by the sorting process. The sorting process is also responsible for identifying
the different attributes of the product (e.g., processor type).
The data originates from the following sources:
1. "Crawlers" - Programs that scan a merchant site and collect the data describing the product offers on the site.
2. "Feeds" - Formatted files supplied by paying merchants that contains the product offers of the merchant.
3. "Deals Agent" - DealTime' s merchant interface that enables a merchant to create a unique product offer and store it directly in the Deals database.
Deals database 12 includes a multiple tabular format populated with the following column-
identifiers:
ID A unique identifier of the deal
DEALERLD The ID if the merchant that offers the deal
DEALTYPE DealTime offers several types of deals: Online stores, Auctions, Classified, Person-2-Person, Group Buying and Special deals (Deal Agent)
NAME The product description
ITEMSLEFT The quantity of items available in the merchant site of this product offer
PRICE The price of the product offer
STARTTIME The time when the deal was stored
ENDTIME The expiration date of the deals . This is dependent on the
DealType - auction deals expire before deals from online stores
URL A link to the product on the merchant site
CATEGORY 1,2,3... A list of categories describing the nature of the product
MANUFACTURER The manufacturer of the product offer
LOCALPRICE If the deal is from an international site - the price in the local currency of the merchant's country
LOCALCURRENCY If the deal is from an international site - the currency sign of the merchant's country
REVTEWID A link to a review describing the product
MEMBER_PRICE The price by which the product is offered to members
(and not guests) on the merchant site
IN_STOCK Is the product in stock on the merchant site
SHTPPING CO ST The cost of shipping of this product, assuming the cost is fixed
In one embodiment, DealTime. com has developed technology that enables the creation
of a crawler and a sorter dedicated to parsing a specific e-commerce site into the Deals database
12, with minimum effort and using relatively unskilled personnel. This enables DealTime.com
to add new e-commerce sites to its Deals database 12 inexpensively and at a rapid pace. The
technology has two primary components, a high level, site description language, and a dictionary
that contains the product and service description elements in many different categories. This
dictionary continuously "learns" the terms used in different areas and then identifies and
correlates such terms as various crawlers examine and parse merchant sites. The crawler (using,
for example, C++ crawlers and VisualCrawler®) downloads the URLs (HTML pages) from third-
party web sites, and parses them to extract data representing deals. The crawler may be
preprogrammed to recognize the particular format and contentunique to the third-party web site.
The crawler can then use, for example, Oracle Pro-C technology to insert the unsorted deal data
into the Deals database Deals database 12 in the Raw-Deals table. The sorter, which is a
daemon, will take those unsorted deals from the Raw-Deals table of the Deals database 12 and
sort them based on data type. It will use a dictionary of keywords, which it stores in its memory,
to categorize those deals. The dictionary can be a program that parses the new data obtained by
the crawler program from the third-party web sites, compares this data with data previously
obtained by the crawler program from third-party web sites and already added to a tabulation of
terms, and adds the new data to the pre-existing tabulation of terms if this new data is not already
present in the tabulation of terms. The output, sorted deals, are then stored in the appropriate
table in the Deals database 12.
FIG. 2 also depicts a personal computer 22 or a customer 20. The customer 20 can use
this personal computer 22 to communicate with the DealTime web site 15 via the Internet. As
depicted in FIG. 2, the customer 20 can transmit via personal computer 22 the information
necessary to initiate action by the DealTime Service 10, namely, a request for a desired product
or service, along with information that identifies the user to the DealTime Service 10, which is
collectively represented as the arrow labeled user personalization 16. This request information
is maintained by DealTime Service 10 in a user database 14 that can be accessed by the
DealTime Service 10 even when the customer' s personal computer 22 is no longer connected to
the DealTime Service 10. The user database 14 contains information about customers or users
and the products and services about which they would like to be alerted. Each user is assigned
a unique user number. Desired product and service category information is stored for each user,
as well as the user's requested notification preference and preferred type of e-commerce site.
FIG. 2 further depicts a matching engine 13 that can compare the requests of customers
20 that are recorded in user database 14 with the information about offers of goods and services
that are recorded in Deals database 12. The matching engine 13 uses highly efficient comparison
methods. When a record of an offer is found that matches a record of a request, the pertinent
information is made available to the user via any of the available notification channels that the
customer 20 has selected. The customer 20 can be notified via e-mail notification channel 17,
via Desktop Notifier using desktop notification channel 18, or by pager notification via pager
channel 19 that sends a message to the customer's Internet-based pager device through the
intermediation of a typical radio tower 123 using conventional pager technology. Desktop
Notifier is a custom software application that the customer can download from the DealTime web
site 15. This application adds a resident program to the customer's personal computer 22 that
permits the personal computer 22 to automatically connect to the DealTime web site 15. The
operation of Desktop Notifier is described more fully below.
The matching engine 13 is responsible for seeking the deals in the Deals database 12 that
match the request of the user. The matching engine 13 is used for handling request by both
online web users and users that requested tracking and notification of their requests. In
operation, the user request, called an "Item," is stored in one o f the Items_* tables of the Deals
database 12 (e.g., ItemsJLaptops). The Item line contains a set of parameters defining the user's
request (price range, product categories, etc.). The matching engine 13 queries the Deals
database 12 for deals that match these parameters. The matching engine 13 returns, for example,
200 rows of tabular data that best match the user's request. The results are stored in the
Deals_Results table of Deals database 12, from which the web site later on retrieves the results
and displays them to the user. The results are sorted according to the weight of the dealer and
then the price. Merchants with a higher weight will be displayed first, and within the same
weight group. Results will be sorted by price. Results are cached for a certain period of time.
If a user issues a request that is identical to a previous request that occurred recently, matching
engine 13 returns the results directly from the Deals_Results table of Deals database 12 and does
not re-query the Deals database 12 . The matching engine 13 canbe implemented using Oracle
stored procedures. The code can be written in the PL/SQL language and stored within the
database.
FIG. 2 also depicts a personal computer 23 of a certified merchant 30. The certified
merchant 30 can use this personal computer 23 to communicate with the DealTime web site 15
via the Internet. The certified merchant 30 can use the personal computer 23 to retrieve
information of customer demand for certain products in the Deal Data Base 12, or to obtain
information on Shopping Club status. The certified merchant 30 can use the personal computer
23 to respond to such information by submitting offers to DealTime customers 20.
FIG.3 is a schematic diagram of system hardware and software that embodies the system
and methods of the foundation DealTime technology. In FIG. 3 there is depicted the DealTime
web site 15 www.DealTime.com that serves as the entry point to the DealTime Service 10.
Communication via the Internet with the DealTime web site 15 by customers 20 and by certified
merchants 30 is routed by the local director 28 to one of the one or more web servers 29 that are
provided to handle communications . Once a connection has been established with the DealTime
Service 10 via the DealTime web site 15 and a web server 29, the DealTime Service 10 routes
the communication from the customer 20 or the certified merchant 30 to the appropriate area of
the database system 24. The database system 24 includes one or more data storage devices 25
that can be divided into storage for both user database 14 and Deals database 12. One or more
database servers 27 are provided to allow access to the database storage 25 in real time. A
database control system 26 is provided to oversee the proper operation of the database system
24, and to maintain control over access to the data storage devices 25. One or more web crawlers
11 are provided to search for specific information on the web and to retrieve information
corresponding to requests for storage within the database system 24.
Next referring to FIGS. 4-8 the e-commerce real time demand and pricing system and
method of the present invention, which can be employed with the e-commerce system of FIGS.
1-3, is shown. It will be understood that the e-commerce system of FIGS 1-3 is an exemplary
system with which the present invention can be employed, and that any system, e-commerce or
other, employing a market place format (i.e., a venue where buyer and seller can interact) is
contemplated to be within the scope of the subject invention. Specifically referring to FIG. 4,
the upper level hardware of the present invention is shown. DealTime web site 402 is in
communication with consumer 404 via the Internet in a manner previously des crib ed in reference
to FIGS. 1-3. Likewise, DealTime web site 402 is also in communication with client merchant
web sites 406 (i.e., the web sites of merchants who subscribe to the real time demand and pricing
system and method of the present invention) as well as non-client merchant web sites 408.
DealTime database 410, in communication with DealTime web site 402, is a data repository of
information pertaining to price information for products offered by non-client merchant web sites
408. Price data is compiled in deal database 410 from non-client merchant web sites 408 by use
of a crawler program described above that may be launched by DealTime web site 402 to parse
non-client merchant web site 408 for price data for a specific product, and that returns to
DealTime web site 402 with the desired pricing information for inclusion into deal database 410.
Demand database 412 is also in communication with DealTime web site 402 and provides
a compilation of the demand, i.e., the product types, the quantity of each product type and the
price of each unit of product, purchased from either non-client merchant web sites 408 or client
merchant web sites 406 through DealTime web site 402 employing the system and method
described aboveinFIGS. 1-3. Alternatively, demand database 412 can also, or instead, compile
"click-through" data from potential customers who do not actually purchase at web sites 406
and/or 408 but merely access the web page associated with the product i.e., "virtual window
shopping." The amount of "virtual window shopping" for a given product has a direct
correlation to product demand. The above described data can be stored as either raw numerical
data, or can be formatted into price or demand curves.
Merchant cost database 416 is a repository for information on cost incurred for each
separate product by client merchants. This information, which can include wholesale cost,
shipping and handling charges for example, as well as inventory, can be submitted by the client
merchant to DealTime for entry into merchant cost database 416 by DealTime, or alternatively
the cost information can be directly entered or edited by the client merchant into merchant cost
database 416 over the Internet by transmitting the data from merchant client web site 406 to
DealTime web site 402. Merchant cost database 416 is in data communication with rules engine
414, described below.
Merchant price database 418 is a repository for information on the retail price of each
separate product offered by client merchants. This information can be submitted by the client
merchant to DealTime for entry into merchant cost database 416 by DealTime, or alternatively
the price information can be directly entered or edited by the client merchant into merchant price
database 418 over the Internet by transmitting the data from merchant client web site 406 to
DealTime web site 402. Merchant price database 418 is in data communication with rules engine
414, described below.
Rules engine 414 organizes the cost data from merchant cost database 416, the price data
from merchant price database 418, and the non-client price data from deal database 410 into a
data format divided by each separate product description. Rules engine also obtains pricing rules
from the client merchants. These rules can be supplied from the client merchants to DealTime
for entry into rules engine 414, or the client merchants can employ the interface between client
merchant web site 406 and DealTime web site 402 to provide pricing rules to rules engine 414.
Pricing rules can be specific to each of the product of the client merchant, and can be based on
one or more of the following non-limiting examples : a profit margin of at least X%; price must
be atleastX% below competing merchant A; lower the price to a point where X% of consumers
have historically paid that price or higher with the last Y days; only modify the price if X or more
units are reflected in the demand data of demand database412. Pricing rules can be based upon,
for example, market share, inventory, cost, profit and/or competition factors. Obviously,
different client merchants will provide different pricing rules.
The rules engine 414 passes the above described data and pricing rules to pricing engine
424 which applies the pricing rules of a particular client merchant to the data from deal database
410, demand database 412, merchant cost database 416 and merchant price database 418 to
produce a revised purchase price for a particular product of that client merchant.
Pricing engine 424 outputs the revised purchase price to pricing checkpoint 424, which
is a software application that shows the revised product price to the client merchant for approval.
Upon approval by the client merchant, received through the client merchant web site 406
and DealTime web site 402 interface, price change subroutine 426 alters the price of that
particular product offered by that particular merchant in merchant price database 418, and may
also alter that product price on the client merchant web site 406 through DealTime web site 402.
Referring to FIG. 5, an example of the function of the hardware of FIG. 4 is shown. At
block 502 the comparison shopping service that connects millions of shoppers with thousands
of merchants is shown. DealTime collects the buying information from users who perform a
search, click to merchants or buying using the DealTime account. When someone on
DealTime.com selects a product and clicks-through to a merchant's web site 406 or 408,
DealTime records the exact product and price in real-time. This information is gathered in
aggregate form, without matching any of the users personal information. At block 504 the
system matches the exact product to the product demand database 412. This product demand
databases 412 creates or updates a demand curve every 5 minutes based on the aggregated
searching and buying information. The demand curve produced records the individual data
points for the product at various different price levels. For example, 2 different people click on
a Palm V listing on DealTime. One of these people select the Palm V at $259 at one merchant,
and the other person selects it for $289 from another merchant. From this scenario, the demand
curve would show equal demand for both prices, based on 2 data points.
All of the products featured on DealTime have an active demand curve. These demand
curves are stored within DealTime's demand data warehouse 506. This data warehouse 506
categorizes and maintains each individual demand curve in a manner that allows for the
information to be easily accessed by pricing engine 424. Each client merchant has a cost
database 416 where all of their available products are matched to their exact pricing and cost
from their suppliers. This data is passed to pricing engine 424 either through a file feed at
intervals throughout the day, or through a real-time database link at block 508. By checking the
cost, at block 510 the pricing engine 424 maintains the correct margin levels for the merchant
(the margin levels are defined by the merchant using the rules engine 414). The cost of goods
is checked within a real-time environment.
The deal database 410 is the functionality for product/price comparison across thousands
of merchant's web sites. At block 510 crawlers search specific merchant site to bring back
product and pricing information in real-time to update the listings. Part of the rule set in
dynamically generating pricing for merchants is governed by the pricing of the merchant's
competitors. All of the exact products that a merchant and its competitors carry are compared
in real-time at block 514 and stored in deal database 410 before being pulled into the pricing
engine 424. The competitive information ensures that the merchant can maintain the most
attractive pricing.
Each client merchant has to provide a detailed rules base for handling its SKUs,
categories or other product sets to merchant cost database 416 at block 516. These rules
determine the pricing strategies for the merchant' s products . Certain products will follow many
specific rules provided by the merchant, while other products may follow only one rule. The
merchant controls these product/rule relationships through a graphical user interface.
The rules engine 414 compiles the information from block 516 at block 518 and interacts
with the pricing engine 424. This rules engine 414 provides the rules set of how the merchant's
products should change based on the level of demand, pricing guidelines by the merchant and
overall buying trends of DealTime. The rules engine governs 414 the actions of the pricing
engine 424 and sets the level at which pricing conditions should be altered.
At block 520, the pricing engine 424 compiles the information from blocks 506-518 and
develops real-time pricing for all of the client merchant' s available products. For example, if the
process notices that the optimum price for the Palm V is $259, and if the merchant and rules
engine meets all conditions, the pricing engine 424 will change the price to $259.
The pricing engine 424 passes the price changes through afinal checkpoint atblock 522.
If a merchant requires final approval on a specific product(s), they can approve the pricing
change through a monitoring tool. This monitoring tool provides an overview of all product-
pricing changes and allows for approval before changes go through to the merchant price
database 418.
At block 524, once the pricing engine 424 alters a price, the product pricing within the
merchant price database 418 is changed to reflect the new pricing. Atblock 520, the new pricing
from block 524 is also reflected throughout the merchant's order fulfillment system on client
merchant web site 406. The available products for on and off-line buyers are altered. At block
528, customers can now buy at the optimized price.
Referring to FIG. 6, a flow chart of the product purchase history data gathering program
of demand database 412 is shown. At block 602, DealTime web site 402 receives product
purchase information (i.e., price, product brand and product model number) based on the
purchase by a customer of a product from client merchant web site 406 or non-client merchant
web site 408 employing DealTime web site 402. This purchase information is stored in demand
database 412 at block 604. At block 606 a demand curve is created (or updated) based on the
data received atblock 604. Atblock 608, these created demand curves are also stored in demand
database412. At block 610 the data from block 606 is exported to rules engine414 atblock 806
of FIG. 8. At block 610, the program also loops back to block 602.
Referring to FIG. 7, a flow chart of the merchant product price data gathering program
of deal database 410 is shown. At block 702 DealTime web site 702 creates a crawler program
to obtain a price specific to a product located in merchant price database 418. Atblock 704 the
crawler program is sent to a plurality of non-client merchant web sites 408 (and client merchant
web sites 406). At block 706 the crawler parses the non-client merchant web sites 408 and sends
the price data from the non-client merchant web sites 408 to DealTime web site 402. At block
708 the price data is stored in deal database 410 and is then exported to rules engine 414 atblock
804 of FIG. 8.
Referring to FIG. 8, a flow chart of the rules engine 414 and pricing engine 424 programs
is shown. At block 802, a client merchant provides pricing rules to rules engine 414. At block
804, current product price data from deal database410 is sent to rules engine414. Atblock 806,
current product purchase data is sent from demand database 412 to rules engine 414. At block
810, client merchant price data is s ent from merchant price datab ase 418 to rules engine 414. At
block 812, client merchant cost data is sent from merchant cost datab ase416 to rules engine 414.
At block 814, rules engine 414 compiles the data from blocks 804 to 812 for a desired product
of a particular client merchant compiles that merchant's pricing rules for that products, and
forwards this information to pricing engine 424 which, at block 816, calculates the optimal price
for that merchant's particular product. At block 818 pricing check point 424 communicates to
the client merchant (for example through the client merchant web site 406 and DealTime web
site 402 interface) the proposed product price change. Block 820 is a decision block. If the
client merchant does not confirm the proposed product price at block 820 the program aborts the
price change at block 822. If the client merchant does confirm the proposed product price at
block 820, the program proceeds to block 824. At block 824 price change subroutine 426
changes the price of the merchant's product to the price proposed by the pricing engine 424 in
both merchant price database 418 and on client merchant web site 406.
Variations, modifications, and other implementations of what is described herein will
occur to those of ordinary skill in the art without departing from the spirit and the scope of the
invention as claimed. Accordingly, the invention is to be defined not by the preceding
illustrative description but instead by the spirit and scope of the following claims.