WO2001041084A2 - Automated event ticket auctioning system - Google Patents

Automated event ticket auctioning system Download PDF

Info

Publication number
WO2001041084A2
WO2001041084A2 PCT/US2000/042431 US0042431W WO0141084A2 WO 2001041084 A2 WO2001041084 A2 WO 2001041084A2 US 0042431 W US0042431 W US 0042431W WO 0141084 A2 WO0141084 A2 WO 0141084A2
Authority
WO
WIPO (PCT)
Prior art keywords
commodity
providing
market information
quote
market
Prior art date
Application number
PCT/US2000/042431
Other languages
French (fr)
Other versions
WO2001041084A3 (en
Inventor
Arthur Roland Bushonville
Norbert Peter Schenk
Mark Rosenfeld
Adam Christopher Swift
Original Assignee
Ultimate Markets, 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 Ultimate Markets, Inc. filed Critical Ultimate Markets, Inc.
Priority to AU43074/01A priority Critical patent/AU4307401A/en
Publication of WO2001041084A2 publication Critical patent/WO2001041084A2/en
Publication of WO2001041084A3 publication Critical patent/WO2001041084A3/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
    • 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
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events

Definitions

  • the present invention relates generally to trading systems and, in particular, to a method and apparatus for use in implementing trades and establishing markets in a commodity exchange system.
  • on-line auction sites such as that provided by eBay, Inc.
  • eBay, Inc. Such auctions are examples of seller-driven systems in which the seller defines contract terms but does not necessarily define a price for the goods to be sold.
  • Another type of auction site is that provided by priceline.com, Inc. in which buyers are allowed to state the terms under which they are willing to complete a purchase.
  • ticket brokers Another type of e-commerce site has also been developed, particularly directed to the buying and selling of event tickets.
  • these sites extend the services of so-called "ticket brokers".
  • these systems function essentially like electronic bulletin boards. That is, sellers of tickets (i.e., the ticket brokers) are able to post their offers and state the particular terms under which they would be willing to complete a transaction for event tickets.
  • bid information i.e., the ticket brokers
  • these systems do not incorporate bid information by potential buyers, they are unlike true commodity markets. That is, these systems generally do not provide a method for potential buyers to submit bids for tickets, nor do they make such bid and offer information generally available thereby allowing market forces to determine prices.
  • no attempt is made to match offers and bids in these on-line systems. Because such bid information is neither accepted nor provided, ticket broker e-commerce sites do not function as true markets.
  • the present invention provides a technique for implementing trades and establishing markets in a commodity exchange system.
  • the commodity exchange system of the present invention is directed to the treatment of seats (more specifically, the tickets for those seats) within event venues as commodities.
  • market information for at least one seat in an event venue is provided to users of the exchange system.
  • the number of seats being traded differentiates markets for a particular event within a particular event venue.
  • users may submit quote proposals (e.g., bid or offers) or quote acceptances.
  • quote proposals e.g., bid or offers
  • quote acceptances e.g., bid or offers
  • Various data structures and display formats are provided to promote market participation and efficiency.
  • the present invention is implemented within a publicly available network, such as the Internet or World Wide Web. In this manner, the present invention provides an improved exchange system.
  • FIG. 1 is a block diagram of a computer system in accordance with the present invention.
  • FIG. 2 is a block diagram of a preferred embodiment of an exchange controller in accordance with the present invention.
  • FIG. 3 is a block diagram illustrating an exchange process in accordance with the present invention.
  • FIG. 4 illustrates an exemplary visual depiction in accordance with the present invention.
  • FIG. 5 illustrates a preferred embodiment of a first data structure in accordance with the present invention.
  • FIG. 6 illustrates a preferred embodiment of a second data structure in accordance with the present invention.
  • FIG. 7 illustrates a preferred embodiment of a third data structure in accordance with the present invention.
  • FIG. 8 illustrates a preferred embodiment of a fourth data structure in accordance with the present invention.
  • FIG. 9 illustrates a preferred embodiment of a fifth data structure in accordance with the present invention.
  • FIG. 10 illustrates a market information display format for particular use in obtaining offers in accordance with the present invention.
  • FIG. 11 illustrates a market information display format for particular use in obtaining bids in accordance with the present invention.
  • FIG. 12 illustrates a market information display format for particular use in providing a more complete market display in accordance with the present invention.
  • FIG. 13 illustrates a market information display format for particular use in providing a detailed market display in accordance with the present invention.
  • FIG. 14 illustrates a market information display format for particular use in providing a market summary in accordance with the present invention.
  • FIG. 1 illustrates a computer system 100 comprising a plurality of computers 102 m communication with each other through a communication network 104.
  • An exchange controller 106 coupled to the communication network 104, is capable of communicating with the computers 102.
  • the communication network 104 comprises a publicly available computer network, such as the Internet or World Wide Web
  • the network 104 may comp ⁇ se or include a p ⁇ vate computer network
  • Each of the computers 102 is preferably a personal computer, typically for use in the home or office.
  • each computer 102 should support a common communication protocol with the exchange controller 106, preferably the so-called TCP/IP suite of protocols used to support Internet and "ETHERNET" communications
  • TCP/IP suite of protocols used to support Internet and "ETHERNET" communications
  • other communication protocols could be equally used dependent, in part, upon the type of communication network 104 employed
  • the exchange controller 106 serves to implement an on-line commodities exchange in accordance with the present invention and will be described in further detail with reference to FIGS 2 and 3 Generally, the exchange controller 106 functions to automate interface operations with potential buyers and sellers of a given commodity, to implement exchange functionality (e.g , display market information, identify potential trades, etc ) and to support settlement activities To this end, the exchange controller 106 is in communication with one or more financial institutions 108 capable of ve ⁇ fymg customer credit availability and limits, issuing payments, holding funds while awaiting transaction clearance and the like The exchange controller 106 is also in communication with an exchange office 110 The exchange office 110 includes personnel required to maintain operation of the exchange controller 1 10, field customer inquiries where necessary, ensure order settlement and to generally administer operations of the exchange In one embodiment of the present invention, the exchange office 110 communicates with a earner 1 12 in order to facilitate settlement of completed transactions.
  • exchange office 110 includes personnel required to maintain operation of the exchange controller 1 10, field customer inquiries where necessary, ensure order settlement and to generally administer operations of the exchange
  • the exchange office 110
  • the exchange office 110 receives information regarding completed transactions (transactions in which a buyer agreed to a seller' s offering p ⁇ ce or in which a seller agreed to a buyer's bid p ⁇ ce) from the exchange controller 106 and forwards any information necessary for a earner 112, if required, to perform delivery of the desired goods. It is anticipated that communications between the exchange controller 106 and the carrier 112 can also be performed directly (as illustrated by the dotted link) such that the necessary information is forwarded directly to the carrier 112 once a transaction has been completed.
  • the exchange controller comprises at least two servers 202, 204, such as "SUN” "ENTERPRISE” 250 servers, operating in combination to provide an on-line exchange system. It is understood that the present invention need not be limited to an on-line implementation, and is susceptible to other implementations. For example, communications between individuals and the exchange controller 106 could be carried out using telephone, facsimile, postal mail or other off-line methods of communication. It is further understood that other implementations (including various hardware implementations) encompassing the same functionality as described herein will be readily apparent to those having ordinary skill in the art.
  • a first server 202 communicates via a database interface 214 with a second server configured to operate as a database 204.
  • a database 204 stores all relevant information necessary to complete commodities transactions, such as buyer and seller identifications, account identifications, passwords, information regarding specific quotes (bids and/or offers), credit information, etc.
  • the first server 202 implements the exchange functionality 206.
  • the exchange functionality 206 encompasses an exchange process 208, a web server 210 and a secure server 212.
  • the first server 202 comprises one or more processing units (such as microprocessors, microcontrollers, etc.) executing stored, computer-readable instructions to provide the exchange functionality 206.
  • the various interfaces 214-218 shown incorporate hardware and software implementations, as known in the art.
  • the exchange process 208 implements functionality, other than user-interface functionality, necessary to provide an automated commodity exchange system including, but not limited to, providing data to the web server 210 for presentation to a user of the exchange system.
  • the exchange process 208 will be described in further detail with regard to FIG. 3.
  • the web server 210 handles all non-secure interactions between the exchange controller and the computers 102 residing on the computer network 104.
  • data received from the exchange process 208 by the web server 210 comprises HTML-compliant data suitable for presentation via a web page.
  • the secure server 212 handles all secure interactions (such as would be used when providing financial account data or other confidential information to the exchange controller) between the controller 106 and computers 102.
  • the network interface 216 couples the controller 106 to the computer network 104. This includes support and termination of network protocols necessary to communicate via the computer network 104.
  • the network interface 216 operates to recognize transmissions intended for the exchange controller and, in a similar manner, to ensure that communications being sent to various computers 102 are properly routed. Although shown as a separate component from the web server 210 and secure server 212, it is understood that the functionality provided by the network interface 216 could be incorporated into one or both of the servers 210. 212.
  • the communication interface(s) 218 allow the controller 106 to communicate with the exchange office 110, for example through the use of a dial-up line, a direct Tl connection or the like, or a secure Internet connection.
  • the communication interface(s) 118 may also be used to communicate with one or more financial institutions using, for example, a direct Tl connection or the like, or a secure Internet connection. Additionally, the communication interface(s) 118 can be used to directly communicate with carriers used to settle the various transactions, although non-automated communications with such carriers are also possible and would provide, at least initially, a more easily implemented alternative.
  • the exchange process 208 is preferably implemented using computer-readable instructions and data structures stored on a computer-readable medium 302 and executed by a processor 304 (e.g., a microprocessor, microcontroller and the like). Additionally, the computer- readable medium 302 may also store data that is manipulated by the processor 304 in conjunction with the execution of the computer-readable instructions.
  • the processor 304 is preferably resident on the first server 202, whereas the computer-readable medium 302 may reside in the first server 202, the database 204 or a combination of the two.
  • the computer-readable medium 302 preferably comprises random-access memory (RAM) and/or read-only memory (ROM) resident in the exchange controller 106
  • the computer-readable medium 302 may also comprise other non-resident storage media, such as magnetic cassettes, floppy disks, flash memory cards, digital video disks, Bernoulli cartridges, RAMs, ROMs, and the like.
  • the computer-readable medium 302 comprises exchange logic 306, a selection information storage structure 314, an optional transmit program 316, quote data 318, address data 320, event data 322, seating data 324, trade data 326 and markets data 328 .
  • the exchange logic 306 implements those functions, preferably through the use of computer-readable instructions, susceptible to automation and necessary to conduct exchange operations. Such functions include, but are not limited to, processing user accounts, providing displays of markets, receiving bids and offers, recognizing matches between submitted bids and offers, processing acceptances of bids and/or offers and other exchange-oriented processing. Those having ordinary skill in the art will recognize other functionality useful in implementing an on-line exchange system may be similarly included in the exchange logic 306.
  • the processor 304 executes the exchange logic 306.
  • the selection information storage structure 314 is adapted to receive selection information corresponding to the commodities being traded. Users of the exchange system, having viewed market information and/or a visual depiction and its conesponding regions, may enter selection information regarding various ones of the regions against which they desire to enter a bid or offer. Thus, the particular format of the selection information storage structure 314 is dependent, in part, upon the commodities being traded.
  • the selection information storage structure 314 must be able to store an identification of the selected region, a bid price and, in the event where a market may include suitable "sub-markets" (e.g., rows within a block of seats), identification of the "sub-markets" and corresponding bids.
  • suitable "sub-markets” e.g., rows within a block of seats
  • identification of the "sub-markets” and corresponding bids may also be included in the selection information storage structure 314.
  • quote data 318 preferably resident in the database 204, is available to the exchange process 208.
  • the quote data 318 comprises all pertinent information regarding quotes provided by each market participant. Data structures necessary to provide linking of quotes are maintained, among other things, within the quote data 318.
  • a preferred data structure for use in storing the quote data 318 is discussed in further detail with regard to FIG. 5.
  • the address data 320 comprises all data relevant to any addresses used in the system.
  • a preferred data structure for use in storing the address data is discussed in further detail with regard to FIG. 6.
  • the event data 322 encompasses all pertinent information regarding events being held at various event venues described in the venue data 324. Preferred data structures for use in storing the event data and the venue data are described with reference to FIGS. 7 and 8, respectively.
  • the trade data 326 includes all information relative to quotes that have been accepted.
  • a preferred data structure for the trade data is described with reference to FIG. 9.
  • the markets data 328 is that data used by the exchange logic 306 to keep track of and present various markets to users of the exchange system. Particular examples illustrating the use of the market data 328 are shown in FIGS. 10-14.
  • At least portions of the data 314-328 collectively form a data structure suitable for implementing an on-line exchange system.
  • a data structure can be provided in whole or in part to a user's computer (e.g., by downloading a web page comprising the data structure) and used to gather selection information.
  • the selection information is conveyed back to the exchange controller. This is illustrated in FIG. 3 where the processor 304 transmits the data structure and receives the selection information.
  • elements may be added to or removed from the data structure, thereby increasing its utility for a particular application.
  • the data structure may include the transmit program 316 in lieu of the selection information storage structure 314.
  • the transmit program 316 is an optional program, such as a "JAVA" applet, included in the data structure that allows selection information to be transmitted to the exchange controller as it is received from the user, rather than waiting for all selection information to be received first.
  • a "JAVA" applet included in the data structure that allows selection information to be transmitted to the exchange controller as it is received from the user, rather than waiting for all selection information to be received first.
  • FIG. 5 illustrates a preferred data structure for the quote data described above.
  • the data structure residing on a computer-readable medium, comprises various records useful in maintaining and processing quotes related to a commodity exchange system.
  • the single-headed arrows between records indicate a to-one relationship (i.e., the originating record points to only one such terminating record) and the multi-headed arrows indicate a to-many relationship (i.e., the originating record can point to more than one of the terminating record).
  • each quote chain record 501 can point to multiple bid records 502 and/or multiple offer records 503 ; however, any one bid or offer record can point to only one quote chain record.
  • Each quote chain record 501 includes, at a minimum, a quote chain identifier and an account identifier.
  • the quote chain identifier potentially defines a quote chain and the account identifier specifies the particular user account that includes the quote chain.
  • a reference code and time stamp may also be included in each quote chain record.
  • the reference code is used by personnel within the exchange office 1 10 as an internal identifier for confirmation (e.g., fulfillment) purposes.
  • the time stamp allows office personnel to know when a particular quote chain was established.
  • Each of the bid records 502 includes, at a minimum, a bid identifier and a quote chain identifier.
  • the bid identifier allows individual bids to be identified (e.g., when searches for particular types of bids are being performed) and the quote chain identifier associates the bid with a single quote chain.
  • the bid records may also include a bid specification identifier that points to a particular bid specification record 504 describing the goods to which the bid pertains.
  • the bid records may also include the bid price as well as a quote date and time stamp used to mark the time the bid was initially created.
  • a quote status may also be included thereby allowing the status of a given bid to be modified. In a preferred embodiment, the quote status for a given bid may be either "active" or "hold".
  • each of the offer records 503 includes, at a minimum, an offer identifier and a quote chain identifier.
  • the offer identifier allows individual offers to be identified (e.g., when searches for particular types of offers are being performed) and the quote chain identifier associates the offer with a single quote chain.
  • the offer records may also include an offer specification identifier that points to a particular offer specification record 505 describing the goods to which the offer pertains.
  • the offer records may also include the offer price as well as a quote date and time stamp used to mark the time the offer was initially created.
  • a quote status serving the same purpose as in the bid records, may also be included in the offer records.
  • the bid specification records 504 and the offer specification records 505 describe the particular goods to which a bid or offer, respectively, pertains.
  • the format of the bid specification records 504 and the offer specification records 505 depends upon the types of goods being traded. Preferred formats for the bid specification records 504 and the offer specification records 505, particularly suited for use in an exchange system dealing in event venue seats as commodities, are illustrated in FIG. 5.
  • Each of the bid specification records 504 comprises, in addition to the bid specification identifier, fields identifying the particular event being bid upon, a quantity of seats being bid upon, and a particular region (i.e., a locale within which seats are deemed fungible) being bid upon.
  • a bid may also specify a "maximum row" such that any seat in the maximum row or a better row (i.e., any row in the same region generally considered as providing more favorable seating) may be used to fulfill the bid.
  • a maximum row indication may also be included in the bid specification records 504.
  • the offer specification records 505 differ from the bid specification records 504 in two respects. First, an offer specification identifier is used. Second, only a row indication (as opposed to a maximum row indication) is provided because a seller can only describe the goods that he or she has to sell.
  • the offer tickets record 508 and the tickets record 509 provide a means for identifying the specific tickets, down to the particular seats, within a given offer. These records allow support personnel to quickly identify the exact tickets being offered in the event of, for example, a dispute over which party has the right to offer certain tickets for sale.
  • the data structure may comprise accounts records 511, credit card records 512 and card type records 513.
  • the account records 511 are uniquely associated with individual users of the exchange system. As shown, each account record comprises information needed to identify and contact individual users and financial information needed to charge customers that engage in transactions.
  • a user name field is provided as a means for identifying users by a unique name. In a preferred embodiment, the user name for each user is an email address.
  • the credit types records 513 identify the particular type of credit card used, e.g., Visa, American Express, etc. Although a specific type of data structure has been described with regard to FIG. 5, those having ordinary skill in the art will recognize that other data structures incorporating similar information and organization may be used and are a matter of design choice.
  • FIG. 6 illustrates a preferred data structure for the address data described above.
  • the data structure residing on a computer-readable medium, comprises various records useful in maintaining address information, such as billing and shipping addresses, for users of a commodity exchange system.
  • the data structure comprises a postal addresses record 601 comprising a postal address identifier, street address fields, a city identifier and a zip code field, as know in the art.
  • the postal addresses record 601 makes reference to a string of cities, states and countries records 602-604.
  • the cities records 602 specify a city identifier for each particular city record, a state identifier corresponding to a particular city, and a name of the particular city.
  • the states records 603 specify a state identifier for each particular state record, a country record corresponding to a particular state, a name of the particular state and an abbreviation of the particular state (such as the two letter postal abbreviations).
  • the countries records 604 specify a country identifier for each particular country record and a name of a particular country.
  • each of the cities, states and countries records 602-604 includes references to one or more cities, states and countries aliases records 606-608, respectively.
  • the respective aliases records 606-608 include the identifier of the corresponding city, state or country and a name field of an alias for that particular city, state or country, e.g., New York city as the "Big Apple".
  • the data structure residing on a computer-readable medium, comprises various records useful in maintaining events information, such as specific concert, theatrical and sporting events for use in a commodity exchange system.
  • the data structure comprises events records 701 corresponding to individual events.
  • An event identifier uniquely identifies each event using a numerical (and thereby more readily searchable) string, whereas an event code comprises a textual identifier for the event.
  • An event category identifier identifies a particular class of events to which the event belongs, e.g., baseball game, football game, rock concert, opera performance, etc.
  • the event date specifies the date on which a particular event is to take place and a seating plan identifier identifies a particular seating plan to be used for the event.
  • Each event record 701 refers to an event category record 702 comprising the event category identifier described above, a name associated with the event category and a parent category identifier, e.g., sports, concerts, theater, etc.
  • each event category record 702 refers to one or more event category alias records 703 comprising, in addition to the event category identifier, an alias for that particular event category.
  • event category record 702 may also refer to one or more event category image records 704 comprising, in addition to the event category identifier, an image identifier for readily identifying and locating the required image.
  • each event category record 702 may also be associated with one or more performer event category records 705 that comprise a performer identification.
  • performer identifications may be used as the basis for searches, for example, where a user wishes to see all available event for a given performer.
  • Each of the event records 701 refers to one or more event alias records 707 comprising alias information associated with the event. Any given event may be a part of a series of events, for example where a given music concert at a particular event venue on a particular date is part of a larger series of concerts in a national tour.
  • the event record 701 may refer to a subordinate data structure comprising an event series record 709, event series event records 710 and event series alias records 711.
  • the even series record 709 comprises an event series identifier and a name associated with the event series.
  • Each event series event record 710 comprising the event and event series identifiers, provides a link between the individual event record 701 and the event series record 710.
  • the event series alias records 711 set forth aliases for the event series.
  • each event record 701 refers to one or more event performers records 713 that associate the event identifier with a performer identifier and a performer role identifier.
  • the particular type of data included in the performer identifier and a performer role identifier data fields depends on the type of event, i.e., an individual actor in a theater production versus a sports team in a sporting event.
  • each event performers record 713 refers to a performer roles record 714 setting forth a name of a particular role.
  • each event performers record 713 refers to a performer record 715 identifying a particular performer by name and alias through association with one or more performer alias records 716.
  • the data structure residing on a computer-readable medium, comprises various records useful in maintaining venue information corresponding to events in a commodity exchange system.
  • the data structure comprises venue records 801 each corresponding to a unique venue and comprising a venue identifier, a name of the venue, and information identifying location of the venue including a street address, city identifier and a postal code.
  • venue alias records 802 are associated with each venue record 801.
  • each venue record 801 refers to one or more seating plan records 803.
  • Each seating plan record 803 comprising a seating plan identifier, a seating plan name identifier, the venue identifier, an image identifier and a nomenclature identifier.
  • the image identifier uniquely identifies display data (such as bitmap files, JPEG files and the like) in an image record 812.
  • Each image record 812 includes an image identifier, a name of the image and an image type identifier.
  • Each image record 812 refers to an image type record 813 comprising the image type identifier and a name for the image type.
  • the display data stored in this manner is suitable for causing a visual depiction of one or more areas to be rendered on a computer display.
  • the areas thus represented include any locales receptive to the establishment of multiple commodity markets based in part upon spatially diverse regions.
  • the areas depicted in the display data files comprise aerial views of seating information for the event venues identified in the event records 801.
  • An example of a visual depiction 400 is illustrated in FIG. 4 where a sports stadium (in this example, Wrigley Field in Chicago, Illinois) is shown.
  • each seating plan record 803 refers to one or more region records 804.
  • Each region record 804 includes information defining the spatially diverse regions included within the area to be depicted.
  • each region defines a portion of the area in which a given commodity may be regarded as fungible, and thus constitutes a separate commodity against which a market may be formed.
  • regions are an overlay to an area that may otherwise comprise predefined sections, as is typically found in many event venues for example.
  • each region record 804 comprises a region identifier identifying a particular region within an area, the seating plan identifier of the parent seating plan record, a color identifier for the region, a region name identifier and a region type identifier.
  • Each region record 804 may refer to one or more section records 805 that identify predefined sections within a given region, each section record 805 comprising a section identifier, a section name, a seating area identifier and the region identifier of the parent region.
  • Each region record 804 also refers to a region type record 805 that identifies the region's type by name, and to a region name record 807 that identifies the region's name.
  • the region records 804 may also support the use of color codes such that each region or separate groups of regions are represented by distinct colors.
  • each region record 804 refers to a color record 808 comprising a color identifier and name.
  • the color records 808 when incorporated into, or used to modify, display data for a given area or venue, the color records 808 cause the separate regions or groups of regions to be displayed in accordance with the assigned color.
  • the background, border or similar indicia of a given region or group of regions could be displayed using a corresponding color, which color is preferably distinct from an adjacent region or group of regions.
  • region data included in the region records 804 and their progeny when overlaying or incorporated into the display data, enables a visual depiction to be provided in which various spatially diverse markets are defined, thereby facilitating transactions through, for example, an on-line exchange-driven system.
  • a plurality of such regions are provided in which various spatially diverse markets are defined, thereby facilitating transactions through, for example, an on-line exchange-driven system.
  • Table 1 describes each of the regions shown in FIG. 4 by region names according to corresponding reference numerals.
  • each seating plan record 803 refers to one or more seating area records 809 each comprising a reference to the seating plan identifier of the parent record, a seating area identifier and seating area name identifier.
  • the seating area name identifier is used to identify a seating area names record 810 comprising the name of the particular seating area.
  • the seating area identifiers are used to associate each seating area record 809 with one or more sections records 805. In this manner, each seating area within a given seating plan may be completely specified.
  • each seating plan record 803 refers to a seating plan name record 815 comprising a name for the parent seating plan, and to a nomenclature record 817.
  • the nomenclature records 817 are used to store names relevant to describing a given venue's seating plan. For example, what some even venues would refer to as a section may be termed an aisle in a different event venue. In order to ensure that a system user is provided with the correct terminology, the nomenclature records 817 may be referenced when presenting seating plan information.
  • the name data included in any of the records 801-817 may be used as textual data to differentiate each of the regions.
  • the textual data may be used in place of, or as a supplement to, the visual depictions described above in order to describe each of the regions.
  • the textual descriptions may also be displayed in accordance with the color coding scheme. That is, suitable background colors, border colors, font colors or other indicia reflective of the color coding scheme may be used, thereby reinforcing the correlation between the regions displayed in a visual depiction and their corresponding textual descriptions.
  • FIG. 9 illustrates a preferred data structure for trade data used to track and memorialize specific trades that have occurred through the commodity exchange system.
  • a trade is a sale of a commodity by a seller to a buyer effectuated through the commodity exchange system described herein.
  • the data structure comprises a trade record 901 with one more references to trade ticket records 902.
  • Each trade record 901 comprises a trade identifier that uniquely identifies each trade made within the commodity exchange system.
  • a price field and a quantity field are also included.
  • the quantity field comprises a number of seats (tickets) being purchased and the price field reflects the per seat price agreed to by the parties.
  • a buyer account identifier and a seller account identifier uniquely identify account records of the buyer and seller, respectively.
  • a trade date field comprises a date and time when agreement was reached between the parties to enter into the trade.
  • each trade record 901 includes a reference code which is used as an internal identifier for purposes of database and system management.
  • the trade tickets records 902 afford a means for quickly identifying the specific tickets associated with a given trade. This is accomplished through the inclusion of a ticket identifier field that refers to a tickets record 509.
  • FIGS. 10-14 The data structures described above relative to FIGS. 5-9 provide a basis upon which a commodity exchange system may be implemented. However, for a commodity exchange system to actually work, users must be able to ascertain the current state of markets and have the ability to enter their quotes into such markets. To this end, the present invention provides market information and allows users to enter quotes in light of such market information. This is illustrated in FIGS. 10-14.
  • FIG. 10 a market information display 1000 for particular use in obtaining offers is illustrated.
  • the displays illustrated in FIGS. 10-14 are exemplary of displays that would be provided on the computers of users of a commodity exchange system directed to the trade of seats within event venues. It should be noted that techniques for obtaining the data included in the displays shown in FIGS. 10-14 from databases and data structures, such as those described above, are well known in the art.
  • the display 1000 is provided to a user that has chosen a particular event and desires to make an offer of tickets to sell. As described above, seats are treated as commodities based on regions in which they are located. Thus, any given region within an event venue for a given event is a suitable basis for establishing a separate market.
  • the present invention also provides for further market creation by accommodating the creation of markets within a given region by virtue of the number of units of the commodity being traded. These quantity-differentiated markets may then operate independent of each other.
  • the display 1000 comprises a market selection region 1002 comprising quantity- based market descriptors 1003 and quantity-based market selectors 1004.
  • a potential seller after having established an account with the exchange system and after having selected a particular event for which he or she has tickets to sell, may select the particular quantity-differentiated market they wish to enter by selecting one of the quantity-based market selectors 1004.
  • the system may initially provide the 1 Ticket market and allow the potential seller to decide which markets they wish to enter.
  • market information 1009 is provided. In the example of FIG. 10, market information 1009 for a 2 Tickets market is displayed.
  • the market information 1009 provided comprises listings for each region in the quantity-differentiated market for which quotes have been received. As described in greater detail below, markets may be further differentiated according to the rows for given seats within a region. In the example shown in FIG. 10, the sole market displayed is for seats in any row in the 'A' region. Also shown are the current highest bid and lowest offer (on a per ticket basis) for that market, in this case $100 and $120, respectively. If desired, the potential seller may enter an offer into an offer field 1010. To complete an offer, the potential seller must fill in data in the offer specification fields 1015-1019 describing the particulars of the offer. To this end, seating area, section, row and seat number information must be entered to specifically identify the tickets being sold.
  • an offer expiration date can be entered. Although various types of pull down menus and data fields are illustrated for these purposes, those having ordinary skill in the art will recognize that a variety of data collection mechanisms may be used. If a mistake is made completing the offer specification fields 1015-1019, or if the user changes his or her mind and wishes to remove an outstanding bid, they may select the cancel button 1024. Once an offer covering specific tickets has been entered, the exchange system ascertains the correct region encompassing the tickets being offered. If, by user error, the market information 1009 being displayed does not correspond to the region identified as encompassing the offered tickets, an error message is provided an the appropriate market information is provided.
  • the potential seller may elect to submit the offer, including the completed offer field 1010, by selecting a submit button 1022.
  • This will result in quote chain records, as described above relative to FIG. 5 and particularly comprising an offer record 503 , being created for that user' s account.
  • the offer thus created is then available to be used by the exchange system to create and display recalculated market data as needed.
  • the potential seller after having completed the offer specification fields 1015-1019 may simply decided that he or she is willing to sell the tickets at the current best bid price. In this case, they may select a sell button 1011 thereby automatically registering their acceptance of that bid. In response, appropriate trade records like those described above relative to FIG. 9 are created.
  • the exchange controller may cause notification regarding the trade to be sent to personnel in the exchange office 110 and/or to a carrier 112 such that appropriate processes to fulfill the trade (i.e., obtain and validate the tickets from the seller and provide them to the buyer, obtain payment from the buyer and provide it to the seller) may be initiated.
  • a market information display 1100 for particular use in obtaining bids is illustrated.
  • the display 1100 is provided to a user that has chosen a particular event and desires to make a bid to buy tickets.
  • a market selection region 1 102 functionally identical to the market selection region 1002 described above, is provided.
  • market information regarding particular markets is also provided.
  • the market information provided in the bid display 1100 comprises listings for different regions and rows, as well as the highest bid and lowest offers for each of these markets.
  • each seat within a given region is considered equivalent to any other seat within that same region for the purposes of establishing a commodity market.
  • the present invention provides an exception to this, in the case of venue seats as commodities, to the extent that each row within a given block, if that entire block may be so subdivided, may be considered "sub-markets" within the given region' s market.
  • markets can be established for particular rows or ranges of rows within a given region.
  • a bid may also specify a "maximum row” such that any seat in the maximum row or a better row (i.e., any row in the same region generally considered as providing more favorable seating) may be used to fulfill the bid. This is illustrated in FIG. 1 1 where separate markets for row 1 alone, rows 1 -5 or any row within the 'A' region are shown.
  • Bids may be entered using the bid fields 1110 against one or more particular markets. If desired, the potential buyer may decide to cancel outstanding bids using the cancel button 1124 or, after entering an expiration date 1119 for the bids, the user may select the submit button 1122 to enter their bids. This will result in quote chain records, as described above relative to FIG. 5 and particularly comprising a bid record 502, being created for that user's account. The bid thus created is then available to be used by the exchange system to create and display recalculated market data as needed. As an alternative to submitting a bid, the potential buyer may simply decided that he or she is willing to buy tickets at the current best offer price. In this case, they may select a buy button 1111 thereby automatically registering their acceptance of that offer.
  • both the offer and bid display screens 1000, 1100 display market information relevant to the potential market participant's desired course of action.
  • the present invention also provides market information for those users who have not yet decided to take a position in a given market or who have taken a position and wish to see a more complete representation of the market, as further described with reference to FIGS. 12-14.
  • FIG. 12 illustrates a complete market display 1200 in which both the bid and offer sides of markets are displayed.
  • the display 1200 is provided to a user that has chosen a particular event and is either deciding whether to take a position in a given market, or who has already taken a position and wishes to see a more complete market representation.
  • market information regarding particular markets is also provided.
  • the market information provided in the complete market display 1200 comprises listings for different regions and rows, as well as the highest bid and lowest offers for each of these markets.
  • the complete market display also includes, for each market displayed, a number of buyers currently having outstanding bids and a number of sellers currently having outstanding offers. In this manner, the complete market display provides a user with a greater sense of the depth of each market.
  • users may choose to enter new bids or offers, or change existing bids/offers, in selected markets using the bid and offer fields 1210, 121 1 provided.
  • a user may enter their bid or offer in the appropriate field 1210, 1211 and select a post bid or offer button 1213, 1215.
  • that bid or offer will already be displayed in the appropriated bid or offer field 1210, 1211.
  • the user can change any such bid or offer and select the change bid or offer button 1212, 1216.
  • selection of the change or post bid buttons 1212, 1213 will cause the bid display 1100 to be provided to the user, whereas selection of the change or post offer buttons 1216, 1215 will cause the offer display 1000 to be provided to the user.
  • a user decides that he or she wants to cancel all of his or her bid and/or offers, he or she may select either or both of the cancel all bids button 1222 and the cancel all offers button 1224.
  • the user may select buy or sell buttons 1214, 1217 for a particular market and immediately enter into a transaction. Where the user selects a sell button, they are first required to enter the necessary offer specification information 1015-1019 described above.
  • a user may select a market detail market display using any one of the details links 1218, in which case they are provided with a market detail display 1300.
  • a less detailed market summary may be selected using a summary link 1220, in which case a market summary display 1400 is provided.
  • the market detail display 1300 comprises similar information as the complete market display 1200, including bid and offer fields, as well as post/change bid, post/change offer, buy, sell and cancel buttons, as described above.
  • the market detail display 1300 further breaks down, for each market within a given quantity-differentiated market, the existing offers and bids and the number of market participants for each. This is illustrated in FIG.
  • N the number of bids and the M lowest offers are displayed, where N is not necessarily equal to M. It is understood that various constraints may be placed on the values of N and M (e.g., they must always be equal and should be no greater than the smaller of the two) and is a matter of design choice.
  • the market for tickets in region 'A' any row is shown at the top of FIG. 13. In the example shown, the current best bid is $95/ticket with only one buyer at that price. However, there are 5 buyers at $93/ticket, 3 buyers at $90/ticket and 8 buyers at $85/ticket.
  • parenthetically enclosed numbers next to a number of buyers indicates the ranking, relative to the other bids at that price, at which the current user's bid will be fulfilled.
  • parenthetical ' 1 ' next to the current user'sbid at $90/ticket fortheregion 'A', any row market indicates that the user's bid at this price will be the first to be fulfilled if accepted by a seller.
  • the user's bid at $25/ticket for the region 'C any row market will be the sixth to be fulfilled if accepted by sellers.
  • a similar convention may be applied to offers.
  • any row market the best offer is currently at $99/ticket with only one seller at that price. However, there are 4 sellers at $105/ticket and 3 sellers at $115/ticket.
  • an ideal market price (the price at which buyers and seller would ideally always agree to a trade) may be represented by an imaginary horizontal line (none shown).
  • the outstanding bids for that market are shown in descending order below the imaginary horizontal line, whereas the outstanding offers for that market are shown in ascending order above the imaginary horizontal line. In this manner, a market participant or an interested non-participant may readily gauge the depth and spread of a given market.
  • color coding may be incorporated into the market detail display 1300.
  • the dotted boxes 1301 -1304 surrounding the detailed market information for each market represent this. In this manner, the information included in the color records 808 for a given region may be reflected in the market detail display 1300, or any of the other market displays discussed herein.
  • a market summary display 1400 is illustrated.
  • all of the quantity-differentiated markets 1404 for a given event are listed, with the current best bids and offers corresponding to each available region 1402 shown in tabular form.
  • the significant difference between the market summary display 1400 and the previous displays 1000, 1100, 1200, 1300 is that no mechanisms exist for a user to enter a competing bid or offer. In this manner, a user may obtain a quick overview of each market for a given event, thereby allowing them to better gauge the individual markets and decide whether they wish to enter, or remain in, any markets at all.
  • the present invention provides a technique for implementing trades and establishing markets for commodities, particularly when applied to an on-line exchange system.
  • market information is provided for a variety of markets including, preferably, a variety of quantity-differentiated markets.
  • the present invention can be used in conjunction with markets for non-traditional commodities, such as seats within event venues. In that context, markets may be further defined according to rows in which the seats are located. Market displays include mechanisms that allow user to enter, change or cancel quotes in various markets.
  • a publicly available communication network such as the Internet or World Wide Web
  • the present invention may be advantageously used to implement a commodity exchange system.
  • a publicly available communication network such as the Internet or World Wide Web

Abstract

Seats at event venues are treated as commodities within a commodity ecxhange system, preferably implemented within a publicly available communication network. Market information for at least one seat in an event venue is provided to users of the exchange system. In one emobdiment of the present invention, the number of seats being traded differentiates markets for a particular event within a particular event venue. Users may submit quote proposals (e.g., bid or offers) or quote acceptances. In this manner, the present invention allows market forces to more readily determine prices for event tickets.

Description

METHOD AND APPARATUS FOR USE IN A COMMODITY EXCHANGE SYSTEM
Technical Field The present invention relates generally to trading systems and, in particular, to a method and apparatus for use in implementing trades and establishing markets in a commodity exchange system.
Background Of The Invention Exchange driven commerce systems are well-known in the art. These systems, such as the New York Stock Exchange (NYSE) or the Chicago Mercantile Exchange (CME), match buyers and sellers by offering an efficient, fair and orderly marketplace. For example, in a commodities exchange, buyers are free to submit bids on well-defined commodities and sellers likewise submit offers on the same commodities. The exchange effectuates communications that allow for the matching process between bids and offers to take place. Increasingly, such exchanges are making steps at automating their systems. Automated exchange-driven commerce systems for trading various instruments are disclosed in, for example, U.S. Pat. No. 4,903,201 and U.S. Pat. No. 5,924,083.
Concurrently, the use of publicly-available communication networks, such as the Internet, have brought about a dramatic rise in electronically-transacted commerce, often referred to as e- commerce. For example, on-line auction sites, such as that provided by eBay, Inc., have become well-known. Such auctions are examples of seller-driven systems in which the seller defines contract terms but does not necessarily define a price for the goods to be sold. Another type of auction site is that provided by priceline.com, Inc. in which buyers are allowed to state the terms under which they are willing to complete a purchase.
Generally, almost any fungible good can be treated as a commodity. For example live cattle, random-length lumber, various foreign currencies, interest rates and stock indices, to name a few, are currently traded as commodities. In a similar vein, on-line "exchange" systems, typically dealing in "non-traditional" commodities, have also been recently developed. For example, several websites on the Internet have recently been created that provide a forum for buyers and sellers of telephone bandwidth and/or long-distance minutes.
Another type of e-commerce site has also been developed, particularly directed to the buying and selling of event tickets. In general, these sites extend the services of so-called "ticket brokers". Typically, these systems function essentially like electronic bulletin boards. That is, sellers of tickets (i.e., the ticket brokers) are able to post their offers and state the particular terms under which they would be willing to complete a transaction for event tickets. However, because these systems do not incorporate bid information by potential buyers, they are unlike true commodity markets. That is, these systems generally do not provide a method for potential buyers to submit bids for tickets, nor do they make such bid and offer information generally available thereby allowing market forces to determine prices. Furthermore, no attempt is made to match offers and bids in these on-line systems. Because such bid information is neither accepted nor provided, ticket broker e-commerce sites do not function as true markets.
Thus, it would be advantageous to provide a novel technique for establishing commodity markets that is readily adaptable of use in on-line exchange systems. A particularly useful application for such techniques is in the area of on-line exchanges dealing in tickets to a variety of events, such as sporting, theatrical and concert events.
Summary Of The Invention The present invention provides a technique for implementing trades and establishing markets in a commodity exchange system. In particular, the commodity exchange system of the present invention is directed to the treatment of seats (more specifically, the tickets for those seats) within event venues as commodities. Generally, market information for at least one seat in an event venue is provided to users of the exchange system. In one embodiment of the present invention, the number of seats being traded differentiates markets for a particular event within a particular event venue. Based on this market information, users may submit quote proposals (e.g., bid or offers) or quote acceptances. Various data structures and display formats are provided to promote market participation and efficiency. Preferably, the present invention is implemented within a publicly available network, such as the Internet or World Wide Web. In this manner, the present invention provides an improved exchange system. Brief Description Of The Drawings
FIG. 1 is a block diagram of a computer system in accordance with the present invention.
FIG. 2 is a block diagram of a preferred embodiment of an exchange controller in accordance with the present invention.
FIG. 3 is a block diagram illustrating an exchange process in accordance with the present invention.
FIG. 4 illustrates an exemplary visual depiction in accordance with the present invention.
FIG. 5 illustrates a preferred embodiment of a first data structure in accordance with the present invention.
FIG. 6 illustrates a preferred embodiment of a second data structure in accordance with the present invention.
FIG. 7 illustrates a preferred embodiment of a third data structure in accordance with the present invention. FIG. 8 illustrates a preferred embodiment of a fourth data structure in accordance with the present invention.
FIG. 9 illustrates a preferred embodiment of a fifth data structure in accordance with the present invention.
FIG. 10 illustrates a market information display format for particular use in obtaining offers in accordance with the present invention.
FIG. 11 illustrates a market information display format for particular use in obtaining bids in accordance with the present invention.
FIG. 12 illustrates a market information display format for particular use in providing a more complete market display in accordance with the present invention. FIG. 13 illustrates a market information display format for particular use in providing a detailed market display in accordance with the present invention.
FIG. 14 illustrates a market information display format for particular use in providing a market summary in accordance with the present invention.
Detailed Description Of The Invention The present invention may be more fully descπbed with reference to FIGS. 1-14 FIG. 1 illustrates a computer system 100 comprising a plurality of computers 102 m communication with each other through a communication network 104. An exchange controller 106, coupled to the communication network 104, is capable of communicating with the computers 102. In a preferred embodiment, the communication network 104 comprises a publicly available computer network, such as the Internet or World Wide Web However, it is understood that the present invention is not limited in this regard, the network 104 may compπse or include a pπvate computer network Each of the computers 102 is preferably a personal computer, typically for use in the home or office. At a minimum, each computer 102 should support a common communication protocol with the exchange controller 106, preferably the so-called TCP/IP suite of protocols used to support Internet and "ETHERNET" communications Of course, other communication protocols could be equally used dependent, in part, upon the type of communication network 104 employed
The exchange controller 106 serves to implement an on-line commodities exchange in accordance with the present invention and will be described in further detail with reference to FIGS 2 and 3 Generally, the exchange controller 106 functions to automate interface operations with potential buyers and sellers of a given commodity, to implement exchange functionality (e.g , display market information, identify potential trades, etc ) and to support settlement activities To this end, the exchange controller 106 is in communication with one or more financial institutions 108 capable of veπfymg customer credit availability and limits, issuing payments, holding funds while awaiting transaction clearance and the like The exchange controller 106 is also in communication with an exchange office 110 The exchange office 110 includes personnel required to maintain operation of the exchange controller 1 10, field customer inquiries where necessary, ensure order settlement and to generally administer operations of the exchange In one embodiment of the present invention, the exchange office 110 communicates with a earner 1 12 in order to facilitate settlement of completed transactions. That is, the exchange office 110 receives information regarding completed transactions (transactions in which a buyer agreed to a seller' s offering pπce or in which a seller agreed to a buyer's bid pπce) from the exchange controller 106 and forwards any information necessary for a earner 112, if required, to perform delivery of the desired goods. It is anticipated that communications between the exchange controller 106 and the carrier 112 can also be performed directly (as illustrated by the dotted link) such that the necessary information is forwarded directly to the carrier 112 once a transaction has been completed.
Referring now to FIG.2, a more detailed view of a preferred embodiment of the exchange controller is provided. The exchange controller comprises at least two servers 202, 204, such as "SUN" "ENTERPRISE" 250 servers, operating in combination to provide an on-line exchange system. It is understood that the present invention need not be limited to an on-line implementation, and is susceptible to other implementations. For example, communications between individuals and the exchange controller 106 could be carried out using telephone, facsimile, postal mail or other off-line methods of communication. It is further understood that other implementations (including various hardware implementations) encompassing the same functionality as described herein will be readily apparent to those having ordinary skill in the art. In the implementation shown, a first server 202 communicates via a database interface 214 with a second server configured to operate as a database 204. Techniques for configuring servers in this manner are well-known in the art. The database 204 stores all relevant information necessary to complete commodities transactions, such as buyer and seller identifications, account identifications, passwords, information regarding specific quotes (bids and/or offers), credit information, etc.
The first server 202 implements the exchange functionality 206. As shown, the exchange functionality 206 encompasses an exchange process 208, a web server 210 and a secure server 212. Although not shown, the first server 202 comprises one or more processing units (such as microprocessors, microcontrollers, etc.) executing stored, computer-readable instructions to provide the exchange functionality 206. Likewise, the various interfaces 214-218 shown incorporate hardware and software implementations, as known in the art. The exchange process 208 implements functionality, other than user-interface functionality, necessary to provide an automated commodity exchange system including, but not limited to, providing data to the web server 210 for presentation to a user of the exchange system.
The exchange process 208 will be described in further detail with regard to FIG. 3. The web server 210 handles all non-secure interactions between the exchange controller and the computers 102 residing on the computer network 104. In a preferred embodiment, data received from the exchange process 208 by the web server 210 comprises HTML-compliant data suitable for presentation via a web page. In contrast, the secure server 212 handles all secure interactions (such as would be used when providing financial account data or other confidential information to the exchange controller) between the controller 106 and computers 102. The network interface 216 couples the controller 106 to the computer network 104. This includes support and termination of network protocols necessary to communicate via the computer network 104. In particular, the network interface 216 operates to recognize transmissions intended for the exchange controller and, in a similar manner, to ensure that communications being sent to various computers 102 are properly routed. Although shown as a separate component from the web server 210 and secure server 212, it is understood that the functionality provided by the network interface 216 could be incorporated into one or both of the servers 210. 212.
As shown, the communication interface(s) 218 allow the controller 106 to communicate with the exchange office 110, for example through the use of a dial-up line, a direct Tl connection or the like, or a secure Internet connection. The communication interface(s) 118 may also be used to communicate with one or more financial institutions using, for example, a direct Tl connection or the like, or a secure Internet connection. Additionally, the communication interface(s) 118 can be used to directly communicate with carriers used to settle the various transactions, although non-automated communications with such carriers are also possible and would provide, at least initially, a more easily implemented alternative.
Referring now to FIG. 3, a more detailed view of the exchange process 208 of FIG. 2 is presented. The exchange process 208 is preferably implemented using computer-readable instructions and data structures stored on a computer-readable medium 302 and executed by a processor 304 (e.g., a microprocessor, microcontroller and the like). Additionally, the computer- readable medium 302 may also store data that is manipulated by the processor 304 in conjunction with the execution of the computer-readable instructions. The processor 304 is preferably resident on the first server 202, whereas the computer-readable medium 302 may reside in the first server 202, the database 204 or a combination of the two. Although the computer-readable medium 302 preferably comprises random-access memory (RAM) and/or read-only memory (ROM) resident in the exchange controller 106, the computer-readable medium 302 may also comprise other non-resident storage media, such as magnetic cassettes, floppy disks, flash memory cards, digital video disks, Bernoulli cartridges, RAMs, ROMs, and the like.
As shown, the computer-readable medium 302 comprises exchange logic 306, a selection information storage structure 314, an optional transmit program 316, quote data 318, address data 320, event data 322, seating data 324, trade data 326 and markets data 328 . The exchange logic 306 implements those functions, preferably through the use of computer-readable instructions, susceptible to automation and necessary to conduct exchange operations. Such functions include, but are not limited to, processing user accounts, providing displays of markets, receiving bids and offers, recognizing matches between submitted bids and offers, processing acceptances of bids and/or offers and other exchange-oriented processing. Those having ordinary skill in the art will recognize other functionality useful in implementing an on-line exchange system may be similarly included in the exchange logic 306. The processor 304 executes the exchange logic 306.
The selection information storage structure 314 is adapted to receive selection information corresponding to the commodities being traded. Users of the exchange system, having viewed market information and/or a visual depiction and its conesponding regions, may enter selection information regarding various ones of the regions against which they desire to enter a bid or offer. Thus, the particular format of the selection information storage structure 314 is dependent, in part, upon the commodities being traded. For example, where a user selects a given region and submits a bid on commodities corresponding to that region, the selection information storage structure 314 must be able to store an identification of the selected region, a bid price and, in the event where a market may include suitable "sub-markets" (e.g., rows within a block of seats), identification of the "sub-markets" and corresponding bids. Those having ordinary skill in the art will recognize that storage for other information necessary for the proper operation of the exchange may also be included in the selection information storage structure 314.
As further shown in FIG. 3. quote data 318, preferably resident in the database 204, is available to the exchange process 208. The quote data 318 comprises all pertinent information regarding quotes provided by each market participant. Data structures necessary to provide linking of quotes are maintained, among other things, within the quote data 318. A preferred data structure for use in storing the quote data 318 is discussed in further detail with regard to FIG. 5. The address data 320 comprises all data relevant to any addresses used in the system. A preferred data structure for use in storing the address data is discussed in further detail with regard to FIG. 6. The event data 322 encompasses all pertinent information regarding events being held at various event venues described in the venue data 324. Preferred data structures for use in storing the event data and the venue data are described with reference to FIGS. 7 and 8, respectively. The trade data 326 includes all information relative to quotes that have been accepted. A preferred data structure for the trade data is described with reference to FIG. 9. Finally, the markets data 328 is that data used by the exchange logic 306 to keep track of and present various markets to users of the exchange system. Particular examples illustrating the use of the market data 328 are shown in FIGS. 10-14.
In one embodiment of the present invention, at least portions of the data 314-328 collectively form a data structure suitable for implementing an on-line exchange system. In accordance with the methods described below, such a data structure can be provided in whole or in part to a user's computer (e.g., by downloading a web page comprising the data structure) and used to gather selection information. When all of a user's selection information has been stored in the selection information storage structure 314, the selection information is conveyed back to the exchange controller. This is illustrated in FIG. 3 where the processor 304 transmits the data structure and receives the selection information. As required, elements may be added to or removed from the data structure, thereby increasing its utility for a particular application. Further still, in another embodiment of the present invention, the data structure may include the transmit program 316 in lieu of the selection information storage structure 314. The transmit program 316 is an optional program, such as a "JAVA" applet, included in the data structure that allows selection information to be transmitted to the exchange controller as it is received from the user, rather than waiting for all selection information to be received first. Those having ordinary skill in the art will recognize that other implementations are possible and are a matter of design choice.
FIG. 5 illustrates a preferred data structure for the quote data described above. The data structure, residing on a computer-readable medium, comprises various records useful in maintaining and processing quotes related to a commodity exchange system. In FIGS. 5-9, the single-headed arrows between records indicate a to-one relationship (i.e., the originating record points to only one such terminating record) and the multi-headed arrows indicate a to-many relationship (i.e., the originating record can point to more than one of the terminating record). A more complete description of the use of the data structure illustrated in FIG. 5, and in particular the use of quote chain identifiers, is provided in attorney docket number 4783.82406 entitled METHOD AND APPARATUS FOR PROCESSING QUOTES IN A COMMODITY EXCHANGE SYSTEM. At a minimum, the data structure illustrated in FIG. 5 comprises a quote chain record 501 and at least one of either a bid record 502 or an offer record 503. For example, each quote chain record 501 can point to multiple bid records 502 and/or multiple offer records 503 ; however, any one bid or offer record can point to only one quote chain record.
Each quote chain record 501 includes, at a minimum, a quote chain identifier and an account identifier. As described above, the quote chain identifier potentially defines a quote chain and the account identifier specifies the particular user account that includes the quote chain. A reference code and time stamp may also be included in each quote chain record. The reference code is used by personnel within the exchange office 1 10 as an internal identifier for confirmation (e.g., fulfillment) purposes. The time stamp allows office personnel to know when a particular quote chain was established.
Each of the bid records 502 includes, at a minimum, a bid identifier and a quote chain identifier. The bid identifier allows individual bids to be identified (e.g., when searches for particular types of bids are being performed) and the quote chain identifier associates the bid with a single quote chain. The bid records may also include a bid specification identifier that points to a particular bid specification record 504 describing the goods to which the bid pertains. The bid records may also include the bid price as well as a quote date and time stamp used to mark the time the bid was initially created. A quote status may also be included thereby allowing the status of a given bid to be modified. In a preferred embodiment, the quote status for a given bid may be either "active" or "hold". Active bids are those currently available for acceptance on the market. A hold status means the bid is currently not available for acceptance. A bid is placed on hold status in those instances where it is desirable to prevent it from being accepted but not to delete it entirely. For example, a bid can be put on hold to investigate the propriety of the bid where a dispute arises. Closely following the structure of the bid records 502, each of the offer records 503 includes, at a minimum, an offer identifier and a quote chain identifier. The offer identifier allows individual offers to be identified (e.g., when searches for particular types of offers are being performed) and the quote chain identifier associates the offer with a single quote chain. The offer records may also include an offer specification identifier that points to a particular offer specification record 505 describing the goods to which the offer pertains. The offer records may also include the offer price as well as a quote date and time stamp used to mark the time the offer was initially created. A quote status, serving the same purpose as in the bid records, may also be included in the offer records. As noted above, the bid specification records 504 and the offer specification records 505 describe the particular goods to which a bid or offer, respectively, pertains. The format of the bid specification records 504 and the offer specification records 505 depends upon the types of goods being traded. Preferred formats for the bid specification records 504 and the offer specification records 505, particularly suited for use in an exchange system dealing in event venue seats as commodities, are illustrated in FIG. 5. Each of the bid specification records 504 comprises, in addition to the bid specification identifier, fields identifying the particular event being bid upon, a quantity of seats being bid upon, and a particular region (i.e., a locale within which seats are deemed fungible) being bid upon. In a preferred embodiment, a bid may also specify a "maximum row" such that any seat in the maximum row or a better row (i.e., any row in the same region generally considered as providing more favorable seating) may be used to fulfill the bid. Thus, a maximum row indication may also be included in the bid specification records 504. Although not shown, it is also possible to include a field for specifying individual rows. The offer specification records 505 differ from the bid specification records 504 in two respects. First, an offer specification identifier is used. Second, only a row indication (as opposed to a maximum row indication) is provided because a seller can only describe the goods that he or she has to sell.
The offer tickets record 508 and the tickets record 509 provide a means for identifying the specific tickets, down to the particular seats, within a given offer. These records allow support personnel to quickly identify the exact tickets being offered in the event of, for example, a dispute over which party has the right to offer certain tickets for sale. Finally, the data structure may comprise accounts records 511, credit card records 512 and card type records 513. The account records 511 are uniquely associated with individual users of the exchange system. As shown, each account record comprises information needed to identify and contact individual users and financial information needed to charge customers that engage in transactions. A user name field is provided as a means for identifying users by a unique name. In a preferred embodiment, the user name for each user is an email address. Because users may have multiple accounts, separate credit card records 512 are provided in the event that a single credit card is used in conjunction with more than one account. The credit types records 513 identify the particular type of credit card used, e.g., Visa, American Express, etc. Although a specific type of data structure has been described with regard to FIG. 5, those having ordinary skill in the art will recognize that other data structures incorporating similar information and organization may be used and are a matter of design choice.
FIG. 6 illustrates a preferred data structure for the address data described above. The data structure, residing on a computer-readable medium, comprises various records useful in maintaining address information, such as billing and shipping addresses, for users of a commodity exchange system. The data structure comprises a postal addresses record 601 comprising a postal address identifier, street address fields, a city identifier and a zip code field, as know in the art. In turn, the postal addresses record 601 makes reference to a string of cities, states and countries records 602-604. The cities records 602 specify a city identifier for each particular city record, a state identifier corresponding to a particular city, and a name of the particular city. The states records 603 specify a state identifier for each particular state record, a country record corresponding to a particular state, a name of the particular state and an abbreviation of the particular state (such as the two letter postal abbreviations). The countries records 604 specify a country identifier for each particular country record and a name of a particular country. Finally, as shown, each of the cities, states and countries records 602-604 includes references to one or more cities, states and countries aliases records 606-608, respectively. The respective aliases records 606-608 include the identifier of the corresponding city, state or country and a name field of an alias for that particular city, state or country, e.g., New York city as the "Big Apple". FIG. 7 illustrates a preferred data structure for the events data described above. The data structure, residing on a computer-readable medium, comprises various records useful in maintaining events information, such as specific concert, theatrical and sporting events for use in a commodity exchange system. The data structure comprises events records 701 corresponding to individual events. An event identifier uniquely identifies each event using a numerical (and thereby more readily searchable) string, whereas an event code comprises a textual identifier for the event. An event category identifier identifies a particular class of events to which the event belongs, e.g., baseball game, football game, rock concert, opera performance, etc. The event date specifies the date on which a particular event is to take place and a seating plan identifier identifies a particular seating plan to be used for the event.
Each event record 701 refers to an event category record 702 comprising the event category identifier described above, a name associated with the event category and a parent category identifier, e.g., sports, concerts, theater, etc. In turn, each event category record 702 refers to one or more event category alias records 703 comprising, in addition to the event category identifier, an alias for that particular event category. Where an image is to be associated with a particular event category (for example, when displaying a list of the available event categories), each event category record 702 may also refer to one or more event category image records 704 comprising, in addition to the event category identifier, an image identifier for readily identifying and locating the required image. Likewise, each event category record 702 may also be associated with one or more performer event category records 705 that comprise a performer identification. Such performer identifications may be used as the basis for searches, for example, where a user wishes to see all available event for a given performer.
Each of the event records 701 refers to one or more event alias records 707 comprising alias information associated with the event. Any given event may be a part of a series of events, for example where a given music concert at a particular event venue on a particular date is part of a larger series of concerts in a national tour. In this case, the event record 701 may refer to a subordinate data structure comprising an event series record 709, event series event records 710 and event series alias records 711. The even series record 709 comprises an event series identifier and a name associated with the event series. Each event series event record 710, comprising the event and event series identifiers, provides a link between the individual event record 701 and the event series record 710. As with the other alias records, the event series alias records 711 set forth aliases for the event series.
Finally, each event record 701 refers to one or more event performers records 713 that associate the event identifier with a performer identifier and a performer role identifier. The particular type of data included in the performer identifier and a performer role identifier data fields depends on the type of event, i.e., an individual actor in a theater production versus a sports team in a sporting event. Where relevant, each event performers record 713 refers to a performer roles record 714 setting forth a name of a particular role. Additionally, where necessary, each event performers record 713 refers to a performer record 715 identifying a particular performer by name and alias through association with one or more performer alias records 716.
Referring now to FIG. 8, there is illustrated a preferred data structure for the venue data described above. The data structure, residing on a computer-readable medium, comprises various records useful in maintaining venue information corresponding to events in a commodity exchange system. The data structure comprises venue records 801 each corresponding to a unique venue and comprising a venue identifier, a name of the venue, and information identifying location of the venue including a street address, city identifier and a postal code. One or more venue alias records 802 are associated with each venue record 801.
A given venue may often be configured in different ways to accommodate various events therein, resulting in different seating plans depending on the event. As such, each venue record 801 refers to one or more seating plan records 803. Each seating plan record 803 comprising a seating plan identifier, a seating plan name identifier, the venue identifier, an image identifier and a nomenclature identifier. The image identifier uniquely identifies display data (such as bitmap files, JPEG files and the like) in an image record 812. Each image record 812 includes an image identifier, a name of the image and an image type identifier. Each image record 812, in turn, refers to an image type record 813 comprising the image type identifier and a name for the image type. The display data stored in this manner is suitable for causing a visual depiction of one or more areas to be rendered on a computer display. Generally, the areas thus represented include any locales receptive to the establishment of multiple commodity markets based in part upon spatially diverse regions. In an application where seats at event venues are treated as commodities, the areas depicted in the display data files comprise aerial views of seating information for the event venues identified in the event records 801. An example of a visual depiction 400 is illustrated in FIG. 4 where a sports stadium (in this example, Wrigley Field in Chicago, Illinois) is shown.
In order to commoditize seats within event venues, the present invention defines spatially diverse regions within areas. This is illustrated in FIG. 8 where each seating plan record 803 refers to one or more region records 804. Each region record 804 includes information defining the spatially diverse regions included within the area to be depicted. In particular, each region defines a portion of the area in which a given commodity may be regarded as fungible, and thus constitutes a separate commodity against which a market may be formed. In effect, regions are an overlay to an area that may otherwise comprise predefined sections, as is typically found in many event venues for example. To this end, each region record 804 comprises a region identifier identifying a particular region within an area, the seating plan identifier of the parent seating plan record, a color identifier for the region, a region name identifier and a region type identifier. Each region record 804 may refer to one or more section records 805 that identify predefined sections within a given region, each section record 805 comprising a section identifier, a section name, a seating area identifier and the region identifier of the parent region. Each region record 804 also refers to a region type record 805 that identifies the region's type by name, and to a region name record 807 that identifies the region's name.
The region records 804 may also support the use of color codes such that each region or separate groups of regions are represented by distinct colors. To this end, each region record 804 refers to a color record 808 comprising a color identifier and name. Thus, when incorporated into, or used to modify, display data for a given area or venue, the color records 808 cause the separate regions or groups of regions to be displayed in accordance with the assigned color. For example, the background, border or similar indicia of a given region or group of regions could be displayed using a corresponding color, which color is preferably distinct from an adjacent region or group of regions. Regardless, the region data included in the region records 804 and their progeny, when overlaying or incorporated into the display data, enables a visual depiction to be provided in which various spatially diverse markets are defined, thereby facilitating transactions through, for example, an on-line exchange-driven system. Referring again to the stadium example illustrated in FIG. 4, a plurality of such regions
402-454 is illustrated. Table 1 below describes each of the regions shown in FIG. 4 by region names according to corresponding reference numerals.
Description Region (by ref. numeral)
Club Boxes Left Field 402
Club Boxes Third Base 404
Club Boxes First Base 406
Club Boxes Right Field 408
Field Boxes Left Field 410
Field Boxes Third Base 412
Field Boxes First Base 414
Field Boxes Right Field 416
Super Suites Left Field 418
Mezzanine Suites Left Field 420
Mezzanine Suites Right Field 422
Super Suites Right Field 424
Terrace Boxes Left Field 426
Terrace Boxes Third Base 428
Terrace Boxes First Base 430
Terrace Boxes Right Field 432
Upper Deck Boxes Left Field 434
Upper Deck Boxes Third Base 436
Upper Deck Boxes First Base 438
Upper Deck Boxes Right Field 440
Upper Deck Left Field 442
Upper Deck Third Base 444
Upper Deck First Base 446
Upper Deck Right Field 448
Family 450
Bleachers 452
Group 454
Table 1.
Referring again to FIG. 8, each seating plan record 803 refers to one or more seating area records 809 each comprising a reference to the seating plan identifier of the parent record, a seating area identifier and seating area name identifier. The seating area name identifier is used to identify a seating area names record 810 comprising the name of the particular seating area. The seating area identifiers are used to associate each seating area record 809 with one or more sections records 805. In this manner, each seating area within a given seating plan may be completely specified.
Finally, each seating plan record 803 refers to a seating plan name record 815 comprising a name for the parent seating plan, and to a nomenclature record 817. The nomenclature records 817 are used to store names relevant to describing a given venue's seating plan. For example, what some even venues would refer to as a section may be termed an aisle in a different event venue. In order to ensure that a system user is provided with the correct terminology, the nomenclature records 817 may be referenced when presenting seating plan information.
It should be noted that the name data included in any of the records 801-817 may be used as textual data to differentiate each of the regions. Thus, the textual data may be used in place of, or as a supplement to, the visual depictions described above in order to describe each of the regions. Where a color coding scheme (as described above) is employed, the textual descriptions may also be displayed in accordance with the color coding scheme. That is, suitable background colors, border colors, font colors or other indicia reflective of the color coding scheme may be used, thereby reinforcing the correlation between the regions displayed in a visual depiction and their corresponding textual descriptions.
FIG. 9 illustrates a preferred data structure for trade data used to track and memorialize specific trades that have occurred through the commodity exchange system. A trade is a sale of a commodity by a seller to a buyer effectuated through the commodity exchange system described herein. To support such trades, the data structure comprises a trade record 901 with one more references to trade ticket records 902. Each trade record 901 comprises a trade identifier that uniquely identifies each trade made within the commodity exchange system. Also included are a price field and a quantity field. In the context of seats within event venues, the quantity field comprises a number of seats (tickets) being purchased and the price field reflects the per seat price agreed to by the parties. A buyer account identifier and a seller account identifier uniquely identify account records of the buyer and seller, respectively. A trade date field comprises a date and time when agreement was reached between the parties to enter into the trade. Finally, each trade record 901 includes a reference code which is used as an internal identifier for purposes of database and system management. The trade tickets records 902 afford a means for quickly identifying the specific tickets associated with a given trade. This is accomplished through the inclusion of a ticket identifier field that refers to a tickets record 509.
The data structures described above relative to FIGS. 5-9 provide a basis upon which a commodity exchange system may be implemented. However, for a commodity exchange system to actually work, users must be able to ascertain the current state of markets and have the ability to enter their quotes into such markets. To this end, the present invention provides market information and allows users to enter quotes in light of such market information. This is illustrated in FIGS. 10-14.
Referring now to FIG. 10, a market information display 1000 for particular use in obtaining offers is illustrated. The displays illustrated in FIGS. 10-14 are exemplary of displays that would be provided on the computers of users of a commodity exchange system directed to the trade of seats within event venues. It should be noted that techniques for obtaining the data included in the displays shown in FIGS. 10-14 from databases and data structures, such as those described above, are well known in the art. The display 1000 is provided to a user that has chosen a particular event and desires to make an offer of tickets to sell. As described above, seats are treated as commodities based on regions in which they are located. Thus, any given region within an event venue for a given event is a suitable basis for establishing a separate market. However, the present invention also provides for further market creation by accommodating the creation of markets within a given region by virtue of the number of units of the commodity being traded. These quantity-differentiated markets may then operate independent of each other. To this end, the display 1000 comprises a market selection region 1002 comprising quantity- based market descriptors 1003 and quantity-based market selectors 1004. A potential seller, after having established an account with the exchange system and after having selected a particular event for which he or she has tickets to sell, may select the particular quantity-differentiated market they wish to enter by selecting one of the quantity-based market selectors 1004. As default, the system may initially provide the 1 Ticket market and allow the potential seller to decide which markets they wish to enter. Should the potential seller possess a number of tickets greater than the largest quantity-differentiated market displayed, the user may enter a desired quantity in an other quantity data field 1006 and, having activated a selection button 1007, be provided with market information for the desired quantity. Regardless, once a particular quantity-differentiated market has been selected, market information 1009 is provided. In the example of FIG. 10, market information 1009 for a 2 Tickets market is displayed.
As shown, the market information 1009 provided comprises listings for each region in the quantity-differentiated market for which quotes have been received. As described in greater detail below, markets may be further differentiated according to the rows for given seats within a region. In the example shown in FIG. 10, the sole market displayed is for seats in any row in the 'A' region. Also shown are the current highest bid and lowest offer (on a per ticket basis) for that market, in this case $100 and $120, respectively. If desired, the potential seller may enter an offer into an offer field 1010. To complete an offer, the potential seller must fill in data in the offer specification fields 1015-1019 describing the particulars of the offer. To this end, seating area, section, row and seat number information must be entered to specifically identify the tickets being sold. Furthermore, an offer expiration date can be entered. Although various types of pull down menus and data fields are illustrated for these purposes, those having ordinary skill in the art will recognize that a variety of data collection mechanisms may be used. If a mistake is made completing the offer specification fields 1015-1019, or if the user changes his or her mind and wishes to remove an outstanding bid, they may select the cancel button 1024. Once an offer covering specific tickets has been entered, the exchange system ascertains the correct region encompassing the tickets being offered. If, by user error, the market information 1009 being displayed does not correspond to the region identified as encompassing the offered tickets, an error message is provided an the appropriate market information is provided.
Once the offer specification fields 1015-1019 have been completed, the potential seller may elect to submit the offer, including the completed offer field 1010, by selecting a submit button 1022. This will result in quote chain records, as described above relative to FIG. 5 and particularly comprising an offer record 503 , being created for that user' s account. The offer thus created is then available to be used by the exchange system to create and display recalculated market data as needed. As an alternative to submitting an offer, the potential seller, after having completed the offer specification fields 1015-1019 may simply decided that he or she is willing to sell the tickets at the current best bid price. In this case, they may select a sell button 1011 thereby automatically registering their acceptance of that bid. In response, appropriate trade records like those described above relative to FIG. 9 are created. Further still, the exchange controller may cause notification regarding the trade to be sent to personnel in the exchange office 110 and/or to a carrier 112 such that appropriate processes to fulfill the trade (i.e., obtain and validate the tickets from the seller and provide them to the buyer, obtain payment from the buyer and provide it to the seller) may be initiated. Referring now to FIG. 11, a market information display 1100 for particular use in obtaining bids is illustrated. The display 1100 is provided to a user that has chosen a particular event and desires to make a bid to buy tickets. A market selection region 1 102, functionally identical to the market selection region 1002 described above, is provided. Likewise, market information regarding particular markets is also provided. As with the offer display 1000, the market information provided in the bid display 1100 comprises listings for different regions and rows, as well as the highest bid and lowest offers for each of these markets. As noted above, each seat within a given region is considered equivalent to any other seat within that same region for the purposes of establishing a commodity market. The present invention provides an exception to this, in the case of venue seats as commodities, to the extent that each row within a given block, if that entire block may be so subdivided, may be considered "sub-markets" within the given region' s market. Thus, markets can be established for particular rows or ranges of rows within a given region. In a preferred embodiment, a bid may also specify a "maximum row" such that any seat in the maximum row or a better row (i.e., any row in the same region generally considered as providing more favorable seating) may be used to fulfill the bid. This is illustrated in FIG. 1 1 where separate markets for row 1 alone, rows 1 -5 or any row within the 'A' region are shown.
Bids may be entered using the bid fields 1110 against one or more particular markets. If desired, the potential buyer may decide to cancel outstanding bids using the cancel button 1124 or, after entering an expiration date 1119 for the bids, the user may select the submit button 1122 to enter their bids. This will result in quote chain records, as described above relative to FIG. 5 and particularly comprising a bid record 502, being created for that user's account. The bid thus created is then available to be used by the exchange system to create and display recalculated market data as needed. As an alternative to submitting a bid, the potential buyer may simply decided that he or she is willing to buy tickets at the current best offer price. In this case, they may select a buy button 1111 thereby automatically registering their acceptance of that offer. As a result, the appropriate trade records like those described above relative to FIG. 9 are created. As with the acceptance of a bid, acceptance of an offer in this manner will cause the necessary fulfillment activities to be initiated. As described above, both the offer and bid display screens 1000, 1100 display market information relevant to the potential market participant's desired course of action. The present invention also provides market information for those users who have not yet decided to take a position in a given market or who have taken a position and wish to see a more complete representation of the market, as further described with reference to FIGS. 12-14.
FIG. 12 illustrates a complete market display 1200 in which both the bid and offer sides of markets are displayed. The display 1200 is provided to a user that has chosen a particular event and is either deciding whether to take a position in a given market, or who has already taken a position and wishes to see a more complete market representation. A market selection region 1202, functionally identical to the market selection regions 1002, 1102 described above, is provided. Likewise, market information regarding particular markets is also provided. As with the offer and bid displays 1000, 1100, the market information provided in the complete market display 1200 comprises listings for different regions and rows, as well as the highest bid and lowest offers for each of these markets. However, the complete market display also includes, for each market displayed, a number of buyers currently having outstanding bids and a number of sellers currently having outstanding offers. In this manner, the complete market display provides a user with a greater sense of the depth of each market.
Having viewed the market information, users may choose to enter new bids or offers, or change existing bids/offers, in selected markets using the bid and offer fields 1210, 121 1 provided. Where a user has not previously entered a bid or offer, they may enter their bid or offer in the appropriate field 1210, 1211 and select a post bid or offer button 1213, 1215. Alternatively, where the user has previously entered a bid or offer, that bid or offer will already be displayed in the appropriated bid or offer field 1210, 1211. However, the user can change any such bid or offer and select the change bid or offer button 1212, 1216. Regardless, selection of the change or post bid buttons 1212, 1213 will cause the bid display 1100 to be provided to the user, whereas selection of the change or post offer buttons 1216, 1215 will cause the offer display 1000 to be provided to the user. If, however, a user decides that he or she wants to cancel all of his or her bid and/or offers, he or she may select either or both of the cancel all bids button 1222 and the cancel all offers button 1224. In yet another alternative, after viewing the market information, the user may select buy or sell buttons 1214, 1217 for a particular market and immediately enter into a transaction. Where the user selects a sell button, they are first required to enter the necessary offer specification information 1015-1019 described above. In addition to the complete market display 1200, a user may select a market detail market display using any one of the details links 1218, in which case they are provided with a market detail display 1300. Conversely, a less detailed market summary may be selected using a summary link 1220, in which case a market summary display 1400 is provided. The market detail display 1300 comprises similar information as the complete market display 1200, including bid and offer fields, as well as post/change bid, post/change offer, buy, sell and cancel buttons, as described above. However, the market detail display 1300 further breaks down, for each market within a given quantity-differentiated market, the existing offers and bids and the number of market participants for each. This is illustrated in FIG. 13, where, for any given market, the N highest bids and the M lowest offers are displayed, where N is not necessarily equal to M. It is understood that various constraints may be placed on the values of N and M (e.g., they must always be equal and should be no greater than the smaller of the two) and is a matter of design choice. As an example, the market for tickets in region 'A', any row is shown at the top of FIG. 13. In the example shown, the current best bid is $95/ticket with only one buyer at that price. However, there are 5 buyers at $93/ticket, 3 buyers at $90/ticket and 8 buyers at $85/ticket. Note that the parenthetically enclosed numbers next to a number of buyers indicates the ranking, relative to the other bids at that price, at which the current user's bid will be fulfilled. Thus, the parenthetical ' 1 ' next to the current user'sbid at $90/ticket fortheregion 'A', any row market indicates that the user's bid at this price will be the first to be fulfilled if accepted by a seller. Alternatively, the user's bid at $25/ticket for the region 'C, any row market will be the sixth to be fulfilled if accepted by sellers. A similar convention may be applied to offers.
Continuing with the example of the region 'A', any row market, the best offer is currently at $99/ticket with only one seller at that price. However, there are 4 sellers at $105/ticket and 3 sellers at $115/ticket. For any given market in the market detail display 1300, an ideal market price (the price at which buyers and seller would ideally always agree to a trade) may be represented by an imaginary horizontal line (none shown). In order to emphasize the current depth and spread of the market, the outstanding bids for that market are shown in descending order below the imaginary horizontal line, whereas the outstanding offers for that market are shown in ascending order above the imaginary horizontal line. In this manner, a market participant or an interested non-participant may readily gauge the depth and spread of a given market.
Furthermore, color coding may be incorporated into the market detail display 1300. The dotted boxes 1301 -1304 surrounding the detailed market information for each market represent this. In this manner, the information included in the color records 808 for a given region may be reflected in the market detail display 1300, or any of the other market displays discussed herein.
Finally, in FIG. 14, a market summary display 1400 is illustrated. In this display, all of the quantity-differentiated markets 1404 for a given event are listed, with the current best bids and offers corresponding to each available region 1402 shown in tabular form. The significant difference between the market summary display 1400 and the previous displays 1000, 1100, 1200, 1300 is that no mechanisms exist for a user to enter a competing bid or offer. In this manner, a user may obtain a quick overview of each market for a given event, thereby allowing them to better gauge the individual markets and decide whether they wish to enter, or remain in, any markets at all.
The present invention provides a technique for implementing trades and establishing markets for commodities, particularly when applied to an on-line exchange system. To this end, market information is provided for a variety of markets including, preferably, a variety of quantity-differentiated markets. The present invention can be used in conjunction with markets for non-traditional commodities, such as seats within event venues. In that context, markets may be further defined according to rows in which the seats are located. Market displays include mechanisms that allow user to enter, change or cancel quotes in various markets. When implemented using a publicly available communication network, such as the Internet or World Wide Web, the present invention may be advantageously used to implement a commodity exchange system. However, what has been described is merely illustrative of the application of the principles of the present invention. Other arrangements and methods can be implemented by those skilled in the art without departing from the spirit and scope of the present invention.

Claims

Claims
What is claimed is: 1. In a commodity exchange system, a method for implementing trades, the method comprising steps of: providing market information for a commodity comprising at least one seat in an event venue; and receiving at least one of a quote acceptance and a quote proposal responsive to the market information.
2. The method of claim 1 , wherein the commodity exchange system comprises a plurality of computers in communication with each other via a communication network, and wherein the step of providing the market information further comprises providing the market information to any of the plurality of computers via the communication network.
3. The method of claim 2, wherein the step of receiving further comprises receiving the at least one of the quote acceptance and the quote proposal from any of the plurality of computers via the communication network.
4. The method of claim 1 , wherein the commodity is defined by date of an event within the event venue.
5. The method of claim 1 , wherein the commodity is defined by a number of seats in the event venue.
6. The method of claim 1 , wherein the commodity is defined by a region within the event venue, the region encompassing the at least one seat.
7. The method of claim 6, wherein the commodity is defined by a row specification within the region.
8. The method of claim 1 , wherein the step of providing the market information further comprises providing at least one of a highest bid indication and a lowest offer indication.
9. The method of claim 8, wherein the step of providing the market information further comprises providing at least one of an indication of a number of buyers and an indication of a number of sellers.
10. The method of claim 1 , wherein the step of providing the market information further comprises providing information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers.
11. The method of claim 1 , further comprising a step of: determining recalculated market information based upon the quote acceptance or the quote proposal; and providing the recalculated market information.
12. In a commodity exchange system, a method for establishing markets, the method comprising steps of: defining quantity-differentiated markets for a commodity, each of the quantity- differentiated markets based on a unique number of units of the commodity to be traded; and providing market information for at least one of the quantity-differentiated markets.
13. The method of claim 12, further comprising a step of: receiving at least one of a quote acceptance and a quote proposal responsive to the market information.
14. The method of claim 12, wherein the commodity exchange system comprises a plurality of computers in communication with each other via a communication network, and wherein the step of providing the market information further comprises providing the market information to any of the plurality of computers via the communication network.
15. The method of claim 14, further comprising a step of: receiving at least one of a quote acceptance and a quote proposal from any of the plurality of computers via the communication network.
16. The method of claim 12, wherein the commodity comprises at least one seat within an event venue.
17. The method of claim 16, wherein the commodity is defined by date of an event within the event venue.
18. The method of claim 16, wherein the commodity is defined by a region within the event venue, the region encompassing the at least one seat.
19. The method of claim 18, wherein the commodity is defined by a row specification within the region.
20. The method of claim 12, wherein the step of providing the market information further comprises providing at least one of a highest bid indication and a lowest offer indication for the at least one of the quantity-differentiated markets.
21. The method of claim 20, wherein the step of providing the market information further comprises providing at least one of an indication of a number of buyers and an indication of a number of sellers for the at least one of the quantity-differentiated markets.
22. The method of claim 12, wherein the step of providing the market information further comprises providing information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers for the at least one of the quantity-differentiated markets.
23. An apparatus for use in a commodity exchange system, the apparatus comprising: means for providing market information for a commodity comprising at least one seat in an event venue; and means for receiving at least one of a quote acceptance and a quote proposal responsive to the market information.
24. The apparatus of claim 23, wherein the commodity exchange system comprises a plurality of computers in communication with each other via a communication network, and wherein the means for providing the market information further comprises means for providing the market information to any of the plurality of computers via the communication network.
25. The apparatus of claim 24, wherein the means for receiving further comprises means for receiving the at least one of the quote acceptance and the quote proposal from any of the plurality of computers via the communication network.
26. The apparatus of claim 23 , wherein the commodity is defined by date of an event within the event venue.
27. The apparatus of claim 23, wherein the commodity is defined by a number of seats in the event venue.
28. The apparatus of claim 23, wherein the commodity is defined by a region within the event venue, the region encompassing the at least one seat.
29. The apparatus of claim 28, wherein the commodity is defined by a row specification within the region.
30. The apparatus of claim 23, wherein the means for providing the market information further comprises means for providing at least one of a highest bid indication and a lowest offer indication.
31. The method of claim 30, wherein the means for providing the market information further comprises means for providing at least one of an indication of a number of buyers and an indication of a number of sellers.
32. The method of claim 23, wherein the means for providing the market information further comprises means for providing information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers.
33. The apparatus of claim 23, further comprising: means for determining recalculated market information based upon the quote acceptance or the quote proposal; wherein the means for providing further function to provide the recalculated market information.
34. An apparatus for use in a commodity exchange system, the apparatus comprising: means for storing data defining quantity-differentiated markets for a commodity, each of the quantity-differentiated markets based on a number of units of the commodity to be traded; and means for providing market information for at least one of the quantity-differentiated markets.
35. The apparatus of claim 34, further comprising: means for receiving at least one of a quote acceptance and a quote proposal responsive to the market information.
36. The apparatus of claim 34, wherein the commodity exchange system comprises a plurality of computers in communication with each other via a communication network, and wherein the means for providing the market information further comprises means for providing the market information to any of the plurality of computers via the communication network.
37. The apparatus of claim 36, further comprising: means for receiving at least one of a quote acceptance and a quote proposal from any of the plurality of computers via the communication network.
38. The apparatus of claim 34, wherein the commodity comprises at least one seat within an event venue.
39. The apparatus of claim 38, wherein the commodity is defined by date of an event within the event venue.
40. The apparatus of claim 38, wherein the commodity is defined by a region within the event venue, the region encompassing the at least one seat.
41. The apparatus of claim 40, wherein the commodity is defined by a row specification within the region.
42. The apparatus of claim 34, wherein the means for providing the market information further comprises means for providing at least one of a highest bid indication and a lowest offer indication for the at least one of the quantity-differentiated markets.
43. The apparatus of claim 42, wherein the means for providing the market information further comprises means for providing at least one of an indication of a number of buyers and an indication of a number of sellers for the at least one of the quantity-differentiated markets.
44. The method of claim 34, wherein the means for providing the market information further comprises means for providing information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers for the at least one of the quantity-differentiated markets.
45. A computer-readable medium having stored thereon a data structure comprising: a plurality of quote records corresponding to users of a commodity exchange system, wherein each quote record of the plurality of quote records corresponds to a commodity of a plurality of commodities, each commodity comprising at least one seat in at least one event venue.
46. The computer-readable medium of claim 45, wherein the data structure forms at least a part of a web page resident on a server.
47. The computer-readable medium of claim 46, wherein the data structure further comprises: market information display files used to display market information derived from the plurality of quote records.
48. The computer-readable medium of claim 47, wherein the market information display files function to display at least one of a highest bid indication and a lowest offer indication.
49. The computer-readable medium of claim 48, wherein the market information display files function to display at least one of an indication of a number of buyers and an indication of a number of sellers.
50. The computer-readable medium of claim 47, wherein the market information display files function to display information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers.
51. A computer-readable medium having stored thereon a data structure comprising: records defining a plurality of quantity-differentiated markets for a commodity, each of the plurality of quantity-differentiated markets based on a number of units of the commodity to be traded; and a plurality of quote records corresponding to users, wherein each quote record of the plurality of quote records corresponds to a quantity- differentiated market of the plurality of quantity-differentiated markets.
52. The computer-readable medium of claim 51 , wherein the data structure forms at least a part of a web page resident on a server.
53. The computer-readable medium of claim 52, wherein the data structure further comprises: market information display files used to display market information derived from the plurality of quote records.
54. The computer-readable medium of claim 53, wherein the market information display files function to display at least one of a highest bid indication and a lowest offer indication for at least one of the plurality of quantity-differentiated markets.
55. The computer-readable medium of claim 54, wherein the market information display files function to display at least one of an indication of a number of buyers and an indication of a number of sellers for at least one of the plurality of quantity-differentiated markets.
56. The computer-readable medium of claim 53, wherein the market information display files function to display information regarding N highest bids, a number of buyers at each of the N highest bids, information regarding M lowest offers and a number of buyers at each of the M lowest offers for at least one of the plurality of quantity-differentiated markets.
PCT/US2000/042431 1999-12-02 2000-12-01 Automated event ticket auctioning system WO2001041084A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU43074/01A AU4307401A (en) 1999-12-02 2000-12-01 Method and apparatus for use in a commodity exchange system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US45286499A 1999-12-02 1999-12-02
US09/452,864 1999-12-02

Publications (2)

Publication Number Publication Date
WO2001041084A2 true WO2001041084A2 (en) 2001-06-07
WO2001041084A3 WO2001041084A3 (en) 2002-05-02

Family

ID=23798267

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/042431 WO2001041084A2 (en) 1999-12-02 2000-12-01 Automated event ticket auctioning system

Country Status (2)

Country Link
AU (1) AU4307401A (en)
WO (1) WO2001041084A2 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004081826A1 (en) * 2003-03-10 2004-09-23 Graincom Pty Ltd Commodities exchange system and method
AU2004219547B2 (en) * 2003-03-10 2005-06-30 Graincom Pty Ltd Commodities exchange system and method
US7574375B1 (en) 1999-09-28 2009-08-11 Cfph, L.L.C. Systems and methods for transferring items with restricted transferability
US9978096B2 (en) 2006-10-25 2018-05-22 Stubhub, Inc Method and system for illustrating where a ticket is located in an event venue
US10885474B2 (en) 2006-10-25 2021-01-05 Paypal, Inc. System and methods for third-party access to a network-based system for providing location-based upcoming event information
US11035682B2 (en) 2016-09-15 2021-06-15 Simpsx Technologies Llc Navigation routes as community object virtual hub sequences to which users may subscribe
US11138661B2 (en) 2016-09-15 2021-10-05 Simpsx Technologies Llc Agriculture community objects with price-time priority queues for transformed agriculture units
US11138827B2 (en) 2016-09-15 2021-10-05 Simpsx Technologies Llc Implementations of a computerized business transaction exchange for various users
US11157852B2 (en) 2016-09-15 2021-10-26 Simpsx Technologies Llc Tool appliance community objects with price-time priority queues for transformed tool appliance units
US11215466B2 (en) 2016-09-15 2022-01-04 Circlesx Llc Route community objects with price-time priority queues for transformed transportation units
US11295244B2 (en) 2006-10-25 2022-04-05 Stubhub, Inc. System and methods for mapping price and location of tickets in an event venue
US11500526B2 (en) 2017-01-13 2022-11-15 Circlesx Llc Computer ball device for mixed reality, virtual reality, or augmented reality
US11740777B2 (en) 2016-09-15 2023-08-29 Circlesx Llc Multi-dimension information service helmet method and system
US11741112B2 (en) 2017-06-29 2023-08-29 Ebay Inc. Identification of intent and non-intent query portions
US11790382B2 (en) 2016-09-15 2023-10-17 Circlesx Llc Method to transmit geolocation exchange based markets
US11810023B2 (en) 2018-10-22 2023-11-07 Circlesx Llc System and method for a transportation or freight capacity exchange for one or more transportation or freight capacity units
US11823090B2 (en) 2016-09-15 2023-11-21 Circlesx Llc Transportation and freight and parking and tolling and curb capacity unit IPO method and system
US11836791B2 (en) 2016-09-15 2023-12-05 Circlesx Llc Securitization of transportation units
US11861527B2 (en) 2018-11-07 2024-01-02 Circlesx Llc Financial swap payment structure method and system on transportation capacity unit assets
US11880883B2 (en) 2016-09-15 2024-01-23 Circlesx Llc Systems and methods for geolocation portfolio exchanges
US11907870B2 (en) 2018-01-23 2024-02-20 Circlesx Llc Market exchange for transportation capacity in transportation vehicles

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023685A (en) * 1996-05-23 2000-02-08 Brett; Kenton F. Computer controlled event ticket auctioning system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023685A (en) * 1996-05-23 2000-02-08 Brett; Kenton F. Computer controlled event ticket auctioning system

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7574375B1 (en) 1999-09-28 2009-08-11 Cfph, L.L.C. Systems and methods for transferring items with restricted transferability
US8527356B2 (en) 1999-09-28 2013-09-03 Cfph, Llc Systems and methods for transferring items with restricted transferability
US8645218B2 (en) 1999-09-28 2014-02-04 Cfph, Llc Transferring a ticket
US8645219B2 (en) 1999-09-28 2014-02-04 Cfph, Llc Authorization system and method
US8655735B2 (en) 1999-09-28 2014-02-18 Cfph, Llc Transferring an item
WO2004081826A1 (en) * 2003-03-10 2004-09-23 Graincom Pty Ltd Commodities exchange system and method
AU2004219547B2 (en) * 2003-03-10 2005-06-30 Graincom Pty Ltd Commodities exchange system and method
US11282001B2 (en) 2006-10-25 2022-03-22 Stubhub, Inc. Method and system for illustrating where a ticket is located in an event venue
US10885474B2 (en) 2006-10-25 2021-01-05 Paypal, Inc. System and methods for third-party access to a network-based system for providing location-based upcoming event information
US11593720B2 (en) 2006-10-25 2023-02-28 Paypal, Inc. System and methods for third-party access to a network-based system for providing location-based upcoming event information
US11295244B2 (en) 2006-10-25 2022-04-05 Stubhub, Inc. System and methods for mapping price and location of tickets in an event venue
US9978096B2 (en) 2006-10-25 2018-05-22 Stubhub, Inc Method and system for illustrating where a ticket is located in an event venue
US11215466B2 (en) 2016-09-15 2022-01-04 Circlesx Llc Route community objects with price-time priority queues for transformed transportation units
US11790382B2 (en) 2016-09-15 2023-10-17 Circlesx Llc Method to transmit geolocation exchange based markets
US11138827B2 (en) 2016-09-15 2021-10-05 Simpsx Technologies Llc Implementations of a computerized business transaction exchange for various users
US11138661B2 (en) 2016-09-15 2021-10-05 Simpsx Technologies Llc Agriculture community objects with price-time priority queues for transformed agriculture units
US11880883B2 (en) 2016-09-15 2024-01-23 Circlesx Llc Systems and methods for geolocation portfolio exchanges
US11555709B2 (en) 2016-09-15 2023-01-17 Circlesx Llc Financial swap index method and system on transportation capacity units and trading derivative products based thereon
US11035682B2 (en) 2016-09-15 2021-06-15 Simpsx Technologies Llc Navigation routes as community object virtual hub sequences to which users may subscribe
US11740777B2 (en) 2016-09-15 2023-08-29 Circlesx Llc Multi-dimension information service helmet method and system
US11836791B2 (en) 2016-09-15 2023-12-05 Circlesx Llc Securitization of transportation units
US11157852B2 (en) 2016-09-15 2021-10-26 Simpsx Technologies Llc Tool appliance community objects with price-time priority queues for transformed tool appliance units
US11823090B2 (en) 2016-09-15 2023-11-21 Circlesx Llc Transportation and freight and parking and tolling and curb capacity unit IPO method and system
US11829594B2 (en) 2017-01-13 2023-11-28 Circlesx Llc Computer ball device for mixed reality, virtual reality, or augmented reality
US11500526B2 (en) 2017-01-13 2022-11-15 Circlesx Llc Computer ball device for mixed reality, virtual reality, or augmented reality
US11741112B2 (en) 2017-06-29 2023-08-29 Ebay Inc. Identification of intent and non-intent query portions
US11907870B2 (en) 2018-01-23 2024-02-20 Circlesx Llc Market exchange for transportation capacity in transportation vehicles
US11810023B2 (en) 2018-10-22 2023-11-07 Circlesx Llc System and method for a transportation or freight capacity exchange for one or more transportation or freight capacity units
US11907869B2 (en) 2018-10-22 2024-02-20 Circlesx Llc System and method for a transportation or freight capacity exchange for one or more transportation or freight capacity units
US11861527B2 (en) 2018-11-07 2024-01-02 Circlesx Llc Financial swap payment structure method and system on transportation capacity unit assets

Also Published As

Publication number Publication date
AU4307401A (en) 2001-06-12
WO2001041084A3 (en) 2002-05-02

Similar Documents

Publication Publication Date Title
WO2001041084A2 (en) Automated event ticket auctioning system
US6647373B1 (en) Method and system for processing and transmitting electronic reverse auction information
US5915209A (en) Bond trading system
US8554661B2 (en) Methods and systems for retrieving data stored in a database
US6131087A (en) Method for automatically identifying, matching, and near-matching buyers and sellers in electronic market transactions
WO2001044892A2 (en) Method and apparatus for establishing commodity markets
US20010034687A1 (en) Service contracts and commodities market for trading service contracts
US20020052758A1 (en) Method and apparatus for providing rights for event tickets
US20020116314A1 (en) Method of using a computerised trading system to process trades in financial instruments
US20030236736A1 (en) Electronic system and method for trading seat licenses, event tickets and contingent event ticket certificates
US20080270321A1 (en) System and method for real-time options trading over a computer network
US20040039696A1 (en) System and method for executing a payment transaction over a computer network
US20090048962A1 (en) Interactive Security Brokerage System
US8538847B2 (en) Method for investing working capital
WO2001041085A2 (en) Method and apparatus for processing quotes in a commodity exchange system
US10529019B2 (en) Trading platform with automated negotiation and option crossing
US8588729B2 (en) Method for retrieving data stored in a database
KR20020004086A (en) A method for competed brokerage service link system on the internet by reverse auction
JP2001306876A (en) Auction system using network and method of the system
WO2002001316A2 (en) Network system for handling request for proposal relating to the selection of an investment advisor by an institutional investor

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG 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