WO2001075740A2 - System and method for multi-variable auctions - Google Patents

System and method for multi-variable auctions Download PDF

Info

Publication number
WO2001075740A2
WO2001075740A2 PCT/US2001/010568 US0110568W WO0175740A2 WO 2001075740 A2 WO2001075740 A2 WO 2001075740A2 US 0110568 W US0110568 W US 0110568W WO 0175740 A2 WO0175740 A2 WO 0175740A2
Authority
WO
WIPO (PCT)
Prior art keywords
auction
seller
bid
financial instrument
responses
Prior art date
Application number
PCT/US2001/010568
Other languages
French (fr)
Inventor
Brian M. Overstreet
Robert F. Kyle
Howard S. White
Original Assignee
Directplacement.Com, 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 Directplacement.Com, Inc. filed Critical Directplacement.Com, Inc.
Priority to AU2001251219A priority Critical patent/AU2001251219A1/en
Publication of WO2001075740A2 publication Critical patent/WO2001075740A2/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions

Definitions

  • the field of the invention pertains to a system and method for implementing the sale of complex items with multiple pricing variables in an auction format. Further, the invention extends to a system and method for implementing a multi-variable auction for transactions associated with private investment in public equities using a global computer network.
  • Description of the Related Technology In the retail commerce setting, most goods and services are sold using a general seller-driven protocol where the seller sets a price and the buyer decides whether or not to accept that price. Prices for some goods and services might change frequently, but the buyer must still wait for the seller to offer a price that he or she finds acceptable. Some forms of commerce offer far more flexible environments, for example, allowing the buyer and the seller to exchange multiple offers and counteroffers. However the vast majority of retail purchases utilize seller-driven, fixed- price, non-negotiable pricing protocols.
  • auctions serve as an example of a common commerce model which allow buyers and sellers to avoid the inflexibility of fixed-price, non-negotiable pricing protocols.
  • auctions are seller-driven in that the seller attracts numerous buyers who, as a group, determine the final selling price.
  • the auction model has been particularly successful in providing merchants or independent sellers an excellent medium to offer a variety of goods and services for sale in multiple auction formats.
  • the basic auction format is known as the American or Yankee auction where a number of items are offered for sale and the highest bids "win.”
  • a derivation of this standard auction format allows a reserve prices to be set by the seller such that a minimum bid price is selected (which the seller may or may not choose to disclose).
  • this reserve auction format (or alternatively auction with reserve), the seller has the option to accept or reject bids which do not meet the reserve.
  • the standard auction format is also know as an absolute auction (or an auction without reserve) because the highest bid is deemed to have won the purchase of the item(s).
  • Another auction format is known as the Dutch auction where the seller lists multiple identical items. After a bidding period, all winning bidders pay the same price for the time, that is the lowest successful bid.
  • Internet sites have applied a different twist to the online auction by offering "reverse auctions.”
  • the many examples of auction-based commerce systems described above operate in a single bid variable format, namely price. That is, the bidder with the highest bid price wins the auction and so the conventional auction commerce models can be supported with a simple, single variable calculation to determine the auction winner.
  • the existing model is efficient for the sale of commodities such as televisions, electric power, automobiles, and items traditionally sold at garage sales.
  • the conventional model is unable to determine the highest bid on the items for sale which have a plurality of variables which contribute to the computation of the highest bid, especially when each of the variables has a different degree of importance in the computation of the highest bid.
  • a large number of variables comprise the pricing of the instrument, for example, the interest rate, the term, the price, the payment terms, the quantity, etc.
  • the private equity market often involves deals with offerings of such complex financial instruments.
  • private investments in public equities typically rely on offering a variety of complex financial instruments for sale to selected bidders.
  • PIPE public equities
  • These sorts of "private placements” can be structured to include the offering of simple shares of common stock or more complicated offerings of warrants and fixed and variable convertible preferred stock issues.
  • the PIPE market today is highly fragmented and populated by small brokerage firms and independent agents. Due to the smaller size of most PIPE transactions (less than $10 million) the large investment and brokerage firms are typically not involved in PIPE transactions. This sort of market situation provides an excellent opportunity for applications of Internet technology.
  • a multi-variable auction system need not only be limited to the PIPE market.
  • Application of a multi-variable online auction system can be expanded into other inefficient securities markets, such as the high yield debt market, the convertible debt market, and the foreign private placement market. All of these markets (which are considerably larger than the PIPE market) are highly fragmented, completely inequitable, and currently inaccessible to a broad group of investors.
  • the multi-variable auction system is particularly well suited for the high yield and convertible debt markets where price, coupon, term, and other variables all play a vital part in the transaction.
  • One embodiment of the invention comprises a multi-variable auction wherein a plurality of bidders can make a bid on an item with multiple pricing variables.
  • the invention provides a multi-variable valuation process whereby the seller of the item assigns a variable value to each of the pricing variables associated with the item for auction, a multi- variable response valuation process whereby the seller assigns a value to potential responses available to the bidders for each pricing variable, and a valuation matrix process configured to calculate a bid value for each of the bids made by the bidders, wherein the bid value measures the responses selected by the bidders based on the values of the pricing variables and the values of the responses.
  • the invention includes a ranking process which ranks the bid values associated with each of the bidders.
  • Another embodiment of the invention can include an auction method comprising offering an item with multiple pricing variables for sale and assigning a seller-defined value to each of the pricing variables associated with an item for sale.
  • the invention includes a method comprising defining possible responses for each of the pricing variables which may be selected by a bidder and assigning a seller-defined value to each of the possible responses.
  • the bidder can bid on the item by choosing responses from the possible responses defined by the seller and then a bid value is calculated based on the values of the pricing variables and the corresponding values of the responses chosen for the pricing variable. Finally, the bid values are ranked to determine the winning bid.
  • Figure 1 is block diagram illustrating one network configuration that comprises a client computer and a server computer that are connected via a network.
  • Figure 2 is a block diagram illustrating one network configuration that comprises a web browser and a server computer that are connected via a network, such as the network of Figure 1, whereby the web server provides a bidding engine.
  • Figure 3 is a block diagram illustrating an embodiment of the interrelationships of three processes which calculate inputs for the bidding engine of Figure 2, namely the multi-variable valuation process, the multi-variable response valuation process, and the valuation matrix process.
  • Figure 4 is a block diagram illustrating an embodiment of the multi-variable valuation process of Figure 3.
  • Figure 5 illustrates an example of a web page display of an embodiment of the multi-variable valuation process of Figure 3.
  • Figure 6 is a block diagram illustrating an embodiment of the multi-variable response valuation process of Figure 3.
  • Figure 7 illustrates an example of a web page display of an embodiment of the multi-variable response valuation process of Figure 3.
  • Figure 8 is a block diagram illustrating an embodiment of the valuation matrix process of Figure 3.
  • Figure 9 illustrates an example of a web page display generated by one embodiment of the invention whereby the valuation matrix process of Figure 8 has calculated a bid value for a particular bid.
  • Figure 10 is a block diagram illustrating the relationships between the various database tables used by valuation matrix process shown in Figure 3.
  • On embodiment of the invention is a system and method for implementing the sale of complex items, for example, complex financial instruments, with multiple pricing variables using a multi-variable auction format.
  • Another embodiment of the invention comprises a multi-variable auction for auctioning financial instruments such as those related to private investments in public equities (commonly referred to as "PIPE" transactions).
  • the invention can automatically analyze and rank the competitive bids and precisely determine which bid carries the maximum economic benefit to the seller of the complex items.
  • the invention extends to a system and method for implementing a multi-variable auction using a global computer network, such as the Internet.
  • one embodiment of the invention offers an exclusive online destination providing institutional and accredited investors a way to directly purchase, sell, and research PIPE securities.
  • a user 102 communicates with a computing environment which may include multiple server computers 108 or single server computer 110 in a client/server relationship on a computer network 116.
  • a computing environment which may include multiple server computers 108 or single server computer 110 in a client/server relationship on a computer network 116.
  • each of the server computers may include multiple server computers 108 or single server computer 110 in a client/server relationship on a computer network 116.
  • each of the server computers may include multiple server computers 108 or single server computer 110 in a client/server relationship on a computer network 116.
  • the server computers 108, 110 includes a server program which communicates with a client computer 115.
  • the server computers 108, 110 includes a server program which communicates with a client computer 115.
  • the server computers 108, 110 includes a server program which communicates with a client computer 115.
  • the client computer 115 may each have any conventional general purpose single- or multi-chip microprocessor such as a Pentium '8 processor, a Pentium* Pro Processor, a 8051 Processor, a MIPS* Processor, a
  • the microprocessor may be any conventional special purpose microprocessor such as a digital signal processor or a graphics processor.
  • the server computers may be any conventional special purpose microprocessor such as a digital signal processor or a graphics processor.
  • the server computers 108, 110 and the client computer or computing device 115 may be desktop, server, portable, hand-held, set-top, wireless telephone or any other desired type of configuration.
  • the server computers 108, 110 and the client computer 115 each may be used in connection with various operating systems such as: Unix, Linux, disk operating system (DOS), OS/2, Windows 3.X, Windows 95, Windows 98, and Windows NT.
  • the server computers 108, 110, and the client computer 115 may each include a network terminal equipped with a visual display, keyboard (or keypad) and pointing device (or cursor control, such as arrow buttons).
  • the client computer 115 includes a network browser 320 that is used to access the server computer 110.
  • the network browser 120 is the Internet
  • the user 102 at the computer 115 may utilize the browser 120 to remotely access the server program using a keyboard and/or pointing device and a visual display, such as a monitor 118, liquid crystal displays, or the like. It is noted that although only one client computer 115 is shown in Figure 1, the network configuration 300 can include many client computers as may be associated with a global computer network.
  • WAP Wireless Applications Protocol
  • the network 116 may include any type of electronically connected group of computers including, for instance, the following networks: a virtual private network, a public Internet, a private Internet, a secure Internet, a private network, a public " network, a value-added network, an intranet, a packet switched network, a circuit switched network, a combination packet and circuit switched network, and the like.
  • the connectivity to the network may be, for example, remote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink linterf ace (FDDI) or Asynchronous Transfer Mode (ATM).
  • the network 116 may connect to the client computer 115, for example, by use of a modem, by use of a network interface card that resides in the client computer 115, or by wireless cellular protocols such as GSM or CDMA.
  • the server computers 108 may be connected via a wide area network 106 to a network gateway 104, which provides access to the wide area network 106 via a high-speed, dedicated data circuit.
  • Devices other than the hardware configurations described above, may be used to communicate with the server computers 108, 110. If the server computers 108, 110 are equipped with voice recognition or DTMF hardware, the user 102 can communicate with the server programs by use of a telephone 124.
  • Other connection devices for communicating with the server computers 108, 110 include a portable personal computer 126 with a modem or wireless connection interface, a cable interface device 128 connected to a visual display 130, or a satellite dish 132 connected to a satellite receiver 134 and a television 136.
  • the user may connect to the network with a wireless handheld device such as those popularized by Motorola, Nokia, Sony, Ericcson, 3Com/Palm, and so forth.
  • a wireless handheld device such as those popularized by Motorola, Nokia, Sony, Ericcson, 3Com/Palm, and so forth.
  • each of the above hardware configurations are included within the definition of the client computer 115.
  • the invention may be practiced with other ways of allowing communication between the user 102 and the server computers 108, 110, either available now or as may be developed in the future.
  • server computers 108, 110 and the client computer 115 may not necessarily be located in the same room, building or complex.
  • the client computer 115 is generally remotely located from the server computers 108, 110.
  • a client computer having a web browser 210 can initiate an Hypertext Transport Protocol ("http") request 215 via the network 102.
  • the http request 215 can be passed to a web server 220 which retrieves an associated program page 225.
  • the program page 225 may be a Hypertext Markup Language (HTML) page, an extended HTML page with codes (e.g., ColdFusion codes), an Extended Markup Language (XML) page, a program or collection of programs (such as a Java or JavaScript protocol), a common gateway interface (CGI) protocol, and so on.
  • HTML Hypertext Markup Language
  • XML Extended Markup Language
  • CGI common gateway interface
  • a bidding engine 230 of the invention then processes the program page 225, and ultimately a web page 235 is transmitted to the client computer via the network 102.
  • the bidding engine 230 may be configured to communicate with a web page engine 240 such as the ColdFusion server application.
  • a web page engine 240 such as the ColdFusion server application.
  • Such an application may be in data communication with a database server 245, a file system 250, and email server 255, various distributed objects 260, and other enterprise systems 265 or legacy systems.
  • the bidding engine 230 and web page engine 240 may be combined, subdivided, or partitioned in any number of ways.
  • the bidding engine 230 can be created using a web auction development tool set, such as Virtual Auctioneer available from eyemedia, Inc. of Dallas, Texas. This tool set can use an RAD (rapid application development) middleware product in order to enable the query and manipulation of data from databases and to dynamically render the results as web pages.
  • RAD rapid application development
  • ColdFusion Application Server v4.0 from Allaire is the middleware product.
  • the minimum system requirements in one such configuration are Windows NT v4.0, ColdFusion application server v4.0, and Microsoft SQL server 7.0.
  • the output from the bidding engine 230 may be subsequently processed by the web page engine 240 application, such as ColdFusion.
  • the bidding engine 230 serves to generate the bid results based on the inputs of various processes of the invention.
  • the embodiment of this invention comprises three processes which calculate inputs for the bidding engine 230: (i) the multi-variable valuation process 320, (ii) the multi-variable response valuation process 340, and (iii) the valuation matrix process 360.
  • these processes may be combined or partitioned in a number of ways. For instance, they may all be included in the bidding engine 230.
  • Each of these processes are depicted in Figures 4, 5, and 6, respectively.
  • a seller 300 interested in offering an item for sale with a plurality of variables provides input to the multi-variable valuation process 320 and the multi-variable response valuation process 340.
  • the valuation matrix process 360 uses the valuations generated by these two processes (namely the multi-variable valuation process 320 and the multi-variable response valuation process 340) and applies the bid 380 submitted by a bidder 390 to create an input for the bidding engine 230.
  • Figure 4 illustrates an embodiment of the multi-variable valuation process 320.
  • the seller 300 defines which transaction term variables will be available for bidding in the auction.
  • the seller can select N variables, where N is a positive integer greater than zero.
  • the selected variables are depicted in a variable table 410.
  • the seller 300 assigns a variable value to each variable.
  • the variables with assigned variable values are depicted in a selected variables table 430.
  • variable value could be an integer between 10 and 50 and the seller 300 could assign higher variable values to those variables which the seller 300 considers more important in the auction.
  • the selected variables may have the same variable value or they may all have different variable values. For example, if the seller is offering shares of preferred stock of a company for private placement, then the seller 300 may have selected the following variables with the following variable values:
  • Figure 5 illustrates an example of a web page display generated by one embodiment of the invention whereby the seller 300 has assigned variable values to three transaction term variables.
  • the web page display of one embodiment of the invention as depicted in Figure 5 allows the seller 300 to assign variable value in box 50 for a transaction term listed in heading 52.
  • the web page display can list transaction term variables previously entered by the seller 300 with previously assigned variable values listed as well. If the seller 300 has also defined potential responses for the transaction term variable listed in heading 52, the potential response weights for those defined potential responses, and the sorting order for the defined potential responses (e.g., the order in which the potential responses will be displayed), then these definitions can be listed in response section 56.
  • Figure 6 depicts an embodiment of the multi-variable response valuation process 340.
  • the seller 300 selects a potential response for each of the N variables.
  • a potential response table 510 illustrates as an example, the potential responses selected for variable 1 and variable 2.
  • the number of potential responses chosen by the seller 300 must be less than the variable value assigned to that variable by the seller 300 in state 420. This may be desirable for normalizing the results.
  • the seller can select x H potential responses for each selected variable, where x N is a positive integer greater than zero but less than the variable value assigned to variable N.
  • the seller 300 has selected x, potential responses for variable 1 and x 2 potential responses for variable 2.
  • Each selected variable may have more than, less than, or an equal number or potential responses as the other selected variables (e.g., x, can be greater than x 2 , x . can be less than x 2 , or x, can equal x 2 ).
  • x cannot be greater than the variable value assigned to variable 1 and x 2 cannot be greater than the variable value assigned to variable 2.
  • the seller 300 assigns a potential response weight to each potential response.
  • a potential response weight table 530 illustrates an assignment by the seller 300 of potential response weights to the x, potential responses selected for variable 1 and the x 2 potential responses selected for variable 2.
  • the seller 300 can assign a higher potential response weight to those potential responses which the seller 300 considers more important in the auction.
  • the selected variables may have the same potential response weight or they can have different potential response weights.
  • the potential response weights assigned to each potential response are calculated based on the number of potential responses available and the number of potential response weights available for assignment. For example, the potential response weight can be calculated so that the marginal difference between each potential response weight for a particular response is equal or nearly so (i.e., a linear response function).
  • the "step" between each potential response weight can be calculated according to the following formula:
  • PRW -1 step x N -l
  • the "step" between each potential response weight can be calculated according to the following formula:
  • Number of transaction term variables 4
  • Potential response weight range 1 to 10
  • PRW-1 10-1 9 .
  • the potential response weight assigned to each potential response for variable 2 could be:
  • the potential value range can be increased from 1 to 10, to 1 to 100, or 1 to 1,000, for example.
  • Randomly chosen potential response weights can have asymmetrical steps up or down in value and consequently, the potential response weight can skew the significance of a variable value.
  • the “steps" between each potential responses value are equal or nearly so and consequently the seller 300 can prevent the potential response variable value from determining the significance of the bid.
  • a non-linear function could be used for step to obtain a desired objective, e.g., exponential, impulse, sigmoidal, etc.
  • Figure 7 illustrates an example of a web page display generated by one embodiment of the invention whereby the seller 300 has assigned potential response weights to selected potential responses.
  • the web page display of one embodiment of the invention as depicted in Figure 7 allows the seller 300 to define a potential response for a particular transaction term variable listed in heading 70 and then assign potential response weights for each defined potential response.
  • the seller 300 can define a potential response by entering data in response blocks 72.
  • the seller 300 can assign a response weight to each response by entering numerical data in weight blocks 74.
  • sorting blocks 76 the seller 300 can define how the potential response and potential response weights will be sorted (e.g., the order in which the potential responses will be displayed).
  • FIG. 8 illustrates an embodiment of the valuation matrix process 360.
  • the bidder 390 selects a potential response for each of the selected variables chosen by the seller 300 for the time offered for sale. After selecting a potential response for each selected variable, the bidder 390 submits his or her bid 380 to the valuation matrix process 360 at state 610.
  • the valuation matrix process 360 determines the overall value of the bid 380 by calculating a bid value at state 620.
  • the valuation matrix process 360 calculates the bid value by multiplying each of the variable values by the potential response weights corresponding to the potential responses for the selected variable. The products of the variable values and the potential response weights are added together to create bid value, as represented in the following equation: l , x SPRW, V 2 x SPRW 2
  • the bid value could be calculated as:
  • the bid value could also be calculated as the sum of the each value variable divided by the selected response value (or alternatively, the sum of the each selected potential response weight divided by the corresponding variable values).
  • the bid value could be calculated as the sum of all the values (namely, the sum of all the variable values and the selected potential response weights).
  • the bid value can be calculated based on the discounted cash flows generated from the actual terms chosen by the bidder 390 based on the potential response weights selected by the bidder 390 (for a general discussion of calculating the value of discounted cash flows, see Brealey, Richard A. and Myers, Stewart C, Principles of Corporate Finance, 4 th ed., McGraw Hill, 1991).
  • the bid value can also be calculated based on geometric or other non-linear relationships between the various values. For example, a natural logarithm could be applied to individual weighted values to compress the range of results.
  • values and weights do not have to be limited to integer numbers or subject to the ranges identified here.
  • the seller 300 can assign a default potential response for each selected variable.
  • the seller 300 can set a default (or a minimum or a reserve) bid value. That is, if a default bid value is set by the seller 300, then the seller is only obligated to accept bids that equal or exceed its default bid value.
  • each bid is put in a rank ordered list by the bidding engine 230 in state 630.
  • the bidding engine 230 can assess which bids have a higher bid value and rank those bids accordingly. If there are multiple units being sold in the auction, the bidding engine 230 can determine how many units will be allocated to a specific bid based on the ranking of that bid at the time the bid is submitted. If a default bid value has been selected by the seller 300, the bidding engine 230 can determine whether bids equal and/or exceed the default bid value. In state 640, the seller 300 can select the winning bid from the rank ordered list.
  • Figure 9 illustrates an example of a web page display generated by one embodiment of the invention whereby the valuation matrix process 360 has calculated a bid value for a particular bid and allows the bidder 390 to confirm and submit his or her bid.
  • the web page display of one embodiment of the invention as depicted in Figure 9 can display a summary of information about the bid 380 of a particular bidder 390 in a bid ranking box 90. This information can include, for example, the bid value calculated for that bid, the ranking of that bid value index among the other previously submitted bids, and the date that bid was submitted. Additionally, the bid ranking box 90 can display any previously submitted bids by that particular bidder 390.
  • the details of the bid can be displayed, such as the selected response for each transaction term variable and the total bid amount.
  • the bidder 390 can review this information and either confirm and submit the bid by activating a submit button 94 or edit the bid 380 by activating a change button 96.
  • the bidding engine 230 may rely on a database accessed through the web page engine
  • Data entered by sellers and bidders are recorded in numerous tables stored in the database server 245.
  • the relationships between some of the database tables in one particular embodiment is illustrated in Figure 7 as an example.
  • a user with programming knowledge can also configure the invention to update data stored in a legacy system.
  • the Products database table 700 holding the general product information depicted in Figure 10.
  • the Products database table 700 can hold data such as asking price, starting price, and quantity on hand.
  • the Products database table 700 holds data from numerous other tables.
  • the Products database table 700 holds the identity of the seller 300 and so is linked to the Seller database table 710 storing various details about the seller 300.
  • the Products database table 700 also holds the bidder identification and so is also linked to the Bids database table 720 and the Bidders database table 730. These database tables store data regarding the history of bids on listed items and detailed data of the bidder 390, respectively.
  • the transaction term variables as selected by the seller 300 can be stored in the Variables database table 740. Potential responses to each transaction term variable can be stored in Potential Responses database table 750. Both the Variables database table 740 and the Potential Responses database table 750 can be linked to the Products database table 700. The potential responses selected by the bidder 390 can be stored in the Selected Potential Responses database table 760. The Potential Responses database table 760 can be linked to both the Bidders database table 730 and the Products database table 700.
  • the Products database table 700 can include fields such as ProductlD, ProductTypelD, CategorylD, ProductName, ShortDescription, LongDescription, DateCreated, and Status.
  • the ProductName, ShortDescription, and LongDescription fields can store textual data concerning the name of the product given by the seller 300 and a short and long description of the product given by the seller 300.
  • the seller 300 can also identify the category, which can delineate in which market the seller 300 wants to sell his or her product(s), such as the primary market and the secondary market. This data can be stored as textual or numerical identifiers in the CategorylD field.
  • seller 300 can also identify the product type (such as a common stock, preferred stock, bond, etc.) of the product, and this data can be stored as textual or numerical identifiers in the ProductTypelD field. Additionally, each product offered for sale by the seller 300 can be given a unique identifier. In a further embodiment, this identifier can be automatically generated by the bidding engine 230. This identifier can be stored in the ProductlD field.
  • product type such as a common stock, preferred stock, bond, etc.
  • the Seller database table 710 can include data fields regarding the seller 300.
  • the Seller database table 710 can store data in fields such as SellerlD, SellerName, SellerUserName, and SellerPassword.
  • the seller 300 can enter his or her name and this textual data can be stored in the field SellerName.
  • the seller 300 can be prompted to select a user name and password, which, when entered in combination, can be used to provide selective access to the invention by the seller 300.
  • This data can be either textual or numerical in form and can be stored in fields SellerUserName, and SellerPassword.
  • the Bidders database table 730 can store data in a number of fields.
  • fields such a BidderlD, UserName, Password, FirstName, LastName, Address, City, StatelD, Zip, Phone, Email, DateCreated, and Active.
  • Contact information for a bidder 390 such as his or her first and last name, address, city, state, zip, telephone number, and email address can be stored in fields FirstName, LastName, Address, City, StatelD, Zip, Phone, and Email, respectively.
  • the bidder 390 can be prompted to select a user name and password, which, when entered in combination, can be used to provide selective access to the invention by the bidder 390.
  • This data can be either textual or numerical in form and can be stored in fields UserName, and Password.
  • the Bidders database table 730 can keep track of when bidders enter the web site by storing the date their account was created in a DateCreated field.
  • the Bids database table 720 can hold data in various fields such as BidlD, ProductlD, BidderlD, Amount, and
  • the ProductlD and BidderlD field data can be provided by the Products database table 700 and the Bidders database table 730, respectively.
  • the amount of the bid 380 made by the bidder (for example, in U.S. dollars) can be stored in the Amount field.
  • the number of products on which the bidder 390 is making a bid 380 can be stored in the Quantity field.
  • each bid 380 made by a bidder 390 can be given a unique identifier.
  • This identifier can be automatically generated by the bidding engine 230. This identifier can be stored in the BidlD field.
  • the Variables database table 740 can store the textual and numerical data relating to the various pricing variables associated with each product. As examples, the following fields can be stored in the Variables database table 740: QuestionlD, ProductlD, Question, and VariableValue.
  • the ProductlD field data can be provided by the Products database table 700.
  • the text of a question prompting a bidder 390 to select a potential repsonse to a pricing variable can be stored in the Question field and the QuestionlD field can store a unique identifier to that question.
  • the variable value assigned by the seller 300 to the transaction term variable associated with the question can be stored in the VariableValue field.
  • the Potential Reponses database table 750 can then store the potential responses to the questions associated with each transaction term variable and stored in the Variable database table.
  • the Potential Responses database table 750 can include, for example, fields such as QuestionlD (provided by the Variables database table 740), BidderlD (provided by the Bidders database table 730), ProudctlD (provided by the Products database table 700), PotentialResponselD, PotentialResponse, and PotentialResponseWeight.
  • the potential responses available to the bidder 390 can be stored as textual and/or numerical data in the PotentialResponse field and the PotentialResponselD field can store a unique identifier to that potential response.
  • the potential response weight assigned by the seller 390 to that particular potential response can be stored in the Potential response database table 750 as well in the PotentialResponseWeight field.
  • Selected Potential Responses database table 760 When the bidder 390 has selected various potential responses for each question associated with a transaction term variable, these selected potential responses can be stored in the Selected Potential Responses database table 760. Fields such as PotentialResponselD, PotentialResponse, PotentialResponseWeight, ProductlD, Question, VariableValue, BidderlD, and SeiectedPotentialResponse can be stored in the Selected Potential Responses database table 760.
  • the PotentialResponselD, PotentialResponse, and PotentialResponseWeight fields can be supplied by the Potential Responses database table 750 and the ProductlD, Question and VariableValue, and BidderlD fields can be provided by the Products database table 700, the Variables database table 740, and the Bidders database table 730.
  • the textual or numerical data of the potential response selected by the bidder 390 for a particular question on a pricing variable can be stored in the SeiectedPotentialResponse field. This is but one of many data sche as that could be used to implement the principles of the present invention.
  • standard commercial database management programs available from companies such as Oracle, Informix, Sybase, and Microsoft could be used to implement the database.

