DE10296837T5 - Dialogue-oriented business system - Google Patents

Abstract

Dialog-oriented business system for trading instruments between contractual partners with:
a plurality of dealer terminals, each having a user interface for entering and displaying to a dealer of dialog-oriented messages with business-related information, the dealer terminals communicating with one another via a communication network, the dealer terminals each further comprising a parser for parsing the entered dialog-oriented messages, wherein the parser includes:
Means for analyzing the dialog-oriented messages to detect a state of a store, the store having a plurality of possible states;
Means for analyzing the dialog messages to collect business related information regarding the captured status of the business; and
Means for returning a parsed message comprising the business status and business related information to the user interface.

Description

CROSS REFERENCES TO RELATED REGISTRATIONS

This application claims priority over the U.S. Application No. 09/753,940, filed January 3, 2001, and the preliminary U.S. Application Serial No. 60/308,618, filed July 30, 2001. All of these applications are hereby incorporated by reference.

FIELD OF THE INVENTION

This invention relates to business systems and in particular to dialog-oriented business or trading systems that Trade instruments between partners. It particularly relates but not exclusively, on financial trading and business systems, that trade different financial papers. The invention relates especially on the parsing (text analysis / speech analysis) of dialog-oriented Messages entered into the system by traders.

BACKGROUND OF THE INVENTION

It has become commonplace, financial papers to deal with computer systems. To a large extent, these are open Call-back procedures replaced where dealers face to face on trading floors negotiated. Different computerized trading systems have changed for trading different instruments, such as Currency spot (FX spot), interest rate futures (FRAs) and other instruments developed. Some systems are anonymous in that the Contractual partners (counterparties) to a trade the identity of others Do not know contractors in the market until a deal has been made. Successful anonymous trading systems have been around for a number of years EBS Dealing Resources, Inc., and operated by Reuters plc. The the latter company also has a dialog-oriented one known as Reuters 2000 / l business system operated, the dialogue-oriented exchange between dealers at the Reaching a deal computerized, being a business negotiation between traders allows becomes.

Existing business systems tended to be dealers to assist in trading a single instrument. at huge Institutions where a given dealer has only one instrument does not cause any difficulties. At smaller institutions however, can be a forex trader for example different types of instruments for one or multiple currency pairs act. It is for such a dealer inappropriate, several different trading systems or a mixture of computerized systems and conventional Use trading techniques such as voice brokers to have to.

There is therefore a need for a system that trades a number of instruments on one integrated platform to trade in particular for traders in to simplify smaller institutions.

Financial markets, such as foreign exchange markets, can use extreme speed work. Dealers are required to market activity respond almost immediately to avoid losing potential business. As a result, the dealer terminal be visually very simple and it must be easy for the dealer, new or changing To record information. The ability, a number of different instruments from a single terminal to act carries to the complexity at and can cause that the dealer presented more information becomes.

At any time, a dealer can many shops involved, with some of them maturing into finished businesses and others canceled at a stage before settlement for (invalid explained) become. This business can affect a variety of instruments. Each of these stores will Have instrument-specific information that the dealer can see must to enable him to do the business. The However, displaying all of this information on the screen results to it for the dealer is difficult to interpret the screen visually and is therefore not desirable.

Reuters plc operates a dialog-oriented one business system under the trade name REUTERS DEALING 2000 / l. In this system type dealer Enter a dialog text in the terminals relating to businesses that execute them want. The dialog text can possibly no business related Have content or possibly Information regarding the business contain. The system directs the dialog as it is entered into the system will continue on a character-by-character basis. When a deal is done partners are asked to confirm the deal and can review the terms and conditions renegotiate.

Although the Reuters 2000 / l system has been operating successfully for a number of years, we have noticed that the parsing approach has a number of disadvantages. The The present invention in its various aspects is directed to overcoming these disadvantages and providing improved parsing in a dialog-oriented business system, thereby improving the utility and acceptance of such a system for retailers and institutions.

SUMMARY THE INVENTION

A first aspect of the invention lies using parsing to capture terms in the dialog, the one change in the business state specify.

More specifically, it becomes a dialog-oriented one business system provided for trading instruments between contracting parties with: a number of dealer terminals, which each have a user interface for entering and displaying business-related of dialog-oriented messages for the dealer Have information, the dealer terminals with each other via a Communication network communicate, the dealer terminals each also a parser for include parsing the entered dialog-oriented messages, the parser comprising: means for analyzing the dialog-oriented News to make a change the state of a business to capture, the business a variety of possible states having; Means for analyzing dialog-oriented messages, to business related To capture information for the recorded status of the business is relevant; and means of return a parsed message showing the business condition and relevant business related information includes, to the user interface.

Embodiments of this aspect The invention has the advantage that the parsing of dialogues is strong is simplified. In the first case, the parser needs changes of the state only between one of a few possible business states. If a change of the condition has been recorded, there are only a limited number of Conceived of business related Information for these states are relevant, which makes parsing very easy.

A second aspect of the invention introduces Parsing on complete dialog-oriented messages delivered by the terminal become. To be more precise, it is a dialog-oriented business system provided for trading instruments between contracting parties with: a plurality of dealer terminals, the one user interface each for input and display of business related information for the dealer, like dialog-oriented messages, with the dealer terminals with each other about a communication network communicate with the dealer terminals one parser each for show the parsing of the entered dialog-oriented messages, the parser comprising: means for receiving complete dialog-oriented messages from the user interface and to analyze the complete messages, to business related Determine information and to form a parsed message; and means of return the parsed message to the user interface.

Parsing entire lines of a dialog is very beneficial because it allows implement a structured parsing approach at which the message can be parsed to, after a first function, such as a change in the business state to look for, and then parsed in a way that by the first function is prescribed. This is with systems of the State of the art not possible parse the characters.

A third aspect of the invention allows the user to view and change parsed messages before they are sent to the contractual partner.

More specifically, it becomes a dialog-oriented one business system provided for trading instruments between contracting parties with: a plurality of terminals, each having a user interface for entering and displaying to the dealer of business related Information, such as dialog-oriented messages, where the dealer terminals with each other about a communication network communicate with the dealer terminals each also parsing for include parsing the entered dialog-oriented messages, the parser comprising: means for analyzing dialog-oriented Messages from the user interface to business related Capture information and form a parsed message; medium to return the parsed message to the user interface and for viewing the parsed message; and means for confirming or changing the content of the parsed Message before transmission the message to a dealer terminal of a contractual partner.

Once the parsed message has been formed, the user can accept, edit, or invalidate it. The contractual partner will only see the final message if it exists. Thus, if a trader makes a mistake, changes his mind, or suddenly market conditions change, the trader can change or invalidate a message that would otherwise be sent. Not only is this convenient for the trader, it is highly beneficial for the trader's market position as he does not have to disclose his trading position and thought processes until he is happy with his position. This is not possible with prior art systems in which dialogs are parsed when they are typed. Although each partner can void the terms of a deal or try to correct them once it has been completed, they still have their cards (moving green de / strategies) to the contracting party, which is undesirable.

Another aspect of the invention allows that more than one dialogue with the same contractor at the same time is up to date at any time. If the parser to any Time information regarding of the new business regardless on the status of the current business recorded, he notifies the user interface, and a new dialogue or business becomes initiated.

More specifically, it becomes a dialog-oriented one business system provided for trading instruments between contracting parties with: a number of dealer terminals, which each have a user interface for entering and displaying to the dealer of business related Show information as dialog-oriented messages, where the dealer terminals with each other about a communication network communicate with the dealer terminals each also a parser for include parsing the entered dialog-oriented messages, the parser comprising: means for analyzing dialog-oriented Messages from the user interface to business related Collect information and form a parsed message; and means of return the parsed message to the user interface for viewing the parsed message; the system further comprising: medium to start a business with a contractor at the request of a dealer; and Means to initiate another business with the same contract partner when the parser records business-related information that is on a business additionally to a current business refers.

A system that addresses this aspect of Implementing the invention has the advantage that it is highly flexible and respond to the way dealers work and think. If a dealer at any stage of negotiating a deal with asks a contractor for an unrelated business rate, the system will record this course request and initiate a new business. Both stores and all other new businesses can together, but completely independently from each other. State of the art systems enable just that a single dialogue with a given contractor led at a time can be.

In another aspect of the invention is a parser stupid in that he has no knowledge of the Business processing procedure reserves. The parser parses a line of the dialog and returns a file that the business condition and related business information includes.

More specifically, it becomes a dialog-oriented one business system provided for trading instruments between contracting parties, with: a number of dealer terminals, which each have a user interface for entering and displaying business-related Show information as dialog-oriented messages to the dealer, where the dealer terminals with each other about a communication network communicate with the dealer terminals each parsing for include parsing the entered dialog-oriented messages, the parsing comprising: means for analyzing dialog-oriented Messages from the user interface to business related Capture information and form a parsed message; and Means to return the parsed message to the user interface for viewing the parsed message; where when returning the parsed message no record of the parsed to the parser user interface Message or business reserves, to which it refers.

Embodiments of this aspect The invention has the advantage that the parser is very simple. Since the parser also does not store historical information, it is easy it to the user, for example as an applet (small utility program) download every time the user logs into the system logs. This makes the system suitable for use in an Internet environment suitable and makes it for dealer very easy to access the system since it doesn't use the parser have to load them onto their workstations themselves. It also decreases the additional effort regarding IT support for user organizations, such as banks or other financial organizations.

In another aspect of the invention becomes a stage for filtering parsed messages between merchant terminals introduced. This makes possible, that parsed messages checked to ensure that they comply with the business or operating rules of the System.

More specifically, a dialog-oriented business system for trading instruments between contractual partners is provided with: a plurality of dealer terminals, each having a user interface for entering and displaying business-related information as dialog-oriented messages to the dealer, the dealer terminals communicating with one another via a communication network, the Merchant terminals each include parsing for parsing the entered dialog-oriented messages, the parser comprising: means for analyzing dialog-oriented messages from the user interface to capture business related information and form a parsed message; and means for returning the parsed message to the user interface and displaying the parsed message; the system further comprising: a server for receiving parsed messages with business-related information from dealer terminals and distributing the parsed messages to target terminals, the server means for checking the acceptance of the parsed messages sent by a dealer terminal before communication to a target dealer terminal and for rejecting them illegal parsed messages without routing the rejected messages to the target trader term nal has.

This aspect of the invention points the advantage that illicit transactions can be filtered out without that a business agreed by the partners. The filtering can also be a Credit check (credit check) to ensure that each partner is adequate Has resources to complete the deal. A Credit check can be integrated into an institutional credit system that typically the shops Limits that are concluded with each contract partner over a certain period of time can be.

If the parsed message as not allowed rejected is decreed the intended recipient has none Knows that the message has ever been sent. This is beneficial since the dealer reveals no information regarding its business position, except if shops possible are.

This aspect of the invention is also advantageous as it prevents traders from frequenting very lively and fast moving markets on business Waste time that is otherwise rejected as not allowed would be once they were completed.

In another aspect of the invention messages displayed on the user interface according to the origin color-coded.

More specifically, it becomes a dialog-oriented one business system provided for trading instruments between contracting parties with: a number of dealer terminals, which each have a user interface for entering and displaying business-related containing dialog-oriented messages Information to the dealer includes, the dealer terminals with each other about communicate a communication network, the dialog-oriented Messages are displayed in a color-coded form around the User to indicate the origin of the dialog-oriented messages.

In a preferred embodiment messages generated by the user in a first color, messages generated by one contractor in a second Color and messages generated by the system in a third color shown. System messages can parsed messages based on user or contract partner input of dialog-oriented messages.

Warning messages are preferably Errors or danger messages are shown in a different color.

This aspect of the invention points the advantage of making the user display much more understandable. This is very significant in a fast moving market where A dealer many businesses may have pending at any time and where he is asked for the business information very much analyze quickly.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are now only exemplary and with reference to the accompanying drawing described in which show:

1 a schematic diagram of a trading system;

2 another schematic diagram showing the main functional components of a dealer terminal;

3 a view of the user interface of a dealer terminal according to a first embodiment of the invention;

4 a similar view to 3 that shows a number of dialog boxes;

5 a view of a business stack within the user interface showing the business detail field;

6 another view of the business stack and the business detail field, with a different business in the business detail field of 5 is highlighted;

7 another view of the deal stack showing a deal detail field for a forward contract;

8th FIG. 12 is another view of the business stack showing the business detail field indicating an error box;

9 a still further view of the business stack showing the business details field highlighting potentially modifiable fields;

10 shows the deal stack with the deal detail field showing a completed spot exchange deal (FX spot) with the value of the deal traded;

11 shows the deal stack with the deal detail field showing a forward deal with a spot rate request message; and

12 shows how the spot rate request message from 11 appears on the counterparty's business detail field as a warning message;

