Trading System Benutzeroberfläche

Benutzerschnittstelle für ein elektronisches Handelssystem US 7752122 B2 Eine Benutzerschnittstelle für eine elektronische Handelsbörse ist vorgesehen, die es einem entfernten Händler ermöglicht, in Echtzeit Gebotsaufträge, Angebotsaufträge und Trades für eine Position und optional eine oder mehrere Quellen von kontextuellen Anzeigen anzuzeigen Daten. Einzelne Händler platzieren Aufträge auf Remote-Client-Terminals, und diese Informationen werden an einen Transaktionsserver weitergeleitet. Der Transaktionsserver empfängt Auftragsinformationen von den entfernten Terminals, passt ein Gebot für ein Element an ein Angebot für ein Element an, das auf das dem Angebot entsprechende Angebot entspricht, und überträgt ausstehende Gebots - und Angebotsinformationen und zusätzliche Informationen (wie Trades und Kontextdaten) ) Zurück zu den Client-Endgeräten. Jedes Client-Terminal zeigt alle ausstehenden Gebote und Angebote für ein Element an, so dass der Trader Aufträge für Aufträge anzeigen kann. Eine Prioritätsansicht wird bereitgestellt, in der Befehle als Orten an Orten angezeigt werden, die den Werten der Orders entsprechen. Die Größe der Token gibt die Menge der Aufträge wieder. Eine alternative Ansicht positioniert Auftrags-Icons an einem Ort, der den Wert und die Menge des Auftrages widerspiegelt. Zusätzlich werden Kontextdaten für die Position angezeigt, um dem Händler zu ermöglichen, so viele Informationen wie möglich zu berücksichtigen, während er Transaktionsentscheidungen trifft. (19) 1. Verfahren zur Bereitstellung einer Schnittstelle zu einem elektronischen Handelssystem, bei dem a. Ein Verfahren zur Bereitstellung einer Schnittstelle für ein elektronisches Handelssystem vorgesehen ist, Bei dem Aufträge einen Gebotstyp oder einen Angebotstyp umfassen, wobei das Verfahren umfasst: Erzeugen einer Mehrzahl von Preisniveaus, die dem Gut über eine Handelseinrichtung mit einer elektronischen Information entsprechen Prozessor und kommunikativ mit dem elektronischen Handelssystem gekoppelt ist und die Mehrzahl von Preisniveaus entlang einer skalierten Preisachse über einen Ausgang anzeigt, der mit der Handelseinrichtung verbunden ist, die Angebote für das Gute von einer elektronischen Vermittlung über die Handelseinrichtung empfängt und die Gebote in Bezug auf die Mehrzahl anzeigt Der Preisniveaus entlang der skalierten Preisachse über den Ausgabeempfang das Gute von der elektronischen Vermittlung über das Handelsgerät anfordert und die Abfrage bezüglich der Vielzahl von Preisniveaus entlang der skalierten Preisachse über die Ausgabe, die eine Bestellung für die Ware vorlegt, anzeigt Wobei die Benutzeraktion eine Menge und einen Preis für die Bestellung spezifiziert und ein Auftragsindikator entsprechend der platzierten Reihenfolge in Bezug auf die Vielzahl von Preisniveaus entlang der Skalierten Preisachse über die Ausgabe einen bestimmten Preiswert basierend auf einer Formel über die Handelseinrichtung ermittelt und einen Markierungsindikator relativ zu den mehreren Preisniveaus entlang der skalierten Preisachse an einem Ort, der dem spezifischen Preiswert der Markierung entspricht, erzeugt und anzeigt Indikator über die Ausgabe repräsentiert, wobei die Markierungsanzeige die Vielzahl von Preisniveaus entlang der skalierten Preisachse in Abhängigkeit von Änderungen des spezifischen Preiswertes ansteigt oder absteigt. 2. Verfahren nach Anspruch 1, wobei der spezifische Preiswert aktualisiert wird, wenn neue Daten bezüglich einer Variablen der Formel empfangen werden. 3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der spezifische Preiswert aktualisiert wird und das Markierungskennzeichen an einer neuen Stelle relativ zu den mehreren Preisniveaus entlang der Preisachse angezeigt wird, wobei der neue Standort dem aktualisierten spezifischen Preiswert entspricht. 4. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der spezifische Preiswert aktualisiert wird und der aktualisierte spezifische Preiswert zwischen einem ersten Preisniveau und einem zweiten nachfolgenden Preisniveau entlang der skalierten Preisachse liegt, dann wird das Markierungszeichen auf einem neuen angezeigt Ort, der den aktualisierten spezifischen Preiswert repräsentiert, der relativ zu Orten ist, die den ersten Preiswert und den zweiten nachfolgenden Preiswert repräsentieren. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass eine Änderung des spezifischen Preiswertes kleiner ist als die Differenz zwischen zwei nachfolgenden Preiswerten, die entlang der Preiswertachse angezeigt werden. 6. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Markierungsindikator eine senkrecht zur Preiswertachse orientierte Aktionslinie aufweist. 7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Formel direkt von einem Benutzer eingegeben wird. 8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Formel ausgewählt ist aus einer vorgegebenen Liste von Formeln. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Gut eine Ware umfasst. 10. Verfahren zur Erleichterung des Handels und der Anzeige von Informationen für einen Benutzer in Bezug auf den Kauf und Verkauf eines Gutes in einem System, bei dem Aufträge einen Gebotstyp oder einen Angebotstyp umfassen, wobei das Verfahren umfasst: Anzeigen einer Preisachse, die das Gut über einen zugeordneten Ausgang darstellt Wobei eine Handelseinrichtung einen bestimmten Preiswert basierend auf einer Formel über die Handelseinrichtung bestimmt, die eine Aktionslinie senkrecht zur Preisachse über den Ausgang anzeigt, wobei die Aktionslinie dem spezifischen Preiswert entspricht und wobei die Aktionslinie die Aktionslinie ansteigt oder absteigt Preis-Achse abhängig von Änderungen des spezifischen Preiswerts, der einen Befehl erhält, ein Auftragssymbol für eine Menge des Gutes an einer Stelle entlang der Preisachse über eine Benutzereingabe, die dem Handelsgerät zugeordnet ist, zu senden und eine Bestellung an ein elektronisches Handelssystem über zu senden Wobei die Reihenfolge für die Menge des Gutes und für einen bestimmten Preiswert ist, der auf der Grundlage des Ortes bestimmt wird, an dem das Auftragssymbol platziert wurde. 11. Verfahren zum Anzeigen von Informationen über den Kauf und Verkauf eines Gutes in einem elektronischen Handelssystem, bei dem Aufträge einen Bietyp oder einen Angebotstyp umfassen und bei denen diese Aufträge auf der Grundlage einer Zeitpriorität abgeglichen werden, umfassend: Anzeigen einer Werteachse auf einem Grafische Benutzerschnittstelle über einen mit einer Handelseinrichtung verbundenen Ausgang, wobei die Werteachse Werte umfasst, die die Preise für einen guten Empfangsmarkt darstellen, der eine erste Bestellung angibt, und eine zweite Bestellung zu einem Preis an der elektronischen Vermittlung über die a Wobei der erste Auftragsindikator die erste Bestellung über die Handelseinrichtung repräsentiert, die einen zweiten Auftragsindikator erzeugt, um den zweiten Auftrag über die Handelseinrichtung darzustellen und den ersten Auftragsindikator und den zweiten Auftragsindikator an Orten in Bezug auf den Preis entlang der Werteachse über den Ausgang anzuzeigen Wobei die Anordnung der Indikatoren erster und zweiter Ordnung auf einer Zeit basiert, zu der jede Bestellung an der elektronischen Vermittlungsstelle platziert wurde. 12. Verfahren nach einem der Ansprüche 11 bis 12, dadurch gekennzeichnet, dass die Erfassung von Marktdaten, die anzeigen, dass ein dritter Auftrag zu dem Preis an der elektronischen Börse ansteht, einen dritten Auftragsindikator erzeugt, der den dritten Auftragsindikator an einem Ort in Bezug auf den Preis darstellt Entlang der Werteachse und benachbart zu den Indikatoren der ersten und zweiten Ordnung, wobei die Anordnung der Indikatoren für die dritte, zweite und erste Ordnung auf einer Zeit basiert, zu der jede Anordnung an der elektronischen Vermittlungsstelle platziert wurde. 13. Verfahren nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass die erste Reihenfolge zeitlich vor der zweiten und dritten Ordnung platziert wurde, und des Weiteren umfassend: Empfangen einer Benachrichtigung, dass die erste Reihenfolge abgeglichen wurde, und Entfernen des ersten Ordnungsindikators von der Anzeige, Anzeigen der dritten Ordnung für die Anzeige. 14. Verfahren nach einem der Ansprüche 13 bis 14, dadurch gekennzeichnet, dass der zweite Auftrag vor dem dritten Auftrag platziert wird und ferner umfasst: automatisches Verschieben des Indikators zweiter Ordnung zu einer zuvor durch den ersten Auftragsbezeichner besetzten Stelle und automatisches Verschieben des Indikators dritter Ordnung auf a Die zuvor durch den Indikator zweiter Ordnung besetzt wurde. 15. Verfahren nach einem der Ansprüche 11 bis 15, dadurch gekennzeichnet, dass der erste Auftragsindikator mit einem ersten visuellen Merkmal für einen Benutzer angezeigt wird, der den Auftrag erster Ordnung angefordert hat, und den zweiten Auftragsindikator mit einer zweiten visuellen Charakteristik für andere Benutzer anzuzeigen. 16. Verfahren nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, dass die ersten und zweiten Befehle Befehle zum Kauf des Gutes sind oder die ersten und zweiten Befehle Befehle zum Verkauf des Gutes sind. 17. Verfahren nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass die Größe des Indikators erster Ordnung entsprechend der der ersten Ordnung zugeordneten Menge eingestellt wird. 18. Verfahren nach einem der Ansprüche 11 bis 18, dadurch gekennzeichnet, dass die Größe des Indikators zweiter Ordnung der Größe der zweiten Ordnung entspricht. Verfahren nach Anspruch 11, wobei die Wertachse weiterhin den Wert angibt, zu dem das Gut derzeit gehandelt wird, indem ein Höchstgebotsindikator an einem Ort angezeigt wird, der einem aktuellen Höchstgebotswert entspricht, und Anzeigen eines Niedrigangebotsindikators an einer entsprechenden Stelle Zu einem niedrigsten Angebotswert entlang der Werteachse. VERWEIS AUF VERWANDTE ANMELDUNG Diese Anmeldung ist eine Fortsetzung der U. S. Patentanmeldung Nr. Nr. 09289,550, eingereicht am 9. April 1999, US-A - Nr. 7,212,999 mit dem Titel User Interface für ein elektronisches Handelssystem, dessen Inhalt hier durch Bezugnahme vollumfänglich einbezogen wird. Die vorliegende Erfindung betrifft allgemein das Gebiet graphischer Benutzerschnittstellen und insbesondere das Gebiet graphischer Benutzerschnittstellen für elektronische Handelssysteme. HINTERGRUND DER ERFINDUNG Handelsgruben sind das Lebensnerv einer Marktwirtschaft. Mengen von Gütern und Anteilen an Unternehmen werden von Millionen von Investoren gekauft und verkauft. Wenn ein bestimmtes Handelsprodukt oder ein bestimmtes Produkt mehr geschätzt wird, wird der Wert des Gegenstandes als Ergebnis eines aggressiveren Bietens durch die Käufer getrieben. Wenn ein Artikel weniger wertig ist, wird der Wert des Artikels als Folge von aggressiveren Angeboten zum Verkauf des Artikels getrieben. Der erfolgreiche Trader erwartet den Anstieg oder Abfall des Wertes eines Posten und führt seine eigene Transaktion durch, bevor der Rest des Marktes Kenntnis von den Potenzialgewinnen oder - verlusten hat. Daher ist die Vorwegnahme des Marktes und speziell der zukünftigen Nachfrage nach einem Gegenstand von Interesse für den Erfolg eines Händlers entscheidend. Die Transaktionen für jedes Element treten in einer Handelsgrube für diesen Posten auf. Die Handelsgrube ist ein bezeichnetes Gebiet in einer Börse, in der die Kunden ihre Aufträge, entweder Angebote oder Angebote, für den Gegenstand an einen Broker in der Grube einreichen. Die Börse zeichnet alle Transaktionen und Relays oder Positionen an die einzelnen Händler das ausstehende Angebot mit dem höchsten Wert und dem ausstehenden Angebot mit dem niedrigsten Wert für die Position zusammen mit der Menge auf, die in der Bestellung angegeben ist. Die Börse gibt keine Informationen zu allen ausstehenden Angeboten und Angeboten an die Händler ab, weil diese Informationen den Marktteilnehmern einen Vorteil gegenüber den Händlern verschaffen und es den Marktmachern ermöglichen, ihre eigenen Handelsrichtungen schnell zu ändern und voranzutreiben Kundenaufträge und nutzen Kundenlimitaufträge, um die Market Maker vor Verlusten zu schützen. Jedoch erschwert für einen einzelnen Händler, der nur die letzten Bestellinformationen für einen Artikel hat, die Aufgabe des Händlers, Trends in den Aufträgen für einen Artikel zu ermitteln, weil der Händler sehr wenig Informationen über das Volumen der Angebote und Gebote oder die Rate, mit der diese Volumina verfügen, aufweist verändern sich. Weitere Informationen werden auch von dem Händler verwendet, um den Markt vorwegzunehmen, einschließlich der aktuellen Börsenperformance, der historischen Transaktionsdaten für die Position, der Anzahl der Händler an der Grube und der Händler die Bedeutung der Aktivität der Grube. Es ist jedoch oft schwierig für einen Händler, diese Informationen schnell aus verschiedenen und oft nicht zusammenhängenden Quellen zusammenzustellen oder sogar effektiv alle diese Informationen zu verarbeiten, um eine informierte Transaktionsentscheidung zu treffen. Aus diesen Informationen und anderen externen Informationen muss der Händler versuchen, Trends im Kauf oder Verkauf für den Gegenstand zu bestimmen, um den Markt und die Nachfrage nach einem bestimmten Artikel zu antizipieren. Daher wird ein System benötigt, in dem Trendinformationen der Marktnachfrage für eine einzelne Position den Händlern in einem intuitiven Format zur Verfügung gestellt werden, das es Händlern ermöglicht, schnell zu interpretieren, wie sich die Marktnachfrage auf eine Position ändert. Es wird auch ein System benötigt, das dem Trader kontextbezogene Informationen über den Gegenstand oder den Markt liefert, während der Trader auf einer bestimmten Position handelt, so dass der Trader die Informationen schnell interpretieren und dann entsprechend handeln kann. ZUSAMMENFASSUNG DER ERFINDUNG Die vorliegende Erfindung ist eine Benutzerschnittstelle für ein elektronisches Handelssystem, die es einem entfernten Händler erlaubt, Trends in den Aufträgen für ein Element zu sehen und die Handelsinformationen in einem leicht zu sehenden und zu interpretierenden graphischen Format bereitzustellen. Die Benutzerschnittstelle der vorliegenden Erfindung arbeitet in einem System, in dem einzelne Händler Aufträge einschließlich Geboten und Angeboten auf entfernten Client-Endgeräten platzieren und diese Informationen zu einem Transaktionsserver weiterleiten. Der Transaktionsserver empfängt Auftragsinformationen von den entfernten Terminals, passt ein Gebot für ein Element an ein Angebot für ein Element an, das auf das Angebot anspricht, das dem Angebot entspricht, und überträgt ausstehende Gebots - und Angebotsinformationen zurück zu den Client-Endgeräten. Somit zeigt gemäß der vorliegenden Erfindung jedes Client-Terminal alle ausstehenden Angebote und Angebote für einen Gegenstand an, im Gegensatz zu den herkömmlichen Systemen und Verfahren, bei denen dem einzelnen Händler nur das höchste Angebot und das niedrigste Angebot bekannt waren. Dies ermöglicht es dem Trader, Trends in Aufträgen für einen Artikel zu sehen und somit besser dem Händler zu ermöglichen, die Nachfrage nach dem Artikel zu antizipieren. Beispielsweise wird in einer Ausführungsform ein Graph mit einer Wertachse gebildet. Bid-Icons und Angebotssymbole für alle offenen Gebote und Angebote werden auf dem Diagramm an Orten angezeigt, die den Werten der Gebote und Angebote entsprechen. Wenn ein Artikel geboten wird, d. h. die Nachfrage nach dem Artikel wächst, werden alle neuen Gebote dem entfernten Händler angezeigt. Der Händler sieht sofort die steigende Nachfrage nach dem Element, wie es auftritt, und kann folgern, dass das Element in Wert steigen kann, und kann eine Bestellung für den Artikel sofort kaufen, während der Wert für das Element immer noch niedrig erscheint. Im Gegensatz dazu wusste der Händler bei herkömmlichen Systemen nur von der Existenz des höchsten Gebots, und daher wüsste er nicht, dass die Nachfrage nach dem Produkt zunahm. Durch das Öffnen des Buches werden jedoch alle ausstehenden Aufträge an alle entfernten Händler angezeigt, und jeder Händler ist in der Lage, sofort die wachsende Nachfrage zu sehen und seine Position auf dem Markt entsprechend zu maximieren. Die Benutzerschnittstelle der vorliegenden Erfindung präsentiert diese Information in einem intuitiven Format, was dem Händler ermöglicht, fundierte Entscheidungen schnell zu treffen. In einer Prioritätssicht-Ausführungsform werden Gebots - und Angebotssymbole entsprechend einer Achse von Werten angezeigt. Dies führt dazu, dass die Gebotsymbole auf dem unteren Teil des Bildschirms angezeigt werden und die Angebotssymbole auf dem oberen Teil des Bildschirms angezeigt werden. Der Händler ist in der Lage, sofort die Anzahl und das Volumen der Angebote und Angebote für das Element und ihre Differenz im Wert zu erkennen. Die Gebote und Angebote werden vorzugsweise in verschiedenen Farben, Formen oder anderen visuellen Merkmalen dargestellt, wodurch die Händler in der Lage sind, den gegenwärtigen Zustand des Marktes schnell zu ermitteln. Der Bildschirm wird häufig aktualisiert, um die letzten Gebote und Angebote anzuzeigen. In einer Ausführungsform sind die Icons mit einer Kante ausgebildet, die zu der Achse der Werte hin abgewinkelt ist. Wenn alle offenen Angebote und Gebote angezeigt werden, bildet die Anordnung der Symbole natürlich die Kanten eines Dreiecks, das auf die Wertdifferenz an der Werteachse zeigt. In noch einer weiteren Ausführungsform werden den Händlern eigene Gebote und Angebote in einer ersten Farbe oder einer anderen visuellen Eigenschaft angezeigt und die Gebote und Angebote anderer Händler werden in einer zweiten Farbe oder visuellen Charakteristik angezeigt. Dies erlaubt dem Händler, schnell seine relative Position auf dem Markt zu bestimmen. Schließlich stellt in einer bevorzugten Ausführungsform eine Größe der Icons die Menge des Angebots oder Angebots dar, was ein leichtes visuelles Mittel zur Bestimmung der relativen Mengen, die jedes Gebot und Angebot repräsentieren, ermöglicht. In einer Ausführungsform der Wertquantitätsansicht werden eine Achse von Werten und eine Achse von Mengen verwendet, um die Position der Angebots - und Angebotssymbole zu bestimmen. Die Symbole in dieser Ausführungsform sind Markierungen oder Marken und bieten dem Trader ein anderes Aussehen und Gefühl. Durch die Bereitstellung von Alternativansichten kann ein Trader eine Ansicht auswählen, mit der der Trader am komfortabelsten handeln kann. Eine Wertquantifizierungsanalyse wird in einer weiteren Ausführungsform in Bezug auf die Wertachse an einem Ort angezeigt, der dem aktuellen Wert entspricht, den das Analytikum darstellt. Die Analytik wird vorzugsweise als eine Markierung, die Aktionslinie genannt wird, in einer Farbe oder einer anderen visuellen Charakteristik angezeigt, die sich von den anderen Charakteristiken unterscheidet, die verwendet werden, um andere dargestellte Objekte darzustellen. Die Aktionslinie wird von jedem einzelnen Trader ausgewählt und kann das Verhältnis von Wertsteigerungsrate, Volatilität, Verkaufsvolumen oder jede andere Metrik des Traderentwurfs widerspiegeln oder aus einer Liste von vorbestimmten Metriken ausgewählt werden. Die Aktionszeile reagiert auf Änderungen in den Daten, die sie misst und aktualisiert sie im Wesentlichen in Echtzeit. Die Aktionszeile ermöglicht es dem Händler, sofort die aktuelle Bewertung des Gegenstands relativ zu der eigenen Bewertung des Gegenstands zu bestimmen. Wenn sich die Angebote oder Angebote der Handlungslinie nähern, ist der Händler bereit, eine Transaktion in Übereinstimmung mit der Bewertung des Händlers abzuschließen. In einem weiteren Aspekt der Erfindung werden Marktdaten und andere Kontextdaten angezeigt, während der Händler eine der vorgenannten Benutzerschnittstellen betrachtet. Ein historisches Diagramm wird im Hintergrund einer Benutzeroberfläche angezeigt, um zusätzliche Informationen für den Händler bereitzustellen, der den Zustand des Marktes bestimmt und wie er den Wert des Elements beeinflussen kann. Beispielsweise kann die historische Tabelle die verschiedenen Marktindizes, die historischen Werte der Position oder andere und jede andere historische Wert-, Quantitäts - oder Volumenentwicklung darstellen. Das historische Diagramm kann den durchschnittlichen Wert des Elements über einen Zeitraum darstellen oder einen Wert oder Werte für jede andere Position oder Gruppe von Elementen darstellen. Das historische Diagramm wird in Bezug auf eine vertikale Achse von Werten angezeigt und wird in Abhängigkeit von der Zeit horizontal angezeigt. Das historische Diagramm wird aktualisiert, um dem Trader die neuesten Informationen zur Verfügung zu stellen, während der Trader handelt. Somit ist der Händler gemäß der vorliegenden Erfindung in der Lage, sofortige Entscheidungen bezüglich eines Elements zu treffen, während er kritische Informationen über andere Elemente oder die vergangene Leistung des aktuellen Elements und anderer Indizes empfängt. Dies ist ein großer Vorteil gegenüber herkömmlichen Handelsmethoden, bei denen diese Information nicht gleichzeitig bereitgestellt wird, und wenn überhaupt präsentiert, ist es schwierig, schnell zu verarbeiten. Eine alternative Ausführungsform stellt eine Trading-Pit-Ansicht bereit, die Händler-Icons für jeden Trader anzeigt und die Trader-Icons platziert, die das Aktivitätsniveau des Traders widerspiegeln. Bodenmakler und andere Umstehende werden ebenfalls angezeigt und identifiziert, um es dem Händler zu ermöglichen, auf einen Blick die jeweiligen Positionen und Aktivitäten aller Benutzer zu verstehen, die derzeit mit dem Transaktionsserver für diese Handelsgrube verbunden sind. Die Auswahl eines Händler-Symbols bietet Informationen über den Händler und kann ein Fenster öffnen, um es den Händlern zu ermöglichen, miteinander unter Verwendung einer oder mehrerer Methoden zu kommunizieren, einschließlich elektronischer Post, Textchat oder Kommunikation per Sprache über eine Netzwerkverbindung. Die Trading-Pit-Ansicht ermöglicht es dem Fernhänd - ler, sofort zu ermitteln, von wem der Trader gehandelt wird, wie aktiv er ist, und ermöglicht dem Händler, den Markt besser zu antizipieren. KURZBESCHREIBUNG DER ZEICHNUNGEN 1 ist ein Blockdiagramm einer bevorzugten Ausführungsform des elektronischen Handelssystems der vorliegenden Erfindung. FEIGE. 2 ist ein Blockdiagramm einer bevorzugten Ausführungsform des Transaktionsmanagers der vorliegenden Erfindung. Fig. 3a - 3c sind Screenshots, die eine Ausführungsform einer Prioritätsansicht gemäß der vorliegenden Erfindung darstellen. FEIGE. 3d veranschaulicht ein Pop-Up-Fenster für die Bestellung. FEIGE. 3e zeigt ein Verkaufsbestell-Popup-Fenster. FEIGE. 4 ist ein Screenshot, der eine Ausführungsform einer ValueQuantity-Ansicht gemäß der vorliegenden Erfindung darstellt. FEIGE. 5 ist ein Flussdiagramm, das eine bevorzugte Ausführungsform eines Verfahrens zum Anzeigen von Gebots - und Angebotssymbolen gemäß der vorliegenden Erfindung darstellt. FEIGE. 6 ist ein Flussdiagramm, das eine bevorzugte Ausführungsform eines Verfahrens zum Erzeugen eines Bid-Order-Symbols gemäß der vorliegenden Erfindung darstellt. FEIGE. 7 ist ein Flussdiagramm, das eine bevorzugte Ausführungsform eines Verfahrens zum Erzeugen eines Angebotsordnungssymbols gemäß der vorliegenden Erfindung darstellt. FEIGE. 8 ist ein Flussdiagramm, das eine alternative Ausführungsform zum Erzeugen eines Auftragssymbols darstellt. FEIGE. 9 ist ein Screenshot, der eine Pit-Panel-Ansicht gemäß der vorliegenden Erfindung darstellt. FEIGE. 10 ist ein Flussdiagramm, das eine bevorzugte Ausführungsform des Erzeugens und Platzierens eines Händlersymbols gemäß der vorliegenden Erfindung darstellt. FEIGE. 11 ist ein Screenshot, der ein Kommunikationsfenster gemäß der vorliegenden Erfindung darstellt. DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM 1 zeigt das elektronische Handelssystem gemäß der vorliegenden Erfindung. Die Client-Endgeräte 104 sind mit einem Transaktionsmanager 100 gekoppelt. Die Client-Endgeräte 104 sind Personalcomputer, Endgeräte als Teil eines Netzwerks oder irgendein anderes Rechengerät. Händler verwenden die Client-Endgeräte 104, um mit Handelspits zu interagieren, die von dem Transaktionsmanager 100 verwaltet werden. Der Transaktionsmanager 100 verwaltet die von den Client-Endgeräten 104 erzeugten Transaktionsanforderungen. Leitet Informationen zu, von und zwischen den Terminals 104 und dem Transaktionsmanager 100 weiter. Und speichert und ruft Informationen aus einer Datenbank 108 oder Datenbanken 108 ab. FEIGE. 2 zeigt eine spezifischere Ausführungsform des Transaktionsmanagers 100. Die Clients 104 sind mit dem Anmeldungsmanager 204 gekoppelt, um jedem Clientzugriff auf den Transaktionsmanager 100 zur Verfügung zu stellen. Und jedem Client 104 zu gestatten, eine oder mehrere Handelsvertiefungen 220 zu bestimmen, mit denen verbunden werden soll. Der Transaktionsmanager 100 hostet einen oder mehrere Transaktionsprozessoren 200. Jeder Transaktionsprozessor 200 ist für den Handel eines bestimmten Elements verantwortlich, der im Wesentlichen eine bestimmte Handelsgrube unterstützt. Die Zusammenfassungsinformations-Agenten 224 für jeden Transaktionsprozessor 220 liefern einen aktuellen Status der Aktivität jeder Grube 220 an einen Händler, der mit dem Anmeldungs-Manager 204 verbunden ist. Der Händler kann ein Pit 220 auswählen, zu dem es auf der Grundlage der Zusammenfassungsinformation verbunden werden soll. Sobald der Anmeldeprozess abgeschlossen ist, sind die Clients 104 mit einem Registrierungsserver 212 für die bestimmte Handelsvertiefung 220 gekoppelt. Die Registrierung für jede Grube 220 erfordert, dass der Client 104 einen Zugangsschlüssel bereitstellt, den er von dem Anmeldeverwalter 204 während der Anmeldung erhalten hat. Nach der Registrierung für eine Grube 220. Kann der Händler Aufträge für den Gegenstand, der in der Handelsgrube 220 gehandelt wird, hinzufügen, ändern oder löschen. Eine Art eines Auftrags, der als Gebot bezeichnet wird, ist ein Auftrag, bis zu einer bestimmten Menge eines Artikels bei oder unter einem bestimmten Wert zu kaufen. Eine andere Art einer Bestellung, die als Angebot bezeichnet wird, ist ein Auftrag, bis zu einer bestimmten Menge eines Artikels an oder über einem bestimmten Wert zu verkaufen. Andere Arten von Aufträgen sind je nach Art des Gegenstandes, der in der Handelsgrube 220 gehandelt wird, möglich. Jede Grube 220 enthält einen Transaktionsserver 200. Der Transaktionsserver 200 empfängt Aufträge, überträgt Angebote und Angebote (wenn ein Angebot und ein Angebot aufeinander abgestimmt sind, wird es als Handel oder Ausführung bezeichnet) und leitet Informationen sowohl an die Datenbank 208 als auch an die Client-Terminals 104, die mit der Handelsvertiefung 220 verbunden sind. Die Client-Endgeräte 104 erzeugen Icons für Gebots - und Angebotsaufträge (Bid - und Offer-Icons), historische Charts und Trader-Icons und bestimmen die Platzierung von Gebots - und Angebotssymbolen und Trader-Icons in Reaktion auf die von dem Transaktionsserver 200 empfangenen Informationen. Die Datenbank 208, mit der der Transaktionsserver 220 gekoppelt ist, speichert die Informationen, die jedem Trader entsprechen, Informationen über jeden über einen Zeitraum (wie Beginn der Handelstage) übermittelten Auftrag, Informationen über jeden Handel über einen Zeitraum (wie zum Beispiel die letzten 180 Tage) ) Und die Information, die dem gehandelten Gegenstand entspricht. Jeder Händler kann Informationen enthalten, die mit dem gespeicherten Händlerkonto verknüpft sind, einschließlich eines Namens, E-Mail-Kontos, Adresse, Telefonnummer, persönlicher Wertquantifizierungsmetrik oder analytischer Aktivitätspegelhistorie und verschiedener anderer Informationen, die für den einzelnen Händler eindeutig sind Durch die vorliegende Erfindung verwendet werden, um eine virtuelle Handelsumgebung zu schaffen. Die Informationen, die jeder Bestellung entsprechen, beinhalten, ob es sich um einen neuen Auftrag, um Änderungen eines bestehenden Auftrags oder um die Streichung eines zuvor übermittelten Auftrags, um die Art der Bestellung (zB Angebot oder Angebot), um den Wert, die Menge, Das Datum, an dem die Bestellung eingegangen ist, und alle anderen für die Bestellung spezifischen Informationen. Die Informationen, die jedem Handel entsprechen, umfassen den Wert, die Menge, den Käufer und den Verkäufer. Die Informationen, die dem Gegenstand entsprechen, der gehandelt wird, umfassen den höchsten ausstehenden Bidwert und den niedrigsten ausstehenden Angebotswert für die Position sowie eine Liste der Werte aller offenen Bestellungen für die Position. Die Artikelinformation wird auf der Datenbank 208 in einer Datenstruktur, wie beispielsweise einer Auftragstabelle, gespeichert. Der Server 200 aktualisiert die Informationen in der Reihenfolgestabelle abhängig von dem Empfangen von Informationen von den Client-Endgeräten 104. Die aktualisierten Informationen werden dann zurück zu den Client-Endgeräten 104 übertragen. Andere Informationen, wie beispielsweise Informationen, die beim Erstellen von historischen Diagrammen verwendet werden, können auch in der Datenbank 208 gespeichert werden. Informationen, die global zu mehr als einer Grube 220 sein können. Beispielsweise Händlerdaten, auch auf der Systemdatenbank 108 gespeichert. Um zu ermöglichen, daß die Information von jeder Handelsgrube 220 zugegriffen wird. Für Händler, die in derselben Handelsgrube angemeldet sind 220. Werden alle Aufträge (d. H. Gebote oder Angebote, die einen Wert und eine Menge angeben) an den Transaktionsserver 200 für diese Grube 220 übertragen. Der Server 200 analysiert die Aufträge für Spiele mit hervorragenden oder offenen Aufträgen. Wenn zwischen Aufträgen verschiedener Typen, beispielsweise zwischen einem Angebot und einem Angebot, eine Übereinstimmung stattfindet, wird eine Transaktion durchgeführt und die Client-Endgeräte 104 werden benachrichtigt, um die übereinstimmenden Symbole zu entfernen. Alle ausstehenden Bestellungen werden an jedes Client-Terminal übertragen, so dass ein Händler alle ausstehenden Bestellungen von allen Händlern zu einem beliebigen Zeitpunkt für ein Element auf einer Handelsgrube anzeigen kann. Die Clientanzeigen werden kontinuierlich oder in bestimmten Intervallen aktualisiert, um aktualisierte Informationen darüber zu liefern, welche Aufträge ausstehend sind, und der Zustand des Marktes in der Grube 220. Wie in Fig. 2. Mehrfachhandelsvertiefungen 220 sind in dem elektronischen Handelssystem vorgesehen, und ein einzelner Händler kann zu der gleichen Zeit wie gewünscht mit so vielen Vertiefungen 220 verbunden sein. Die Anzahl der Handelsvertiefungen 220, die gemäß der vorliegenden Erfindung beibehalten werden können, ist abhängig von der Anzahl der Server, die in dem System bereitgestellt werden, skalierbar. Die Handelsgegenstände umfassen jegliche mögliche Ware, z. B. Mineralien, Futures oder Aktien eines Unternehmens. Andere Netzwerkkonfigurationen können verwendet werden, um das elektronische Handelssystem zu implementieren, wie es dem Fachmann bekannt ist. Die Client-Endgeräte 104 stellen die interaktive Verbindung zwischen den Händlern und den Handelsvertiefungen 220 bereit. Und zeigen die verschiedenen Benutzerschnittstellen der vorliegenden Erfindung. FEIGE. 3a veranschaulicht eine Prioritätsansicht 312, die so ausgelegt ist, dass die Händler die Anordnungen 300 intuitiv platzieren können. 304 und Ansichtsmarkierungen 336, die wertquantisierende Metriken darstellen, und kontextbezogene Trenddaten 316 gemäß der vorliegenden Erfindung. Bei der Ausführungsform der Prioritätsansicht werden die Aufträge 300. 304 werden an einer Stelle angezeigt, die ihrem Wert in Bezug auf die Werteachse 332 entspricht. Die Werte können Preis, Zinssatz oder andere Metrik darstellen, durch die eine Position bewertet werden kann. Beispielsweise hat das Angebot 304 (1) einen Wert von 28,45 und der niedrigste Punkt der unteren Kante 308 des Symbols 304 (1) ist mit dem Wert 28,45 auf der Werteachse 332 ausgerichtet. Bei dieser Ausführungsform sind die oberen Kanten 309 der Gebote und unteren Kanten 308 der Angebotssymbole abgewinkelt. Das höchste Gebot ist das Gebot mit dem höchsten Wert, und das rechteste Angebot ist das Angebot mit dem niedrigsten Wert. Dies ermöglicht die Kanten 308. 309 der Symbole 300. 304, um ein Dreieck zu bilden, das auf die Werttrennung zwischen dem letzten niedrigsten Angebot und dem letzten höchsten Gebot hinweist. Die Menge jeder Bestellung wird durch eine Größe des Symbols, wie etwa seine Länge oder Höhe, dargestellt. Icons mit einer grßeren Grße repräsentieren Ordnungen mit einer grßeren Grße. Die spezifische Menge und andere Informationen eines auf dem Bildschirm angezeigten Auftrags können durch Auswählen dieser Reihenfolge bekannt sein, die ein Popup-Fenster aufruft, um den genauen Wert und die Menge der ausgewählten Reihenfolge anzuzeigen. In einer alternativen Ausführungsform werden die spezifischen Auftragsinformationen in der Auftragsaufgabenleiste 328 angezeigt. Als Reaktion auf einen Händler, der ein Gebots - oder Angebotssymbol auswählt, sofern der Auftrag vom Händler, der die Bestellung auswählt, eingereicht wurde. Alternativ, wenn Platz erlaubt, können die Menge und Wert in der Ikone selbst angezeigt. Wenn mehrere Aufträge mit gleichem Wert vorliegen, werden die Aufträge in Abhängigkeit von dem Zeitpunkt, zu dem der Auftrag platziert wurde, gestapelt oder nebeneinander angeordnet. Beispielsweise haben die Gebote 300 (5), 300 (6), 300 (7) gleiche Werte bei 29,50. Daher sind alle drei Gebotsymbole 300 vertikal gestapelt. Ein bevorzugtes Verfahren zum Stapeln legt die ältesten Ordnungen am nächsten an den horizontalen Raum, der natürlich auftritt und die Angebote und Angebote abtrennt. Die horizontale Trennung zwischen den Angeboten und Angeboten erfolgt natürlich, weil alle angezeigten Gebote stets einen niedrigeren Wert als die angezeigten Angebote haben. Wenn ein Gebot auf einen Wert platziert wird, der einem Angebotswert entspricht oder diesen übersteigt, wird eine Transaktion sofort durchgeführt und die Icons entfernt. Zum Beispiel können in dem Stapel, der die Ordnungen 300 (7), 300 (6) und 300 (5) in Fig. 3a. Das erste und damit das älteste Gebot in der Zeit war 300 (7) und ist an der Spitze des Stapels, am nächsten an der horizontalen Trennung zwischen den angezeigten Gebote und Angebote platziert. Die anderen zwei gestapelten Gebote 300 (6), 300 (5) sind unter dem ältesten Gebot 300 (7) angeordnet, entsprechend dem Zeitpunkt, zu dem sie eingereicht wurden, und sortiert in der Reihenfolge der ältesten bis neuesten. In dem Stapel, der die Angebote 304 (2), 304 (3) und 304 (4) enthält, wird das älteste Angebot 304 (2) auf dem Boden des Stapels positioniert, Ist auf der Oberseite des Stapels positioniert. Das obige Verfahren zur Bestellung von Angeboten und Angeboten ist ein bevorzugtes Verfahren, jedoch können auch andere Sortierungsschemata innerhalb des Umfangs der vorliegenden Erfindung verwendet werden. The trader using the client terminal 104 in accordance with the present invention, is shown all of the outstanding orders 300 . 304 for the item being traded. This is one significant difference between the present invention and conventional systems because a trader using a system in accordance with the present invention is able to view trends in the bids and offers in addition to the buying and selling of the item being traded. For example, in FIG. 3 a . a trader can quickly analyze the outstanding orders 300 . 304 . and determine that there are an almost equal number of bids 300 ( 8 ) as offers ( 9 ). Thus, the trader may infer that the market is stable, and the value for the item will not be dramatically driven up or down in the near future. Accordingly, the trader may decide to take no action. However, as shown in FIG. 3 b . if demand builds through an increased number of bids being made, as shown by the display of an increased number of bid icons 300 . or bids are being made for large quantities, as shown by the display of bid icons 300 having a greater size, and if supply recedes as indicated by the display of a reduced number of offers icons 304 . the trader can anticipate that the value for the item will increase. Consequently, the trader will place bids for the currently low valued offers 304 . Thus, by viewing all outstanding offer icons 304 and bid icons 300 as they are made on an item, the trader can anticipate the market and quickly adjust his or her trading plans to take advantage of the information. In contrast, in conventional systems, the trader only knows the last highest bid and the last highest offer. In the example of FIG. 3 a . the trader would only know the existence of bid 300 ( 9 ) and offer 304 ( 1 ). Only the market maker would know of the existence of the other bids and offers. Individual traders would therefore be unaware of trends in bidding, and experience greater difficulty in anticipating the market. The trader can also view the gap between offer icons 304 and bid icons 300 to determine at what value sales may be made and for what quantity. In the example of FIG. 3 a . the trader can determine that there are several bids 300 ( 5 ), 300 ( 6 ), 300 ( 7 ), at a value slightly less than 27.35. Therefore, if the trader has a number of items to sell, the trader can make offers at that value and be assured of a sale of all of his or her items. However, if this value is too low, the trader can choose to keep all of his items until the value of the item has risen, which would be reflected in the display of additional bid icons at a higher value position in the screen. In contrast, if a trader was using a conventional system, the trader would have to offer his items incrementally, without knowing in advance when sales are likely to be made. The value axis 332 indicates the value at which an item is being traded. This value may represent different qualitative measures for an item, such as the raw price for the item for bonds, the value could be the cost for the bond or the implied interest rate for the bond, or the value be used as a measure for an implied volatility of the item, for example, a generic measurement of the relative expense of an option. Each trader can use their own value scale. For example, one trader may use a bond cost as an axis of values and another may use the implied interest rate of the bond. Regardless of a traders choice of value, the different orders are displayed on the traders screen in terms of the value the trader is chosen. Additionally, the value scales are completely customizable. For example, a gold arbitrageur could create a scale that measures the difference between the futures price of the metal less the spot cash price of the metal. The arbitrageur could then apply the cost of carry, including insurance and storage, to the futurecash price difference to generate an implied interest rate for the gold. Thus, the value axis for the arbitrageur would be an interest rate. In another example a trader who is interested in trading soybean oil could buy and sell soybeans, but, by using a value axis which accounts for the current cost of crushing soybeans, storage of soybeans, transport, etc, can be actually trading in soybean oil. Thus different traders in the same trading pit 220 would see the same bid and offers but organized with respect to their own specific value axis. Thus, the present invention provides enormous flexibility in constructing a view of an items value which is directly representative of the traders own interest in the item. The priority view 312 offers several other advantages to a trader. The offers 304 and the bids 300 are displayed in different colors, shapes, textures or sizes, or other distinguishing visual characteristics, to allow the trader to quickly ascertain the current state of the market for this item. Additionally, orders made by the trader are displayed having a different visual characteristic than the visual characteristic used to display orders of other traders. This allows the trader to easily distinguish between their own orders and the orders of other traders. For example, in FIG. 3 a . the trader is able to immediately determine that offers 304 ( 3 ) and 304 ( 7 ) are the traders own offers 304 . and therefore should be discounted from any market analysis. In FIG. 3 a . the trader can also quickly determine that the trader himself is the trader with the most bids 300 in place, which suggests to the trader that the value for the item may be driven down if the trader removes his bids 300 from the pit 220 . Orders can be placed by a trader using the user interface of the present invention in variety of ways. In one embodiment, as shown in FIG. 3 a . the trader can directly submit an order by using the order task bar 328 . The options to specify value and quantity of either a bid or offer, and the expiration period are provided. After the information is entered, the trader selects Place Order, and the order is submitted to the transaction server 200 for the pit 220 . and an offer or bid icon 304 . 300 is generated and displayed at the desired location at the desired size. The order information is communicated to the transaction server 200 and from there to the other client terminals, so that the new bidoffer appears in the displays of all other traders in this same pit. In a preferred embodiment, the trader submits an order by simply selecting either an offer token 324 or bid token 320 using a pointing device. After being selected, the trader adjusts the size of the offer or bid token 324 . 320 until the size of the token matches the desired quantity of the order. Preferably, a pop-up window or other screen indicator is displayed to show in numerical terms the quantity of the current size of the token, to ease the process of creating a properly sized order token. Next, the token is dragged to a location on the screen which corresponds to the desired value of the order. Again, a screen indicator displays the current value for the token at its current location as it is being dragged to allow precise placement of the token at the desired value. In the embodiment of FIG. 3 a . a value marker 344 follows bid token 320 as it is moved to a location in the display. The value marker 344 indicates the value of the new order as the order is being placed. This allows for the trader to easily and precisely move the token 320 . 324 to the desired value. After reaching the desired value, the trader releases the pointing device button and a Buy pop-up window 350 . as shown in FIG. 3 d . is displayed with the bid order information. The Buy pop-up window 350 allows the trader to modify the order information (value, quantity, expiration), cancel the order or submit the order with the presently displayed information. If the order is to sell an item, a Sell pop-up window 354 is displayed, as shown in FIG. 3 e . After the order is submitted to the transaction server, it will be displayed on the screens of all traders in this trading pit connected to the transaction server 200 . An additional feature of the user interface of the present invention is the provision of contextual data. Contextual data comprises historical trading data of the item, historical or current trading data of other items, historical or current trading data of an average of items. For example, the trader may wish to have the Dow Jones Average displayed on the screen, and updated in realtime. Viewing contextual data along with the outstanding offers and bids allows the trader to better anticipate the market. For example, if the Dow Jones average is used as the contextual data, and is falling sharply, the trader may decide to begin selling his items even though the value of the item in the pit 220 has been stable. This allows the trader to anticipate where the market is headed. Any type of data useful to the trader can be displayed as contextual data. The contextual data 316 is preferably displayed as a historical chart 316 along a vertical axis of values and against a horizontal axis of time. The historical chart 316 can be displayed against any time period, for example, hours, minutes, etc. The historical chart 316 is updated periodically as the data for the item is updated. If the historical chart 316 includes the current item, as shown in FIG. 3 a . bar lines are displayed in the data to indicate the high and low values of the item for that time period. A volume graph 340 is displayed at the bottom edge of graph. The volume graph illustrates the volume of transactions in the pit 220 . and gives additional information to the trader regarding the state of the market for the item. Yet another feature of the user interface of the present invention is the display of a marker 336 . The marker 336 is representative of a value quantifying metric specified by the trader. The metric determines a current action value for the item which identifies the value at which the trader should act if the value of the item rises above the action value or falls beneath the action value. For example, in FIG. 3 b . the value quantifying metric generates an action value of 68.57. The marker 336 is displayed at this value to indicate to the trader the location of the action value in relation to the current bids 300 and offers 304 . In the example of FIG. 3 b . the marker is displayed as an action line 336 . As can be seen, the outstanding bids are below the action line 336 and the current offers are above the action line 336 . This indicates to the trader that no action should be taken. The value quantifying metric can be an algorithm or formula based upon factors the trader believes are important in ascertaining the true worth of an item. This metric can be set to reflect value-to-earnings ratio, volatility, volume of orders, percent gain, or any simple or complex design. The trader can input a custom metric or can select a metric from a predesignated list of metrics. Metrics may also be purchased from 3 rd parties and incorporated into the client terminal 104 . This allows new metrics to be added at any time. The action value displayed by metrics are dynamically determined either by the client terminal 104 or the server 200 . and updated whenever new data is received regarding a component of the metric. Thus, the trader is given the latest information to update the traders action line 336 . allowing the trader to make current, informed decisions regarding possible orders. For example, in FIG. 3 c . the metric has been updated from the time of FIG. 3 b . The action line 336 has moved corresponding to the new action value of 80.21. As can be seen displaying the updated action line 336 allows the trader to immediately determine that the outstanding offers are now below his action line 336 . and therefore that these offers should be purchased despite the fact that the offers themselves remained at the same value from the time of FIG. 3 b to the time of FIG. 3 c. As discussed above, a trader may be connected to several trading pits 220 at once. If a trader has multiple connections, the trader can view the different pits 220 simultaneously, or if the trader wishes to concentrate on a single item, the trader can have only one pit 220 displayed. Additionally, the trader can disable the different options for a view to suit the traders preferences, and maximize visibility for a traders particular terminal 104 . FIG. 4 illustrates an alternate view of the user interface in accordance with the present invention. The valuequantity view 420 illustrates the market for the item using a first axis of values 408 and a second axis 412 for quantity. Thus, the location of each offer icon 400 and each bid icon 404 represents the value for the offer or bid and the quantity for which the offer or bid is made. Optionally, the action line 336 is also displayed, as well as the contextual data. The alternate view provides a different intuitive perspective on the state of the market. By providing alternate views, as shown in FIG. 3 c . the electronic trading system of the present invention allows the different preferences of different traders to be met. Orders in this view are placed by selecting an offer token 416 or a bid token 412 and moving the token to a location which corresponds to the desired quantity and value. If the trader wishes to purchase immediately, the trader can simply drag a bid token 412 to the location directly over any offer token, and a window pops up displaying a bid order with value and quantity equal to that of the offer token. If the trader wishes to sell immediately, the trader can simply drag an offer token 416 to the location directly over any bid token, and a window pops up displaying an offer order with value and quantity equal to that of the bid token. The trader can then execute the transaction. FIG. 5 is a flow chart illustrating a preferred embodiment of the user interface in accordance with the present invention. The client terminal 104 . through data received from the transaction server 200 . displays 500 at least one outstanding bid icon corresponding to a quantity and value of the bid. The client terminal 104 also displays 504 at least one outstanding offer icon corresponding to a quantity and value of an offer. Thus, by displaying at least one outstanding bid and offer icon, the book is opened and traders viewing the client terminal can readily spot trends in supply and demand for an item and quickly anticipate the market. FIG. 6 illustrates an embodiment of a method of generating an order icon in accordance with the priority view 312 of the present invention. First, the client terminal 104 receives 600 the order type. The order can be either a bid or an offer. The trader specifies the type by selecting an offer or bid token to place the order, or by manually indicating the order type on the task bar. Second, the client terminal 104 receives 604 a quantity specified for the order. The quantity, as described above, is specified by the trader either by entering the number directly into the order task bar or by adjusting the size of the order token. In an embodiment where the order information is entered into the taskbar, an order icon will be generated 608 whose vertical size matches the quantity specified after the order has been processed by the server 200 . The client terminal 104 then receives 612 a value for the order. Again the trader can specify the value by entering the information into the taskbar or can drag the order token to the location corresponding to the value. Finally, the client terminal 104 displays 614 an order confirmation window displaying the value, quantity, and expiration information. The trader can modify the order in this window and then must either cancel the order by closing the window or pressing the cancel button or submit it by pressing the OK button. The client terminal 104 which receives the value and quantity and order type information transmits 616 the information to the server 200 . The server 200 then processes the order information, and updates the order table. Once the server 200 transmits updated order information to a client terminal 104 . the client terminal 104 . in the priority view, determines 618 whether a slot is open adjacent an existing order which has a lower value, if the order is a bid, or a higher value, if the order is an offer. In the priority view 312 . the horizontal axis is divided into slots, each slot having a width equal to an order icon 300 . 304 and each slot separated by a standard set-off unit. Incoming orders are sorted by the value of the order. For offers, the offers with the lowest values are positioned closest to the axis of values 332 . and for bids, the bids with the highest values are positioned closest to the axis of values 332 . When a new order is received, the client terminal 104 re-sorts the outstanding orders and places the order icons 300 . 304 in the appropriate positions. If a new order is equal to an existing order of the same type, the order is stacked onto the existing order. FIG. 6 illustrates a more detailed methodology of the sorting mechanism, using the example of placing a new bid. However, the methodology is equally applicable to placing a new offer. A new bid is designated for the slot adjacent an existing bid which has the least value of the set of existing bids having values greater than the value of the new bid. The client terminal 104 determines 618 whether this determined slot has an existing bid within it. If it does not, the icon is placed 636 at the determined slot. If the slot does contain an existing bid, the client terminal 104 determines 620 whether the existing bid has a value less than the requested bid. All existing bids that have values less than the requested bid are moved 640 to the adjacent slot positioned away from the axis of values 332 . In the example of FIG. 3 a . the adjacent slot would be a slot positioned to the left. All other bids having values less than the requested bid are shifted 640 correspondingly. If the client terminal determines 624 that the existing bid has a value equal to the existing bid, the requested bid is stacked 632 below the existing bid or bids, away from the horizontal separation between bids and offers as described above. If the client terminal 104 determines 628 that the existing bid is greater than the requested bid, a new slot is determined 628 for the requested bid, and the process is repeated. As shown in FIG. 7. upon receiving new bid information, the transaction server 200 determines 700 whether there is an existing offer in the order table having a value less than or equal to the requested bid. If there is not, the new bid is added to the table, and the information regarding the new bid is sent 702 to the client terminals 104 for display. If there is an existing offer whose value is less than or equal to the requested bid, i. e. if the new bid is the highest value bid outstanding, the server 200 determines 704 whether the existing offer has a quantity which is less than the quantity represented by the bid. If the offer does have a quantity less than the bid, the server removes 706 the offer from the order table and adds a new bid to the order table with the quantity reduced by the quantity of the offer removed. The server 200 records 720 a trade between the trader submitting the new bid and the trader submitting the removed offer, at a value equal to the offer value and a quantity equal to the offer quantity. All of the outstanding client terminals 104 are sent the information regarding the trade. The client terminals 104 then remove the existing offer icon and add a bid icon which has a size corresponding to the difference in quantities between the existing offer icon and the requested bid icon. The transaction server 200 determines 700 again whether there is another existing offer in the order table having a value less than or equal to the requested bid to determine if another transaction can be made with the quantity remaining in the bid. The server 200 also determines 708 whether the offer has a quantity greater than the quantity of the requested bid. If it does, the quantity of the offer is reduced 716 by the quantity of the bid, and the updated offer information is sent 717 to the client terminals 104 for display. A trade is recorded 720 between the trader submitting the new bid and the trader who submitted the offer at a value equal to the offer value and a quantity equal to the bid quantity. All of the outstanding client terminals 104 are sent the information regarding the trade and update the user interface displays accordingly. If the quantities of the bid and offer are equal, the offer is removed 712 from the table and the transaction is complete. A trade is recorded 720 between the trader submitting the new bid and the trader who submitted the offer at a value equal to the offer value and a quantity equal to the bid quantity. All of the outstanding client terminals 104 are sent the information regarding the trade, and update the user interface displays accordingly. As shown in FIG. 8. in the valuequantity view, the client terminal 104 receives 800 a value, receives 804 a quantity, and receives 806 an order type for a new order. A confirmation window is displayed 807 . and, upon confirmation of the order, the order information is transmitted to the server 200 . Again, this may occur responsive to the trader entering in the information directly or dragging an order token to the proper location and after confirming the order. The server 200 receives the order information, updates the order table, and sends the updated information to the client terminals 104 . The client terminals 104 display a new order icon at a location corresponding to the value and quantity of the order with respect to the axis of quantities and axis of values. If the new order is an offer, and there is an existing bid for a value higher than or equal to the value of the offer, a transaction is completed, and a new offer or a modified bid token is displayed responsive to the quantities that the original offer and bid icons represented. FIG. 9 illustrates a trading pit view 900 called the pit panel view 900 . in accordance with the present invention. The pit panel view 900 provides a visual interface to other members of the pit 220 . All users who are currently registered to the pit 220 are displayed in the pit panel 900 . This is critical information to a trader regarding the activity of the pit 220 . If the pit 220 is crowded, the trader can expect volatility in trading. If the pit 220 is empty, the trader can expect light trading and relatively stable values for the item. The pit panel 900 displays trader icons 912 . observer icons 904 . and floor broker icons 908 . Observers are users who are registered to the pit 220 but who are not actively trading and floor brokers are individuals who have expertise on a pits item and traders, and who assist traders in executing unusual trades, negotiating a deal with multiple traders, or providing history and information on traders to others. As the observers do not trade for themselves, their icons 904 are placed on the outside of the pit icon 916 . Floor brokers who do not trade also have their icons 908 placed on the outside of the pit icon 916 . The trader icons 912 are displayed on the pit icon 916 . The pit icon 916 is preferably displayed as a series of concentric polygons, where each polygon represents an activity level or levels. Traders who are more active are placed closer to the center of the pit icon 916 . The most active trader, in the example of FIG. 9. trader 912 ( 1 ), is placed in the center of the pit icon 916 . In a preferred embodiment, each polygon represents a range of activity levels. For example, the innermost polygon contains the traders with the second through ninth highest activity levels. The next polygon contains the traders having the tenth through twenty-sixth highest activity levels, and so forth. By grouping traders into activity ranges, and thus shifting a traders icon out of a polygon only in response to the traders activity level shifting out of the range represented by the polygon, icon changes and consequent flicker in the display of the pit icon 916 are minimized. However, a trader is able to easily ascertain who the active traders in a pit 220 are and how active the traders are by noting the relative locations of the trader icons 912 in the pit icon 916 . Each trader icon 912 has order indicators 913 to show the quantity of orders a trader has outstanding. Preferably, there are separate indicators 913 for bids and offers, each showing the volume of outstanding bids or offers the trader currently has placed. Other order indicators 913 may be optionally displayed, for example, indicating the sum of all quantities of orders or the volume of orders entered over a specified period of time. Selecting a traders icon 912 will also highlight the traders orders on the priority view, valuequantity view, and other views provided in the system that display orders and which can all be displayed concurrently. Double clicking on a trader icon 912 generates a communication window as shown in FIG. 111 which allows the trader to send an email message 1108 . send an instant message 1104 as part of a text chat session, communicate by voice over the network connection 1112 . or set up a later telephone call or other optional communication to the selected other trader. Thus, the pit panel 900 provides a sense of community in the pit 220 by visual representing useful information, and provides additional information to the trader which the trader can use in anticipating the market. FIG. 10 is a flow chart illustrating a preferred embodiment of generating and placing a trader icon in accordance with the present invention. First, a trading pit icon 916 is displayed 1000 . Next, the client 104 determines 1004 whether a predetermined period of time has passed. The pit panel data is updated periodically, and the client 104 waits for that amount of time before re-generating the display with the new data. If the server 200 determines 1004 that the predetermined period has expired, a first trader icon is selected 1008 . The client 104 determines 1010 whether the trader is still connected to the server 200 from the data provided by the server 200 . If the trader is not, the trader icon 912 for the trader is removed 1011 . and the client 104 determines 1020 whether there are more traders. If the trader is still connected, an activity level is determined 1012 for the trader. Activity levels are determined as a combination of the volume of outstanding orders, the value of outstanding orders, recent activity, or other measures which determine how active a trader has been. Once the activity level has been determined, the client 104 displays 1016 the icon 912 for the trader at the location corresponding to the activity level. In an embodiment where order indicators 913 are displayed, the order indicators 913 are updated to include the latest order data. In the preferred embodiment, as discussed above, the pit icon 916 is comprised of concentric polygons or rings, the traders are ordered by activity levels, and each polygon represents a range of activity level orders. After the activity level of a trader is determined, the traders are reordered responsive to their activity levels, and the trader icon 912 for each the trader is placed in the polygon designated for the order of the trader. The client 104 determines 1020 if there are more traders. If there are not, the client 104 determines 1024 if there are bystanders and, if there are, selects 1028 the first bystander icon 904 . 908 and determines 1032 whether the bystander is connected using data that is provided by the server 200 . If the bystander is not connected, the bystander icon is removed 1040 . If the bystander is connected, the client 104 determines 1036 whether there are more bystanders. If there are not, the client 104 returns to the step of determining 1004 whether a predetermined time period has ended, as the pit panel 900 view has been updated to reflect the current users and their current activity levels. Seer The main window is split into three sections, the tool bar at the top, the treeview to the left and the object viewer to the right. The treeview contains all opened trading accounts, Indicators, Charts, Time Frames and the Library. Each trading account is built up of logical parts called objects . Most of these objects are based upon trading concepts such as orders and positions. Each object has its own icon, and clicking on it will bring up the object viewer to the right. The Library is simply a convenient placeholder for common objects that you can cutcopypaste into and out of trading accounts. The only objects that the Library will accept are Systems, Money Management, Functions, Charts, Indicators and Portfolios. Any objects in the Library are automatically saved every time Seer exits. Clicking the backtest, optimise or debug button will backtestoptimisedebug the currently selected account from the date selected, to the date selected. The tool bar at the top generally operates on the selected trading account (or component object of a trading account) in the treeview. For example, Clicking Backtest will backtest the current selected account in the treeview. The last part of the tool bar is the date time selectors, changing these values will effect the start and end date of the trading system being backtested. The Objects 8211 an Overview The Account Object The main object is the account, a basic representation of your trading account. Each account contains the following objects, Orders, Positions and Trade History. These objects should be self-explanatory. The account object also contains two folders, Systems and Functions. The Systems folder contains system objects, and the function folder contains global functions used by objects within the account. Each Trading Account can have multiple systems each system is processed in the order in which it appears in the treeview. The System Object The System Object contains all the rules for your trading system. The system object contains the objects Variables, Money Management, Portfolio, Positions, Trade History and the event Objects Begin, Bar, and End. Clicking on System object will allow you to view and change the various settings for the system. The Variables Object The Variable object contains all the variables used in the System or Money management Object. This object allows you to edit the variable contents, and whether the optimiser should optimise the variable or not. The Money Management Object The Money Management object contains the rules for the orders placed by your system. Each System has its own money management object, which can be different. Each money management can access the trading statistics of the system and the trading statistics of the account as a whole. The money management object contains a variable object the Event objects for each order type. The Money Management object also contains a function called PositionSize, this can be used to calculate the size of the position on entry. The Portfolio Object Contains a list of symbols, which the system object is run against. When more than one symbol is in the portfolio true portfolio backtesting is performed. The Positions Object Contains the open positions for this system (or account) after a backtest. The Trade History Object Contains the trade history for this System (or Account) after a backtest. The Orders Object Contains the orders for the account that will be placed on the next bar. The Event Object Contains your rules for the system or money management. Clicking on the event object shows the rule editor and the current defined variables (from the variables object). The Function Object The function object defines a global function that can be used throughout the trading account by any system or money management object. The Chart Object The chart object allows you to build and test a chart that can be displayed in a chart window. The Indicator Object The indicator object allows you to build and test an technical analysis indicator that be be included in a chart or system. The Time Frame Object The Time Frame object allows you to create custom bars based upon time or ticks and specify the number of barsbacks. The time frames are then used to define the heartbeat for system object or in the construction of chartsTrading Technologies: User Interface for Stock Trading Before writing more about Trading Technologies v. CQG. I will first note that TT is my former client and I personally filed the original complaint in this very case 12 years ago (2005). Although TT is no longer my client, I am bound by and respect the rules of professional ethics and the duties owed to former clients. The new non-precedential opinion from the Federal Circuit affirms the district court ruling that TT8217s asserted claims are patent eligible. The patent claims here cover a computerized method and system used for trading stocks and similar products. When buying and selling stocks, speed and accuracy are both critically important and in this invention, TT created a Graphical-User-Interface design (and operational software) that helps traders buy and sell stock more quickly and more accurately. See U. S. Patents No. 6,772,132 and No. 6,766,304. The court writes: It is not disputed that the TTI System improves the accuracy of trader transactions, utilizing a software implemented programmatic method. For Section 101 purposes, precedent does not consider the substantive criteria of patentability. For Section 101 purposes, the claimed subject matter is directed to a specific improvement to the way computers operate, Enfish. for the claimed graphical user interface method imparts a specific functionality to a trading system directed to a specific implementation of a solution to a problem in the software arts. Id . The opinion is authored by Judge Newman and joined by Judges O8217Malley and Wallach. The court8217s opinion is a short and interesting read: Precedent has recognized that specific technologic modifications to solve a problem or improve the functioning of a known system generally produce patent-eligible subject matter. 8230 Ineligible claims generally lack steps or limitations specific to solution of a problem, or improvement in the functioning of technology. For some computer-implemented methods, software may be essential to conduct the contemplated improvements. Enfish 8230 Abstraction is avoided or overcome when a proposed new application or computer-implemented function is not simply the generalized use of a computer as a tool to conduct a known or obvious process, but instead is an improvement to the capability of the system as a whole. We reiterate the Courts recognition that at some level, all inventions. embody, use, reflect, rest upon, or apply laws of nature, natural phenomena, or abstract ideas. Alice. quoting Mayo. This threshold level of eligibility is often usefully explored by way of the substantive statutory criteria of patentability, for an invention that is new, useful and unobvious is more readily distinguished from the generalized knowledge that characterizes ineligible subject matter. This analysis is facilitated by the Courts guidance whereby the claims are viewed in accordance with the general rule that patent claims must be considered as a whole. Alice. quoting Diamond v. Diehr . As demonstrated in recent jurisprudence directed to eligibility, and as illustrated in the cases cited ante, the claim elements are considered in combination for evaluation under Alice Step 1, and then individually when Alice Step 2 is reached. Applying an overview of this evolving jurisprudence, the public interest in innovative advance is best served when close questions of eligibility are considered along with the understanding flowing from review of the patentability criteria of novelty, unobviousness, and enablement, for when these classical criteria are evaluated, the issue of subject matter eligibility is placed in the context of the patent-based incentive to technologic progress. The patents are also currently being challenged on 101 grounds in CBM proceedings before the USPTO. Although I feel that it should have a direct impact, it is unclear to me whether this decision will impact the PTO proceedings addressing the identical question. (For instance, the court here holds that the patent covers a technological invention 8211 and CBM proceedings can only proceed for non-technological inventions.) Patentees may also consider petitioning the court to make this decision precedential. About Dennis Crouch Law Professor at the University of Missouri School of Law. Co-director of the Center for Intellectual Property and Entrepreneurship. View all posts by Dennis Crouch rarr Post navigation Claim 1 of US Patent 6,772,132: 1. A method of placing a trade order for a commodity on an electronic exchange having an inside market with a highest bid price and a lowest ask price, using a graphical user interface and a user input device, said method comprising: setting a preset parameter for the trade order displaying market depth of the commodity, through a dynamic display of a plurality of bids and a plurality of asks in the market for the commodity, including at least a portion of the bid and ask quantities of the commodity, the dynamic display being aligned with a static display of prices corresponding thereto, wherein the static display of prices does not move in response to a change in the inside market displaying an order entry region aligned with the static display prices comprising a plurality of areas for receiving commands from the user input devices to send trade orders, each area corresponding to a price of the static display of prices and selecting a particular area in the order entry region through single action of the user input device with a pointer of the user input device positioned over the particular area to set a plurality of additional parameters for the trade order and send the trade order to the electronic exchange. This is why Alice is such a disaster. It8217s impossible to tell from reading claims what8217s patentable and what8217s not. You have to somehow 8220divine8221 whether something 8220is an improvement to way computers operate8221, especially when the claimed subject matter doesn8217t actually improve the computer itself: it only improves the way trades are made using the computer. The same with Enfish. Both of these were really improvements to the functioning of software 8212 the computer itself was not 8220improved8221 in any way. When I look at both the claims here and in Enfish, I think they8217re invalid under Alice. Yet, the courts hold the other way. Why 8220Much of the advancement made in computer technology consists of improvements to software that, by their very nature, may not be defined by particular physical features but rather by logical structures and processes. We do not see in Bilski or Alice, or our cases, an exclusion to patenting this large field of technological progress.8221 The claim there: A data storage and retrieval system for a computer memory, comprising: means for configuring said memory according to a logical table, said logical table including: a plurality of logical rows, each said logical row including an object identification number (OID) to identify each said logical row, each said logical row corresponding to a record of information a plurality of logical columns intersecting said plurality of logical rows to define a plurality of logical cells, each said logical column including an OID to identify each said logical column and means for indexing data stored in said table. Can anyone look at this claim and tell me what8217s patentable about it (under Alice, that is) The only way to do it is research the 8220improvement8221 made to some 8220software8221, and then somehow correlate that 8220improvement8221 with the claim. How the hec k is an Examiner supposed to do this And what do I tell my client Currently, I8217ve been telling them that I have no idea whether their claim is valid or not they8217ll have to wait until litigation. Also, why aren8217t the claims under Alice valid under this theory They involved computer software that was an improvement over other software. Reply link does not work in your browser because JavaScript is disabled. Reply Greg DeLassus says: why arent the claims under Alice valid under this theory This is just my opinion, but I read Trading Techs as the CAFC throwing up their hands and saying 8220heck if I know what Alice means. Let8217s just treat Alice as confined to its own facts and try to sketch out a 101 test based on our own precedents, unburdened by the more confusing aspects of Alice .8221 In other words, if you are having a hard time reconciling this case to the holding in Alice . join the club. I do not think that they can be reconciled. I think that this case represents a bolder presentation of the trend we have seen emerging in the CAFC over the last three months of some of the judges realizing that they have tried to implement Alice . and it just cannot be done. Mayo and Alice are just too entirely self-contradictory. Instead of continuing to beat their heads against the wall trying to implement an inherently undiscernible standard, it appears to me that certain judges (Taranto, Reyna, Newman, Moore, and O8217Malley) are just going to give up on it and forge a new test. Meanwhile, Dyk, Wallach, Mayer, and Hughes are sort of apostles of Alice and are going to do their level best to see that Alice is implemented in a strong sense by resolving any internal contradictions in Alice always in favor of unpatentability. Reply link does not work in your browser because JavaScript is disabled. Reply Mayo and Alice are just too entirely self-contradictory. Tell everyone what8217s 8220self-contradictory8221 about those cases, Greg. Also, the fact that PatentBob is 8220confused8221 about something isn8217t evidence of anything except, maybe, that the earth hasn8217t completely blown up. Reply link does not work in your browser because JavaScript is disabled. Reply Greg 8211 a lot like you 8211 does not respond well to counter points presented to his views. Except when he deigns it so, that is. Reply link does not work in your browser because JavaScript is disabled. Reply Ned Heller says: Greg, the difference between Alice and here is simple. In Alice, the claims were directed to a business method, non statutory. Here, an improvement to the way computers operate. Now, this is why I believe the Supreme Court and the Federal Circuit as a whole are following FlookBilski (Stevens) reasoning and not the Bilski majority which never bothered to explain its reasoning. Reply link does not work in your browser because JavaScript is disabled. Reply Greg DeLassus says: I am hard pressed to see how these claims are any more an improvement to how a computer operates than were the Alice claims. Both amount to a discovery that you could do X on a computer. This is not like Enfish where you have (arguably) created a method of indexing data that makes it faster to find certain kinds of data. The claim itself purports to be a method of placing a trade order, not a method of improving computer function. I know that Judge Newman8217s opinion characterized these claims as improving computer function, but I think that it is to ingenuous to take that at face value. The invention claimed in Alice improved as much computer function as the invention claimed here. Reply link does not work in your browser because JavaScript is disabled. Reply Greg: I know that Judge Newmans opinion characterized these claims as improving computer function, but I think that it is to ingenuous to take that at face value. That8217s because Judge Newman l i e d. Plain and simple. Reply link does not work in your browser because JavaScript is disabled. Reply Greg DeLassus says: In short, yes, but Benson was poorly reasoned, and that8217s even setting aside the judicial creation of exceptions to 101 based on what were really enablement concerns in the pre-1952 caselaw. This is because Benson8217s claims should have been patentable under even Benson8217s own logic. The 8220nutshell8221 of the Benson Court8217s reasoning is this: 8220It is conceded that one may not patent an idea. But in practical effect that would be the result if the formula for converting BCD numerals to pure binary numerals were patented in this case.8221 This second sentence is incorrect as a factual matter. The Benson claims did not cover all ways of 8220converting BCD numerals to pure binary numerals8221 on a computer, just some of them. For an easy example of this, consider that the claims don8217t preempt a BCD to decimal to binary conversion (what a human might do by hand). And don8217t just take my word for it: the Benson Court itself acknowledged a nuanced distinction between this method and other methods of BCD to decimal conversion, stating earlier in the opinion that 8220the method sought to be patented varies the ordinary arithmetic steps a human would use by changing the order of the steps, changing the symbolism for writing the multiplier used in some steps, and by taking subtotals after each successive operation.8221 So as noted above, the Benson court was wrong to think that the 8220practical effect8221 of these claims was to patent the idea of BCD to binary conversion. Moreover, the Court also has the analysis backwards when it further stated that 8220the mathematical formula involved here has no substantial practical application except in connection with a digital computer.8221 Who cares It is irrelevant whether the claimed method could be performed without the claimed computer components, because that wasn8217t claimed. What is relevant under Benson8217s reasoning is merely whether the so-called idea of 8220BCD to binary conversion8221 was monopolized by this claimed steps. And it wasn8217t. But I would daresay that Benson8217s claims would logically be found eligible under the majority of the 2016 Fed. Cir. precedent. First, the claims are not 8220directed to8221 BCD to binary conversion, but to a specific way to perform that conversion. The 8220essence8221 or 8220character as a whole8221 or 8220focus8221 or 8220basic thrust8221 of the claims is thus to this specific implementation, not the general concept of BCD to binary conversion. And frankly, this sort of focal point analysis has been the law before this TTI case it is set forth as the initial step in the 8220directed to8221 inquiry in Internet Patents Corp, Enfish, Electric Power, McRO, Affinity Labs v. DirecTV, Merial, TLI, Fairwarning IP, Bascom, and Rapid Litigation Management. Moreover, even if this focal point analysis were disregarded, the Benson claims would be patentable at the 8220directed to8221 inquiry under the Enfish safe harbor (an improvement to computer functionality) or the non-preemption logic of McRO (an improved method of BCD to binary conversion, not the only method), and the Benson claims would in any event be patentable at the 8220inventive concept8221 inquiry using the logic of Bascom (a particular arrangement of elements providing a technical improvement over prior art ways of BCD to binary conversion). Reply link does not work in your browser because JavaScript is disabled. Reply Ned Heller says: E, Ultimately what Benson has come to stand for is that mathematical algorithms are not statutory processes. They have to be applied in a conventional process or machine to improve them. Reply link does not work in your browser because JavaScript is disabled. Reply That8217s quite a casual (and patronizing) dismissal of my point that doesn8217t actually address anything I said. But I8217ll do you a courtesy that you don8217t do me and accept, for argument8217s sake, your premise that Benson can be captioned as 8220mathematical algorithms are only statutory when applied in a conventional process or machine.8221 Even with this understanding of Benson, then at least some of Benson8217s claims would be eligible, because they are implemented by way of 8220reentrant shift registers.8221 Do you disagree But in any event, I do not accept the apparent breadth of your premise. Benson8217s reasoning all stems from the proposition that 8220one may not patent an idea.8221 Well, the term 8220mathematical algorithm8221 would not ordinarily be an equivalent term for an 8220idea8221 to a layman, so it seems that Benson does not use the term 8220mathematical algorithm8221 in the way we might ordinarily understand it. Instead, Benson implicitly defines that term using a quote from Mackay Co. v. Radio Corp. that states that 8220while a scientific truth, or the mathematical expression of it, is not a patentable invention, a novel and useful structure created with the aid of knowledge of scientific truth may be.8221 The term 8220mathematical expression8221 as used in Benson refers to a formulation of a 8220scientific truth8221 in the language of math (e. g. emc2, which is not restricted to some particular applied domain). This is emphasized by the distinction drawn in this quote between scientific truths and 8220novel and useful structure created with the aid of knowledge of scientific truth8221 (which Benson implies would be eligible). Benson defines an 8220algorithm8221 as 8220a procedure for solving a given type of mathematical problem,8221 not as the specific procedure for solving a specific problem. With this in mind, Benson describes the 8220algorithm8221 at issue in its claims as 8220a generalized formulation for programs to solve mathematical problems of converting one form of numerical representation to another.8221 In doing so, Benson draws a contrast between 8220the generic formulation8221 and 8220programs that may be developed as specific applications.8221 Benson itself is not particularly clear on what this dichotomy implies, but I believe the intent is to suggest that specific applications of a general algorithm are eligible, despite the fact that the 8220generic formulation8221 itself is not (if this were not the intended reading, then what would be the point of this discussion of 8220specific applications8221). From this language in the opinion, it is my view that Benson actually stands for the proposition that while a general idea or a results-defined mathematical statement would be classified as an ineligible 8220mathematical algorithm,8221 a specific implementation should not be. But Benson8217s claims are 8211 in reality 8211 specific implementations of the general concept of BCD to binary conversion, not broad recitations of the general concept itself, so I think Benson8217s ultimate finding of ineligibility does not follow from its reasoning. As a result, to the extent that Benson remains precedential (given the vast number of more recent cases), I read the case not as suggesting that any 8220mathematical algorithm8221 is ineligible (as we might use that term in lay parlance), but to suggest only that claims that can phrased using the language of math are ineligible when they are recited at a high level and by their ultimate results, while claims including the specific steps for achieving those ultimate results remain eligible. Reply link does not work in your browser because JavaScript is disabled. Reply Ned Heller says: E, what is important about any Supreme Court case is the way the Supreme Court itself characterizes it. Thus, in Flook we learned that mathematical algorithms are non statutory, and that the bit about 8220wholly preempt8221 was not a requirement. Simply referring to a use, even somewhat specific, was not 8220enough.8221 There had to be an inventive application. Later, in Diehr, we learn that math 8220applied8221 in a conventional process (to improve that process) was sufficient. In MayoAlice, we again learned that 8220abstract8221 material must be applied in an inventive fashion. However, this did not displace Flook8217s statement that mathematical algorithm8217s are nonstatutory or that wholly preempt was not required. What we learned is that 8220abstract8221 includes math (and business methods.) But to me, by circular logic, the Supreme Court is dancing around Bilski8217s majority holding (calling business methods abstract) by really following Flook and the dissent in Bilski that math and business methods are nonstatutory. I just call it as I see it. Again, it is best not to focus on Benson8217s reasoning. That has been eclipsed, especially the bit about 8220wholly preempt.8221 Now, regarding Benson8217s claims, they were construed to cover the mathematical algorithm, with the computer preamble as a limitation on use: in other words, do it on a computer. This is precisely the kind of use limitation that was demolished in Flook, and finally disposed of in Alice. Reply link does not work in your browser because JavaScript is disabled. Reply 8220Thus, in Flook we learned that mathematical algorithms are non statutory, and that the bit about wholly preempt was not a requirement. Simply referring to a use, even somewhat specific, was not enough. There had to be an inventive application. Later, in Diehr, we learn that math applied in a conventional process (to improve that process) was sufficient.8221 Yes, we learned if you change an alarm limit at the end of your method it is not an eligible method, but if you open a door at then end of you method, because a limit has been reached, then it is eligible8230. so, always add some insignificant post solution activity, like opening a door to make your claim eligible. Reply link does not work in your browser because JavaScript is disabled. Reply Ned Heller says: Les, the claims have to be more like Diehr than that. The claim as a whole must be directed to a specific inventive application and not to simply do it on a computer, or use it in a chemical process. Ned. Here is Diehr8217s claim 1: A method of operating a rubber-molding press for precision molded compounds with the aid of a digital computer, comprising: providing said computer with a data base for said press including at least, natural logarithm conversion data (1n), the activation energy constant (C) unique to each batch of said compound being molded, and a constant (x) dependent upon the geometry of the particular mold of the press, initiating an interval timer in said computer upon the closure of the press for monitoring the elapsed time of said closure, constantly determining the temperature (Z) of the mold at a location closely adjacent to the mold cavity in the press during molding, constantly providing the computer with the temperature (Z), repetitively performing in the computer, at frequent intervals during each cure, integrations to calculate from the series of temperature determinations the Arrhenius equation for reaction time during the cure, which is 1n vCZx where v is the total required cure time, repetitively comparing in the computer at frequent intervals during the cure each said calculation of the total required cure time calculated with the Arrhenius equation and said elapsed time, and opening the press automatically when a said comparison indicates completion of curing. Other than opening the door, and the particular equation, how is it significantly different from the Claims in Alice You are even more off than normal Ned. Do you recognize the parallel between what you just posted and the line from the Wizard of Oz (pay no attention to that man behind the curtain). May I also remind you (yet again) to read (heck even print it out here so that everyone can read it) what your state attorney oath says (I guarantee that it does not place the Supreme Court above the Constitution) Reply link does not work in your browser because JavaScript is disabled. Reply Ned Heller says: anon, your lack of understanding of the Supreme Court jurisprudence in this area is legendary. You interpreted Bilski as holding that 8220business methods are eligible subject matter.8221 Of course, they are not and never legitimately have been. You remain the one that is off and I was the one perpetually correcting you that the holding in Bilski was NOT directed to 8220business methods8221 but instead was to 8220abstract.8221 Your attempt to redefine history F A I L S