`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`————————————————
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`————————————————
`
`GAIN CAPITAL HOLDINGS, INC.,
`Petitioner,
`
`v.
`
`OANDA CORPORATION,
`Patent Owner.
`
`————————————————
`
`Case No. CBM2020-00021
`Patent No. 8,392,311
`————————————————
`
`
`DECLARATION OF IVAN ZATKOVICH
`
`
`
`
`
`
`
`
`OANDA - EXHIBIT 2002
`
`

`

`TABLE OF CONTENTS
`
`INTRODUCTION ......................................................................................... 1
`I.
`BACKGROUND AND QUALIFICATIONS .............................................. 2
`II.
`III. SUMMARY OF DECLARATION AND OPINIONS ................................ 5
`IV. LEGAL STANDARDS .................................................................................. 6
`A.
`Covered Business Method Eligibility ................................................... 6
`B.
`Subject Matter Eligibility ...................................................................... 6
`V.
`PERSON OF ORDINARY SKILL IN THE ART ...................................... 8
`VI. STATE OF THE PRIOR ART ..................................................................... 9
`A. Order Types ........................................................................................... 9
`B.
`Real-Time Pricing ...............................................................................16
`VII. OVERVIEW OF THE ʼ311 PATENT ....................................................... 20
`A.
`Field of Invention ................................................................................20
`B.
`Background and Problems Addressed ................................................21
`1.
`Restricted Trading Data ............................................................ 21
`2.
`Restrictive Types of Orders ...................................................... 22
`C.
`Specific Teachings of the Invention ....................................................24
`1.
`System Architecture .................................................................. 24
`a)
`Trading System Server ................................................... 25
`b)
`Trading Client System .................................................... 30
`2.
`Real Time Pricing ..................................................................... 32
`3. Market Order with Requested Price .......................................... 34
`VIII. REBUTTAL TO THE DONEFER DECLARATION ............................. 38
`IX. APPLYING THE LEGAL FRAMEWORK ............................................. 44
`A.
`Review. ................................................................................................45
`The Claims are Directed to Patent-Eligible Subject Matter. ...............46
`B.
`1.
`Alice Test – Step 1 .................................................................... 46
`2.
`Alice Test – Step 2 .................................................................... 49
`X. APPENDIX – LIST OF MATERIALS CONSIDERED .......................... 56
`
`The Claims are not Eligible for Covered Business Method Patent
`
`
`
`
`
`i
`
`

`

`DECLARATION OF IVAN ZATKOVICH
`REGARDING CBM2020-00021
`
`
`
`I, Ivan Zatkovich, hereby declare:
`INTRODUCTION
`I.
`I have been retained by counsel for OANDA Corporation (“OANDA”)
`1.
`to provide opinions on subject matter eligibility issues concerning the claims of U.S.
`Patent No. 8,392,311 entitled “CURRENCY TRADING SYSTEM, METHODS,
`AND SOFTWARE” (the “ʼ311 Patent” or “Patent-in-Suit”).
`This declaration is a rebuttal to Petitioner Gain Capitol Holdings, Inc.’s
`2.
`(“GAIN”) Covered Business Model (CBM) Petition CBM2020-00021 for the ʼ311
`Patent (“Petition”). I have been asked to opine on the subject matter eligibility of
`the Patent-in-Suit under 35 U.S.C. § 101 taking into account legal guidance provided
`by counsel for OANDA and my evaluation of the Patent-in-Suit. I have also been
`retained by OANDA to offer an expert opinion on U.S. Patent Nos. 7,146,336 and
`7,496,534.
`My opinions are set forth below. I make these statements based upon
`3.
`facts and matters within my own knowledge or on information provided to me. All
`such facts and matters are true to the best of my knowledge and belief. I am being
`paid $585 per hour for my work on this matter, and my pay is in no way dependent
`upon the content of my opinions or the results of my work. A list of materials I
`considered in forming these opinions is included at the end of this declaration.
`
`1
`
`