13 Fig. 4 is a flowchart showing an overview of the parsing process;

14a and 14b are flowcharts showing the parsing process in more detail;

15 is a screen shot of a second embodiment of the user interface showing a parsed message entered by the seller;

16 shows the screen of 15 if the parsed message was sent but not recorded;

17 shows the buyer's interface when the parsed message is received;

18 shows the buyer's interface when the system is waiting for the buyer to offer;

19 shows the seller's screen when a course is received;

20 shows the seller's screen when a deal is closed;

21 shows an example of a warning message and an error message together with a second dialog, which is initiated from the first dialog; and

22 shows another example of warning messages.

DETAILED DESCRIPTION OF THE PREFERRED Embodiment

This in 1 Schematic system is a dialog-oriented business system for trading a variety of financial instruments. Instruments that can be traded include, but are not limited to, foreign exchange spot (FX spot), dates and outrights (fixed-term currency transactions). Although the following description will focus on foreign exchange spot and forward transactions, it is apparent that this is only for the purposes of illustrating the invention and that the invention is not limited to any particular financial paper or to any financial paper at all. It is also applicable to the action of any other justifiable thing (fungible), such as raw materials (commodities), metals, etc.

The exemplary system is preferred an internet-based system where dealers with other dealers from Dealer terminals via the Communicate internet. shops are agreed through an exchange of messages between traders.

The message content becomes automatic parsed by the system to business-related Identify content for processing. Once the parsing one Annual Change in condition the rest of the business processing is captured from the business stack handled. The business state change does not have to be through dialogue, but can be accessed directly from the terminal dealer can be entered, for example by using on-screen function buttons or Keyboard-driven menus, can be entered. This enables the system also users, through a simple exchange of business content data, that are not critical of the dialogue, and by a mixture of the two Procedure to act.

The following description gives an overview of the trading system within which the user interface of dealers used to do business perform. However, it is obvious that this is just an example of a trading system which is suitable for use with the invention. The invention is not limited to any particular trading system, but is applicable to any system where a trader trades multiple instruments. Such a system can be internet-based or on a conventional public one or private network work. It can be a distributed architecture use or work through a central host or on a any other way.

Now referring to 1 is based on an disclosed trading system 10 on a number of server farms 12 created by a system intranet 14 are connected. The server farms 12 communicate with dealer terminals 16 on bank / stock exchange floors through a communication network, here the Internet 14 , and local bank intranets 18 , The majority of business processing takes place at dealer terminals 16 instead, taking business news from the server farms 12 to contract partner dealer terminals 16 be directed. The server farms also return traded business information to bank back office systems (not shown) to allow deal tickets to be generated and transactions to be settled. The shops are in the system 16 either entered directly by the dealer or through parsed dialogs exchanged between the dealers as described. The parsing takes place at the dealer terminals.

2 schematically shows the user terminals 16 as well as a server farm. A variety of dealer terminals 16 , two of which are shown, communicate with each other and with other terminals (not shown) by exchanging dialog-oriented messages via a system server that forms part of the server farm. Every customer terminal 16 comprises three logical components: a user interface 20 , a communication module 22 and a parser 24 , The customer terminals are typically a suitable computer, such as a PC or a workstation with conventional components, such as input devices including a keyboard and a mouse and a monitor, which represents the user interface for a dealer.

The dealer terminals 16 and the server 26 communicate over a communication network, which may be a private network or a public network, such as the Internet, such as the World Wide Web, as it is 1 is shown. The communication module can, for example, be a month at the dealer terminal or customer area network or other suitable device.

The parser 24 carries out an analysis of dialogs exchanged between dealer terminals and extracts business-related information from these dialog exchanges, as will be described in detail later. The functional components of the system: the parser 24 who have favourited User Interface 20 and the communication software for the communication module 22 are preferably downloaded to the dealer terminals as an applet each time a dealer logs into the system. This means that the customer terminal does not have to store any software to access and run the system, all of which can be done by accessing an appropriate page on the World Wide Web. The system 10 can be used by a trader no matter where he or she is. However, as can be seen, the system is designed to trade very large amounts of currencies and currency products, as well as other defensible items (fungibles), and in practice is limited to banks and other institutions with proven creditworthiness. Nonetheless, the portability and flexibility of the system is beneficial for merchants and is not available in prior art dialog business systems where access to a proprietary network is limited.

In the preferred embodiment, the server includes 26 a business server 28 and a chat server 30 , These form part of the server farm of 1 , The business server acts to verify the details of proposed transactions against business and banking rules and allows other checks to be performed before a proposed transaction is made visible to the potential contractor. This may include the seller's creditworthiness; which is their ability to settle the trade they propose. The chat server 60 handles the exchange of dialogues between customers on the network. As explained, dialog-oriented messages, which may or may not contain business related information, are routed between customers via the chat server. A customer can participate in multiple dialogs at any time and conduct multiple different dialogues with a certain other different customer at the same time, allowing two partners to have two or more transactions negotiated at the same time.

3 shows the user interface displayed on each dealer terminal. The display comprises a number of fields. To a degree, the fields displayed can be configured by any trader according to his or her preferences, although some of the fields are permanent. Basically, the ad includes 100 three imaginary containers 102 . 104 and 106 , The container 102 is the top of the three bins and extends across the width of the display, with a bottom left bin below the top bin 104 and a lower right container 106 is. To the left of the containers is a configurable icon display 108 ,

The upper bin only shows fields that require the full width of the dealer's display area. Each of the fields that can be displayed is assigned one of two priorities. A priority field 1 cannot be covered. A priority field 2 can be covered or set to zero in height. In either case, the field data model is retained when the field is invisible, which allows the data it contains to be displayed when it becomes visible again.

There are three permanent fields, each of which has priority 1 exhibit. These are in the 3 and 4 shown. In the upper container 102 becomes a business stack 110 , in the lower left container 104 a dialogue area 112 with a number of dialogues in which the dealer takes part and in the bottom right container an incoming dialog box 114 is displayed in which incoming dialog-oriented messages are displayed. The incoming messages include dialogues in which the trader is not yet participating and may never be able to participate.

The optional fields that the dealer can choose to display include: A dealer business field (not shown) that has a priority 1 is assigned and which shows all the transactions carried out by the dealer and which can be displayed in each of the two lower containers; an overview field (not shown) which is a priority 1 is assigned and that is positioned in one of the two lower containers; a business log field (not shown) with a priority 2 and that shows stores logged by the system and in the top bin 102 were displayed; a course area 116 which displays the current trading rates on the system for different currency pairs and which is a priority 2 is assigned; and a dialog archive (not shown) positioned in one of the lower bins and a priority 2 having.

Like it out 4 it can be seen that some of the fields comprise a button bar along their lower edge. The different functions of the buttons are explained below. The button bars of the dialog boxes include a float button. Clicking this button allows the position of the field around the screen to be changed even outside the window in which the entire system is displayed. This can be useful, for example, if the customer wishes to display several optional fields or if there is a larger number of open dialogs. In the described embodiment, up to ten dialogs can run simultaneously, although it is obvious that this is any number that can be changed.

The incoming dialog box lists only incoming dialog-oriented messages. In the example of 3 a single dialog is displayed. At this time, the customer is not a partner in the dialogue. The dialog is displayed under four headings: identifier (ID), which is the unique dialog identity number, time, which is the time at which the dialog was initiated by the contracting party; From, which is the identity of the contracting party initiating the dialogue; and message, which is the last message line in the dialog. In the example of 3 For example, the message "A dialog started by peter @ CITO" was sent by a dealer identified as Peter to the institution with the identifier CITQ. The dialog was initiated at 13:34:54 and has the identification number 1791. Each new dialog is identified with an ID number. It is also associated with a business info file that includes a set of business related information including the business type: currency spot, currency outrights, appointments, etc., the amount of the transaction, the direction of business (seller, buyer) and other necessary information. A business information structure also includes the current state of the business. Central to the way dialogs are parsed is the concept of a business that is in a number of states that indicate how far the business has progressed. Essentially, these states begin with No State, which refers to a dialog without business related information; RFQ, which is the state in which a course request was identified by the parser; Course where a course was identified by the parser in response to the RFQ; and buy / sell where the deal is made by a partner who agrees to buy or sell at the listed price.

Under the incoming dialog box is a button bar with buttons marked with 'Record', 'Delete', 'Transfer' and 'Chat'. To select a dialog to act on, the customer clicks on the dialog line, which will cause the dialog line to be displayed in a different color from all other dialogs in the field (in the present case it is the only dialog). When the customer clicks the 'Record' button, a dialog box appears in the lower left container 104 opened for the selected dialog ( 4 ). At this point, the system causes all other partners to whom the dialog-oriented message was sent to display the message 'User name has joined the dialog'. When a partner joins a dialogue, they only see that dialogue from the point at which they joined. As soon as a first person has accepted an invitation to chat with a business code, this invitation will be withdrawn by all other partners to whom the invitation was sent.

As soon as a dealer starts a dialogue, the dialog is removed from its incoming dialog box.

The 'delete' button does so when that the selected one is clicked Dialog deleted from the display becomes. When a dialog is deleted is, the dialog initiator will have a 'dialog of user names denied' in their own Dialog box received.

The 'Transfer' button is only released if when a dialogue is bilateral. If clicked, the dialog will appear to the dealer or transfer the business code, the dialog-transfer dialog is specified. Can regulate that define who, if any, a given trader gives a Transfer dialogue can.

The 'Chat' button calls starting a dialog session and also opening a dialog box in the dialog area. Multiple dialogues can be with the same person open although a warning box is preferably displayed to notify the customer if he tries a second or subsequent dialogue with the same Open person.

All the functionality of the button bar can alternatively be displayed as a pulldown menu to operate only through the keyboard.

With additional reference to 5 to 7 the store stack shows a list of stores in which the trader is involved and which are pending or closed.

The business stack 130 includes the following main components: a business list 132 , a business detail field 134 and a button bar 136 , The store list presents information about a store under four headings: the store status 120 , the time 122 , the contractual partner (dealer / bank) 124 , the instrument that is traded 126 and the business 126 that is carried out. Those in the business list 132 presented information is independent of the traded instrument. This is achieved through the use of the business detail field and is extremely advantageous as it allows the business batch to be presented to the customer in a very simple manner with the minimal amount of information and in a manner that is easily done by the trader is recorded.

Around the text of the business field 126 To understand, it must first be noted how business related information can be brought into the system and how the system understands the information, how it relates to a business. Business information can be presented to the system in one of two ways: by entering business directly or by parsing dialogs. Parsing dialogs will be explained in more detail later. At this stage, it is sufficient to note that parsing involves the system parsing dialog messages to determine if they contain any business-related content. If they do, the deal will appear in the deal list.

A deal is started by entering a 'quote request' (RFQ) into the system of a trader. An RFQ is an indication from a trader that he is interested in trading. The first line of the business list in 3 shows an RFQ. Here the trader has made an inquiry to trade $ 2.5 million in the US $ / Canadian dollar market. No demand or offer prices are given at this stage and there is no indication of whether the trader wants to buy or sell. The RFQ could be entered into the system as a dialog-based message or by the retailer who makes a direct entry, in which case he presses the RFQ button on the store button bar. This will display a field that asks for the instrument, currency pair and amount.

So a business can either by entering a direct course request into the system or by initiates the creation of a course request by parsing dialogues become. Conveniently, can the latter being referred to as an indirect course request.

When an RFQ is received or captured the system determines the text that is displayed in the business list becomes. This will either be a direct RFQ transcription or be a representation of the parsed, indirect RFQ.

There will be a number of business conditions for each Instrument defined. Each of these has an associated status chain, which is displayed in the status field, a chain of stores, which is the text that appears in the business box, and a understood description.

Terminalzustand

Some examples of business conditions for currency spot (FX spot) are as follows.

terminal condition

The ones associated with some of the above chain stores and state chains are as follows: It should be noted that the business chain is the dialog text that the system actually entered for that of the dealer Dialog is exchanged when the trader uses either business information the button bar on the business stack or equivalent keyboard menu enters.

Terminalzustände

The following is an example of the business conditions where the instrument is a forward transaction:

terminal states

For every business in the business stack there is a corresponding dialogue session. In some cases, the RFQ from a dialogue. In other cases, it won't. In in the latter case, a direct course, a dialog is created however, a dialog box is only opened, i.e. the dialog box will be revealed if specifically requested by the dealer.

Thus, whenever the system an action on a business in response to a dealer action, one Message line included in the dialog session, which is the nature of this Action indicates. This line of news is in a form where, if the dealer had revealed the underlying dialogue and the message text Type it in, parse it, and generate the same action on the store. The message will be in a form that is the best dialogue practice reflects from the point of view of parsing.

