Note: Descriptions are shown in the official language in which they were submitted.
CA 02298432 2000-02-11
MARKET TRANSPARENT ELECTRONIC BROKERAGE SYSTEM
FIELD OF INVENTION
The invention generally relates to the field of electronic brokerage or
S transaction systems, and more particularly to systems which provide market
transparency
so as to enable buyer and seller to transact without the need for
intermediaries such as
brokers.
BACKGROUND OF INVENTION
In an open market, price is determined by demand and supply. For market
participants, it is important to know all existing bids and offers in the
market, along with
bid and ask prices and associated quantities. They need this information to
make trading
decisions or to decide whether to participate in the market. Also crucial to
many market
participants trading in commodities with volatile prices are forward price
curves for the
commodities. This information may aid them in managing price risks in
commodities.
Further, participants often wish to know the identity of their counter
parties, their credit-
worthiness, and possibly other information about them such as their geographic
location
or their contact information.
A variety of electronic brokerage systems have been proposed in prior art
which allows users to electronically submit offers to buy or sell financial
instruments or
goods and electronically close transactions. The prior art systems typically
identify and
display on users' viewscreens the best bid and ask prices for a particular
item. Some prior
art systems will automatically match buyer and seller, while in other systems
trades must
be manually executed. In some systems, such as the currency transaction system
in U. S.
Patent No. 5,375,055 issued December 20, 1994 to Togher et al, market
participants may
specify limitations on the amount of credit that they are willing to specify
to counter
parties, such that a participant may not be able to accept any offer to buy or
sell. The
20719707.1
CA 02298432 2000-02-11
-2-
Togher et al system therefore discloses the best "dealable" price for currency
transactions
that a participant may accept.
Conventionally, however, in these systems the market is closed in the sense
that participants may see only the offer with the best eligible price, not all
available offers.
As indicated earlier, knowledge of market depth can be important to
participants in
making a trading decision or to observers in deciding to participate.
Furthermore, other
then restricting trading on the basis of credit limitations, the prior art
does not provide
much flexibility in excluding counter parties based on other criteria, such as
restricting
trade between affiliated companies or competitors.
SUMMARY OF INVENTION
The present invention provides an electronic brokerage or trading system
allowing anyone with communication capability such as Internet access to
participate in
market activities. The system enables an open market to be established where
buyers and
sellers communicate their intention to trade and transact with each other
anonymously.
Each participant, whether a buyer or a seller, needs to be registered with the
system first.
Once they are registered, participants can select their trading counter-
parties, submit offers
to buy or sell, view all offers submitted by other market participants, and
trade with
selected counter-parties. An unregistered user of the system can only view
submitted
offers.
A participant can select other participants whom they are unwilling to trade
with based on pre-determined criteria. They can set up the exclusionary
criteria separately
for offers to buy, offers to sell, or any transactions. This information is
maintained in a
central database, and the system will block any ineligible transaction.
Participants electronically submit offers to buy or sell to the system. The
offers include at least a quantity of a particular financial instrument or
commodities and a
bid or ask price therefor. Where the instrument relates to a futures-based
commodity
contract the offer may also include a period of supply and a delivery date.
The system
20719707.1
CA 02298432 2000-02-11
-3-
processes each submitted offer and stores it in the central database. All
offers, whether
eligible or not, are transmitted to the participants' workstations for
viewing. Offers which
a given participant is ineligible to accept are visually differentiated. The
system does not
reveal the identity of the offeror in order to retain anonymity although the
offerors' credit
rating may be displayed along with the details or attributes of the offer. If
the offers
include a future contract period and delivery date, the system preferably
sorts the offers
into categories based on these characteristics and ranks the offers by price
within each
category for viewing. Offers displayed in this fashion provide participants
with an instant
indication of the shape of forward price curves.
Each participant may decide whether to accept an offer featuring the best
eligible price, or with some other offer which may be more advantageous, such
as
quantity. The system sends confirmation messages to both participants of a
trade and
reveals their identifies to each other after the trade has been executed. The
system will
block a participant from transacting with an offering participant in the event
the
contemplated transaction is ineligible for either party. In such an event,
since the system
enables any participant to access contact information of all counter-parties
who are
unwilling to trade with the participant, it is possible for a participant to
negotiate outside
the system in person with any one of unwilling counter-parties in order to
arrange for a
private transaction.
BRIEF DESCRIPTION OF DRAWINGS
These and other features, aspects, and advantages of the present invention
will become better understood with regard to the following detailed
description of a
preferred embodiment and the accompanying drawings, therefor, wherein:
~ Fig. 1 is a schematic diagram of the architecture of the electronic
transaction
system in accordance with the preferred embodiment, showing market
participants
and public, non-participating observers interacting with a central host
system;
~ Fig. 2 is a schematic diagram of data tables employed by the host system;
20719707.1
CA 02298432 2000-02-11
_4_
~ Figs. 3 and 4 are diagrams of input screens for enabling a system
administrator to
register market participants;
~ Fig. 5 is a diagram of an input screen for enabling participants to select
or exclude
its trading counter-parties;
~ Fig. 6 is a diagram of a display screen enabling users to observe the state
of the
market in summary form;
~ Fig. 7 is a diagram of a display screen for viewing all offers related to a
particular
financial instrument;
~ Fig. 8 is a diagram of an input screen for allowing participants to submit
or modify
offers to buy or sell;
~ Fig. 9 is a flowchart showing the processing carned out by the host system
when
an offer is submitted by a participant;
~ Fig. 10 is a flowchart showing the processing carried out by the host system
when
an offer is accepted by a participant;
~ Fig. 11 is a diagram showing various windows providing information relating
to
the status of a transaction; and
~ Fig. 12 is a schematic diagram of the software architecture of the host
system in
accordance with the preferred embodiment.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to the drawings, the present invention provides an electronic
brokerage system 10 for use in trading conventional financial instruments such
as stocks,
bonds and commodities. The system also enables participants to trade other
types of
intangibles including "quasi-commodities" such as electrical power or
pollution rights
which in some respects resemble the bulk-like nature of commodities and in
other respects
have personal attributes associated therewith as discussed in greater detail
below.
20719707.1
CA 02298432 2000-02-11
_5_
Fig. 1 provides an organizational overview of the system 10 in accordance
with the preferred embodiment. Structurally, the system 10 comprises a central
host
system 14 which includes a server 16 and a central database 18. Users of the
system
employ workstations 20 to communicate with the server 16 over a communications
network 22. A variety of facilities may be used for the communications network
as known
in the art per se including the public telephone system or the Internet.
The system 10 has two types of users, namely market participants 24 and
observers 26. Market participants are individuals or organizations which have
officially
registered with the host system 14 and are entitled to buy and sell financial
instruments
and other intangibles. (The term "commodity" will hereinafter be used to
generically refer
to any of these items). Through their workstations 20, market participants 24
can submit
or review offers to buy and sell commodities and initiate the execution of
transactions.
Observers 26 are individuals which have not registered with the host system 14
or
otherwise cannot be validated thereby. These users cannot trade or otherwise
participate
1 S in market activities but may view market action.
Referring additionally to Fig. 2, an overview of the core of the central
database 18 is shown. This database preferably includes Participant table 30
which lists all
of the registered market participants, their contact information and logon
status. Table 30
also preferably includes, for a given registered participant, information
specifying which of
the other participants the given participant is permitted to trade with or
otherwise is
excluded from trading with. This is discussed in greater detail below.
Participant table 30
is relationally linked to one or more Offer tables 32 used to store all open
offers to buy
and sell different types of commodities and/or different categories of
instruments within a
particular type of commodity. The Offer tables 32 are relationally linked to
the
Transactional log tables 34 which log executed transactions. The Offer tables
32 are also
relationally linked to a Market Summary table 36 which, as explained in
greater detail
below, provides a snapshot of the market as a whole for a group of commodities
or a
group of financial instruments within a particular type of commodity. The
central
20719707.1
CA 02298432 2000-02-11
. , _6_
server 16 accepts buy and sell offers from the workstations 14 for storage in
the central
database 18 and continuously broadcasts the offers stored therein to various
of the
workstations 14. The server 16 also processes trades as described in greater
detail below.
As mentioned, market participants must register with the host system 14 in
order to trade. The registration process is preferably carned out by a system
administrator. Figs. 3 and 4 show input screen forms 40 and 42 displayable on
a
workstation 20 for enabling the system administrator to enter a participant's
registration
information. As shown in Fig. 3, window 40A enables any previously input
participant to
be selected for editing, or alternatively a new participant may be edited
through this screen
form. The fill legal name of the particpant is entered into input field 40C. A
short name
or abbreviation may also be entered, as shown at 40D. Input field 40F is used
to collect
the participant's telephone number. Once this information is submitted, or
otherwise re-
edited if previously submitted, the virtual save button 40G will cause the
participant's
registration information to be stored in the central database 18. If a new
participant is
submitted the system will thereafter generate a unique company ID for internal
identification purposes. This ID is shown in display-only field 40A and cannot
be
changed.
In addition, the sytem administrator preferably assigns each market
participant a credit rating which is entered in input field 40E. This credit
rating may be the
same as that assigned by credit rating agencies such as Standard & Poor's or
Moody's
Investors Service. Alternatively, the system administrator may use some other
credit
ratings developed solely for all participants utilizing the system 10. These
credit ratings
will enable other market participants to decide whether or not they wish to
transact with
the listed participant based on the credit-worthiness thereof.
A market participant may have one or more user accounts allowing one or
more specific individuals to utilize system 10 concurrently. Fig. 4 shows
input screen 42
for setting up a user account from the workstation 20, which may be
established by the
system administrator or by the participant itself. Windows 42A, 42B and 42C
enable
20719707.1
CA 02298432 2000-02-11
-7-
previously input users to be selected for editing or a new user may be entered
by clearing
all fields. Each user account is associated with a unique user ID 42D. The
user's name
and title are entered in input fields 42E and 42F respectively. Each user may
be contacted
in a variety of ways. List box 42I identifies the mode of communication such
as
telephone, e-mail, or facsimile, and field 42J enables the appropriate address
or telephone
number to be entered into the sytem. The virtual save buttons 42H and 42I
respectively
enable the user and contact information to be saved when newly entered or
otherwise
edited. The user account is preferably activated by the system administrator
(internal or
system-wide) by actuating check-box 42G.
Once a given market participant 24 has been officially registered with the
host system 14 the participant may select with whom it is willing to trade
with (hereinafter
referred to as a "counter-party"). Fig. 5 shows an input screen form 44
available at
workstation 20 which enables market particpants to selectively exclude certain
market
participants as counter-parties, and conversely to select active counter-
parties. List
windows 46B and 46S list excluded counter-parties and list windows 48B and 48S
list
active counter-parties. There may be a number of reasons why a market
participant may
not be able or willing to trade with every other market participant. For
example, a
participant may be unwilling to trade with its competitors or be unwilling to
trade over an
anonymous public market with its own subsidiaries or affiliated companies.
Similarly, a
participant may have a preferential price for certain classes of
counterparties but be
unwilling to offer the same price to all market participants. In addition, a
participant may
be unwilling to trade or extend credit to participants having poor credit
ratings. Similarly,
a participant may wish to exclude other participants based on geographical
factors. For
instance, with a quasi-commodity such as electrical power there may not exist
the
necessary transmission lines to deliver power from one participant to another.
Similarly,
with respect to pollution rights, regulatory rules may prevent the transfer of
rights from
one participant to another. In these respects quasi-commodities have personal,
as
opposed to bulk, attributes.
20719707.1
CA 02298432 2000-02-11
r -$-
In the preferred embodiment shown in Fig. 5, all participants are by default
deemed to be active counter-parties but this can be manually changed through
the use of
virtual Add and Exclude buttons 44A and 44B which enable participants to be
moved
between lists 46B and 48B or lists 46S and 48S. Note that in each list the
credit rating of
S other market participants is listed so as to permit the ready selection of
participants based
on credit-worthiness. In addition, through the use of a reverse colour scheme,
a visual
indication is preferably provided to the present participant as to those other
market
participants that have elected not to transact with the present participant.
This feature
may foster private negotiation between parties for deals outside of the public
market.
It should also be noted that in the preferred embodiment separate active
and excluded counter-party lists 46B, 48B and 465, 48S are respectively
maintained for
buy and sell transactions. This allows a participant to select one set of
counter-parties to
sell to and another set of counter-parties to buy from. This feature provides
a number of
advantages. For example, with respect to the illustrated market for electrical
power, a
buyer may not care who supplies the electrical power due to the commodity-like
characteristics of the power. However, as a seller, the participant may be
much more
concerned about a buyer's credit-worthiness. Thus a given participant may
elect to buy
power from a second participant but not to sell power thereto. This feature
provides
additional flexibility into the selection criteria. Those skilled in the art
will understand that
absolute transaction restrictions may be provided in alternative embodiments.
The Expression fields 50A and 50B provide a query language expression or
phrase used by the server 16 to filter or select a subset of counter-parties
that the present
participant may trade with (or not) on a buy or sell transaction. In the
preferred
embodiment the manually selected counter-parties are expressed in the query
language
used by the system 10 in fields 50A and 50B - such as the well-known SQL
structured
query language. However, these expressions may be edited so that each market
participant can set up its own rules, i.e., selection and exclusionary
criteria, to select its
excluded counter-parties. The rules can be based on a number of variables made
available
by the host system 14 to market participants from which logical expressions
can be
20719707.1
CA 02298432 2000-02-11
-9-
constructed. For instance, a participant may set up rules governing
eligibility to transact
based on counter-parties' credit ratings and monetary amounts of transactions.
A rule
may be set up so that a potential counter-party has a credit rating of "A" for
all
transactions of $100,000 and under; a credit rating of "AA" for transactions
of $1,000,000
and under; and a credit rating of "AAA" for transactions of $10,000,000 and
under (and
whereby no single transaction is permitted over $10,000,000). Once the
expression is
entered it is parsed by the server 16 to define excluded counter-parties or
specific offers
made thereby and the results are stored in the central database 18, preferably
in the
Participants file 30. Under this feature of excluding counter-parties, the
identities of
excluded or active counter-parties may not be immediately identifiable,
however, other
screens of the system as will be shortly described provide the participant
with a visual
indication as to whether or not the participant is eligible to transact on a
given offer to buy
or sell.
Fig. 6 shows an interactive "master blotter" screen 60 which is displayable
on workstation 20 and which provides a concise overview of the current market
for a
group of commodities, or a group of financial instruments pertaining to a
particular
commodity as shown here. The example illustrated in Fig. 6 depicts a fixtures-
based
electric power market wherein an offer includes a bid or ask price per unit
and the quantity
of units (e.g., megawatts) being offered for sale or purchase. An offer may
also include a
contract delivery date, as shown. Offers are continually updated by host
system 16 to all
workstations 20 displaying the master blotter screen 60, based on the Market
Summary
table 36 of the central database 18. In addition, other useful information may
be
transmitted and displayed, such as the offering participants' credit rating,
and/or its
geographical location. However, the identity of the offering participant is
concealed in
order to maintain an anonymous trading system.
Offers are grouped into categories. In the illustrated futures-based
example, categories are defined by the power delivery period and contract
start date.
For instance, "Month ahead + 1" means power delivery for the entire next
calendar month.
The master blotter screen 60 shows only the price and size of the last trade
62 and the best
20719707.1
CA 02298432 2000-02-11
- 10-
bid and ask offers 64 and 66 respectively (based on price), for each category
68. However,
by selecting or double clicking on a category 68 shown on the master blotter
screen 60 all
offers present in that category are displayable in an orders screen 70 (shown
in Fig, 7).
The present participant is provided with a visual indication, such as through
the use of a
reverse colour scheme, as to whether it is eligible to accept any given offer
64 or 66
displayed on the master blotter screen 60. This ineligibility may arise due to
the present
participant's counter-party exclusionary selection or due to the exclusionary
selection set
up by the other market participants. The display also uses a particular colour
to display
the offers that the present participant has submitted.
Fig. 7 shows the orders display screen 70 where offers to buy 72 or sell 74
(i.e., bid and ask offers) in a particular category are grouped together and
displayed in
decreasing order from top to bottom based on price. Along with the prices are
shown the
quantity of units such as megawatts available for purchase or sale as well as
the credit
ratings of the offering participant. Again, through the use of a colour
schemes, the display
visually differentiates those offers which the present participant is
ineligible to transact,
and offers which have been tendered by the present participant. The identity
of the other
offering participants is not disclosed in order to retain anonymity. It should
also be noted
that all of the buy and sell offers in the selected category that collectively
define the
market therein are available for display through the order screen. This
provides complete
market transparency to the participant.
The participant can elect to accept any of the offers to buy 72 or sell 74
listed in the orders screen 70 by double clicking on the corresponding row.
This brings up
an order entry screen 80 shown in Fig. 8 in which case fields 82 - 90 thereof
which define
the transaction are filled in. Alternatively, the participant can submit an
entirely new offer
to buy or sell (for the displayed category or for any other category) by
clicking on virtual
buttons 76 and 78 (Fig. 7). In this case, the workstation displays a blank
order entry
screen 80 (Fig. 8) so that input fields 30 through 38 may be filled in by the
participant to
define the new offer. The order entry screen 80 also allows participants to
modify and/or
cancel pre-existing offers submitted by that participant.
20719707.1
CA 02298432 2000-02-11
-11-
Referring now particularly to Fig. 8, input field 82 is designed as a list box
wherein a participant may select one of a pre-determined number of categories
such as the
illustrated electricity supply period. Input field 84 is also a list box which
enables the
participant to select either a buy or sell offer. Input field 86 indicates the
price per unit of
the offer; input field 88 indicates the number of units being offered; and
input field 88
specifies whether partial fills of the offer are acceptable. The screen 80
also comprises
display-only fields including reference field 92 which represents a unique
identification
number for the order automatically assigned by the system; a user
identification field 94
which specifies the user ID of the individual who submitted the order; and a
modification
field 96 representing the user ID of the individual that last modified the
order, if
applicable. Towards the bottom of the screen, a window 98 exists in which all
of the
market activity for the participant that day is displayed. This features aids
in disseminating
information with respect to the market activities of the participant amongst
the various
individual users trading on behalf of the participant. Additionally, another
window 99 is
provided to show the latest transactions for informational purposes. These
windows are
updated in real time.
Fig. 9 illustrates the processing carried out by the central host system 14
when a participant 24A submits (at 100) a new offer or modifies a pre-existing
offer. At a
first step 102 the offer is associated with one of the pre-established
categories 68 and
stored on the appropriate data table of the central database 18. As mentioned,
these
categories may be for different types of commodities or for different
financial instruments
in connection with a particular commodity. In a following step 104, all of the
offers within
the identified category, including the just-submitted offer, are ranked
according to price.
At step 106, the system 14 performs a test to determine if the just-submitted
offer is the
best buy or sell price for the identified category. If so, then at step 108
cell in the Market
Summary table 36 of the central database 18 is updated and the updated
information is
also broadcast over the communications network 22 to each workstation 20
displaying the
master blotter screen 60 so that the appropriate cell, i.e., row and column is
also updated.
If step 108 is unnecessary, then the master blotter screens 60 remain
unchanged.
20719707.1
CA 02298432 2000-02-11
-12-
Nevertheless, the just-submitted offer is stored in the central database 18,
and broadcast
on demand to workstations 20 displaying orders screen 70.
Refernng now to Figs. 7, 8, 10, and 1 l, the processing that occurs when a
participant desires to accept an offer is discussed in Beater detail. As
previously
mentioned, a given participant 24A selects an offer for acceptance by double
clicking on
any of the rows in the orders screen 70 (Fig. 7). This causes the offer to be
displayed on
the order entry screen 80 (Fig. 8) whereby the participant may accept the
offer by clicking
on the commit order button 93. This action corresponds to step 112 of the
flowchart
shown in Fig. 10 and causes a message to be transmitted over the
communications
network to the central server 16. At a first step 114, the server 16 sends a
message back
to the workstation of participant 24A which causes a window 140 (See Fig. 11)
to open
requesting the user to confirm the trade by clicking on virtual confirmation
button. Once
the user elects to proceed with the trade the server 16 at step 116 then
queries the central
database 18 to determine whether or not the participant has accepted an offer
from an
active or non-excluded counterparty. As previously mentioned, a participant
may exclude
other participants through manual selection or by setting up exclusionary
rules. If the
participant making the offer (the "offeror") 24B is an active counterparty to
the accepting
participant 24A then, at step 118 the server 16 queries the central database
18 to
determine if the accepting participant 24A is an active counterparty with
respect to the
offeror 24B. If either of the conditions tested for at steps 116 and 118 are
false, then at
step 120, the server 16 transmits a message to the present participant 24A
indicating that
the trade could not be executed. This causes a window 144 (Fig. 11) to open on
the
workstation associated with participant 24A informing it that the trade could
not be
executed. However, if both of the conditions at steps 116 and 118 are
satisfied, then at
step 122, the server 16 checks to see whether the contemplated transaction
would result in
a partially filled offer. If so, then at step 124, the server 16 checks to see
whether or not
the offeror has permitted partial fills. If not, control passes to step 120
wherein the trade
failure message is transmitted to participant 24A. However, if partial fills
are permitted
then at step 126, the server 16 readjusts the offer by subtracting the number
of units
20719707.1
CA 02298432 2000-02-11
-13-
(e.g. power) just contracted for from the original amount and re-submits the
adjusted offer
back to the appropriate offer table 32. At step 128, the server 16 sends a
trade
acknowledgment message to the offeror 24B and to the accepting participant
24A. This
causes a window 142 (Fig. 11 ) to activate on the workstations of the offeror
24B and
S accepting participant 24A acknowledging a successful trade to each
participant thereof.
Note that at this time each participant is provided with the identity of its
counterparty, as
shown. At step 130, the Market Summary table 36 of the central database 18 is
updated
as required and the server 16 broadcasts an update message to workstations 20
which
currently display the master blotter screen 60 and other system screens
reflecting the
change in the state of the market. At step 132 the server 16 updates the
transaction log
tables 34 of the central database 18.
In the preferred embodiment, the transactional log maintains a history of
trades and can be downloaded by participants or other subscribers of the
system. This
ability can be quite advantageous for participants wishing to manage price
risks. More
particularly, some markets, such as the market for trading pollution rights,
are quite new.
In such markets, it is difficult to determine how price varies with supply and
demand,
especially in a forward market. However, by downloading the historical trade
information,
participants can derive forward price curves to assist in managing price risk.
It should also be noted that the master blotter screen 60 provides an
instantaneous forward price curve. This is because the offers are categorized
and sorted
by contract period and delivery date. A variant of the preferred embodiment
may
alternatively display on the master blotter the best prices associated with
offers having a
minimum threshold on the quantity of commodity offered for sale. This may
assist in
reducing any anomalies that may arise in best prices introduced by small
quantities of
commodities offered for purchase or sale.
One advantage provided by the preferred embodiment in comparison to
other over the counter trading methods, e.g., bi-lateral telephone negotiation
or trading
through a broker, is that the present invention provides price transparency
and
20719707.1
CA 02298432 2000-02-11
- 14-
transparency with respect to the depth of market for any given financial
instrument. This
is because all of the offers of purchase and sale for any given future
contract period are
viewable by participants. This is in marked contrast to traditional financial
exchanges
which are implemented and controlled by intermediaries such as brokers. In
contrast, the
preferred embodiment substantially reduces transaction costs and enables the
natural buyer
and seller, as well as speculators willing to trade risk, to directly interact
in a setting which
provides a level playing field to all participants.
Fig. 12 shows the software architecture of the system 10, which resembles
a client/server architecture. The primary software components of this system
are a server
feeder 150 and client software 154 and 156. System administrators use
administration
client software 154 to monitor the system and to perform administrative tasks.
This
software runs on a workstation associated with the system administrator and
enables the
administrator to access administration screens 40 and 42 for registering
participants with
the system. User client 156 is a program which resides on the workstation of
each market
participant 24. This program preferably comprises a conventional Internet
browser which
enables market participants to view the various user screens shown in Figs. 5 -
8. The
browser is preferably supplied with an applet, which may be downloaded from
the host
system 16, which provides local intelligence for executing database queries
and other local
processing. All communications with the host system 16 are managed by the user
client
are managed by the user client software 156. Non-participating observers 26
will access
the system and view the master blotter screen 60, but as previously mentioned
observers
cannot navigate from this screen to the other display screens of the system.
The server feeder 150 is responsible for managing all submitted offers,
blocking ineligible transactions and executing eligible transactions requested
by market
participants, as discussed above. The server feeder 150 is also responsible
for updating
the central database 18 and sending update messages to all user clients 156.
In the
preferred embodiment, the system employs software to update the screen
displays on
workstations 24 in substantially real time. This software organizes screen
displays as
spread sheets, wherein each cell represents an attribute such as price,
quantity or delivery
20719707.1
CA 02298432 2000-02-11
-15-
date of an offer. When a new offer is submitted or an existing offer is
modified, the server
feeder 150 does not send an entirely new page display to user client software
156.
Instead, the software 152 only sends packets reflecting the incremental change
to effect
certain cells of the currently displayed screens and the user client software
156
dynamically updates only the effected cells. Typical software that has been
used as
SLINGSHOTT"' available from CSK Software or software is also available for
this
function from Microsoft. Those skilled in the art will realize that a variety
of alternative
technologies may be used to provide a means for updating the display screens
on
workstations 24 in substantially real time.
The server feeder 150 sends database queries to an SQL server
software 160 which processes such queries and interfaces with the central
database 18.
Other software components of the system include an e-mail daemon 162 which is
responsible for sending confirmatory e-mail messages to participants for a
variety of
purposes, including confirmation of trade execution. Fax daemon 166 provides a
similar
1 S purpose. The end of day software component 164 generates daily reports
from the market
transaction logs of the central database 18. The end of month software
component 168 is
responsible for back office processing tasks such as sending out invoices to
bill market
participants for a subscription to the system and to realize any commissions
arising out of
the completion of transactions. This component is also responsible for monthly
maintenance and mailing activities. Those skilled in the art will realize that
these software
components may run over a distributed computing platform or be executed by the
same
computer system that runs the server feeder 150.
20719707.1
