WO2002043303A2 - Standardizing price discovery and negotiations in commercial industries with multiple specification layers - Google Patents

Standardizing price discovery and negotiations in commercial industries with multiple specification layers Download PDF

Info

Publication number
WO2002043303A2
WO2002043303A2 PCT/US2001/043406 US0143406W WO0243303A2 WO 2002043303 A2 WO2002043303 A2 WO 2002043303A2 US 0143406 W US0143406 W US 0143406W WO 0243303 A2 WO0243303 A2 WO 0243303A2
Authority
WO
WIPO (PCT)
Prior art keywords
values
bid
demand set
vendors
multiple sets
Prior art date
Application number
PCT/US2001/043406
Other languages
French (fr)
Other versions
WO2002043303A3 (en
Inventor
Hans Dau
Keri Ann Aivazis
Original Assignee
Zeborg, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zeborg, Inc. filed Critical Zeborg, Inc.
Priority to EP01989727A priority Critical patent/EP1360625A2/en
Priority to AU2002228613A priority patent/AU2002228613A1/en
Priority to CA002429947A priority patent/CA2429947A1/en
Publication of WO2002043303A2 publication Critical patent/WO2002043303A2/en
Publication of WO2002043303A3 publication Critical patent/WO2002043303A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the invention disclosed herein relates generally to the field of price discovery in commercial industries and more specifically to price discovery in commercial industries where products and services involve multiple specification layers.
  • Multiple Specification Layers occur when at least one of the elements of the set of characteristics for a Specification can be expressed with more than one set of elements. For example, if one of the elements of a specification were "location,” several sets of location elements could be valid for a given Specification, such as the set of all states, the set of all cities, the set of all 3-digit zip codes, the set of all 5-digit zip codes, the set of all 9-digit zip codes or the set of all postal delivery addresses. If at least two of these sets were valid for the "location" element of a Specification, then Multiple Specification Layers would exist for that Specification.
  • a Specification for a shipment consists of the following set of four elements: origin, destination, weight and commodity class (the descriptor of a shipment's transportation characteristics). Each unique combination of these elements can yield a different price for a particular shipment.
  • Multiple Specification Layers exist for LTL freight shipping specifications in the United States because "origin" can be drawn from the set of regions, the set of states, the set of 3-digit zip codes, the set of 5-digit zip codes or even the set of 9-digit zip codes.
  • the same set of Specification Layers exist for "destination" element of the shipping specification.
  • the Specification Layers consist of 18 Freight All Kinds ("FAK”) classes or 18 National Motor Freight Classification (“NMFC”) ratings.
  • the Buying Entity perceives the LTL pricing problem to be a five dimensional pricing matrix (origin, destination, weight bracket, commodity class, and vendor). To fully populate this matrix, each vendor would have to supply approximately 80,000 prices to the Buying Entity. In the more general case, a Buying Entity that desires to solicit the full matrix of prices from N transportation firms would therefore have to solicit 80,000 x N prices. Generally, attempts by Buying Entities to collect thousands of individually rated prices from a single vendor, let alone tens of thousands of individually rated prices from multiple vendors, are not successful due to the limitations of vendor estimation capabilities in the current art.
  • Percentage-of bids also do not make visible the willingness of certain carriers to reallocate equipment and staff to selected sub-segments of the market.
  • Another solution to the pricing problem in the art is to employ the Internet to locate the most attractively priced vendor who is both willing and able to execute a transaction at a given moment in time.
  • Such services are usually provided through Web sites which combine a pricing search mechanism with a transaction execution mechanism. While perhaps revealing attractive prices available to Buying Entities on a one-transaction-at-a-time basis, these services do not yield consistently attractive pricing to Buying Entities, particularly Buying Entities with significant transaction volumes.
  • the current art enables Buying Entities to employ the Internet to search for attractive shipping prices on a one-transaction-at-a-time basis.
  • a Buying Entity can post a Specification for a given shipment and can solicit bid data for the Specification from alternative competing transportation vendors. If a Buying Entity discovers acceptable pricing, the Internet service enables the Buying Entity and the selected vendor to commit the transaction.
  • This technique allows transportation vendors and Buying Entities to transmit pricing and corresponding specifications between themselves. At the margin, this technique also more efficiently clears transient markets for surplus shipping capacity. This technique is described in U.S. Patent 6,064,981.
  • the present invention relates to the standardization of price discovery, including collecting, storing, retrieving, evaluating, and negotiating pricing and specifications between a Buying Entity and vendors, for any industry with a pricing structure containing Multiple Specification Layers.
  • the present invention is equally applicable to any industry containing Multiple Specification Layers, such as the quantitative market research industry, the LTL freight industry is used herein for illustrative purpose and also as a preferred embodiment.
  • a Buying Entity is any purchaser of any good or service, such as an individual, corporation, partnership or other association.
  • a Specification refers to any given set of characteristics for a commodity such that a single price and a single quantity may be associated with a transaction for that commodity between a particular Buying Entity and seller. Most often, each element of the set of characteristics is itself a set containing a finite number of possible values.
  • a Specification Layer refers to one of the layers of a Multiple Specification Layer.
  • a Blended Average Price is a term used to refer to a class of inexact pricing heuristics currently in use by transportation firms.
  • an employee called an estimator
  • To compute a Blended Average Price an employee, called an estimator, for a transportation vendor performs a costing analysis for a set of shipments following a particular delivery method and route and then applies that analysis to a group of delivery methods and routes that, in the opinion of the estimator, share a certain degree of similarity.
  • the estimator then assigns a price to the group of delivery methods and routes, using any means known in the art for establishing such prices.
  • Such means typically require the estimator to make a variety of assumptions concerning difficult to forecast factors such as the future aggregate distribution of demand and the future average utilization of equipment for the group(s) of delivery methods and routes at hand.
  • the estimator's job is further complicated by the need to express such prices at Multiple Specification Layers inherent in the Specification for transportation services.
  • the price that results from such calculations is a blend of assumptions regarding the future and averages achieved in the past.
  • the present invention relates to the standardization of price discovery (e.g. collecting, storing, retrieving, evaluating, and negotiating pricing and specifications between Buying Entities and vendors) for any industry with a pricing structure containing Multiple Specification Layers.
  • price discovery e.g. collecting, storing, retrieving, evaluating, and negotiating pricing and specifications between Buying Entities and vendors
  • the addition of Multiple Specification Layers to the methods previously described in Standardizing Price Discovery in Commercial Industries requires the use of novel techniques for collecting, storing and retrieving pricing data.
  • Buying Entities can fully articulate the Multiple Specification Layers in their Demand Set, thereby minimizing the risk premia in that Demand Set.
  • vendor prices are collected using a "funneling" technique that accommodates the Multiple Specification Layers inherent in the Buying Entity's Demand Set. This technique allows vendors to reveal their most competitive pricing for any portion of or all of a given Buying Entity's Demand Set.
  • the system allows a Buying Entity to solicit multiple rounds of bids from the vendor set using the funneling technique.
  • the system provides an algorithm to store and retrieve vendor prices across all of a Buying Entity's Multiple Specification Layers.
  • a Target Rate List is developed from the most competitive prices solicited during the bidding round(s).
  • the Target Rate List is constructed so as to be optimized for each Buying Entity's Demand Set.
  • a Buying Entity can create a contractual pricing schedule optimized for the Multiple Specification Layers of its Demand Set so that the schedule covers a plurality of transactions that the Buying Entity anticipates it may encounter over a given time period.
  • a pricing schedule may take the form of a PRIVATE RATECARD accessed by the Buying Entity whenever transactions must be executed.
  • the present invention has a number of advantages over the current art.
  • the present invention provides Buying Entities with a pricing and price standardization mechanism that alleviates the necessity of resorting to inferior pricing techniques, such as inexact pricing heuristics, vendor estimators employing Blended Average Pricing, or other third-party transaction-based pricing services.
  • the invention also allows a Buying Entity to unbundle its price discovery process from its transaction execution process. By unbundling these processes, a Buying Entity can exploit the advantages inherent in sophisticated competitive bidding environments, such as the tendency of these environments to yield the most attractive prices available to any given Buying Entity in the marketplace — articularly in comparison to inexact pricing heuristics, vendor estimators or third-party transaction based pricing services.
  • the present invention also allows both Buying Entities and vendors to save time which would otherwise have been allocated to dealing with routine rating requests.
  • the above described concepts are achieved by a computer implemented method of price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values.
  • the method involves receiving from a buyer a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one characteristic.
  • the demand set is provided to one or more vendors.
  • a bid from at least one of the one or more vendors for one or more specifications of the demand set is received.
  • the received bids are stored.
  • FIG. 1 is a schematic representation of one embodiment of the invention
  • FIG. 2 is an illustration of Multiple Specification Layers in the LTL freight industry
  • FIG. 3 illustrates how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention
  • FIG. 3 A continues the illustration for how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the cu ⁇ ent invention
  • FIG. 3B continues the illustration for how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention
  • FIG. 4 illustrates how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention
  • FIG. 4A continues the illustration for how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the cu ⁇ ent invention
  • FIG. 4B continues the illustration for how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the cu ⁇ ent invention
  • FIG. 5 is a flow chart illustrating the use of an embodiment of the present invention to create a PRIVATE RATECARD
  • FIG. 6 illustrates use of an embodiment of the present invention to enter into contracts using a PRIVATE RATECARD
  • FIG. 7 illustrates use of an embodiment of the present invention allowing an independent party to publish a Public Pricing Index
  • FIGS. 8 A and 8B illustrate alternate embodiments of the present invention comprising use of a PUBLIC RATECARD.
  • the present invention may be implemented in any electronic interactive environment, such as, for example the Internet and exchange data via any wide area, local or virtual networks or a CD ROM. Although it is theoretically possible to carry out the principles and methods of the present invention manually, the overwhelming amount and complexity of the data that is usually involved in the price discovery and standardization processes of this invention, coupled with realistic time constraints, best lend themselves to computerized manipulation.
  • the present invention preferably is implemented online, for example by means of a Web site, comprising, for example, a central processing server 100 and pricing database 110, which is accessed by N Buying Entities 200 and by M vendors 300 through telecommunication networks 400.
  • the examples of the techniques of the present invention reference the LTL
  • Table 500 shows an example for a first specification layer, Specification Layer 1, providing elements at the regional level.
  • Table 510 shows an example for a second specification layer, Specification Layer 2, that provides elements at the state level that co ⁇ espond to the first element of the regional level, "Northeast”.
  • Table 520 shows an example for a third specification layer, Specification Layer 3, that provides elements at the 3 digit zip code level that co ⁇ espond to the first element of the state level, "CT”.
  • Tables 530, 540, and 550 show examples for a fourth specification layer, Specification Layer 4, that provide elements at the 5 digit zip code level that co ⁇ espond to 3 digit zip code "061” (Table 530 covering zip code for Hartford, CT), to 3 digit zip code "065" (Table 540 covering zip codes for New Haven, CT), and to 3 digit zip code "069” (Table 550 covering zip codes for Stamford, CT).
  • a Buying Entity generates a Demand Set for performance by a vendor or vendors in a particular industry, such as the transportation industry or any other commercial industry in which a Buying Entity needs to procure goods or services.
  • the Demand Set contains the various elements of performance likely to be required in a given industry, such as specifications and service level requirements.
  • a Buying Entity supplies the Demand Set by providing the specifications, for any or all of the elements, which the Buying Entity has required in the past and/or expects to require in the future.
  • an LTL vendor would be interested in a Buying Entity's total number of shipments, total tonnage, and distribution patterns (for both number of shipments and tonnage) across weight groups for a given period of time.
  • the Demand Set is made available at a Buying Entity's option, either to all vendors within an industry or only to those vendors authorized by the Buying Entity to receive the Demand Set.
  • the Demand Set is made available online to all authorized vendors or made available in any other fashion that is accepted in the relevant industry or prefe ⁇ ed by the parties.
  • the vendor can analyze them to determine the attractiveness of each Buying Entity's Demand Set given the vendor's equipment and capabilities.
  • the comparison is conducted by means of a look-up engine or a query engine which would allow a vendor to find, compare and analyze portions of the Demand Set by criteria of interest to the vendor.
  • a vendor can submit a bid to any received Demand Set.
  • each vendor after viewing the Buying Entity's Demand Set, then can respond by providing prices at the Specifications Layer best suited to the vendor's capabilities.
  • the prices submitted by any one vendor may or may not be at the same levels as the Specification Layers outlined in the Buying Entity's Demand Set.
  • the present invention allows vendors to selectively depart from Blended Average Pricing. This technique allows vendors to minimize the Risk Premia in the Buying Entity's Demand Set because it becomes possible for vendors to isolate profitable and unprofitable business and price accordingly.
  • each participating vendor registers with the system and receives a customized ID and password required to enter the website and provide bid data elements.
  • FIGS 3, 3 A, 3B, 4, 4A, and 4B illustrate the mechanism employed to collect and store bid data from vendors in the LTL freight industry.
  • the vertical axis represents source and the horizontal axis represents destination.
  • the bid data collected by the present invention can be stored in a series of matrices.
  • a five dimensional pricing set such as in transportation pricing problems
  • two dimensions can be collected at a time by holding the other three dimensions constant.
  • the bid data collection program can hold vendor name, commodity class and weight bracket constant while stepping through the Multiple Specification Layers for origin and destination pricing. Then the program can change the weight bracket and step through the Multiple Specification Layers for origin and destination again. The entire process can be repeated for as many commodity classes and weight brackets as are necessary for a given Buying Entity's Demand Set.
  • the invention need not collect every possible price for each Demand Set element. Indeed, by organizing the Multiple Specification Layers into a hierarchy and traversing through those layers hierarchically from highest to lowest, a vendor supplying bid data can enter the data in a highly selective and economical fashion. For example, imagine our two hypothetical vendors supplying prices via the present invention where First Vendor is primarily an east-west shipper and Second Vendor is a north-south shipper. Further assume that both vendors compete primarily in Connecticut. Transportation vendors tend to compete by concentrating their equipment on certain routes where they attempt to achieve high load factors and co ⁇ espondingly high profitability, thus the bidding strategy for each firm is likely to reflect those strategies.
  • First Vendor might desire to supply a Buying Entity with aggressive pricing on routes where he believes that he has a cost advantage. For an east-west shipper in Connecticut, this might occur along Interstate 95, near the cities located on the Atlantic coast.
  • First Vendor's bidding strategy might be to bid aggressively in certain 3-digit and 5-digit zip codes along the Atlantic coast while bidding cautiously on other routes inside Connecticut and between Connecticut and nearby states. This strategy is illustrated in Figures 3, 3A, and 3B.
  • Fig. 3 provides examples of bid data at various specification layers.
  • each white square within a matrix represents a null price.
  • a Homogenous Rate Zone is indicated by a group of squares that all contain the same price, where the prices are indicated by the lower-case letters in the Figures. Shaded squares are Heterogeneous Rate Zones; vendor prices in these zones are defined in the next lower layer in the Specifications Layer hierarchy.
  • Fig. 3 A provides an example of bid data at a fourth specification layer, Specification Layer 4, covering the 5 digit zip code level co ⁇ esponding to Stamford,
  • Fig. 3B provides another example of bid data at Specification Layer 4, but covering the 5 digit zip code level co ⁇ esponding to New Haven, Connecticut.
  • Second Vendor might also desire to supply a Buying Entity with aggressive pricing on routes where he believes he has a cost advantage. For a north-south shipper in Connecticut, this might occur along Interstate 91, extending north from New Haven through Hartford. Second Vendor's bidding strategy might be particularly aggressive in certain 3-digit and 5-digit zip codes along Interstate 91 while cautious on other routes inside Connecticut and between Connecticut and nearby states. This strategy is illustrated in Figures 4, 4 A, and 4B. Fig. 4 provides examples of bid data at various specification layers for the Second
  • the matrix 700 shows bid data for a Specification Layer 1, covering region-to-region pricing
  • matrix 710 shows bid data for Specification Layer 2
  • matrix 720 shows bid data for Specification Layer 3, covering 3 digit zip code-to-3 digit zip code pricing.
  • each white square within a matrix represents a null price
  • Homogenous Rate Zones are indicated by the lower-case letters
  • shaded squares are Heterogeneous Rate Zones.
  • Fig. 4A provides an example of bid data for the Second Vendor at Specification Layer 4, covering the 5 digit zip code level co ⁇ esponding to New Haven, Connecticut. Again, Homogenous Rate Zones are indicated by the lower-case letters.
  • Fig. 4B provides another example of bid data at Specification Layer 4, but covering the 5 digit zip code level co ⁇ esponding to Hartford, Connecticut.
  • each white square within a matrix represents a null price.
  • a Homogenous Rate Zone is indicated by a group of squares that all contain the same price, where the prices are indicated by the lower-case letters in the Figures. Shaded squares are Heterogeneous Rate Zones; vendor prices in these zones are defined in the next lower layer in the Specifications Layer hierarchy.
  • matrix 610 contains 2 Homogeneous Rate Zones, one including all the squares in the first column except the first row and the other including all the squares in the first row except the first column. Both these Homogeneous Rate Zones have a price of "d”. Matrix 610 also shows that Specification Layer 2 contains one Heterogeneous Rate Zone, e.g., for "CT” to "CT”.
  • any shipping price can be expressed either as a dollar amount (or other cu ⁇ ency amount) or as a percentage of a published reference table containing such monetary amounts.
  • prices can be represented as a percentage of a published reference table, such as CZAR-LITE.
  • Vendors can enter rates at any Specification Layer they choose. For transportation industry pricing problems with two elements in a typical Specification, such as origin and destination, each of which can be subject to Multiple Specification Layers, it is useful to envision the rate storage problem in the form of a matrix.
  • (Origin State List/Range) —> (Destination State List/Range) S, has 2,500 entries. However, if there are repeating elements in the matrix, then a list representation of the matrix offers storage economies over a conventional 2,500 element table. A few examples should serve to illustrate the nature of these economies.
  • a computer program can convert the list representation of a matrix into a conventional table, complete with repeating values and null values. Such a program can build tables on demand and as needed from any stored list representation. This property is convenient for displaying or printing out the contents of the database.
  • Example 3 Here is an illustration of a more complex representation of a state-to- state table list:
  • a pointer construct such as the C programming language
  • Three core constructs are needed to represent the abstraction: a list construct, a price construct, and a Homogenous Rate Zone construct.
  • a list construct could be defined as a record containing either a single entry or a range of entries.
  • the abstraction (Origin List or Range) could be implemented as a list construct, as could the abstraction (Destination List or Range)
  • the price construct, R can be implemented as a record containing one of three possible values: a cu ⁇ ency amount, a percentage of a named reference table, or a system flag indicating a Heterogeneous Rate Zone.
  • a computerized mechanism to store Specification Layer prices could be implemented as a list of Homogenous Rate Zone constructs.
  • a computerized mechanism to store Multiple Specification Layer prices could be implemented as a list of Specification Layers.
  • search functions could be built to traverse all defined lists looking for prices that coincide with particular query criteria.
  • all vendor bids for a particular Demand Set are collected and analyzed.
  • the collection and analysis are performed online.
  • the analysis is performed by use of an algorithm that is customizable by the Buying Entity.
  • the output of the analysis is a Target Rate List containing a price for each bid element.
  • the Target Rate List is visible only to the participating vendors by means of, for example, being posted online on a Web site designed for this purpose.
  • the Target Rate List is utilized as a reference point for all subsequent negotiations between the parties for performances in the relevant industry. * Once a Target Rate List is generated and vendors have signaled their willingness to perform for the Buying Entity at the prices indicated on the Target Price List, a Buying Entity can stop the bidding process. A Buying Entity also could invite a second, or other subsequent round(s) of bids, where the bids are expressed as a percentage of the Target Rate List.
  • Target Rate List algorithm may operate as follows: for each element of the Buying Entity's Demand Set, and for each vendor who submitted prices, the algorithm retrieves the best price submitted by that vendor among all defined Multiple Specification Layers. Having collected the set of all such prices for all Specification Layers across all bidding vendors, the Buying Entity may specify an output where, given "m” vendors and a value "n" specified by the Buying Entity, where "m” > "n", the n th lowest bid is chosen for each element of the Buying Entity's Demand Set.
  • the Target Rate List is subsequently adjusted to achieve internal consistency of the prices, either by blunt ocular analysis or by computerized means.
  • Either the first or the second or subsequent rounds of bidding may lead to a contract for a particular performance or to an agreement to agree on later performances.
  • An agreement to agree takes the form of a PRIVATE RATECARD, which may be expressed as a set of percentages of the co ⁇ esponding Target Price List or a set of actual dollar figures.
  • Figure 5 shows a flowchart for creating a PRIVATE RATECARD.
  • the Buying Entity's Demand Set is obtained, step 1000.
  • the Multiple Specification Layers are defined, step 1100.
  • the Risk Premia in the Multiple Specification Layers of the Buying Entity's Demand Set are minimized, step 1200.
  • price collection is performed with the Multiple Specification Layers, step 1300.
  • Target Rate determination is performed with the Multiple Specification Layers, step 1400.
  • PRIVATE RATECARD contracting is performed with the Multiple Specification Layers.
  • a PRIVATE RATECARD is an electronic or paper schedule, presented in any acceptable format and containing the set of agreed upon prices for various performance elements.
  • a PRIVATE RATECARD also contains a formula which, with the aid of a PRIVATE
  • RATECARD calculator in accordance with this invention, is used to translate the schedule of agreed upon prices into a total price for a future specification.
  • each PRIVATE RATECARD is unique to the Buying Entity and the vendor or vendors which had agreed to the PRIVATE RATECARD schedule.
  • the Buying Entity when a Buying Entity with a PRIVATE RATECARD needs to contract with a vendor, the Buying Entity drafts the specifications for the job.
  • the Buying Entity then uses a PRIVATE RATECARD calculator to derive the price for that job.
  • the derivation can be obtained by any means known in the art.
  • the PRIVATE RATECARD calculator is an online calculator that includes a look-up engine for locating the relevant bid elements or Specification Levels.
  • the PRIVATE RATECARD calculator implements the PRIVATE RATECARD formula for the agreed upon prices for the relevant bidding elements or Specification Levels and outputs a final price calculation.
  • the format of the output is customizable by the user.
  • the PRIVATE RATECARD calculator is implemented over the Internet to facilitate updates of the calculator to reflect changes in macroeconomic and microeconomic factors, to accommodate new advances in the relevant technology, and to reflect changes to the PRIVATE RATECARD schedule of prices.
  • the PRIVATE RATECARD calculator can derive prices for multiple PRIVATE RATECARDS. Due to the amount and complexity of the data involved, this task would be enormous burdensome and virtually unmanageable if one were to attempt it manually.
  • FIG. 6 shows the use of a PRIVATE RATECARD to create contracts between Buying Entities and vendors.
  • a Buying Entity first drafts a Specification for its job, step 2000.
  • the Specification for a job would typically include origin, destination, shipment weight, commodity class, and any ancillary services that may be required.
  • a computer program written in accordance with the present invention by any means known in the art calculates the weight bracket based upon the shipment weight.
  • the present invention then employs the PRIVATE RATECARD calculator to obtain a total job price based on the origin, destination, weight bracket, commodity class, and ancillary services information for the job and retrieves the PRIVATE RATECARD prices for the shipment from all vendors who have agreed to a PRIVATE RATECARD pricing structure, step 2100.
  • the Buying Entity selects the vendor, step 2200, and the vendor then performs the job, step 2300.
  • any individual, entity or organization may publish a Public Pricing Index, contaimng a schedule of target prices, based on defining Multiple Specification Layers, price collection, and target rate determination processes according to this invention.
  • a Public Pricing Index contaimng a schedule of target prices, based on defining Multiple Specification Layers, price collection, and target rate determination processes according to this invention.
  • Fig. 7 first, Multiple Specification Layers are defined, step 3000. Then price collection is performed, step 3100. Next, target rate determination is performed, step 3200. Finally, a schedule of target prices is published to create a Public Pricing Index, step 3300. Once the Public Pricing Index is published, some but not all Buying Entities, particularly small and midsize companies, may find that they do not need to conduct the price determination and target rate processes outlined here. Instead, these companies may use the Public Pricing Index.
  • the Public Pricing Index may be adjusted over time for both macroeconomic factors, such as inflation, and microeconomic factors particular to the industry, such as a rapid rate of technological advance. Vendors may publish public asking prices, expressed as a percentage of the Public Pricing Index. The resulting schedule is refe ⁇ ed to herein as a PUBLIC RATECARD. A vendor may then make the PUBLIC RATECARD pricing available to Buying Entities in the vendor's industry, either by posting the PUBLIC RATECARD online or by any other means known in the art. A Buying Entity may contract with a vendor with the most favorable PUBLIC
  • a Purchasing Entity may review the available PUBLIC RATECARD(s), preferably by means of a look-up engine or a search engine that would enable the Buying Entities to search and compare the PUBLIC RATECARD(s) by Specifications of interest.
  • a vendor retrieves the Public Pricing Index, step 4000.
  • step 4100 the vendor calculates its public "Ask” prices, e.g., as a percentage of the Public Pricing Index.
  • step 4200 the vendor publishes its public "Ask” prices, e.g., via an Internet site designed for this purpose.
  • a Buying Entity may use a PUBLIC RATECARD calculator to determine the total price for a given Specification using the pricing schedule in any given
  • the Buying Entity uses a PUBLIC RATECARD calculator to determine the best "public price" for the job, step 5100.
  • a PUBLIC RATECARD calculator derives a final contract price similarly to the way a PRIVATE RATECARD calculator does so.
  • the Buying Entity selects a vendor, step 5200. As an option, this selection may be performed, in part, by a Purchasing Entity
  • Buying Entities can utilize both the present invention and the invention described in U.S. Serial No. 60/233,034, titled Standardizing Price Discovery and Negotiations in Commercial Industries and incorporated by reference herein, to comprehensively price all of the services to a Buying Entity from a vendor.
  • the system gathers bid data elements from vendors based on any of the several sets of Multiple Specifications Layers that are generally known in the industry, but it also collects the bids charged by these vendors for ancillary services.
  • LTL freight ancillary services can include, but are not limited to, facilities storage, freeze protection, weight verification, stop-off, and redelivery, and generally do not have the problem of Multiple Specification Layers.

Abstract

A computer implemented method of price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values. The method involves receiving from a buyer (200) a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one of the more vendors (300) for one or more specifications of the demand set is received. The received bids are stored (110). Finally, all the stored bids are analyzed to identify a preferred bid for each specification of the demand set.

Description

STANDARDIZING PRICE DISCOVERY AND NEGOTIATIONS IN COMMERCIAL INDUSTRIES WITH MULTIPLE SPECIFICATION LAYERS
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority from U.S. Provisional Application No. 60/252,667, filed on November 22, 2000, which is hereby incorporated by reference into this application. This application is related to U.S. Application entitled, "IMPROVED PRICE
DISCOVERY AND NEGOTIATIONS AND RELATED PROCESSES", filed on September 17, 2001, attorney docket no. 4487-10; U.S. Provisional Application Serial No. 60/233,033, filed on September 15, 2000; U.S. Provisional Application Serial No. 60/233,034, filed on September 15, 2000; and U.S. Provisional Application Serial No. 60/275,895, filed on March 14, 2001, all of which are hereby incorporated by reference into this application.
BACKGROUND OF THE INVENTION
The invention disclosed herein relates generally to the field of price discovery in commercial industries and more specifically to price discovery in commercial industries where products and services involve multiple specification layers.
In commercial industries where products and services are regularly described by Multiple Specification Layers, Buying Entities have experienced difficulty in optimizing pricing terms available from competing vendors. Industries with Multiple Specification Layers tend to present Buying Entities with pricing problems containing hundreds of thousands or even millions of individual pricing elements, each of which must be collected and evaluated individually in order to fully analyze all pricing options available to a given Buying Entity.
Multiple Specification Layers occur when at least one of the elements of the set of characteristics for a Specification can be expressed with more than one set of elements. For example, if one of the elements of a specification were "location," several sets of location elements could be valid for a given Specification, such as the set of all states, the set of all cities, the set of all 3-digit zip codes, the set of all 5-digit zip codes, the set of all 9-digit zip codes or the set of all postal delivery addresses. If at least two of these sets were valid for the "location" element of a Specification, then Multiple Specification Layers would exist for that Specification. For example, in the LTL freight industry, a Specification for a shipment consists of the following set of four elements: origin, destination, weight and commodity class (the descriptor of a shipment's transportation characteristics). Each unique combination of these elements can yield a different price for a particular shipment. Multiple Specification Layers exist for LTL freight shipping specifications in the United States because "origin" can be drawn from the set of regions, the set of states, the set of 3-digit zip codes, the set of 5-digit zip codes or even the set of 9-digit zip codes. The same set of Specification Layers exist for "destination" element of the shipping specification. For commodity class, the Specification Layers consist of 18 Freight All Kinds ("FAK") classes or 18 National Motor Freight Classification ("NMFC") ratings. Shipment weights, between 1 and 40,000 pounds, are commonly partitioned into 10 weight brackets. Using the 3-digit zip code Specification Layer for origin and destination, the 10 industry standard weight brackets, and 18 commodity classes, a Buying Entity with 10 manufacturing or "source" sites, 800 customer or "destination" sites, and a network of 50 shipping vendors faces a pricing optimization problem with 4,000,000 individual prices. These are not arbitrary numbers: there are approximately 800 3-digit zip codes in the United States and there is at least 1 regional LTL shipper operating in each of the 50 states; therefore, this is a lower bound for the pricing problem facing a midsize manufacturer with national distribution. Thus, the Buying Entity perceives the LTL pricing problem to be a five dimensional pricing matrix (origin, destination, weight bracket, commodity class, and vendor). To fully populate this matrix, each vendor would have to supply approximately 80,000 prices to the Buying Entity. In the more general case, a Buying Entity that desires to solicit the full matrix of prices from N transportation firms would therefore have to solicit 80,000 x N prices. Generally, attempts by Buying Entities to collect thousands of individually rated prices from a single vendor, let alone tens of thousands of individually rated prices from multiple vendors, are not successful due to the limitations of vendor estimation capabilities in the current art.
The complexity of pricing problems with Multiple Specification Layers increase with the number of discrete elements in the individual Specification Layers. For example, at the 5-digit zip code Specification Layer for origin and destination, each vendor in the above problem would need to supply nearly two trillion individually rated data elements which implies a pricing problem with one hundred trillion pricing elements from the Buying Entity's perspective across 50 vendors.
A common solution to the pricing problem in the existing art is for the Buying Entity to rely upon inexact pricing heuristics to permit comparison of competing price quotations from vendors, instead of conducting a thorough analysis of the pricing options available. Historically, collators and publishers of industry transaction data have emerged to supply common pricing reference sources for industry participants, often in the form of one or more published reference tables. In these industries the most prevalent inexact pricing heuristic used by Buying Entities is the "percentage-of the rate in a specific published reference table" heuristic.
For example, in the LTL freight industry, it is common for Buying Entities to solicit pricing from transportation vendors by collecting bids in the form of a "percentage-of a common published reference table. This technique has the advantage of simplicity, but because the pricing tables are, by design, broad in terms of elements such as route and commodity class coverage, this pricing method tends not to reveal the most aggressive pricing available in the marketplace from niche carriers. These niche carriers may possess equipment, utilization, staffing, or other market advantages tied to specific routes or commodity classes. Also, "percentage-of bids present niche carriers with business risks, such as reduced profitability, should a Buying Entity's service demands vary from the specific niches where the smaller carrier has an advantage. "Percentage-of bids also do not make visible the willingness of certain carriers to reallocate equipment and staff to selected sub-segments of the market. Another solution to the pricing problem in the art is to employ the Internet to locate the most attractively priced vendor who is both willing and able to execute a transaction at a given moment in time. Such services are usually provided through Web sites which combine a pricing search mechanism with a transaction execution mechanism. While perhaps revealing attractive prices available to Buying Entities on a one-transaction-at-a-time basis, these services do not yield consistently attractive pricing to Buying Entities, particularly Buying Entities with significant transaction volumes.
For example, in the transportation industry, the current art enables Buying Entities to employ the Internet to search for attractive shipping prices on a one-transaction-at-a-time basis. A Buying Entity can post a Specification for a given shipment and can solicit bid data for the Specification from alternative competing transportation vendors. If a Buying Entity discovers acceptable pricing, the Internet service enables the Buying Entity and the selected vendor to commit the transaction. This technique allows transportation vendors and Buying Entities to transmit pricing and corresponding specifications between themselves. At the margin, this technique also more efficiently clears transient markets for surplus shipping capacity. This technique is described in U.S. Patent 6,064,981.
All of the prior art techniques described herein attempt to solve the pricing problems that emerge in industries with Multiple Specification Layers with simple heuristics negotiated in advance of need or with mechanisms to perform pricing searches at the time of the transaction. However, none of the solutions produce optimal results for Buying Entities.
SUMMARY OF THE INVENTION
The present invention relates to the standardization of price discovery, including collecting, storing, retrieving, evaluating, and negotiating pricing and specifications between a Buying Entity and vendors, for any industry with a pricing structure containing Multiple Specification Layers. Applicant's previous U.S. Application No. 60/233,034, titled Standardizing Price Discovery and Negotiations in Commercial Industries, is incorporated herein by reference. Although the present invention is equally applicable to any industry containing Multiple Specification Layers, such as the quantitative market research industry, the LTL freight industry is used herein for illustrative purpose and also as a preferred embodiment. A Buying Entity is any purchaser of any good or service, such as an individual, corporation, partnership or other association.
A Specification refers to any given set of characteristics for a commodity such that a single price and a single quantity may be associated with a transaction for that commodity between a particular Buying Entity and seller. Most often, each element of the set of characteristics is itself a set containing a finite number of possible values.
A Specification Layer refers to one of the layers of a Multiple Specification Layer. A Blended Average Price is a term used to refer to a class of inexact pricing heuristics currently in use by transportation firms. To compute a Blended Average Price, an employee, called an estimator, for a transportation vendor performs a costing analysis for a set of shipments following a particular delivery method and route and then applies that analysis to a group of delivery methods and routes that, in the opinion of the estimator, share a certain degree of similarity. The estimator then assigns a price to the group of delivery methods and routes, using any means known in the art for establishing such prices. Such means typically require the estimator to make a variety of assumptions concerning difficult to forecast factors such as the future aggregate distribution of demand and the future average utilization of equipment for the group(s) of delivery methods and routes at hand. The estimator's job is further complicated by the need to express such prices at Multiple Specification Layers inherent in the Specification for transportation services. Invariably, the price that results from such calculations is a blend of assumptions regarding the future and averages achieved in the past.
The present invention relates to the standardization of price discovery (e.g. collecting, storing, retrieving, evaluating, and negotiating pricing and specifications between Buying Entities and vendors) for any industry with a pricing structure containing Multiple Specification Layers. The addition of Multiple Specification Layers to the methods previously described in Standardizing Price Discovery in Commercial Industries requires the use of novel techniques for collecting, storing and retrieving pricing data.
According to an embodiment of the present invention, Buying Entities can fully articulate the Multiple Specification Layers in their Demand Set, thereby minimizing the risk premia in that Demand Set.
According to a further embodiment of the present invention, vendor prices are collected using a "funneling" technique that accommodates the Multiple Specification Layers inherent in the Buying Entity's Demand Set. This technique allows vendors to reveal their most competitive pricing for any portion of or all of a given Buying Entity's Demand Set.
According to a further embodiment of the invention, the system allows a Buying Entity to solicit multiple rounds of bids from the vendor set using the funneling technique. According to a further embodiment of the invention, the system provides an algorithm to store and retrieve vendor prices across all of a Buying Entity's Multiple Specification Layers.
According to a further embodiment of the invention, a Target Rate List is developed from the most competitive prices solicited during the bidding round(s). The Target Rate List is constructed so as to be optimized for each Buying Entity's Demand Set.
According to a further embodiment of the invention, a Buying Entity can create a contractual pricing schedule optimized for the Multiple Specification Layers of its Demand Set so that the schedule covers a plurality of transactions that the Buying Entity anticipates it may encounter over a given time period. Such a pricing schedule may take the form of a PRIVATE RATECARD accessed by the Buying Entity whenever transactions must be executed.
The present invention has a number of advantages over the current art. The present invention provides Buying Entities with a pricing and price standardization mechanism that alleviates the necessity of resorting to inferior pricing techniques, such as inexact pricing heuristics, vendor estimators employing Blended Average Pricing, or other third-party transaction-based pricing services. The invention also allows a Buying Entity to unbundle its price discovery process from its transaction execution process. By unbundling these processes, a Buying Entity can exploit the advantages inherent in sophisticated competitive bidding environments, such as the tendency of these environments to yield the most attractive prices available to any given Buying Entity in the marketplace — articularly in comparison to inexact pricing heuristics, vendor estimators or third-party transaction based pricing services.
The present invention also allows both Buying Entities and vendors to save time which would otherwise have been allocated to dealing with routine rating requests. The above described concepts are achieved by a computer implemented method of price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values. The method involves receiving from a buyer a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one characteristic. Then the demand set is provided to one or more vendors. A bid from at least one of the one or more vendors for one or more specifications of the demand set is received. The received bids are stored. Finally, all the stored bids are analyzed to identify a prefeπed bid for each specification of the demand set.Other embodiments of the present invention are further described hereinbelow.
BRIEF DESCRIPTION OF THE DRAWINGS The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding parts, and in which: FIG. 1 is a schematic representation of one embodiment of the invention;
FIG. 2 is an illustration of Multiple Specification Layers in the LTL freight industry;
FIG. 3 illustrates how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention;
FIG. 3 A continues the illustration for how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the cuπent invention;
FIG. 3B continues the illustration for how a first LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention;
FIG. 4 illustrates how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the current invention;
FIG. 4A continues the illustration for how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the cuπent invention; FIG. 4B continues the illustration for how a second LTL shipper might supply prices to a Buying Entity using an embodiment of the cuπent invention;
FIG. 5 is a flow chart illustrating the use of an embodiment of the present invention to create a PRIVATE RATECARD;
FIG. 6 illustrates use of an embodiment of the present invention to enter into contracts using a PRIVATE RATECARD;
FIG. 7 illustrates use of an embodiment of the present invention allowing an independent party to publish a Public Pricing Index; and
FIGS. 8 A and 8B illustrate alternate embodiments of the present invention comprising use of a PUBLIC RATECARD.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention may be implemented in any electronic interactive environment, such as, for example the Internet and exchange data via any wide area, local or virtual networks or a CD ROM. Although it is theoretically possible to carry out the principles and methods of the present invention manually, the overwhelming amount and complexity of the data that is usually involved in the price discovery and standardization processes of this invention, coupled with realistic time constraints, best lend themselves to computerized manipulation. Referring to Figure 1, the present invention preferably is implemented online, for example by means of a Web site, comprising, for example, a central processing server 100 and pricing database 110, which is accessed by N Buying Entities 200 and by M vendors 300 through telecommunication networks 400. The examples of the techniques of the present invention reference the LTL
Freight industry. However, it will be apparent to an individual of ordinary skill in the art that these algorithms and techniques could be employed in other industries.
Defining the Multiple Specification Layers. First of all, the relationships among the Multiple Specification Layers in a given industry must be defined to the system of the present invention by the Buying Entity, such as by means of a list. Figure 2 shows this relationship among the Multiple Specification Layers in the LTL freight industry. Table 500 shows an example for a first specification layer, Specification Layer 1, providing elements at the regional level. Table 510 shows an example for a second specification layer, Specification Layer 2, that provides elements at the state level that coπespond to the first element of the regional level, "Northeast". Table 520 shows an example for a third specification layer, Specification Layer 3, that provides elements at the 3 digit zip code level that coπespond to the first element of the state level, "CT". Tables 530, 540, and 550 show examples for a fourth specification layer, Specification Layer 4, that provide elements at the 5 digit zip code level that coπespond to 3 digit zip code "061" (Table 530 covering zip code for Hartford, CT), to 3 digit zip code "065" (Table 540 covering zip codes for New Haven, CT), and to 3 digit zip code "069" (Table 550 covering zip codes for Stamford, CT).
Minimizing Risk Premia in Buying Entity's Demand Set. Generally, a Buying Entity generates a Demand Set for performance by a vendor or vendors in a particular industry, such as the transportation industry or any other commercial industry in which a Buying Entity needs to procure goods or services. The Demand Set contains the various elements of performance likely to be required in a given industry, such as specifications and service level requirements. A Buying Entity supplies the Demand Set by providing the specifications, for any or all of the elements, which the Buying Entity has required in the past and/or expects to require in the future.
For example, an LTL vendor would be interested in a Buying Entity's total number of shipments, total tonnage, and distribution patterns (for both number of shipments and tonnage) across weight groups for a given period of time.
The Demand Set is made available at a Buying Entity's option, either to all vendors within an industry or only to those vendors authorized by the Buying Entity to receive the Demand Set. Preferably, the Demand Set is made available online to all authorized vendors or made available in any other fashion that is accepted in the relevant industry or prefeπed by the parties.
As a vendor receives Demand Sets from Buying Entities, the vendor can analyze them to determine the attractiveness of each Buying Entity's Demand Set given the vendor's equipment and capabilities. Preferably, the comparison is conducted by means of a look-up engine or a query engine which would allow a vendor to find, compare and analyze portions of the Demand Set by criteria of interest to the vendor.
Price Collection.
A vendor can submit a bid to any received Demand Set. In the present invention, each vendor, after viewing the Buying Entity's Demand Set, then can respond by providing prices at the Specifications Layer best suited to the vendor's capabilities. The prices submitted by any one vendor may or may not be at the same levels as the Specification Layers outlined in the Buying Entity's Demand Set. By permitting vendors to submit prices in this manner, the present invention allows vendors to selectively depart from Blended Average Pricing. This technique allows vendors to minimize the Risk Premia in the Buying Entity's Demand Set because it becomes possible for vendors to isolate profitable and unprofitable business and price accordingly.
In order to fully understand the price collection process, it may be helpful to imagine how the different bidding strategies for two competing Connecticut based regional LTL transportation companies would play out for a Buying Entity soliciting bids using the present invention.
First, each participating vendor registers with the system and receives a customized ID and password required to enter the website and provide bid data elements.
Figures 3, 3 A, 3B, 4, 4A, and 4B illustrate the mechanism employed to collect and store bid data from vendors in the LTL freight industry. Note that in these figures, the vertical axis represents source and the horizontal axis represents destination. In looking at the figures, it is important to observe that all of the bid data collected by the present invention can be stored in a series of matrices. In a five dimensional pricing set, such as in transportation pricing problems, two dimensions can be collected at a time by holding the other three dimensions constant. For example, the bid data collection program can hold vendor name, commodity class and weight bracket constant while stepping through the Multiple Specification Layers for origin and destination pricing. Then the program can change the weight bracket and step through the Multiple Specification Layers for origin and destination again. The entire process can be repeated for as many commodity classes and weight brackets as are necessary for a given Buying Entity's Demand Set.
The invention need not collect every possible price for each Demand Set element. Indeed, by organizing the Multiple Specification Layers into a hierarchy and traversing through those layers hierarchically from highest to lowest, a vendor supplying bid data can enter the data in a highly selective and economical fashion. For example, imagine our two hypothetical vendors supplying prices via the present invention where First Vendor is primarily an east-west shipper and Second Vendor is a north-south shipper. Further assume that both vendors compete primarily in Connecticut. Transportation vendors tend to compete by concentrating their equipment on certain routes where they attempt to achieve high load factors and coπespondingly high profitability, thus the bidding strategy for each firm is likely to reflect those strategies.
First Vendor might desire to supply a Buying Entity with aggressive pricing on routes where he believes that he has a cost advantage. For an east-west shipper in Connecticut, this might occur along Interstate 95, near the cities located on the Atlantic coast. First Vendor's bidding strategy might be to bid aggressively in certain 3-digit and 5-digit zip codes along the Atlantic coast while bidding cautiously on other routes inside Connecticut and between Connecticut and nearby states. This strategy is illustrated in Figures 3, 3A, and 3B. Fig. 3 provides examples of bid data at various specification layers. The matrix
600 shows bid data for a first specification layer, Specification Layer 1, covering region-to- region pricing. The matrix 610 shows bid data for a second specification layer, Specification Layer 2, covering state-to-state pricing. The matrix 620 shows bid data for a third specification layer, Specification Layer 3, covering 3 digit zip code-to-3 digit zip code pricing. As described below, each white square within a matrix represents a null price. A Homogenous Rate Zone is indicated by a group of squares that all contain the same price, where the prices are indicated by the lower-case letters in the Figures. Shaded squares are Heterogeneous Rate Zones; vendor prices in these zones are defined in the next lower layer in the Specifications Layer hierarchy. Fig. 3 A provides an example of bid data at a fourth specification layer, Specification Layer 4, covering the 5 digit zip code level coπesponding to Stamford,
Connecticut. Again, Homogenous Rate Zones are indicated by the lower-case letters. Fig. 3B provides another example of bid data at Specification Layer 4, but covering the 5 digit zip code level coπesponding to New Haven, Connecticut.
Similarly, Second Vendor might also desire to supply a Buying Entity with aggressive pricing on routes where he believes he has a cost advantage. For a north-south shipper in Connecticut, this might occur along Interstate 91, extending north from New Haven through Hartford. Second Vendor's bidding strategy might be particularly aggressive in certain 3-digit and 5-digit zip codes along Interstate 91 while cautious on other routes inside Connecticut and between Connecticut and nearby states. This strategy is illustrated in Figures 4, 4 A, and 4B. Fig. 4 provides examples of bid data at various specification layers for the Second
Vendor. The matrix 700 shows bid data for a Specification Layer 1, covering region-to-region pricing, matrix 710 shows bid data for Specification Layer 2, covering state-to-state pricing, and matrix 720 shows bid data for Specification Layer 3, covering 3 digit zip code-to-3 digit zip code pricing. Again, each white square within a matrix represents a null price, Homogenous Rate Zones are indicated by the lower-case letters, and shaded squares are Heterogeneous Rate Zones.
Fig. 4A provides an example of bid data for the Second Vendor at Specification Layer 4, covering the 5 digit zip code level coπesponding to New Haven, Connecticut. Again, Homogenous Rate Zones are indicated by the lower-case letters. Fig. 4B provides another example of bid data at Specification Layer 4, but covering the 5 digit zip code level coπesponding to Hartford, Connecticut.
Not illustrated, but also a part of the competitive environment, are national shippers who provide service to the Connecticut shipping market. However, the national shippers are likely to be at a competitive disadvantage on certain routes in this hypothetical scenario. In relation to the local shippers, the national shippers may only have enough pricing information to be able to price the Connecticut market at the Specification Layer 2 level of pricing detail in Figure 3 (e.g., a flat percentage-of published reference table rates for Connecticut routes). Given this hypothetical example, it would be a mistake for the Buying Entity to organize its bid at state- to-state level of detail (i.e., Specification Layer 2 in Figure 3), as the Buying Entity might not discover the particularly competitive rates available on selected routes in Connecticut from First Vendor and Second Vendor described above in relation to national shippers. Yet, in the cuπent art, transportation bids are typically organized at the wrong levels of detail due to widespread use of primitive pricing heuristics applied to large groups of routes. Returning to the ways in which vendors enter their bids into the cuπent invention, in Figure 3, each white square within a matrix represents a null price. A Homogenous Rate Zone is indicated by a group of squares that all contain the same price, where the prices are indicated by the lower-case letters in the Figures. Shaded squares are Heterogeneous Rate Zones; vendor prices in these zones are defined in the next lower layer in the Specifications Layer hierarchy. Returning to Figure 3, the example of matrix 610 contains 2 Homogeneous Rate Zones, one including all the squares in the first column except the first row and the other including all the squares in the first row except the first column. Both these Homogeneous Rate Zones have a price of "d". Matrix 610 also shows that Specification Layer 2 contains one Heterogeneous Rate Zone, e.g., for "CT" to "CT".
Note that any shipping price can be expressed either as a dollar amount (or other cuπency amount) or as a percentage of a published reference table containing such monetary amounts. In the LTL freight industry, for example, prices can be represented as a percentage of a published reference table, such as CZAR-LITE. In order to provide the vendor with the ability to supply rates at Multiple Specification Layers, it is important to request the rates collected by the invention in a storage-efficient fashion.
To fully understand how this process is implemented, a little math is required.
Let the abstraction
(Origin List or Range) —>■ (Destination List or Range) — R represent the matrix containing the value R for all coordinates defined by the Origin List or Range and the Destination List or Range:
Destinations
R R R R R R
R R R R R R
R R R R R R
• a**
R R R R R R o
R R R R R R
R R R R R R
Note that this abstraction is the computerized representation of a Homogenous
Rate Zone.
Vendors can enter rates at any Specification Layer they choose. For transportation industry pricing problems with two elements in a typical Specification, such as origin and destination, each of which can be subject to Multiple Specification Layers, it is useful to envision the rate storage problem in the form of a matrix.
An origin destination rate matrix at the state-to-state Specification Layer would look like this:
Destinations
State 1 State 2 State 3 State 4 State
N
Region
State 1 Sπ s 12 S m
State 2 • • •
State 3
.a
8 State 4
State N S NI S NN
Where, Sjj= rate for freight between origin state i and destination state j. If there were 50 states in a country, the dimension (i.e., size) of the state-to-state rate matrix would be: dim (State Rate Matrix) = dim (number of states x number of states) = 50 x 50
= 2,500 If all elements, Sy, are unique, the table representation,
(Origin State List/Range) —> (Destination State List/Range) = S, has 2,500 entries. However, if there are repeating elements in the matrix, then a list representation of the matrix offers storage economies over a conventional 2,500 element table. A few examples should serve to illustrate the nature of these economies. Example 1 : A Homogenous Rate Zone contains only one entry in the list representation of a matrix. Let S /= C for all i and j. Let C be a constant number. Then the list representation of this table has one entry of the form: (fS1: SNJ) → ([S1: SNJ) = C.
Example 2: A matrix containing two constant values contains two entries in a list representation of the matrix. Let Sπ, Sn S21 , S2 = D and Sy— E for all i, j > 2. Let D and E be different constant numbers. Then a list representation of this table has two entries: ([Sι: S2]) → ([Sι: S2]) = D ([S3: SN]) → ([S3: SN]) = E
There are two important observations regarding list representations of matrices. First, if there is no price for a Specification, then the coπesponding list element is null and it is not stored. Second, a computer program can convert the list representation of a matrix into a conventional table, complete with repeating values and null values. Such a program can build tables on demand and as needed from any stored list representation. This property is convenient for displaying or printing out the contents of the database.
Example 3. Here is an illustration of a more complex representation of a state-to- state table list:
([Sj: S5J, S8, S10) → ([Sι: S5], S8, S10) = A
Figure imgf000017_0001
This list representation could be expanded to create the following matrix (where A and B are constant numbers) : SI S2 S3 S4 S5 S6 S7 S8 S9 S10
Figure imgf000018_0001
The programming implementation of the list representation could be completed as follows. The abstraction,
(Origin List or Range) —> (Destination List or Range) = R can be codified in any programming language with a pointer construct, such as the C programming language, that can implement arbitrary length lists of records and where records can contain any number of predefined values. Three core constructs are needed to represent the abstraction: a list construct, a price construct, and a Homogenous Rate Zone construct.
A list construct could be defined as a record containing either a single entry or a range of entries. The abstraction (Origin List or Range) could be implemented as a list construct, as could the abstraction (Destination List or Range)
The price construct, R, can be implemented as a record containing one of three possible values: a cuπency amount, a percentage of a named reference table, or a system flag indicating a Heterogeneous Rate Zone.
A Homogeneous Rate Zone construct (Origin List or Range) —> (Destination List or Range) = R could be implemented as a record containing 2 list constructs and a price construct.
A computerized mechanism to store Specification Layer prices could be implemented as a list of Homogenous Rate Zone constructs.
A computerized mechanism to store Multiple Specification Layer prices could be implemented as a list of Specification Layers. In addition, search functions could be built to traverse all defined lists looking for prices that coincide with particular query criteria.
Target Rate List Determination.
According to a system of the present invention all vendor bids for a particular Demand Set are collected and analyzed. Preferably, the collection and analysis are performed online. The analysis is performed by use of an algorithm that is customizable by the Buying Entity. The output of the analysis is a Target Rate List containing a price for each bid element.
The Target Rate List is visible only to the participating vendors by means of, for example, being posted online on a Web site designed for this purpose. The Target Rate List is utilized as a reference point for all subsequent negotiations between the parties for performances in the relevant industry. * Once a Target Rate List is generated and vendors have signaled their willingness to perform for the Buying Entity at the prices indicated on the Target Price List, a Buying Entity can stop the bidding process. A Buying Entity also could invite a second, or other subsequent round(s) of bids, where the bids are expressed as a percentage of the Target Rate List.
Any number of Target Rate List algorithms known in the art may be used. For example, the Target Rate List algorithm may operate as follows: for each element of the Buying Entity's Demand Set, and for each vendor who submitted prices, the algorithm retrieves the best price submitted by that vendor among all defined Multiple Specification Layers. Having collected the set of all such prices for all Specification Layers across all bidding vendors, the Buying Entity may specify an output where, given "m" vendors and a value "n" specified by the Buying Entity, where "m" > "n", the nth lowest bid is chosen for each element of the Buying Entity's Demand Set. Preferably the Target Rate List is subsequently adjusted to achieve internal consistency of the prices, either by blunt ocular analysis or by computerized means.
PRIVATE RATECARD Contracting.
Either the first or the second or subsequent rounds of bidding may lead to a contract for a particular performance or to an agreement to agree on later performances. An agreement to agree takes the form of a PRIVATE RATECARD, which may be expressed as a set of percentages of the coπesponding Target Price List or a set of actual dollar figures.
Figure 5 shows a flowchart for creating a PRIVATE RATECARD. First, the Buying Entity's Demand Set is obtained, step 1000. Then the Multiple Specification Layers are defined, step 1100. Next, the Risk Premia in the Multiple Specification Layers of the Buying Entity's Demand Set are minimized, step 1200. Then price collection is performed with the Multiple Specification Layers, step 1300. Then Target Rate determination is performed with the Multiple Specification Layers, step 1400. Finally, at step 1500, PRIVATE RATECARD contracting is performed with the Multiple Specification Layers.
A PRIVATE RATECARD is an electronic or paper schedule, presented in any acceptable format and containing the set of agreed upon prices for various performance elements. A PRIVATE RATECARD also contains a formula which, with the aid of a PRIVATE
RATECARD calculator in accordance with this invention, is used to translate the schedule of agreed upon prices into a total price for a future specification. Of course, each PRIVATE RATECARD is unique to the Buying Entity and the vendor or vendors which had agreed to the PRIVATE RATECARD schedule.
PRIVATE RATECARD Calculator
According to the present invention, when a Buying Entity with a PRIVATE RATECARD needs to contract with a vendor, the Buying Entity drafts the specifications for the job. The Buying Entity then uses a PRIVATE RATECARD calculator to derive the price for that job. The derivation can be obtained by any means known in the art. Preferably, the PRIVATE RATECARD calculator is an online calculator that includes a look-up engine for locating the relevant bid elements or Specification Levels. The PRIVATE RATECARD calculator implements the PRIVATE RATECARD formula for the agreed upon prices for the relevant bidding elements or Specification Levels and outputs a final price calculation. The format of the output is customizable by the user.
Preferably, the PRIVATE RATECARD calculator is implemented over the Internet to facilitate updates of the calculator to reflect changes in macroeconomic and microeconomic factors, to accommodate new advances in the relevant technology, and to reflect changes to the PRIVATE RATECARD schedule of prices.
The PRIVATE RATECARD calculator can derive prices for multiple PRIVATE RATECARDS. Due to the amount and complexity of the data involved, this task would be immensely burdensome and virtually unmanageable if one were to attempt it manually.
Entering into Contracts Using a PRIVATE RATECARD. Figure 6 shows the use of a PRIVATE RATECARD to create contracts between Buying Entities and vendors. In order to use a PRIVATE RATECARD in industries with Multiple Specification Layers, a Buying Entity first drafts a Specification for its job, step 2000. For example, in the LTL freight industry, the Specification for a job would typically include origin, destination, shipment weight, commodity class, and any ancillary services that may be required. A computer program written in accordance with the present invention by any means known in the art calculates the weight bracket based upon the shipment weight. The present invention then employs the PRIVATE RATECARD calculator to obtain a total job price based on the origin, destination, weight bracket, commodity class, and ancillary services information for the job and retrieves the PRIVATE RATECARD prices for the shipment from all vendors who have agreed to a PRIVATE RATECARD pricing structure, step 2100. The Buying Entity selects the vendor, step 2200, and the vendor then performs the job, step 2300. Public Pricing Index
Referring to Figure 7, according to an alternative embodiment of the invention, any individual, entity or organization may publish a Public Pricing Index, contaimng a schedule of target prices, based on defining Multiple Specification Layers, price collection, and target rate determination processes according to this invention. According to Fig. 7, first, Multiple Specification Layers are defined, step 3000. Then price collection is performed, step 3100. Next, target rate determination is performed, step 3200. Finally, a schedule of target prices is published to create a Public Pricing Index, step 3300. Once the Public Pricing Index is published, some but not all Buying Entities, particularly small and midsize companies, may find that they do not need to conduct the price determination and target rate processes outlined here. Instead, these companies may use the Public Pricing Index. The Public Pricing Index may be adjusted over time for both macroeconomic factors, such as inflation, and microeconomic factors particular to the industry, such as a rapid rate of technological advance. Vendors may publish public asking prices, expressed as a percentage of the Public Pricing Index. The resulting schedule is refeπed to herein as a PUBLIC RATECARD. A vendor may then make the PUBLIC RATECARD pricing available to Buying Entities in the vendor's industry, either by posting the PUBLIC RATECARD online or by any other means known in the art. A Buying Entity may contract with a vendor with the most favorable PUBLIC
RATECARD or, alternatively, a Buying Entity may review the available PUBLIC RATECARD(s), preferably by means of a look-up engine or a search engine that would enable the Buying Entities to search and compare the PUBLIC RATECARD(s) by Specifications of interest. Referring to Fig. 8A, a vendor retrieves the Public Pricing Index, step 4000.
Next, in step 4100, the vendor calculates its public "Ask" prices, e.g., as a percentage of the Public Pricing Index. Finally, in step 4200, the vendor publishes its public "Ask" prices, e.g., via an Internet site designed for this purpose. Optionally, a Buying Entity may use a PUBLIC RATECARD calculator to determine the total price for a given Specification using the pricing schedule in any given
PUBLIC RATECARD. Referring to Fig. 8B, a Buying Entity drafts specification for a job, step
5000. Then, the Buying Entity uses a PUBLIC RATECARD calculator to determine the best "public price" for the job, step 5100. A PUBLIC RATECARD calculator derives a final contract price similarly to the way a PRIVATE RATECARD calculator does so. Then the Buying Entity selects a vendor, step 5200. As an option, this selection may be performed, in part, by a Buying
Entity comparing this output with output obtained by using a PRIVATE RATECARD calculator used in connection with any of the Buying Entity's PRIVATE RATECARD(s). The selected vendor then executes the job, step 5300.
* * *
Buying Entities can utilize both the present invention and the invention described in U.S. Serial No. 60/233,034, titled Standardizing Price Discovery and Negotiations in Commercial Industries and incorporated by reference herein, to comprehensively price all of the services to a Buying Entity from a vendor. For example, in the Freight LTL industry, the system gathers bid data elements from vendors based on any of the several sets of Multiple Specifications Layers that are generally known in the industry, but it also collects the bids charged by these vendors for ancillary services. LTL freight ancillary services can include, but are not limited to, facilities storage, freeze protection, weight verification, stop-off, and redelivery, and generally do not have the problem of Multiple Specification Layers.
It will also be understood that the specifications, figures, examples and tables are illustrative of the present invention and that other embodiments within the spirit and scope of the invention will suggest themselves to those skilled in the art.
All references cited herein are incorporated by reference.

Claims

WHAT IS CLAIMED IS:
1. A computer implemented method of price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values, the method comprising: receiving from a buyer a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one characteristic; providing the demand set to one or more vendors; receiving a bid from at least one of the one or more vendors for one or more specifications of the demand set; storing all received bids; and analyzing all stored bids to identify a prefeπed bid for each specification of the demand set.
2. The method of claim 1 , wherein the step of receiving a bid comprises receiving bids that specify, for at least one specification of the demand set having an associated bid, a value for the at least one characteristic from a different set of the multiple sets of values than the set of the multiple sets of values of the at least one specification of the demand set.
3. The method of claim 1 , wherein the step of receiving a bid comprises receiving bids from m vendors; and wherein for a value n such that m > n, the step of analyzing identifies the nth lowest bid for each specification of the demand set.
4. The method of claim 1, further comprising: providing the prefeπed bid for each specification of the demand set to one or more vendors; and receiving a subsequent bid from at least one of the one or more vendors who received the prefeπed bid for each specification of the demand set, each subsequent bid comprising a percentage of the prefeπed bid for a specification of the demand set.
5. The method of claim 1, wherein the multiple sets of values related to the at least one characteristic are aπanged in a hierarchy, and wherein the step of receiving a bid comprises: for each unique combination of the one or more characteristics that are not capable of being described by multiple sets of values, and for each of the at least one characteristics that is capable of being described by multiple sets of values, and for one or more sets of the respective multiple sets of values in their hierarchical order, receiving data coπesponding to one or more values of the respective set, the data selected from the group consisting of a Homogenous Rate Zone and a Heterogeneous Rate Zone.
6. The method of claim 5, wherein the step of storing all received bids comprises storing each Homogenous Rate Zone as a Homogenous Rate Zone construct comprising one or more lists and a price construct selected from the group consisting of a cuπency amount, a percentage of a table from which a cuπency amount can be derived, and a flag indicating a Heterogeneous Rate Zone.
7. The method of claim 6, wherein the step of storing all received bids comprises storing received data for one or more sets of the respective multiple sets of values as a list of Homogenous Rate Zone constructs.
8. The method of claim 7, wherein the step of storing all received bids comprises storing received data for each of the at least one characteristics that is capable of being described by multiple sets of values as a list of lists of Homogenous Rate Zone constructs.
9. The method of claim 5, wherein the commodity has two or more characteristics that are capable of being described by multiple sets of values, and wherein the step of receiving data comprises receiving data for the two or more characteristics simultaneously using a matrix.
10. The method of claim 1, further comprising creating a pricing schedule related to the prefeπed bid for each specification of the demand set and associated with one or more of the one or more vendors, wherein the schedule includes a formula.
11. The method of claim 10, wherein the pricing schedule is publicly available.
12. The method of claim 10, wherein the step of creating a pricing schedule comprises creating a pricing schedule expressed as a set of percentages of the prefeπed bid for each specification of the demand set.
13. The method of claim 10, wherein the step of creating a pricing schedule comprises creating a pricing schedule expressed in cuπency figures.
14. The method of claim 10, further comprising: receiving a job specification from the buyer; calculating a price for the job specification for each vendor associated with the pricing schedule using the pricing schedule, the job specification, and the formula; receiving from the buyer a selection identifying one of the vendors for which a price was determined to perform the job.
15. A computer system for performing price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values, the system comprising: a computer in communication with a buyer and one or more vendors; and a database; wherein the computer receiving from a buyer a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one characteristic; wherein the computer provides the demand set to one or more vendors; wherein the computer receives a bid from at least one of the one or more vendors for one or more specifications of the demand set; wherein the computer stores all received bids in the database; wherein the computer analyzes all stored bids to identify a prefeπed bid for each specification of the demand set.
16. A computer program product comprising a computer usable medium having computer readable code embodied therein, the computer readable code, when executed, causing a computer to implement a method for price discovery for a commodity having one or more characteristics, wherein at least one of the one or more characteristics is capable of being described by multiple sets of values, the method comprising: receiving from a buyer a demand set of specifications related to the commodity, each specification comprising values for the one or more characteristics, including a value from one of the multiple sets of values for the at least one characteristic; providing the demand set to one or more vendors; receiving a bid from at least one of the one or more vendors for one or more specifications of the demand set; storing all received bids; and analyzing all stored bids to identify a prefeπed bid for each specification of the demand set.
PCT/US2001/043406 2000-11-22 2001-11-21 Standardizing price discovery and negotiations in commercial industries with multiple specification layers WO2002043303A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP01989727A EP1360625A2 (en) 2000-11-22 2001-11-21 Standardizing price discovery and negotiations in commercial industries with multiple specification layers
AU2002228613A AU2002228613A1 (en) 2000-11-22 2001-11-21 Standardizing price discovery and negotiations in commercial industries with multiple specification layers
CA002429947A CA2429947A1 (en) 2000-11-22 2001-11-21 Standardizing price discovery and negotiations in commercial industries with multiple specification layers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US25266700P 2000-11-22 2000-11-22
US60/252,667 2000-11-22

Publications (2)

Publication Number Publication Date
WO2002043303A2 true WO2002043303A2 (en) 2002-05-30
WO2002043303A3 WO2002043303A3 (en) 2003-08-14

Family

ID=22956998

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/043406 WO2002043303A2 (en) 2000-11-22 2001-11-21 Standardizing price discovery and negotiations in commercial industries with multiple specification layers

Country Status (4)

Country Link
EP (1) EP1360625A2 (en)
AU (1) AU2002228613A1 (en)
CA (1) CA2429947A1 (en)
WO (1) WO2002043303A2 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4412287A (en) * 1975-05-29 1983-10-25 Braddock Iii Walter D Automated stock exchange
US5063507A (en) * 1990-09-14 1991-11-05 Plains Cotton Cooperative Association Goods database employing electronic title or documentary-type title
US5845266A (en) * 1995-12-12 1998-12-01 Optimark Technologies, Inc. Crossing network utilizing satisfaction density profile with price discovery features

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4412287A (en) * 1975-05-29 1983-10-25 Braddock Iii Walter D Automated stock exchange
US5063507A (en) * 1990-09-14 1991-11-05 Plains Cotton Cooperative Association Goods database employing electronic title or documentary-type title
US5285383A (en) * 1990-09-14 1994-02-08 Plains Cotton Cooperative Association Method for carrying out transactions of goods using electronic title
US5845266A (en) * 1995-12-12 1998-12-01 Optimark Technologies, Inc. Crossing network utilizing satisfaction density profile with price discovery features

Also Published As

Publication number Publication date
CA2429947A1 (en) 2002-05-30
EP1360625A2 (en) 2003-11-12
AU2002228613A1 (en) 2002-06-03
WO2002043303A3 (en) 2003-08-14

Similar Documents

Publication Publication Date Title
Elmaghraby et al. Combinatorial auctions in procurement
US6751597B1 (en) System and method for adaptive trade specification and match-making optimization
US6131087A (en) Method for automatically identifying, matching, and near-matching buyers and sellers in electronic market transactions
Birge et al. Optimal commissions and subscriptions in networked markets
US20060136324A1 (en) Reverse auction with qualitative discrimination
US20060136325A1 (en) Automated proxy bidding
US20090006122A1 (en) System and method for creating a cost-effective and efficient retail electric power exchange/energy service provider load optimization exchange and network therefor
US20020013760A1 (en) System and method for implementing electronic markets
US20030195836A1 (en) Method and system for approximate matching of data records
WO2001075548A9 (en) System and method for implementing electronic markets
US20060136323A1 (en) Method for determining single figure of merit
WO1999030259A1 (en) Commodity exchanging apparatus, commodity exchanging system, commodity exchanging method and storage medium
AU2006244499B2 (en) Portfolio execution and reporting
US20160379284A1 (en) Landlord-Tenant-Property Matching System and Matrix
US20020107786A1 (en) Peer-to-peer application for online goods trading
US20040039682A1 (en) Preference elicitation in combinatorial auctions
US20070250430A1 (en) Peer-to-peer based marketplaces
CN114493430B (en) Logistics distribution system and method based on big data
Balcan et al. Generalization guarantees for multi-item profit maximization: Pricing, auctions, and randomized mechanisms
US20020147596A1 (en) On-line laboratory services brokerage system
US20030028455A1 (en) Information supply system
WO2001031537A2 (en) System and method for adaptive trade specification and match-making optimization
US20020116315A1 (en) System and method for bidding in multiple auctions
US20110054989A1 (en) Methods for Providing Network Marketing and Revenue Sharing to Participants of an Electronic Marketplace System
WO2002043303A2 (en) Standardizing price discovery and negotiations in commercial industries with multiple specification layers

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2429947

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2001989727

Country of ref document: EP

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2001989727

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2001989727

Country of ref document: EP

NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP