`Apple Inc. v. Smartflash LLC
`CBM2015-00015
`Page 00001
`
`
`
`U.S. Patent
`
`Jun. 28,2011
`
`Sheet 1 017
`
`US 7,970,713 B1
`
`mow
`
`
`
` mo_.1!l..I.I....|cow._0>._mwn®>>Ho:Uo._n_
`
`
`
`
`
`2:09$n_m>>
`
`oz$3
`
`_,.9".
`
`
`
`E4..o_.n_.
`
`Page 00002
`
`
`Page 00002
`
`
`
`
`
`U.S. Patent
`
`Jun. 28,2011
`
`Sheet 2 017
`
`US 7,970,713 B1
`
`yo
`
`
`
`ManualPrice204
`
`Demand202
`
`
`FIG.2 (PriorArt)
`
`TIME
`
`Page 00003
`
`
`Page 00003
`
`
`
`U.S. Patent
`
`Jun. 28, 2011
`
`Sheet 3 017
`
`US 7,970,713 B1
`
`300
`
`Seasonality 302
`
`
`
`SKU 304
`
`Customer Segment 306
`
`Demand Curve 322
`/
`
`Relative Expected
`Value 324
`
`
`
`
`
`,»\\/
`
`\
`
`Page 00004
`
`
`Page 00004
`
`
`
`U.S. Patent
`
`Jun. 28,2011
`
`Sheet 4 017
`
`US 7,970,713 B1
`
`l"’—'-"-———_"'_—"—
`
`
`
`.vmv
`
`
`
`.$9.?.1...
`
`2:52mmnm>>
`
`o3m_:uo_>_m:_o:n_
`
`_..0_u_
`
`tmESmoO
`
`oov
`
`omw09$925
`
`mmmnfimo
`
`0mo.‘
`
`o:$3
`
`Page 00005
`
`
`Page 00005
`
`
`
`
`
`
`
`
`
`U.S. Patent
`
`n.HJ
`
`7M5mhS
`
`1_._o_Eo_.a:M.8m:_o:n_&o=mE9:<
`
`com
`
`_m.co=oEo.n_
`
`m:_o_.n_
`
`vow
`
`
`
`
`
`oz.m_%o_>_9._o_.n_
`
`7SU
`
`1B317:0
`
`7I9,mGE
`
`Page 00006
`
`
`Page 00006
`
`
`
`U.S. Patent
`
`Jun. 28, 2011
`
`Sheet 6 017
`
`US 7,970,713 B1
`
`600 /
`
` Dynamic
`Price602
`
`
`Demand202
`
`
`FIG.6
`
`TIME
`
`Page 00007
`
`
`Page 00007
`
`
`
`U.S. Patent
`
`7.m7mhSm
`
`797,SU
`
`Mo:mN:
`mmoJswam»F«E
`
`
`
`ymwscmm.._o__n_xm
`
`
`
`m=::mc_o_.n_5#2..
`
`2:.9589._o__n_
`
`«Eo:
`
`1B
`
`m.0,N....u_..._
`
`Page 00003
`
`
`Page 00008
`
`
`
`US 7,970,713 B1
`
`1
`METHOD AND APPARATUS FOR
`AUTOMATIC PRICING IN ELECTRONIC
`COMMERCE
`
`RELATED APPLICATIONS
`
`This application relates to the following group of applica-
`tions. Each application in the group relates to, and incorpo-
`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-
`ing.
`
`Title
`
`First Inventor
`
`Filing Date
`
`Serial
`Number
`
`Vlad Gorelik May 10, 2000
`
`09/567,946
`
`Method and
`Apparatus for
`Determining
`Customer Lifetime
`Value and Setting
`Price
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`This invention relates to the field of pricing. In particular,
`the invention relates to methods and apparatus for automati-
`cally adjusting pricing on items in an electronic commerce
`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 1 00 to monitor usage ofthe sites
`hosted by the web server 100. Additionally, other servers may
`be used by the vendor to support the electronic commerce
`site, e.g. application servers, customer relationship manage-
`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.
`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-
`tion with other business policies.
`For example, in the clothing business, there may be a
`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,
`past sales, etc. Looked at from a microeconomics standpoint,
`the merchandiser is guessing the shape of the demand curve.
`
`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-
`ing methodologies have as demand changes over time. The
`graph 200 shows the passage of time on the X-axis. The
`relative demand ofa given product over time 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-
`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
`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 ofitems 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
`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
`reverse auction. However, using a reverse auction comes at
`the cost of convenience to the transaction, and in Priceli-
`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
`services, for sale in non-negotiated and non-auction settings
`to provide efiicient pricing for both buyers and sellers. Fur-
`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,
`versus short term gains.
`
`SUMMARY OF THE INVENTION
`
`A automatic pricing method and apparatus for use in elec-
`tronic commerce environments is described. Automatic pric-
`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-
`uct will be used generically to refer either products, services,
`or specific pricing units, e.g. a product or service for a par-
`ticular segment.
`Automatically determined prices can be refined as demand
`changes over time. Accordingly, as demand for a given prod-
`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-
`mate demand for the group of products.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Page 00009
`
`
`Page 00009
`
`
`
`US 7,970,713 B1
`
`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-
`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
`testing costs. Accordingly, a rigorous testing approach is pro-
`vided that significantly reduces testing costs while allowing
`for estimation of demand. This approach uses statistical tech-
`niques to estimate demand by testing a significantly smaller
`number of prices than would otherwise be required. Further,
`the particular testing methodology is designed to test those
`prices in a fashion that keeps the testing costs low. Addition-
`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
`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
`more money. However, the testing process can be continued
`to refine the price.
`Once the automatically determined price is set, monitoring
`ofwhat actually occurs canbe compared against the predicted
`results for a price. If there is sufiicient variance from the
`prediction, the product can be re-tested to select a new auto-
`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
`example, if ReebokTM shoes are price tested while leaving
`NikeTM 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
`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-
`tion pricing ofproducts canuse embodiments ofthe 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-
`sourced service by a third party, e.g. Pricing Provider, to
`vendors, e.g. Vendor X. Through the establishment of com-
`munications links between Vendor X’s electronic commerce
`
`facilities and the Pricing Provider, prices for items seen by
`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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`
`FIG. 4 illustrates an electronic commerce system accord-
`ing to one embodiment of the invention.
`FIG. 5 illustrates components of a pricing module accord-
`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-
`ping robots.
`is able to measure actual, current
`Further this model
`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 ofthe invention will be con-
`sidered.
`
`B. Conceptual Framework
`Pricing for an item should be capable oftaking into account
`factors other thanjust 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;
`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-
`ers (a segment) in winter. Which can be discretely priced as
`compared to existing customers for that same season as rep-
`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-
`vices, e.g. airline tickets, etc. Also, sometimes the discussion
`may refer to a web page, or web site, etc., including a product.
`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
`
`
`Page 00010
`
`
`
`US 7,970,713 B1
`
`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 efiicient live price testing requires a certain mini-
`mum sales velocity, e. g. customers looking at and buying/not
`buying a product, clustering is supported within the segmen-
`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-
`ticular pricing unit being tested may represent Brand X
`Pocket Umbrellas and BrandY Mini-Umbrellas for the cus-
`
`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 sulfi-
`cient sales velocity for live price testing. The particular clus-
`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-
`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 324 shown as a dotted
`line represents the value of selling different quantities. The
`relative expected value 324 can represent price times quan-
`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
`carmot easily be exactly measured, the expected value 324, is
`not easy to determine. Accordingly, in order to set a price that
`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
`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-
`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.
`The web server 100 is a web server. Standard web servers
`
`such as ApacheTM and Internet Information ServerTM can be
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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-
`mation could be reviewed instead of, or in addition to, stan-
`dard web logs. The common logfile format is better described
`at
`<http://www.apache.org/docs/mod/mod_log_com-
`mon.html>. Additionally, the logs 110 may include transac-
`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
`no longer provided by the vendor’ s database, e. g. the database
`102. Instead, the price is provided by the pricing module 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
`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
`commerce vendors. Alternatively, a given electronic com-
`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
`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
`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
`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-
`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-
`ule 410 includes several pricing modes: automatic pricing
`500, manual pricing 502, promotional pricing 504 and auto-
`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-
`selves. The pricing modes can be implemented using one or
`more computer programs for execution on one or more com-
`puter systems.
`The operation of the pricing module will now be consid-
`ered in greater detail. The pricing module 410 provides an
`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-
`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
`
`
`Page 00011
`
`
`
`US 7,970,713 B1
`
`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, ifthe
`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
`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-
`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-
`tronic commerce vendor can be obtained, e.g. according to
`the vendor’s own datamart analysis of purchasers and prod-
`ucts, customer relationship management (CRM) system,
`enterprise resource planning (ERP) system, and/or the ven-
`dor’s preferences. Some embodiments of the invention sup-
`ply a base segmentation scheme for the customer segment
`axis 306 for differentiating between new and existing custom-
`ers. Enabling this differentiation may require additional links
`between the vendor’s systems and the pricing module 410,
`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-
`tems, e.g. the database 102, the vendor’s ERP system, the
`vendor’s own datamart analysis of purchasers and products,
`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
`modes are non-automated pricing modes. Traditional prior art
`techniques can be used to set pricing unit prices. The admin-
`istrative interface may support direct retrieval ofpricing from
`the vendor’s database, e.g. the database 102, direct entry of
`prices, and/or retrieval of prices from some other database.
`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
`to select which items will be priced according to which meth-
`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-
`dor to run promotions without respect for a particular goal.
`E. Automatic Pricing for Liquidation Mode
`Embodiments of the invention support an automatic pric-
`ing for liquidation 506 mode. This mode allows for automatic
`price selection to enable product liquidation. Accordingly, the
`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 ofa 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
`measurement techniques described below can be used in con-
`junction with this pricing technique; however, instead strictly
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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-
`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 pricing 500 pricing mode offered by the
`pricing module 410 is designed to help vendors automatically
`reach better pricing decisions through automatic estimation
`and measurement of actual demand to select prices. Further,
`the specific demand estimation and measurement process is
`designed to minimize losses due to the testing process.
`FIG. 6 illustrates the goals of automatic pricing with graph
`600 illustrating that the automatic price 602 for a pricing unit
`follows demand 202 for a pricing unit. Thus, the vendor is
`able to have her/his prices follow demand and receive a better
`price for the pricing unit at each time and thus greater overall
`profits. Further, because pricing unit prices are automatically
`determined using a mixture of: live price testing; competitive
`information (what competing vendors are charging for a
`product as determined through price checking and/or shop-
`ping agents); as well as any vendor supplied information, e.g.
`cost, merchandiser recommendations, manufacturer’s sug-
`gested retail price, etc. This information can be provided
`through the administrative interface, from the vendor’s data-
`base 102, and/or other databases. A dedicated shopping robot
`can be used, widely available shopping robots can be used,
`and/or human price shoppers can be used to obtain competi-
`tive pricing information.
`The use of inputs, e.g. competitors’ prices, serves to pro-
`vide test points for the live testing process and also, when
`appropriate, as a “tie” breaker between two prices that have
`very similar results based on live price testing, e.g. take the
`price the competitor is using if the performance difference
`between the best found price and the competitor’ s price is less
`than some predetermined amount. However, in automatic
`pricing 502 mode, it is the actual results of the live price
`testing that determine the price.
`Ultimately, the vendor can choose to override the selected
`price, e.g. by selecting the pricing unit for manual pricing.
`However, this is not recommended for the reason that the
`automatically determined price will be based upon actual
`demand—a quantitatively determined amount—whereas the
`manually set price is based on qualitative assumptions and
`models. As such, the automatically determined price will be
`goal maximizing, e.g. profit, revenue, etc. Further, as dis-
`cussed below, the automatically determined price can account
`for customer lifetime value.
`
`G. Price Testing Method
`The estimation and measurement of actual demand
`
`through live price testing enables various pricing modes to
`automatically select prices. The demand testing process will
`be described with reference to automatic pricing 502 mode.
`However, the same approach can be used for automated liq-
`uidation pricing 508 mode. FIG. 7 illustrates the feedback
`loop controlling pricing.
`Pricing Feedback Loop
`A list 710 of pricing units to test is maintained. Pricing
`units are added to the list 710 based upon explicit requests
`702, e.g. the vendor signals that she/he would like a particular
`
`Page 00012
`
`
`Page 00012
`
`
`
`US 7,970,713 B1
`
`9
`price unit automatically priced for the first time or that she/he
`would like to have price re-determined. Additionally, triggers
`704 from the monitoring 716, described in greater detail
`below, can cause pricing units to be added to the list 710. The
`pricing control 700 controls the flow of all of the processes
`within the feedback loop.
`The selection 712 process allows for orderly testing of
`demand. If too many pricing units are price tested simulta-
`neously, the results may be affected by the other ongoing
`tests. Similarly, testing a single pricing unit without similar
`testing of related pricing units, e. g. ReebokTM shoes without
`testing NikeTM shoes, may cause distorted results.
`Additionally, some individual pricing units may not have
`sufficient sales velocity for live price testing; accordingly,
`clustering can be used to test several pricing units simulta-
`neously, with aggregate results used to determine the prices of
`the each of the pricing units. If appropriate, the selection 712
`process can include querying one or more systems for auto-
`matic determination of suitable clusters of pricing units.
`Another variant is testing multiple price units for bundling
`purposes. In this configuration, the vendor identifies a bundle
`of pricing units that she/he would like priced together, e.g. a
`pricing unit for a computer and a pricing unit for a monitor
`bundled together as a package. In this instance, the demand
`for the bundle can be measured and priced—possibly differ-
`ently from the pricing for each pricing unit alone.
`Accordingly, the list 710 is analyzed by the selection 712
`process. This process can identify dependencies in testing
`like those described above, e.g. ReebokTM shoes and NikeTM
`shoes should be price tested at similar times. Once such
`dependencies are determined,
`the particular items being
`tested are passed to a calibration 714 process.
`The pricing control 700 will exert control over the timing of
`individual tests. For example, if 100 products are currently
`being calibrated, the pricing control 700 can distribute the
`tests across time and implement vendor selected pricing poli-
`cies. For example, no more than Z items tested simulta-
`neously; no more thanY % of tested items with prices above,
`or below, the item’s starting price, etc.
`The calibration 714 process can occur for multiple pricing
`units in parallel and includes live price testing and is
`described in greater detail below. Once the calibration 714
`process for a pricing unit is complete, that pricing unit is
`moved to monitor 716 process. Additionally, the tested pric-
`ing units can be removed fro