WO2001041085A2

WO2001041085A2 - Method and apparatus for processing quotes in a commodity exchange system

Info

Publication number: WO2001041085A2
Application number: PCT/US2000/042432
Authority: WO
Inventors: Arthur Roland Bushonville; Norbert Peter Schenk; Mark Rosenfeld; Adam Christopher Swift
Original assignee: Ultimate Markets, Inc.
Priority date: 1999-12-02
Filing date: 2000-12-01
Publication date: 2001-06-07
Also published as: AU4307501A; WO2001041085A3

Abstract

Quotes received from a user of an exchange system are linked together to provide a quote chain, preferably by associating each of the quotes with a quote chain identifier (501). Each quote of the quote chain comprises a bid or offer directed to at least one seat within at least one event venue. Acceptance of any one of the quotes in the quote chain causes the remaining unaccepted quotes to be inactivated. Prior to acceptance of any one of the quotes in the quote chain, the user may request to have any one or more of the quotes in the quote chain unlinked from the quote chain. The processing necessary to implement such quote chains is preferably carried out at a centrally located exchange controller (106) coupled to various users through a computer communications network (104).

Description

METHOD AND APPARATUS FOR PROCESSING QUOTES 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 processing quotes in a commodity exchange system by linking quotes.

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. One type of order supported in prior art exchanges, particularly futures exchanges, is the so-called OCO ("one cancels the other" or "order cancels order") order. An OCO order involves the entry of two separate orders or quotes, i.e., bids to buy and/or offers to sell, associated with each other. If one order is filled, the other is automatically cancelled. Thus, an OCO order is an order in which each component order is conditioned on the possible fulfillment of the other. 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. Of course, because these systems do not function as true commodity markets, buyers and sellers do not have the capability of specifying conditional quotes analogous to OCO orders.

Thus, it would be advantageous to provide novel techniques for processing quotes 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. Such techniques should preferably incorporate the ability to conditionally link quotes together.

Summary Of The Invention

The present invention provides a technique for processing quotes in a commodity exchange system dealing particularly in markets for seats within event venues. Quotes received from a user are linked together to provide a quote chain, preferably by associating each of the quotes with a quote chain identifier. Each quote of the quote chain comprises a bid or offer directed to at least one seat within at least one event venue. The quotes may be linked in response to a request from the user. Regardless, acceptance of any one of the quotes in the quote chain causes the remaining unaccepted quotes to be inactivated. Prior to acceptance of any one of the quotes in the quote chain, the user may request to have any one or more of the quotes in the quote chain unlinked from the quote chain such that the one or more unlinked quotes will not be inactivated should any one of the linked quotes be accepted. Data structures supporting such functionality are also disclosed. The processing necessary to implement such quote chains is preferably carried out at a centrally-located exchange controller coupled to various users through a computer communications network. In this manner, the present invention provides greater flexibility to market participants.

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 is a flow chart illustrating a method in accordance with the present invention.

Detailed Description Of The Invention

The present invention may be more fully described with reference to FIGS. 1-10. FIG. 1 illustrates a computer system 100 comprising a plurality of computers 102 in 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 comprise or include a private 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 verifying 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 110, 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 carrier 112 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 price or in which a seller agreed to a buyer's bid price) from the exchange controller 106 and forwards any information necessary for a carrier 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 provided 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 corresponding 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. 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). 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 110 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.

Referring now to FIG. 10, a method for processing quotes is illustrated. The method illustrated in FIG. 10 is preferably implemented by an exchange controller, as described above. At step 1001 , one or more quotes are received from a given user. A quote is a bid to purchase or an offer to sell a given commodity, preferably concerning one or more seats within one or more event venues. A method for establishing commodity markets, particularly in the context of event venue seats, is disclosed in co-pending application attorney docket no. 4783.82407 entitled METHOD AND APPARATUS FOR ESTABLISHING COMMODITY MARKETS. Regardless of the type of market against which the quotes are provided, each quote provided by the user is categorized under a single user account. It is understood that a single user can have more than one trading account with a commodity exchange and, in such a case, the user is required to specify to which accounts a given quote pertains.

At step 1002, the user is optionally queried whether any quotes received from that user are to be linked together. To this end, and referring again to FIG. 1 , the user can be presented with, for example, a table listing information for each quote currently outstanding (i.e., unfulfilled) in the user's account. The table is conveyed to the user via the communication network 104 and displayed on the user's computer 102. If the user wishes to link two or more quotes, selections are made of which quotes are to be linked together and the resulting selection information is provided to the exchange controller 106 in the form of a request, at step 1003, to link the selected quotes together. It is understood that such a request does not necessarily have to be prompted by a query from the exchange controller 106. For example, the user could specify at the outset of a session with the controller, without prior prompting from the controller, that all subsequent quotes received during that session are to be linked together. In yet another alternative, all quotes from the user may be automatically linked together. In this event, no query or link request in needed.

Regardless of the manner in which designations are made to link specific quotes together, the desired quotes are linked together at step 1004 resulting in a quote chain. In order to ensure the conditional nature of each quote included in the quote chain, the quote chain is treated as a single entity. Where each quote is represented as a record stored in a database, this unity of the quote chain can be achieved by providing a link (i.e., a pointer) between each of the records included in the quote chain. Thus, the existence of the quote chain would arise by virtue of a quote record pointing to at least one other quote record. Other techniques for indicating that two or more quotes are linked together may be readily identified by those having ordinary skill in the art. However, the present invention preferably incorporates the use of quote chain identifiers to indicate the occurrence of a quote chain.

In a preferred embodiment, as each quote is received, it is uniquely associated with a quote chain identifier. In such an embodiment, the quote chain identifier (comprising any type of data suitable for uniquely identifying other data, such as an alphanumeric string or the like) serves as a means for establishing a linkage between a plurality of quotes. Because each quote is initially associated with its own quote chain identifier, subsequent operations linking one quote with another causes both quotes to become associated with only one of the quote chain identifiers; the other quote chain identifier is discarded. Where quotes are represented as records in a database, association of a quote with a quote chain identifier is achieved simply by modifying that quote' s record to include a reference to the quote chain identifier. Further quotes can be added to the quote chain by similarly modifying their records to also include the relevant quote chain identifier. Having established a quote chain, the user can be provided information that allows the user to refer to the quote chain directly, for example, the quote chain identifier.

Once a quote chain has been established, it is continually checked, at step 1005, whether any of the quotes included in the quote chain are still capable of fulfillment. For example, assume a given quote chain is composed of bids for three separate events respectively occurring on May 1 , June 1 and July 1. In this case, acceptance of any one of the bids would result in the other bids being inactivated. If, by the beginning of July 2, none of the bids had been accepted, obviously none of the bids would be capable of acceptance any longer. Other scenarios can be readily devised giving rise to circumstances in which no quotes included in a quote chain could be fulfilled. Regardless of the circumstances, if no quotes in a quote chain are capable of fulfillment, all quotes in the quote chain are inactivated at step 1006.

If, however, quotes within a given quote chain are still capable of fulfillment, processing proceed in a parallel fashion to steps 1007-1008 and 1009-1010. At step 1007, it is determined whether an acceptance indication corresponding to any quote within the quote chain has been received. For a bid, an acceptance indication is received when a seller agrees to sell at the bidder's price. For an offer, an acceptance indication is received when a buyer agrees to purchase at the offerer's price. Regardless, one consequence of such an acceptance being received is that the remaining and otherwise unaccepted quotes included in the quote chain are inactivated. In the context of the present invention, an "inactivated" quote is a quote that has been rendered, by whatever means necessary, incapable of being accepted. Such inactivation can be achieved, for example, by discontinuing display of the quote, flagging the quote as no longer being open to acceptance, deleting or archiving records associated with the quote's quote chain identifier or a combination of these or similar methods. The present invention is not limited in this regard. The present invention also allows for a user to "unlink" one or more quotes from a given quote chain. To this end, a request to unlink at least one quote from a quote chain can be received at step 1009. For example, a user can be provided with a summary of a given quote chain in tabular form such that information for each quote included in the quote chain is displayed. Based on this information, the user may select one or more quotes to be unlinked from the quote chain and provide such information in the form of a request at step 1009. In response, at step 1010, the selected quotes are unlinked from the designated quote chain. Where a quote chain identifier is used to establish the identity of a given quote chain, the quotes to be unlinked are modified to no longer include the quote chain identifier and are optionally assigned new, unique quote chain identifiers for possible future use. Referring again the example of linked bids for events occurring on May 1 , June 1 , and July 1 , the user may select the July 1 bid to be unlinked from the May 1 and June 1 bids. Subsequent acceptance of either of the May 1 or June 1 bids will cause the other of the May 1 or June 1 bids to be inactivated, but will not cause the July 1 bid to be inactivated.

The present invention increases the flexibility of market participants to tailor market positions to their particular needs, particularly when applied to an on-line exchange system. By providing a mechanism allowing quotes to be linked together, the present invention provides for the establishment of quote chains in which acceptance of any one quote in the quote chain causes the remaining quotes to be inactivated. Additionally, users may unlink one or more quotes currently forming a part of a quote chain. The present invention can be used in conjunction with markets for non-traditional commodities, such as seat locations within event venues. 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

ClaimsWhat is claimed is:

1. In a commodity exchange system, a method for processing quotes, the method comprising steps of: receiving a first quote from a user of the commodity exchange system; receiving at least a second quote from the user; and linking the first quote and at least the second quote together to provide a quote chain, wherein acceptance of any quote in the quote chain causes remaining quotes in the quote chain to be inactivated, and wherein each quote in the quote chain is directed to at least one seat within at least one event venue.

2. The method of claim 1, further comprising steps of: querying the user whether they desire to link together any quotes received from the user; and receiving a request from the user to link the first quote and at least the second quote.

3. The method of claim 1 , further comprising steps of: receiving an acceptance indication corresponding to any one quote in the quote chain; and inactivating the remaining quotes in the quote chain responsive to the acceptance indication.

4. The method of claim 1 , wherein each of the first quote and the second quote comprise either of a bid and an offer.

5. The method of claim 1 , wherein the first quote and at least the second quote are received from the user via a computer communication network.

6. The method of claim 1, further comprising steps of: receiving a request from the user to unlink at least one quote of the quote chain; and unlinking the at least one quote from the quote chain, wherein subsequent acceptance of any quote of the quote chain will not cause the at least one quote to be inactivated.

7. A computer-readable medium comprising computer-executable instructions for performing the steps recited in claim 1.

8. In a commodity exchange system, a method for processing quotes, the method comprising steps of: receiving a quote from a user of the commodity exchange system; associating the quote with a quote chain identifier uniquely associated with the user, wherein each quote associated with the quote chain identifier is directed to at least one seat within any event venue of a plurality of event venues; and inactivating unaccepted quotes associated with the quote chain identifier when any quote associated with the quote chain identifier is accepted.

9. The method of claim 8, further comprising a step of: receiving a subsequent quote from the user; and associating the subsequent quote with the quote chain identifier.

10. The method of claim 9, wherein the quote and the subsequent quote are received from the user via a computer communication network.

11. The method of claim 9, further comprising steps of: querying the user whether they desire to link together any quotes received from the user; and receiving a request from the user to link the quote and at least the subsequent quote.

12. The method of claim 8, wherein any quote associated with the quote chain identifier comprise either of a bid and an offer.

13. The method of claim 8, further comprising steps of: receiving a request from the user to unlink at least one quote associated with quote chain identifier; and disassociating the at least one quote from the quote chain identifier, wherein subsequent acceptance of any quote associated with the quote chain identifier will not cause the at least one quote to be inactivated.

14. A computer-readable medium comprising computer-executable instructions for performing the steps recited in claim 8.

15. An apparatus for use on a commodity exchange system, the apparatus comprising: means for receiving a first quote and at least a second quote from a user of the commodity exchange system; and means for linking the first quote and at least the second quote together to provide a quote chain, wherein acceptance of any quote of the quote chain causes remaining quotes of the quote chain to be inactivated, and wherein each quote of the quote chain is directed to at least one seat within at least one event venue.

16. The apparatus of claim 15, further comprising: means for receiving an acceptance indication corresponding to any one quote of the quote chain; and means, responsive to the acceptance indication, for inactivating the remaining quotes of the quote chain.

17. The apparatus of claim 15, further comprising: means for querying the user whether they desire to link together any quotes received from the user; and means for receiving a request from the user to link the first quote and at least the second quote.

18. The apparatus of claim 15, wherein each of the first quote and the second quote comprise either of a bid and an offer.

19. The apparatus of claim 15, further comprising: means for providing, to the user, a quote chain identifier corresponding to the quote chain.

20. The apparatus of claim 15, further comprising: means for receiving a request from the user to unlink at least one quote of the quote chain; and means for unlinking the at least one quote from the quote chain, wherein subsequent acceptance of any quote of the quote chain will not cause the at least one quote to be inactivated.

21. A commodity exchange system comprising a computer communication network coupled to an exchange controller in accordance with the apparatus of claim 15.

22. An apparatus for use in a commodity exchange system, the apparatus comprising: means for receiving a quote from a user of the commodity exchange system; means for associating the quote with a quote chain identifier uniquely associated with the user, wherein each quote associated with the quote chain identifier is directed to at least one seat within any event venue of a plurality of event venues; and means for inactivating unaccepted quotes associated with the quote chain identifier when any quote associated with the quote chain identifier is accepted.

23. The apparatus of claim 22, wherein the means for receiving further functions to receive a subsequent quote from the user, and wherein the means for associating further function to associate the subsequent quote with the quote chain identifier.

24. The apparatus of claim 23, further comprising: means for querying the user whether they desire to link together any quotes received from the user; and means for receiving a request from the user to link the quote and at least the subsequent quote.

25. The apparatus of claim 22, wherein any quote associated with the quote chain identifier comprise either of a bid and an offer.

26. The apparatus of claim 22, further comprising: means for providing the quote chain identifier to the user.

27. The apparatus of claim 22, further comprising: means for receiving a request from the user to unlink at least one quote associated with quote chain identifier; and means for disassociating the at least one quote from the quote chain identifier, wherein subsequent acceptance of any quote associated with the quote chain identifier will not cause the at least one quote to be inactivated.

28. A commodity exchange system comprising a computer communication network coupled to an exchange controller in accordance with the apparatus of claim 22.

29. A computer-readable medium having stored thereon a data structure comprising: a first quote record corresponding to a user of a commodity exchange system; and at least a second quote record corresponding to the user and linked to the first quote record to provide a quote chain, wherein acceptance of any quote of the quote chain causes remaining quotes of the quote chain to be inactivated, and wherein each quote of the quote chain is directed to at least one seat within at least one event venue.

30. The computer-readable medium of claim 29, wherein each of the first quote record and at least the second quote record comprise either of a bid record and an offer record.

31. The computer-readable medium of claim 29, wherein the data structure further comprises : at least one bid specification record, wherein each bid record is uniquely linked to a corresponding one of the at least one bid specification record.

32. The computer-readable medium of claim 29, wherein the data structure further comprises : at least one offer specification record, wherein each offer record is uniquely linked to a corresponding one of the at least one offer specification record.

33. A computer-readable medium having stored thereon a data structure comprising: at least one quote record corresponding to a user of a commodity exchange system; and a quote chain identifier associated with each of the at least one quote record, wherein acceptance of any of the at least one quote record associated with the quote chain identifier causes a remainder of the at least one quote record associated with the quote chain identifier to be inactivated, and wherein any quote record associated with the quote chain identifier is directed to at least one seat within any event venue of a plurality of event venues

34. The computer-readable medium of claim 33 , wherein any quote record associated with the quote chain identifier comprises either of a bid record and an offer record.

35. The computer-readable medium of claim 33, wherein the data structure further comprises: at least one bid specification record, wherein each bid record is uniquely linked to a corresponding one of the at least one bid specification record.

36. The computer-readable medium of claim 33, wherein the data structure further comprises: at least one offer specification record, wherein each offer record is uniquely linked to a corresponding one of the at least one offer specification record.