DE10297348T5

DE10297348T5 - Dialogorientiertes Geschäftssystem

Info

Publication number: DE10297348T5
Application number: DE10297348T
Authority: DE
Inventors: Peter Richard Horsfall; Neena Jain; Edward Howorka
Original assignee: EBS Dealing Resources International Ltd
Current assignee: EBS Dealing Resources International Ltd
Priority date: 2001-10-19
Filing date: 2002-10-21
Publication date: 2004-11-18
Anticipated expiration: 2022-10-22
Also published as: WO2003034174A2; JP4511178B2; US7269793B2; JP2005527878A; DE10297348B4; WO2003034174A3; US20030093363A1; AU2002358929A1

Abstract

Verfahren zum Senden von Nachrichten in einem Duplex-Nachrichtensystem, wobei das Verfahren umfasst:
Erfassen des Beginnens der Eingabe einer neuen Nachricht an einer ersten Nachrichtenstation;
während die neue Nachricht eingegeben und bis die neue Nachricht gesendet wird, Überwachen nach einer ankommenden Nachricht von einer zweiten Nachrichtenstation; und
wenn die ankommende Nachricht während des Überwachen erfasst wird, Warnen eines Benutzers der ersten Nachrichtenstation vor der ankommenden Nachricht.

Description

Querverweise auf verwandte Anmeldungen
Diese Anmeldung beansprucht Priorität gegenüber der vorläufigen Anmeldung mit der Nr. 60/337 591, eingereicht am 19. Oktober 2001, deren Gesamtheit hiermit durch Bezug aufgenommen wird.

Hintergrund der Erfindung

Diese Erfindung bezieht sich auf Computer-Nachrichtensysteme, die Nachrichten zwischen Benutzern austauschen. Sie betrifft insbesondere dialogorientierte Handelssysteme zum Handeln von vertretbaren Sachen (fungibles), wie beispielsweise Finanzinstrumenten.

Dialogorientierte Geschäftssysteme ermöglichen es den beteiligten Partnern, Nachrichten über ein Computer-Netzwerk auszutauschen. Diese Nachrichten können einfacher Chat sein oder können handelsbezogene Information umfassen. Typischerweise analysiert das Geschäftssystem die Nachrichten, um geschäftsbezogene Information aufzunehmen. Geschäfte werden zwischen den Partnern in einem Austausch von Nachrichten abgeschlossen, und abgeschlossene Geschäfte werden aus dem Nachrichtentext von dem System erfasst und protokolliert.

Dialogorientierte Systeme können Simplex- oder Duplex-Chat ermöglichen.

Duplex-Chat ermöglicht allen bei dem Dialog beteiligten Partnern eine gleiche und gleichzeitige Steuerung des Dialogs aufzuweisen. Simplex-Chat ermöglicht es nur einer Person, zu jeder Zeit die Steuerung des Dialogs aufzuweisen.

Typischerweise laufen bei einem Duplex-System Nachrichten, die zwischen Händler-Workstations (WS) geleitet werden, durch einen Chat-Server, der die Nachrichten in der Reihenfolge protokolliert, in der sie bei der Workstation empfangen werden. Der Zweck davon besteht darin, zu gewährleisten, dass beide Partner zu dem Dialog die gleichen Nachrichten auf ihrem Bildschirm in der Reihenfolge sehen, in der die Nachrichten in dem Protokoll erfasst werden.

Wenn der Chat-Server eine Nachricht von irgendeinem Händler empfängt und diese Nachricht an den bestimmten Zielhändler weiterleitet, sendet er eine Bestätigung an die sendende Händler-Workstation.

Dieses Duplex-Chat-Model, wobei ein Chat-Server Nachrichten in der Reihenfolge des Empfangs protokolliert, ist sehr vorteilhaft und bietet eine Anzahl von Vorteilen gegenüber konkurrierenden Systemen. Ein besonderes Problem kann jedoch entstehen, das sich auf die zeitliche Steuerung von von verschiedenen Partnern auf dem System gesendeten Nachrichten bezieht. Da ein Duplex-Chat-System es allen Partnern ermöglicht, ihre Nachrichten von ihren Workstations zur gleichen Zeit einzugeben und zu senden, entsteht die Möglichkeit, dass eine Antwortnachricht von einer zweiten Workstation als Antwort auf eine Nachricht von einer ersten Workstation zu etwa der gleichen Zeit gesendet wird, wenn eine weitere Nachricht von der ersten Workstation gesendet wird. Wenn die Antwortnachricht an der ersten Workstation ankommt, scheint es der ersten Workstation, als ob es eine Antwort auf die zweite, nicht die erste Nachricht ist. Dieses Problem, das ein technisches Problem ist, das teilweise durch die Art des Duplex-Chat-Systems und teilweise durch die zeitliche Steuerung von zwischen Workstations über mindestens einen Server gesendete Nachrichten verursacht wird, kann potentielle katastrophale Folgen aufweisen.

Es sei das folgende Beispiel eines Dialogs über ein Duplex-Chat-System zwischen zwei Händlern betrachtet. Der Händler A sendet „Wie geht es Ihnen?" an den Händler B. Der Händler B liest die Nachricht und beginnt „OK" als Antwort einzugeben. Bevor er diese Nachricht gesendet hat, sendet der Händler A ohne Warten auf eine Antwort auf seine ursprüngliche Nachricht „Sie kaufen 100M USD@1.86". Dies ist ein Angebot an den Händler B, $ 100 Millionen bei einem Wechselkurs von 1,86 zu kaufen. Bevor diese Nachricht beim Händler B empfangen wird, sendet dieser Händler die „OK"-Nachricht als Antwort auf die vorhergehende Nachricht vom Händler A. Sowohl der Händler A als auch der Händler B sehen auf ihren Bildschirmen die folgende Sequenz von Nachrichten: „Wie geht es Ihnen?; Sie kaufen 100M USD@1.86.; OK." Der Chat-Server, der den Austausch von Nachrichten handhabt, protokolliert ebenfalls die Nachricht in dieser Sequenz, der Sequenz, mit der sie bei dem Server empfangen wurden.

Somit denken bei der obigen Sequenz das System und der Händler A, dass der Händler B dem vorgeschlagenen Handel zugestimmt hat, wobei er tatsächlich lediglich dem Händler A eine Bemerkung über sein Wohlergehen gemacht hat. Offensichtlich kann ein Händler aus diesem Fehler in dem Duplex-Chat-System Vorteil ziehen, um sich boshaft zu verhalten.

Wir haben erkannt, dass dieses Problem besonders gefährlich ist, da es für den Händler keinen verfügbaren Mechanismus gibt, um anzugeben, auf welche Nachricht er antwortet, und das System nicht erfasst, auf welche Nachricht von dem Händler A der Händler B antwortet. Es gibt daher einen Bedarf in der Technik nach einem Duplex-Chat-System, das einen Austausch von Nachrichten analysieren und gewährleisten kann, dass Nachrichten und Antworten korrekt zusammenpassen werden.

Zusammenfassung der Erfindung

Die vorliegende Erfindung beabsichtigt, den oben erwähnten Nachteil bei Duplex-Chat-Systemen des Stands der Technik zu überwinden.

In seiner weitesten Form überwacht ein Aspekt der Erfindung nach ankommenden Nachrichten, sobald wie ein Benutzer beginnt, eine neue dialogorientierte Nachricht einzugeben. Wenn irgendwelche Nachrichten erfasst werden (nachdem der Benutzer eine neue dialogorientierte Nachricht initiiert hat), wird der Benutzer auf diese aufmerksam gemacht, bevor die neue dialogorientierte Nachricht gesendet wird. Dies gewährleistet, dass der Benutzer hinsichtlich aller nachfolgend empfangener Nachrichten von dem gleichen Partner prüfen kann, dass seine Nachricht passend ist, und er die neue Nachricht verbessern oder löschen kann, falls notwendig ist.

In seiner weitesten Form weist ein zweiter Aspekt der Erfindung eine Referenz jeder von irgendeinem Benutzer gesendeten Nachricht zu. Die Referenzen werden bei einem Nachrichten-Server protokolliert. Wenn eine neue Nachricht als Antwort auf eine frühere Nachricht gesendet wird, wird die neue Nachricht die Referenz der früheren Nachricht umfassen. Der Nachrichten-Server wird diese Referenz mit der zuletzt protokollierten Referenz vergleichen. Wenn die Referenzen nicht die Gleichen sind, wird der Nachrichten-Server einem oder beiden Partnern zu dem Dialog angeben, dass es eine Überkreuzung gegeben hat.

Genauer gesagt wird die Erfindung durch die unabhängigen Ansprüche definiert, auf die Bezug gemacht werden sollte.

Eine bevorzugte Ausführungsform der Erfindung stellt ein dialogorientiertes Geschäftssystem für das ausgehandelte Handeln von Instrumenten, wie beispielsweise Finanzinstrumenten, durch Austausch von dialogorientierten Nachrichten in einer Duplex-Nachrichtenumgebung bereit. Das Handelssystem umfasst eine Mehrzahl von Händlerterminals, die beispielsweise über das Internet mittels eines Nachrichten-Servers kommunizieren können. Jedes Händlerterminal umfasst einen Bildschirm, der dialogorientierte Nachrichten anzeigt. Wenn ein neuer Dialog initiiert wurde, beispielsweise wenn ein Händler eine ankommende Nachricht angenommen hat, wird das Händlerterminal das Beginnen einer neuen Nachrichteneingabe erfassen, die als Antwort gesendet wird. Dies kann einen Tastendruck von einer Tastatur umfassen. Während dieser Zeit überwacht das Terminal nach neuen ankommenden Nachrichten von dem Vertragspartner zu dem Dialog. Wenn der Händler versucht, die neue Nachricht zu senden, wenn eine neue ankommende Nachricht erfasst wurde, wird das Senden der neuen Nachricht gesperrt, und der Benutzer wird vor der ankommenden Nachricht, beispielsweise durch Hervorheben der neuen Nachricht auf der Anzeige, gewarnt. Der Benutzer kann dann das Senden bestätigen, die Nachricht verbessern und dann bestätigen, oder die Nachricht löschen. In den ersten beiden Fällen fährt das Terminal fort, nach neuen ankommenden Nachrichten zu überwachen und wird den Benutzer erneut warnen und das Senden einer Nachricht sperren, wenn eine neue ankommende Nachricht zwischen zwei Sendeversuchen erfasst wird.

An dem Server werden Nachrichten, wie sie empfangen werden, zusammen mit einer eindeutigen Referenz protokolliert. Diese Referenz wird zu dem sendenden Terminal in einer Bestätigungsnachricht zurückgeleitet und zu dem Ziel-Terminal mit der Nachricht weitergeleitet. Wenn das Ziel-Terminal eine Antwort sendet, wird die Antwort die Referenz der Nachricht enthalten, auf die die Antwort gerichtet ist. Der Server vergleicht diese Referenz mit der Referenz der letzten Nachricht in dem Protokoll, und wenn die Referenzen nicht identisch sind, benachrichtigt er einen oder beide der Partner, dass es eine Überkreuzung gegeben hat. Diese Benachrichtigung ist vorzugsweise ein Ikon, das auf der Anzeige der Händler in den Zeilen des Dialogs erscheinen kann, die sich überkreuzen. Vorzugsweise kann das Ikon ebenfalls den Kontext der Überkreuzung angeben.

Die Ausführungsformen der Erfindung weisen bei ihren verschiedenen Aspekten den Vorteil auf, dass die bei Duplex-Chat-Systemen inhärenten Probleme, auf die oben Bezug genommen wurde, durch Erfassen aus der Sequenz von Nachrichten und Lenken der Aufmerksamkeit des Händlers auf diese überwunden werden. Somit können die Folgen eines Antwortens auf die „falsche" Nachricht vermieden werden.

Kurzbeschreibung der Zeichnungen
Ausführungsformen der Erfindung werden nun nur beispielhaft und mit Bezug auf die begleitenden Zeichnungen beschrieben, in denen zeigen:
1 ein schematisches Diagramm eines Handelssystems;
2 ein weiteres schematisches Diagramm, das die Hauptfunktionskomponenten eines Händlerterminals zeigt;
3 eine Ansicht der Benutzerschnittstelle eines Händlerterminals;
4 eine ähnliche Ansicht zu 3, die die Anzahl von Dialogfeldern zeigt;
5 eine Ansicht eines Geschäftsstapels innerhalb der Benutzerschnittstelle, die das Geschäftsdetailfeld zeigt;
6 eine weitere Ansicht des Geschäftsstapels und des Geschäftsdetailfelds, wobei ein unterschiedliches Geschäft in dem Geschäftsdetailfeld von 5 hervorgehoben ist;
7 ein Ablaufdiagramm, das einen Überblick des Parsen-Verfahrens (Text/Sprachanalyse) zeigt;
8a und 8b Ablaufdiagramme, die das Parsen-Verfahren ausführlicher zeigen;
9 ein Bildschirmausdruck einer zweiten Ausführungsform der Benutzerschnittstelle, die eine geparste Nachricht zeigt, die von dem Aussteller (maker) eingegeben wurde;
10 den Bildschirm von 9, wenn die geparste Nachricht gesendet jedoch nicht aufgenommen wurde;
11 die Schnittstelle des Abnehmers (taker), wenn die geparste Nachricht empfangen wird;
12 die Schnittstelle des Abnehmers, wenn das System auf den Abnehmer wartet, anzubieten;
13 den Bildschirm des Ausstellers, wenn ein Angebot empfangen wird;
14 den Bildschirm des Ausstellers, wenn ein Geschäft abgeschlossen wurde;
15 ein modifiziertes Chat-Feld, das die Erfindung verkörpert;
16 das Chat-Feld von 15 mit einer abgeschlossenen Dialogzeile;
17 das Chat-Feld von 15 mit einem zweiten Versuch am Senden einer Dialogzeile;
18 das Chat-Feld, wenn eine fehlerfreie Sendung gesendet wird;
19 das Chat-Feld, das eine Überkreuzung hervorhebt;
20 die Überkreuzung von 19, nach dem eine „Zeige Kontext"-Aktion aufgerufen wurde;
21 ein Ablaufdiagramm, das die Schritte zeigt, die an dem Chat-Server unternommen wurden, um die Nachrichtenüberkreuzungen zu identifizieren;
22a und 22b ein Ablaufdiagramm, das die Schritte zeigt, die an der Benutzerschnittstelle unternommen wurden, um Dialogzeilen zu identifizieren, die empfangen wurden, während der Benutzer eine neue Dialogzeile aufbaut; und
23 die Daten, die bei dem Chat-Server protokolliert werden.
Ausführliche Beschreibung der bevorzugten Ausführungsform
Die Ausführungsform der Erfindung liefert eine Lösung zu dem Problem, dass es scheint, dass ein Händler auf eine Nachricht geantwortet hat, die unterschiedlich von derjenigen ist, auf die er tatsächlich geantwortet hat. Es gibt zwei Aspekte zu diesem Problem: Eine Rennsituation und eine Überkreuzungssituation, bei der sich Nachrichten von zwei Partnern einander überkreuzen.
Allgemein verfolgt das System die letzte Nachricht, die der Benutzer gelesen hat, bevor er seine Antwort sendet, im Gegensatz zu der letzten Nachricht, die auf seinem Bildschirm angezeigt wird, wenn er seine Antwort sendet. Diese Vorgehensweise erfasst die Absicht des Benutzers, wenn er auf eine Nachricht antwortet. Außerdem beginnt, um die Lösung zu behalten, ohne die Duplex-Art der Chat-Funktionalität zu opfern, jede Workstation des Händlers damit, alle neuen Zeilen von Nachrichten zu verfolgen, die empfangen werden, sobald sie die erste Taste von dem Händler betätigt wird, um seine Eingabe einzugeben, bis zu der Zeit, wenn er die Nachricht sendet. Natürlich gibt es weitere Wege, bei denen ein Händler eine Nachricht in das System eingeben können, beispielsweise mittels sprachaktivierter Software, wobei das Prinzip jedoch dasselbe ist, weil das System nach allen neuen Nachrichten vom Anfang des Aufbaus einer Nachricht bis zu der Zeit, bei der sie gesendet wird, überwacht. Das Senden der Nachricht kann durch eine Anzahl von Verfahren, beispielsweise durch Betätigen einer „Sende"-Taste auf einer Tastatur oder einem Tastenfeld, Klicken einer „Sende"-Schaltfläche auf der Workstation oder Verwenden eines gesprochenen „Sende"-Befehls bei einem sprachaktivierten System, erreicht werden.
Wenn die Workstation zusätzliche ankommende Dialogzeilen erfasst hat, die beim Eingeben empfangen wurden, wird die Workstation den Händler warnen und die empfangenen neuen Zeilen hervorheben. Sie wird dann den Händler bitten, entweder fortzufahren oder eine neue Nachricht einzugeben. Somit kann der Händler die zusätzlichen Zeilen lesen und seine Antwort, basierend auf den von dem Vertragspartner empfangenen zusätzlichen Zeilen, ändern.
Wenn der Händler erneut „Senden" drückt, um mit dem Senden der Nachricht fortzufahren, wird die Workstation die Nachricht an den Chat-Server zusammen mit der Referenznummer der von dem Server empfangenen letzten Zeile senden.
Keine Warnung wird gesendet, wenn keine zusätzlichen Zeilen während des Nachrichtenaufbaus empfangen wurden.
Die oben umrissene Vorgehensweise ermöglicht dem Server, Überkreuzungen zu erfassen und ebenfalls das Nachrichtenprotokoll auf eine Weise zu markieren, die später ordnungsgemäße Audits ermöglicht.