The business list shows all current RFQ at which the dealer is involved. He can see other RFQs if the appropriate options are set. The dealer will preferably have the option of closing deals automatically to delete, when they are finished. The dealer will prefer the Have option to see all RFQs automatically generated by his Account has been forwarded. Are automatically forwarded RFQs from the business list through the delete function to delete.

As mentioned above, the business list is completely independent of the instrument traded. Thus, the business list shows only five columns: condition, time, dealer / bank, instrument and business. The business column contains an instrument / state specific string that is generated by the system will to describe the business.

To the independence of the business list 132 the business details field points out 134 an instrument-specific format at the bottom of the business list, reflecting full details of the business currently selected in the list.

If a new business to the business list added it will appear at the bottom of the list regardless of the sort order currently selected introduced (A resort is used to keep the business in order Sort order). If a business to the business list as a result of the actions of the dealer (RFQ or chat) added the last item added to the table becomes the selected item. The list is scrolled so that the selected item for the dealer is visible.

When a new business from one Contract partner is initiated, changes the selected one business Not. When the focus is on the business list, it changes the currently selected Item not when a new store is added to the list. If a new business to the business stack added will, so the business stack would have to go through about business the background of the scroll bar (scroll bar), for example, red until the store is visible through the passage is made.

The business detail field can have buttons and other controls included that are specific to an instrument functionality refer to that through the standard business batch buttons available is. If a business is in a modifiable state, the modification is via edit controls in the business details field carried out. These potentially modifiable fields are meant to be different Color, for example, cyan) background to the rest of the business detail field. The Deal Detail panel can itself be a different color, for example yellow, as have the business list. If the fields are editable, you can, for example, by a white one Background with a black border can be distinguished.

The format of the business details field is specific to the instrument of the business. Each implementation of the field has certain common fields and controls that are always in the same place: state, time, dealer / bank, instrument and error / warning combo box. The 5 . 6 . 8th and 9 illustrate the business details field for foreign exchange at different levels of a business, and 7 illustrates the business details field for foreign exchange dates at a certain level of the business process.

Thus, the business detail field includes 134 all information in the business list 132 , with the exception that it is instead of the business list 132 contains the information that, when entered and then parsed, to the business list 132 will lead. Thus, for foreign exchange cash ( 5 ) the business detail field Amount, Currency Pair, Value Date, Demand and Offer Prices and Traded. In 5 the shop detail field for the first shop in the stack is shown. This is a business that has just started and where the RFQ has been issued. As there are no demand or offer prices yet, the only fields that are pre-assigned are the amount, the currency pair and the value date. When parsed, this results in 'I request $ 2.5 million.cad' as it is at the top of the business list 132 is shown.

In 6 the highlighted store is the third on the list, and the condition of the store is pre-offer B seller, indicating that the seller has taken up the buyer's offer and is offering bid and ask prices for 3,200 million Japanese yen. Since both the amount and the prices can be edited, they appear in the business detail field as black text on a white background.

7 shows the business detail field for a forward transaction. Here the field shows both near and far amounts, the currency, the type of both near and far deals, their value positions, the left and right sides, cash amounts ( 5 ), all in amounts and business amounts. In the example shown, the field refers to the fourth deal in the list that is a closed deal. This means that all fields in the business details field are pre-assigned and none can be modified. There is an error / warning combination box in the lower left side of the detail field so that traders can be notified of entries or errors that are not permitted. This combination box preferably has an entry in its drop-down list for each error or warning condition associated with the store. When an error or warning is selected in the combo box, the field to which the error or warning relates is highlighted in a very obvious way, for example with a red (error) or orange background (warning). Errors and warnings are listed in order of priority. This combo box includes an associated label on its right that indicates the number of errors or warnings that the combo box contains. When an alarm or warning state changes in the list, the item with the highest priority is the selected item.

8th shows an example of the error box. Here, the highlighted store is the third in the store list. This requires an amount as well as demand and supply prices. The dealer has No demand and offer prices entered, and the error box shows that a demand or offer price is required. In addition, the supply status chain and the demand and sales fields, which would normally be shown in white, are highlighted in red.

The presence of an error in the combination box is supposed to be key and menu elements lock that allow that business continues until the error condition is corrected.

9 shows the business detail field for a business waiting to be accepted. Here the seller has made an offer and the store is now waiting for an acceptance or rejection from the buyer. The amount, demand and sales details are highlighted to indicate that they can be modified.

The column entries state, time, dealer / bank and instrument are just below on the business details panel their respective columns positioned in the business list. If adapts the size of the columns, their relative positions will also adjust. The width of the error / warning combination box and their assigned Zählbeschriftung is preferably automatically on that of the combined columns Condition, time, dealer / bank and instrument set. The instrument-specific fields under the business column will adjust in size and position proportional to the width of the business column.

The instrument-specific fields will now be more detailed for the described two example instruments. It is obvious, that the invention is applicable to all instruments and that the fields will change from instrument to instrument.

The amount field is initially only read and shows the amount of the RFQ in millions. When the store reaches the pre-offer seller stage ( 6 ), the field becomes editable.

The 'To' currency field is to the right of the amount field and is the currency in which the RFQ is expressed. If it is not the base currency it will be displayed and if it is it will not be displayed. It is up to the pre-course B seller stage not editable, at which point it becomes editable.

The currency pair field simply shows the traded currency pair.

The value date gives the value date for the business and cannot be changed by the partners. It is a regular date for the Instrument unless otherwise stated, for example by an asterisk.

The demand and supply fields show inquiries and offers where they exist. Except in the pre-offer B seller and pre-new offer seller stages of the store, they are only read if they can be edited as is related to 6 is described. If a large figure, ie the most significant digits of the price from the market entry into the trading system, is available, this number is used. If there is an arbitrage situation, the market entry rate, the large number of the system's best offer, is used. This can be seen in the system course field that the customer can select to display.

The last field is the Traded Price field, which shows the price at which the deal was made. Like it out 10 it can be seen that this reflects the page (buy or sell) on which the transaction was made. In 10 the traded price is the demand rate.

The appointment-specific shown in the business details field Fields are as follows: Near and far amounts. These work on the same way as the amount field in the cash register example.

On-currency. This works in the same way as the amount field in the checkout example.

Currency pair. This works in the same way as the amount field at the checkout example.

Near and distant periods. If these periods of time standard periods of time, for example one month, they are shown as such. If they don't they are shown in dashed lines.

Dates near and far. this shows the near and far value positions.

Left and right prices. Where a left Side (LHS) or right side (RHS) exists, it will be in this Field displayed. It's a read-only field, except when the business condition in the pre-offer B seller or pre-new offer B seller condition is. If it is in edit mode, this field is at the market rate default if they are for the demand available is. If the dealer leaves the LHS or RHS empty, then a one-sided price is noted without a demand or offer.

Service and discount. If the LHS is less than the RHS, the system assumes that the base currency is with a premium to the local currency is. If the dealer does not enter a minus and the RHS is smaller than the LHS, that takes System that the base currency at a discount to the national currency. Where a tee is recorded, adds the system signs A-A in front of each value and shows the demand and the offer with them. A dealer can have negative amounts for you Enter discount.

Spot rate. Where a spot rate exists, it shows the spot rate demand field. It is a read-only field if the store is not in the I / C rate or I / C rate (I sell / buy or buy / sell at a given rate). In edit mode, the field with a middle course between the Demand and supply market prices pre-assigned.

Spot button. Like it out 11 As can be seen, the business detail field includes a checkout button that the customer can click to display a checkout request dialog box. The checkout button is only visible to the retailer if the transaction is in the I / O confirmation or I / I confirmation stages. The spot rate request dialog box includes an edit box that allows the trader to enter a text of up to 30 characters that has been pre-populated with the text 'Check rate'. This enables the trader to check the spot rate before committing to a deal. Like it out 11 can be seen, the dialog box includes send and delete buttons. The send button closes the box, transmits the message and changes the business status to I V / K expect course or I K / N expect course.

On the other hand, when a seller shop receives a spot rate request message, the message appears as an alarm in the error / alarm combo box. This is in 12 shown.

Flat rate. This field is only read and reflected when the seller presents a spot rate the sum of the traded price and the spot price. For overnight or morning-next periods becomes the sign of the demand or offer course vice versa to calculate the flat rate.

Settled course. this is that last field in the business details field and is a read-only field. If the buyer is buying / selling or Selling / Buying, the field reflects the price on the side of the Market that was traded on.

Outrights. The fields for the business details field, if the instrument is an outright, they are not shown as they are the same as for a cashier referred to above.

The business column shows different ones stateful Strings for every instrument. Some of these have been previously discussed for cash. The Strings are not hard-coded in the system, but from configurable centrally by the system administrator. The dealers have preferably no control over the strings. As previously seen, the state definitions include Text elements (tokens) delimited by tildes (tilde signs) that represent the underlying values for the business.

The text elements for the cash desk and outrights are as follows:

The text elements for futures are as follows:

The third part of the business stack 130 is the button bar 136 that are under the business list 132 and the business detail field 134 is. The button bar gives the merchant various options to continue or cancel a deal. The button bar is specific to each business. This means that the button bar displayed depends on the store that is selected in the store stack. Some options will not be available to a trader at certain stages of the business as explained.

With reference back to 5 to 8th it will be seen that the button bar differs from figure to figure depending on the state of the store highlighted in the store list. In some cases, buttons do not appear in bold, indicating that they are not available. In some cases, buttons are exchanged. As examples of the latter, the record button is shown in 5 through an offer button in 6 replaced. The cancel button of 5 is activated by the Nothing in button 6 replaced.

The button bar provides the trader with an alternative, but also valid procedure for trading in accordance with dialog exchange with contracting parties using the dialog boxes. The system works by converting business instructions into parsed text using the buttons in the same way can be entered as it parses dialog text to produce parsed text for the business list business field.

The buttons available to dealers are as follows:
Recording (e.g. 5 ). This enables a trader to 'include' an RFQ entered into the system by a buyer. As a result, the record button is only available to the seller and only when the store is in the pre-record B seller state. By pressing Record, the seller indicates that he is interested in an offer via the RFQ. The RFQ can be sent from the buyer to one or a number of dealers. If a business code has been sent (ie one or more trading floors), the RFQ will be removed from the business lists of all other recipients when a recording is received.

Course (e.g. 6 ). This enables a trader to enter a rate and is thus only released on the seller side when a deal is in the pre-course B seller state. The action of the course will change according to the instrument. For a spot or outright transaction, the system transfers the seller's demand and / or offer price along with an amount to the buyer. For a forward transaction, the system transfers the seller's LHS points and / or RHS points to the buyer along with near and far amounts.

The first button in the button bar combines all standard actions. For the checkout example, the button return to recording, however, business conditions differ of the above are shown in gray. For futures more options are available. If the business in Condition is V / K or K / V-before-course seller or V / K- or K / V-before-course-2 buyer, the button will appear as a course button (not shown) displays what enables the seller to spot the seller's spot rate to transfer the system. If the forward transaction in the V / K or K / V pre-confirmation buyer or V / K or K / V Pre-Confirmation-2 buyer becomes the button as a cash register button displayed it to the buyer allows that of the seller to accept the proposed spot rate.

Chat. This button that only available is when a single business selected causes the dialog box for the store to display in the lower left container open becomes. Even if the deal in a direct, non-dialogue form carried out the system will show a detached version of the dialog, the to this business condition guided would have. This is possible, because every business has one Dialogue without consideration on how the business shows carried out whether by dialog or direct input using the button bars. The dealer can switch to dialogue at any time to continue the business. The system will parse this dialog and will not switch between direct ones and indirect business entry procedures differ. The system is transparent in this regard.

Hold. This button will only released if a selected one business in the pre-offer seller condition is. It causes the selected store to be returned to the pre-admission buyer and pre-admission seller states will, and if the original RFQ on a business code has been sent that the RFQ is displayed again to all these partners becomes.

Transfer. This button will only be released if selected stores are in the pre-offer seller state are. It enables a dealer, the business to another dealer transfer within the limits of a preset authority. The press the button will cause a dialog box to appear in which the dealer the dealer's code can enter to which the business transferred to is. A related one Message is on the business stack displayed by the author so that he knows that he is now dealing with a different Contract partner acts.

To sell. This button will only for Instruments, such as cash or outrights released. It provides a means for a buyer ready to sell at the seller's demand rate and so only released in pre-buy / sell condition when there is an offer from the seller gives.

RFQ. This button enables one Seller, to bring a course request to the market. When this button is pressed the seller must the amount and currency pair deliver. When the RFQ is received from the system, the store is new Dialog assigned.

The heading of the RFQ button changes in FIX order if the RFQ through dialog parsing on the buyer side was initiated and on confirmation accuracy by the buyer waiting.

