Note: Descriptions are shown in the official language in which they were submitted.
Electronic Trading System and Method for Mutual Funds
Field
This disclosure relates to electronic trading systems and related methods.
Background
[00021 Known trading systems for mutual funds are often separate and
distinct from
systems used for other types of financial instruments and interests. This is
due to differing
regulations and differing technologies used. One of the many drawbacks of such
trading
systems is that additional technical knowledge and maintenance are required
from the end
users.
[00031 In an example known equity marketplace, dealers submit orders on
behalf of one or
more retail end-investors through their front-office systems. Positions are
aggregated and
registered at a clearing and settlement service in the name of the dealer. The
dealer's back-
office maintains individual investor's positions and manages entitlements and
tax reporting.
Mutual funds, on the other hand, are typically processed through a separate
fund transaction
processing system, where an individual purchase/redemption instruction is
routed from the
investment advisor on behalf of each end-investor to the fund issuer. As there
is no secondary
trading in mutual funds, all orders are fulfilled directly from the fund
treasury.
[00041 The fund maintains a registry of all beneficial owners and manages
entitlements and
tax reporting. As such, most dealers have separate front-office systems for
managing equities
from managing mutual funds without sufficient integration between the two,
which can make
transacting in mutual funds a very manual and laborious process far a dealer
that mainly works
with equities.
[00051 As such, widespread and efficient electronic trading of mutual funds
is hampered.
1
Date Recue/Date Received 2022-05-13
CA 02922112 2016-02-29
P5523CA00
Summary
[0006] According to one aspect of the present invention, method in an
electronic trading
system includes receiving data messages via a network, the data messages
representative of
orders for mutual funds from market participant terminals. Each data message
contains a
mutual-fund identifier, an indication of a number of units, and a market-
participant identifier.
The method further includes generating pending orders from the data messages.
Each pending
order contains a market-participant identifier extracted from a particular
data message, an
indication of a number of units extracted from the particular data message,
and a mutual fund
manufacturer identifier obtained from a mutual-fund identifier extracted from
the particular
data message. The method further includes accumulating the pending orders for
an
indeterminate amount of time in a batch of accumulated pending orders,
receiving an
indication of price for each of the mutual funds from a respective mutual fund
manufacturer
system, and for each accumulated pending order, calculating a total price
based on a respective
received indication of price and the number of units specified in the
accumulated pending order
to generate a filled order. The method further includes outputting filled
orders to a settlement
and clearing system.
[0007] The method can further include querying a database to obtain a
mutual fund
manufacturer identifier using a mutual-fund identifier as a query key.
[0008] The method can further include generating a pending order from a
received data
message without matching price or time of the received data message with any
booked order.
[0009] Each data message can omit a price.
[0010] The method can further include reporting a market-participant
identifier of a filled
order to a mutual fund manufacturer system identified from the filled order.
[0011] The method can further include receiving other data messages via the
network, the
other data messages representative of other orders for at least one equity
instrument, and
executing trades based on the other orders in parallel to accumulating the
pending orders for
2
CA 02922112 2016-02-29
P5523CA00
the mutual funds, the execution of trades based on the other orders bypassing
the
accumulating.
[0012] The method can further include generating at least one integrated
and
heterogeneous market data feed containing data from the filled orders for the
mutual funds
and containing other data from other filled orders for at least one equity
instrument.
[0013] The method can further include performing an exception process, the
exception
process obtaining a suitable previous indication of price for use as an
unreceived or erroneous
indication of price or cancelling orders for the respective mutual fund.
[0014] According to another aspect of the present invention, an electronic
trading system
includes an order processing engine configured to receive data messages via a
network. The
data messages are representative of orders for mutual funds from market
participant terminals.
Each data message contains a mutual-fund identifier, an indication of a number
of units, and a
market-participant identifier. The order processing engine is further
configured to generate
pending orders. Each pending order contains a market-participant identifier
extracted from a
particular data message, an indication of a number of units extracted from the
particular data
message, and a mutual fund manufacturer identifier obtained from a mutual-fund
identifier
extracted from the particular data message. The system further includes an
order accumulator
coupled to the order processing engine and configured to receive pending
orders from the
order processing engine. The order accumulator is configured to store pending
orders for an
indeterminate amount of time in a batch of accumulated pending orders. The
system further
includes an order resolver coupled to the order accumulator. The order
resolver is configured
to receive an indication of price for each of the mutual funds from a
respective mutual fund
manufacturer system. The order resolver is further configured to fetch
accumulated pending
orders from the order accumulator and, for each accumulated pending order,
calculate a total
price based on a respective received indication of price and the number of
units specified in the
accumulated pending order to generate a filled order. The order resolver is
further configured
to output filled orders to a settlement and clearing system.
3
CA 02922112 2016-02-29
P5523CA00
[0015] The order processing engine can be further configured to query a
database to
obtain a mutual fund manufacturer identifier using a mutual-fund identifier as
a query key.
[0016] The order processing engine can be further configured to generate a
pending order
from a received data message without matching price or time of the received
data message
with any booked order.
[0017] Each data message can omit a price.
[0018] The order resolver can be further configured to report a market-
participant
identifier of a filled order to a mutual fund manufacturer system identified
from the filled
order.
[0019] The order processing engine can be further configured to receive
other data
messages via the network, the other data messages representative of other
orders for at least
one equity instrument. The order processing engine can be further configured
to match the
other orders for execution of trades in parallel to the order accumulator
accumulating the
pending orders for the mutual funds, the execution of trades based on the
other orders
bypassing at least the order accumulator.
[0020] The order resolver can be further configured to output data from the
filled orders
for the mutual funds to a market data system that is configured to generate at
least one
integrated and heterogeneous market data feed containing data from the filled
orders for the
mutual funds and containing other data from other filled orders for at least
one equity
instrument.
[0021] The order resolver can be configured to perform an exception
process, the
exception process obtaining a suitable previous indication of price for use as
an unreceived or
erroneous indication of price or cancelling orders for the respective mutual
fund.
4
CA 02922112 2016-02-29
P5523CA00
=
Brief Description of the Drawings
[0022] The drawings illustrate, by way of example only, embodiments of
the present
disclosure.
[0023] FIG. 1 is a diagram of an overall system.
[0024] FIG. 2 is a flowchart of a method for electronic trading.
[0025] FIG. 3 is a diagram of an electronic trading system.
[0026] FIG. 4 is a diagram of data structures.
[0027] FIG. 5 is a flowchart of an exception process.
[0028] FIG. 6 is a diagram showing relative timing of the method for
electronic trading.
Detailed Description
[0029] The present invention provides an integrated platform for
purchase/redemption of
mutual funds together with trading of other financial instruments, such as
equities. Mutual
fund orders are configured in a manner similar to orders for other financial
instruments, such as
equities, and are identified and processed according to the techniques
described herein. This
advantageously allows one trading system to process mutual funds in addition
to one or more
other financial instruments, despite the significant financial and technical
differences in
processing purchase/redemption of mutual funds. Market data feeds can be
similarly
integrated. In view of the invention, market participants need not maintain
separate and
distinct systems for mutual funds and other financial instruments. Further,
computer
processing and memory efficiencies can be gained by using one system.
[0030] FIG. 1 shows a system according to the present invention. The
system includes one
or more mutual fund manufacturer systems 10, one or more admin terminals 12, a
plurality of
market participant terminals 14, one or more portfolio management systems 16,
one or more
smart order routers and/or order management systems 18, a settlement and
clearing system
20, and an electronic trading system 22, and a market data system 24 mutually
connected via a
CA 02922112 2016-02-29
P5523CA00
network 26. The system can further include other components, such as
electronic message
gateways (not shown) and similar.
[0031] The network 26 can include any number and type of computer networks,
such as a
local area network (LAN), wide-area network (WAN), virtual private network
(VPN), a wireless
network, an intranet, and the Internet. The network 26 operates to
communicatively couple the
components 10¨ 24, while isolating domains of such components 10 ¨ 24 from one
another,
where appropriate, and restricting communications between domains.
[0032] Each of the mutual fund manufacturer systems 10 can include servers,
data stores,
or other types of computers within a mutual fund manufacturer's domain and
under the
control of a mutual fund manufacturer.
[0033] An admin terminal 12 can be connected to a mutual fund manufacturer
system 10
to manage and control the system 10, such as to trigger the transmission of
data from the
mutual fund manufacturer system 10 to the trading system 22.
[0034] The market participant terminals 14 are connected to respective
portfolio
management systems 16, which are configured to place orders initiated by
market participant
terminals 14 via the smart order routers and order management systems 18 for
execution at
the trading system 22. Data messages inbound to the trading system 22
represent orders for
financial instruments and interests by market participants in control of the
terminals 14, such as
dealers and brokers who buy and sell such instruments and interests on behalf
of investors.
Examples of financial instruments and interests are discussed below, and
notably at least
include mutual funds.
[0035] The terminals 12, 14 can be electronic devices, such as desktop
computers, smart
phones, tablet computers, and similar devices that have at least one processor
configured to
execute instructions stored in memory.
[0036] The settlement and clearing system 20 is connected to the trading
system 22 and
receives data indicative of filled orders from the trading system 22. The
settlement and clearing
6
CA 02922112 2016-02-29
P5523CA00
system 20 handles the financial transactions behind the exchange of financial
instruments and
interests facilitated by the trading system 22. The settlement and clearing
system 20 can
include servers, data stores, or other types of computers within one or more
settlement and
clearing domains under the control of one or more settlement and clearing
entity.
[0037] The trading system 22 includes servers, data stores, or other types
of computers
within a trading system domain controlled by an exchange or other entity. The
trading system
22 is configured to receive data messages representative of orders for mutual
funds from
market participant terminals 14, accumulate such orders, and then fill the
orders based on price
data received from the manufacturer systems, such as net asset value (NAV)
price. The trading
system 22 is also configured to process orders received from market
participant terminals 14
for other financial instruments and interests, in a conventional manner.
Advantageously, the
trading system 22 can process data representative of orders for instruments
and interests that
are subject to only primary trading (i.e., mutual funds) and also process data
representative of
orders for instruments and interests that are subject to primary and secondary
trading (e.g.,
equities, exchange-traded funds, etc.). As will be discussed, a set of
universal techniques are
used, so that one trading system 22 can handle such disparate types of data.
[0038] The market data system 24 is configured to output one or more market
data feeds
containing mutual fund data integrated with equity data. Both equities and
mutual funds may
be identified by their mutual-fund identifiers (e.g., symbol) and may further
include last trade
data, such as last traded price and volume. Mutual fund data may further
include attributes,
such as maximum/minimum volume thresholds accepted for purchase/redemption. An
example of a market data feed is shown below in Table 1.
[0039] Table 1:
Symbol Last Trade Min/Max Volume
Price Volume (or NA for not
applicable)
ABC $251.49 10000 NA
7
CA 02922112 2016-02-29
P5523CA00
,
QRS-M $150.00 500 100/NA
XYZ $85.44 1000 NA
[0040] In the illustrative example of Table 1, the feed contains mutual
fund data integrated
with normal equity data. The indicator or tag for a mutual fund, in this
example, is "-M".
[0041] The portfolio management systems 16 and market participant terminals
14 can be
configured to consume the market data feeds provided by the market data system
24. Such
configuration can include identifying the mutual-fund indicator or tag in the
feed and displaying
information for mutual funds with the indicator, tag, or some other indication
to market
participants. Advantageously, market data is provided in integrated but
heterogeneous feeds,
in a network efficient and computationally efficient manner, with end points
decoding the
feeds according to their needs.
[0042] FIG. 2 shows a flowchart of a method performed by the trading system
22.
[0043] At step 30 a data message is received at the trading system 22 from
one of the
market participant terminals 14.
[0044] If the data message does not contain a mutual-fund identifier, such
as a preassigned
symbol for the fund similar to a stock symbol, as determined by the trading
system 22
inspecting the data message at step 32, then the data message is treated as an
order for
another kind of financial instrument or interest. The trading system 22
performs matching and
trade processing normally for such financial instrument or interest, at step
34.
[0045] If the data message contains a mutual-fund identifier, then the
message is
determined to also contain data that includes an indication of a number of
units ordered and a
market-participant identifier identifying the source of the order. Notably,
the data message
specifies a number of units (volume) of a mutual fund, rather than financial
information such as
a total spend or a price of the fund. The data message may include a limit
price that triggers
cancelation of the order after determination of a NAV price that contravenes
the limit. At step
8
CA 02922112 2016-02-29
P5523CA00
36, the trading system 22 extracts data from the data message and uses it to
generate a
pending order that contains the market-participant identifier, the indication
of the number of
units, and a mutual fund manufacturer identifier. The mutual fund manufacturer
identifier can
be obtained by the trading system 22 a database to obtain a mutual fund
manufacturer
identifier using the mutual-fund identifier as a query key, where such
database stores
relationships of mutual-fund identifiers to mutual fund manufacturer
identifiers. Generating a
pending order is performed without matching price or time of the respective
data message with
a corresponding booked order. Rather, each order is automatically generated
identifying the
correct mutual fund manufacturer irrespective of the price, which is not yet
known.
[0046] At step 37, it is determined whether a minimum volume threshold
applies and
whether a maximum volume threshold applies. For each such threshold that
applies, the
threshold is checked and any pending order violating the threshold is
rejected, via step 39. That
is, if a pending order has a volume that exceeds a maximum volume threshold
for the ordered
fund, then the pending order is rejected. Likewise, if a pending order has a
volume that is less
than a minimum volume threshold for the ordered fund, then the pending order
is rejected.
Such thresholds may be set by fund manufacturers to introduce volume discounts
or tiered
pricing using volume as a proxy for the type of client submitting the
instruction.
[0047] At step 38, the pending order is accumulated by the trading system
22 and stored in
a batch with other pending orders for an indeterminate amount of time, which
can be based on
a configured end time (e.g., periodic, time-of-day, etc.). Accumulating orders
involves collecting
and storing orders for a time and is distinct from aggregating orders, which
instead groups
orders based on another characteristic. The present invention does not
aggregate orders or
processed orders in aggregation. Rather, each order is processed individually
after a group of
orders are accumulated over a period of time.
[0048] Step 40 determines whether the accumulated orders are to be resolved
based on
the configured end time. In one example, the configured end time is 6:00 PM of
each trading
day. Before the configured end time, step 40 returns the method to step 30 to
wait to receive
9
CA 02922112 2016-02-29
P5523CA00
more data messages. On or after the configured end time, step 40 resolves the
accumulated
orders by advancing to step 42.
[0049] At step 42, the trading system 22 receives an indication of price
for each of the
mutual funds identified in the pending orders from the respective mutual fund
manufacturer
systems 10. The trading system 22 can query the respective mutual fund
manufacturer systems
for price data. Alternatively, the trading system 22 can wait for such data to
be delivered.
The price data can be representative of NAV prices.
[0050] Reception of suitable price data is checked for by an exception
process (FIG. 5). The
exception process includes checking that the price data meets basic
requirements (e.g., exists,
is well formed, and is complete).
[0051] At step 43, for each accumulated pending order that specifies a
limit price, the limit
price is compared to the obtained NAV price and the accumulated pending order
is cancelled,
via step 39, if the limit price is contravened.
[0052] Next, at step 44, the trading system 22 calculates a total price
based on the relevant
received indication of price and the number of units specified in each
accumulated pending
order to generate a filled order. All accumulated pending orders that were not
cancelled at step
43 are processed in this manner.
[0053] Filled orders are then transmitted to the settlement and clearing
system 20, at step
46.
[0054] In addition, the method may include, at step 48, reporting a market-
participant
identifier of a filled order to the respective mutual fund manufacturer system
10 identified
from the filled order, so that the mutual fund manufacturer system 10 can
process any
commission due to the market participant.
[0055] The method repeats each trading day.
[0056] FIG. 3 shows components of the electronic trading system 22.
CA 02922112 2016-02-29
P5523CA00
, ,
[0057] The trading system 22 includes an order processing engine 60, a
database 62, an
order accumulator 64, and an order resolver 66. Each of the components 60 ¨64
can include a
combination of hardware processors and memory and programmatic instructions to
implement
the discussed functionality. Functionality of the components 60¨ 64 can be
combined into
fewer components or further separated into more components, with the
components 60 ¨64
being illustrative and not limiting.
[0058] The order processing engine 60 is configured to receive data
messages via a
network 26 from market participant terminals. Each data message is
representative of an order
for a financial instrument or interest, including mutual funds. In the case of
mutual funds, a
data message contains a mutual-fund identifier, an indication of a number of
units, and a
market-participant identifier. Because the system operates on a unit-basis,
such a data message
can omit a price, a total amount to spend, and similar information. A data
message can include
a limit price.
[0059] The order processing engine 60 can be configured to perform
matching and trade
processing normally for financial instruments and interests other than mutual
funds. That is, an
incoming order for an equity instrument (e.g., a stock) can be matched to
another order to
create a trade, which is then executed. Such processing is performed by the
order processing
engine 60 in parallel to processing of mutual fund order and thus bypasses the
order
accumulator 64 and order resolver 66. The order processing engine 60 can be
configured to
differentiate orders for mutual funds from other financial instruments and
interests by
detecting a mutual-fund indicator or tag in data messages, such mutual-fund
indicator being
within the mutual-fund identifier (e.g., symbol) or as an attribute of orders
contained in the
data messages.
[0060] The order processing engine 60 is further configured to generate
pending orders for
mutual funds based on received data messages. Each pending order contains a
market-
participant identifier extracted from a particular data message and an
indication of a number of
units extracted from the particular data message. Each pending order further
includes a mutual
fund manufacturer identifier obtained by using the mutual-fund identifier
extracted from the
11
CA 02922112 2016-02-29
P5523CA00
particular data message as a key to query the database 62, which stores
relationships of
mutual-fund identifiers to mutual fund manufacturer identifiers.
[0061] The order processing engine 60 can implement minimum and maximum
volume
(unit) thresholds, discussed above, to reject pending orders that contravene
any such
threshold(s) set for a particular fund.
[0062] The order accumulator 64 is coupled to the order processing engine
60 and is
configured to receive pending orders from the order processing engine 60. The
order
accumulator 641s configured to store pending orders for an indeterminate
amount of time in a
batch of accumulated pending orders 70.
[0063] The order resolver 66 is coupled to the order accumulator 64. The
order resolver 66
is configured to receive an indication of price for each of the mutual funds
identified in the
accumulated pending orders 70 from the respective mutual fund manufacturer
systems 10 and
to execute an exception process (FIG. 5) to ensure that suitable price data is
available. The
order resolver 66 is further configured to fetch accumulated pending orders 70
from the order
accumulator 64. For each accumulated pending order, the order resolver 66
calculates a total
price based on a respective received indication of price and the number of
units specified in the
accumulated pending order to generate a filled order. Calculation of total
price can include
multiplying a NAV price received from the manufacturer by the number of units
ordered. The
order resolver 66 can also be configured to cancel any order that does not
meet its limit price, if
any. Operation of the order resolver 66 can be limited by a resolve condition
68 that must be
met before generation of filled orders. The resolve condition can be a time-
based condition,
such as a particular time of day for each trading day. For example, the
resolve condition 68 can
specify 6:00 PM of every trading day, so that operation of the order resolver
66 is triggered at
that time. The order resolver 66 is further configured to output filled orders
or settlement
records to the settlement and clearing system 20.
[0064] Settlement records are also transmitted to the fund manufacturer
systems 10 to
ensure the required number of units for each respective fund are either
created and settled or
12
CA 02922112 2016-02-29
P5523CA00
received and retired. This information can also be used as one of the inputs
into the NAV
calculation for the next business day. Settlement records are also transmitted
to the market
participants. Settlement records can also transmitted to the market data
system 24 for output
in one or more market data feeds.
[0065] FIG. 4 shows data structures according to the present invention. A
message data
structure 80 includes fields for mutual-fund identifier 82, number of units
84, and market-
participant identifier 86. The data structure 80 can form the basis for data
messages
representing orders. A fund/manufacturer correlation data structure 90
includes fields for
mutual fund manufacturer identifier 92 and mutual-fund identifier 82. The data
structure 90
can form the basis of the fund/manufacturer relationships stored in the
database 62. An order
data structure 100 describes a transaction between two parties and includes
fields for mutual
fund manufacturer identifier 92, mutual-fund identifier 82, number of units
84, and market-
participant identifier 86. The order data structure 100 can be used to store
pending and filled
orders.
[0066] FIG. 5 shows a flowchart for an exception process used when
receiving price data
(e.g., NAVs) from manufacturer systems 10.
[0067] The exception process includes, for each mutual fund identifier
(e.g., symbol),
checking that data purporting to being price data has been received (step 100)
and checking
that such data is well-formed (step 102), which can include checking that the
message or file
containing the data lacks fundamental errors and that the data itself has
characteristics of
accepted price data (e.g., a monetary value). The data is also checked for
currency (step 104),
which can include verifying that one or more dates in the data match the
current date. Further,
a logic check (step 106) may be implemented as another check to ensure that
the data lacks
other errors. The logic check may include mathematical limits for valid prices
(e.g., >0), sensible
limits for valid prices (e.g., disallow price moves greater than +1-50%), and
similar.
[0068] If any of the checks at steps 100¨ 106 fail, then it is determined
that the received
price data, if any, is invalid and a notification is generated, at step 108.
The notification can
13
CA 02922112 2016-02-29
P5523CA00
indicate which check failed. At step 110, the notification is transmitted to
the manufacturer
system 10 that sent the price data.
[0069] Without valid price data for the current trading day, the process
repeats, via step
112, until valid price data is received or until a timeout expires. The
timeout can be set to a
specific time of the trading day (e.g., 11:00 PM), a specific time of the next
day (e.g., 8:00 AM),
a specific duration after market close (e.g., within 3 hours after close), or
similar.
[0070] If the timeout expires, it is determined the no valid price data for
the current day
was received. Step 114 then determines whether valid price data is available
for a preceding
trading day, such as the immediately preceding trading day. If available, then
price data for the
preceding trading day is selected as the price data for the current day, at
step 116. This
provides tolerance to errors in transmitting the price data without unduly
compromising the
ability to execute trades. In other examples of the exception process, valid
price data of a
trading day earlier than the immediately preceding trading day can be used if
valid price data
for the immediately preceding trading day is unavailable.
[0071] If no valid price data is available for the specified preceding
trading day(s), then, at
step 118, the orders for the current day for the respective mutual fund
identifier (e.g., symbol)
are cancelled.
[0072] If all of the checks at steps 100¨ 106 pass, then the received price
data is
considered valid and is selected as the price data for the current trading
day, at step 120.
[0073] FIG. 6 shows a flowchart diagram illustrating the components of the
system that
perform each action and showing the timing of each action. The process applies
to purchase
and redemption of fund units, though the clearing and settlement process 168
will vary
depending on whether purchase or redemption is performed.
[0074] During a given trading day, purchase/redemption instructions 150 are
generated by
the market participant terminals 14 and portfolio management systems 16 and
transmitted as
orders to the trading system 22. The trading system accumulates orders 152
until the end of
14
CA 02922112 2016-02-29
P5523CA00
the trading day. At the end of the trading day, manufacturer systems 10
transmit 154 NAVs via
the network for the trading day to the trading system 22 which receives 156
the NAVs. The
trading system 22 resolves 158 the orders, as discussed above, and transmits
160 respective
settlement records via the network. The market participant terminals and
systems 14, 16,
manufacturer systems 10, and settlement and clearing system 20 respectively
receive 162, 164,
166 the settlement records or variations thereof. During the next one or more
subsequent
days, the settlement and clearing system 20, along with one or more transfer
agents,
custodians, and/or clearing brokers, perform a settlement and clearing process
168 to
financially complete each order according to the settlement records. The
settlement and
clearing system 20 transmits an execution report upon completion, which is
receptively
received 172, 174 by the manufacturer systems 10 and the market participant
terminals and
systems 14, 16. The manufacturer systems 10 receiving execution reports 172
can include
receiving settlement funds to custodial accounts. The market participants
receiving execution
reports 174 can include receiving or delivering units, depending on whether
units were bought
or sold.
[0075] The techniques described above can be implemented in an electronic
marketplace
or trading system for issuing, trading, holding, transferring, buying,
selling, or participating in
other types of exchange for one or more financial instrument or interest.
Electronic
marketplaces and trading systems include one or more electronic networked
order books,
venues, trading venues, securities trading venues, marketplaces, exchanges,
private equity
exchanges, public securities exchanges, order books (e.g., dark books, lit
books, etc.) within an
exchange, alternative trading systems, and/or other markets, alone or in
combination.
Advantageously, the one or more financial instrument or interest include
mutual funds, as
discussed herein, and may further include exchange-traded funds (ETFs),
securities, debt,
shares, stocks, derivatives, and similar or other type of financial product,
instrument, or
interest. That is, a system according to the present invention processes
mutual fund orders, as
discussed, and can be additionally configured to process orders/trades for
other financial
instruments or interests. The techniques discussed herein can be applied to
various
computerized trading systems, including those operating in various
marketplaces.
CA 02922112 2016-02-29
P5523CA00
[0076] While
the foregoing provides certain non-limiting example embodiments, it should
be understood that combinations, subsets, and variations of the foregoing are
contemplated.
The monopoly sought is defined by the claims.
16