Das folgende Beispiel zeigt, wie die beschriebene Methodik arbeitet. Es zeigt den Austausch von Nachrichten zwischen zwei Händlern, dem Händler A und Händler B.

Händler A	Händler B
Sendet Zeile 1
	empfängt Zeile 1
Sendet Zeile 2
	empfängt Zeile 2

Sendet Zeile 3
	empfängt Zeile 3
	beginnt einzugeben...
Sendet Zeile 4
	empfängt Zeile 4
Sendet Zeile 5
	empfängt Zeile 5
	Drückt „senden"
	WS hebt Zeilen 4 und 5 hervor und fragt „wünschen sie fortzufahren?"
Sendet Zeile 6
	empfängt Zeile 6 während die Warnung an ist.
	Drückt „Senden", um Zeile 7 zu senden.
	WS hebt Zeile 6 hervor und fragt „wünschen sie fortzufahren?".
	Händler beginnt, die Zeile 7 zu modifizieren, drückt „senden".
	WS prüft, dass keine Zeile empfangen wurde, sendet Zeile 7 und Bezugszahl von Zeile 6 an Server.
Empfängt Zeile 7.

Bevor die Funktionalität ausführlicher beschrieben wird, wird zuerst das dialogorientierte Geschäftssystem, auf das sie wirkt, mit Bezug auf 1 bis 14 beschrieben.
Das in 1 schematisch dargestellte System ist ein dialogorientiertes Geschäftssystem zum Handeln einer Vielfalt von Finanzinstrumenten durch Austausch von Nachrichten in einer Duplex-Nachrichtenumgebung. Instrumente, die gehandelt werden können, umfassen Devisen-Kassa (FX Spot), Termine und Outrights (fest terminierte Devisengeschäfte), wobei sie jedoch nicht auf diese begrenzt sind. Obwohl sich die folgende Beschreibung auf Devisen-Kassa und Termingeschäfte konzentrieren wird, ist es offensichtlich, dass dies nur für die Zwecke des Darstellens der Erfindung ist, und dass die Erfindung nicht auf irgendein bestimmtes Finanzpapier oder auf Finanzpapiere überhaupt begrenzt ist. Sie ist gleichfalls auf das Handeln jeder anderen vertretbaren Sache, wie beispielsweise Rohstoffe (commodities), Metalle, etc. anwendbar.
Das beispielhafte System ist vorzugsweise ein internetgestütztes System, bei dem Händler mit anderen Händlern von Händlerterminals über das Internet kommunizieren. Geschäfte werden durch einen Austausch von Nachrichten zwischen Händlern vereinbart. Der Nachrichteninhalt wird automatisch von dem System geparst, um geschäftsbezogenen Inhalt zur Verarbeitung zu identifizieren. Sobald das Parsen eine Geschäftszustandsänderung erfasst hat, wird der Rest der Geschäftsverarbeitung von dem Geschäftsstapel gehandhabt. Die Geschäftszustandsänderung muss nicht durch Dialog, sondern kann direkt von dem Terminal der Händler eingegeben werden, beispielsweise durch Verwenden von Bildschirmfunktionsschaltflächen oder Tastatur-angesteuerten Menüs, eingegeben werden. Somit ermöglicht das System ebenfalls Benutzern, durch einen einfachen Austausch von Geschäftsinhaltsdaten, die nicht dialogkritisch sind, und durch eine Mischung der beiden Verfahren zu handeln.
Die folgende Beschreibung gibt einen Überblick des Handelssystems, innerhalb dessen die Benutzerschnittstelle von Händlern verwendet wird, um Geschäfte auszuführen. Es ist jedoch offensichtlich, dass dies nur ein Beispiel eines Handelssystems ist, das zum Gebrauch mit der Erfindung geeignet ist. Die Erfindung ist nicht auf irgendein bestimmtes Handelssystem begrenzt, sondern ist auf jedes chatgestütztes Duplex-System anwendbar. Ein derartiges System kann internetgestützt sein oder auf einem herkömmlichen öffentlichen oder privaten Netzwerk arbeiten. Es kann eine verteilte Architektur verwenden oder mittels eines zentralen Host arbeiten oder auf eine beliebige andere Art und Weise ausgestaltet sein. Es ist jedoch ein Merkmal jedes derartigen Systems, dass Chat von einem Chat-Server gehandhabt wird, der ebenfalls der Chat-Handhabung fest zugeordnet sein kann oder ebenfalls weitere Funktionen durchführt.
Mit Bezug nun auf 1 basiert ein offenbartes Handelssystem auf einer Mehrzahl von Server-Farmen, die durch ein System-Intranet verbunden sind. Die Server-Farmen kommunizieren mit Händlerterminals auf Bank/Börsen-Parketten durch ein Kommunikationsnetzwerk, hier das Internet, und lokale Bank-Intranets. Der größere Teil der Geschäftsverarbeitung findet an Händlerterminals statt, wobei Geschäftsnachrichten von den Server-Farmen zu Vertragspartner-Händlerterminals geleitet werden. Die Server-Farmen leiten ebenfalls gehandelte Geschäftsinformation an Bankabrechnungsstellen (bank back office systems) zurück, um zu ermöglichen, dass Händlerzettel (deal tickets) erzeugt werden und Geschäfte abgerechnet werden. Die Geschäfte werden in das System entweder direkt von dem Händler oder durch zwischen den Händlern ausgetauschte geparste Dialoge eingegeben, wie es beschrieben wird. Das Parsen findet an den Händlerterminals statt.
2 zeigt das System auf schematische Art ein wenig ausführlicher. Eine Mehrzahl von Kundenbenutzern, von denen zwei gezeigt sind, kommunizieren miteinander und mit anderen, nicht gezeigten Kundenbenutzern durch Austauschen von dialogorientierten Nachrichten von Ihren Terminals über einen System-Server. Jedes Kundenterminal umfasst drei logische Komponenten: eine Benutzerschnittstelle 50, ein Kommunikationsmodul 52 und einen Parser 54. Die Kundenterminals können jeder geeignete Computer, wie beispielsweise ein PC oder eine Workstation, sein, der herkömmliche Komponenten, wie beispielsweise Eingabevorrichtungen einschließlich einer Tastatur und einer Maus und einen Monitor, der einem Händler die Benutzerschnittstelle darstellt, aufweist.
Die Kundenstationen und der Server kommunizieren über ein Kommunikationsnetzwerk, das ein privates Netzwerk oder ein öffentliches Netzwerk, wie beispielsweise das Internet, sein kann, beispielsweise über das World Wide Web, wie es 1 gezeigt ist. Das Kommunikationsmodul kann beispielsweise ein Modem an der Kundenstation oder dem Kunden-Ortsbereichsnetzwerk oder eine andere geeignete Vorrichtung sein.
Der Parser 54 führt eine Analyse von zwischen Systemkunden ausgetauschten Dialogen durch und extrahiert geschäftsbezogene Informationen aus diesen Dialog-Austauschen, wie es später ausführlich beschrieben wird. Die Funktionskomponenten des Systems: der Parser, die Benutzerschnittstelle und die Kommunikations-Software werden vorzugsweise als ein Applet jedes Mal in die Händlerterminals heruntergeladen, wenn sich ein Kunde in das System einloggt. Dies bedeutet, dass das Kundenterminal nicht irgendeine Software speichern muss, um auf das System zuzugreifen und es ablaufen zu lassen, wobei all dieses durch Zugreifen auf eine geeignete Seite auf dem World Wide Web durchgeführt werden kann. Das System kann von einem Händler verwendet werden, egal, wo er sich befindet. Wie jedoch ersichtlich wird, ist das bei diesem Beispiel beschriebene System dafür bestimmt, sehr große Beträge von Währungen und Währungsprodukten sowie auch andere vertretbare Sachen zu handeln, und ist in der Praxis auf Banken und andere Institutionen mit nachgewiesener Kreditwürdigkeit beschränkt. Nichtsdestotrotz ist die Portierbarkeit und die Flexibilität des Systems für Händler vorteilhaft und bei Dialog-Geschäftsystemen des Stands der Technik nicht verfügbar, bei denen der Zugriff auf ein proprietäres Netzwerk begrenzt ist.
Das Kommunikationsnetzwerk umfasst einen Geschäfts-Server 58 und einen Chat-Server 60. Diese bilden einen Teil der Server-Farm von 1. Der Geschäfts-Server wirkt, um die Einzelheiten vorgeschlagener Geschäfte gegen Geschäfts- und Bankregeln zu verifizieren, und ermöglicht, dass andere Prüfungen durchgeführt werden, bevor ein vorgeschlagenes Geschäft dem möglichen Vertragspartner sichtbar gemacht wird. Dies kann die Kreditwürdigkeit des Geschäftsausstellers umfassen; die ihre Fähigkeit ist, den Handel abzurechnen, den sie vorschlagen. Der Chat-Server 60 handhabt den Austausch von Dialogen zwischen Kunden auf dem Netzwerk. Wie es erläutert wird, werden dialogorientierte Nachrichten, die geschäftsbezogene Informationen enthalten können oder nicht, zwischen Kunden über den Chat-Server geleitet. Ein Kunde kann an mehreren Dialogen zu jeder Zeit teilnehmen und mehrere unterschiedliche Dialoge mit einem bestimmten anderen unterschiedlichen Kunden gleichzeitig durchführen, was es zwei Partnern ermöglicht, zwei oder mehrere Geschäfte in Verhandlung zur gleichen Zeit aufzuweisen.
3 zeigt die Benutzerschnittstelle, die an jedem Händlerterminal angezeigt wird. Die Anzeige umfasst eine Anzahl Felder. Bis zu einem Grad sind die angezeigten Felder von jedem Händler gemäß seiner oder ihrer Präferenzen konfigurierbar, obwohl einige der Felder permanent sind. Im Wesentlichen umfasst die Anzeige 100 drei imaginäre Behälter 102, 104 und 106. Der Behälter 102 ist der obere der drei Behälter und erstreckt sich über die Breite der Anzeige, wobei unter dem oberen Behälter ein unterer linker Behälter 104 und ein unterer rechter Behälter 106 ist. Zu der Linken der Behälter ist eine konfigurierbare Ikonenanzeige 108.
Der obere Behälter zeigt nur Felder an, die die volle Breite des Anzeigebereichs der Händler erfordern. Jedes der Felder, das angezeigt werden kann, wird einer von zwei Prioritäten zugewiesen. Ein Feld mit Priorität 1 kann nicht verdeckt werden. Ein Feld mit Priorität 2 kann verdeckt oder in der Höhe auf Null gesetzt werden. In jedem der beiden Fälle wird das Felddatenmodell beibehalten, wenn das Feld unsichtbar ist, was ermöglicht, dass die enthaltenen Daten angezeigt werden, wenn sie erneut sichtbar werden.
Es gibt drei permanente Felder, wobei jedes von diesen die Priorität 1 aufweist. Diese sind in den 3 und 4 gezeigt. In dem oberen Behälter 102 wird ein Geschäftsstapel 110, in dem unteren linken Behälter 104 ein Dialogbereich 112 mit einer Anzahl von Dialogen, bei denen der Händler teilnimmt, und in dem unteren rechten Behälter ein Ankommende-Dialoge-Feld 114 angezeigt, bei dem ankommende dialogorientierte Nachrichten angezeigt werden. Die ankommenden Nachrichten umfassen Dialoge, bei denen der Händler noch nicht teilnimmt, und vielleicht nie teilnehmen kann.
Die optionalen Felder, die der Händler für die Anzeige wählen kann, umfassen:
Ein Händlergeschäftsfeld (nicht gezeigt), dem eine Priorität 1 zugewiesen wird und das alle von dem Händler durchgeführten Geschäfte zeigt, und das in jeder der beiden unteren Behälter angezeigt werden kann;
ein Überblickfeld (nicht gezeigt), dem eine Priorität 1 zugewiesen wird und das in einer der beiden unteren Behälter positioniert ist;
ein Geschäftsprotokollfeld (nicht gezeigt) mit einer Priorität 2 und das Geschäfte zeigt, die von dem System protokolliert wurden und in dem oberen Behälter 102 angezeigt wurden;
einen Kursbereich 116, der die aktuellen Handelskurse auf dem System für verschiedene Währungspaare anzeigt und dem eine Priorität 2 zugewiesen ist; und
ein Dialogarchiv (nicht gezeigt), das in einem der unteren Behälter positioniert ist und eine Priorität 2 aufweist.
Wie es aus 4 ersichtlich ist, umfassen einige der Felder eine Schaltflächenleiste entlang ihres unteren Rands. Die verschiedenen Funktionen der Schaltflächen werden nachstehend erläutert. Die Schaltflächenleisten der Dialogfelder umfassen eine Schwebeschaltfläche. Ein Klicken auf diese Schaltfläche ermöglicht, dass die Position des Feldes um den Bildschirm sogar außerhalb des Fensters verändert wird, in dem das gesamte System angezeigt wird. Dies kann beispielsweise nützlich sein, wenn der Kunde wünscht, mehrere optionale Felder anzuzeigen oder es eine größere Anzahl von offenen Dialogen gibt. Bei der beschriebenen Ausführungsform können bis zu zehn Dialoge gleichzeitig ablaufen, obwohl es offensichtlich ist, dass dies eine beliebige Anzahl ist, die verändert werden kann.
Das Ankommende-Dialoge-Feld listet nur ankommende dialogorientierte Nachrichten auf. Bei dem Beispiel von 3 wird ein einziger Dialog angezeigt. Zu dieser Zeit ist der Kunde kein Partner des Dialogs. Der Dialog wird unter vier Überschriften angezeigt: Kennung (ID), die die eindeutige Dialogidentitätsnummer ist, Zeit, die die Zeit ist, bei der der Dialog von dem Vertragspartner initiiert wurde; Von, die die Identität des den Dialog initiierten Vertragspartners ist; und Nachricht, die die letzte Nachrichtenzeile in dem Dialog ist. Bei dem Beispiel von 3 wurde beispielsweise die Nachricht „Ein Dialog gestartet von peter@CITQ" von einem als Peter identifizierten Händler bei der Institution mit der Kennung CITQ gesendet. Der Dialog wurde um 13:34:54 initiiert und weist die Kennungsnummer 1791 auf. Jeder neue Dialog wird mit einer Kennungsnummer identifiziert. Er wird ebenfalls einer Geschäftsinfodatei zugeordnet, die einen Satz von geschäftsbezogener Information einschließlich der Geschäftsart: Devisen-Kassa, Devisen-Outrights, Termine etc.; den Geschäftsbetrag, die Geschäftsrichtung (Aussteller, Abnehmer) und andere notwendige Information umfasst. Die Geschäftsinfodatei umfasst ebenfalls den aktuellen Zustand des Geschäfts. Zentral zu der Art und Weise, mit der Dialoge geparst werden, ist das Konzept eines Geschäfts, das in einer Anzahl von Zuständen ist, die angeben, wie weit das Geschäft fortgeschritten ist. Im Wesentlichen beginnen diese Zustände mit Kein Zustand, der sich auf einen Dialog ohne geschäftsbezogene Information bezieht; RFQ, die der Zustand ist, bei der eine Kursanfrage von dem Parser identifiziert wurde; Kurs, bei dem ein Kurs von dem Parser als Antwort auf die RFQ identifiziert wurde; und Kaufen/Verkaufen, bei dem das Geschäft von einem Partner abgeschlossen wird, der übereinstimmt, bei dem notierten Preis zu kaufen oder zu verkaufen.
Unter dem Ankommende-Dialoge-Feld ist eine Schaltflächenleiste mit Schaltflächen, die mit 'Aufnehmen', 'Löschen', 'Übertragen' und 'Chat' markiert sind. Um einen Dialog zum Handeln auszuwählen, klickt der Kunde auf die Dialogzeile, was veranlassen wird, dass die Dialogzeile in einer zu allen anderen Dialogen in dem Feld unterschiedlichen Farbe angezeigt wird (im vorliegenden Fall ist es der einzige Dialog). Wenn der Kunde auf die Schaltfläche 'Aufnahme' klickt, wird ein Dialogfeld in dem unteren linken Behälter 104 für den ausgewählten Dialog geöffnet. An diesem Punkt veranlasst das System, dass alle anderen Partner, an die die dialogorientierte Nachricht gesendet wurde, die Nachricht 'Benutzername ist dem Dialog beigetreten' anzeigt. Wenn ein Partner einem Dialog beitritt, sehen sie diesen Dialog nur von dem Punkt, an dem sie beigetreten sind. Sobald eine erste Person eine Einladung aufgenommen hat, mit einem Geschäftscode zu chatten, wird diese Einladung von allen anderen Partnern entzogen, an denen die Einladung gesendet wurde.
Sobald ein Händler einen Dialog aufnimmt, wird der Dialog aus seinem Ankommende-Dialoge-Feld entfernt.
Die Schaltfläche 'Löschen' bewirkt, wenn sie geklickt wird, dass der ausgewählte Dialog von der Anzeige gelöscht wird. Wenn ein Dialog gelöscht ist, wird der Dialoginitiator ein 'Dialog von Benutzernamen verweigert' in ihrem eigenen Dialogfeld empfangen.
Die Schaltfläche 'Übertragen' wird nur freigegeben, wenn ein Dialog zweiseitig ist. Falls geklickt, wird der Dialog an den Händler oder den Geschäftscode übertragen, der dem Dialog-Übertragen-Dialog spezifiziert ist. Regeln können festgelegt werden, die definieren an wen, falls überhaupt, ein gegebener Händler einen Dialog übertragen kann.
Die Schaltfläche 'Chat' ruft das Starten einer Dialogsitzung auf und öffnet ebenfalls ein Dialogfeld in dem Dialogbereich. Mehrere Dialoge können mit der gleichen Person geöffnet werden, obgleich ein Warnkästchen vorzugsweise angezeigt wird, um den Kunden zu benachrichtigen, falls er versucht, einen zweiten oder anschließenden Dialog mit der gleichen Person zu öffnen.
Die gesamte Funktionalität der Schaltflächenleiste kann alternativ als ein Pulldown-Menü angezeigt werden, um die Betätigung allein durch die Tastatur zu ermöglichen.
Mit zusätzlichen Bezug auf 5 bis 7 zeigt der Geschäftsstapel eine Liste von Geschäften, bei denen der Händler beteiligt ist und die anhängig oder abgeschlossen sind.
Der Geschäftsstapel 130 umfasst die folgenden Hauptkomponenten: eine Geschäftsliste 132, ein Geschäftsdetail-Feld 134 und eine Schaltflächenleiste 136. Die Geschäftsliste präsentiert Information über ein Geschäft unter vier Überschriften: den Geschäftszustand 120, die Zeit 122, den Vertragspartner (Händler/Bank) 124, das Instrument, das gehandelt wird 126 und das Geschäft 126, das durchgeführt wird. Die in der Geschäftsliste präsentierte Information ist von dem gehandelten Instrument unabhängig. Dies wird durch die Verwendung des Geschäftsdetail-Felds erreicht und ist äußerst vorteilhaft, da es ermöglicht, dass der Geschäftsstapel dem Kunden auf eine sehr einfache Art und Weise mit der minimalen Informationsmenge und auf eine Art und Weise präsentiert wird, die von dem Händler ohne Weiteres aufgenommen wird.
Um den Text des Geschäft-Felds 126 zu verstehen, muss zuerst bemerkt werden, wie geschäftsbezogene Information in das System gebracht werden kann und wie das System die Information versteht, wie sie sich auf ein Geschäft bezieht. Geschäftsinformationen können dem System auf eine von zwei Arten vorgelegt werden: durch direkte Geschäftseingabe oder durch Parsen von Dialogen. Das Parsen von Dialogen wird später ausführlicher erläutert. In diesem Stadium ist es ausreichend, zu bemerken, dass Parsen beinhaltet, dass das System dialogorientierte Nachrichten analysiert, um zu bestimmen, ob sie irgendwelchen geschäftsbezogenen Inhalt enthalten. Falls sie es tun, dann wird das Geschäft in der Geschäftsliste angezeigt.
Ein Geschäft wird durch eine Eingabe 'Kursanfrage' (RFQ) in das System von einem Händler begonnen. Eine RFQ ist eine Angabe von einem Händler, dass er am Handel interessiert ist. Die erste Zeile der Geschäftsliste in 3 zeigt eine RFQ. Hier hat der Händler eine Anfrage auf den Markt gebracht, um $2,5 Millionen in dem US$/kanadischen Dollarmarkt zu handeln. In diesem Stadium werden keine Nachfrage- oder Angebotspreise angegeben, und es gibt keine Angabe, ob der Händler kaufen oder verkaufen möchte. Die RFQ könnte in das System als eine dialogorientierte Nachricht oder durch den Händler, der eine direkte Eingabe macht, eingegeben werden, wobei er in diesem Fall die Schaltfläche RFQ in der Geschäft-Schaltflächenleiste drückt. Dies wird ein Feld anzeigen, das nach dem Instrument, dem Währungspaar und dem Betrag fragt.
Somit kann ein Geschäft entweder durch die Eingabe einer direkten Kursanfrage in das System oder durch die Erfassung einer Kursanfrage durch das Parsen von Dialogen initiiert werden. Zweckmäßigerweise kann auf das Letztere als eine indirekte Kursanfrage Bezug genommen werden.
Wenn eine RFQ empfangen oder erfasst wird, bestimmt das System den Text, der in der Geschäftsliste angezeigt wird. Dies wird entweder eine Transkription der direkten RFQ oder eine Darstellung der geparsten, indirekten RFQ sein.
Eine Anzahl von Geschäftszuständen werden für jedes Instrument definiert. Jeder dieser weist eine zugeordnete Zustandskette, die in dem Zustandsfeld angezeigt wird, eine Geschäftskette, die der Text ist, der in dem Geschäft-Feld angezeigt wird, und eine verstandene Beschreibung auf.
Für jedes Geschäft in dem Geschäftsstapel gibt es eine entsprechende Dialogsitzung. In einigen Fällen rührte die RFQ von einem Dialog her. In anderen Fällen wird sie es nicht. In dem letzteren Fall, einem direkten Kurs, wird ein Dialog erzeugt, wobei jedoch ein Dialogfeld nur geöffnet wird, d.h., der Dialog wird preisgegeben, wenn es spezifisch von dem Händler angefordert wird.
Somit wird, wann immer das System eine Aktion an einem Geschäft als Antwort auf eine Händleraktion durchführt, eine Nachrichtenzeile in die Dialogsitzung aufgenommen, die die Art dieser Aktion angibt. Diese Nachrichtenzeile ist in einer Form, bei der, wenn der Händler den zu Grunde liegenden Dialog preisgegeben hatte und den Nachrichtentext eingetippt hat, sie parsen und die gleiche Aktion an dem Geschäft erzeugen wird. Die Nachricht wird in einer Form sein, die die beste Dialogpraxis vom Blickpunkt des Parsens widerspiegelt.
Die Geschäftsliste zeigt alle aktuellen RFQ an, bei denen der Händler beteiligt ist. Er kann andere RFQ sehen, wenn die geeigneten Optionen gesetzt sind. Der Händler wird die Option aufweisen, abgeschlossene Geschäfte automatisch zu löschen, wenn sie abgeschlossen sind. Der Händler wird vorzugsweise die Option aufweisen, alle RFQ zu sehen, die automatisch von seinem Konto weitergeleitet wurden. Automatisch weitergeleitete RFQ sind von der Geschäftsliste durch die Löschfunktion zu löschen.
Wie es oben erwähnt ist, ist die Geschäftsliste von dem gehandelten Instrument vollständig unabhängig. Somit zeigt die Geschäftsliste nur fünf Spalten an: Zustand, Zeit, Händler/Bank, Instrument und Geschäft. Die Geschäftsspalte enthält eine Instrument/Zustand-spezifische Zeichenkette, die von dem System erzeugt wird, um das Geschäft zu beschreiben.
Um die Unabhängigkeit der Geschäftsliste auszugleichen, weist das Geschäftsdetail-Feld an dem unteren Teil der Geschäftsliste ein Instrumentspezifischen Format auf und spiegelt volle Einzelheiten des Geschäfts wider, das aktuell in der Liste ausgewählt ist.
Wenn ein neues Geschäft zu der Geschäftsliste hinzugefügt wird, wird es am unteren Teil der Liste ohne Rücksicht auf die aktuell ausgewählte Sortierungsreihenfolge eingeführt (eine Umsortierung wird verwendet, um das Geschäft ordnungsgemäß in der Sortierungsreihenfolge zu positionieren). Wenn ein Geschäft zu der Geschäftsliste als Ergebnis der Aktionen des Händlers (RFQ oder Chat) hinzugefügt wird, wird das zuletzt zu der Tabelle hinzugefügte Element das ausgewählte Element. Die Liste wird durchlaufen (to scroll), so dass das ausgewählte Element für den Händler sichtbar ist. Wenn das neue Geschäft von einem Vertragspartner initiiert wird, ändert sich das ausgewählte Geschäft nicht. Wenn der Fokus in der Geschäftsliste ist, ändert sich das aktuell ausgewählte Element nicht, wenn ein neues Geschäft zu der Liste hinzugefügt wird. Wenn ein neues Geschäft zu dem Geschäftsstapel hinzugefügt wird, so dass der Geschäftsstapel durchlaufen werden müsste, um das Geschäft zu betrachten, leuchtet der Hintergrund der Bildlaufleiste (scroll bar) beispielsweise rot auf, bis das Geschäft durch das Durchlaufen sichtbar gemacht wird.
Das Geschäftsdetail-Feld kann Schaltflächen und andere Steuerungen enthalten, die sich auf eine Instrument-spezifische Funktionalität beziehen, die durch die standardmäßigen Geschäftsstapelschaltflächen nicht verfügbar ist. Wenn ein Geschäft in einem modifizierbaren Zustand ist, wird die Modifikation über Editiersteuerungen in dem Geschäftsdetail-Feld durchgeführt. Diese potenziell modifizierbaren Felder sollen einen unterschiedlichen Farb-Hintergrund (beispielsweise Cyan) zu dem Rest des Geschäftsdetail-Felds aufweisen. Das Geschäftsdetail-Feld kann selbst eine unterschiedliche Farbe, beispielsweise Gelb, als die Geschäftsliste aufweisen. Wenn die Felder editierbar sind, werden sie beispielsweise durch einen weißen Hintergrund mit einem schwarzen Rand unterschieden.
Das Format des Geschäftsdetail-Felds ist für das Instrument des Geschäfts spezifisch. Jede Implementierung des Feldes weist bestimmte gemeinsame Felder und Steuerungen auf, die immer an derselben Stelle sind: Zustand, Zeit, Händler/Bank, Instrument und Fehler/Warn-Kombinationskästchen (combo box). Die 5 und 6 veranschaulichen das Geschäftsdetail-Feld für Devisenkassa.
Somit umfasst das Geschäftsdetail-Feld alle Informationen in der Geschäftsliste mit der Ausnahme, dass es anstatt der Geschäftsliste die Informationen enthält, die, wenn sie eingegeben und dann geparst werden, zu der Geschäftsliste führen werden. Somit umfasst für Devisenkassa das Geschäftsdetail-Feld Betrag, Währungspaar, Wertstellung, Nachfrage- und Angebotspreise und Gehandelt. In 5 ist das Geschäftsdetail-Feld für das erste Geschäft in dem Stapel gezeigt. Dies ist ein Geschäft, das gerade begonnen hat und bei dem die RFQ ausgegeben wurde. Da es noch keine Nachfrage- oder Angebotspreise gibt, sind die einzigen Felder, die vorbelegt sind, der Betrag, das Währungspaar und die Wertstellung. Wenn geparst, führt dies zu 'ich fordere 2,5 Millionen USD.cad' an.
In 6 ist das hervorgehobene Geschäft das dritte in der Liste, und der Zustand des Geschäfts ist Vor-Angebot Aussteller was angibt, dass der Aussteller das Abnehmerangebot aufgenommen hat und Nachfrage- und Angebotspreise für 3 200 Millionen japanische Yen anbietet. Da sowohl der Betrag als auch die Preise editiert werden können, erscheinen sie in dem Geschäftsdetail-Feld als schwarzer Text auf einem weißen Hintergrund.
Das Parsen innerhalb Geschäftsysteme ist bekannt. Parsen wird bei dem Reuters Dealing 2000/1 System verwendet, durch Reuters PLC verkauft und seit vielen Jahren auf dem Devisenmarkt verwendet. Bei diesem System finden jedoch alle Geschäftstransaktionen durch Dialog statt, der auf einem Simplex-Modell durchgeführt wird. Der Händler hat nicht die Option, eine direkte Geschäftseingabe zu verwenden, wie es oben beschrieben ist. Als Ergebnis gibt es keine Anforderungen für das System, fähig zu sein, Geschäftsinformation zu entparsen. Deshalb und aus verschiedenen anderen Gründen unterscheiden sich die Anforderungen des vorliegenden Systems an das Parsen deutlich von denen des Stands der Technik. Die folgende Beschreibung wird die Devisenmärkte und insbesondere die oben beschriebenen drei Instrumente betrachten: Devisenkassa, Devisen-Outrights und Devisentermine. Zuerst wird die Art und Weise beschrieben, mit der der Parser arbeitet, indem mit Bezug auf die Ablaufdiagramme von 7, 8a, 8b und die verschiedenen Bildschirmausdrucke der Benutzerschnittstelle von 9 bis 14 erläutert wird, wie ein dialogorientiertes Geschäft ausgeführt wird. Es sei zuerst bemerkt, dass die 9 bis 14 eine unterschiedliche Ausführungsform zu der Benutzerschnittstelle zeigt, die vorher beschrieben wurde.
Bei allen Stufen des Chat-Austausches überwacht der Parser die Dialoge, wobei er nach einer RFQ (Kursanfrage) sucht. Die Anwesenheit einer RFQ alarmiert den Parser, dass ein neues Geschäft initiiert wird. Wenn somit zwei Händler Nettigkeiten austauschen, die sich nicht auf ein Geschäft beziehen, wird der Parser den Dialog nach einer RFQ überwachen. Der Parser des Benutzers ist für das Parsen des Dialogs des Benutzers verantwortlich, wobei er jedoch keine Rolle bei dem Parsen eines von dem anderen Partner empfangenen Dialogs spielt.
Bei dem folgenden Beispiel wurde ein neuer Dialog von einem Kunden initiiert, der als Kunde 1 bezeichnet und in 9 als kdunay@EBSN gezeigt wird. Dieser Benutzer hat eine Nachricht in sein Chat-Feld getippt und die Eingabetaste betätigt. Dies veranlasst die Benutzerschnittstelle die Chat-Zeile an den Parser ohne Rücksicht auf den Inhalt zu senden. Der Parser parst den Dialog, wobei er nach einer Änderung des Zustands und anderen geschäftsbezogenen Informationen sucht. Bei dem vorliegenden Fall hat der Parser eine RFQ in der Chat-Zeile entdeckt. Diese Zeile, obgleich sie nicht gezeigt ist, kann ein 'ich möchte einen Yen' gewesen sein. Der Parser erfasst dies als eine RFQ und schaut dann nach anderen geschäftsbezogenen Informationen, die das gehandelte Instrument, hier als Devisenkassa identifiziert, das Währungspaar, hier US$/japanischer Yen und den Betrag, hier 1 Million umfasst. Der Parser gibt den geparsten Dialog an die Benutzerschnittstelle in der Form der Geschäftsinfostruktur zurück, auf die vorher Bezug genommen wurde, und die den Geschäftszustand und die geschäftsbezogenen Informationen enthält.
9 zeigt die Situation, bei der die Geschäftsinfostruktur an die Benutzerschnittstelle zurückgegeben wurde. Die RFQ wurde noch nicht in das System eingegeben und wird als eine geparste Zeile 200 in dem Geschäftsstapel 202 angezeigt. Die geparste Zeile kann entweder von dem Benutzer, kdunay@EBSN, durch Betätigen der roten Abbruchschaltfläche 204 für ungültig erklärt oder editiert werden, beispielsweise, um den Betrag der Währung zu ändern, wenn der Händler einen Fehler gemacht hat, seine Meinung ändert oder auf eine Änderung in den Marktbedingungen reagiert. Das Editieren wird durch Drücken der Schaltfläche 'Festlegen' 208 durchgeführt. Alternativ kann der Benutzer den Dialog neu eingeben, so dass er erneut geparst wird. Um den Benutzer anzugeben, dass eine Aktion erforderlich ist, wird der Zustand der Zeile in dem Geschäftsstapel vorzugsweise in einer repräsentativen Farbe, beispielsweise grün, gezeigt. Die Schaltfläche 206 auf der Schaltflächenleiste, die der Benutzer für die zu sendende RFQ drücken muss, ist ebenfalls in grün gezeigt. Der geparste Dialog ist in dem Geschäftsstapel in einer repräsentativen Farbe, beispielsweise rot, gezeigt, um zu zeigen, dass es ein systemerzeugter Text ist. An diesem Punkt wird eine Systemnachricht 'Vorlegen?' ebenfalls in rot in dem Dialogfeld angezeigt.
Es ist ersichtlich, dass sich der Geschäftsstapel von 9 von demjenigen des vorhergehenden Beispiels dadurch unterscheidet, dass er einen Streifen 210 über der Schaltflächenleiste aufweist, die dem Benutzer bedeutsame Information über ein hervorgehobenes Geschäft anzeigt. Somit umfasst der Streifen den Geschäftszustand, den Händler, das Instrument (Kassa), das Währungspaar, den Betrag mit der angegebenen Basiswährung und die Nachfrage- und Angebotskurse. Diese letzteren Kurse werden in Kästchen 212, 214 angezeigt, die in 15 nicht gefüllt sind, da noch kein Kurs bei diesem Geschäft notiert wurde.
Bei dem Beispiel führte die geparste Dialogzeile zu in einem erfassten Geschäftszustand. Die Textzeile könnte einfach etwas wie 'Hallo, wie geht's' gewesen sein. Der Parser würde dann keine geschäftsbezogene Information erfasst haben, sondern würde eine Antwort an die Benutzerschnittstelle senden, um anzugeben, dass eine Dialogzeile geparst wurde, jedoch keine Geschäftsinformation gefunden wurde.
Wenn der Benutzer mit der geparsten Zeile zufrieden ist, wie sie in dem Geschäftsstapel erscheint, drückt er die Schaltfläche 'Fortfahren' 206. Dies veranlasst, dass der geparste Dialog an das Kommunikationsmodul des Kunden 54 (2) und dann an den Geschäfts-Server 58 gesendet wird.
An diesem Punkt gibt es eine Anzahl von Merkmalen des Parsens, die hervorgehoben werden sollten. Zuerst parst der Parsen den Dialog zeilenweise. Das Parsen findet nicht statt, bis der Benutzer das Tippen beendet und die Sendeschaltfläche 216 betätigt hat. Dies steht im Gegensatz zu dem bei dem Reuters 2000/1 System verwendeten System, auf das vorher Bezug genommen wurde, das Dialoge zeilenweise parst, wenn sie von dem Benutzer eingegeben werden. Das hier beschriebene System ist dadurch vorteilhaft, dass der Benutzer ändern kann, was er getippt hat, beispielsweise um auf Änderungen in dem Markt zu reagieren oder einfach um Fehler zu korrigieren, ohne dem Vertragspartnerhändler seine Karten (Beweggründe/Strategien) offen zu legen. Dem Händler des Vertragspartners Kenntnis über eine Sicht des Marktes zu geben ist höchst unerwünscht, da es die Nachfrage oder das Angebot beeinflussen kann, die/das er macht.
Zweitens spielt der Parsen bei dem geschäftemachenden Verfahren keine Rolle und behält keine Kenntnis des Geschäfts. Der Parsen schaut nur auf die Dialogzeile nach Informationen bezüglich des Geschäftszustands. Er gibt die Geschäftsinfostruktur zu der Benutzerschnittstelle zurück und behält keine Kenntnis des Geschäfts. Dies macht den Parsen sehr einfach.
Drittens basiert das Parsen auf einer Geschäftszustandsstruktur mit der Betonung auf die Erfassung von Zustandsbewegungen. Die Geschäftszustände sind sehr einfach: Keiner, RFQ, Angebot, Kaufen/Verkaufen, obwohl diese ausgearbeitet werden, wie es erläutert wird. Bei jedem dieser Zustände gibt es eine Anzahl geschäftsbezogener Begriffe, nach denen der Parser sucht. Dies macht das Parsen sehr einfach und genau. Erstens, da es nicht viele Begriffe gibt, nach denen zu suchen ist, und zweitens, da es eine geringe Chance gibt, das eine Verwirrung entsteht, die zu einem Fehlparsen führt. Dies könnte beispielsweise auftreten, wenn eine Zeile eines Dialogs auf ein vergangenes Geschäft zwischen den Partnern Bezug nahm. Durch Trennen des Geschäftsverfahrens in eine Anzahl von Zuständen, die jeweils eine begrenzte Anzahl von Begriffen aufweisen, die geparst werden können, ist es für den Parser relativ leicht, derartige Fehlparsen zu vermeiden. Die Einzelheiten der Zustände und der geschäftsbezogenen Begriffe für jeden Zustand werden später ausführlich beschrieben.
Bei dem gegebenen Beispiel enthielt der von dem Parser geparste Dialog sowohl eine Änderung im Geschäftzustand als auch alle Information, die erforderlich ist, um diesen erfassten Zustand zu begleiten (Instrument, Währungspaar, etc.). Für jeden der möglichen Geschäftszustände gibt es nur eine Anzahl erlaubter Übergänge und für jeden Geschäftszustand gibt es eine begrenzte Anzahl von Ausdrücken, die der Parser als Angabe einer Änderung des Zustands erkennen wird. Wenn der neue Dialog beispielsweise eine Kursanfrage umfasst, wird der Parser nach Informationen suchen, die einen Kurs angeben. Er wird die gesamte Zeile parsen und nach einem gegebenen Zustand suchen, um eine vorbestimmte Anzahl von Informationsfeldern zu füllen. Diese werden abhängig von dem Zustand variieren. Wenn der Parser eine Änderung des Zustands von RFQ im Angebot erwartet, würde er beispielsweise suchen, ob es eine Angabe eines Nachfragekurses und/oder eines Angebotskurses oder eine Verweigerung anzubieten gibt. Wenn es einen Nachfrage/Angebotskurs gibt, sucht er in dem Fall eines Devisenkassahandels ebenfalls nach einer Angabe der Währung. Die Zustände der Geschäfte und der erforderlichen Felder werden sich abhängig von dem gehandelten Instrument verändern.
Sobald der von dem Benutzer eingegebene Dialog geparst wurde, gibt der Parser der Benutzerschnittstelle eine von drei Möglichkeiten zurück:

a) es gibt nichts in dem Dialog, das geparst werden kann. Dies wird der Fall sein, wenn der Dialog keine geschäftsbezogene Informationen enthält;
b) eine Aktualisierung der Geschäfts-Struktur, die den neuen Geschäftszustand und die gefundenen Gebiete umfasst;
c) eine Fehlermeldung, wenn es eine Zweideutigkeit gibt und er die Zustandsänderung nicht auflösen kann. In diesem Fall wird der Fehler in dem Chat-Stapel angezeigt und das Geschäft nicht geändert.

Es sei zu der geparsten dialogorientierten Nachricht zurückgekehrt. Von dem Kommunikationsmodul des Kunden 54 wird die Nachricht an den Geschäfts-Server gesendet, wobei an diesem Punkt geprüft wird, um sicherzustellen, dass sie mit Systemvorschriften, Bankvorschriften und geschäftsbezogenen Regeln übereinstimmt. Sie kann ebenfalls ermöglichen, dass Bonitätsprüfungen, beispielsweise durch Verknüpfen von Einzelheiten in dem Geschäft mit den globalen Kreditprüfmechanismen der Benutzerbank, durchgeführt werden. Wenn das Geschäft nicht fortgesetzt werden kann, wird eine Fehlermeldung an dem Benutzerterminal angezeigt, wobei jedoch der Vertragspartner von dieser Tatsache keine Kenntnis erhält. Soweit wie es den Vertragspartner betrifft, wird die RFQ, die er ausgegeben hat, einfach nicht beantwortet. Diese Fähigkeit, fehlgeschlagene Geschäfte zu verbergen, ist vorteilhaft, da ein Benutzer häufig nicht wünscht, dass ein Vertragspartner erfährt, dass er ein Geschäft mit ihm versucht hat, das jedoch fehlgeschlagen ist. Er wird ebenfalls nicht wünschen, dass der Vertragspartner die Einzelheiten des versuchten Geschäfts kennt, da es ihm wertvolle Information über seine Absichten und sein Lesen des Markts offen legen wird. Dieser Vorteil rührt von der Art und Weise her, mit der das System Dialoge auf einer zeilenweise Grundlage und nicht in Echtzeit parst, wenn sie zeichenweise eingetippt werden.
Unter der Annahme, dass der Geschäfts-Server 58 die RFQ nicht zurückweist, wird die geparste Nachricht an die Zielbenutzerschnittstelle über das Kommunikationsmodul des Zielkunden gesendet. Es sei bemerkt, dass das System angeordnet ist, so dass der Geschäfts-Server allen geschäftsbezogenen, geparsten Verkehr und der Dialog- oder Chat-Server alle Dialoge handhabt, die nicht-geparsten Dialog übertragen, d.h. Dialoge, für die der Parser herausgefunden hat, dass sie keine Änderung des Geschäftszustands enthalten. Diese Doppel-Server-Anordnung ist zweckmäßig, jedoch nicht wesentlich, und könnte durch einen einzigen Server oder eine andere Server-Konfiguration ersetzt werden.
10 zeigt die Benutzerschnittstelle, nachdem die RFQ an den Vertragspartner gesendet wurde. Der Zustand des Geschäfts in dem Geschäftsstapel ist als 'Warten auf Aufnahme' gezeigt, was bedeutet, dass die Benutzerschnittstelle nicht benachrichtigt wurde, dass der Vertragspartner das Geschäft von seinem ankommenden Dialogfeld aufgenommen hat. Bei dem Dialogfeld für das Geschäft wird nun der Dialog des Kunden in einer repräsentativen Farbe, beispielsweise grün, gezeigt, um zu zeigen, dass die Nachricht von dem Kunden herrührte.
Mit Bezug nun auf 11 ist die Benutzerschnittstelle des Kunden gezeigt, an die die in 8 beschriebene RFQ gesendet wurde. Der Kunde wird als test@EBSN identifiziert. Die RFQ-Nachricht wurde von dem Geschäfts-Server weitergeleitet und an test@EBSN des Kunden weitergesendet. Die Benutzerschnittstelle des sendenden Kunden wurde ebenfalls benachrichtigt, dass die Nachricht gesendet wurde. Die ankommende Nachricht wird zuerst in dem Feld für ankommende Nachrichten des Kunden erscheinen. In 9 hat der Kunde test@EBSN diese Nachricht doppelt angeklickt, um einen neuen Dialog in dem aktiven Dialogfeld zu öffnen. In der Figur wird dies als Dialog gekennzeichnet, wobei der Name des Vertragspartners kdunay@EBSN gekennzeichnet wird. Das System gibt in dem Dialogfeld an, dass sich der Kunde test@EBSN dem Dialog angeschlossen hat, und zeigt die geparste Nachricht in dem Geschäftsstapel an. Es sei bemerkt, dass die Nachricht als Quote 1 mil JPYusd/JPY? gekennzeichnet wird, was eine verschönerte Version der in dem Geschäftsstapel des Ausstellerkunden angezeigten geparsten Nachricht ist. Die Originalversion der Nachricht wird in dem Dialogfeld angezeigt. Die Nachricht wird in dem Dialogfeld in einer repräsentativen Farbe, beispielsweise blau, angezeigt, um anzugeben, dass es eine ankommende Nachricht ist. In dem Geschäftsstapel wird der Zustand des Geschäfts als 'Aufnehmen' angezeigt und grün gefärbt, um anzugeben, dass eine Aktion von dem Kunden erforderlich ist. In diesem Fall muss der Kunde auf die RFQ antworten.
Der zweite Kunde test@EBSN tippt dann seine Antwort auf die RFQ in die Chat-Zeile 220 des Dialogfeldes ein und betätigt die Sendeschaltfläche 222. Auf die gleiche Art und Weise wie die RFQ-Zeile veranlasst dies die Benutzerschnittstelle, die vollständige Textzeile an den Parser zu senden, der den Text erneut parst und die Geschäftsinfostruktur an die Benutzerschnittstelle zurücksendet. Der geparste Text, wenn er eine Zustandsänderung enthält, und die notwendige geschäftsbezogene Information wird über den Geschäfts-Server an den Vertragspartner gesendet. Es sei bemerkt, dass der Parser für den Kunden kdunay@EBSN nur Dialog parst, der von diesem Kunden eingegeben wurde, und der Parser bei dem Kunden test@EBSN nur den von diesem Kunden eingegebenen Dialog parst.
12 zeigt den Vertragspartnerkunden test@EBSN, wenn ein Angebot von dem Benutzer eingegeben und von dem Parser geparst, jedoch von dem Benutzer nicht bestätigt wurde. Der Zustand in dem Geschäftsstapel zeigt Angebot?, und das Dialogfeld gibt das Angebot als von dem Parser geparst gefolgt von einem Fragezeichen an. Die Chat-Zeile des Dialogfeldes lädt den Benutzer ein, fortzufahren. In 12 wird der Zustand in dem Geschäft-Feld vorzugsweise in einer eine Warnung anzeigenden, repräsentativen Farbe, in diesem Fall Orange, gezeigt. Das System zeigt eine Nachricht in dem Dialogfeld 'Große Zahl (Big Figure) nicht verfügbar' an. In diesem Fall ist die Nachricht falsch und wurde erzeugt, als das Kursfeld gesperrt war, wobei es jedoch dazu dient darzustellen, wie Warnungen angezeigt werden können.
13 zeigt die Benutzerschnittstelle des Kunden kdunay@EBSN, wenn die Antwort empfangen wird. Der Kunde test@EBSN hat ein Angebot als Antwort auf die als 123.33/123.35 gezeigte RFQ vorgelegt. Diese zwei Zahlen sind die Kauf/Verkaufsspanne. Diese wird in dem Dialogfeld in blau gezeigt, da es eine ankommende Nachricht ist. Es sei bemerkt, dass der vorhergehende Eintrag in dem Feld der eigene Dialog des Kunden ist. Dies wird in einer repräsentativen Farbe, beispielsweise grün gezeigt. Der Geschäftsstapel zeigt die Änderung in dem Zustand in Kaufen/Verkaufen, wobei der Zustand in grün hervorgehoben wird. Dies zeigt, dass eine Aktion durch den Kunden erforderlich ist und dass die nächste Phase des Geschäfts entweder eine Vereinbarung, zu dem Angebotspreis zu kaufen und zu verkaufen oder eine Verweigerung ist. Es ist ersichtlich, dass die Geschäftsinformationszeile die Angebotspreise, den Betrag und das Währungspaar zeigt, und dass die großen Kästchen auf dem unteren Streifen 212, 214 nun die Nachfrage/Angebotspreise aufweisen.
14 zeigt die Schnittstelle des ersten Kunden, nachdem der Kunde auf das Angebot geantwortet hat, indem er vereinbart, zu dem Angebotspreis zu verkaufen. Der Zustand hat sich in 'Ich verkaufe' geändert, und die Geschäftszeile liest sich nun 'Ich verkaufe 1 mil JPY usd/JPY@123.33. Die letzte Zeile in dem Dialogfeld zeigt in grün, dass der Kunde verkauft hat, und dieser geht eine Systemaufforderung in rot Verkaufen? voraus. Diese Aufforderung erscheint, wenn der Benutzer 'Verkaufen' eintippt und die Zustandsänderung in Verkaufen von dem Parser erfasst und an die Benutzerschnittstelle zurückgegeben wird, jedoch bevor der Kunde den Verkauf durch Betätigen der Schaltfläche Fortfahren bestätigt hat.
Egal was der Zustand eines Geschäfts ist, der Parser sucht immer nach neuen RFQs, und wenn eine erfasst wird, öffnet er einen neuen Dialog. Somit könnte bei dem vorhergehenden Beispiel, anstatt übereinzustimmen zu verkaufen, der Kunde kdunay@EBSN eine neue Anfrage eingebracht haben, wie beispielsweise 'Ich möchte 1 mil gpb', was angibt, dass er eine Million £Sterling gegen $US kaufen möchte. Der Parser erfasst diese RFQ und öffnet einen neuen Dialog, wobei er jedoch den existierenden Dialog nicht beendet. Es gibt nun zwei Dialoge zwischen den gleichen zwei Partnern. Die Fähigkeit, verschiedene Dialoge zwischen den gleichen zwei Vertragspartnern gleichzeitig ablaufen zu lassen, ist höchst erwünscht. Das System kann eine große Anzahl von gleichzeitigen Dialogen zwischen den gleichen zwei Vertragspartnern, beispielsweise 10, unterstützen. Dies sollte nicht mit der Fähigkeit verwechselt werden, eine Anzahl von Dialogen mit unterschiedlichen Vertragspartnern zur gleichen Zeit offen zu halten, was in der Technik bekannt ist und ebenfalls mit dem die Erfindung verkörpernden System möglich ist. Der Dialog wird in einer dritten Farbe, beispielsweise blau, gezeigt.
Die obige Erläuterung veranschaulicht, wie das System einen von dem Benutzer eingegebenen Dialog handhabt. Im Verlauf eines Geschäfts wird es verschiedene Dialogzeilen geben, wobei jede in der erläuterten Art und Weise gehandhabt wird. Sobald ein Parser die Geschäfts-Struktur und die erfassten Felder an die Benutzerschnittstelle weitergeleitet hat, gehen die Informationen von dem Parser verloren. Der Parser weist vorzugsweise keine Kapazität oder Anforderung auf, um Informationen über die Historie des Dialogs zu behalten.
Zurückkehrend nun zu 7 und 8, zeigt 7 einen Überblick des beschriebenen Verfahrens. Bei Schritt 300 sucht der Parser, ob es eine Kennungsnummer für einen gegebenen Dialog gibt. Wenn es keine gibt, erzeugt er bei Schritt 302 eine neue Geschäftsinfostruktur, und setzt bei Schritt 304 den Zustand des Geschäfts auf Ano deal@. Wenn es eine Kennung gibt, schlägt er den Geschäftszustand 306 aus dem vorhergehenden Parsen nach. Dieser Zustand wird jedoch nicht bei dem Parser gehalten, sondern wird von der Benutzerschnittstelle bereitgestellt. Bei Schritt 308 wird der aktuelle Geschäftszustand auf die nächste Stufe in dem Geschäft eingestellt, und bei Schritt 310 werden Definitionen auf die Nachricht gemäß dem aktuellen Geschäftszustand angewendet. Diese bestimmen, welche Begriffe der Parser in dem Dialog als geschäftsbezogene Informationen bestätigen wird.
In 8a und 8b gibt der Händler eine Nachricht an die Benutzerschnittstelle bei Schritt 400 ein. Diese Nachricht wird von der Benutzerschnittstelle an den Parser gesendet, wo sie bei 410 empfangen wird. Bei 420 versucht der Parser, die Nachricht zu parsen. Wenn sie nicht geparst werden kann, wird die dialogorientierte Nachricht an den Chat-Server bei 430 und dann an den vorgesehenen Empfänger bei 440 gesendet. Eine Nachricht, die nicht geparst werden kann, ist eine, die keinen geschäftsbezogenen Inhalt aufweist.
Wenn der Parser geschäftsbezogene Informationen erfassen kann, bestimmt er bei Schritt 450, ob es einen Fehler gibt oder nicht. Wenn ein Fehler erfasst wird, wird eine Fehlermeldung an den Händler bei 460 gesendet.
Wenn es keinen Fehler gibt, bestimmt der Parser bei Schritt 470, ob das Parsen beendet ist oder nicht. Wenn es nicht ist, wird der Kunde gefragt, die Informationen bei Schritt 480 zu beenden.
Wenn das Parsen erfolgreich abgeschlossen wurde, wird die Geschäftsinformationsdatei bei Schritt 490 aktualisiert, und die Ergebnisse des Parsens werden an der Benutzerschnittstelle bei Schritt 500 angezeigt.
Die Händler müssen dann entscheiden, ob sie fortfahren und die geparste Nachricht an den Vertragspartner senden möchten oder nicht (bei 510). Die Bestätigungsstufe wird durch die Fortfahr-, Editier- und Abbruchschaltflächen auf dem vorher beschriebenen Geschäft-Feld durchgeführt. Bei dem vereinfachten Diagramm von 8b ist die Editierfunktion nicht gezeigt. Wenn der Händler nicht fortfahren möchte, wird das Geschäft bei Schritt 520 für ungültig erklärt, ohne dass es dem Vertragspartner gezeigt wurde. Wenn der Händler fortzufahren wünscht, wird die geparste Nachricht bei 530 an den Geschäfts-Server gesendet, und der Geschäfts-Server versucht bei 540 die geparste Nachricht gegen die Systemgeschäftsregeln zu bestätigen. Wenn er das Geschäft bei 550 nicht bestätigen kann, wird der Händler benachrichtigt, wobei jedoch der Vertragspartnerhändler keine Angabe empfängt, dass die Nachricht jemals gesendet wurde. Wenn das Geschäft bestätigt wird, dann wird eine Bestätigungsnachricht an den Händler bei 560 und ebenfalls an den Chat-Server bei 570 und an den Empfänger bei 440 gesendet.
Mit Bezug nun auf 15 bis 20 wird das Chat-Feld bei verschiedenen Stufen des Fortschreitens eines Dialogs gezeigt. Diese Figuren erläutern verschiedene Aspekte der vorliegenden Erfindung.
Die Funktionalität des Chat-Servers (60 2) wird zuerst erläutert. Wie es zuvor erläutert wurde, handhabt der Chat-Server Dialoge zwischen den Vertragspartnern, wobei jede Nachricht protokolliert wird, wie sie empfangen wird, wobei jede Nachricht dem Sender bestätigt und sie an den bestimmten Empfänger weitergeleitet wird.
Bei der Ausführungsform der vorliegenden Erfindung weist der Chat-Server eine Referenz jeder Chat-Zeile zu, die von einer Workstation empfangen wurde. Typischerweise ist diese eine Bezugsnummer. Dieser Bezug wird immer mit einer Chat-Zeile gesendet, wenn der Chat von dem Chat-Server zu der Zielhändler-Workstation gesendet wird. Die Bezugsziffern sind überall in dem Handelssystem eindeutig und wiederholen sich nicht (d.h., dass sie nicht zu Null oder einen anderen Startpunkt bei einem vorbestimmten Wert zurückkehren).
Wenn der Chat-Server eine Chat-Zeile protokolliert, die er von einer Händler-Workstation empfangen hat, wird er die Bezugsziffer, die er dieser Zeile zugewiesen hat, zusammen mit der Zeile in der Chat-Datenbank protokollieren.
Um eine Überkreuzung zu handhaben, vergleicht der Chat-Server, wenn er irgendeine Textzeile von der Workstation empfängt, die Bezugsziffer des Chats, auf den in der Nachricht geantwortet wurde, mit der Bezugsziffer der letzten Chat-Nachricht in der Datenbank.
Wenn die Ziffern nicht identisch sind, setzt der Chat-Server ein Überkreuzungs-Flag für die von der Workstation empfangene Nachricht in der Chat-Datenbank. Der Chat-Server protokolliert ebenfalls die Bezugsziffer der Nachricht, auf die geantwortet wird, wenn sie von der Workstation empfangen wird, in der Chat-Datenbank.
Dieses Verfahren wird in dem Ablaufdiagramm von 21 dargestellt.
Bei der mit Bezug auf 1 bis 14 beschriebenen Ausführungsform ist das System Internet-gestützt, und ein Applet stellt dem Benutzer die direkte Geschäftsfunktionalität bereit. Die folgende Beschreibung bezieht sich auf Modifikationen an dem Applet, obwohl es offensichtlich ist, dass die aufgenommene Funktionalität nicht durch ein Applet implementiert werden muss. Sie könnte beispielsweise in jeder der Händler-Workstations programmiert und auf diesen Workstations resident sein.
Um dem Applet, das in eine Workstation beim Hochfahren heruntergeladen wird, die einer Chat-Zeile zugewiesene Bezugsziffer mitzuteilen, verwendet der Chat-Server die SendChatAck-Nachricht, die verwendet wird, um den Empfang einer Nachricht durch den Chat-Server dem Applet zu bestätigen. Der Applet zeigt die Chat-Zeile nicht an, bis die Bezugsziffer empfangen wird. Chat-Zeilen werden in der Bezugsziffer-Reihenfolge angezeigt. Jedes Vertragspartner-Applet zeigt die Zeilen in der gleichen Reihenfolge an, wie sie sie in der Reihenfolge anzeigen, mit der sie den Server erreichen. Mit Ausnahme der ersten Dialogzeile in einem neuen Dialog umfasst jede Dialogzeile die Bezugsziffer der Dialogzeile in dem Kontext, in dem sie geschrieben wurde (die Kontextreferenz). Dies ermöglicht dem Chat-Server, Überkreuzungen zu identifizieren.
Um die Bezugsziffer der Kontextdialogzeile aufzunehmen, zeichnet das Applet die Bezugsziffer der letzten sichtbaren Dialogzeile, die in der Liste der Nachrichten des Dialogfeldes ist, wann immer eine Nachricht an den Chat-Server gesendet wird.
Mit Bezug nun auf 22 wird der Schritt des Aufzeichnens der Bezugsziffer der letzten Dialogzeile, die sichtbar ist, bei 610 gezeigt, wobei das System kontinuierlich nach einem Tastendruck oder einer anderen Angabe des Anfangs einer neuen Dialogzeile bei 600 prüft.
Wenn keine Textzeilen zu der empfangenen Nachrichtenliste, in der Zeit, zwischen der der Händler begann, eine neue Textzeile einzugeben, und der Zeit, wenn der Händler versucht, die neue Textzeile zu dem Server zu senden, hinzugefügt werden, wird die neue Textzeile normal gesendet. Wie oben erwähnt, kann ein „Sende"-Befehl auf mehrere Arten angewiesen werden. Die Informationen, die gesendet werden, umfassen als ihre Kontextreferenz die Referenzziffer, die bei Schritt 610 erfasst wird, wenn die Eingabe begann. In 22 wird die Entscheidung, ob eine Zeile zu senden ist, d.h., ob es irgendwelche zusätzlichen Textzeilen in der empfangenen Nachrichtenliste gibt, bei Schritt 630 getroffen, nachdem ein Sende-Befehl bei Schritt 620 erfasst wurde, und die Textzeile wird als Schritt 640 gesendet.
Wenn die Antwort auf die Frage bei Schritt 630 ja ist, d.h., dass die neuen Textzeilen zu der Nachrichtenliste hinzugefügt werden, nachdem der Händler beginnt, seine Dialogzeile einzugeben, werden die dazwischen tretende Zeile oder Zeilen hervorgehoben, wie es in 15 gezeigt ist. Hier hat der Händler begonnen, eine Zeile 800 in das Texteingabefeld 700 beginnend mit dem Wort „kann" einzugeben, bevor die Zeile 802, die mit „können wir irgendetwas tun ..." beginnt, von dem Händler wim@ABNA empfangen wird. Die Hervorhebung wird mittels einer Dialogzeilen-Dazwischentreten-Warnung durchgeführt. Diese Warnung kann beispielsweise einen rosafarbenen Hintergrund zu der Nachrichtenzelle aller dazwischen tretenden Zeilen hinzufügen.
Wenn die Dialogzeilen-Dazwischentreten-Warnung in Kraft ist, wenn der Händler versucht, die Dialogzeile an den Server zu senden, wird die Dialogzeile nicht gesendet, und eine Sende-Unterbrechungs-Warnung wird an das Texteingabefeld eingelegt. Dies wird in 16 gezeigt, die das Texteingabefeld mit einem rosafarbenen Hintergrund zeigt. Dieser Hintergrund wird sich rosa färben, wenn der Händler die Sendetaste betätigt, die ihm die Tatsache nahe bringt, dass die Dialogzeilen-Dazwischentreten-Warnung in Kraft ist und von ihm verlangt zu prüfen, dass die Zeile, die er versucht zu senden 800, immer noch in dem Kontext der zuletzt empfangenen Zeile 802 anwendbar ist.
Beide beschriebenen Warnungen können von einer beliebigen Farbe sein und können einen Audio-Indikator, wie beispielsweise einen eindeutigen distinkten Ton, umfassen oder lediglich daraus bestehen. Der Händler kann distinkte Audio-Warnungen für ankommende und abgehende Nachrichtenmelder verwenden. Typischerweise können die Audio-Indikatoren von Händlern gesperrt werden.
17 zeigt die Situation, bei der die „Sende-Unterbrechungs-Warnung" in Kraft ist (d.h. der Händler wurde bereits benachrichtigt, dass mehr Nachrichtenzeilen empfangen wurden, seitdem der Händler begann, die neue Textzeile einzugeben), und der Händler versucht, die neue Dialogzeile zu senden 800, und mehr Zeilen wurden seit dem letzten Versuch, sie an den Server zu senden, hinzugefügt. In diesem Fall wird die Dialogzeile nicht gesendet, und es wird damit fortgefahren, die Sende-Unterbrechungs-Warnung auf das Texteingabefeld 800 anzuwenden. Die Dialogzeilen-Dazwischentreten-Warnung wird nur auf diejenigen Zeilen angewendet, die seit dem letzten Sendeversuch hinzugefügt wurden. Somit wird in 17 der zweite Versuch des Händlers, eine Zeile 800 zu senden, von der Zeile unterbrochen, die mit „irgendetwas tun ..." Zeile 804 beginnt.
18 zeigt die Situation, bei der keine zusätzlichen Dialogzeilen zwischen dem letzten Sendebefehl und dem vorherigen Versuch, die Zeile an den Server zu senden, hinzugefügt wurden. Die neue Textzeile 800 wird dann normal gesendet und umfasst als ihre Kontextreferenz die Referenz der letzten Zeile, die in der Nachrichtenliste sichtbar ist. In 18 wurde die Zeile „Kann ich Sie später anrufen" 806 gesendet, und wird die Referenz der Zeile 804 „irgendetwas nach der Arbeit tun" als ihre Kontextreferenz aufweisen. Wenn die Zeile gesendet wird, wird das Texteingabefeld 700 gelöscht und auf seine gewöhnliche Hintergrundfarbe, beispielsweise Cyan, eingestellt.
Wenn der Händler eine Sende-Unterbrechungs-Warnung empfängt, kann er wünschen, den Text der Nachricht zu modifizieren, der in dem Texteingabefeld 700 ist. Wenn der Text modifiziert wird, wird die Dialogzeilen-Dazwischentreten-Warnung gelöscht, und das System zeichnet die Bezugsziffer der letzten sichtbaren Dialogzeile in der Nachrichtenliste auf. Nachdem der Händler beginnt, den Text zu modifizieren, fährt der visuelle Indikator von der Sende-Unterbrechungs-Warnung (die Änderung in der Hintergrundfarbe) fort, um dem Händler bekannt zu geben, dass eine Sende-Unterbrechung stattgefunden hat. Das Verfahren fährt dann fort, als ob eine neue Textzeile von dem Händler eingegeben wurde.
Obwohl ein sauberes Senden erreicht wurde, ist es für den Server möglich, die gesendete Dialogzeile zu empfangen, nachdem er eine neue Zeile von dem Vertragspartner empfangen hat, jedoch bevor diese neue Zeile zu dem Händler gesendet wurde. In dieser Situation teilt der Server Bezugsziffern zu den Zeilen in strenger chronologischer Reihenfolge zu.
Erfasste Überkreuzungen werden dem Händler mittels einer zusätzlichen Spalte in dem Chat-Feld angezeigt. Mit Bezug auf 19, wird, obwohl das Merkmal ebenfalls in jeder der 15 bis 19 gezeigt ist, eine durch ein Sternchen-Ikon angegebene zusätzliche Spalte 808 zwischen der Befestigungs(Büroklammer-Ikon)Spalte 810 und der Nachrichtenspalte 812 angeordnet.
Ein Sternchen erscheint in dieser Spalte, wo der Chat-Server oder die Händler-Workstation eine Überkreuzung erfasst hat, d.h., das Überkreuzungs-Ikon gibt eine Dialogzeile an, deren Kontextreferenz nicht mit der Bezugsziffer der Dialogzeile übereinstimmt, die ihr direkt in der Nachrichtenliste vorangeht.
Die Kontextspalte 808 kann von dem Händler verwendet werden, um den tatsächlichen Kontext anzuzeigen, der für eine gesendete Dialogzeile aufgezeichnet wurde. Diese Anzeige wird durch Auswählen von „Zeige-Kontext" aus dem Pop-Up-Menü des Dialogfeldes erreicht, obwohl auf sie in jeder anderen zweckmäßigen Art und Weise zugegriffen werden könnte. Beispielsweise kann der Benutzer wählen, den Kontext für jede neue Dialogzeile in der Nachrichtenliste automatisch anzuzeigen, die eine Überkreuzung aufweist. Wenn aufgerufen, werden Ikone, die den tatsächlichen Kontext der Zeile angeben, in der Überkreuzungsspalte 808 angezeigt. Dies wird in 20 gezeigt, bei der die Ikone in der Überkreuzungsspalte angeben, dass der Kontext für die Zeile 816 nicht die Zeile 814 sondern tatsächlich die Zeile 812 ist.
Die verschiedenen Ikone, die zusammen mit dem Überkreuzungsstatus und den Beschreibungen verwendet werden können, werden in der nachstehenden Tabelle 1 gezeigt. Diese Liste ist offensichtlich nicht erschöpfend und andere Symbole können verwendet werden.
Für das bei dem Chat-Server 20 (2) gespeicherte Chat-Archiv stellt 23 schematisch den Aufbau eines Chat-Archivs dar. Das Archiv ist tatsächlich eine große Datenbank, die Einzelheiten aller Chat-Zeile enthält, die an den Server gesendet wurden. Die Datenbank umfasst Spalten, die die Zeit 900, den Sender 910, die Nachricht 920, die Bezugsziffer 930, die Kontextreferenz 940 und die Überkreuzung 950 identifizieren.
Die „Sende-Unterbrechungs"-Warnungen werden in dem Dialog protokolliert und sind von dem Chat-Archiv sichtbar. Diese protokollierten Zeilen werden nicht an den Vertragspartner gesendet und werden in der Form „Sende Unterbrechung mit Kontextreferenz nnn", wobei „nnn" die Kontextreferenz ist, auf der sich die Warnung stützt, gesendet.
Wie es oben beschrieben ist, werden verschiedene Nachrichten zwischen dem Chat-Server- und den Händler-Workstation-Applets gesendet. Bezugsziffern werden an diese Nachrichten angehängt. Somit wird, wann immer ein Applet eine Chat-Nachricht an einen Chat-Server sendet, eine Sende-Chat-Nachricht gesendet. Diese umfasst ein Feld für die Bezugsziffer der letzten, auf dem Bildschirm angezeigten Zeile, seit das Applet begann, eine neue Nachricht zu verfolgen, d.h., wenn ein Tastendruck oder ein Startbefehl einer anderen neuen Nachricht von dem Applet erfasst wurde.
Wenn der Chat-Server 20 eine Sende-Chat-Nachricht empfängt, bestätigt er sie mit einer SendChatAck-Nachricht. Diese Nachricht umfasst die Bezugsziffer der neuen Chat-Zeile, die von dem Applet gesendet wurde. Der Chat-Server sendet Chat-Nachrichten, die in einer SendChat-Nachricht empfangen wurden, an das Ziel-Applet in einer ReceivedChat-Nachricht. Diese Nachricht umfasst ein Feld, die die Bezugsziffer der Chat-Zeile aufweist.
Es ist aus der obigen Beschreibung offensichtlich, dass die Ausführungsform den Vorteil aufweist, im Stande zu sein, sowohl Dialogzeilen, die ankommen, nachdem ein Händler die Eingabe beginnt, als auch Überkreuzungen zu handhaben. Indem dies getan wird, überwindet sie die in der Einführung erläuterten Nachteile und verbessert so den Wert und die Nützlichkeit von Chatgestützten Duplex-Systemen.
Viele Modifikationen zu der beschriebenen Ausführungsform sind ohne Abweichen von dem Schutzumfang der Erfindung möglich und werden Fachleuten offensichtlich sein. Obwohl die Beschreibung in Bezug auf das Handeln von Finanzinstrumenten gegeben wurde, ist es beispielsweise auf jedes Handelssystem anwendbar, egal, was gehandelt wird. Sie ist ebenfalls nicht auf Handelssysteme begrenzt, sondern auf jedes System anwendbar, bei dem ein genauer Duplex-Chat gewünscht ist, um Nachrichten zwischen Partnern auszutauschen, wobei Nachrichten sehr häufig gesendet werden.
Der Schutzumfang der Erfindung ist nicht auf irgendeine besondere Implementierung, wie beispielsweise die Bereitstellung einer Händlerfunktionalität durch Applets in einem Internet-gestützten System, begrenzt, sondern ist auf jedes computerisiertes System, das einen Zwischen-Chat-Server beinhaltet, egal wie es implementiert ist, anwendbar.
Tabelle 1
Zusammenfassung
In einem Duplex-Chat-Dialogorientiertem Handelssystem werden Händlerterminals zur Überwachung von neu eingehenden Nachrichten eingesetzt, von dem Zeitpunkt an, an dem ein Händler eine neue Nachricht eingibt bis zu dem Zeitpunkt ihres Sendens. Wenn eine eingehende Nachricht erfasst wird, wird das Senden der Nachricht unterdrückt und der Händler auf eine neu eingehende Nachricht hingewiesen, woraufhin er seine Nachricht bestätigen, modifizieren oder neu senden kann. Nachrichten werden über einen Chat-Server ausgetauscht, welcher jeder Nachricht eine eindeutige Referenznummer zuweist. Wenn eine am Server empfangene Nachricht in Beantwortung auf eine vorhergehende Nachricht gesendet wird, trägt sie die Referenz der vorhergehenden Nachricht. Der Server vergleicht diese Referenz mit der aktuellen Referenz, die er protokolliert hat und benachrichtig die Partner über eine Überkreuzung, falls die Referenzen nicht die gleichen sind.

