111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US007970713Bl
`
`c12) United States Patent
`Gorelik et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,970,713 Bl
`Jun. 28, 2011
`
`(54) METHOD AND APPARATUS FOR
`AUTOMATIC PRICING IN ELECTRONIC
`COMMERCE
`
`(75)
`
`Inventors: Vladimir Gorelik, Palo Alto, CA (US);
`Andrew Ian Atherton, San Francisco,
`CA (US); Nina Barrameda Zumel, San
`Francisco, CA (US)
`
`(73) Assignee: OIP Technologies, Inc., San Francisco,
`CA (US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 1340 days.
`
`(21) Appl. No.: 09/568,001
`
`(22) Filed:
`
`May 10,2000
`
`(51)
`
`(52)
`
`(58)
`
`(56)
`
`Int. Cl.
`G06F 17100
`(2006.01)
`U.S. Cl. ....... 705/400; 705/1.1; 705/7.29; 705/7.35;
`705/26.1; 705/26.61
`Field of Classification Search . ... ... ... ... .. ... 705/400,
`705/1.1, 7.29, 7.35, 26.1, 26.61
`See application file for complete search history.
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`3,581,072 A *
`5/1971 Nymeyer ........................ 705/37
`5,331,544 A *
`7/1994 Lu et al ........................... 705/10
`7 I 1998 Kolton et a!.
`5,778,357 A *
`..................... 707/2
`5,873,069 A *
`2/1999 Reuhl eta!. ..................... 705/20
`6,196,458 B1
`3/2001 Walker et al.
`6,230,150 B1 *
`5/2001 Walker et al .................. 705/400
`6,233,564 B1
`5/2001 Schulze, Jr.
`6,424,949 B1
`7/2002 Deaton et a!.
`6,477,180 B1
`1112002 Aggarwal eta!.
`6,539,392 B1 *
`3/2003 Rebane ......................... 707/101
`
`wo
`
`FOREIGN PATENT DOCUMENTS
`wo 02/010961
`* 7/2001
`
`OTHER PUBLICATIONS
`
`"Navigating the Intersection of forecasting, market research and
`pricing" by Cook, Aug. 1995, Pharmaceutical Executive, v15, n8, p.
`54-58.*
`"Pricing research for decision making" by Mohn, winter 1995, Mar(cid:173)
`keting Research, a Magazine of Management & Applications, v &n1
`p. 10-19.*
`"Pricing decision in small firms: Theory and practice" by Cun(cid:173)
`ningham, 1993, Management Decision, v31n& p. 46-55.*
`A guide to conducting marketing research on the Internet by
`Emery,Jan. 1996 in Potentials in Marketing v23, n1, p22, entire
`document.*
`* cited by examiner
`
`Primary Examiner- Janice A. Mooneyham
`Assistant Examiner- Michael J Fisher
`(74) Attorney, Agent,
`or Firm- Hickman Palermo
`Truong & Becker LLP
`
`ABSTRACT
`(57)
`An automatic pricing method and apparatus for use in elec(cid:173)
`tronic commerce environments is described. Automatic pric(cid:173)
`ing uses live price testing to estimate and measure demand for
`specific products-taking into account where appropriate, a
`vendor selected segmentation scheme. The results of live
`price testing are compared using a vendor selected goal func(cid:173)
`tion, e.g. profit maximization, to select a new price. A goal
`function that balances short term gains versus long term gains
`based on customer lifetime value is described. The live price
`testing approach used is designed to minimize losses due to
`price testing through statistical methods. Additionally, meth(cid:173)
`ods for distributing price testing across time so as to avoid
`problems caused by too many ongoing tests as well as side
`effects from testing are described. The selected price is a win
`for both purchasers and vendors as the automatic price will
`approximate the efficiency of a reverse auction without the
`inconvenience of the auction format while being goal maxi(cid:173)
`mizing for the vendor. For example, a vendor that normally
`sets prices of items for sale to customers can use embodi(cid:173)
`ments of the invention to great effect.
`
`62 Claims, 7 Drawing Sheets
`
`Pricing Control 700
`
`Explic~ Request
`
`702 --+--
`
`List Of
`Pricing Units
`To Test
`710
`
`Select
`712
`
`Monitor
`716
`
`Calibrate
`
`714
`
`Apple Exhibit 1052
`Apple Inc. v. Smartflash LLC
`CBM2015-00121
`Page 00001
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 1 of7
`
`US 7,970,713 Bl
`
`LC')
`0
`
`::l
`
`T""" u
`"'C e a..
`
`Q)
`C>
`
`ro a..
`.c
`~·
`
`,.......,
`~
`<(
`....
`0 ·-....
`a..
`.._._...,.
`
`•
`
`(!) -LL
`
`\
`\
`\
`\
`\
`\
`\
`\
`\
`\
`Q)
`rJ)
`roC'\1
`.Co
`~T"""
`ro
`0
`
`I
`
`..
`...
`
`r
`
`\
`
`I
`
`0
`0
`T"""
`L...
`Q)
`~
`Q) en
`.c
`~
`
`...
`...
`
`... ..
`
`0
`T"""
`T"""
`rJ)
`C>
`0
`...J
`
`Page 00002
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 2 of7
`
`US 7,970,713 Bl
`
`....
`•
`0 - ·-....
`(!)
`LL c..
`
`...........
`
`' \
`
`\
`J
`
`I
`
`/
`
`{
`\
`\
`\
`I
`I
`
`I
`
`/
`
`I
`\
`\
`\
`\
`J
`
`/
`
`""'
`
`N
`0
`N
`"'0 c
`ro
`E
`~"\..
`I
`' \
`'
`
`y
`
`Page 00003
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 3 of7
`
`US 7,970,713 Bl
`
`300 "'
`
`Seasonality 302
`
`Pricing Unit 310
`.¥
`I
`I
`I
`' , I /
`-w
`
`SKU 304
`
`Customer Segment 306
`
`320 "' Q
`
`Demand Curve 322
`
`/
`
`- ........
`
`/
`
`Relative Expected
`Value 324
`/
`,¥
`\
`
`\
`\
`
`p
`FIG. 3
`
`Page 00004
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 4 of7
`
`US 7,970,713 Bl
`
`-LL
`
`..92
`:::J
`"'C
`0
`~0
`'I'"""
`0)....,.
`c:
`T5
`·;:: a..
`
`,,
`
`t ro
`EO
`_.....,.
`roO
`ca
`0
`
`r - - - - - - - - - - - - -
`I
`t
`
`C\1
`C\1
`.....,.
`0
`:::J
`
`"'0 e a..
`t
`
`I
`I
`I
`I
`I
`
`0
`0
`'I'"""
`L...
`Q)
`2:
`Q)
`(f)
`..0
`
`~
`
`0
`C\1
`.....,.
`Q)
`0)
`
`..0
`
`ro a..
`~
`
`)
`
`I
`
`Q)
`CJ)
`roN
`..Co
`2'1'"""
`ca
`0
`
`1\
`
`v
`
`...
`
`0
`'I'"""
`'I'"""
`
`CJ)
`0)
`0
`...J
`
`Page 00005
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 5 of7
`
`US 7,970,713 Bl
`
`•
`
`-LL
`
`•
`•
`•
`
`- ...... ·-
`
`c:::
`....
`0
`·- 0 0
`ro o)ro <0
`Ec:::-oo
`.8 "(3 ·:; lO
`::J "i:: 0"
`<(O..:.:::i
`
`ro a 0>
`+=i -~ ""¢
`ooo
`E ·c lO
`oa..
`....
`a..
`
`0>
`0
`+=i -~ N
`ro oo
`Ci5(tl0
`
`0
`·- 0>
`
`~ -~ 0 00
`c::: ·- 10
`>-'-Cla..
`
`0
`~
`""¢
`~
`::J
`"0
`0
`~
`0>
`c:::
`"(3
`"i:: a..
`
`Page 00006
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 6 of7
`
`US 7,970,713 Bl
`
`•
`
`(!) -LL
`
`N
`0 co
`<J.)
`0
`'i::
`D...
`0
`E
`ro
`
`~~I
`I
`
`/
`
`/
`
`/
`
`Page 00007
`
`

`
`U.S. Patent
`
`Jun.28,2011
`
`Sheet 7 of7
`
`US 7,970,713 Bl
`
`•
`
`(!) -LL
`
`"'¢
`or-
`,.....
`
`Q)
`......
`ctl
`I...
`..0
`ctl
`(.)
`
`(()
`or-
`,.....
`
`I...
`0
`:!:
`c::
`0
`~
`
`N
`or-
`,.....
`
`.......
`()
`Q)
`Q)
`CJ)
`
`0
`,.....
`or-
`
`(/)
`
`....
`- ·c:-
`- C)._
`o=>:G
`.~ c:: 0
`.....J ·-.~ ..,_
`I... a..
`
`-(/)
`
`Q)
`:::J
`0"
`Q)N
`O::o
`:!:,.....
`.~
`c.
`X w
`
`0
`0 ,.....
`.... c::
`
`0 I...
`
`0
`(.)
`C) c::
`'(3
`·;::
`a..
`
`Page 00008
`
`

`
`US 7,970,713 Bl
`
`1
`METHOD AND APPARATUS FOR
`AUTOMATIC PRICING IN ELECTRONIC
`COMMERCE
`
`RELATED APPLICATIONS
`
`This application relates to the following group of applica(cid:173)
`tions. Each application in the group relates to, and incorpo(cid:173)
`rates by reference, each other application in the group. The
`invention of each application is assigned to the assignee of
`this invention. The group of applications includes the follow(cid:173)
`ing.
`
`Title
`
`First Inventor
`
`Filing Date
`
`Serial
`Number
`
`Vlad Gorelik
`
`May 10,2000
`
`09/567,946
`
`Metbod and
`Apparatns for
`Determining
`Customer Lifetime
`Value and Setting
`Price
`
`BACKGROUND OF THE INVENTION
`
`20
`
`2
`And therefore, guessing the optimal price. This pricing
`approach will be referred to as manual pricing.
`FIG. 2 illustrates the impact that traditional, manual, pric(cid:173)
`ing methodologies have as demand changes over time. The
`graph 200 shows the passage of time on the X-axis. The
`relative demand of a given product overtime is represented by
`the dotted curve 202. The pricing under a manual pricing
`model is shown as the stepped solid line 204. Notice that
`while the manual price 204 can be adjusted, e.g. by a mer-
`10 chandiser, based on current market conditions, it only roughly
`tracks the demand, and therefore the optimal price.
`Thus, at times when demand is peaking-and therefore
`higher prices could be charged-the manual price does not
`15 respond. Similarly, as demand dips sharply, the manual price
`does not respond either. Further, because of the need for
`manual intervention to adjust the manual price 204, the price
`may not be adjusted frequently enough to capture either large
`or small market trends.
`As the number of items that need to be priced grows and the
`business rules for determining prices become more complex,
`the manual pricing model becomes extremely untenable.
`Some automated pricing models have been developed that
`facilitate the adjustment of manual prices based on predictive
`25 estimates of demand. These models typically emulate the
`assumptions that a merchandiser would use and can automate
`the process of adjusting prices in response to the inputs to the
`predictive models. The results do not look significantly dif-
`ferent from FIG. 2.
`In order to address the problems of manual pricing, some
`electronic commerce providers have adopted auction and/or
`reverse auction models, as well as variants. Priceline.com
`with its "Name your price"-style services for airline tickets,
`groceries, and gasoline, is a notable example of a variant of a
`35 reverse auction. However, using a reverse auction comes at
`the cost of convenience to the transaction, and in Priceli(cid:173)
`ne.com's case, consumer choice.
`Accordingly, what is needed is a pricing model that allows
`sellers to automatically adjust the prices of products, and
`40 services, for sale in non-negotiated and non-auction settings
`to provide efficient pricing for both buyers and sellers. Fur(cid:173)
`thermore, an approach for determining the lifetime value of a
`customer should be provided to allow the vendor to set prices
`that balance long term gains, e.g. customer repeat business,
`45 versus short term gains.
`
`1. Field of the Invention
`This invention relates to the field of pricing. In particular,
`the invention relates to methods and apparatus for automati(cid:173)
`cally adjusting pricing on items in an electronic commerce 30
`environment.
`2. Description of the Related Art
`Electronic commerce sites enable business to sell products
`and services to consumers and other businesses. FIG. 1
`broadly illustrates the basic configuration used by electronic
`commerce vendors. A web server 100 is coupled to a database
`102 that includes pricing information for products, e.g. the
`product 105. When a client, not shown in FIG. 1, requests a
`web page, e.g. the web page 104, over a network such as the
`Internet, the web server 100 generates the web page 104. The
`web page 104 may include a reference to the product 105, e.g.
`a textual description, a picture, and/or some other reference,
`as well as a price 106. The dashed arrows in FIG. 1 illustrate
`that the web page 104 is generated from the web server 100,
`e.g. for the manual elements of the web page 104, and the
`database 102, e.g. for dynamic information such as product
`information and pricing. Logs such as the logs 110 can be
`maintained by the web server 100 to monitor usage of the sites
`hosted by the web server 100. Additionally, other servers may
`be used by the vendor to support the electronic commerce 50
`site, e.g. application servers, customer relationship manage(cid:173)
`ment (CRM) systems, and/or other systems.
`For a particular product, e.g. a book, a compact disc, a
`plane ticket, a grocery item, etc., the pricing displayed is
`typically controlled by one or more product merchandisers. 55
`These merchandisers are people with product area specific
`qualitative knowledge. The merchandisers set prices for items
`falling within their categories of pricing expertise in conjunc(cid:173)
`tion with other business policies.
`For example, in the clothing business, there may be a 60
`product merchandiser who specializes in women's handbags
`and another in women's shoes. In order to set the price for an
`item, the merchandiser will qualitatively evaluate the market
`and the good considering factors such as: the good itself, the
`brand strength, market conditions, business goals, seasons, 65
`past sales, etc. Looked at from a microeconomics standpoint,
`the merchandiser is guessing the shape of the demand curve.
`
`SUMMARY OF THE INVENTION
`
`A automatic pricing method and apparatus for use in elec(cid:173)
`tronic commerce environments is described. Automatic pric(cid:173)
`ing uses live price testing to estimate and measure demand for
`specific products-taking into account, where appropriate, a
`vendor selected segmentation scheme. A segmentation
`scheme can be used by a vendor to differentiate between
`different types of customers as well as other aspects, a given
`product may be represented by multiple pricing units, each
`corresponding to different segments. For now, the term prod(cid:173)
`uct will be used generically to refer either products, services,
`or specific pricing units, e.g. a product or service for a par(cid:173)
`ticular segment.
`Automatically determined prices can be refined as demand
`changes over time. Accordingly, as demand for a given prod(cid:173)
`uct changes, the price determined according to the automatic
`pricing method can change. Embodiments of the invention
`can handle low volume products by testing a group of similar
`products, e.g. in the same category, simultaneously to esti(cid:173)
`mate demand for the group of products.
`
`Page 00009
`
`

`
`US 7,970,713 Bl
`
`3
`The results oflive price testing are evaluated using a vendor
`selected goal function, e.g. profit maximization, to select a
`new price. Some embodiments of the invention include pre(cid:173)
`defined goal functions for revenue maximization and profit
`maximization. Additional goal functions can be supplied by
`the vendor. Additionally, embodiments of the invention may
`include a goal function that can balance short and long term
`gains, based on the lifetime value of the customer, for the
`selected goal function.
`Brute force live price testing could have extremely high 10
`testing costs. Accordingly, a rigorous testing approach is pro(cid:173)
`vided that significantly reduces testing costs while allowing
`for estimation of demand. This approach uses statistical tech(cid:173)
`niques to estimate demand by testing a significantly smaller
`number of prices than would otherwise be required. Further, 15
`the particular testing methodology is designed to test those
`prices in a fashion that keeps the testing costs low. Addition(cid:173)
`ally, the tested prices can be selected according to competitive
`research, vendor supplied suggestions, and/or other sources.
`The live testing process can determine, using a vendor 20
`selected goal function, which of the tested prices are better
`and worse than the current price for the product to a certain
`confidence. Then, one of the better prices can be selected.
`At this point, the vendor is already doing better according
`to the goal function than she/he was doing before, e.g. making 25
`more money. However, the testing process can be continued
`to refine the price.
`Once the automatically determined price is set, monitoring
`of what actually occurs can be compared against the predicted
`results for a price. If there is sufficient variance from the 30
`prediction, the product can be re-tested to select a new auto(cid:173)
`matic price.
`Additionally, methods for distributing price testing across
`time so as to avoid problems caused by too many ongoing
`tests as well as side effects from testing are described. For 35
`example, if Reebok™ shoes are price tested while leaving
`Nike™ shoes prices at the same level, the estimation of
`demand will be inaccurate. Accordingly, testing is distributed
`over time with related products price tested concurrently.
`The selected price according to the automatic pricing is a 40
`win for both purchasers and vendors. The automatic price will
`approximate the efficiency of a reverse auction, a plus for the
`purchaser, without the inconvenience of the auction format.
`At the same time, the selected price is goal maximizing for the
`vendor. Accordingly, vendors with non-negotiated, non-auc- 45
`tion pricing of products can use embodiments of the invention
`to great effect.
`Additionally, embodiments of the invention offer features
`automatic price selection during liquidation using a similar
`live price testing method with a different goal function.
`Embodiments of the invention can be provided as an out(cid:173)
`sourced service by a third party, e.g. Pricing Provider, to
`vendors, e.g. Vendor X. Through the establishment of com(cid:173)
`munications links between Vendor X's electronic commerce
`facilities and the Pricing Provider, prices for items seen by 55
`purchasers to the Vendor X's web site can be provided by the
`Pricing Provider. Alternatively, the vendor herself/himself
`can be provided embodiments of the invention, e.g. software
`and/or hardware, to provide pricing services.
`
`BRIEF DESCRIPTION OF THE FIGURES
`
`FIG. 1 illustrates a prior art electronic commerce system.
`FIG. 2 demonstrates the effect of manual pricing as
`demand adjusts.
`FIG. 3 illustrates the segmentation model used to identify
`pricing units and a demand curve for a pricing unit.
`
`4
`FIG. 4 illustrates an electronic commerce system accord(cid:173)
`ing to one embodiment of the invention.
`FIG. 5 illustrates components of a pricing module accord(cid:173)
`ing to one embodiment of the invention.
`FIG. 6 demonstrates the effect of automatic pricing as
`demand adjusts.
`FIG. 7 illustrates the feedback loop controlling pricing.
`
`DETAILED DESCRIPTION
`
`A. System Overview
`Electronic commerce vendors face unique hurdles in estab-
`lishing prices. First, the present day marketplace is such that
`a number of competitors will price items at, or below, cost.
`How should a vendor respond to those actions? Similarly,
`with shopping robots, or agents, consumers who are price
`conscious can easily search dozens of similar vendors for a
`particular good or service drastically increasing the speed at
`which pricing changes influence customer perceptions.
`One solution is to move away from traditional, or manual,
`pricing towards a more automatic pricing model. This model
`is designed to help vendors price their products and services,
`appropriately, even when competitors are dropping prices or
`some customers are so value conscious they are using shop(cid:173)
`ping robots.
`Further this model is able to measure actual, current
`demand for a particular product-and more particularly a
`particular pricing unit-through live price testing. Those
`results can be incorporated to allow a vendor to optimize each
`price according their pricing strategy.
`First, the conceptual framework used by embodiments of
`the invention will be considered. Next, the configuration of an
`electronic commerce environment according to embodiments
`of the invention will be considered. Then, the methods for
`testing and adjusting prices will be considered in greater
`detail with reference to the goals of automatic pricing.
`Finally, additional embodiments of the invention will be con(cid:173)
`sidered.
`B. Conceptual Framework
`Pricing for an item should be capable of taking into account
`factors other than just the particular item. More specifically, a
`segmentation model such as the segmentation model 300 of
`FIG. 3 can be used to set prices at a finer grained level.
`Embodiments of the invention are flexible enough to account
`for vendor specific segmentation schemes.
`The segmentation model 300 is an example segmentation
`scheme used by vendors according to some embodiments of
`the invention. Three segmentation axes are defined: SKU 304,
`e.g. individual pricing units for a product; seasonality 302;
`50 and customer segments 306. The customer segments 306 may
`be defined according to the system used by the customer, e.g.
`from clustering or other data analysis techniques. Similarly,
`the seasonality 302 can be determined from the vendor's data.
`Thus, for a particular SKU, e.g. a Brand X Pocket
`Umbrella, there may be multiple pricing units, e.g. the pricing
`unit 310, for each customer segment and season. Thus, the
`pricing unit 310 may represent the umbrella for new custom(cid:173)
`ers (a segment) in winter. Which can be discretely priced as
`compared to existing customers for that same season as rep-
`60 resented by a different pricing unit 310.
`Further, although the discussion thus far has been in terms
`of products, the discussion applies with equal force to ser(cid:173)
`vices, e.g. airline tickets, etc. Also, sometimes the discussion
`may refer to a web page, or web site, etc., including a product.
`65 For obvious reasons, most tangible goods-and even digital
`goods-are not actually part of the web site, but rather some
`reference to them is included in the web site, e.g. photograph,
`
`Page 00010
`
`

`
`US 7,970,713 Bl
`
`5
`narrative description, etc. Actual fulfillment of a purchase of
`a product, whether tangible or digital, is a separate process not
`directly considered here.
`Because efficient live price testing requires a certain mini(cid:173)
`mum sales velocity, e.g. customers looking at and buying/not
`buying a product, clustering is supported within the segmen(cid:173)
`tation scheme. For example, several related products with low
`sales could be clustered together for testing as a single pricing
`unit. Similarly, several customer segments could be clustered
`to allow for the case where there are insufficient customers in
`some segments. Several examples may be helpful: the par(cid:173)
`ticular pricing unit being tested may represent Brand X
`Pocket Umbrellas and BrandY Mini-Umbrellas for the cus(cid:173)
`tomer segment new customers. Similarly, the pricing unit
`may represent Brand X Pocket Umbrellas for both new and
`existing customers, etc. The particular clustering selected
`may be determined by the vendor, by data analysis, and/or
`through an evaluation of which clusters will produce suffi(cid:173)
`cient sales velocity for live price testing. The particular clus(cid:173)
`tering used at a given time can be dynamically determined
`and adjusted, e.g. based on current sales velocity.
`Returning to the pricing model, from microeconomics, we
`can predict that for a given pricing unit, e.g. the pricing unit
`310 (a Brand X Pocket Umbrella, winter season, new custom(cid:173)
`ers ), a demand curve will exist as shown in the graph 320 of
`FIG. 3. The demand curve 322 is shown as a solid line. As in
`standard economic theory, the curve is downward sloping so
`that as price increases, quantity decreases.
`Similarly, the relative expected value 3 24 shown as a dotted
`line represents the value of selling different quantities. The
`relative expected value 324 can represent price times quan(cid:173)
`tity, e.g. revenue. Other expected value functions may be
`used, e.g. profit, e.g. price less cost multiplied by the quantity,
`etc. For a given pricing unit, the expected value 324 has a
`maximum. Ideally, the pricing model should select the price
`corresponding to that maximum at all times.
`The precise shape of the demand curve 322 in FIG. 3 is
`based on conjecture. The actual demand curve may vary
`substantially from a predicted demand curve and will change
`over time, e.g. as in FIG. 2 where the demand 202 changes
`over time. The estimation of actual demand therefore is a
`process used by embodiments of the invention to set prices.
`However, for the same reason that the demand curve 322
`cannot easily be exactly measured, the expected value 324, is
`not easy to determine. Accordingly, in order to set a price that 45
`will come close to maximizing expected value over time, a
`systematic approach to determining the demand curve 322
`must be used.
`The environment used by embodiments of the invention
`will now be considered together with the configuration of an 50
`electronic commerce vendor to use embodiments of the
`invention.
`C. Architecture Configuration and Details
`FIGS. 4 and 5 illustrate the system environment used by
`embodiments of the invention in greater detail. The configu(cid:173)
`ration of FIG. 4 is designed in to interface with existing
`electronic commerce systems, e.g. the electronic commerce
`environment of FIG. 1.
`Architecture
`The following lists the elements of FIG. 4 and describes
`their interconnections. FIG. 4 includes the web server 100,
`the database 102, the logs 110, the datamart 400, the pricing
`module 410, and the web page 420. The web page 420
`includes the product 422 and the price 424.
`The following describes the uses of the elements of FIG. 4. 65
`The web server 100 is a web server. Standard web servers
`such as Apache™ and Internet Information Server™ can be
`
`6
`used as the web server 100. The web server 100 produces log
`files, e.g. the logs 110. The logs 110 will include standard
`information as that found in a common logfile format, or other
`specialized information. For example, if the web server 100
`can identifY the paths of individual users, then per user infor(cid:173)
`mation could be reviewed instead of, or in addition to, stan(cid:173)
`dard web logs. The common logfile format is better described
`at
`<http://www.apache.org/docs/mod/mod_log_com(cid:173)
`mon.html>. Additionally, the logs 110 may include transac-
`10 tion logs of completed purchases made using the web server
`100.
`The electronic commerce environment of FIG. 4 differs
`from the prior art systems in that prices, e.g. the price 424, is
`15 no longer provided by the vendor's database, e.g. the database
`102. Instead, the price is provided bythepricingmodule 410.
`The pricing module 410 will determine the price according to
`analysis of data in the datamart 400 and the vendor selected
`pricing approach for a pricing unit. The datamart 400 and
`20 pricing module 410 can be remotely hosted relative to the
`servers supporting the web server 100. They can also be
`operated by a third party, e.g. as hosted application. This
`could be used to allow a single third party to provide the
`datamart 400 and pricing module 410 to multiple electronic
`25 commerce vendors. Alternatively, a given electronic com(cid:173)
`merce vendor can operate their own datamart 400 and pricing
`module 410 according to specifications provided by a third
`party together with suitably provided programs. The datamart
`400 and the pricing module 410 can be supported by one or
`30 more computer systems.
`The terms "program", or "computer program", as used in
`this application, refers to any sequence of instructions
`designed for execution on a computer system. A program may
`include a subroutine, a function, a procedure, an object
`35 method, an object implementation, an executable application,
`an applet, a servlet, a source code, an object code, and/or
`some other sequence of instructions designed for execution
`on a computer system.
`Although a framework where the pricing module 410
`40 directly supplies the price to the web page is shown, the
`pricing module 410 could update the database 102. The
`choice of configurations may depend on the vendor's prefer(cid:173)
`ences as well as how the services provided by the pricing
`module 410 are licensed to vendors.
`Now, the pricing module 410 will be considered in greater
`detail. Then, the operation of different pricing modes within
`the pricing module 410 will be considered.
`Pricing Module
`FIG. 5 includes the pricing module 410. The pricing mod(cid:173)
`ule 410 includes several pricing modes: automatic pricing
`500, manual pricing 502, promotional pricing 504 and auto(cid:173)
`matic pricing for liquidation 506. Additional pricing modes
`can be provided by the supplier of the pricing module 410,
`third parties, and/or the electronic commerce vendors them-
`55 selves. The pricing modes can be implemented using one or
`more computer programs for execution on one or more com(cid:173)
`puter systems.
`The operation of the pricing module will now be consid(cid:173)
`ered in greater detail. The pricing module 410 provides an
`60 administrative interface to allow an electronic commerce
`vendor to set up their site for interaction with the pricing
`module 410. This administrative interface can be web based
`using a web server coupled to the pricing module 410.
`Additionally, the administrative interface allows the ven(cid:173)
`dor to select pricing modes on a per pricing unit basis. Thus,
`a single product may be priced using multiple pricing modes
`depending on the vendor's selection. The vendor can continu-
`
`Page 00011
`
`

`
`US 7,970,713 Bl
`
`20
`
`7
`ously adjust the pricing mode selected for an item. Additional
`administrative features are described below in connection
`with each pricing mode.
`The setup process allows the electronic commerce vendors
`to provide data about their products, or metadata. This would
`include, their segmentation scheme, categories of items,
`which items fall into which categories, etc. For example, if the
`vendor uses a particular taxonomy, or category, scheme such
`as the United Nations Standard Products and Services Codes
`(UN/SPSC), that can be used as well, e.g. for clustering 10
`products for testing purposes. Also, historical web logs and
`transaction data can be supplied through this interface. This
`provision can also continue, e.g. through streaming delivery
`of the information to the datamart 400, and the pricing mod- 15
`ule 410. The particular datamart loading procedures can be
`adjusted based on the vendor's capabilities and those of the
`selected datamart 400. For example, datamart technology
`from Sagent Technologies, Mountain View, Calif., could be
`used to provide the datamart.
`Additionally, the segmentation scheme used by the elec(cid:173)
`tronic commerce vendor can be obtained, e.g. according to
`the vendor's own datamart analysis of purchasers and prod(cid:173)
`ucts, customer relationship management (CRM) system,
`enterprise resource planning (ERP) system, and/or the ven- 25
`dar's preferences. Some embodiments of the invention sup(cid:173)
`ply a base segmentation scheme for the customer segment
`axis 306 for differentiating between new and existing custom(cid:173)
`ers. Enabling this differentiation may require additional links
`between the vendor's systems and the pricing module 410, 30
`e.g. vendor's system signals the pricing module 410 when the
`user is an existing customer. Similarly, embodiments of the
`invention can obtain seasonality data from the vendor's sys(cid:173)
`tems, e.g. the database 102, the vendor's ERP system, the
`vendor's own datamart analysis of purchasers and products, 35
`and/or other sources.
`Each of the pricing modes will now be considered in
`greater detail.
`D. Manual Pricing Mode and Promotional Pricing Mode
`The manual pricing 502 and promotional pricing 504 40
`modes are non-automated pricing modes. Traditional prior art
`techniques can be used to set pricing unit prices. The admin(cid:173)
`istrative interface may support direct retrieval of pricing from
`the vendor's database, e.g. the database 102, direct entry of
`prices, and/or retrieval of prices from some other database. 45
`The pricing can be set per pricing unit, or for all segments for
`a given product, e.g. the price for the handbag is $X.
`As noted, manual, or traditional, pricing models do not
`permit a vendor to maximize returns as shown by FIG. 2.
`However, a manual pricing mode is provided to allow vendors 50
`to select which items will be priced according to which meth(cid:173)
`ods. This may also be important if certain items must be
`priced according to contractual obligations, e.g. minimum
`price or fixed price.
`Similarly, the promotional pricing 504 mode allows a ven- 55
`dor to run promotions without respect for a particular goal.
`E. Automatic Pricing for Liquidation Mode
`Embodiments of the invention support an automatic pric(cid:173)
`ing for liquidation 506 mode. This mode allows for automatic
`price selection to enable product liquidation. Accordingly, the 60
`vendor indicates, e.g. using the administrative interface, in
`the vendor's database 102, and/or in some other database, that
`she/he would like to eliminate her stock of a product in a given
`time period, e.g. Y days. The system then automatically sets
`prices to sell the product within that time period. The demand 65
`measurement techniques described below can be used in con(cid:173)
`junction with this pricing technique; however, instead strictly
`
`8
`of applying a profit maximizing goal, the goal will be to
`maximize profit while ensuring that inventory is liquidated in
`Y days.
`Accordingly, as demand for the given inventory item is
`sampled, a price will be selected that will allow the full
`remaining quantity to be liquidated by the goal date. For
`example, suppose 100 coats remain with 10 days left to liq(cid:173)
`uidate the measurement. A price will be selected which,
`according to the measured demand, will sell the remaining
`inventory as slowly as possible (that is, at as high a price as
`possible), while still selling out by the end of the 10 day
`period.
`F. Automatic Pricing
`The automatic