Call. This button enables one traders to initiate a call. To buy. This button will only released if a selected one business for a Instrument, such as a cash register or an outright, in which Pre-buy / sell Buyer state is where there is an offer from the seller. By pressing the Button gives the buyer the system that he will buy at the seller's offer price would like to.

Abort. This is a multi-function button, the heading of which depends on the business condition and the instrument traded on the selected business. It is used for all negative functions. These functions may change from instrument to instrument, but for the cashier they are as follows:

The negative actions for futures are as follows:

Of the various actions mentioned above the demolition action aborts the existing business level, resulting in a previous business level returned becomes. The Nothing Action indicates that the buyer is on a proposed business is not interested. The interrupt action removes the deal from that business pile and is only released when a store reaches a terminal state, that is, it is a closed deal.

Clear all. This button deletes all legitimate business from the business stack.

All off. This button pulls all stores back from the market that are in an appropriate form.

The previous section described the trades available to a trader from the button bar. It is desirable that the dealer be able to perform all of the available functions without using a pointing device such as a mouse. Accordingly, the system provides a set of pop-up menus that provide the same functionality as the button bar, but all of which can be accessed from the keyboard. Each function can be called from the same keyboard character in every menu. Examples of the characters to which functions can be assigned are:

An example of a possible menu for a business condition is as follows:

PARSE

The description above has with the dealer interface with the business system deals. It was mentioned that business into the system directly through the business stack button bar or equivalent by pressing a button can be entered or that business entered by dialog can be wherein the dialog is parsed by the system to be business-related Extract information. The next section examines the parsing mechanism.

Parsing within business systems is well known. Parsing is used in the Reuters Dealing 2000/1 system referred to in the introduction. With this system, however, all business transactions take place through dialogue. The trader does not have the option to use direct business entry as described above. As a result, there are no requirements for the system to be able to extract business information. For this reason and for various other reasons, the requirements of the present system for parsing differ significantly from those of the prior art. The following description will consider the foreign exchange markets and in particular the three instruments described above: foreign exchange spot, foreign exchange outrights and foreign exchange dates. First, the way in which the parsing works is described by referring to the flowcharts of FIG 13 . 14a . 14b and the various screen prints of the user interface of 15 to 22 it explains how a dialog-oriented business is carried out. It should first be noted that the 15 to 22 shows a different embodiment to the user interface, which was previously described.

Monitored at all levels of chat exchange the parsing the dialogues, looking for an RFQ (course request). The presence of an RFQ alerts the parser that a new business is being initiated becomes. So if two dealers Exchange niceties that are not related to a business, the parser will monitor the dialog after an RFQ. The user's parser is for parsing the user's dialog, but responsible for it no role in parsing a dialog received from the other partner plays.

In the following example, a new dialog was initiated by a customer named customer 1 and in 15 is shown as kdunay @ EBSN. This user typed a message in his chat field and hit enter. This causes the user interface ( 2 ) to send the chat line at the parsing regardless of the content. The parser parses the dialog, looking for a change in status and other business related information. In the present case, the parsing discovered an RFQ in the chat line. This line, although not shown, may have been an 'I want a yen'. The parser records this as an RFQ and then looks for other business-related information that includes the traded instrument, here identified as the spot cash, the currency pair, here US $ / Japanese yen, and the amount, here 1 million. The parser returns the parsed dialog to the user interface in the form of a business information structure, previously referred to, which contains the business status and business related information.

15 shows the situation where the business information structure was returned to the user interface. The RFQ has not yet been entered in the system and is shown as a parsed line 200 in the business stack 202 displayed. The parsed line can either be edited by the user, kdunay @ EBSN, by pressing the red cancel button 204 declared invalid or edited, for example to change the amount of currency if the trader made a mistake, changes his mind or responds to a change in market conditions. Editing is done by pressing the 'Set' button 208 carried out. Alternatively, the user can re-enter the dialog so that it is parsed again. To indicate to the user that an action is required, the status of the row in the business stack is preferably shown in a representative color, for example green. The button 206 The button bar that the user must press for the RFQ to be sent is also shown in green. The parsed dialog is shown in the business stack in a representative color, for example red, to show that it is system-generated text. At this point, a system message 'Submit? 'also shown in red in the dialog box.

It can be seen that the business stack of 15 differs from that of the previous example in that it has a stripe 210 above the button bar, which shows the user significant information about a highlighted business. Thus, the stripe encompasses the business condition 201 , the dealer 203 , the instrument (cash desk) 205 , the currency pair 207 , the amount with the specified base currency and the demand and supply rates. These latter courses are in boxes 212 . 214 displayed in 15 are not filled because no price has been listed for this transaction.

In the example, the parsed dialog line to in a recorded business state. The line of text could be simple something like 'hello how are you The Parser would then no business related information would have captured, but would send a response to the user interface to indicate that a dialog line was parsed, but no business information was found.

When the user is satisfied with the parsed line as it appears in the business stack, he presses the 'Continue' button 206 , This causes the parsed dialog to be sent to the customer's communication module 22 ( 2 ) and then to the business server 28 is sent.

At this point there are a number of parsing features that should be highlighted. First, the parsing parses the dialog line by line, and the parsing does not take place until the user finishes typing and the send button 216 has actuated. This is in contrast to the previously used system used in the Reuters 2000/1 system that parses dialogs line by line when entered by the user. The system described here is advantageous in that the user can change what he has typed, for example to react to changes in the market or simply to correct errors without revealing his cards (motives / strategies) to the contract partner dealer. It is highly undesirable to let the counterparty's trader know about a view of the market, as it can affect the demand or supply that he makes.

Second, the parser doesn't matter and doesn't keep in the business process Knowledge of business. The parser only looks at the dialog line for information regarding the business status. It returns the business information structure to the user interface and has no knowledge of the business. This makes the parser very easy.

Third, parsing is based on one Store State Structure with an emphasis on capturing state movements. The business conditions are very simple: none, RFQ, offer, buy / sell, though this be worked out as it explains becomes. In any of these conditions there are a number of business related ones Terms the parser is looking for. This makes parsing a lot simple and accurate. First, since there are not many terms, after and second, because there is little chance that creates confusion that leads to misparsing. This could for example, occur when a line of a dialog is on a past business between the partners. By separating the business process in a number of states each of which has a limited number of terms that are parsed can be is it for the parser relatively easy to avoid such false parsing. The details of states and the business-related Terms for every state will be later described in detail.

Contained in the given example the dialog parsed by the parser is both a change in business status as well as any information that is required to capture this Accompany condition (instrument, currency pair, etc.). For each the possible Business conditions there there are only a number of allowed transitions and for each Business condition there is a limited number of expressions that the parser can use as an indication a change of the state will recognize. For example, if the new dialog includes a course request, the parser will look for information which indicates a course. It will parse the entire line and after looking for a given state by a predetermined number of To fill information fields. These become dependent vary from state to state. If the parser changes the state of RFQ expected in the offer For example, he would look to see if there was a demand rate and / or offer a quote or refuse to offer gives. If there is a demand / offer rate, he looks in that In the case of currency spot trading, also after specifying the currency. The conditions of business and the required fields will vary depending on the instrument being traded change.

As soon as the one entered by the user Dialog parsed, the parser gives the user interface one of three ways back:

• a) there is nothing in the dialog that parsed can be. This will be the case if the dialogue is not business related Contains information;
• b) an update of the business structure to the new store state and includes the areas found;
• c) an error message if there is an ambiguity and he the change of state do not dissolve can. In this case, the error is shown in the chat stack and the business not changed.

It had returned to the parsed dialog-oriented message. From the customer's communication module 22 will send the message to the business server 28 sent, which is checked at this point to ensure that it complies with system, banking, and business-related rules. It can also allow credit checks to be performed, for example by linking details in the store to the global credit check mechanisms of the user bank. If the business cannot continue, an error message is displayed on the user terminal, but the contracting party is not aware of this fact. As far as the contracting party is concerned, the RFQ that he has issued is simply not answered. This ability to hide failed deals is beneficial because a user often does not want a contractor to know that he has attempted a deal with him, but has failed. He will also not want the contractor to know the details of the deal being attempted as it will reveal valuable information about his intentions and his reading of the market. This advantage comes from the way the system parses dialogs on a line-by-line basis, rather than in real time, when typed in character by character.

Assuming that the business server 28 the RFQ does not reject, the parsed message is sent to the target user interface via the target customer's communication module. It should be noted that the system is arranged so that the business server handles all business related parsed traffic and the dialog server handles all dialogs that transmit non-parsed dialogs, ie dialogs for which the parser has found that they are none Change in business condition included. This dual server arrangement is useful, but not essential, and could be replaced by a single server or other server configuration.

16 shows the user interface after the RFQ has been sent to the contractor. The state of the deal in the deal stack is shown as 'Waiting for Admission', which means that the user interface has not been notified that the contractor has admitted the deal from its incoming dialog box. The dialog box for the store now becomes the dialog box for the customer shown in a representative color, for example green, to show that the message came from the customer.

Now referring to 17 the customer's user interface is shown to which the in 14 described RFQ was sent. The customer is identified as test @ EBSN. The RFQ message was forwarded from the business server and sent to the customer's test @ EBSN. The sending customer's user interface was also notified that the message was sent. The incoming message will first appear in the customer's incoming message field. In 15 the customer test @ EBSN double-clicked this message to open a new dialog in the active dialog. In the figure, this is identified as a dialog, whereby the name of the contractual partner kdunay @ EBSN is identified. The system indicates in the dialog box that the customer test @ EBSN has joined the dialog and displays the parsed message in the business stack. It should be noted that the message as a quote 1 mil JPYusd / JPY? identifying what is an embellished version of the parsed message displayed in the seller customer's business stack. The original version of the message is displayed in the dialog box. The message is displayed in the dialog box in a representative color, for example blue, to indicate that it is an incoming message. In the store stack, the condition of the store is displayed as 'pick up' and colored green to indicate that action is required from the customer. In this case, the customer must respond to the RFQ.

The second customer test @ EBSN then types his answer to the RFQ in the chat line 220 of the dialog box and presses the send button 222 , In the same way as the RFQ line, this causes the user interface to send the full line of text to the parser, which parses the text again and sends the business information structure back to the user interface. The parsed text, if it contains a change of state, and the necessary business-related information is sent to the contracting party via the business server. It should be noted that the partner for the customer kdunay @ EBSN only parses dialog that was entered by this customer, and the parser at the customer test @ EBSN parses only the dialog entered by this customer.

18 shows the contractual partner customer test @ EBSN when an offer was entered by the user and parsed by the parser, but was not confirmed by the user. The state in the business stack shows Quotation? And the dialog box indicates the quotation as parsed by the parser followed by a question mark. The chat line of the dialog box invites the user to continue. In 18 the status in the store field is preferably shown in a representative color indicating an alarm, in this case orange. The system displays a message in the 'Large number not available' dialog box. In this case, the message is incorrect and was generated when the price field was locked, but it is used to show how alarms can be displayed.

19 shows the user interface of the customer kdunay @ EBSN when the response is received. The customer test @ EBSN has submitted an offer in response to the RFQ shown as 123.33 / 123.45. These numbers are the purchase-purchase margin. This is shown in blue in the dialog box, for example, since it is an incoming message. It should be noted that the previous entry in the field is the customer's own dialog. This is shown in a representative color, for example green. The business stack shows the change in state to buy / sell, with the state highlighted in green. This shows that action by the customer is required and that the next phase of the transaction is either an agreement to buy and sell at the offer price or a refusal. It can be seen that the business information line shows the offer prices, the amount and the currency pair, and that the large boxes on the bottom strip 212 . 214 now have the demand / supply prices.

20 shows the interface of the first customer after the customer has responded to the offer by agreeing to sell at the offer price. The state has changed to 'I am selling' and the business line is now reading 'I am selling 1 mil JPY usd/JPY@123.33. The last line in the dialog box shows in green that the customer has sold, and this goes to a system prompt in red Sell? ahead. This prompt appears when the user types 'sell' and the change in state in sell is detected by the parser and returned to the user interface, but before the customer has confirmed the sale by clicking the Continue button.

No matter what the state of a business, the parser is always looking for new RFQs and when one is detected, it opens a new dialog. Thus, in the previous example, rather than agreeing to sell, the customer kdunay @ EBSN may have submitted a new request, such as 'I want 1 mil gpb', indicating that he would like to buy £ 1million for $ US. The parser captures this RFQ and opens a new dialog, but does not end the existing dialog. There are now two dialogues between the same two partners. The ability to run different dialogues between the same two contractors at the same time is highly desirable. The system can support a large number of simultaneous dialogues between the same two contracting parties, for example 10. This should not be confused with the ability to have a number of dialogs with different ones To keep contractual partners open at the same time, which is known in the art and is also possible with the system embodying the invention.