Claims

Verfahren zum Senden von Nachrichten in einem Duplex-Nachrichtensystem, wobei das Verfahren umfasst: Erfassen des Beginnens der Eingabe einer neuen Nachricht an einer ersten Nachrichtenstation; während die neue Nachricht eingegeben und bis die neue Nachricht gesendet wird, Überwachen nach einer ankommenden Nachricht von einer zweiten Nachrichtenstation; und wenn die ankommende Nachricht während des Überwachen erfasst wird, Warnen eines Benutzers der ersten Nachrichtenstation vor der ankommenden Nachricht.
Verfahren gemäß Anspruch 1, bei dem die erste Nachrichtenstation eine Anzeige und der Schritt des Warnens ein Anzeigen einer Warnung auf der Anzeige umfasst.
Verfahren gemäß Anspruch 2, bei dem das Anzeigen der Warnung ein Hervorheben einer Darstellung der ankommenden Nachricht auf der Anzeige umfasst.
Verfahren gemäß Anspruch 1, ferner mit einem Fragen des Benutzers, nach Warnung des Benutzers der ersten Nachrichtenstation, ob der Benutzer wünscht, mit dem Senden der neuen Nachricht fortzufahren.
Verfahren gemäß Anspruch 1, bei dem ein Nachrichten-Server zwischen den ersten und zweiten Nachrichtenstationen angeordnet ist, und das Verfahren ferner ein Zuweisen einer Referenz zu jeder Nachricht durch den Nachrichten-Server umfasst.
Verfahren gemäß Anspruch 1, ferner mit den Schritten eines Einrichtens eines Dialogs zwischen der ersten und zweiten Nachrichtenstation vor dem Schritt des Überwachens.
Verfahren gemäß Anspruch 5, bei dem die zwischen den ersten und zweiten Nachrichtenstationen gesendeten Nachrichten über den Nachrichten-Server gesendet werden, und bei Empfang einer empfangenen Nachricht durch den Nachrichten-Server von einer bestimmten Nachrichtenstation, das Verfahren ferner ein Zurückgeben einer Bestätigung an die bestimmte Nachrichtenstation von dem Nachrichten-Server umfasst, wobei die Bestätigung die Referenz der empfangenen Nachricht aufweist.
Verfahren gemäß Anspruch 5, bei dem jede Referenz eindeutig ist.
Verfahren gemäß Anspruch 5, ferner mit einem Protokollieren empfangener Nachrichten mit jeweiligen Referenzen an dem Nachrichten-Server.
Verfahren gemäß Anspruch 9, bei dem der Nachrichten-Server ferner folgende Schritte durchführt: Vergleichen der Referenz einer bestimmten empfangenen Nachricht mit der Referenz der letzten protokollierten Nachricht; und falls die Referenz der bestimmten empfangenen Nachricht und der letzten protokollierten Nachricht nicht im Wesentlichen identisch sind, Markieren der bestimmten empfangenen Nachricht als Überkreuzung.
Verfahren gemäß Anspruch 10, ferner mit dem Anzeigen einer Angabe, dass eine Überkreuzung an einer oder beiden der ersten und zweiten Nachrichtenstationen erfasst wurde.
Verfahren gemäß Anspruch 11, bei dem die Angabe einen Kontext der Überkreuzung umfasst.
Verfahren zum Senden von Nachrichten in einem Duplex-Nachrichtensystem, bei dem Nachrichten zwischen einer ersten Nachrichtenstation und einer zweiten Nachrichtenstation über einen Nachrichten-Server gesendet werden, wobei das Verfahren folgende Schritte umfasst: Empfangen einer ersten Nachricht an einem Server; Zuweisen einer ersten Referenz zu der ersten Nachricht; Protokollieren der ersten Nachricht und der ersten Referenz in einem Protokoll; Empfangen einer zweiten Nachricht an den Server nach der ersten Nachricht, wobei die zweite Nachricht eine zweite Referenz zu einer vorhergehenden Nachricht umfasst; Protokollieren der zweiten Nachricht und der zweiten Referenz an dem Server; Vergleichen der zweiten Referenz mit der Referenz in dem Protokoll, der der zweiten Nachricht direkt vorausgeht; und Angeben, dass es eine Nachrichtenüberkreuzung gegeben hat, wenn die zweite Referenz und die in dem Protokoll direkt vorgehende Referenz nicht im Wesentlichen übereinstimmen.
Verfahren gemäß Anspruch 13, bei dem die Angabe ein Senden einer Angabe an eine oder beide der ersten und zweiten Nachrichtenstationen umfasst.
Verfahren gemäß Anspruch 14, bei dem die Angabe ein Ikon umfasst.
Verfahren gemäß Anspruch 14, bei dem die Angabe den Kontext der Überkreuzung zeigt.
Verfahren gemäß Anspruch 13, bei dem jede Referenz eindeutig ist.
Verfahren gemäß Anspruch 13, bei dem bei Empfang mindestens eine der ersten und zweiten Nachrichten von einer der ersten und zweiten Nachrichtenstationen, der Server die mindestens eine der ersten und zweiten Nachrichten und die jeweilige Referenz an die andere der ersten und zweiten Nachrichtenstationen weiterleitet.
Verfahren gemäß Anspruch 18, ferner mit einem Bestätigen des Empfangs mindestens einer der ersten und zweiten Nachrichten, wobei das Bestätigen die jeweilige Referenz umfasst.
Verfahren eines dialogorientierten Geschäfts, bei dem ein erster und zweiter Händler Geschäfte von Instrumenten durch Austausch von Nachrichten zwischen Händler-Workstations in einer Duplex-Nachrichtenumgebung aushandeln, wobei das Verfahren folgende Schritte umfasst: Erfassen bei einer ersten Händler-Workstation des Beginns der Eingabe einer neuen Nachricht durch einen ersten Händler, die sich auf einen Dialog zwischen dem ersten Händler und einem zweiten Händler bezieht; Überwachen einer ankommenden Nachricht an der ersten Händler-Workstation, die sich auf den Dialog bezieht und die zwischen dem erfassten Beginn der Eingabe der neuen Nachricht und einem Versuch empfangen wurde, die neue Nachricht von der ersten Händler-Workstation an eine zweite Händler-Workstation zu senden; bei Erfassung der ankommenden Nachricht Warnen des ersten Händlers vor der ankommenden Nachricht; und Unterbrechen eines Sendens der neuen Nachricht.
Verfahren gemäß Anspruch 20, bei dem der Schritt des Warnens ein Hervorheben einer Darstellung der ankommenden Nachricht auf einer ersten Händler-Workstation-Anzeige umfasst.
Verfahren gemäß Anspruch 20, bei dem das Unterbrechen ein Ermöglichen des ersten Händlers, die neue Nachricht zu senden, zu modifizieren und zu senden, oder zu löschen umfasst.
Verfahren gemäß Anspruch 22 mit: Überwachen nach ankommenden Nachrichten zwischen einem ersten Versuch, die neue Nachricht zu senden, und einem nachfolgenden Versuch, die neue Nachricht oder eine modifizierte oder frische Nachricht zu senden; und bei Erfassung einer neuer ankommenden Nachricht, Unterbrechen des nachfolgenden Versuchs.
Verfahren gemäß Anspruch 20, bei dem Nachrichten zwischen den Händler-Workstations über einen Nachrichten-Server gesendet werden, und das Verfahren ferner umfasst: bei Empfang jeder Nachricht an dem Server, Zuweisen einer jeweiligen Referenz zu einer jeweiligen Nachricht; Speichern von an dem Server empfangener Nachrichten mit entsprechenden Referenzen; Vergleichen der Referenz einer an dem Server empfangenen bestimmten Nachricht mit der zuletzt an dem Server gespeicherten Referenz; und wenn die verglichenen Referenzen nicht die Gleichen sind, benachrichtigen eines oder beider Händler über eine Nachrichtenüberkreuzung.
Verfahren gemäß Anspruch 23, bei dem das Benachrichtigen ein Anzeigen eines Ikon umfasst.
Verfahren gemäß Anspruch 24, bei dem jede Workstation eine Liste gesendeter und empfangener Nachrichten anzeigt, und das Ikon eine Überkreuzungsnachricht identifiziert, für die eine Überkreuzung erfasst wurde.
Verfahren gemäß Anspruch 25, bei dem Ikon eine Angabe des Überkreuzungs-Kontexts umfasst.
Verfahren für dialogorientierte Geschäfte, bei dem Händler Geschäfte von Instrumenten durch Austausch von Nachrichten zwischen Händler-Workstations in einer Duplex-Nachrichtenumgebung aushandeln, wobei das Verfahren folgende Schritte umfasst: bei einer ersten Händler-Workstation, Erfassen des Beginnens einer Eingabe einer neuen Nachricht, die sich auf einen laufenden Dialog zwischen der ersten Händler-Workstation und einer zweiten Händler-Workstation bezieht; Überwachen nach einer ankommenden Nachricht an einer ersten Händler-Workstation, die sich auf den Dialog bezieht, bei der Erfassung des Beginnens des Eingebens der neuen Nachricht; und bei Erfassung der ankommenden Nachricht, Benachrichtigen des ersten Händlers über die ankommende Nachricht vor dem Senden der neuen Nachricht.
Verfahren eines dialogorientierten Geschäfts, bei dem Händler Geschäfte von Instrumenten durch Austauschen von Nachrichten zwischen jeweiligen Händler-Workstations über einen Nachrichten-Server in einer Duplex-Nachrichtenumgebung aushandeln, wobei das Verfahren umfasst: an dem Nachrichten-Server: bei Empfang einer ersten Nachrichten von einer ersten Workstation, Zuweisen einer ersten Referenz zu der ersten Nachricht; Protokollieren der ersten Nachricht mit der ersten Referenz in einem Protokoll; Weiterleiten der ersten Nachricht an eine bestimmte Empfangs-Workstation zusammen mit der ersten Referenz; Bestätigen der ersten Nachricht an der ersten Workstation zusammen mit der ersten Referenz; und bei Empfang einer zweiten Nachricht, die eine zweite Referenz von einer zweiten Workstation aufweist, Vergleichen der zweiten Referenz mit der Referenz in dem Protokoll, die der zweiten Referenz direkt vorangeht, und wenn die zweite Referenz und die der zweiten Referenz direkt vorangehende Referenz in dem Protokoll nicht die Gleichen sind, Benachrichtigen der zweiten Workstation über eine Überkreuzung; und bei einer bestimmten Workstation: bei Erfassung des Beginnens einer Eingabe einer neuen Nachricht durch einen bestimmten Händler, die von der bestimmten Workstation an eine Vertragspartner-Workstation zu senden ist, Überwachen nach einer ankommenden Nachricht an der bestimmten Workstation, während die neue Nachricht eingegeben wird; und bei Erfassung der ankommenden Nachricht, Warnen des bestimmten Händlers vor der ankommenden Nachricht.
Verfahren für ein dialogorientiertes Geschäft, bei dem Händler Geschäfte von Instrumenten durch Austausch von Nachrichten zwischen Händler-Workstations in einer Duplex-Nachrichtenumgebung aushandeln, und bei dem Nachrichten über einen Nachrichter-Server ausgetauscht werden, der Nachrichten bei Empfang protokolliert und eine empfangene Nachricht einem sendenden Partner bestätigt, der die empfangene Nachricht gesendet hat, wobei das Verfahren folgende Schritte umfasst: Empfangen einer ersten Nachricht von einer ersten Nachrichtenstation; Zuweisen einer ersten Referenz zu der ersten Nachricht; Protokollieren der ersten Nachricht und der ersten Referenz in einem Protokoll; Empfangen einer zweiten Nachricht von einer zweiten Nachrichtenstation an den Server nach der ersten Nachricht, wobei die zweite Nachricht eine zweite Referenz auf eine vorhergehende Nachricht umfasst; Protokollieren der zweiten Nachricht und der zweiten Referenz an den Server; Vergleichen der zweiten Referenz mit der Referenz in dem Protokoll, das der zweiten Nachricht direkt vorangeht; und Benachrichtigen einer oder beider der ersten und zweiten Nachrichtenstationen, dass es eine Nachrichtenüberkreuzung gegeben hat, wenn die zweite Referenz und die direkt vorangehende Referenz in dem Protokoll nicht im Wesentlichen übereinstimmen.
Verfahren gemäß Anspruch 28, bei dem das Benachrichtigen ein Anzeigen eines Ikons an einer der Nachrichtenstationen umfasst.
Verfahren gemäß Anspruch 31, bei dem das Ikon eine Angabe des Kontexts der Überkreuzung umfasst.
Verfahren gemäß Anspruch 30, bei dem jede Referenz eindeutig ist.
Verfahren gemäß Anspruch 30, bei dem das Warnen mindestens eine Audioangabe oder ein Hervorheben einer Darstellung eines ankommenden Bildes umfasst.
Duplex-Nachrichtensystem mit einer Mehrzahl von Nachrichtenstationen zum Austauschen von dialogorientierten Nachrichten, wobei jede der Nachrichtenstationen umfasst: ein Mittel zum Erfassen des Beginnens einer Eingabe einer neuen Nachricht, die sich auf einen existierenden Dialog mit einem Vertragspartner in dem Nachrichtensystem bezieht; ein Überwachungsmittel zum Überwachen nach einer ankommenden Nachricht von dem Vertragspartner, während die neue Nachricht eingegeben wird; und ein Warnungsmittel zum Warnen eines Benutzers vor der von den Überwachungsmitteln erfassten Nachricht.
System gemäß Anspruch 35, bei dem jede Nachrichtenstation ferner eine Anzeige und ein Mittel zum Anzeigen einer von dem Warnungsmittel erzeugten Warnung umfasst.
System gemäß Anspruch 36, bei dem das Warnungsmittel erfasste ankommende Nachrichten auf der Anzeige hervorhebt.
System gemäß Anspruch 35, bei dem zumindest einige der Nachrichtenstationen eine Tastatur zur Eingabe von Nachrichten und das Erfassungsmittel ein Mittel zum Erfassen eines Tastendrucks von der Tastatur umfasst.
System gemäß Anspruch 35, bei dem: jede Workstation ein Mittel zum Senden einer abgeschlossenen Nachricht umfasst; wobei das Warnungsmittel ein Mittel zum Hindern des Mittels am Senden umfasst, wenn die ankommende Nachricht erfasst wurde; und das Mittel zum Senden ein Mittel zum Bestätigen, Verbessern oder Löschen der neuen Nachricht als Antwort auf eine Warnung von dem Warnungsmittel umfasst.
System gemäß Anspruch 39, bei dem: das Überwachungsmittel ferner nach einer zusätzlichen ankommenden Nachricht überwacht, die nach der Erzeugung einer Warnung durch das Warnungsmittel und vor einem Versuch, eine verbesserte Nachricht durch das Mittel zum Senden zu senden, überwacht; und wobei das Warnungsmittel eine weitere Warnung erzeugt und das Mittel am Senden der verbesserten Nachricht bei Erfassung der zusätzlichen ankommenden Nachricht hindert.
System gemäß Anspruch 35, ferner mit: einem Nachrichten-Server zum Empfangen von von den Sender-Workstations gesendeter Nachrichten und zum Weiterleiten der ankommenden Nachrichten an bestimmte Ziel-Workstations, wobei der Server umfasst: ein Nachrichtenprotokoll zum Protokollieren der ankommenden Nachrichten; und ein Mittel zum Zuweisen einer jeweiligen Referenz zu jeder ankommenden Nachricht; wobei das Nachrichtenprotokoll die jeweilige zugewiesene Referenz mit einer jeweiligen Nachricht protokolliert.
System gemäß Anspruch 41, bei dem der Server ein Mittel zum Benachrichtigen eines bestimmten Partners umfasst, der eine bestimmte Nachricht der jeweiligen Referenz sendet, die der bestimmten Nachricht zugeordnet ist.
System gemäß Anspruch 41, bei dem der Server ein Mittel zum Benachrichtigen eines bestimmten Partners umfasst, der eine bestimmte Nachricht der Referenz empfängt, die der bestimmten Nachricht zugewiesen wurde.
System gemäß Anspruch 43, bei dem: der Server eine Antwort auf eine Auswahlnachricht mit einer jeweiligen Referenz auf die Auswahlnachricht empfängt; der Server ein Mittel zum Vergleichen der jeweiligen Referenz der Auswahlnachricht mit der Referenz der zuletzt protokollierten Nachricht umfasst; und der Server ein Mittel zum Benachrichtigen einer oder beider Sender der Auswahlnachricht und des bestimmten Empfängers der Auswahlnachricht über eine Überkreuzung umfasst, wenn die jeweilige Referenz der Auswahlnachricht und die Referenz der zuletzt protokollierten Nachricht nicht im Wesentlichen die Gleichen sind.
System gemäß Anspruch 44, bei dem jede der Nachrichtenstationen ein Mittel zum Anzeigen einer von dem Nachrichten-Server benachrichtigten Überkreuzung umfasst.
System gemäß Anspruch 45, bei dem das Anzeigemittel ein Ikon umfasst.
System gemäß Anspruch 46, bei dem das Ikon eine Angabe des Kontexts der Überkreuzung umfasst.
System gemäß Anspruch 41, bei dem jede durch den Nachrichten-Server zugewiesene Referenz eindeutig ist.
Duplex-Nachrichtensystem mit einer Mehrzahl von Nachrichtenstationen zum Austauschen von dialogorientierten Nachrichten, wobei eine bestimmte Nachrichtenstation umfasst: einen Detektor, der das Beginnen der Eingabe einer neuen Nachricht in die bestimmte Nachrichtenstation erfasst; einen Monitor, der nach einer ankommenden Nachricht an der bestimmten Nachrichtenstation von anderen der Mehrzahl von Nachrichtenstationen überwacht, während die neue Nachricht eingegeben wird; und einen Warnungsgenerator, der eine Warnung erzeugt, um den Benutzer der bestimmten Nachrichtenstation vor der ankommenden Nachricht zu warnen, wobei die ankommende Nachricht von einer anderen Nachrichtenstation in einem Dialog mit der bestimmten Nachrichtenstation herrührt und an der bestimmten Nachrichtenstation vor einem Versuch empfangen wird, die neue Nachricht dem Benutzer zu senden.
Duplex-Nachrichtensystem gemäß Anspruch 49, bei dem das System ferner einen Nachrichten-Server umfasst, der zwischen den Nachrichtenstationen angeordnet ist, der ankommenden Nachrichten empfängt und an bestimmte Ziele weiterleitet, wobei der Nachrichten-Server umfasst: einen Referenzgenerator, der eine jeweilige Referenz einer ankommende Nachricht von einer Sendernachrichtenstation zuweist; ein Nachrichtenprotokoll, das die ankommende Nachricht mit der jeweiligen zugewiesenen Referenz protokolliert; einen Nachrichtenbestätiger, der die empfangene ankommende Nachricht bestätigt und eine jeweilige zugewiesene Referenz an die Sendernachrichtenstation zurückgibt; einen Nachrichtenweiterleiter, der die empfangene ankommende Nachricht an ein bestimmtes Ziel zusammen mit der jeweiligen zugewiesenen Referenz weiterleitet; einen Komparator, der eine Referenz der ankommenden Nachricht mit der zuletzt an dem Server protokollierten Referenz vergleicht; und einen Überkreuzungs-Benachrichtigen, der einen oder beide Sender und Empfänger der ankommenden Nachricht über eine Überkreuzung benachrichtigt, wenn die von dem Komparator verglichenen Referenzen nicht im Wesentlichen die Gleichen sind.
Duplex-Nachrichtensystem mit: einer Mehrzahl von Nachrichtenstationen, die dialogorientierte Nachrichten austauschen; und einem Nachrichten-Server, der zwischen den Nachrichtenstationen angeordnet ist, der Nachrichten von den sendenden Stationen empfängt und die Nachrichten an bestimmte Stationen weiterleiten, wobei der Nachrichten-Server umfasst: einem Referenzgenerator, der eine jeweilige Referenz einer von einer sendenden Nachrichtenstation empfangenen Nachricht zuweist; einem Nachrichtenprotokoll, das die ankommende Nachricht mit der jeweiligen Referenz protokolliert; einem Nachrichtenbestätiger, der die ankommende Nachricht bestätigt und die jeweilige Referenz an die sendende Nachrichtenstation zurückgibt; einem Nachrichtenweiterleiter, der die ankommende Nachricht an eine bestimmte Zielstation zusammen mit der jeweiligen zugewiesenen Referenz weiterleitet; einem Komparator, der die Referenz der ankommenden Nachricht mit der zuletzt an dem Server protokollierten Referenz vergleicht; und einem Überkreuzungs-Benachrichtiger, der eine oder beide Sendernachrichtenstationen und die bestimmte Zielstation der ankommenden empfangenen Nachricht über eine Überkreuzung benachrichtigt, wenn die von dem Komparator verglichenen Referenzen nicht im Wesentlichen die Gleichen sind.
System gemäß Anspruch 51, bei dem jede der Nachrichtenstationen eine Anzeige umfasst, die eine Überkreuzungs-Benachrichtigung von dem Nachrichten-Server anzeigt.
System gemäß Anspruch 51, bei dem jede Nachrichtenstation einen Ikonen-Generator umfasst, der ein Überkreuzungs-Ikon zur Anzeige als Antwort auf eine Überkreuzungs-Benachrichtigung von dem Server erzeugt.
System gemäß Anspruch 53, bei dem das Ikon den Kontext der Überkreuzung angibt.
Duplex-Nachrichtensystem mit: einer Mehrzahl von Nachrichtenstationen, die dialogorientierte Nachrichten austauschen; und einem Nachrichten-Server, der zwischen den Nachrichtenstationen zum Empfangen von Nachrichten von sendenden Stationen und zum Weiterleiten der Nachrichten an bestimmte Ziele angeordnet ist, wobei der Nachrichten-Server umfasst: ein Mittel zum Erzeugen von Referenzen und zum Zuweisen einer jeweiligen eindeutigen Referenz an jede an dem Server empfangenen Nachricht; ein Mittel zum Protokollieren empfangener Nachrichten mit jeweiligen Referenzen; ein Mittel zum Bestätigen einer empfangenen Nachricht, die von einer Sendernachrichtenstation empfangen wurde, und zum Zurückgeben der jeweiligen zugewiesenen Referenz an die Sendernachrichtenstation; ein Mittel zum Weiterleiten der empfangenen Nachricht und jeweiliger Referenzen an ein bestimmtes Ziel; ein Mittel zum Vergleichen der Referenz der empfangenen Nachricht mit der zuletzt an dem Server protokollierten Referenz; und ein Mittel zum Benachrichtigen der Sendernachrichtenstation und des bestimmten Ziels der empfangenen Nachricht über eine Überkreuzung, wenn die von dem Vergleichsmittel verglichenen Referenzen nicht im Wesentlichen die Gleichen sind.
Dialogorientiertes Geschäftssystem zum Aushandeln von Geschäften zwischen Händlern durch Austausch von Nachrichten zwischen Händler-Workstations, die in einer Duplex-Nachrichtenumgebung arbeiten, wobei jede Händler-Workstation umfasst: ein Mittel zum Erfassen des Beginnens einer Eingabe einer neuen Nachricht in die Händler-Workstation; ein Überwachungsmittel zum Überwachen nach einer ankommenden Nachricht an der Händler-Workstation von einer anderen der Mehrzahl von Workstations, während die neue Nachricht eingegeben wird; und ein Warnungsmittel zum Warnen eines Händlers, der an der Händler-Workstation arbeitet, vor der von dem Überwachungsmittel erfassten ankommenden Nachricht, die von einer anderen der Mehrzahl von Workstations in einem Dialog mit der Händler-Workstation herrührt.
System gemäß Anspruch 56, bei dem jede Händler-Workstation eine Anzeige und ein Mittel zum Anzeigen einer von dem Warnungsmittel erzeugten Warnung umfasst.
System gemäß Anspruch 57, bei dem das Warnungsmittel eine Darstellung der erfassten ankommenden Nachricht auf der Anzeige hervorhebt.
System gemäß Anspruch 56, bei dem: jede Händler-Workstation eine Tastatur zur Eingabe von Nachrichten umfasst; und das Mittel zum Erfassen ein Mittel zum Erfassen eines Tastendrucks von der Tastatur umfasst, die das Beginnen der Eingabe der neuen Nachricht angibt.
System gemäß Anspruch 56, bei dem: jede Workstation ein Mittel zum Senden einer abgeschlossenen Nachricht umfasst; das Warnungsmittel ein Mittel zum Hindern des Mittels am Senden umfasst, wenn die ankommende Nachricht erfasst wurde; und das Sendemittel ein Mittel zum Bestätigen, Verbessern oder Löschen der neuen Nachricht als Antwort auf eine Warnung von dem Warnungsmittel umfasst.
System gemäß Anspruch 60, bei dem: das Überwachungsmittel ferner nach einer weiteren ankommenden Nachricht überwacht, die nach Erzeugung einer Warnung durch das Warnungsmittel und vor einem Versuch, eine verbesserte Nachricht durch das Sendemittel zu senden, empfangen wurde; und das Warnungsmittel eine weitere Warnung erzeugt und das Sendemittel am Senden der verbesserten Nachricht bei Erfassung der weiteren ankommenden Nachricht durch das Überwachungsmittel hindert.
System gemäß Anspruch 56, ferner mit: einem Nachrichten-Server zum Empfangen von von Sender-Workstations gesendeter Nachrichten und zum Weiterleiten der ankommenden Nachrichten an bestimmte Zielhändler-Workstations, wobei der Server umfasst: ein Nachrichtenprotokoll zum Protokollieren der ankommenden Nachrichten; und ein Mittel zum Zuweisen einer jeweiligen Referenz zu jeder ankommenden Nachricht; wobei das Nachrichtenprotokoll die jeweilige zugewiesene Referenz mit einer jeweiligen Nachricht protokolliert.
System gemäß Anspruch 62, bei dem der Server ein Mittel zum Benachrichtigen eines sendenden Partners umfasst, der eine bestimmte Nachricht der jeweiligen Referenz, die der bestimmten Nachricht zugewiesen wurde.
System gemäß Anspruch 62, bei dem der Server ein Mittel zum Benachrichtigen eines Partners umfasst, der eine bestimmte Nachricht der jeweiligen zugewiesenen Referenz empfängt, die der bestimmten Nachricht zugewiesen ist.
System gemäß Anspruch 62, bei dem: der Server eine Antwort auf eine Auswahlnachricht mit einer jeweiligen Referenz an der Auswahlnachricht empfängt; der Server ein Mittel zum Vergleichen der jeweiligen Referenz der Auswahlnachricht mit der Referenz der zuletzt protokollierten Nachricht umfasst; und der Server ein Mittel zum Benachrichtigen eines oder beider Sender der Auswahlnachricht und des bestimmten Empfängers der Auswahlnachricht einer Überkreuzung umfasst, wenn die jeweilige Referenz der Auswahlnachricht und die Referenz der zuletzt protokollierten Nachricht nicht im Wesentlichen die Gleichen sind.
System gemäß Anspruch 65, bei dem jede der Nachrichtenstationen ein Mittel zum Anzeigen einer von dem Nachrichten-Server benachrichtigten Überkreuzung umfasst.
System gemäß Anspruch 66, bei dem das Anzeigemittel ein Ikon umfasst.
System gemäß Anspruch 67, bei dem das Ikon eine Angabe des Kontexts der Überkreuzung umfasst.
System gemäß Anspruch 62, bei dem jede von dem Nachrichten-Server zugewiesene Referenz eindeutig ist.
Dialogorientiertes Geschäftssystem zum ausgehandelten Handeln von Geschäften von Instrumenten durch Händler mit: einer Mehrzahl von Händlerterminals, die dialogorientierte Nachrichten in einer Duplex-Nachrichtenumgebung austauschen; und einem Nachrichten-Server, der zwischen den Händlerterminals angeordnet ist, wobei der Nachrichten-Server Nachrichten von den Händlerterminals empfängt und die Nachrichten an bestimmte Empfangshändlerterminals sendet, wobei der Nachrichten-Server umfasst: einen Referenzgenerator, der eine jeweilige Referenz einer ankommenden Nachricht zuweist, die von einem Senderhändlerterminal empfangen wurde; ein Nachrichtenprotokoll, das die ankommende Nachricht mit einer jeweiligen zugewiesenen Referenz protokolliert; einen Nachrichtenbestätiger, der die ankommende Nachricht bestätigt und die jeweilige Referenz an das sendende Händlerterminal zurückgibt; einen Nachrichtenweiterleiter, der die ankommende Nachricht an ein bestimmtes Empfangshändlerterminal zusammen mit der jeweiligen zugewiesenen Referenz weiterleitet; einen Komparator, der die Referenz der ankommenden Nachricht mit der zuletzt an dem Server protokollierten Referenz vergleicht; und einen Überkreuzungs-Benachrichtigen, der einen oder beide Sender und den Empfänger der ankommenden Nachricht über eine Überkreuzung benachrichtigt, wenn die von dem Komparator verglichenen Referenzen nicht im Wesentlichen die Gleichen sind.
System gemäß Anspruch 70, bei dem jeder der Händlerterminals eine Anzeige umfasst, die eine von dem Nachrichten-Server empfangene Überkreuzungsbenachrichtigung anzeigt.
System gemäß Anspruch 70, bei dem die Händlerterminals einen Ikonen-Generator umfassen, der ein Überkreuzungs-Ikon als Antwort auf eine Überkreuzungsbenachrichtigung von dem Server erzeugt.
System gemäß Anspruch 72, bei dem das Ikon den Kontext der Überkreuzung angibt.
Dialogorientiertes Geschäftssystem für den ausgehandelten Handel von Instrumenten zwischen Händlern mit: einer Mehrzahl von Händlerterminals für den Austausch von dialogorientierten Nachrichten zwischen Händlern in einer Duplex-Nachrichtenumgebung; und einem Nachrichten-Server, der zwischen den Händlerterminals zum Empfangen von Nachrichten von sendenden Händlerterminals und zum Weiterleiten der Nachrichten an bestimmte Ziele angeordnet ist, wobei der Nachrichten-Server umfasst: ein Mittel zum Erzeugen einer Referenz und zum Zuweisen einer jeweiligen eindeutigen Referenz an einer ankommenden Nachricht, die an dem Server von einem Senderhändlerterminal empfangen wurde; ein Mittel zum Protokollieren der ankommenden Nachricht mit der jeweiligen Referenz; ein Mittel zum Bestätigen der ankommenden Nachricht und zum Zurückgeben der jeweiligen zugewiesenen Referenz an das Senderhändlerterminal; ein Mittel zum Weiterleiten der ankommenden Nachricht und der jeweiligen Referenz an ein bestimmtes Ziel-Terminal; ein Mittel zum Vergleichen der Referenz der ankommenden Nachricht mit der zuletzt an dem Server protokollierten Referenz; und ein Mittel zum Benachrichtigen zumindest des Senderhändlerterminals und/oder des bestimmten Ziel-Terminals über eine Überkreuzung, wenn die von dem Vergleichsmittel verglichenen Referenzen nicht im Wesentlichen die Gleichen sind.
Händlerterminal für ein dialogorientiertes Geschäftssystem, bei dem Geschäfte durch Austausch von dialogorientierten Nachrichten zwischen Händlerterminals in einer Duplex-Nachrichtenumgebung ausgehandelt werden, wobei das Händlerterminal umfasst: ein Mittel zum Erfassen des Beginnens einer Eingabe einer neuen Nachricht in das Händlerterminal; ein Überwachungsmittel zum Überwachen nach einer ankommenden dialogorientierten Nachricht an dem Händlerterminal, die nach Erfassung des Beginnens der Eingabe der neuen Nachricht empfangen wurde; und ein Warnungsmittel zum Warnen eines Händlers, der das Händlerterminal benutzt, vor der von dem Überwachungsmittel erfassten ankommenden Nachricht und das von einem Partner im Dialog mit dem Händlerterminal herrührt.
Händlerterminal gemäß Anspruch 75, ferner mit einer Anzeige zum Anzeigen von geschäftsbezogener Information und zum Anzeigen von von dem Warnungsmittel erzeugten Warnungen.
Händlerterminal gemäß Anspruch 76, bei dem das Warnungsmittel eine Darstellung der erfassten ankommenden Nachricht auf der Anzeige hervorhebt.
Händlerterminal gemäß Anspruch 75, ferner mit einer Tastatur zum Ermöglichen der Eingabe von Nachrichten in das Händlerterminal; und wobei das Erfassungsmittel einen Tastendruck von der Tastatur erfasst, der das Beginnen der Eingabe der neuen Nachricht angibt.
Händlerterminal gemäß Anspruch 75, ferner mit einem Mittel zum Senden einer abgeschlossenen Nachricht von dem Händlerterminal; und wobei das Warnungsmittel ein Mittel zum Hindern des Mittels am Senden umfasst, wenn die ankommende Nachricht erfasst wurde; und wobei das Mittel zum Senden ein Mittel zum Bestätigen, Verbessern oder Löschen der neuen Nachricht als Antwort auf eine Warnung von dem Warnungsmittel umfasst.
Händlerterminal gemäß Anspruch 79, bei dem das Überwachungsmittel ferner ein Mittel zum Überwachen nach einer weiteren ankommenden Nachricht umfasst, die nach Erzeugung einer Warnung durch das Warnungsmittel und vor einem Versuch, die neue Nachricht erneut zu senden, empfangen wurde, und wobei das Warnungsmittel ein Mittel zum Erzeugen einer weiteren Warnung bei Erfassung der zusätzlichen ankommenden Nachricht umfasst.
Händlerterminal für ein dialogorientiertes Geschäftssystem, bei dem Geschäfte durch Austausch von dialogorientierten Nachrichten zwischen Händlerterminals in einer Duplex-Nachrichtenumgebung ausgehandelt werden, wobei das Händlerterminal umfasst: einen Detektor zum Erfassen des Beginnens einer Eingabe einer neuen dialogorientierten Nachricht in das Händlerterminal; einen Monitor zum Überwachen nach einer ankommenden dialogorientierten Nachricht an dem Händlerterminal, die zwischen der Erfassung des Beginnens der neuen Nachricht und eines Versuchs, die neue Nachricht zu senden, empfangen wurde; und einen Warnungsgenerator zum Warnen eines Händlers, der das Händlerterminal benutzt, vor der von dem Monitor erfassten dialogorientierten Nachricht, die von einem Partner bei einem Dialog mit dem Händler herrührt.
Computerlesbares Speichermedium zum Speichern von Daten zum Durchführen folgender Schritte: Erfassen des Beginnens einer Eingabe einer neuen Nachricht durch einen Händler in ein erstes Händlerterminal; während die neue Nachricht eingegeben und bis die neue Nachricht gesendet wird, Überwachen nach einer ankommenden Nachricht von einem zweiten Händlerterminal; und wenn die ankommende Nachricht während des Überwachens erfasst wird, Warnen eines Benutzers des ersten Händlerterminals vor der ankommenden Nachricht.