`

`II. BACKGROUND AND QUALIFICATIONS
`A copy of my curriculum vitae with a list of cases where I have been
`4.
`retained in the past five years is submitted as EX2012.
`I received a Bachelor’s degree in Computer Science, with a minor in
`5.
`Electrical Engineering Digital Circuit Design, from the University of Pittsburgh in
`1980. I completed a Master’s thesis in Computer Networks in 1981 at the University
`of Pittsburgh, the results of which were published in Byte Magazine. My Master’s
`thesis involved designing a heterogeneous network architecture that allowed
`substantially different computer systems to communicate with a common command
`interface.
`I have over 35 years of experience in the fields of computer science and
`6.
`computer network architecture involving a diverse set of implementations including
`the following: telecommunications, eCommerce, financial transaction systems
`including trading and investments systems, banking and payment network systems,
`currency exchange rates, and secure electronic transactions.
`I have been a Principal Consultant with eComp Consultants for over ten
`7.
`years. eComp Consultants provides professional consulting services relating to
`computer and technical matters in a wide range of industries including embedded
`internet systems, cellular telephony, and eCommerce and financial transactions.
`These consulting services are wide ranging, include working with clients, such as
`Amazon.com, Microsoft, GEICO, Verizon, and McGraw-Hill, on specific
`
`2
`
`

`

`information technology projects, process improvement, project management, and
`other technology issues.
`At eComp Consultants, I have been frequently called upon to provide
`8.
`my expert opinion on matters in patent disputes. I have been qualified as a technical
`expert in over 24 matters and have specifically analyzed and testified about computer
`systems for managing and tracking shipments and supply chain and logistics
`management. A complete list of the cases in which I have testified in the last five
`years is included in my resume.
`In my professional career, I have worked for companies such as Digital
`9.
`Equipment Corp., GTE Data Services (now Verizon), and Eva-Tone, Inc. on projects
`designing, developing, and integrating software and hardware for major computer
`and telecommunications systems and networks, and on projects designing and
`developing eCommerce, financial and payment systems, and web publishing
`systems.
`I have designed, implemented, and/or managed specific projects related
`10.
`to the technology of the Patent-in-Suit including the following:
`• IMR Global – eBusiness Manager designing and implementing financial
`applications for:
`- ETrade – Developed initial version of ETrade’s online securities trading
`system. Implemented transaction for matching security interests with limit
`and stop orders.
`
`3
`
`

`

`- Citicorp – Developed web-based mortgage payment and debt management
`& consolidation system.
`- Smith Barney – Implemented financial user interface display for PDA
`Trader Access system, which allowed for retrieval of financial trading orders
`and information for brokers. Specifically, user interface display allowed for
`the following:
`identifying and aggregating orders, routing orders,
`reconciling account and order book reconciliation, and interest calculations.
`• Tanning Technology – Served as the Architect, Financial System Platforms.
`In this role I worked on the following:
`- Hartford Insurance – Developed subrogation system for multi-policy
`payment allocation.
`- GEICO – Implemented online claims processing and payments system.
`• Utility Partners – Implemented natural gas commodities online trading and
`auction system.
`• Evatone – Developed transaction management and exchange rate management
`systems for card payment gateways for clients such as Wachovia Bank and
`Capital One.
`• Vaud Advisors Social Media Technology Fund – Served as Fund Leader and
`Technology Advisor. Defined the criteria for selecting and funding technology
`start-ups including social based financial trading platforms, investment
`vehicles, and eCommerce applications.
`
`4
`
`

`

`By virtue of at least the above education and experiences, I have gained
`11.
`a detailed understanding of the technology that is the subject of this declaration. For
`example, my experience with financial transactions, securities trading systems, and
`computer network architecture is relevant to the subject matter of the Patent-in-Suit.
`As such, I am qualified to provide opinions regarding the state of the art at the period
`of time of the invention, which I understand to be around the year 2000 to 2001 time
`frame, how one of ordinary skill in the art at that time would have interpreted and
`understood the Patent-in-Suit, and the subject matter eligibility of the claims of the
`Patent-in-Suit under 35 U.S.C. § 101.
`III. SUMMARY OF DECLARATION AND OPINIONS
`12. My analysis in this declaration proceeds as follows. In Part IV, I lay
`out my understanding of the legal standards applicable to deciding the Petition. In
`Part V, I identify an appropriate definition of the person of ordinary skill in the art
`for purposes of analyzing the ’311 Patent’s claims and the state of the prior art. In
`Part VI, I describe the state of the prior art as of the priority date of the ʼ311 Patent.
`In Part VII, I explain the teachings of the ʼ311 Patent and what its claimed advances
`are over the prior art. In Part VIII, I explain how the Declaration of Bernard S.
`Donefer (EX1008, “Donefer Declaration”), submitted in support of the Petition,
`misstates the prior art and misapprehends the invention of the ʼ311 Patent. Finally,
`in Part IX, I describe how the ’311 Patent’s claims fit into my understanding of the
`applicable legal framework, and I conclude that—with a proper understanding of the
`
`5
`
`

`

`prior art and the claims in the ʼ311 Patent—there is no valid basis on which to
`institute CBM review.
`IV. LEGAL STANDARDS
`A. Covered Business Method Eligibility
`I am advised that a covered business method patent means a patent that
`13.
`claims a method (or corresponding apparatus) for performing data processing or
`other operations used in the practice, administration, or management of a financial
`product or service, but not technological inventions.
`To determine whether a patent covers a technological invention, I
`14.
`understand that the Patent Trial and Appeal Board (the “Board”) considers two
`factors on a case-by-case basis: (a) whether the claimed subject matter in the patent
`as a whole recites a technological feature that is novel and unobvious over the prior
`art; and (b) whether the claimed subject matter as a whole solves a technical problem
`using a technical solution.
`Subject Matter Eligibility
`B.
`15.
`I am informed by counsel that through decisions such as Alice Corp.
`Pty. Ltd. v. CLS Bank Int’l, 573 U.S. 208 (2014) and Mayo Collaborative Servs. v.
`Prometheus Labs, Inc., 566 U.S. 66 (2012), the Supreme Court established a two-
`step test to distinguish between patents that claim laws of nature, natural phenomena,
`and abstract ideas from patents that claim patent-eligible applications of these
`concepts. I will refer to this test as the “Alice test” because I understand that the
`
`6
`
`

`

`specific articulation of the test, as provided to me by counsel, comes from these
`decisions.
`I am also informed by counsel that a petitioner for a CBM review has
`16.
`the burden to prove, by a preponderance of the evidence, that a patent claim is
`eligible for CBM review, and separately that a claim is ineligible for patent
`protection. To determine whether a claim is ineligible, I understand that the
`petitioner must show that the claim is directed to an abstract idea (“Step 1”). If the
`claim is directed to an abstract idea, the question then becomes whether the
`limitations of the claim transform the claim from one that covers an abstract idea
`into one that claims a patent-eligible application of that abstract idea (“Step 2”).
`I am also informed that, even if the claims “recite” or incorporate an
`17.
`abstract idea, the claims are not “directed to” that abstract idea if there are limitations
`of the claim that integrate the abstract idea into a practical application of the idea.
`Step 2 of the Alice analysis is only considered if the abstract idea is not limited to a
`practical application. I am informed that Step 2 is sometimes described as the search
`for an inventive concept, or for some element or combination of elements that
`establishes that the claim amounts to more than just a patent claim on an abstract
`idea.
`Further, I am advised that some mathematical algorithms are ineligible
`18.
`abstract ideas even if they are executed on a general-purpose computer. I am advised
`that some fundamental economic and conventional business practices are abstract
`
`7
`
`