Description

SYSTEM AND METHOD FOR MULTI-VARIABLE AUCTIONS
Background Field of the Invention The field of the invention pertains to a system and method for implementing the sale of complex items with multiple pricing variables in an auction format. Further, the invention extends to a system and method for implementing a multi-variable auction for transactions associated with private investment in public equities using a global computer network. Description of the Related Technology In the retail commerce setting, most goods and services are sold using a general seller-driven protocol where the seller sets a price and the buyer decides whether or not to accept that price. Prices for some goods and services might change frequently, but the buyer must still wait for the seller to offer a price that he or she finds acceptable. Some forms of commerce offer far more flexible environments, for example, allowing the buyer and the seller to exchange multiple offers and counteroffers. However the vast majority of retail purchases utilize seller-driven, fixed- price, non-negotiable pricing protocols.
Auctions serve as an example of a common commerce model which allow buyers and sellers to avoid the inflexibility of fixed-price, non-negotiable pricing protocols. In general, auctions are seller-driven in that the seller attracts numerous buyers who, as a group, determine the final selling price.
Other commerce systems exist which are exchange-driven. That is, these exchange driven commerce models, such as a trading floor model, match buyers and sellers by offering an efficient, fair and orderly marketplace. These systems, such as National Association of Securities Dealers Automated Quotations (NASDAQ) or the New York Stock Exchange (NYSE) favor neither buyers nor sellers, but simply effectuate communications that allow for the matching process to take place. An example of an automated exchange-driven commerce system for trading futures is disclosed in U.S. Patent No.4,903,201 to Wagner. The Internet has provided an environment where various forms of commerce models can be implemented.
Many types of commerce systems, such as malls, catalogs and auction house, are being implemented on the Internet in order to utilize the inherent advantages of the Internet. These electronic commerce approaches generally seek to create better seller or exchange-driven systems by making the sale of goods and services more efficient.
Today, many Internet sites offer online retail service and online auctions in many varied formats. Both forms of commerce models have been largely successful. The auction model has been particularly successful in providing merchants or independent sellers an excellent medium to offer a variety of goods and services for sale in multiple auction formats. The basic auction format is known as the American or Yankee auction where a number of items are offered for sale and the highest bids "win." A derivation of this standard auction format allows a reserve prices to be set by the seller such that a minimum bid price is selected (which the seller may or may not choose to disclose). In this reserve auction format (or alternatively auction with reserve), the seller has the option to accept or reject bids which do not meet the reserve. In this context, the standard auction format is also know as an absolute auction (or an auction without reserve) because the highest bid is deemed to have won the purchase of the item(s). Another auction format is known as the Dutch auction where the seller lists multiple identical items. After a bidding period, all winning bidders pay the same price for the time, that is the lowest successful bid. Recently, Internet sites have applied a different twist to the online auction by offering "reverse auctions."
In this format, prospective buyers and not sellers offer prices for goods and services for auction and sellers and merchants are permitted to bid on these asking prices.
In addition to the many varied retail and auction forms of commerce models available on the Internet, some securities brokerage sites have also implemented standard trading floor models. In this format, subscribers to the Internet site can trade securities online, which are listed on a public exchange. Asking and bidding prices are updated instantaneously.
The many examples of auction-based commerce systems described above operate in a single bid variable format, namely price. That is, the bidder with the highest bid price wins the auction and so the conventional auction commerce models can be supported with a simple, single variable calculation to determine the auction winner. The existing model is efficient for the sale of commodities such as televisions, electric power, automobiles, and items traditionally sold at garage sales. However, the conventional model is unable to determine the highest bid on the items for sale which have a plurality of variables which contribute to the computation of the highest bid, especially when each of the variables has a different degree of importance in the computation of the highest bid. For example, with the sale of complex financial instruments, a large number of variables comprise the pricing of the instrument, for example, the interest rate, the term, the price, the payment terms, the quantity, etc.
Consequently, the sale of complex items, such as financial instruments, with multiple pricing variables is currently not possible in the conventional auction format. Moreover, due to the inherent complexity of such multi- variable items, it is almost impossible for the seller to accurately determine the best bid without an automated process. Therefore, a selling party is unable to rely on an objective mathematical calculation of the highest bid and, as a result, the selling party must in part depend on a more subjective estimation of the best bid. This can place the selling party at a considerable disadvantage as they are not assured of the highest possible bid for the item that they are selling and instead must make a "best guess" as to the highest bid when comparing multiple offers from potential buyers.
The private equity market often involves deals with offerings of such complex financial instruments. For example, private investments in public equities (commonly referred to as "PIPE" transactions) typically rely on offering a variety of complex financial instruments for sale to selected bidders. These sorts of "private placements" can be structured to include the offering of simple shares of common stock or more complicated offerings of warrants and fixed and variable convertible preferred stock issues.
First popularized in the early 1990's, the current PIPE market offers public companies the ability to sell large blocks of their securities to institutional investors in lieu of conducting a secondary public offering. For the issuing company, a PIPE sale is much less costly, time consuming, and regulated than a secondary public offering. For the investor, a PIPE transaction allows it to invest a large amount of money and receive a preferential stake in the public company. In 1998, newly issued PIPE transactions totaled $11 billion. That amount exceeded $18 billion in 1999. Domestically, approximately 100 institutional investors dominate the PIPE marketplace. In addition, currently over 3,000 institutions invest in PIPE securities to augment their primary investment strategies, with new institutions entering the market every day.
The PIPE market today is highly fragmented and populated by small brokerage firms and independent agents. Due to the smaller size of most PIPE transactions (less than $10 million) the large investment and brokerage firms are typically not involved in PIPE transactions. This sort of market situation provides an excellent opportunity for applications of Internet technology.
Currently, investment and brokerage firms have not focused on applying the Internet technology to the PIPE market. However, many firms rely on the Internet as an excellent resource for structuring other financial deals. Wit Capital, W.R. Hambrecht, E-Offering, Direct Stock Market (dsm.com), Off Road Capital, nvst.com, and garage.com are but just some examples. These firms and others like them provide venture funding and related services for private companies or service initial public offerings (IPOs) and secondary initial public offerings on the internet; however, in general, none of these services have been expanded to raise private capital for public companies. The firms which currently do offer select PIPE and venture capital transactions to their accredited clients, rely on the traditional offering process of a managed placement or underwriting. A few firms also enable issuers to sell their IPO securities in a simple price-based auction but without current plans of entering the PIPE market. More importantly, no services currently exist for an auction based direct-to-investor format for PIPE transactions; moreover, no services exist for a multi-variable auction system in the PIPE market.
Additionally, a multi-variable auction system need not only be limited to the PIPE market. Application of a multi-variable online auction system can be expanded into other inefficient securities markets, such as the high yield debt market, the convertible debt market, and the foreign private placement market. All of these markets (which are considerably larger than the PIPE market) are highly fragmented, completely inequitable, and currently inaccessible to a broad group of investors. The multi-variable auction system is particularly well suited for the high yield and convertible debt markets where price, coupon, term, and other variables all play a vital part in the transaction.
There is a need for a system and method to offer a multi-variable auction format for the sale of complex items, such as financial instruments, with multiple pricing variables. Additionally, there is a need for this system and method to offer this multi-variable auction in an automated and easily accessible format, such as on a global computer network. Such an invention would provide the selling party with a system and method to determine more accurately and precisely the best bid for various and complex items. Moreover, the invention would provide buyers with the opportunity to trade for various complex items such as financial instruments. Summary of the Invention The system of the present invention has several features, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this invention, certain aspects and embodiments are presented below. One embodiment of the invention comprises a multi-variable auction wherein a plurality of bidders can make a bid on an item with multiple pricing variables. The invention provides a multi-variable valuation process whereby the seller of the item assigns a variable value to each of the pricing variables associated with the item for auction, a multi- variable response valuation process whereby the seller assigns a value to potential responses available to the bidders for each pricing variable, and a valuation matrix process configured to calculate a bid value for each of the bids made by the bidders, wherein the bid value measures the responses selected by the bidders based on the values of the pricing variables and the values of the responses. Moreover, the invention includes a ranking process which ranks the bid values associated with each of the bidders.
Another embodiment of the invention can include an auction method comprising offering an item with multiple pricing variables for sale and assigning a seller-defined value to each of the pricing variables associated with an item for sale. Moreover, the invention includes a method comprising defining possible responses for each of the pricing variables which may be selected by a bidder and assigning a seller-defined value to each of the possible responses. In this embodiment, the bidder can bid on the item by choosing responses from the possible responses defined by the seller and then a bid value is calculated based on the values of the pricing variables and the corresponding values of the responses chosen for the pricing variable. Finally, the bid values are ranked to determine the winning bid.
Brief Description of the Drawings Figure 1 is block diagram illustrating one network configuration that comprises a client computer and a server computer that are connected via a network.
Figure 2 is a block diagram illustrating one network configuration that comprises a web browser and a server computer that are connected via a network, such as the network of Figure 1, whereby the web server provides a bidding engine.
Figure 3 is a block diagram illustrating an embodiment of the interrelationships of three processes which calculate inputs for the bidding engine of Figure 2, namely the multi-variable valuation process, the multi-variable response valuation process, and the valuation matrix process. Figure 4 is a block diagram illustrating an embodiment of the multi-variable valuation process of Figure 3.
Figure 5 illustrates an example of a web page display of an embodiment of the multi-variable valuation process of Figure 3.
Figure 6 is a block diagram illustrating an embodiment of the multi-variable response valuation process of Figure 3. Figure 7 illustrates an example of a web page display of an embodiment of the multi-variable response valuation process of Figure 3.
Figure 8 is a block diagram illustrating an embodiment of the valuation matrix process of Figure 3. Figure 9 illustrates an example of a web page display generated by one embodiment of the invention whereby the valuation matrix process of Figure 8 has calculated a bid value for a particular bid.
Figure 10 is a block diagram illustrating the relationships between the various database tables used by valuation matrix process shown in Figure 3.
Detailed Description of Certain Embodiments
On embodiment of the invention is a system and method for implementing the sale of complex items, for example, complex financial instruments, with multiple pricing variables using a multi-variable auction format. Another embodiment of the invention comprises a multi-variable auction for auctioning financial instruments such as those related to private investments in public equities (commonly referred to as "PIPE" transactions). The invention can automatically analyze and rank the competitive bids and precisely determine which bid carries the maximum economic benefit to the seller of the complex items. Further, the invention extends to a system and method for implementing a multi-variable auction using a global computer network, such as the Internet. Specifically, one embodiment of the invention offers an exclusive online destination providing institutional and accredited investors a way to directly purchase, sell, and research PIPE securities.
Referring to Figure 1, an exemplary network configuration 100 will be described. A user 102 communicates with a computing environment which may include multiple server computers 108 or single server computer 110 in a client/server relationship on a computer network 116. In a client/server environment, each of the server computers
108, 110 includes a server program which communicates with a client computer 115. The server computers 108,
110, and the client computer 115 may each have any conventional general purpose single- or multi-chip microprocessor such as a Pentium'8 processor, a Pentium* Pro Processor, a 8051 Processor, a MIPS* Processor, a
Power PC* Processor, or an Alpha® Processor. In addition, the microprocessor may be any conventional special purpose microprocessor such as a digital signal processor or a graphics processor. Furthermore, the server computers
108, 110 and the client computer or computing device 115 may be desktop, server, portable, hand-held, set-top, wireless telephone or any other desired type of configuration. Furthermore, the server computers 108, 110 and the client computer 115 each may be used in connection with various operating systems such as: Unix, Linux, disk operating system (DOS), OS/2, Windows 3.X, Windows 95, Windows 98, and Windows NT. The server computers 108, 110, and the client computer 115 may each include a network terminal equipped with a visual display, keyboard (or keypad) and pointing device (or cursor control, such as arrow buttons). In one embodiment of network configuration 100, the client computer 115 includes a network browser 320 that is used to access the server computer 110. In one embodiment of the invention, the network browser 120 is the Internet
Explorer, licensed by Microsoft Inc. of Redmond, Washington. Other wireless applications may use a program using a wireless protocol, such as the Wireless Applications Protocol (WAP). The user 102 at the computer 115 may utilize the browser 120 to remotely access the server program using a keyboard and/or pointing device and a visual display, such as a monitor 118, liquid crystal displays, or the like. It is noted that although only one client computer 115 is shown in Figure 1, the network configuration 300 can include many client computers as may be associated with a global computer network. The network 116 may include any type of electronically connected group of computers including, for instance, the following networks: a virtual private network, a public Internet, a private Internet, a secure Internet, a private network, a public" network, a value-added network, an intranet, a packet switched network, a circuit switched network, a combination packet and circuit switched network, and the like. In addition, the connectivity to the network may be, for example, remote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink linterf ace (FDDI) or Asynchronous Transfer Mode (ATM). The network 116 may connect to the client computer 115, for example, by use of a modem, by use of a network interface card that resides in the client computer 115, or by wireless cellular protocols such as GSM or CDMA.
The server computers 108 may be connected via a wide area network 106 to a network gateway 104, which provides access to the wide area network 106 via a high-speed, dedicated data circuit. Devices, other than the hardware configurations described above, may be used to communicate with the server computers 108, 110. If the server computers 108, 110 are equipped with voice recognition or DTMF hardware, the user 102 can communicate with the server programs by use of a telephone 124. Other connection devices for communicating with the server computers 108, 110 include a portable personal computer 126 with a modem or wireless connection interface, a cable interface device 128 connected to a visual display 130, or a satellite dish 132 connected to a satellite receiver 134 and a television 136. In another embodiment, the user may connect to the network with a wireless handheld device such as those popularized by Motorola, Nokia, Sony, Ericcson, 3Com/Palm, and so forth. For convenience of description, each of the above hardware configurations are included within the definition of the client computer 115. The invention may be practiced with other ways of allowing communication between the user 102 and the server computers 108, 110, either available now or as may be developed in the future.
Further, it is noted the server computers 108, 110 and the client computer 115, may not necessarily be located in the same room, building or complex. In fact, the client computer 115 is generally remotely located from the server computers 108, 110.
Referring to Figure 2, the network configuration depicted in Figure 2 can be implemented to incorporate one configuration of this invention. A client computer having a web browser 210 can initiate an Hypertext Transport Protocol ("http") request 215 via the network 102. The http request 215 can be passed to a web server 220 which retrieves an associated program page 225. The program page 225 may be a Hypertext Markup Language (HTML) page, an extended HTML page with codes (e.g., ColdFusion codes), an Extended Markup Language (XML) page, a program or collection of programs (such as a Java or JavaScript protocol), a common gateway interface (CGI) protocol, and so on. A bidding engine 230 of the invention then processes the program page 225, and ultimately a web page 235 is transmitted to the client computer via the network 102. The bidding engine 230 may be configured to communicate with a web page engine 240 such as the ColdFusion server application. Such an application may be in data communication with a database server 245, a file system 250, and email server 255, various distributed objects 260, and other enterprise systems 265 or legacy systems. In other embodiments, the bidding engine 230 and web page engine 240 may be combined, subdivided, or partitioned in any number of ways.
In one embodiment, the bidding engine 230 can be created using a web auction development tool set, such as Virtual Auctioneer available from eyemedia, Inc. of Dallas, Texas. This tool set can use an RAD (rapid application development) middleware product in order to enable the query and manipulation of data from databases and to dynamically render the results as web pages. In one particular embodiment, ColdFusion Application Server v4.0 from Allaire is the middleware product. The minimum system requirements in one such configuration are Windows NT v4.0, ColdFusion application server v4.0, and Microsoft SQL server 7.0. The output from the bidding engine 230 may be subsequently processed by the web page engine 240 application, such as ColdFusion.
In one embodiment, the bidding engine 230 serves to generate the bid results based on the inputs of various processes of the invention. As depicted in Figure 3, the embodiment of this invention comprises three processes which calculate inputs for the bidding engine 230: (i) the multi-variable valuation process 320, (ii) the multi-variable response valuation process 340, and (iii) the valuation matrix process 360. Of course, when implemented in software or a system architecture, these processes may be combined or partitioned in a number of ways. For instance, they may all be included in the bidding engine 230. Each of these processes are depicted in Figures 4, 5, and 6, respectively. A seller 300 interested in offering an item for sale with a plurality of variables provides input to the multi-variable valuation process 320 and the multi-variable response valuation process 340. The valuation matrix process 360 uses the valuations generated by these two processes (namely the multi-variable valuation process 320 and the multi-variable response valuation process 340) and applies the bid 380 submitted by a bidder 390 to create an input for the bidding engine 230.
Figure 4 illustrates an embodiment of the multi-variable valuation process 320. In state 400, the seller 300 defines which transaction term variables will be available for bidding in the auction. The seller can select N variables, where N is a positive integer greater than zero. The selected variables are depicted in a variable table 410. Next, at state 420, the seller 300 assigns a variable value to each variable. The variables with assigned variable values are depicted in a selected variables table 430.
As an example, the variable value could be an integer between 10 and 50 and the seller 300 could assign higher variable values to those variables which the seller 300 considers more important in the auction. The selected variables may have the same variable value or they may all have different variable values. For example, if the seller is offering shares of preferred stock of a company for private placement, then the seller 300 may have selected the following variables with the following variable values:
Figure imgf000009_0001
TABLE 1
Figure 5 illustrates an example of a web page display generated by one embodiment of the invention whereby the seller 300 has assigned variable values to three transaction term variables. The web page display of one embodiment of the invention as depicted in Figure 5 allows the seller 300 to assign variable value in box 50 for a transaction term listed in heading 52. In the text body 54, the web page display can list transaction term variables previously entered by the seller 300 with previously assigned variable values listed as well. If the seller 300 has also defined potential responses for the transaction term variable listed in heading 52, the potential response weights for those defined potential responses, and the sorting order for the defined potential responses (e.g., the order in which the potential responses will be displayed), then these definitions can be listed in response section 56.
Figure 6 depicts an embodiment of the multi-variable response valuation process 340. In state 500, the seller 300 selects a potential response for each of the N variables. A potential response table 510 illustrates as an example, the potential responses selected for variable 1 and variable 2. In one embodiment, the number of potential responses chosen by the seller 300 must be less than the variable value assigned to that variable by the seller 300 in state 420. This may be desirable for normalizing the results. For example, as the potential response table 510 illustrates, the seller can select xH potential responses for each selected variable, where xN is a positive integer greater than zero but less than the variable value assigned to variable N. For example, in the potential response table 510, the seller 300 has selected x, potential responses for variable 1 and x2 potential responses for variable 2. Each selected variable may have more than, less than, or an equal number or potential responses as the other selected variables (e.g., x, can be greater than x2, x. can be less than x2, or x, can equal x2). However, x, cannot be greater than the variable value assigned to variable 1 and x2 cannot be greater than the variable value assigned to variable 2. For instance, in table 1, for the cash dividend, N=2 and x2 20. Next, in state 520, the seller 300 assigns a potential response weight to each potential response. A potential response weight table 530 illustrates an assignment by the seller 300 of potential response weights to the x, potential responses selected for variable 1 and the x2 potential responses selected for variable 2. As with the variable values for the selected variables, the seller 300 can assign a higher potential response weight to those potential responses which the seller 300 considers more important in the auction. The selected variables may have the same potential response weight or they can have different potential response weights. In one embodiment, the potential response weights assigned to each potential response are calculated based on the number of potential responses available and the number of potential response weights available for assignment. For example, the potential response weight can be calculated so that the marginal difference between each potential response weight for a particular response is equal or nearly so (i.e., a linear response function). For example, if the seller selects xN potential responses for transaction term variable N and then decides the potential response weight range to be an integer value between 1 and PRW (such as a value between 1 and 10, where PRW = 10), then the "step" between each potential response weight can be calculated according to the following formula:
PRW -1 step = xN -l
For example, if the seller 300 is offering shares of preferred stock of a company for private placement with four transaction term variables, and there are four potential responses for transaction term variable 2 (for example, 5%, 6%, 7%, and 8% for the cash dividend rate of the preferred stock), then the "step" between each potential response weight can be calculated according to the following formula:
Number of transaction term variables: 4 Number of potential responses for transaction term 2 (x2): 4
Potential response weight range: 1 to 10
x2 = 4
PRW = 10
PRW-1 10-1 9 . step = = = — = 3 x, -1 4-1 3
Therefore, the potential response weight assigned to each potential response for variable 2 could be:
Variable Potential Response Potential Response Weight
Cash dividend rate of 5% 10 preferred stock _„, 7
7% 4
8% 1 Of course, often the calculation of potential response weights may not result in integer values and so, in order to account for the more precise variances, the potential value range can be increased from 1 to 10, to 1 to 100, or 1 to 1,000, for example.
Randomly chosen potential response weights can have asymmetrical steps up or down in value and consequently, the potential response weight can skew the significance of a variable value. However, by calculating the potential responses values with a mathematical formula as illustrated as an example above, the "steps" between each potential responses value are equal or nearly so and consequently the seller 300 can prevent the potential response variable value from determining the significance of the bid. Of course, a non-linear function could be used for step to obtain a desired objective, e.g., exponential, impulse, sigmoidal, etc.
An example of this calculation and the assignment of potential response weights is depicted in Table 2 below. Following the example previously given above, if the seller 300 is offering shares of preferred stock of a company for private placement, then the seller 300 may have selected the following variables with the following potential responses having the following potential response weights:
Figure imgf000011_0001
Figure imgf000012_0001
TABLE 2
Figure 7 illustrates an example of a web page display generated by one embodiment of the invention whereby the seller 300 has assigned potential response weights to selected potential responses. The web page display of one embodiment of the invention as depicted in Figure 7 allows the seller 300 to define a potential response for a particular transaction term variable listed in heading 70 and then assign potential response weights for each defined potential response. The seller 300 can define a potential response by entering data in response blocks 72. Next, the seller 300 can assign a response weight to each response by entering numerical data in weight blocks 74. Moreover, in sorting blocks 76, the seller 300 can define how the potential response and potential response weights will be sorted (e.g., the order in which the potential responses will be displayed). The variable value and the sort order (e.g., the order in which the variable value will be displayed) previously defined for the transaction term variable listed in heading 70 can be listed in row 78. Figure 8 illustrates an embodiment of the valuation matrix process 360. In state 600, the bidder 390 selects a potential response for each of the selected variables chosen by the seller 300 for the time offered for sale. After selecting a potential response for each selected variable, the bidder 390 submits his or her bid 380 to the valuation matrix process 360 at state 610. The valuation matrix process 360 determines the overall value of the bid 380 by calculating a bid value at state 620. In one embodiment, the valuation matrix process 360 calculates the bid value by multiplying each of the variable values by the potential response weights corresponding to the potential responses for the selected variable. The products of the variable values and the potential response weights are added together to create bid value, as represented in the following equation: l, x SPRW, V2 x SPRW2
BVI = 4Vi χ SPRWi V3 x SRRW3 i=ϊ or
VN x SPRWN
Bid value
Equation 1 where: V = variable value SPRW = selected potential response weight
Continuing with the example from above, if the bidder 390 chooses 5 years for the term of preferred stock, 6% for the cash dividend rate, 3 months for the time period for preferred stock to be convertible at fixed conversion price, and 106% for the fixed conversion price as a percentage of average closing bid price, then the bid value could be calculated as:
Variable Potential Potential
Variable Value Response Response Weiqht VV. SPRW,
Term of preferred stock 10 5 1000 10,000
Cash dividend rate of preferred 20 6% 700 14,000 stock
Time period for preferred stock 20 3 months 550 11,000 to be convertible at fixed conversion price
Fixed conversion price as a 50 106% 486 24,300 percentage of average closing bid price
Bid value: 59,300
This is but one equation for one embodiment of the invention. However, other equations can be used to calculate a bid value. As an example, rather than add the products of the variable values and the selected response values to create a bid value as illustrated above, the bid value could also be calculated as the sum of the each value variable divided by the selected response value (or alternatively, the sum of the each selected potential response weight divided by the corresponding variable values). As another example, the bid value could be calculated as the sum of all the values (namely, the sum of all the variable values and the selected potential response weights). These alternative mathematical formulations of the bid value are illustrated below: (V, SPRW,) (V, + SPRW,) (V2 SPRW2) (V2 + SPRW2)
(V3 SPRW3) (V3 + SPRW3)
(VN + SPRWN
(VN ÷ SPRWN)
Bid value
Bid value
Equation 2 Equation 3
Additionally, the bid value can be calculated based on the discounted cash flows generated from the actual terms chosen by the bidder 390 based on the potential response weights selected by the bidder 390 (for a general discussion of calculating the value of discounted cash flows, see Brealey, Richard A. and Myers, Stewart C, Principles of Corporate Finance, 4th ed., McGraw Hill, 1991). In a further embodiment, the bid value can also be calculated based on geometric or other non-linear relationships between the various values. For example, a natural logarithm could be applied to individual weighted values to compress the range of results. Furthermore, values and weights do not have to be limited to integer numbers or subject to the ranges identified here.
Additionally, in one embodiment, the seller 300 can assign a default potential response for each selected variable. In this embodiment, the seller 300 can set a default (or a minimum or a reserve) bid value. That is, if a default bid value is set by the seller 300, then the seller is only obligated to accept bids that equal or exceed its default bid value.
Referring again to Figure 8, once the bid value for a bid has been determined by the valuation matrix process 360, each bid is put in a rank ordered list by the bidding engine 230 in state 630. The bidding engine 230 can assess which bids have a higher bid value and rank those bids accordingly. If there are multiple units being sold in the auction, the bidding engine 230 can determine how many units will be allocated to a specific bid based on the ranking of that bid at the time the bid is submitted. If a default bid value has been selected by the seller 300, the bidding engine 230 can determine whether bids equal and/or exceed the default bid value. In state 640, the seller 300 can select the winning bid from the rank ordered list. Figure 9 illustrates an example of a web page display generated by one embodiment of the invention whereby the valuation matrix process 360 has calculated a bid value for a particular bid and allows the bidder 390 to confirm and submit his or her bid. The web page display of one embodiment of the invention as depicted in Figure 9 can display a summary of information about the bid 380 of a particular bidder 390 in a bid ranking box 90. This information can include, for example, the bid value calculated for that bid, the ranking of that bid value index among the other previously submitted bids, and the date that bid was submitted. Additionally, the bid ranking box 90 can display any previously submitted bids by that particular bidder 390. In the bid confirmation box 92, the details of the bid can be displayed, such as the selected response for each transaction term variable and the total bid amount. The bidder 390 can review this information and either confirm and submit the bid by activating a submit button 94 or edit the bid 380 by activating a change button 96. In one embodiment, the bidding engine 230 may rely on a database accessed through the web page engine
240. Data entered by sellers and bidders are recorded in numerous tables stored in the database server 245. The relationships between some of the database tables in one particular embodiment is illustrated in Figure 7 as an example. Moreover, a user with programming knowledge can also configure the invention to update data stored in a legacy system.
At the center of the relationships is the Products database table 700 holding the general product information depicted in Figure 10. For example, the Products database table 700 can hold data such as asking price, starting price, and quantity on hand. The Products database table 700 holds data from numerous other tables. For example, the Products database table 700 holds the identity of the seller 300 and so is linked to the Seller database table 710 storing various details about the seller 300. The Products database table 700 also holds the bidder identification and so is also linked to the Bids database table 720 and the Bidders database table 730. These database tables store data regarding the history of bids on listed items and detailed data of the bidder 390, respectively.
The transaction term variables as selected by the seller 300 can be stored in the Variables database table 740. Potential responses to each transaction term variable can be stored in Potential Responses database table 750. Both the Variables database table 740 and the Potential Responses database table 750 can be linked to the Products database table 700. The potential responses selected by the bidder 390 can be stored in the Selected Potential Responses database table 760. The Potential Responses database table 760 can be linked to both the Bidders database table 730 and the Products database table 700.
In one embodiment, the Products database table 700 can include fields such as ProductlD, ProductTypelD, CategorylD, ProductName, ShortDescription, LongDescription, DateCreated, and Status. The ProductName, ShortDescription, and LongDescription fields can store textual data concerning the name of the product given by the seller 300 and a short and long description of the product given by the seller 300. The seller 300 can also identify the category, which can delineate in which market the seller 300 wants to sell his or her product(s), such as the primary market and the secondary market. This data can be stored as textual or numerical identifiers in the CategorylD field. Furthermore, seller 300 can also identify the product type (such as a common stock, preferred stock, bond, etc.) of the product, and this data can be stored as textual or numerical identifiers in the ProductTypelD field. Additionally, each product offered for sale by the seller 300 can be given a unique identifier. In a further embodiment, this identifier can be automatically generated by the bidding engine 230. This identifier can be stored in the ProductlD field.
The Seller database table 710 can include data fields regarding the seller 300. For example, the Seller database table 710 can store data in fields such as SellerlD, SellerName, SellerUserName, and SellerPassword. The seller 300 can enter his or her name and this textual data can be stored in the field SellerName. Moreover, the seller 300 can be prompted to select a user name and password, which, when entered in combination, can be used to provide selective access to the invention by the seller 300. This data can be either textual or numerical in form and can be stored in fields SellerUserName, and SellerPassword. The Bidders database table 730 can store data in a number of fields. For example, fields such a BidderlD, UserName, Password, FirstName, LastName, Address, City, StatelD, Zip, Phone, Email, DateCreated, and Active. Contact information for a bidder 390, such as his or her first and last name, address, city, state, zip, telephone number, and email address can be stored in fields FirstName, LastName, Address, City, StatelD, Zip, Phone, and Email, respectively. Additionally, the bidder 390 can be prompted to select a user name and password, which, when entered in combination, can be used to provide selective access to the invention by the bidder 390. This data can be either textual or numerical in form and can be stored in fields UserName, and Password. Moreover, the Bidders database table 730 can keep track of when bidders enter the web site by storing the date their account was created in a DateCreated field. The Bids database table 720 can hold data in various fields such as BidlD, ProductlD, BidderlD, Amount, and
Quantity. The ProductlD and BidderlD field data can be provided by the Products database table 700 and the Bidders database table 730, respectively. The amount of the bid 380 made by the bidder (for example, in U.S. dollars) can be stored in the Amount field. The number of products on which the bidder 390 is making a bid 380 can be stored in the Quantity field. Also, each bid 380 made by a bidder 390 can be given a unique identifier. In a further embodiment, This identifier can be automatically generated by the bidding engine 230. This identifier can be stored in the BidlD field.
The Variables database table 740 can store the textual and numerical data relating to the various pricing variables associated with each product. As examples, the following fields can be stored in the Variables database table 740: QuestionlD, ProductlD, Question, and VariableValue. The ProductlD field data can be provided by the Products database table 700. The text of a question prompting a bidder 390 to select a potential repsonse to a pricing variable can be stored in the Question field and the QuestionlD field can store a unique identifier to that question. The variable value assigned by the seller 300 to the transaction term variable associated with the question can be stored in the VariableValue field. The Potential Reponses database table 750 can then store the potential responses to the questions associated with each transaction term variable and stored in the Variable database table. The Potential Responses database table 750 can include, for example, fields such as QuestionlD (provided by the Variables database table 740), BidderlD (provided by the Bidders database table 730), ProudctlD (provided by the Products database table 700), PotentialResponselD, PotentialResponse, and PotentialResponseWeight. The potential responses available to the bidder 390 can be stored as textual and/or numerical data in the PotentialResponse field and the PotentialResponselD field can store a unique identifier to that potential response. The potential response weight assigned by the seller 390 to that particular potential response can be stored in the Potential response database table 750 as well in the PotentialResponseWeight field.
When the bidder 390 has selected various potential responses for each question associated with a transaction term variable, these selected potential responses can be stored in the Selected Potential Responses database table 760. Fields such as PotentialResponselD, PotentialResponse, PotentialResponseWeight, ProductlD, Question, VariableValue, BidderlD, and SeiectedPotentialResponse can be stored in the Selected Potential Responses database table 760. The PotentialResponselD, PotentialResponse, and PotentialResponseWeight fields can be supplied by the Potential Responses database table 750 and the ProductlD, Question and VariableValue, and BidderlD fields can be provided by the Products database table 700, the Variables database table 740, and the Bidders database table 730. The textual or numerical data of the potential response selected by the bidder 390 for a particular question on a pricing variable can be stored in the SeiectedPotentialResponse field. This is but one of many data sche as that could be used to implement the principles of the present invention. Furthermore, standard commercial database management programs available from companies such as Oracle, Informix, Sybase, and Microsoft could be used to implement the database.
While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the spirit of the invention.

Claims

WHAT IS CLAIMED IS:
1. An auction system, wherein each of a plurality of bidders make a bid on an item having a plurality of pricing variables, the auction system comprising: a multi-variable valuation process configured to assign a seller-defined value to each of the pricing variables associated with the item for auction; a multi-variable response valuation process configured to assign a seller-defined value to a plurality of responses available to the bidders; a valuation matrix process configured to calculate a bid value for each bid made by the bidders, wherein the bid value represents the responses selected by the bidders based on the pricing variable values and the response values; and a ranking process configured to rank order the bid values associated with each bid made by the bidders.
2. The auction system of Claim 1, wherein the auction system is implemented on a global computer network.
3. The auction system of Claim 1, wherein the valuation matrix process calculates the bid values by summing the multiplicative products of each of the seller-defined values assigned to each of the pricing variables and each of the seller-defined values assigned to each of the responses.
4. The auction system of Claim 1, wherein the valuation matrix process calculates the bid values by summing the quotients of each of the seller-defined values assigned to each of the pricing variables and each of the seller-defined values assigned to each of the responses.
5. The auction system of Claim 1, wherein the valuation matrix process calculates the bid values by summing the each of the seller-defined values assigned with each of the pricing variables and each of the seller- defined values assigned to each of the responses.
6. The auction system of Claim 1, wherein the valuation matrix process calculates the bid values based on a non-linear relationship between the seller-defined values assigned to each of the pricing variables and the seller-defined values assigned to each of the responses.
7. The auction system of Claim 1, wherein the bid item is a financial instrument.
8. The auction system of Claim 1, wherein the bid item is a financial instrument associated with a private investment in a public equity transaction.
9. The auction system of Claim 1, wherein the bid item is a loan from a financial institution.
10. The auction system of Claim 1 , wherein the bid item is a service contract.
11. The auction system of Claim 1 , wherein the bid item is a consumer durable.
12. An auction method, comprising: assigning a seller-defined value to each of a plurality of pricing variables associated with an item for sale; defining a plurality of possible responses for each of the pricing variables which may be selected by a bidder for the item; and assigning a seller-defined value to each of the possible responses.
13. The auction method of Claim 12, further comprising: offering the item for sale on a computer network; selecting the pricing variables associated with the item for sale; selecting responses from the plurality of possible responses for each of the pricing variables associated with the item; calculating a bid value based on the seller-defined values of the selected pricing variables and the corresponding values of the selected responses; and rank ordering the bid value of each bid made by the bidders.
14. The auction method of Claim 12, wherein the computer network comprises a global computer network.
15. The auction method of Claim 12, wherein the calculating the bid value comprises summing the multiplicative products of each of the seller-defined values assigned to each of the pricing variables and each of the seller-defined values assigned to each of the responses.
16. The auction method of Claim 12, wherein the calculating the bid value comprises summing the quotients of each of the seller-defined values assigned to each of the pricing variables and each of the seller-defined values assigned to each of the responses.
17. The auction method of Claim 12, wherein the calculating the bid value comprises summing each of the seller-defined values assigned with each of the pricing variables and each of the seller-defined values assigned to each of the responses.
18. The auction method of Claim 12, wherein the calculating the bid value is based on a non-linear relationship between the seller-defined values assigned to each of the pricing variables and the seller-defined values assigned to each of the responses.
19. The auction method of Claim 12, wherein the item for sale comprises a financial instrument.
20. The auction method of Claim 12, wherein the item for sale comprises a financial instrument associated with a private investment in a public equity transaction.
21. The auction method of Claim 12, wherein the item for sale comprises a loan from a financial institution.
22. The auction method of Claim 12, wherein the item for sale comprises a service contract.
23. The auction method of Claim 12, wherein the item for sale comprises a consumer durable.
24. An auction system for multi-variable items, comprising: a multi-variable auction database stored in a data storage device and being configured to store a plurality of variable values and a plurality of possible response values associated with each item; and a multi-variable auction program executing on a computer, wherein the program is configured to manipulate the multi-variable auction database and to allow selective access to a plurality of bidders.
25. An auction system for auctioning a financial instrument to a plurality of selected bidders, the online auction system comprising: a multi-variable valuation process configured to assign a seller-defined value to each of a plurality of transaction term variables associated with the financial instrument for sale; a multi-variable response valuation process configured to assign a seller-defined value to a plurality of responses available to the selected bidders; a valuation matrix process configured to calculate a bid value for each bid made by the selected bidders, wherein the bid value represents the responses selected by the selected bidders based on the transaction term variable values and the response values; and a ranking process configured to rank order the bid values associated with each bid made by the selected bidders.
26. The auction system of Claim 25, wherein the auction system is implemented on a global computer network.
27. The auction system of Claim 25, wherein the valuation matrix process calculates the bid values by summing the multiplicative products of each of the seller-defined values assigned to each of the transaction term variables and each of the seller-defined values assigned to each of the responses.
28. The auction system of Claim 25, wherein the valuation matrix process calculates the bid values by summing the quotients of each of the seller-defined values assigned to each of the transaction term variables and each of the seller-defined values assigned to each of the responses.
29. The auction system of Claim 25, wherein the valuation matrix process calculates the bid values by summing each of the seller-defined values assigned to each of the transaction term variables and each of the seller- defined values assigned to each of the responses.
30. The auction system of Claim 25, wherein the valuation matrix process calculates the bid values based on a non-linear relationship between the seller-defined values assigned to each of the transaction term variables and the seller-defined values assigned to each of the responses.
31. The auction system of Claim 25, wherein the valuation matrix process calculates the bid values based on a discounted cash flow analysis of the financial instrument based on the selected responses.
32. An auction method for auctioning a financial instrument to a plurality of selected bidders, the online auction method comprising: assigning a seller-defined value to each of a plurality of transaction term variables associated with the financial instrument for auction; defining a plurality of possible responses for each transaction term variable which may be selected by a bidder for the financial instrument; and assigning a seller-defined value to each of the possible responses.
33. The auction method of Claim 32, further comprising: offering the financial instrument for sale to a plurality of selected bidders; selecting the transaction term variables associated with the financial instrument for sale; selecting responses from the possible responses for each of the transaction term variables associated with the item; calculating a bid value based on the seller-defined values assigned to the selected transaction term variables and the corresponding values of the selected responses; and rank ordering the bid value of each bid made by the selected bidders.
34. The auction method of Claim 32, wherein the auction method is implemented on a global computer network.
35. The auction method of Claim 33, wherein calculating the bid value comprises summing the multiplicative products of each of the seller-defined values assigned to each of the transaction term variables and each of the seller-defined values assigned to each of the responses.
36. The auction method of Claim 33, wherein calculating the bid value comprises summing the quotients of each of the seller-defined values assigned to each of the transaction term variables and each of the seller- defined values assigned to each of the responses.
37. The auction method of Claim 33, wherein calculating the bid value comprises summing the each of the seller-defined values assigned with each of the transaction term variables and each of the seller-defined values assigned to each of the responses.
38. The auction method of Claim 33, wherein calculating the bid value is based on a geometric relationship between the seller-defined values assigned to each of the transaction term variables and the seller-defined values assigned to each of the responses.
39. The auction method of Claim 33, wherein calculating the bid value is based on a discounted cash flow analysis of the financial instrument based on the selected responses.
40. An auction system for auctioning a financial instrument to a plurality of bidders, the online auction system comprising: a multi-variable auction database stored in a data storage device and being configured to store a plurality of variable values and a plurality of possible response values associated with each financial instrument; and a multi-variable auction program executing on a computer, wherein the program is configured to manipulate the multi-variable auction database and to allow selective access to the plurality of bidders.
41. The auction system of Claim 25, wherein the online auction system implements private investments in public equities by a plurality of selected bidders.
42. The auction method of Claim 32, wherein the online auction method implements private investments in public equities by a plurality of selected bidders.
43. The auction system of Claim 40, wherein the online auction system implements private investments in public equities by a plurality of selected bidders.
44. The auction system of Claim 25, wherein the financial instrument is associated with the high yield debt market.
45. The auction system of Claim 25, wherein the financial instrument is associated with the convertible debt market.
46. The auction system of Claim 25, wherein the financial instrument is associated with the foreign private placement market.
47. The auction method of Claim 32, wherein the financial instrument is associated with the high yield debt market.
48. The auction method of Claim 32, wherein the financial instrument is associated with the convertible debt market.
49. The auction method of Claim 32, wherein the financial instrument is associated with the foreign private placement market.
50. The auction system of Claim 40, wherein the financial instrument is associated with the high yield debt market.
51. The auction system of Claim 40, wherein the financial instrument is associated with the convertible debt market.
52. The auction system of Claim 40, wherein the financial instrument is associated with the foreign private placement market.
53. The auction system of Claim 25, further comprising a primary market wherein the financial instrument is auctioned directly to the plurality of selected bidders.
54. The auction system of Claim 25, further comprising a secondary market wherein the financial instrument is a previously issued financial instrument and auctioned to the plurality of selected bidders.
55. The auction method of Claim 33, wherein offering the financial instrument for sale comprises auctioning the financial instrument directly to the plurality of selected bidders on a primary market.
56. The auction method of Claim 33, wherein offering the financial instrument for sale comprises auctioning a previously issued financial instrument to the plurality of selected bidders on a secondary market.
57. An auction system, comprising: a plurality of investors selected by a seller of a financial instrument; a financial instrument offered for sale by the seller to the plurality of selected investors; a multi-variable selection process wherein the plurality of investors make a bid on the financial instrument by selecting a value for each of a plurality of transaction term variables associated with the financial instrument; and a multi-variable valuation process configured to determine the bid value for each bid made by the plurality of investors based on the seller-defined values assigned to a plurality of transaction term variables associated with the financial instrument.
58. The auction system of Claim 33, wherein the auction system is implemented on a global computer network.
59. The auction system of Claim 33, wherein the online auction system implements private investments in public equities by a plurality of selected bidders.
60. The auction system of Claim 33, wherein the financial instrument is associated with the high yield debt market.
61. The auction system of Claim 33, wherein the financial instrument is associated with the convertible debt market.
62. The auction system of Claim 33, wherein the financial instrument is associated with the foreign private placement market.
63. An auction method for selling a financial instrument, the auction method comprising: offering the financial instrument for sale over a global computer network; bidding on the financial instrument by selecting a value for each of a plurality of transaction term variables associated with the financial instrument; and determining the bid value for each bid based on the seller-defined values assigned to a plurality of transaction term variables associated with the financial instrument.
64. The auction method of Claim 63, wherein access to the auction method is limited to a plurality of selected users of the global computer network.
65. The auction method of Claim 63, wherein the auction method implements private investments in public equities by a plurality of selected bidders.
66. The auction method of Claim 63, wherein the financial instrument is associated with the high yield debt market.
67. The auction method of Claim 63, wherein the financial instrument is associated with the convertible debt market.
68. The auction method of Claim 63, wherein the financial instrument is associated with the foreign private placement market.
69. The auction system of Claim 26, wherein access to the auction system is limited to a plurality of selected users of the global computer network.
70. The auction method of Claim 34, wherein access to the auction method is limited to a plurality of selected users of the global computer network.
71. The auction system of Claim 40, wherein, wherein the auction system is implemented on a global computer network.
72. The auction method of Claim 71, wherein access to the auction system is limited to a plurality of selected users of the global computer network.
PCT/US2001/010568 2000-03-31 2001-03-30 System and method for multi-variable auctions WO2001075740A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001251219A AU2001251219A1 (en) 2000-03-31 2001-03-30 System and method for multi-variable auctions

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US54092300A 2000-03-31 2000-03-31
US53985300A 2000-03-31 2000-03-31
US09/540,923 2000-03-31
US09/539,853 2000-03-31

Publications (1)

Publication Number Publication Date
WO2001075740A2 true WO2001075740A2 (en) 2001-10-11

Family

ID=27066238

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/010568 WO2001075740A2 (en) 2000-03-31 2001-03-30 System and method for multi-variable auctions

Country Status (2)

Country Link
AU (1) AU2001251219A1 (en)
WO (1) WO2001075740A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2366885A (en) * 2000-04-07 2002-03-20 Ibm Multi-attribute auction
GB2444085A (en) * 2006-11-24 2008-05-28 Bluesuite Ltd Auctioning similar items
US7809611B2 (en) 2006-11-24 2010-10-05 Mediaequals Ltd Multi-stage automated auctions

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2366885A (en) * 2000-04-07 2002-03-20 Ibm Multi-attribute auction
US7200570B1 (en) 2000-04-07 2007-04-03 International Business Machines Corporation Multi-attribute auction methodology and system
GB2444085A (en) * 2006-11-24 2008-05-28 Bluesuite Ltd Auctioning similar items
US7809611B2 (en) 2006-11-24 2010-10-05 Mediaequals Ltd Multi-stage automated auctions

Also Published As

Publication number Publication date
AU2001251219A1 (en) 2001-10-15

Similar Documents

Publication Publication Date Title
US7574395B2 (en) Price improvement in an active trading market
US7529708B2 (en) System and method for determining latent demand for at least one of a plurality of commodities
US20020095369A1 (en) Anonymous auctioning of structured financial products over a computer network
EP1081614A2 (en) Dynamic order visibility system for the trading of assets
EP1246112A1 (en) Request for quote (RFQ) and inside markets
US8463690B2 (en) Systems and methods for vending and acquiring order priority
US20020013760A1 (en) System and method for implementing electronic markets
US20070043647A1 (en) Electronic trading environment with price improvement
US20010049651A1 (en) Global trading system and method
US20070112693A1 (en) Method and system for obtaining a discovered price
KR20020027511A (en) Systems and methods for linking orders in electronic trading systems
US20050216393A1 (en) Systems and methods for allowing market-maker participation in transactions
US6952219B2 (en) System and method for color-coding objects having multiple attributes
US7149717B1 (en) Method and system to effectuate multiple transaction prices for a commodity
JP2004537769A (en) Method of displaying the market depth of a product traded in a market and a graphical user interface therefor, and method of placing a trade order for a product and a client system therefor
WO2009114511A2 (en) System and method for specified pool trading
JPH11504455A (en) Negotiating Network Using Satisfaction Density Profile
EP1405234A2 (en) System and method for an auction of multiple types of items
US20090048962A1 (en) Interactive Security Brokerage System
WO2001071968A9 (en) Subscription auction and sale system
WO2001075548A9 (en) System and method for implementing electronic markets
Klaue et al. Automated negotiation on agent-based e-marketplaces: an overview
US10529019B2 (en) Trading platform with automated negotiation and option crossing
WO2001031537A9 (en) System and method for adaptive trade specification and match-making optimization
US20070073594A1 (en) E-commerce infrastructure and transaction system to commoditize unutilized, and underutilized assets & resources and excess capacity, via sharing or bartering arrangements transacted throught the econoshare system invention

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ CZ DE DE DK DK DM DZ EE EE ES FI 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 PL PT RO RU SD SE SG SI SK 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 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 GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
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

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP