The present invention relates to electronic trading systems and more particularly, to a system and method for displaying executed trade information including aggregated trade information and/or market side information.
Trading exchanges have advanced from in-person floor trading operations to technology-enabled electronic trading exchanges that allow remote users to participate in various markets. In general, sellers submit sell orders (offers or asks) with prices at which they will sell a specified quantity of tradable objects, and buyers submit buy orders (bids) with prices at which they will buy a specified quantity of tradable objects. A tradable object, as used herein, refers to any object which can be traded with a price and a quantity, and includes various items such as stocks, bonds, funds, futures, spreads, options, commodities, etc. In an electronic trading exchange, a host exchange disseminates to all connected participants market information relating to bids, offers, and trades in order to provide the same transparency that floor traders are provided. Sellers try to sell at the highest price and buyers try to buy at the lowest price, and an exchange matching system facilitates the matching of bids and offers in order to execute trades. In many electronic exchanges, disseminated trade notifications typically include the tradable object for which the trade occurred, the price upon which the buyer and seller agreed, the number of shares or contracts that traded, and the exchange-time of the trade.
Trade notifications rarely include any other descriptive information in addition to what is specified above. In particular, the parties involved in the trade typically are not revealed and most exchanges report every trade individually, regardless of whether or not the trade resulted from a larger buy or sell order. For example, if there are 100 different sellers each attempting to sell a single futures contract at the same price, and if a buyer submits a buy order at that price and with a quantity of 100, this will result in 100 separate trade notifications being generated, even though just a single buy order is involved. Similarly, many trade notifications can be generated when there is a single sell order of a larger quantity which is divided up between multiple different buyers.
Trade notifications are received on the trader side by a trader system which includes user devices and a trading application running for example on a server. The trade notifications are processed in a desired manner, and the associated trade information is then displayed in what is typically called a “trade ticker” on the display screens of the user devices. Because new trade information is constantly being appended over the course of a trading session, as new trades occur, the new trades are typically added to the end of the list of trades on the ticker, and as they accumulate, the oldest trades are removed to make room for the more recent trades.
Because this raw trade information can be overwhelming and trades can occur so rapidly that they are scrolled off the screen before a trader has time to recognize and interpret them, typically trading applications include features which allow the trader to specify filters to eliminate some of the so-called “noise”, which is information that is not relevant to that trader. For example, a trader may want to only be notified of trades for a particular tradable object, or even a subset of a tradable object. If a trader is trading IBM stock, he may not care about every Google trade. Additionally, since certain stocks like IBM may trade hundreds of millions of times in a day, a trader may only want to be notified of trades with quantities larger than or equal to a predetermined amount, such as 1,000 shares. Traditional trading applications often have a filter by size feature to filter out those trades with quantities that are less than a predetermined amount and display only those trades having quantities greater than or equal to the predetermined amount.
Although such a filter feature can help to eliminate a lot of irrelevant information, it can also lead to the unintentional elimination of important data. For example, if there are 35 different sellers each attempting to sell less than 1000 contracts of a specified futures contract at the same price and with a total quantity of 25,000 contracts, and if a buyer submits a buy order at that price and with a quantity of 25,000, this will result in 35 separate trades and 35 corresponding trade notifications being generated, each having an associated trade quantity of less than 1000 contracts. In this case, if a trader wants to have displayed only those trades with quantities greater than 1000 contracts, the trader will not be aware that these trades occurred and will unfortunately miss the fact that 25,000 contracts have traded.
Traders base their decisions to buy and sell on many factors, and knowing what objects are trading, at what price, and when they are trading are all important factors. However, other factors can also be helpful and are not conveyed using traditional trading applications. For example, traditional tickers, while displaying the trade price, do not convey whether the executed trade traded on the bid side or the offer side of the market. Further, traditional tickers displaying trade information do not convey whether further volume is available at a specific price.
Therefore, it would be advantageous for a trading application and method to group smaller trades into an aggregated trade for display when it is likely that a single larger buy or sell order is involved, while retaining the ability to filter out and not display trades having quantities or aggregated quantities less than a predetermined amount. Further, it would advantageous to provide market side information and/or remaining available volume at the trade price corresponding to each displayed trade. A trading application which displays aggregated trade information, market side information, and/or remaining volume information helps the trader assimilate and process a large amount of information such that informed and rapid trading decisions can be made.
In at least some embodiments, the present invention relates to a method for displaying trade information. The method includes receiving from a host exchange a plurality of trade notifications, each trade notification corresponding to an executed trade and including an associated identification of the tradable object traded, an associated trade price, an associated trade quantity, and an associated trade execution time. For each executed trade of interest, a trading application determines whether the executed trade belongs in an aggregated set with one or more other executed trades, wherein all executed trades in an aggregated set are for the same associated tradable object, have traded at the same associated trade price, and have been executed within a predetermined time period of each other. For each aggregated set, the trading application causes to be displayed on a user display the corresponding executed trades in the set as a single aggregated trade with the associated identification of the tradable object traded, the associated trade price, and an associated aggregated quantity. For each executed trade of interest not in an aggregated set, the trading application causes to be displayed on the user display the associated identification of the tradable object traded, the associated trade price, and the associated trade quantity.
In other embodiments, the invention relates to a method for displaying trade information, the method including receiving from a host exchange a plurality of trade notifications, each trade notification corresponding to an executed trade and including an associated identification of the tradable object traded, an associated trade price, an associated trade quantity, and an associated trade execution time. The method also includes receiving from a host exchange a plurality of bid and offer notifications, each bid or offer notification corresponding to a respective buy or sell order and including an associated identification of the tradable object, an associated bid or offer price, and an associated bid or offer quantity. For each executed trade of interest, a trading application compares the associated trade price to at least one of a highest bid price and a lowest offer price corresponding to the associated tradable object traded existing at the time of the executed trade to determine whether the executed trade occurred on a bid side or on an offer side of the market. For each executed trade of interest, the trading application causes the associated identification of the tradable object traded, the associated trade price, and the associated trade quantity to be displayed on a user display, wherein each executed trade is displayed using an associated visual or audio indicator for indicating whether it traded on the bid side or on the offer side of the market. An associated visual indicator can be color, and each displayed trade can further indicate by color whether additional volume exists at the associated trade price.
The present invention is described herein with reference to one or more exemplary embodiments, however, it should be understood that the present invention is not limited to these embodiments. Those skilled in the art will appreciate that other arrangements and other elements can be used instead, and some elements may be omitted altogether. Further, as in most electronic systems, those skilled in the art will appreciate that various components can be implemented as discrete or distributed components, and various functions can be implemented by software, hardware, and/or firmware. For example, a processor executing a set of machine language instructions stored in memory (software) may perform various functions. Provided with the present disclosure describing several functions, those skilled in the art can readily prepare appropriate computer instructions to enable such functions.
Referring to
The host exchange 12 includes various computers, servers, and applications, and is supported by any of a variety of exchange organizations, such as the Chicago Board of Trade, the New York Stock Exchange, the Chicago Mercantile Exchange, or the like. As is known, the host exchange performs several functions including the receipt and review of the submitted buy and sell orders, and the prioritization and matching of these orders to generate executed trades. Further, the host exchange continually provides market information to the trader systems, including bid and offer notifications and trade notifications. Each bid or offer notification corresponds to one of the submitted buy or sell orders and includes an identification of the associated tradable object, bid or offer price, and quantity desired. Each trade notification corresponds to one of the executed trades and includes an identification of the associated tradable object traded, the trade price, the trade quantity, and the execution time. Different exchanges can provide this information in various formats and ways, such as reporting every order or trade as it occurs, or reporting at pre-specified time intervals.
The network 16 provides electronic communication between the host exchange 12 and the trader system 14 and can take any of a variety of forms, including the Internet, wired or wireless connections, secured or unsecured communication, as is known.
Similarly, the trader system 14 can be implemented in a variety of ways, with the illustrated embodiment including a server 20 or processor for receiving the market information from the host exchange and capable of running a software trading application 22 which extracts relevant trade information and causes it to be displayed in a trade ticker on the display screen 24 of one or more of the user devices 18. The user devices 18 can take various forms such as personal computers or hand-held devices and can be connected to the server via a network 26, such as a local or wide area network, in a wired or wireless manner.
In general, the trading application 22 facilitates the display of market information such as executed trades and associated prices and quantities on display screens 24 of respective user devices 18, wherein certain executed trades are aggregated when defined conditions are met, and wherein trades having quantities below a predetermined threshold can be filtered out and not displayed, as more fully described below. Further, the trading application 22 facilitates the display of other important trade information such as whether a trade has occurred on the bid side or the offer side of the market, and whether additional trade volume is available. This new information is provided to the trader in an intuitive way, so that just by looking at the displayed trades in the trade ticker, this additional trade information can be quickly understood and acted upon by the trader.
Most exchanges such as host exchange 12 provide notifications corresponding to all submitted buy and sell orders, including information relating to modifications or cancellations, and executed trades as they occur and so it is up to the trader system 14 to maintain a current state or “book” for each tradable object, which is a consolidation of all the information related to prices and quantities for that tradable object. For example, the trading application 22 keeps track of this current state information and also facilitates the display of this information by displaying existing buy and sell order prices and quantities in a manner such as shown in
a sell order of 117 shares at a price of $400.2
a sell order of 26 shares at a price of $400.1
a buy order of 100 shares at a price of $400.0
a buy order of 13 shares at a price of $399.9
a buy order of 27 shares at a price of $399.7
As described below, this consolidated buy and sell order information can be used to provide meaningful information to supplement the trade information, to determine whether an executed trade occurred on the bid side or offer side of the market and to determine whether remaining volume is available at the associated trade price. For example, using the example shown in
As for the determination of market side information, the current inside market (highest buy order price/lowest sell order price at a point in time) for a tradable object allows the determination of whether the object traded by someone “lifting” the offer (buying at the resting sell order price) or by someone “hitting” the bid (selling at the resting buy order price). For example, if the trade price for a share of GOOG is $400.0 and the current market has a bid price of $400.0 and an offer price of $400.1, then the trade occurred on the bid side of the market.
Knowing this additional information can be helpful to a trader to make informed decisions regarding buying and selling that tradable object, because it provides insight into movement and momentum of the market, and provides valuable insight to the trader regarding the current ability or inability to transact at that price.
Referring now to
At a step 110, the trading application receives any user preferences regarding which executed trades are of interest, such as which tradable objects are of interest, and whether any filters should be applied in order to prevent the display of trades having quantities less than (or less than or equal to) a predetermined threshold quantity. For example, a trader can specify via the user device that only GOOG trades are of interest and should be displayed, and only those GOOG trades with quantities greater than or equal to (or greater than) 1000 shares should be displayed. In the absence of a user selection, a default threshold quantity can be used to prevent the display of trades having associated quantities below that default amount. For example, a default threshold can be a set value such as 100 shares or contracts or a value selected in a previous session.
At a step 120, for each executed trade of interest, the associated trade price is compared to at least one of a current highest bid price and a lowest offer price corresponding to the associated tradable object and existing at the associated trade execution time to determine whether the executed trade occurred on a bid side or on an offer side of the market.
At a step 130, for each executed trade of interest, it is determined whether that trade and any other executed trades belong in an aggregated set. Certain conditions can be defined such that when met, executed trades in the aggregated set are assumed to correspond to a larger buy or sell order. In one embodiment, if there are two or more executed trades for the same tradable object at the same price and within a predetermined time period, such as three seconds, the executed trades are deemed to be part of the same aggregated set. The trading application can utilize a default predetermined time period or a trader can specify a desired predetermined time period. The determination of a likely aggregated trade composed of smaller trades can be further refined with other conditions such as requiring that no intervening trades occur involving different tradable objects. This is because if a buy or sell order is matched with multiple sell or buy orders and multiple trades are executed, it can be safely assumed that the host exchange will disseminate all trade notifications that correspond to those multiple trades before disseminating any other trade information.
Another consideration to determine whether or not reported trades should be aggregated is by evaluating the state of the market when the trades occurred, and only aggregating those trades which occurred on the same bid or offer side of the market. Thus in a preferred embodiment, executed trades are aggregated when they are for the same tradable object at the same trade price, are executed within a predetermined time period of each other without an intervening trade of a different tradable object, and all occur on the same bid or offer side of the market.
Consider the following examples showing trade times, an identification of the tradable object, prices, and associated quantities. If the following three trades occur in rapid succession, then the two GOOG trades are not aggregated because of the intervening IBM trade:
If the following trades occur, these trades are not aggregated because different trade prices are involved:
In this case, because the trade with a different price is in between two other trades at the same price, the trades could not have resulted from a single buy or sell order. Aggregation is not appropriate because then relevant information would not be conveyed to the trader—namely that GOOG was trading on both sides of the market. In this example, each GOOG trade would be separately displayed on the user display.
Consider the following trades:
The trading application would form a first aggregated set for trades 2 and 3 and a second aggregated set for trades 5 and 6. Trades 1 and 4 are not part of aggregated sets. In other words, if two or more executed trades occur for the same tradable object and at the same price, without any intervening trades, and within a predetermined time period specified by the trader (for example, three seconds), but these executed trades occurred on both sides of the market, the trades are not aggregated.
At a step 140, the executed trades of interest are displayed in a ticker on a user display. In particular, for each aggregated set, an aggregated trade is displayed with the associated identification of the tradable object that was traded, the associated aggregated quantity, the associated trade price, and optionally an execution time. Similarly, for each executed trade of interest which is not in an aggregated set, the associated identification of the tradable object is displayed, along with the associated trade quantity and the associated trade price, and optionally the execution time.
In a preferred embodiment, each displayed trade is displayed using an associated visual or audio indicator, such as color, for indicating whether it traded on the bid side or on the offer side of the market. For example, the color can be blue if the trade traded on the bid side and red if the trade traded on the offer side of the market. Color is useful because it is a visual indicator which is quickly perceived and interpreted. Other indicators such as fonts or icons for conveying this information can also be used.
Thus in the previous example, the following will be displayed (assuming no filtering by size) with one or more items associated with each displayed trade, and preferably the entire trade information, in an associated color as indicated below:
The associated color for each displayed trade can further indicate whether additional volume exists at the trade price. How much additional volume is available is determined by referencing the current state of the tradable object then existing. Specifically, if no additional volume exists at the trade price, the associated color is lighter compared to when additional volume is available. For example, if no additional volume is available, then the displayed trade will be shaded light blue to indicate the last price traded in its entirety on the bid side, or light red (pink) to indicate it traded in its entirety on the offer side.
As a final example, consider the case wherein several tradable objects are being monitored, with the occurrence of the following trades:
In this example, the trading application 22 will operate in a manner such that trades 1 and 2 will be aggregated, trade 3 will not be aggregated, trade nos. 4 and 5 will be aggregated, trade no. 6 will not be aggregated, trade nos. 7-19 will be aggregated, trade nos. 20 and 21 will be aggregated, trade no. 22 will not be aggregated, and trades nos. 23-25 will be aggregated. Therefore, the following trade information will be displayed:
In summary, the trading application 22 provides a trade ticker that smartly consolidates executed trades that belong to each other and therefore makes the trade ticker easier to follow. Especially during fast market times, each displayed trade likely remains on the trade ticker for a longer period of time before being displaced by newer trades, in contrast to prior art trading applications which don't aggregate trades and where many smaller trades can easily quickly cover multiple screens and result in the quicker disappearance of prior trades. Additionally, providing aggregated quantities to the trader is a major benefit because it eliminates having to add or approximate the total number of shares or contracts traded in many smaller trades. Further, aggregation allows a filter by size feature to be implemented without the risk of losing key information.
By evaluating a current state of the market when trade notifications are disseminated, certain information can be determined that is not provided in the disseminated market information, namely, whether executed trades occurred on the bid side or the offer side of the market, and whether additional volume remains at the trade price. This information enables a trader to make decisions by describing with more certainty the momentum or state of a market and whether further trading volume at that price is possible. This is in contrast to prior art trading applications which display trade information and merely indicate “upticks” and “downticks” in a market such as by way of an up arrow or a down arrow associated with a displayed trade to indicate price movement of the most recent price to the previous price.
For example, an active trader is often concerned with what direction the market is currently moving and whether specific prices are available to trade something, especially if the trader is concurrently engaging in another trade, in order to set up a spread position for example. The trading application 22 and resulting display described above provides more complete information to the trader if a market is already in the process of moving, saving time and effort. For example, assume the inside market prices corresponding to a particular tradable object are $14/$15. Assume that the trader system determines that the last trade price of $14.5 occurred on the offer side, and no volume remains on the offer side. As described above, this trade information would then be displayed in pink, informing the trader that no additional volume exists at that offer price to be bought. If instead a spread trader knows he can buy at that price, he may offer to sell something else at a level he considers a better sale. The $14.5 offer for that trade is his ‘lean’. He was doing another trade ‘leaning’ on the info that he could buy that market at $14.5.
With prior art tickers, an up arrow only indicates that $14.5 was a higher trade price than the previous trade. A trader can assume with a certain probability that the latest trade traded on the offer side of the market at the time of the trade notification (since $14 was previous and lower), but he cannot safely assume that the $14.5 offer is still there to buy. So the prior art ticker has left an information gap, and the trader would have to go check another display screen showing bids, offers and prices for that tradable object to see whether the inside market is now 13.5/14.5, 14/14.5, 14/15, or 14.5/15. It could be any of those, and important seconds can elapse in the process of checking.
However, the pink indication on the ticker of the present invention tells a trader that at that moment, there is definitely not a 14.5 offer, so caution should be employed. A new 14.5 offer may come in to the market, but the trader at least knows the important information that he lost his lean so he needs to re-access the other actions he is contemplating. The only informational gap that the ticker of the present invention has left is whether the market is now 14/15 or 14.5/15, but the fact that the offer $14.5 price has traded out and no volume is available is very useful and doesn't leave the information gap that an arrow would.
Assume now instead that the last trade price of $14.5 occurred on the bid side, and additional volume is available. This would be indicated by a blue $14.50 price on the ticker. This lets the trader know that there is still at least some quantity bid at the price at least at that moment. It is possible that the $14.5 bid may disappear and the trader is left momentarily unaware, but trading decisions are determined more by what is the state at an exact moment, with the understanding that what may happen next cannot be predicted with certainty.
Thus, this trading application 22 and resultant user display enables a trader to operate in a more efficient, accurate, and convenient manner. For a market-maker, this increased efficiency translates into more liquid and deeper markets, one of the great and envied attributes of this country's capital markets.
It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein, but include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims.
This application is a continuation of U.S. patent application Ser. No. 17/343,130 filed Jun. 9, 2021, which is a continuation of U.S. patent application Ser. No. 15/654,292 filed Jul. 19, 2017, now U.S. Pat. No. 11,068,981, which is a continuation of U.S. patent application Ser. No. 14/257,075 filed Apr. 21, 2014, now U.S. Pat. No. 9,741,076, which is a continuation of U.S. patent application Ser. No. 12/468,610 filed May 19, 2009, now U.S. Pat. No. 8,744,945, the contents of each of which are fully incorporated herein by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
3253263 | Lee et al. | May 1966 | A |
4674044 | Kalmus et al. | Jun 1987 | A |
4750135 | Boilen | Jun 1988 | A |
4903201 | Wagner | Feb 1990 | A |
5038284 | Kramer | Aug 1991 | A |
5077665 | Silverman et al. | Dec 1991 | A |
5101353 | Lupien et al. | Mar 1992 | A |
5136501 | Silverman et al. | Aug 1992 | A |
5270922 | Higgins | Dec 1993 | A |
5297031 | Gutterman et al. | Mar 1994 | A |
5297032 | Trojan et al. | Mar 1994 | A |
5339392 | Risberg et al. | Aug 1994 | A |
5454104 | Steidlmayer et al. | Sep 1995 | A |
5588009 | Will | Dec 1996 | A |
5689651 | Lozman | Nov 1997 | A |
5758097 | Debe et al. | May 1998 | A |
5774877 | Patterson, Jr. et al. | Jun 1998 | A |
5793301 | Patterson, Jr. et al. | Aug 1998 | A |
5797002 | Patterson, Jr. et al. | Aug 1998 | A |
5809483 | Broka et al. | Sep 1998 | A |
5832496 | Anand et al. | Nov 1998 | A |
5845266 | Lupien et al. | Dec 1998 | A |
5905868 | Baghai et al. | May 1999 | A |
5913202 | Motoyama | Jun 1999 | A |
5915209 | Lawrence | Jun 1999 | A |
5915245 | Patterson, Jr. et al. | Jun 1999 | A |
5924082 | Silverman et al. | Jul 1999 | A |
5924083 | Silverman et al. | Jul 1999 | A |
5946667 | Tull, Jr. et al. | Aug 1999 | A |
5963923 | Garber | Oct 1999 | A |
5974393 | McCullough et al. | Oct 1999 | A |
5995943 | Bull et al. | Nov 1999 | A |
5995980 | Olson et al. | Nov 1999 | A |
6006206 | Smith et al. | Dec 1999 | A |
6012046 | Lupien et al. | Jan 2000 | A |
6014643 | Minton | Jan 2000 | A |
6035287 | Stallaert et al. | Mar 2000 | A |
6058389 | Chandra et al. | May 2000 | A |
6097399 | Bhatt et al. | Aug 2000 | A |
6098051 | Lupien et al. | Aug 2000 | A |
6131087 | Luke et al. | Oct 2000 | A |
6134535 | Belzberg | Oct 2000 | A |
6195647 | Martyn et al. | Feb 2001 | B1 |
6272474 | Garcia | Aug 2001 | B1 |
6278982 | Korhammer et al. | Aug 2001 | B1 |
6282521 | Howorka | Aug 2001 | B1 |
6370569 | Austin | Apr 2002 | B1 |
6408282 | Buist | Jun 2002 | B1 |
6418419 | Nieboer et al. | Jul 2002 | B1 |
6505174 | Keiser et al. | Jan 2003 | B1 |
6516339 | Potts, Jr. et al. | Feb 2003 | B1 |
6618707 | Gary | Sep 2003 | B1 |
6766304 | Kemp, II et al. | Jul 2004 | B2 |
6772132 | Kemp, II et al. | Aug 2004 | B1 |
6938011 | Kemp, II et al. | Aug 2005 | B1 |
6993507 | Meyer et al. | Jan 2006 | B2 |
6993511 | Himmelstein | Jan 2006 | B2 |
7124110 | Kemp, II et al. | Oct 2006 | B1 |
7127424 | Kemp, II et al. | Oct 2006 | B2 |
7181424 | Ketchum et al. | Feb 2007 | B1 |
7212997 | Pine et al. | May 2007 | B1 |
7228289 | Brumfield | Jun 2007 | B2 |
7243083 | Burns et al. | Jul 2007 | B2 |
7310615 | Lewis | Dec 2007 | B2 |
7366691 | Kemp, II et al. | Apr 2008 | B1 |
7373327 | Kemp, II et al. | May 2008 | B1 |
7389268 | Kemp, II et al. | Jun 2008 | B1 |
7412462 | Margolus et al. | Aug 2008 | B2 |
7426491 | Singer et al. | Sep 2008 | B1 |
7428506 | Waelbroeck et al. | Sep 2008 | B2 |
7451112 | Backestrand et al. | Nov 2008 | B2 |
7558754 | Singer et al. | Jul 2009 | B1 |
7580882 | West et al. | Aug 2009 | B2 |
7590587 | Duquette | Sep 2009 | B2 |
7593887 | Duquette | Sep 2009 | B2 |
7620587 | Duquette | Nov 2009 | B2 |
7680721 | Cutler | Mar 2010 | B2 |
7680727 | Kemp, II et al. | Mar 2010 | B2 |
7685049 | Singer | Mar 2010 | B1 |
7707091 | Kauffman et al. | Apr 2010 | B1 |
7742962 | Singer | Jun 2010 | B1 |
7774263 | Wunsch et al. | Aug 2010 | B1 |
7813998 | Mauro, Jr. et al. | Oct 2010 | B1 |
7822672 | Hausman | Oct 2010 | B2 |
7974915 | Kemp, II et al. | Jul 2011 | B2 |
7979345 | Kemp, II et al. | Jul 2011 | B2 |
8027895 | Howorka et al. | Sep 2011 | B2 |
8036977 | Mintz et al. | Oct 2011 | B1 |
8082203 | Mauro, Jr. | Dec 2011 | B1 |
8126794 | Lange et al. | Feb 2012 | B2 |
8145558 | Duquette | Mar 2012 | B2 |
8150760 | Duquette | Apr 2012 | B2 |
8150761 | Duquette | Apr 2012 | B2 |
8204822 | Kemp, II et al. | Jun 2012 | B2 |
8229837 | Duquette | Jul 2012 | B2 |
8407131 | Kemp, II et al. | Mar 2013 | B2 |
8423373 | Singer | Apr 2013 | B2 |
8676697 | Kemp, II et al. | Mar 2014 | B2 |
8744945 | Lane et al. | Jun 2014 | B2 |
8762257 | Singer | Jun 2014 | B2 |
8781947 | Duquette | Jul 2014 | B2 |
9741076 | Lane et al. | Aug 2017 | B2 |
9805417 | Kemp, II et al. | Oct 2017 | B2 |
10055790 | Singer | Aug 2018 | B2 |
10776871 | Singer | Sep 2020 | B2 |
10937093 | Duquette | Mar 2021 | B2 |
11282141 | Singer | Mar 2022 | B2 |
20010003179 | Martyn | Jun 2001 | A1 |
20010037284 | Finkelstein et al. | Nov 2001 | A1 |
20020007335 | Millard et al. | Jan 2002 | A1 |
20020023038 | Fritsch et al. | Feb 2002 | A1 |
20020035534 | Buist et al. | Mar 2002 | A1 |
20020052827 | Waelbroeck et al. | May 2002 | A1 |
20020055899 | Williams | May 2002 | A1 |
20020059129 | Kemp, II et al. | May 2002 | A1 |
20020072980 | Dutta | Jun 2002 | A1 |
20020073017 | Robertson | Jun 2002 | A1 |
20020099644 | Kemp, II et al. | Jul 2002 | A1 |
20020120546 | Zajac | Aug 2002 | A1 |
20020120551 | Jones | Aug 2002 | A1 |
20020138401 | Allen et al. | Sep 2002 | A1 |
20020178104 | Hausman | Nov 2002 | A1 |
20020184237 | McFeely | Dec 2002 | A1 |
20030004852 | Burns | Jan 2003 | A1 |
20030004853 | Ram et al. | Jan 2003 | A1 |
20030009411 | Ram et al. | Jan 2003 | A1 |
20030023542 | Kemp, II et al. | Jan 2003 | A1 |
20030033239 | Gilbert et al. | Feb 2003 | A1 |
20030069834 | Cutler | Apr 2003 | A1 |
20030126155 | Parker et al. | Jul 2003 | A1 |
20030236737 | Kemp, II et al. | Dec 2003 | A1 |
20040034591 | Waelbroeck et al. | Feb 2004 | A1 |
20040117292 | Brumfield et al. | Jun 2004 | A1 |
20040148242 | Liu | Jul 2004 | A1 |
20040162772 | Lewis | Aug 2004 | A1 |
20040260639 | Lundberg et al. | Dec 2004 | A1 |
20050049954 | Graham et al. | Mar 2005 | A1 |
20050228735 | Duquette | Oct 2005 | A1 |
20050267836 | Crosthwaite et al. | Dec 2005 | A1 |
20060085317 | Allen | Apr 2006 | A1 |
20060195389 | Kemp, II et al. | Aug 2006 | A1 |
20060259382 | Kemp, II et al. | Nov 2006 | A1 |
20060265317 | Duquette | Nov 2006 | A1 |
20060265320 | Duquette | Nov 2006 | A1 |
20060293999 | Tanpoco et al. | Dec 2006 | A1 |
20070038556 | Kemp, II et al. | Feb 2007 | A1 |
20070088648 | Mather et al. | Apr 2007 | A1 |
20070100735 | Kemp, II et al. | May 2007 | A1 |
20070136133 | Li | Jun 2007 | A1 |
20080010186 | Weimer | Jan 2008 | A1 |
20080086401 | Mather | Apr 2008 | A1 |
20080162333 | Kemp, II et al. | Jul 2008 | A1 |
20080215477 | Annunziata | Sep 2008 | A1 |
20090018968 | Ardell et al. | Jan 2009 | A1 |
20090076899 | Gbodimowo | Mar 2009 | A1 |
20090132409 | Lutnick et al. | May 2009 | A1 |
20090157534 | Arsiwala | Jun 2009 | A1 |
20090182656 | Tully et al. | Jul 2009 | A1 |
20090240630 | Casey et al. | Sep 2009 | A1 |
20090292650 | Duquette | Nov 2009 | A1 |
20090292651 | Duquette | Nov 2009 | A1 |
20090292652 | Duquette | Nov 2009 | A1 |
20090319441 | Duquette | Dec 2009 | A1 |
20100076907 | Rosenthal et al. | Mar 2010 | A1 |
20100100830 | Singer | Apr 2010 | A1 |
20100131404 | Kemp, II et al. | May 2010 | A1 |
20100131405 | Kemp, II et al. | May 2010 | A1 |
20100293109 | Jain et al. | Nov 2010 | A1 |
20100299280 | Lane et al. | Nov 2010 | A1 |
20110225083 | Kemp, II et al. | Sep 2011 | A1 |
20110251942 | Rosenthal et al. | Oct 2011 | A1 |
20120203683 | Duquette | Aug 2012 | A1 |
20120233058 | Kemp, II et al. | Sep 2012 | A1 |
20130159162 | Kemp, II et al. | Jun 2013 | A1 |
20130211997 | Singer | Aug 2013 | A1 |
20130218739 | Kmiec et al. | Aug 2013 | A1 |
20140279376 | Duquette | Sep 2014 | A1 |
20140316966 | Singer | Oct 2014 | A1 |
20140337196 | Lane et al. | Nov 2014 | A1 |
20140379545 | Kemp, II et al. | Dec 2014 | A1 |
20170316504 | Lane et al. | Nov 2017 | A1 |
20180018437 | Kemp, II et al. | Jan 2018 | A1 |
20180330441 | Singer | Nov 2018 | A1 |
20200364793 | Singer | Nov 2020 | A1 |
Number | Date | Country |
---|---|---|
1067471 | Jan 2001 | EP |
9114231 | Sep 1991 | WO |
9226005 | Sep 1995 | WO |
9849639 | Nov 1998 | WO |
9919821 | Apr 1999 | WO |
9930259 | Jun 1999 | WO |
9953424 | Oct 1999 | WO |
0052619 | Sep 2000 | WO |
0062187 | Oct 2000 | WO |
0062187 | Oct 2000 | WO |
0065510 | Nov 2000 | WO |
0116830 | Mar 2001 | WO |
0116852 | Mar 2001 | WO |
0116852 | Mar 2001 | WO |
0122315 | Mar 2001 | WO |
0122315 | Mar 2001 | WO |
0165403 | Sep 2001 | WO |
0188808 | Nov 2001 | WO |
0259815 | Jan 2002 | WO |
0215461 | Feb 2002 | WO |
0217193 | Feb 2002 | WO |
0229686 | Apr 2002 | WO |
0248945 | Jun 2002 | WO |
0269226 | Sep 2002 | WO |
0279940 | Oct 2002 | WO |
0293325 | Nov 2002 | WO |
03090032 | Oct 2003 | WO |
03090032 | Dec 2003 | WO |
Entry |
---|
Hungarian Intellectual Property Office Search Report and Written Opinion in Singapore Application No. 201108564-4 dated May 21, 2013. |
International Search Report of PCT/US2003/018436. |
International Search Report and Written Opinion of PCT/US2010/35416. |
CQG, “CQG Integrated Client Basics, Version 7.9, May 18, 2009” [Retrieved Jul. 1, 2010] Retrieved from the Internet, <URL:http://www.cqg.com/Docs/CQG_Basics_UG_7x9.pdf>. |
Kharouf, “A Trading Room with a View”, Futures, vol. 27, Nov. 1998. |
Levy, S. “Graphical User Interface,” https://www.britannica.com/technology/graphical-user-interface, Encyclopaedia Britannica, 1999. |
Paul, et al. “Course 24: OpenGL and Window System Integration” Presented at Special Interest Group on Graphics and Interactive Techniques (SIGGRAPH), Los Angeles, Aug. 3-8, 1997. http://www.siggraph.org/s97/conference/courses/24.html. |
USPTO Presentation, NASDAQ, Nov. 8, 2001. |
X_Trader Product HTML Page [online], Trading Technologies International, Inc., Jun. 9, 2000. [Retrieved on Mar. 22, 2001] from the Internet: www.tradingtechnologies.com/products/xtrade_full.html (viewed May 22, 2001) Jun. 9, 2000. |
Number | Date | Country | |
---|---|---|---|
20230222590 A1 | Jul 2023 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 17343130 | Jun 2021 | US |
Child | 18187889 | US | |
Parent | 15654292 | Jul 2017 | US |
Child | 17343130 | US | |
Parent | 14257075 | Apr 2014 | US |
Child | 15654292 | US | |
Parent | 12468610 | May 2009 | US |
Child | 14257075 | US |