-
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.
-
Duplex-Chat wird von E-Mail-Clients, beispielsweise dem 1997 erschienenen „OUTLOOK“ (https://de.wikipedia.org/w/index.php?title=Microsoft_Outlook&oldid=160638486 ; Bearbeitungsstand: 14. Dezember 2016, 09:26) der Firma Microsoft, verwendet. Ein Benutzer von „OUTLOOK“ kann Nachrichten erstellen und wird gleichzeitig über eingehende Nachrichten weiterer Benutzer informiert. Die Offenlegungsschrift
EP 1 067 741 A1 beschreibt ein Verfahren, gemäß dem ein Benutzer durch ein zweites Medium automatisch über den Empfang einer E-Mail benachrichtigt wird, auch wenn das E-Mail-System des Benutzers nicht mit dem Server seines Dienstanbieters verbunden ist.
-
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.
-
Figurenliste
-
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äftsystem 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 Kundenbenutzem, 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 Wamkä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 Pull-down-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äftsiriformationen 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 Instrument-spezifischen 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 Parser 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 Parser bei dem geschäftemachenden Verfahren keine Rolle und behält keine Kenntnis des Geschäfts. Der Parser 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 Parser 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 Intemet-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-Wamung 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-Wamung 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-Wamung 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-Wamungen 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-Wamung 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-Wamung 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-Wamung (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-lkon)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 Chat-gestü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 Intemet-gestützten System, begrenzt, sondern ist auf jedes computerisiertes System, das einen Zwischen-Chat-Server beinhaltet, egal wie es implementiert ist, anwendbar.
Tabelle 1
Ikon | „Überkreuzung“ vorhanden | Zeige Kontextstatus | Beschreibung |
| Nein | Nicht vorhanden | Reguläre Zeile (keine |
| | | „Überkreuzung“) |
| Ja | Nicht vorhanden | Zeile hat sich überkreuzt und: |
| | | * | zeigt nicht ihren Kontext |
| Ja | Start | Zeile hat sich überkreuzt und: |
| | | * | ist der Anfang einer |
| | | Kontextanzeige |
| Nein | Dazwischen tretend | Zeile hat sich nicht überkreuzt und: |
∥ | | | * | ist zwischen einer |
| | | überkreuzten Zeile, die ihren Kontext zeigt, und der übereinstimmenden Kontextzeile positioniert. |
| Ja | Dazwischen tretend | Zeile hat sich überkreuzt (wobei sie ihre Kontextzeile nicht zeigt) und: |
| | | * | ist zwischen einer |
| | | überkreuzten Zeile, die ihren Kontext zeigt, und der übereinstimmenden Kontextzeile positioniert. |
⮳ | Nein | Kontextzeile | Zeile hat sich nicht überkreuzt und: |
| | | * | ist die Kontextzeile für eine |
| | | überkreuzte Zeile, die ihren Kontext zeigt. |
| Ja | Kontextzeile | Zeile hat sich überkreuzt (wobei sie jedoch ihren Kontext nicht zeigt) und: |
| | | * | ist die Kontextzeile für eine |
| | | überkreuzte Zeile, die ihren Kontext zeigt. |