`

`ideas. Additionally, I am advised that claims directed to nothing more than the
`performance of an abstract business practice on the Internet or using a conventional
`computer are also abstract ideas. However, I understand that it is improper to
`oversimplify a claim by looking at the claim generally and failing to account for the
`specific limitations recited in the claim. To determine patent eligibility under Steps
`1 and 2 of the Alice test, the claim must be considered as a whole.
`Lastly, I am advised that if a claim is rooted in using computer
`19.
`technology to overcome a problem arising in the realm of computer functionality or
`computer networking, that claim may be eligible for patent protection. I also
`understand that if a claim is directed to a specific improvement in computer
`capabilities, that claim may be eligible for patent protection.
`PERSON OF ORDINARY SKILL IN THE ART
`V.
`I have performed the analysis in this declaration with a view to the
`20.
`understanding of a person of ordinary skill in the art (“POSITA”) as of the priority
`date of the Patent-in-Suit, which I understand is at least as early as March 8, 2001.
`Identifying the level of understanding of a POSITA is important for understanding
`how a POSITA would interpret aspects of the Patent-in-Suit and how a POSITA
`would view the challenges and deficiencies in the state of the art for subjects
`discussed in the patent.
`21. GAIN has stated, and I agree, that a POSITA at the time of the invention
`detailed in the ’311 Patent includes:
`
`8
`
`

`

`someone who had, through education or practical experience, the
`equivalent of a bachelor’s degree in computer science, information
`systems, or a related field, and at least two years of work experience
`developing electronic trading systems. This would also include a person
`who had, through education or practical experience, the equivalent of a
`bachelor’s degree in finance, economics, or a related field, and who had
`obtained knowledge of computer systems equivalent to that described
`above.
`
`[Petition, 16-17.]
`VI. STATE OF THE PRIOR ART
`Because the ’311 Patent’s claims relate to currency trading over a
`22.
`computer network, to identify the relevant prior art, this section presents a brief
`overview of systems offering currency trading over a computer network in and
`around the 2000 to 2001 timeframe—the time leading up to the filing of the ’311
`Patent (“Relevant Time”). The discussion focuses on what a POSITA, as defined
`above, would have been aware of at the Relevant Time. I will describe in turn:
`(A) the order types used in currency trading over a computer network; and
`(B) the availability of real-time pricing for foreign currency trading.
`In doing so, I will identify the shortcomings present in the online currency trading
`technologies in use at the Relevant Time.
`A. Order Types
`There were three principal order types in use when trading currency
`23.
`over a computer network at the Relevant Time: “Request for Quote (RFQ) Orders,”
`
`9
`
`