The explanation above illustrates how the system handles a dialog entered by the user. In the course of a business there will be different dialog lines, each in the manner described and how it is handled. Once a parser the business structure and forward the captured fields to the user interface information from the parser is lost. The parser points preferably no capacity or request for information regarding the history of the Maintain dialogue.

The 21 and 22 illustrate two other aspects of the parser. In 21 it can be seen that there are two separate dialogs between test @ EBSN and kdunay @ EBSN. The two dialogues are at 224 and 226 in the business stack and as dialogues 1 and 2 shown in the dialog box. In 21 the second dialog is active. This is the top line of the business stack. The system returns an error message if the offer was entered without an amount. The offer status is entered in the business stack in a representative color, for example pink, and an error message is displayed in red above the button bar, telling the user the source of the problem. In this case, she says 'must have an amount'. The error is also reflected in the dialog box that displays a series of 'Amount required' error messages 228 followed by another highlighting message 'must have amount' 230 having.

22 gives another example of the alarm message. The situation presented is a development of the second dialogue of 21 , A bid amount has now been entered, but the system again states that the large number is not available, highlighting the condition in orange. The second business line in the business stack also shows an alarm if the business has been withdrawn by one of the partners.

Now returning to 13 and 14 , shows 13 an overview of the described method. At step 300 the parser looks for whether there is an identifier number for a given dialog. If there are none, it generates at step 302 a new business information structure, and continues at step 304 the state of business on Ano deal @. If there is an identifier, it suggests the business status 306 from the previous parsing. However, this state is not maintained by the parser, but is provided by the user interface. At step 308 the current business status is set to the next level in the business, and at step 310 definitions are applied to the message according to the current business status. These determine which terms the parser will confirm in the dialog as business-related information.

In 14A and 14B the dealer gives a message to the user interface at step 400 on. This message is sent from the user interface to the parser, where it is at 410 Will be received. at 420 the parser tries to parse the message. If it cannot be parsed, the dialog-oriented message is sent to the chat server 430 and then to the intended recipient 440 Posted. A message that cannot be parsed is one that has no business-related content.

If the parser can capture business related information, it determines at step 450 whether there is an error or not. If an error is detected, an error message is sent to the dealer 460 Posted.

If there is no error, the parser determines at step 470 whether parsing is finished or not. If it is not, the customer is asked the information at step 480 to end.

If the parsing was successful, the business information file goes to step 490 updated, and the parsing results are displayed on the user interface at step 500 displayed.

The trader must now decide whether to continue and send the parsed message to the contract partner or not (at 510 ). The confirmation level is carried out by the continue, edit and cancel buttons on the previously described business field. With the simplified diagram of 14B the editing function is not shown. If the trader does not want to continue, the deal will step 520 declared invalid without being shown to the contractual partner. If the trader wishes to continue, the parsed message will be on 530 sent to the store server and the store server tries to 540 to confirm the parsed message against system business rules. If he did business with 550 cannot confirm, the dealer is notified, but the counterparty dealer receives no indication that the message was ever sent. If the deal is confirmed, then a confirmation message will be sent to the dealer 560 and also to the chat server 570 and to the recipient 440 Posted.

The way in which the parsing takes place, will now be more detailed described.

A general currency terminology module provides an indication of the common terminology used by traders is going to forex the chat field on the dealer platform to act.

The system monitors all dialogs carried out via the chat field and interprets text from the Dialogs in a fixed format within the business stack, which standardizes the business details and enables the system to create a formal deal ticket for each forex transaction.

The system can use the significant terms differ within a dialogue that relates to the settlement of business Respectively. This includes terms related to the course request, answers with a course, confirmation of buying or selling and any message of special settlement instructions Respectively.

The system can use terms within a dialogue that leads to ambiguity regarding business details, or whether a business at all is underway could. For example, traders can get one explain previous trade or provide distinctive courses internally.

The system can ignore terms that do not relate to the execution of a transaction. That is, friendly Formalities, such as explanations regarding the weather or certain news stories, are ignored by the system no matter what point they are in the business process occur.

Functional components of the general foreign exchange terminology requirements are:
Chat terminology - common business terms
Chat terminology - negative terms
Chat terminology - unrecognized terms

The interaction between the components is:
Chat Terminology - Common Business Terms provides the list of terms and variables that directly affect a forex business in progress and should be parsed by the system.
Chat Terminology - Negative Terms provides the list of negative terms the system should know that would indicate that previous / previous terms / phrases are not related to an ongoing business.
Chat terminology - Unrecognized terms describes how the system should handle terms / phrases that it does not recognize within the chat dialog.

Chat terminology - common business terms

The system can all be common Recognize phrases and terms used within a dialog that affect the handling of the business. specific Terms within the dialog provide values for the variables that are necessary are so a business can be completed. The system should be able to handle this Record terms and the data to the appropriate fields within the business stack to deliver.

dealer use a variety of different ways / abbreviations, to communicate the same thing within a dialogue. The System can relate to market conventions related to the business stack required key variables take up.

As part of a quote request, the system allows the user to enter a single ISO currency code 'CurrX' or his pseudonym to represent the USD / CurrX currency pair. For example:
CHF = USD / CHF
NZD = NZD / USD
GBP = GBP / USD
cable = GBP / USD
Peso = USD / MXP

The system enables the user to enter a complete currency pair, that is, with reference to both currencies, in the following formats:
Currency1 / Currency2
Currency1 / Currency2
Currency1 / Currency2
Currency1 / Currency2

The system allows the user to specify an amount with a label to indicate a size. For example:
10 million = 10 million
500k = 500 thousand
1 bio = 1 billion (I billion)

If the user specifies an amount without a label indicating the size, the system has to interpret the amount as expressed in millions. For example:
10 = 10 million
CHF in 20 = USD / CHF for 20 million USD
GBP in 500k = GBP / USD for 500,000 GBP

The system allows the user to specify a two-way course in any of the following formats:
Bid quote / offer quote
Demand price-offer price
Demand course Offer rate
Bid quote * Offer price

The user can specify a one-way demand course in any of the following formats:
Bid quote /
buy at [demand course]
Demand at [demand rate)

The user can specify a one-way offer rate in any of the following formats:
- / offer quote
buy at [offer price]
Demand at [offer price]

The user can confirm a deal with the following terms:
Ok
done
confirmed
conf (confirmed)
agreed
agree

The system enables the user to cancel a deal using any of the following terms:
Cancel
Canc
Nothing
Nothing
Nthing
Nthng (nothing)
NT (no thanks)
No Thanks
No thks

If the user does the business in the Dialog aborts, the system automatically breaks the corresponding one business entry in the business stack from.

Chat terminology - negatives terms

The system takes into account that dealers can use the chat field to explain trades previously concluded, whereby they don't try a business complete. The system will recognize terms that indicate that the current one Dialogue in which the dealer involved, not a business concerns.

The system does not attempt to parse any variables from the chat field if the following phrases precede the same line of input / sentence that indicate a past event (replace any characters for ...):
... did (executed) ... [business variables]
... dealst (traded) ... [business variables]
... completed ... [business variables]
... made (carried out) ... [business variables]
... quoted ... [business variables]
... bought ... [business variables]
... sold ... [business variables]

Some examples of the occurrence of the above terms are as follows:
We made EUR 10 million yesterday (We did EUR 10 million ydd) - The dealer is referring to a past transaction
We traded GBP / USD in 10 last week (We dealt cable in 10 last week) - the trader is referring to a past transaction
I completed the stg deal - The trader is referring to a past ge schäft
He made my stg at 67/70 (He made me stg at 67/70 B) - The dealer is referring to a past offer
I have done a deal for Swiss in 20 - The trader is referring to a past deal
He quoted 67/70 (He quoted 67/70) - The trader is referring to a past offer

If the user has entered phrases / terms relating to a past event, the system continues to monitor the chat field immediately after the input has been sent to the contractor. For example:
We made EUR yesterday
I want 20 CHF today - The trader is only referring to a past transaction that the system ignores based on the rules above. The second set is an RFQ for USD / CHF, $ 20 million parsed by the system.
I did not quote you CHF at 50/57
It is 60/57 (Its 60/57) - The trader is referring to a past price (or a false price in this case) that the system ignores based on the rules above. The second set is a USD / CHF offer parsed by the system.

Chat terminology - unrecognized terms

The chat box is for a variety of casual Dialogues are used that have nothing to do with the business process. The system will ignore all terms that meet the requirements of the business use case do not match.

FOREIGN CASH-PARSE

The foreign exchange cash module provides that Users ability to disposal, the currency spot instrument type the chat field on the EBS dealer platform to act.

The functional components of the Foreign exchange parsing requirements are the business use case and the chat terminology business terms. The business use case describes the process of closing a deal and allows the system to actively 'search' for certain terms / phrases that it expects to find within a dialogue that relates to an actual business. Chat Terminology Business Terms provides the list of terms and variables that a deal to close directly concern and should be parsed by the system.

Business use case

To do a spot exchange transaction, the following must take place:
A spot exchange rate request is sent from a buyer to his or her seller (s).

In response, the seller can either: a two-way course (demand and supply) in response to that RFQ deliver - this only if an amount has been specified in the RFQ; a one-way course (Demand and Supply) in response to the RFQ - this only if an amount was specified in the RFQ; a course for one deliver certain amount in response to the RFQ; or specify that he doesn't want to deliver a course with which there is no business.

The buyer receives a course. As answer he can either: indicate that he wants to buy and confirm the deal; specify, that he wants to sell and the business to confirm; or cancel the deal, if the buyer don't like the course.

The deal is now closed.

The system recognizes the stage at which a foreign exchange cash transaction is within the business process. The system searches for specific phrases that relate to the specific stage of the business process. If there is currently no business in progress in a chat field, the system monitors the chat field according to a course request. In particular, the system searches for the following terms, which indicate that a course request was initiated within a chat field dialog:
an indication of the type of instrument (foreign exchange)
an indication of a currency pair
an indication of an amount
an indication of the currency of the amount

A quote request includes at least one indication of the currency pair. Some examples are as follows:
Hello, CHF please (hihi CHF pls) - The buyer is requesting an offer for USD / CHF
Hello, CHF in 10 please (hi CHF in 10 pls) - The buyer requests an offer for USD / CHF for 10 million D.
Hello, foreign exchange cash in 10 please (Hihi SPOT STG in 10 pls) - The buyer requests an offer for GBP / USD for 10 million GBP
Hello, appointment GBP / EUR please (Hi frd GBP / EUR pls) - The buyer requests an offer for GBP / EUR
NSD for 20 please (Welly for 20 pls) - The buyer is requesting an offer for NZD / USD for 20 million NZD

The system parses all variables, which are specified as part of an RFQ, from the dialog into the appropriate one Field in the business stack.

When the system has identified a course request and it has been sent to the seller, the system monitors the chat box for a response to the course request. The system searches for the following terms within the chat field that indicate a response to the course request:
Indication of a demand rate
Specification of an offer price
Offering a refusal to offer
an indication of an amount
an indication of the currency of the amount

A response to a course request includes an amount if none was delivered in the RFQ, along with at least one of the following:
a demand course
an offer course
OR
to offer a refusal

Some examples of an answer to a course request:
1.4696 / 4700 - The seller delivers a two way rate, demand / offer
4696/4700 - The seller delivers a two way rate, demand / offer
96/00 - The seller delivers a two way rate, demand / offer
56/60 up to 10 (56/60 up to 10) - The seller delivers a two-way rate, demand / offer and an indication of an amount, 10 million
I buy at 60 (1 buy at 60) - The seller delivers a one-way rate; the offer price.
Nothing - the seller refuses to offer

The system parses all variables that the seller specified when responding to a quote request from the dialog into the appropriate fields in the business stack. A refusal to offer is indicated when the seller enters this intent in the chat box or the deal is canceled by the deal stack. If the seller refuses to offer, the system should conclude that the deal has been declared invalid. If the seller refuses to offer, the system restarts the monitoring process and searches for a course request within the dialog. The system ensures that the following variables from the dialog are parsed into the business stack before the buyer is allowed to indicate his intention to buy or sell: the currency pair
the amount
the currency of the amount
a demand and / or an offer

If the above variables are not all in the business stack were successfully parsed, the system requests that the seller enters missing variables before indicating its intention to send. For example the system give an alarm. If the system responds to a Has identified the course request and sent the response to the buyer was monitored the system will pop up the chat box after responding to the offer.

The system searches for the following terms within the chat field that indicate a response to the offer:
an indication to buy at the offer price
an indication to sell at the offer price
an indication of a termination of the transaction

A response to an offer includes at least one of the following:
an indication to buy at the offer price
an indication of selling at the asking price
an indication of a termination of the transaction