`

`“Market Orders,” and “Limit Orders.” Traders could utilize these different order
`types to achieve different ends, but none of these allowed traders to identify a precise
`price in the market and immediately execute a trade using that price.
`An RFQ Order is when a trader makes a request for quote to a dealer
`24.
`for a pair of currencies. These are the types of orders that make up what is referred
`to as the “three-way handshake” process in the ʼ311 Patent Overview section. [See
`EX1001, 1:22-39.] GAIN’s expert, Bernard S. Donefer (“Donefer”), noted in his
`declaration that RFQ Orders are submitted as part of “reverse auctions,” and that
`“the reverse auction process described above is essentially the ‘three-way
`handshake’ referenced in the specification.” [EX1008, ¶61.]
`An RFQ Order comprises three basic steps: “(1) the trader requests a
`25.
`quote, (2) banks respond with quotes, subject to a short time limit, and (3) the trader
`can choose to accept a quote (or not)” [EX1008, ¶61.] During this process, the trader
`does not disclose whether he plans to buy or sell; the bank (or dealer) presents buy
`and sell price quotes with an expiration time, and the expiration time is typically
`very short—seconds—after the quote is provided. An example system described in
`an exhibit to the Donefer Declaration, Currenex FXtrades, allowed banks 25 seconds
`to provide a quote to a trader, and then the trader had 5 seconds to decide whether to
`accept the price. [EX1013, 8.] If prices are not at levels where the trader wants to
`trade, he or she does not trade. Instead, the trader requests a price requote or
`performs another RFQ Order later.
`
`10
`
`

`

`This was a tedious process, particularly in the absence of real-time price
`26.
`quotes. Even with real-time quotes, the process would be cumbersome unless the
`trader could execute the trade at the quoted price immediately and receive that price.
`As an exhibit Donefer relies upon explains, RFQ Orders/reverse
`27.
`auctions were often a trader’s best option to get competitive prices, but they were
`flawed because they could not offer traders the ability to trade on real-time prices:
`
`[A] [r]everse auction, where the buy side is empowered to select not
`only the type of product it’s looking for, but also the price it’s willing
`to pay, is not always the most effective mode when instantaneous
`response is required, but it is the best system for accessibility and
`yields the most competitive prices.
`
`[EX1013, 7.] It should also be noted that the article’s author, Iati, describes this
`process in a section focused on “Treasury FX Trading,” which refers to a segment
`of the foreign exchange marketplace where “corporations and fund managers need
`to buy and sell currencies to mitigate their exposure to operating globally and hedge
`their cross-border trades with FX futures.” [EX1013, 7.] This correctly implies that
`reverse auctions (RFQ orders) were a more common process for large institutional
`traders and not individuals or small traders.
`If a trader did not want to go through the “three-way handshake”
`28.
`process of an RFQ Order, the trader had to choose between either the time of the
`trade or the price—the trader could not specify both in a “two-way handshake” type
`
`11
`
`

`

`of transaction—as described by the restrictions of the Market Order and Limit Order
`below.
` A Market Order is an order type in which a trader indicates a desire
`29.
`to buy or sell at the current market price. As described in the Deal Station 2000
`platform referenced by Donefer [EX1008, ¶¶68-69], a Market Order is “[a]n order
`to buy or sell which is to be filled at the price immediately available; the current
`rates at which the market is dealing.” [EX1027, 1.] Market Orders only execute at
`the foreign currency market price provided by the dealer at the time of the trade
`request, which may or may not be the price that was first quoted to the trader. As
`noted in the Matchbook FX platform (one of Donefer’s relied upon prior art systems)
`Trading Policies document from May 1, 1999, a Market Order is defined as “[a]n
`order to sell or buy Foreign Currency (or Options) ‘at market’ – i.e. immediately and
`at the next Spot Rate available for Customer dealing. No Spot Rate [also known as
`the current market price] is specified when entering a Market Order, and the
`Customer agrees to accept the best price which Matchbook FX, in its discretion, may
`assign to the Fill.” [EX2003, 2.] In other words, the trader cannot specify or accept
`a quoted price in a Market Order.
`Generally, in the RFQ process, the delay between (i) the price quote
`30.
`from the dealer to the trader and (ii) the subsequent trade execution results in the
`trade settling at a price that is different from the quote. Once the trader requests a
`Market Order, however, the trader has no ability to control the price at which the
`
`12
`
`

`

`Market Order will execute. Another exhibit to the Donefer Declaration, in
`describing trading among major dealers, notes:
`
`In very active markets, quotes displayed on the screen can fail to keep
`up with actual market quotes. Also, the rates on the screen are typically
`those available to the largest customers and major players in the
`interbank market for the substantial amounts that the interbank market
`normally trades, while other customers may be given less advantageous
`rates.
`
`[EX1011, 69-70.] In other words, the rates a trader sees on the screen likely would
`not be the rates at which the trader could actually trade.
`In the Deal Station 2000 online trading platform referenced by Donefer,
`31.
`[EX1008, ¶¶63, 68-70], the trader enters the order into the trading client’s computer,
`but the actual trading is done with a professional dealer. This means that trades’
`execution is up to the dealer’s discretion and is not automatically completed by the
`trading platform. Donefer presents an example of the Deal Station order screen,
`which implies that a trader could specify a rate with a market order. [EX1008, ¶69.]
`Deal Station’s own user documentation makes it clear that the rate field in the order
`screen was not a binding rate in the case of a market order. In the live system, the
`trader trades with professional dealers. The dealer has the option to process a market
`order (or not) in several ways, regardless of what rate the trader may input.
`[EX2004, 2.] As the Deal Station 2000 DEMO System Frequently Asked Questions
`document notes, “Thus, even if you submit an order at a rate different from the
`
`13
`
`

`

`current market rate, your order may still be opened.” [EX2004, 2.] Later, the same
`document notes that sometimes the dealer may reject the order because of a large
`difference in the market rate—“Although in real trading you may submit a market
`order at any price, the dealer might reject your order, because of a large difference
`between the market rate and your requested rate.” [EX2004, 2.] This indicates that
`Deal Station was not providing the trader with real-time price data, or that the dealer
`was not executing orders in real time if the trader-inputted rate was different from
`the market rate. Instead, these statements demonstrate that Deal Station treated the
`“rate” field as merely a suggestion, and certainly not a binding request to always
`execute at the requested price or reject it. It is clear that the trader could never
`determine at what price the market order would execute until after it executed. The
`price outcome of the trade was always unpredictable. As such, as with Matchbook
`FX, Deal Station 2000 did not have the capability to provide certainty in specifying
`a precise price and immediately executing at that price using a Market Order.
`In the case of individual and other small traders, dealers had the ability
`32.
`and incentive to execute trades at prices different than those quoted to traders, which
`would be disadvantageous to traders. This could include holding a trade
`momentarily to wait for the market to move against the trader. [EX2005, ¶14.]
`While the Matchbook FX and Deal Station 2000 systems were able to perform
`Market Orders using computer network-based trading, these systems were not able
`to allow the trader to specify precisely when and at what price a trade would execute.
`
`14
`
`

`

`A Limit Order is an order that will execute when the Spot Rate reaches
`33.
`a specified price, or limit. It is not an order for immediate execution at a specified
`price. Rather, Limit Orders are available with certain timing restrictions (e.g., day
`only or good-till-cancelled), but they do not execute at a specific time. Limit Orders
`may also not execute at exactly the price designated by the trader in volatile markets.
`As noted in the Matchbook FX Trading Policies document, a Limit Order is:
`
`An Order to establish an Open Position by selling or buying at a
`specified Spot Rate level. Although a Spot Rate level is specified upon
`entry of Limit Entry Orders, market conditions may often prevent the
`execution of an individual Customer’s Limit Entry Order despite other
`dealing activity at that price level, and/or may require such Orders to
`be Filled at a substantially different Spot Rate, and customer agrees to
`accept the best rate which Matchbook FX, in its discretion, may assign
`to the Fill.
`
`[EX2003, 2.] A trader does not have the ability to specify or control when the Limit
`Order executes, except for establishing parameters on when the Limit Order expires.
`A stop-loss or take-profit order is similar to a Limit Order. The trader
`34.
`can add a stop-loss or take-profit order to their original currency trade. These orders
`automatically close out the original trade if the currency price drops too low (i.e., to
`“stop the loss”) or when it gets high enough to “take a profit.” Technically speaking,
`a stop-loss or take-profit order is not submitted when the order is made. It is held
`until the market reaches the trader’s requested stop or profit price, then it is submitted
`
`15
`
`

`

`as a Market Order. And hopefully, the trade will be executed close to the trader’s
`requested price.
`Note that Limit, stop-loss, and take-profit orders do not require real-
`35.
`time pricing from the dealer for execution because they are not dependent upon the
`market price at the time the trader requests that order. In addition, Limit Orders only
`require a trading system server be capable of enqueueing the trader’s orders and
`checking them from time to time to see if the limits have been satisfied. The trader
`simply specifies the “limit price” at which to buy or sell, and then makes the order.
`Trade execution then triggers when the price reaches the limit thresholds.
`I agree that the prior art systems referenced by Donefer [EX1008] were
`36.
`able to perform Limit Orders, stop-loss orders, and take-profit orders over a
`computer network. However, these systems were not able to provide the capability
`for the trader to specify both when and at what price a trade will execute using a
`Limit Order.
`B. Real-Time Pricing
`Currency prices are subject to high market volatility. Given the diverse
`37.
`set of market factors that affect a foreign currency, the foreign currency prices
`fluctuate rapidly, at inhomogeneous intervals. Prices can change from second-to-
`second and on a tick-by-tick basis and each change must be captured and accounted
`for in any currency trading system.
`
`16
`
`

`

`It is well known that price volatility in the currency market is much
`38.
`more pronounced than in the stock market. [EX2009, 3-4; EX2010, 21:60-64,
`41:63-65.] Most short-term day-traders prefer to trade in this highly volatile market
`because it provides the opportunity the take advantage of the quick price movements
`to capture small profits in a short period (e.g., within minutes or seconds). [EX2009,
`4.] To fully leverage this volatility, traders must have access to real-time pricing.
`Conversely, volatility can be factored into risk-sensitive trading models [EX2010,
`18:36-40], again assuming that real-time pricing is available to provide information
`in a timely manner. The ’311 Patent’s technical invention overcame the prior art’s
`inability to adequately control against real-time market volatility and price
`fluctuation.
`Prior to the invention disclosed in the ’311 Patent, real-time or near
`39.
`real-time pricing was available only via expensive, subscription-based trading
`platforms that were often provided using dedicated networks or direct satellite
`communications. These included systems such as those referenced by Donefer
`(Reuters Dealing 2000-2 and EBS) [EX1008, ¶¶57-59], as well as Reuters 3000
`Xtra, which replaced the Dealing 2000-2 service. These services required
`proprietary software and dedicated hardware, including for example, satellite links,
`which were impractical for, and typically unavailable to, retail currency traders.
`Instead, given the costs associated with these trading platforms, they targeted and
`were used by institutional currency traders.
`
`17
`
`

`

`Providing real-time pricing for retail traders requires a different
`40.
`solution than for institutional traders. Retail traders typically buy and sell currency
`in smaller volumes for their own accounts. Whereas institutional traders act on a
`bigger scale trading large sums on behalf of companies, insurance groups,
`investment funds and vehicles, and other institutions. With potentially millions of
`dollars on the line, institutional traders are able to afford the costs associated with
`these subscription-based models. [EX2006 (Reuters Press Release); EX2007
`(Reuters 3000 Xtra Brochure).] Retail traders, however—lacking the sophisticated
`equipment, funds, and IT support needed to use these systems—had no way to access
`real-time prices that they could trade on using prior art systems.
`The primary prior art system relied upon by Donefer is the Matchbook
`41.
`FX system. [EX1008, ¶¶63-67.] Matchbook, however, did not provide traders with
`the ability to trade at quoted real-time prices. Rather, traders would enter an order
`and Matchbook would “in its discretion” “assign” a price for that order. [EX1023,
`4; EX2003, 2.] Furthermore, the system required minimum trades of $25,000 in
`January of 2000, which is well beyond that of a typical individual or small trader.
`[EX1023, 2.] And, just a few months later, Matchbook FX raised the minimum trade
`amount to $100,000, revealing the apparent difficulty providers were having in
`providing continued small-trade capability. [EX2008, 4.]
`In fact, prior art online computer systems that were available to
`42.
`individual retail traders could only provide prices that did not reflect the real-time
`
`18
`
`

`

`price or were on request only. The conventional way for traders to request updated
`prices was to refresh a page in an internet browser. Due to the technological
`limitations of the prior art systems, platforms thus came in two varieties. A trader
`either had to manually refresh the browser window to get new, more current prices,
`or the platform auto-refreshed at various intervals. Either way, the refresh
`requirement was disruptive and resulted in prices that could still have been several
`or more seconds old. [EX2005, ¶6.]
`The lack of real-time pricing was not problematic for RFQ Orders,
`43.
`Limit Orders, and Market Orders. As described, these order types did not require
`real-time or near real-time pricing to execute successfully. RFQ Orders traded at a
`quoted price, which was subject to the reverse auction/three-way handshake process.
`Conventional Market Orders traded at a market price, which (as described above)
`may or may not have been the price quoted to the trader. Conventional Limit Orders
`traded at or near a trader-specified price, which was not based on a real-time price.
`44. Without real-time pricing, traders cannot trade at a precise price at a
`precise time—traders cannot identify a precise real-time price in the market and
`immediately execute a trade using that price. This capability was not available to
`individual traders in prior art trading systems using a computer ne