Some examples of a course request are:
OK, I buy - The buyer is happy with the offer and agrees to buy at the offer price
OK, mine in 10 (Ok, mine in 10) - The buyer is happy with the price and agrees to buy at the offer price for an amount of 10 million, the amount "10" is ignored by the system, all available Amount is bought
Yours (Yours) - The buyer is happy with the price and agrees to sell at the offer price
OK, I sell (Ok 1 sell) - The buyer agrees to sell.
Nothing, thanks (Nothing thks) - The buyer does not like the price and does not wish to act.

The business will be abandoned specified when the buyer indicates his intention to cancel (he doesn't like the price), or the buyer the business within the business stack aborts. If the buyer the business the system has its monitoring procedure start again and after a course request within the dialog to search. When the system identifies a response to an offer has confirmed the system the business in the business stack and starts his surveillance process again and looks for a course request within the dialog.

Chat terminology B business terms

The system can handle all phrases and Recognize terms that are used within a dialog, the the handling of the business affect.

Specific terms within the Dialogs provide values for the variables necessary to do a business. The system is able to include these terms and the data in the appropriate Fields within the business stack to deliver.

dealer use a variety of different ways / abbreviations, to communicate the same thing within a dialogue. The System can have market conventions related to key variables record that for the business stack required are.

As part of a quote request, the system allows the user to enter the term "cash" to indicate that the transaction is a spot exchange transaction. For example:
SPOT Swiss please = spot exchange transaction for USD / CHF

As part of the quote request, the system allows the user to specify a currency pair with or without an amount to indicate that the transaction is a spot exchange transaction. For example:
Stg pls = spot exchange transaction for GBP / USD
EUR pls = spot exchange transaction for EUR / USD
Eur in 10 pls = spot exchange transaction for EUR / USD,
The amount is EUR 10 million
CHF for 20 = spot exchange transaction for USD / CHF,
Amount is $ 20 million

The system allows the user to specify a currency amount to buy or sell. For example:
10 million GBP against USD pls = USD / GBP, 10 million GBP
Eur pls, 10 million US = EUR / USD, 10 million USD

If the user does not specify the currency of the amount specifically, the system has to interpret the amount and display the amount in the base currency of the currency pair. For example:
eur in 10 pls = EUR / USD 10 million EUR
chf for 10 = USD / CHF, 10 million USD
50 million welly pls = NZD / USD, 50 million NZD

The system allows the user to enter the large number only once as part of the first part of the offer, be it demand or offer. For example:
1.4567 / 70 → demand rate = 1.4567,
Offer price = 1.4570
121.43 / 53 → demand rate = 121.43,
Offer price = 121.53

The system enables the user to specify a course without the large number, ie only with the points (pips) of the course. For example:
67/70 → GBP / USD exchange rate, demand rate = 1.4567,
Offer price = 1.4570
43/53 → GBP / JPY exchange rate, demand exchange rate = 121.43,
Offer price = 121.53

The system warns the user when a large number is not available. The system allows the user to specify their preference to buy the specified currency amount using the following terms:
Buy
Mine (mine)
M (M)
B (K)
Take
T (N)
At [Bid Price]
[Bid Price]

The system allows the user to specify their preference to sell the specified currency amount using the following terms:
Sell
Yours
Y (I)
S (V)
Give
G (G)
At [Bid Price]
[Bid price]

The system allows the buyer to indicate their intention to buy or sell. For example:
I sell CHF (user sell CHF) = user sells previously specified CHF amount
Y = user sells previously specified amount in previously specified currency

FOREX Outrights

The parsing requirements of currency outrights are similar to those for currency spot have been described.

The following is a description of the procedure followed to complete a currency outright transaction.

A foreign exchange outright quote request is from a buyer to his seller (s) Posted.

In response, the seller can either: a two-way course (demand and supply) in response to that RFQ deliver - this only if an amount has been specified in the RFQ; a one-way course (Demand and Supply) in response to the RFQ - this only if an amount was specified in the RFQ; a course for one deliver certain amount in response to the RFQ; or specify that he doesn't want deliver a course, i.e. there is no business.

The buyer receives a course. As answer he can either: indicate that he wishes to buy and confirm that Business; state that he wishes to sell and confirmed the business; the shop B void if that of the buyer don't like the course.

The deal is now closed.

The system recognizes the stage at which a deal is within the deal and looks for specific phrases that correspond to the particular stage of the deal. If there is currently no business in progress in a chat field, the system monitors the chat field according to a course request. The following terms are searched, which indicate that a course request was initiated within a chat field dialog:
an indication of the instrument type (currency outright)
an indication of a currency pair
an indication of an amount
an indication of the currency of the amount
an indication of a duration / date of the appointment

A course request should include at least the following:
an indication of the currency pair
an indication of the type of instrument
an indication of a duration / date of the appointment

Some examples of a course request:
Hello, Outright 3 months CDF please (hihi Outrite 3m CHF pls} - The buyer requests an offer for a currency spot for USD / CHF, which is due in three months
Hello, Outright CHF 10 million 6 months please (hi Out 10 billion CHF 6m pls) - The buyer is requesting an offer for a foreign exchange spot in USD / CHF for USD 10 million, which is due in six months
Hello, Outright GBP / USD maturity date 5 Jan 01) (Hi cable cable in 10 maturity 5 Jan 01 pls - The buyer is requesting an offer for a currency outright in GBP / USD for GBP 10 million January 2001 is due
Hello, Outright GBP / EUR 1 year please (Hi frd Outrite GBP / EUR 1yr pls) - The buyer requests a quote for a currency outright in GBP / EUR that is due after one year.

The system parses all variables that were specified as part of an RFQ from the dialog in the corresponding field in the business batch. When the system has identified a course request and the RFQ has been sent to the seller, it monitors the chat box for details of a response to the course request.

The following terms within the chat field that indicate an answer to the course request are searched:
Indication of a demand rate
Specification of an offer price
Offering a refusal to offer
an indication of an amount

A response to a course request includes an amount (if not provided in the RFQ) along with at least one of the following:
a demand course
an offer rate OR
to offer a refusal

Some examples of an answer to a course request:
1.4301 / 08 - The seller delivers a two way rate, demand / offer
4696/4700 - The seller delivers a two way rate, demand / offer
0.87563-62 - The seller delivers a two way rate, demand / offer
[106.70 90 cash 107.00 03 - the seller delivers a two-way rate, demand / offer, and cash split, 107, 00/107, 03]
Nothing - the seller refuses to offer

All from the seller in response to a course request specified variables are from the dialog in the appropriate fields in the business stack parsed. A refusal to offer is stated when the seller gives his Intent in the chat box or the seller the business in the business stack aborts.

If the seller refuses to offer, the system concludes that the deal has been canceled and the monitoring process is restarted, after a course request within the dialog is sought.

The system ensures that the following dialog variables have been parsed into the business stack before the buyer is allowed to indicate his intention to buy or sell:
an indication of a duration / date
the currency pair
the amount
the currency of the amount
a demand course and / or an offer course

If all of the above variables in the business batch have not been successfully parsed, the system requests that the seller enter the missing variables before indicating his intention to send. When the system has identified a response to a course request and the response has been sent to the buyer, it monitors the chat box for a response to the offer. The following terms are searched within the chat field, which indicate a response to the offer:
to buy an indication
sell an indication
an indication of a termination of the transaction

A response to an offer includes at least one of the following:
to buy an indication
sell an indication
an indication of a termination of the transaction

Some examples of a course request:
OK, I buy - The buyer is happy with the price and agrees to buy at an offer price
Nothing, thanks (Nothing thks) - the buyer does not like the course and does not wish to act

The business will be abandoned specified when the buyer enter his intention to cancel (he doesn't like the price), or the buyer the business in the business stack aborts. If the buyer the business aborts, the system restarts its monitoring process and looks for a course request within the dialog. If that System identifies a response to an offer, confirms that System the business in the business stack and starts his surveillance process again, looking for a course request within the dialog becomes.

As part of a quote request, the system requires the user to enter some of the following terms to indicate that the transaction is a currency outright transaction:
Outright
Outrite
Out
O / r

As part of the quote request, the system requires the user to specify a currency pair. For example:
Outright 6m Stg pls = foreign exchange outright 6 months for GBP / USD
Out 3m EUR pls = foreign exchange outright, 3 months for EUR / USD
O / r 23/01 Eur in 10 pls = foreign exchange outright for EUR / USD, amount is EUR 10 million, maturity is 23/01/01
Outright 9mth CHF for 20 = foreign exchange outright, 9 months for USD / CHF, amount is USD 20 million

The user is allowed to specify a currency amount to buy or sell, for example:
Outrite 10 million GBP against USD 6m pls = GBP / USD, 10 million GBP, 6 months duration
Outrite Eur pls, 10 million US 6m = EUR / USD, 10 million USD, 6 months duration

If the user does not specify the currency of the amount specifically, the system interprets the amount to display the amount in the base currency of the currency pair, for example:
Out eur 10mio 3m pls = EUR / USD 10 million EUR, 3 months
Out chf for 10 months, 20 million = USD / CHF, 10 months, 20 million USD
50 million welly out pls, 3m = NZD / USD, 50 million NZD, 3 months

The system requires the user a duration for the business as part of the course request.

The system has to allow the user to express a due date (the terms "value date" or "due date" can be used) rather than a duration as part of the course request. The seller can enter the forward demand rate directly to show the demand rate for a currency outright. The seller can specify the forward sale rate directly to show the exchange rate for a currency outright. The user can only enter the large number once as part of the first part of the offer, be it demand or offer. For example:
1.4567 / 70 → demand rate = 1.4567, offer rate = 1.4570
121.43 / 53 → demand rate = 121.43, offer rate = 121.53

The user can enter an offer without the large number, ie only the points of the offer. For example:
67/70 → GBP / USD offer, demand rate = 1.4567, offer rate = 1.4570
43/53 → GBP / JPY offer, demand rate = 121.43, offer rate = 121.53

The system warns the user if a large number is not available. The user can specify their preference to buy the specified currency amount on the due date using the following terms:
Buy
Mine (mine)
M (M)
B (K)
Take
T (N)
At [Bid Price]
[Bid price]

The user can specify their preference to sell the specified currency amount on the due date using the following terms:
Sell
Yours
Y (I)
S (V)
Give
G (G)
At [Bid Price]
[Bid price]

The system allows the buyer to indicate his intention to buy or sell. For example:
I sell CHF (user sell CHF) = user sells previously specified amount of CHF
J (Y) = user sells pre-specified amount of pre-specified currency.

FORWARD EXCHANGE-PARSE

Business Use Case The following is a description of the procedure to be followed to conclude a forward exchange transaction.

A forward exchange request for an offer is from a buyer sent to his / her seller (s).

In response, the seller can either: deliver a two-way course in response to the RFQ - this only, if an amount was specified in the RFQ; a one-way course as an answer deliver to the RFQ - this only, if an amount was specified in the RFQ; an offer for one deliver certain amount in response to the RFQ; or specify that he doesn't want deliver an offer, in which case there is no business.

The buyer (shopper) receives one Offer. In response, he can either: indicate that he is approaching Want to buy an appointment / sell at a distant appointment and confirm the transaction; specify, that he wants to buy / sell on the near date and the business to confirm; or the business B cancel by the buyer don't like the offer.

The seller (seller of the business) receives one Notification of buyer intent. In response, he has to to deliver a spot rate.

The buyer receives the spot rate. As answer he can either: the business to confirm; or query the spot rate.

When the buyer queries the spot rate, receives the seller a notification of the request. In response, he can either: deliver a new spot rate or void the deal if the buyer is using not happy with any other course is.

The buyer receives the new spot rate. As Answer can either: confirm the deal; the spot rate again Requests; or the business void if the buyer not happy is that he'll ever get a satisfactory deal will (only available if it has already been queried).

Once the buyer has confirmed the deal it now completed.

The system recognizes the stage at which a business is within the business process and searches for specific phrases that relate to the particular stage of the business process. If there is currently no business in progress in a chat field, the system monitors the chat field for information about a course request. The system searches for the following terms, which indicate that a course request was initiated within a chat field dialog:
an indication of the instrument type (currency date)
an indication of a currency pair
an indication of an amount for the near period
an indication of an amount for the distant period of time
an indication of the currency of the amounts
an indication of a duration / date for the value date
an indication of a duration / date for the due date

A course request should include at least the following:
an indication of the currency pair
an indication of the type of instrument
an indication of a duration / date

Some examples of a course request are as follows:
Hello, date 3 months CHF please (hihi Fwd 3m CHF pls) - The buyer requests a rate for a forward exchange transaction in USD / CHF for 10 million USD cash next (value date is cash date, due date is the day after the cash date)
Hello, swap CHF 10 million please (Hi Swap CHF 10 million s / n pls) - The buyer requests a rate for a forward exchange transaction in USD / CHF for USD 10 million cash next (value date is cash date, due date is the day after the cash date )
Hello, GBP / USD 10 million due date Jan 5, 2001, please (Hihi Forward cable in 10 maturity Jan 5, pls) - The buyer is requesting an offer for a forward exchange transaction in GBP / USD for GBP 10 million / value on the cash date, the due on Jan 5, 2001
Hello, appointment date GBP / EUR due date 1 year (Hi frd Fwd-Fwd GBP / EUR 6 months v 1yr pls) - The buyer requests an offer for a forward exchange transaction in GBP / EUR, value date in 6 months, due date after expiry of a year
Hello, swap CHF, 6 months 10 million for the close date 10 500 000 (Hi swp CHF, 6 mths 10mio at near end 10,500,000 at far) - the buyer requests an offer for a USD / CHF forward exchange transaction, USD 10 million, exchanged for Spot date, and $ 10,500,000 due date (6 months)

The system parses all variables that are specified as part of an RFQ from the dialog into the appropriate field in the business stack. When the system has identified a course request and the RFQ has been sent to the seller, it monitors the chat box for a response to the course request. The system searches for the following terms within the chat field that respond to the course request specify ge:
Specification of a spot demand rate
Specification of a spot offer rate
Specification of a date listing for value date
Offering a refusal to offer
An indication of an amount

A response to a course request includes an amount (if not provided in the RFQ) along with at least one of the following:
a demand course
an offer course
OR
to offer a refusal

Some examples of an answer to a course request:
60/56 - The seller delivers a two way rate, demand / offer
4696/4700 - The seller delivers a two way rate, demand / offer
38/30 - The seller delivers a two way rate, demand / offer
56-60 to 10 (56-60 up to) - The seller delivers a two-way rate, demand / offer, and an indication of an amount, 10 million, that "up to" is ignored by the system.
Nothing - the seller refuses to offer

The system parses all variables that the seller specifies in response to a quote request from the dialog into the appropriate fields in the business stack. A refusal to offer is indicated when the seller enters their intent in the chat box or the seller abandons the deal in the deal stack. If the seller refuses to offer, the system concludes that the deal has been declared invalid. If the seller refuses to offer, the system restarts the monitoring process and searches for a course request within the dialog. The system ensures that the following variables from the dialog are parsed into the business stack before the buyer is allowed to indicate his intention to buy or sell:
an indication of a duration / date of the appointment
the currency pair
a near amount
a further amount
the currency of the amount
a demand and / or an offer

If not all of the above variables successful in the business stack were parsed, the system requires that the seller enters missing variables before indicating its intention to send. When the system identifies a response to a course request has and the answer to the buyer was sent, monitored the system uses the chat box after a response to the course.

The system searches for the following terms within the chat field that indicate a response to the course:
an indication to buy / sell (base currency) at the LHS (left) price
an indication of sell / buy (base currency) at the RHS (right) price
an indication to buy / sell (foreign currency) at the RNS price
an indication of sell / buy (foreign currency) at the LHS price
an indication of a termination of the transaction

An answer to a course should include at least one of the following:
An indication to buy / sell
An indication to sell / buy
An indication of a termination of the deal

Some examples of a course request:
OK, I buy / sell (Ok, 1 buy / sell) - The buyer is happy with the exchange rate and agrees to buy local currency at the spot date and sell local currency at maturity at the RHS price
OK, I v / k (Ok, 1 s / b) - The buyer is happy with the offer and agrees to sell the local currency at the cash date and buy the local currency at the LHS price when it is due
Nothing, thanks (Nothing thks) - the buyer does not like the course and does not wish to act

Termination of the deal is indicated when the buyer enters his intention to cancel (he doesn't like the price) or the buyer abandons the deal in the deal stack. If the buyer cancels the deal, the system restarts the monitoring process and looks for a course request within the dialog. When the system has identified a course request and the response to the offer has been sent to the seller, the system monitors the chat field after providing a Kas sakurses. The system searches for the following terms within the chat field, which indicate the provision of a spot rate:
a provision of a spot rate
an indication of a termination of the transaction (only
if the spot rate has already been queried)

Some examples of how to provide a spot rate:
1.4350 B - the seller agrees to use a spot rate of 1, 435.

If the system is a deployment has identified a spot rate and sent the rate to the buyer the system has the chat field for a response to the spot rate to monitor.

The system searches for the following terms within the chat field that indicate a response to the spot rate:
an indication of the business confirmation
an indication of the request for the spot rate
an indication of a termination of the transaction (only
if at least one course has been provided beforehand)

Some examples of a query of the spot rate are as follows:
Check spot (check spot) - crowded minimal request
Check spot appears high (qualified spot)

The system must return the entire line that includes the request for the spot rate and use it as the text in a spot rate request warning to the seller:
Some examples of a business confirmation are:
OK - confirmation, business is closed
Confirm - confirmation, business is closed
Done B - confirmation, deal is closed

If the seller does business inside of the dialogue confirmed approved the system stores the related business entry within the business stack. An abandonment of business is specified when the seller enters his intention to cancel (he doesn't like something) or the Seller the business in the business stack aborts. If the seller or buyer the business aborts, the system restarts its monitoring process and look for a course request within the dialog. Once the buyer the business approved has confirmed the system the business in the business stack and starts his surveillance process again and looks for a course request within the dialog.

As part of a quote request, the system requires the user to enter one of the following terms to indicate that the transaction is a forward exchange transaction.
Swap
Swp
Fwd (appointment)
Forward
Fwd-fwd (appointment appointment)
Fwd fwd (appointment appointment)
Fwdfwd (appointment appointment)
Fwd / fwd (appointment / appointment)

As part of the quote request, the system requires the user to specify a currency pair. For example:
Swap 6m Stg pls = 6 month foreign exchange for GBP / USD
Swp 3m EUR pls = foreign exchange date, 3 months for EUR / USD
Fwd 23/01 EUR in 10 pls = foreign exchange date for EUR / USD, amount is EUR 10 million, maturity is 23/01/01
Forward 9mth CHF for 20 = currency date, 9 months for USD / CHF, amount is 20 million USD

The system allows the user to specify an amount of a currency to buy or sell, for example:
Swp 10m GBP against USD 6m pls = GBP / USD, 10m GBP, 6 months duration
Swap Eur pls, 10 million USD 6m = EUR / USD, 10 million USD, 6 months duration

If the user does not specify the currency of the amount specifically, the system interprets the amount to display the amount in the base currency of the currency pair. For example:
Out eur 10mio 3m pls = EUR / USD 10 million Eur, 3 months
Out chf for 10 months, 20 million = USD / CHF, 10 months, 20 million USD
50 million welly out pls, 3m = NZD / USD, 50 million NZD, 3 months

The system enables the user to enter a second amount to represent the far end of the amount (due date) of the forward exchange transaction. The system enables the user to specify the amount at the far end of the forward exchange transaction in the following formats:
[Amount] at the far end / section
shared amount (far end / section) [amount]
[Amount] shared amount (far end / section)
Cock amount (at the far end / section) [amount]
[Amount] Interim amount (at the far end / section

The system allows the user a duration for the business as part of the course request, and enables the user, a due date instead of expressing the duration as part of the course request. The User can express a period of time to show the value, and can express an appointment to represent the value date instead of a time span. The user can enter points to indicate the demand rate for a forward exchange and the Offer price for a forward exchange transaction display. If the user is both a demand and a The offer price in points, the system interprets the first Value (to the left) of the two offers as demand rate and parsing him, and interprets the second value (to the right) of the two Offer as the offer price and parses it. In this case, if the demand rate is higher than the offer price and the value date before the cash date (e.g. tomorrow), the system closes the demand rate points (to the left) the spot demand rate to calculate the forward demand rates. This rate represents the rate at which they display the base currency Buy the forward foreign exchange transaction in the first section (near date). In this situation, the forward rate for the currency pair is less than that close course. If the demand rate is higher than the offer rate and the value before the cash date is (e.g. tomorrow), that adds up System the sales offer points (on the right) at the spot offer price, in order to calculate the offer rate. This course represents the course to which they are the base currency sell on the first section (near date) of the forward exchange transaction. In this situation, the forward rate for the currency pair is less than that close course. If the demand rate is higher than the offer rate and the due date after the cash date, (e.g. a week), the system subtracts the demand rate points (to the left) from the spot demand rate, to calculate the forward demand rate. This course represents the Rate at which it is the base currency sell on the second section (also called forward) of the forward exchange transaction. In this situation, the forward rate for the currency pair is less than that close course. If the demand rate is higher than the offer rate and the due date before the cash date (e.g. tomorrow), the system subtracts the Offer price points (to the right) from the spot offer price at the Calculate the forward offer rate. This course will represent the course to which they are the base currency on the second section (further term) of the forward exchange transaction. In this situation, the forward rate for the currency pair is less than that close course.

If the demand rate is lower than the offer price and the value date before the cash date (e.g. tomorrow), the system must set the demand rate points (to the left) subtract from the spot demand rate to the forward demand rate to calculate. This rate represents the rate at which they display the base currency Buy the first section (near date) of the forward exchange transaction. In this situation, the forward rate for the currency pair is greater than the close course.

If the demand rate is lower than the offer price and the value date before the cash date (e.g. tomorrow), the system subtracts the offer price points (for right) from the spot offer rate to the forward offer rate to calculate. This rate represents the rate at which you base the currency on the Buy the first section (near date) of the forward exchange transaction. In this situation, the forward rate for the currency pair is greater than the close course.

If the demand rate is lower than the offer price and the due date after the cash date (e.g. a week), the system adds the Demand rate points (to the left) to the spot demand rate at the Calculate the forward demand rate. This course represents the course to which they are the base currency sell on the second section (also called forward) of the forward exchange transaction. In this situation, the forward rate for the currency pair is greater than the close course.

If the demand rate is higher than the offer price and the due date before the cash date (e.g. tomorrow), the system adds up the offer price points (to the right) to the spot offer rate to the futures quote rate to calculate. This rate represents the rate at which they display the base currency Buy the second section (also called forward) of the forward exchange transaction. In this situation, the forward rate for the currency pair is greater than the close course.

The user can take a spot demand course in association with the forward exchange transaction enter to represent the spot demand rate and can be a spot quote rate in association with the forward exchange transaction Enter to show the spot bid rate. If the user no cash demand course in combination with the forward exchange transaction the system uses the spot market middle rate of the certain currency pair, to show the spot demand rate. If the user does not have a spot demand course in association with the forward exchange transaction the system uses the spot market middle rate of the certain currency pairs, to show the spot offer rate.

If neither of the two sections of the exchange fall on the cash date, the system enables the user to a value request price in connection with the forward exchange transaction and a value offer price in association with the forward exchange transaction enter.

The user can or enter the forward quote rate directly to show the demand rate for a forward exchange transaction.

If the user by means of the scheduled courses offers, the system has the first one (on the left) as the demand rate and the second of the courses (on the right) as the offer rate interpret.

The user can indicate his preference to buy the specified currency amount on the near date and sell the specified currency amount on the remote date using the following terms:
buy / sell
buy sell
b / s (k / v)
bs (kv)
I buy [amount] [currency] on [value date] (I buy [amount] [currency] on [value date]

The user can specify his preference to sell the specified currency amount on the near date and sell the specified currency amount on the remote date using the following terms:
sell / buy
sell buy
sell & buy
s / b (v / k)
sb (vk)
I sell [amount] [currency] on [value date]
(I am selling [Amount] [Currency] on [Value Date]

The user can indicate his intention to buy / sell or sell / buy. For example:
I sell / buy CHF ( I sell / buy CHF) = user
sold buys previously specified amount of CHF
v / k (s / b) = user sells / buys beforehand
specified amount in previously specified currency

In the case of a forward exchange deal where the buyer sells / buys, the system enables the seller to confirm the deal with the following additional terms:
buy / sell
buy sell
buy & sell
b / s (k / v)
bs (kv)

In the case of a forward exchange transaction, at which the seller provides a spot rate that makes it possible System to the seller, the course without the big one Deliver number. The system warns the user if there is no available market rate of which the big one Number is to be derived.

It is obvious from the above that the invention provides the user with a highly advantageous interface provides at the the business stack is presented to the user in a manner that is straightforward from the dealer is to be interpreted that often absorb a lot of information in a very short period of time got to. By separating the information common to all instruments is of information for a business is specific to any particular instrument, it is possible to have one business list showcase, which is simple and easy to look at. However, since the business details field Contains information, which relate to a selected one business relates, the dealer never left without essential information related to the business, he's working on.

If on the system described is traded, the dealer has the choice, business information through dialog chat parsed by the system or directly preferably using buttons on the user interface or keyboard-driven menus. The dealer can be between the two during the course of a business switch. This flexibility is possible, because the entered business related Information whether it is parsed dialog or direct input, only the business stack indicates that there is a change of business condition has given. All other business related activities are from the business stack carried out and include sending necessary messages to the rest of the system, for example to another dealer terminal or billing systems to deal cards to create. The business stack is also for change this the functionality of the buttons on the button bar and the keyboard menus responsible, which are all dependent on the business condition.

It should be noted from the above that the activity of the parser in the business process is limited to detecting changes in the business state. This enables the system to be more flexible. This is in contrast to prior art systems that work through a fixed exchange of dialog-oriented messages, by a trader moving the cursor to a dialog at any time can "own". With the system described, each partner can enter dialogues into the system at any time. However, if the dialog does not include terms with which the parser is preprogrammed to recognize a business in this business state, the dialog will not affect the business process. This means that the dialogue does not have to go from one partner to the other. At any stage in the business process, the last partner to send a dialog-based message can send another message. If it contains no content related to the business in its current state, the parser ignores it and does not affect the business.

Many modifications to that described Systems are possible within the scope of the invention. In particular the invention is neither on any type of instruments nor to some type of trading system architecture over the Limits of the attached here Expectations limited beyond.

Summary

The invention relates to a dialog-oriented business system for trading instruments between contractual partners with:
a plurality of dealer terminals, each having a user interface for entering and displaying to a dealer of dialog-oriented messages with business-related information, the dealer terminals communicating with one another via a communication network, the dealer terminals each further comprising a parser for parsing the entered dialog-oriented messages, wherein the parser includes:
Means for analyzing the dialog-oriented messages to detect a state of a store, the store having a plurality of possible states;
Means for analyzing the dialog messages to collect business related information regarding the captured status of the business; and
Means for returning a parsed message comprising the business status and business related information to the user interface.

The invention also relates to a corresponding dealer terminal for a dialog-oriented business system and a corresponding method and a computer-readable spoke medium with corresponding computer-executable software.
( 1 )

Claims (74)

Dialog-oriented business system for trading instruments between contractual partners with: a number of dealer terminals, which each have a user interface for entering and displaying to a dealer display dialog-oriented messages with business-related information, where the dealer terminals with each other about a communication network communicate, the dealer terminals each also a parser for include parsing the entered dialog-oriented messages, the parser includes: Means for analyzing the dialog-oriented Messages to capture a state of a business, the business a variety of possible states having; Means for analyzing dialog-oriented messages, to business related Information regarding the recorded state of the business capture; and Means for returning a parsed message, the the business condition and the business-related Information includes, to the user interface. Dialog-oriented business system according to claim 1, where the parser completed dialog-oriented messages parsing provided by the user interface. Dialog-oriented business system according to claim 1, where the parser means to monitor everything from the user interface received dialog-oriented messages includes a new one Business without consideration on the business condition of a current business to identify. Dialog-oriented business system according to claim 3, in which the user interface means for initiating a new dialogues between contracting parties with at least one existing one Dialogue shows when the new business is identified. Dialog-oriented business system according to claim 3, where the parser monitors the dialog-oriented messages, to identify a course request (RFQ). Dialog-oriented business system according to claim 1 where the possible Business conditions no business pending, course request, Offer and buy / sell include. Dialog-oriented business system according to claim 1, where the means of return of the parsed messages is a means of returning a business information structure to the user interface. Dialog-oriented business system according to claim 1, in which the user interface receives one received from the parser indicates parsed message and means to accept or reject the parsed message before communicating the parsed message to a contractual partner. Dialog-oriented business system according to claim 8, in which the user interface further includes a means for editing the parsed message before communicating with a contract partner includes. Dialog-oriented business system according to claim 8, where the means to accept or reject the parsed message at least one button on the user interface display comprises by a pointing device is operable. Dialog-oriented business system according to claim 9, in which the means for editing the parsed message at least a button on the user interface display, which is indicated by a Pointing device is operable. Dialog-oriented business system according to claim 1, also with a business server, being the business server acts to an admissibility check the parsed message from a first contract partner, and the parsed message without notifying another contract partner rejects if the parsed message is invalid. Dialog-oriented business system according to claim 1, also with a chat server to handle a non-business related Dialog, in which a dialog-oriented message, in which the parser no business related Information captured, sent to a target dealer via the chat server becomes. Dialog-oriented business system according to claim 1, where the parser to the dealer terminal is downloaded when the dealer terminal is in the dialog-oriented business system logs. Dialog-oriented business system according to claim 14, in which the parser is an applet. A trader terminal for a dialog-oriented business system with a plurality of dealer terminals that with each other about a communication network, the dealer terminal includes: a user interface for input and display to a dealer business-related containing dialog-oriented messages Information; and a parser for parsing the entered dialog-oriented messages; the parser includes: medium to analyze the dialog-oriented messages to a state of a business to capture, the business a variety of possible states having; Means for analyzing dialog-oriented messages, to business related Information regarding the captured state of the business capture; and Means for forming and returning to the user interface a parsed message that shows the business condition and the business-related Information includes. A trader terminal according to claim 16, where the parser completed dialog-oriented messages parsing provided by the user interface. A trader terminal according to claim 16, where the parser means to monitor everything from the user interface received dialog-oriented messages includes a new one business regardless of the business condition of a current business to identify. A trader terminal according to claim 18, wherein the user interface means for initiating a new dialogues between contracting parties with at least one existing one Dialogue shows when the new business is identified. A trader terminal according to claim 18, in which the parser monitors the dialog-oriented messages, to identify a course request (RFQ). A trader terminal according to claim 16, where the possible Business conditions no business pending, Include course request, offer and buy / sell. A trader terminal according to claim 16, where the means of return the parsed messages means for returning a business information structure to the user interface. A trader terminal according to claim 16, in which the user interface receives one received from the parser indicates parsed message and means to accept or reject the parsed message before communicating the parsed message to a contractual partner. A trader terminal according to claim 23, in which the user interface further means for editing the parsed message before communication to a contractual partner includes. A trader terminal according to claim 23, where the means to accept or reject the parsed messages at least one button on the user interface display by a pointing device is operable. A trader terminal according to claim 24, in which the means for editing the parsed message at least a button on the user interface display by a pointing device is operable. A trader terminal according to claim 16, also with a business server, with the business server acting an admissibility check the parsed message from a first contract partner and for the parsed message without notifying another contract partner rejected if the parsed message is invalid. A trader terminal according to claim 16, further comprising a chat server for handling a non-business related Dialog, being a dialog-oriented message in which the parser business-related information recorded to a target dealer via the Chat server is sent. A trader terminal according to claim 16, where the parser to the dealer terminal downloaded when the dealer terminal is in the dealer terminal logs. A trader terminal according to claim 29, in which the parser is an applet. Procedure for trading instruments between Contractual partners in a dialog-oriented trading system in which the contracting parties with each other communicate a communication network, the method following Steps comprises: Enter dialog-oriented messages containing business related Information in the system; Analyze the dialog-oriented Messages to capture a state of a business, the business a variety of possible states having; Capture business-related Information for the recorded status of the business are relevant; and Forming a parsed message containing the business condition and at least part of the business related information. Method according to claim 31, in which the dialog-oriented messages from a user interface to be provided. Method according to claim 31, further with a parsing of all received dialog-oriented News to start a new business regardless on the business condition of a current business to identify. Method according to claim 33, further with initiating a new dialogue between contracting parties with at least one existing dialogue when the new business identifies becomes. Method according to claim 33, also with surveillance the dialog-oriented messages to a course request (RFQ) identify. Method according to claim 31, where the possible Business conditions no business pending, course request, Price includes and buy / sell. Method according to claim 31, further with a return the business-related Information to a user interface. Method according to claim 31, also with: Display the parsed message; and it to enable one of the contractual partners the parsed message before communicating the parsed message to accept or reject the other contractual partner. Method according to claim 38, further allowing the first partner to send the parsed message before communicating the parsed message to the other party to edit. Method according to claim 31, with a check an admissibility the parsed message from a first contract partner; and reject the parsed message without notifying another contractual partner, if the parsed message is invalid. Method according to claim 40, where testing an examination includes whether the contractor has a sufficient bilateral Credit for a proposed deal in the parsed message. Method according to claim 40, where testing an examination includes that business related information with business rules of the dialog-oriented business system matches. Method according to claim 31, further with sending dialog-oriented messages without business-related Information to one of the contracting parties via a chat server. Method according to claim 31, when insufficient when detecting a change in state business-related Information relevant to the condition is captured, an error message is sent to a user interface. Method according to claim 44, where the error message is displayed in an area of the user interface that is firmly assigned to the business in progress. Method according to claim 45, where the error message identifies missing business related information. Dialog-oriented business system according to claim 3, where the business related Information about the current business includes a first course request; and identified the new business is when the parser detects a second course request. Dialog-oriented business system according to claim 18 where the business related Information about the current business includes a first course request; and identified the new business is when the parser detects a second course request. Dialog-oriented business system according to claim 33 where the business related Information about the current business includes a first course request; and identified the new business is when the parser detects a second course request. Dialog-oriented business system according to claim 1, where the parser does not record the past message reserves. Dialog-oriented business system according to claim 16, in which the parser does not record the past message reserves. Dialog-oriented business system according to claim 31, in which the parser does not record the past message reserves. Dialog-oriented business system for trading instruments between contractual partners with: a plurality of dealer terminals, each with a user interface for entering and displaying on an ei NEN dealers of dialog-oriented messages contain business-related information, the dealer terminals communicate with one another via a communication network, the dialog-oriented messages being displayed in a color-coded form in order to indicate to the user an origin of the dialog-oriented messages. Dialog-oriented business system according to claim 53, where the from a dealer terminal of a contract partner received messages in a first color and messages generated at the user interface in a second Color. Dialog-oriented business system according to claim 54, at which each dealer terminal a parser for has parsing of messages entered into the terminal, to business related Extract information and generate parsed messages, where the parsed messages are displayed in a third color become. Dialog-oriented business system according to claim 54, in which alarm messages are displayed in a fourth color. Dialog-oriented business system according to claim 54, in which error messages are displayed in a fourth color. Dialog-oriented business system for trading instruments between traders, the system comprising: a number of dealer terminals, which are coupled together to form a network, with each dealer terminal has a user interface and a parser; in which the User interface containing dialog-oriented messages business-related Information related to business between traders relates, receives and displays; and the parser the dialog-oriented messages analyzed to a state of a current business between dealers to capture, with the parser also the dialog-oriented messages analyzed to the business related Information regarding the state of the current business to capture, and the parser containing a parsed message the state of the current business and generates at least part of the business related information. System according to claim 58, where the parser starts a new business regardless of the state of the current business identified. System according to claim 59, where: the business-related Information about the current business includes a first course request; and identified the new business is when the parser detects a second course request. System according to claim 59, in which the user interface has a second dialog between dealers initiated with an initial dialogue when the new business identified becomes. System according to claim 58, where the parser displays the parsed message to a merchant and the dealer allows edit the parsed message before the parsed message to another dealer is sent. System according to claim 58, where the parser displays the parsed message to a merchant and the dealer allows refuse to send the parsed message to another dealer send. System according to claim 58, also with: a business server, the one with the dealer terminals is paired with the business server receives the parsed message from the parser and based on the current one Condition of the current business determines whether the parsed message is acceptable; and if the business server determines that the parsed message is unacceptable to the business server does not send the parsed message to another dealer terminal. System according to claim 58, also with: a chat server that works with the dealer terminals is coupled; in which the parser the dialog-oriented messages sends to the chat server when there is no business related information in the dialog-oriented messages. System according to claim 58, in which the parser is downloaded to a respective dealer terminal, if the respective dealer terminal accesses the system. System according to claim 66, in which the parser is an applet. Computer-readable storage medium with computer-executable Software to perform of the following steps: Receive dialog-oriented messages containing business related Information; Analyzing the dialog-oriented messages, a state of a business between traders capture; Analyzing the dialog-oriented messages, to business related Information regarding the state of the business capture; and Generating a parsed message containing the business condition and at least part of the business related information. The storage medium of claim 68, wherein the Software also the step of identifying a new business without consideration on the state of the current business. The storage medium of claim 69, wherein: the business-related Information about the current business includes a first course request; and the new business at Capturing a second course request is identified. The storage medium of claim 69, wherein the Software also the step of initiating a second dialog between traders with a first dialogue, if the new business is identified. The storage medium of claim 68, wherein the Software further steps to display the parsed message to a merchant and the dealer to allow edit the parsed message before the parsed message to another dealer is sent. The storage medium of claim 68, wherein the Software further steps to display the parsed message to a merchant and the dealer to allow refusing to send the parsed message to another dealer send, performs. The storage medium of claim 68, wherein the Software also performs the following steps: Determine if the parsed message is acceptable based on the current state current business; and if the parsed message is unacceptable, prevent that the parsed message is sent to another dealer terminal.