Exhibit D
`
`
`
`Page 1 of 21
`
`TRADING TECH EXHIBIT 2301
`TRADESTATION v. TRADING TECH
` CBM2015-00179
`
`

`
`All of the Above, Inc.
`P.O. Box 2765
`Sausalito, California 94966
`(415)460-0642
`aota@woz.org
`
`TRADING GAME
`
`DESIGN DOCUMENT
`
`version 1.0
`March 5, 1998
`
`CONFIDENTIAL
`
`PH00000001
`
`Page 2 of 21
`
`

`
`All of the Above, Inc.
`P.O. Box 2765
`Sausalito, California 94966
`( 415)460-0642
`aota@woz.org
`
`TRADING GAME DESIGN DOCUMENT
`
`1. INTRODUCTION
`
`The Trading Game is an Internet based trading system that presents the user with a real time,
`interactive trading environment. Through a Java client interface, the user trades products with a
`number of other users via a server-maintained market environment.
`The user will be presented with product information, including price, volume, and trading
`position in a compact and easy to read format. The user will be able to send buy and sell requests
`easily and see results as they happen in real time, browse account information, access a chat room,
`news and other pertinent information all from the convenience of a web browser.
`The first stage of this system is a simulation using simulated money and simulated products.
`The final evolution of this system will be to use real products and real money in a secure transaction
`environment. The secure version of this system will require account verification, audit trails,
`transaction and account security, zero fault tolerance, and encryption technologies.
`This Design Document is intended to be a detailed description of the Graphical User Interface
`and the structure of the trading architecture necessary to service the end user GUI. It is not intended to
`be a detailed description of the secure account management system or audit system.
`
`2. TARGET PLATFORM
`
`The Trading Game is expected to be released no sooner than Q4 1998. Therefore, the target
`platform for which it is being created is somewhat ambitious by January 1, 1998 standards.
`Windows95 or NT, Internet Explorer 4.0, Java enabled, Pentium 133,24 MB RAM, 28.8K modem.
`The Trading Game demonstration program may be designed to operate with different
`specifications from the above target due to limitations of time.
`
`3. HOW IT WORKS1
`
`The initial problem with any trading system is that some people have an inherent advantage in
`the market due to the latency of the market status to trade execution loop. This is why some people
`pay a small fortune for a place on the stock exchange floor. A trading system which only exists online
`can eliminate nearly all of this disparity and simultaneously enhance the thrill of competition to the
`betterment of all participants.
`We have developed an event-driven architecture2 which attempts to put all traders on an even
`footing with an equal opportunity to participate in trades regardless of latency. The system works on
`time-stamped windows of events we call TTime. TTime is used as the update window for trades.
`Each Tis sequentially numbered. We adjust TTime duration depending upon the number of users and
`
`1 See Appendix for process diagrams
`2 This architecture may be patentable
`Trading Game Design Document vl.O
`confidential
`
`• page 1
`
`CONFIDENTIAL
`
`PH00000002
`
`Page 3 of 21
`
`

`
`the second standard deviation (adjustable) of their average response times. All trades are events
`synchronized to TTime and executed in the same Ttime. There is no trading advantage to having a T 1
`connection, although users on 14.4 modems will probably fall outside the second standard deviation.
`TTime is derived from requests coming from the client applet. This approach means that the
`client applet can tell if a TTime was lost by comparing the sequential time stamped event received to
`the one requested. It also enables us to reconstruct trades at the server or the client. TTime durations
`may vary as more users log on, or if the Internet experiences widespread delays, but the TTimes will
`still be sequential. Having the client applet request information updates also provides for session
`timeouts if the client goes away or if the line goes dead.
`When a user clicks the TRADE button for a buy or sell, the data is sent to the transaction
`server with information about which TTime is current at the user. If the user made the trade within the
`TTime window, the trade will be put into the queue for processing. At the end of TTime, all trades
`which have been submitted will be sorted with a set of arbitration rules on the basis of TTime (with
`delayed Ts given first priority), other priority metrics (possibly including parameters such as "is this
`an important customer?"), volume and price. Then the trades will be matched, executed, updated to
`the various product and account databases, and distributed to users as an updateT. (see figure X)
`A single updateT requires a data set of less than 255 bytes, the minimum size of a TCPIIP
`block, will be sent to all users. This display data set will be optimized to update the display with
`relevant data and step to the next TTime.
`Each product is traded separately with its own unique TTime. The object-oriented architecture
`will enable rapid creation of new products with very simple point and click decisions. The connections
`to the account information and real-word stock ticker information will be made as objects which are
`also quickly replicated. It is not unreasonable to expect that new products will be able to be created,
`tested and deployed in less than a day since nearly all of the code will be identical.
`Graphics, user appearance and other features are also independent objects which can be
`regularly replaced without affecting other objects.
`Trading cycles should be very short, on the order of every 10 seconds with under 1,000
`simultaneous traders. Since each product is traded separately, popular products can be given their own
`server and connections for better performance. Multiple products will be able to be traded on a single
`low-cost server as long as the number of users remains small. The entire trading system could run on
`a single low-cost server, although we don't recommend this for robust financial transactions.
`
`4. CLIENT SOFTWARE
`
`The client software breaks down into many different components. Quite a few of these
`components are self displaying, Others draw themselves within another component. This allows
`modularity within the GUI, enabling it to only redraw the sections of the graphics that require
`updating, resulting in dramatically increased efficiency. Double buffering will be used to eliminate
`flicker in all critical sections.
`The graphic example shown (ver 2.1) is designed to be an easily replaced set of image objects.
`We envision customers having a choice of interface styles from staid to wild. The system is designed
`so that the underlying data is identical to all users, regardless of their display objects.
`
`The following section is an item by item breakdown of the Graphical User Interface,
`describing each item, its function and any other relevant function.
`Trading Game Design Document vl.O
`confidential
`
`• page 2
`
`CONFIDENTIAL
`
`PH00000003
`
`Page 4 of 21
`
`

`
`l
`I
`l
`
`WINTEL
`
`I
`
`I~
`:J
`I
`
`--
`
`TRADEMAN TRADING SYSTEM
`
`1Ei1
`I 100
`!l EU,l) (»~ I
`l
`I , . (f'U
`l
`~
`1 Ctlh
`~
`mn? _____.
`
`QlC
`
`STOCK TICKi:P. .•. U?L :!.!. )/! .... 1~CL D 7/ A ...
`-
`
`-
`
`-
`
`- - - -
`
`-
`
`-
`
`Screen capture of complete sample Trading System GUI 3
`
`MainApplet This is the applet's display area itself. Its size is determined by the height and width
`parameters within the <applet> HTML tag. The applet will fetch the graphics from the server and
`distribute them to the various objects when the applet loads. This object functions as a container for all
`the functional parts of the Applet.
`• The applet will use a border layout.
`• N01th: Title
`• South: ButtonPanel
`• Center: DisplayCardPanel
`
`Title The Title object will consist of a simple bar at the top of the screen that displays the name
`of the product being traded at the left, and another label at the right that either says: "TRADING
`GAME TRADING SYSTEM" or "PREFERENCES", depending on which card is being displayed
`below.
`
`WINTEL
`
`TRADEMAN TRADING SYSTEM
`
`Title Object
`
`J Unless otherwise noted all images are from graphic design version 2.1 at 65% of scale
`Trading Game Design Document vl.O
`confidential
`
`• page 3
`
`. J
`
`I
`
`J
`
`u
`
`CONFIDENTIAL
`
`PH00000004
`
`Page 5 of 21
`
`

`
`DisplayCardPanel This invisible object holds the majority of the graphic objects. This allows
`everything below the title bar to be "swapped out" for another display. That is, the GUI display may
`be exchanged for the PrefsPanel whenever it is called for (see ButtonBar).
`• This is a standard Java Panel object
`• This uses a CardLayout
`• One card is the PrefsPanel.
`• Another is the DisplayPanel.
`• A third is the Inventory Display
`
`PrefsPanel This object contains all the controls that will be needed to set the user preferences.
`The preference settings will be stored on the server along with account information and requested by
`the client when the applet loads. The changed settings must be sent to the server for storage.
`• This extends Canvas
`• This needs access to the Severlnterfacer so it can send and receive preferences.
`• This might need custom widgets, and perhaps even access to images.
`
`P reteren ces
`
`Scale
`' Hour
`~Day
`3 lfiJeek
`.I Month
`
`Display
`~ Posi~ons
`~Price
`~ 1/olume
`~Gallery
`
`Limits
`~Shares
`~Dollars
`~Trades
`
`Traders to Monitor
`Sellers
`
`Buyers
`
`1.
`2.
`3.
`4
`5.
`
`1.
`2.
`3.
`4
`5.
`
`I , ~ 4
`
`~ .~
`History Account Mail
`Forums
`
`i
`
`'?I·:;,ii.:;
`
`Price
`Shares
`
`Pudio 111erts
`....
`I s •I
`~ Buy
`....
`I:. •I
`~ Sell
`~ 1/olume I :. •I
`....
`....
`~ Spread I :. • I
`~ l'ccountl s •I
`....
`~ Ra~o Is •I r---% Sellers/Buyers
`
`Shares
`Dollars
`Dollars
`
`~ Monitored Trader Mvity
`~ Trade Conti rmali ons
`
`.~
`Chat
`
`··:,~
`N&ws
`
`-~
`Quote
`
`.....
`
`Ticker
`
`··.:~
`Trade
`
`Sample Preferences Panel
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 5
`
`CONFIDENTIAL
`
`PHOOOOOOOS
`
`Page 6 of 21
`
`

`
`Display Panel This invisible object is another container object that will hold the various
`sections of the trading display.
`• This is a standard Java Panel
`• T his uses a BorderLayout
`• To the East is the BuySellPanel
`• To the West is the PrimaryDisplayPanel
`
`BuySeiiPanel Tllis object contains the buy and sell controls. Visually, it encompasses the
`buy and sell order controls and the Trade Button. This object passes the buy and sell requests
`(BSRequest objects) to the Serverlnte1facer for processing.
`The process of making a request is initiated by pressing the TradeButton. The price is derived
`from the Graph object's pdce slider, and the rest of the information comes from either the Buy Selector
`or the SeUSelector, depending on which is active. Whichever of the two is active determines whether
`it is a buy or a sell request. If neither is active, then there is no request.
`
`I
`
`~.:ft.
`ltet~rt.e ~1
`I It Cf \ (0!' )
`I
`)
`ore
`l
`I
`( 1·30 EJ
`
`c.!lo
`
`!.- ~
`
`I~ .lEI
`I &1r10 t.c>~tt I
`I blari!.AI
`)
`I
`I
`I
`I
`C.lh
`{; "
`
`tJTt
`
`NM
`'B.tli
`Nl,ll
`tH.Ill
`
`"
`
`l.'lf
`
`..
`"'"
`·~·
`
`tit
`ll;'lJ
`
`1M .,, .. r
`
`1
`l
`
`1
`
`l
`l
`I
`
`1
`
`1
`
`J
`
`u
`u
`
`BuySell Panel - 3 states: No Action state, Buy state- Sell state w/pressed Trade
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 6
`
`CONFIDENTIAL
`
`PH00000006
`
`Page 7 of 21
`
`

`
`After there is a successful request, the active Buy Selector or SellSelector is rendered inactive,
`preventing accidental repetition. When either of the two selectors are inactive, it is still visible as a
`button. When one of the two buttons is pressed, the other Selector becomes inactive if active, and the
`Selector of the pressed button becomes active. The pull downs retain the values that were set the last
`time they were used.
`• This extends Canvas
`• Requires access to the Serverlnterfacer for transmission of BSRequests
`• This object will need access to graphics.
`• Contains BuySelector
`• Contains SellSelector
`• Contains TradeButton
`Intercepts mousedown events directed at the TradeButton so that it can start the request process
`
`TradeButton This object is basically a button. It needs to communicate with its parent so that
`it can pass its event. It has three states: Inactive, Unpressed, and Pressed. It needs a graphic for each
`state.
`• Specially designed widget
`• Accesses images
`
`Trade Button 3 states: Inactive, unpressed, and pressed.
`
`PrimaryDisplayPanel This object contains the main Graph, its satellite objects, the
`ButtonBar, the Ticker, The AccountDisplay, and The Message Window. This keeps those objects
`organized.
`• Standard Java Panel
`• Uses BorderLayout
`• North: MessagePanel
`• South: GraphPanel
`
`J
`J
`u
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 7
`
`CONFIDENTIAL
`
`PH00000007
`
`Page 8 of 21
`
`

`
`1
`l
`1
`1
`
`J
`
`J
`
`J
`I
`J
`
`Primary Display Panel
`
`MessagePanel This object displays the AccountDisplay and the Message Window.
`• Extends Canvas
`• Contains AccountDisplay
`• Contains Message Window
`
`AccountDisplay This object will take the account information it requires and display the
`shares, average price, and value of the stock.
`• Displays itself inside of the MessagePanel
`• Might require images
`• Requires access to Account information and the current price of the stock
`
`Message Window This object is a scrollable listing of all the messages that need to be brought
`to the user' s attention. It announces order confirmations, errors, trades, etc.
`• Displays itself inside of the MessagePanel
`• Scrollable push down stack/list.
`
`ceoun -
`A
`t
`Sh:lmG
`
`-
`I 1,-.g. Pri~ I
`I
`I
`I
`I
`
`Y'Mio
`
`3/1198 5:34P lflJINTEL BUY TO COVER F/K GTC CASH 750$5.825=$4,936.875 ~
`
`.__ __________ --------- ~
`
`MessagePanel, AccountDisplay and Message Window
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 8
`
`CONFIDENTIAL
`
`PH00000008
`
`Page 9 of 21
`
`

`
`ButtonPanel This object contains the ButtonBar and the Ticker.
`• Extends Panel
`• Uses BorderLayout
`• North: ButtonBar
`• South: Ticker
`
`~-~~- -~~!L~~L -~- !~!..o< ~~t ~ _ ~! __ 2 __ :!~~-
`
`ButtonPanel with ButtonBar
`
`ButtonBar This object draws the buttons and handles the events. The current list of buttons
`are: Prefs, History, Account, Mail, Forums, News, Quote, Ticker, and Trade.
`Prefs: This causes the DisplayCardPanel to switch to the PrefsPanel.
`History: This will open up a new browser window containing a specialized display that plays
`back a "Movie" of the market's trading history.
`Account: This causes the DisplayCardPanel to swap to the InventoryDisplay.
`Mail: This will open a new page.
`Forums: This will open a new page.
`Chat: This will open a new page.
`News: This will open a new page.
`Quote: Depending on what this is supposed to do, it will either open a page or generate a
`message.
`Ticker: Toggles the Ticker on and off.
`Trade: Switches the DisplayCardPanel to the DisplayPanel
`• Extends Canvas
`• Accesses images (button images up and down)
`• Accesses Applet.showDocument()
`
`Ticker This object displays an animated ticker tape. It operates using its own thread and
`accesses pre-digested stock data via the Serverlnterfacer.
`• Extends Canvas
`•
`Implements Runnable
`• Animated
`• Accesses ticker data from the server.
`
`'STOCK TIEKER •.. AAPl 16 3/A •••• (;RCL
`
`33 7/A.-.
`
`Ticker
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 9
`
`CONFIDENTIAL
`
`PH00000009
`
`Page 10 of 21
`
`

`
`GraphPaneJ T his is the busiest Panel in the whole eli splay. It handles all the graphs and charts that
`make up the very heart of the clisplay. It makes use of numerous objects which draw themselves
`inside of the panel. This panel distributes the update data to these objects and causes them to draw
`themselves. Some of theses objects accept events, namely the price slider and the vertical slider (and
`their scroll buttons). This panel is redrawn at least every TTime.
`• Extends Canvas
`• Accesses images
`• Accesses data
`• Contains BuyerSellerGraph
`• Contains Galeries
`• Contains MainGraph
`
`Gm".6J Fmr!!!~~~~ffi
`
`A
`
`600
`
`GraphPanel
`
`BuyerSellerGraph (A) This object handles the vertical bar at the far left of the display and the
`two text readouts above and below it. It simply represents the percentage of participants who are
`buying versus the percentage who are selling.
`•
`Implements Draw Interface
`• Data access through parent
`
`Galleries (B) This object has not been fully explored. It is intended to quantitatively display
`the number of people participating or observing the market. Right now it is vertical red and blue bars
`with no real meaning.
`•
`Implements Draw Interface
`• Data Access
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 10
`
`J
`
`1
`
`1
`
`J
`J
`u
`
`CONFIDENTIAL
`
`PH00000010
`
`Page 11 of 21
`
`

`
`MainGraph (C) This object handles the main part of the graph. It lays out the horizontal
`background bars according to its set resolution, it writes in all the price number information, position
`information, draws the horizontal sliders, the vertical sliders and display boxes, the price sliders and
`display boxes, the green line, the red box line, and the horizontal volume indicator below.
`•
`Implements Draw Interface
`• Accesses images
`• Accesses data
`• Double buffering
`
`Following is a breakdown of the major components the Main Graph object draws
`Background: The background consists of the horizontal orange and white bars that are
`rendered behind the left and right side bars and the MainStage.
`LeftSidebar: (D) Three vertical columns to the left side of the graph indicate position
`information in two and include a price reference in the third.
`MainStage: This renders the rulers above and below the MainStage, scroll buttons, the
`horizontal slider, horizontal bars, position bar graph, the green line, and the red box line. The
`Horizontal slider is manipulated by clicking anywhere in the MainStage area, clicking on the scroll
`buttons, or by dragging the little red triangle. The red arrows indicate the difference between the green
`line and the red box line. The green line is derived from true stock value on the stock exchange and the
`red box indicates the internal value. The upper text box is green line value at that point along the line,
`and the bottom is red box line value.
`RightSidebar: (E) This renders a price reference column, and the price slider. The price
`slider is maneuvered up and down via red, triangular slider or via the vertical scroll buttons.
`V olumelndicator: (F) The volume indicator is a reference to the volume of trading
`throughout the day, as referred to by the bar graph. This might have to be dynamically scaleable.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 11
`
`CONFIDENTIAL
`
`PH00000011
`
`Page 12 of 21
`
`

`
`BuySelector: This object is a dialog of pulldown menus that set the various options for a buy
`request. Settings for BuyTransactionType, BuyOrderType, BuyDurationType, BuyAccountType, and
`BuyQuantityType may be manipulated through pull downs. The BuyQuantityType will also appear in
`a text box that will also accept a six digit user input. When the BuySelector is inactive, all the pull
`downs and text boxes are invisible and inactive. The only thing left is a button that can be pressed to
`reactivate the controls. The values of the controls are maintained until changed. Their initial settings
`can be a default rather than a preference.
`•
`Implements Draw Interface
`•
`Implements pull down menus and a text box
`Pull downs:
`BuyTransactionType: Buy, Buy to cover
`BuyOrderType: Market, Limit, Stop, All or None, Fill or kill
`BuyDurationType: Good until canceled, Day
`Buy AccountType: Cash, Margin, Short
`BuyQuantityType: 200, 100, 75, 50, 25, 10, 5, 1
`
`100
`
`Ei
`I
`I Bu~to CO\IEf J
`:I
`I
`I
`'
`I
`I
`Ca$h
`··8trr
`= -.:
`
`Fill or Kill
`
`GTC
`
`~!
`
`'
`
`All or None
`.. ·
`
`···t'5: ' · .. · • .. •: ~ -~ . . - -·.··
`, .. J~{J"-:.
`.
`·1 S~l from Portfolio I
`I
`·I
`I
`I
`I
`I
`EJ
`I
`
`GTC
`
`Ca$h
`
`100
`
`BuySelector - Sell Selector
`
`SellSelector This works very much like the BuySelector, except that it is for creating sell
`
`orders.
`•
`Implements Draw Interface
`•
`Implements pull down menus and a text box
`Pulldowns:
`SellTransactionType: Sell from portfolio, Sell short, Sell not in account
`SellOrderType: Market, Limit, Stop, All or none, Fill or kill
`SellDurationType: Good until canceled, Day
`SellAccountType: Cash, Margin, Short
`BuyQuantityType: 200, 100, 75, 50, 25, 10, 5, 1
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 12
`
`CONFIDENTIAL
`
`PH00000012
`
`Page 13 of 21
`
`

`
`5. SERVER SIDE OPERATIONS4
`
`ServerConnection This object creates a pipe to the server, sends out requests and gets back a
`response. It has to allow for other events to occur while waiting for a response. This has a built in
`time-out that throws an exception in case of response failure. Otherwise, it returns either a
`confirmation or other requested object.
`• Socket
`• Timeout
`•
`Implements ServerRequest Interface
`
`Serverlnterfacer This object creates, manages and ensures the destruction of server
`connections. It manages an interaction thread that is active whenever there is a connection open. This
`thread checks for responses from the connections and yields the processor for other events.
`•
`Implements ServerRequestlnterface
`
`Account This object is a transport class to encapsulate account data. This account data
`includes inventory, cash reserves, and other information.
`
`Preferences This object contains the applet preferences for communication to and from the
`
`server.
`
`TTime This class contains all the information necessary to display the applet that is available
`to all users, pre-digested and ready for consumption by the display classes. User specific information
`is updated less often via the BigFrame. TTime has a time stamp and a expiration date.
`
`BigFrame This object contains all the user specific information necessary for the client.
`Information like positions and other data are transmitted via this method. Each client receives his own
`tailormade BigFrame. Orders remain in transitional states until confirmations come in. The client
`maintains its own BigFrame, only occasionally requesting one to synchronize with the server in the
`event of error or a certain amount of time/traffic has occurred.
`
`BSRequest This class contains all the information necessary to place a buy or a sell order.
`This is passed to the Server and a confirmation in eventually sent back. This also is the vehicle by
`which a cancellation is issued.
`
`Confirmation This is proof that an order (or cancellation their of) has occurred.
`
`TThread This is the main thread for the process. It handles Data manipulation and
`distribution, client/server synchronization, and data integrity.
`• Contains current TTime
`• Contains "current" BigFrame
`• Contains UpdateTimer
`• Contains Account
`• Contains Serverlnterfacer
`• Contains GraphicPanelList
`
`4 See Appendix for detailed process diagrams
`confidential
`Trading Game Design Document vl.O
`
`• page 13
`
`CONFIDENTIAL
`
`PH00000013
`
`Page 14 of 21
`
`

`
`GraphicPanelList This object maintains a listing of all graphic objects that require repaint()
`events. It uses these to distribute data to the objects that need it.
`
`UpdateTimer This object is driven and polled by the TThread. When it is time for a TTime,
`the request goes through. The TTime that comes back is used to update this object as to any changes
`to the T duration. It also advises the TThread when it is time to load a BigFrame.
`
`Server Request Interface This interface defines a set of functions through which the client
`requests data from the server.
`• boolean sendRequest(BSRequest)
`• Confirmation waitForConfirmation(ServerConnection)
`• Account getAccount()
`I I get full TTime
`• TTime getTTime()
`• TTime getTTime(TTime) I I attempt to get update
`• BigFrame getBigFrame()
`• Sting[] getTickerlnfo()
`• Preferences getPrefs()
`• void setPrefs(Preferences)
`
`II retrieves Ticker information
`
`Draw Interface This interface defines a single function intended to allow the object to draw
`itself into the provided Graphics context at the specified location. It makes building complex graphic
`objects easier.
`• void draw(Graphics, x, y)
`
`6. OTHER SOFTWARE AND SERVICES
`
`We recommend obtaining off-the-shelf software relational database package or contracting
`with the professional services groups of companies which offer the back office account management
`software for financial services. These systems are beyond the scope of this Design Document, but
`generally they are standard function blocks with which the trading server will be able to easily
`communicate. We can define the object fields and then "wire up" the final database to the objects at a
`later date.
`
`Account Management and Audit -
`Oracle offers a range of off-the-shelf relational database packages for banks, stock clearing
`houses, etc. They also can refer us to third party developers who can license complete solutions. The
`basic package costs about $47,000 annually for the license, plus $11,000 a year for maintenance,
`service and upgrades. The software is designed for Unix, but will also run on NT. We recommend
`that Unix be used when real money is transacted due to the higher reliability, scalability and recovery
`capabilities.
`The actual price of customizing this package and the ancillary hardware, software and license
`will require additional refinement of the design and business objectives.
`
`Ticker and News
`Dow Jones, Reuters and Bloomberg offer ticker information systems with a choice of
`domestic or international markets, delay times, and data rates.
`.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 14
`
`CONFIDENTIAL
`
`PH00000014
`
`Page 15 of 21
`
`

`
`The critical issue with the Ticker will be the contractual arrangements with the ticker provider.
`Depending upon the Trading Game business model, these services may view the dissemination of
`real-time quotes such as our system may provide to be an unapproved use of their data. For example,
`if a user can get data just as quickly from our display, why pay $1,600 a month to Bloomberg?
`Regarding pricing, Bloomberg provides US market informatoin on 56K or ISDN dedicated
`tickers to a Windows API for $1,640 a month, with a 2 year guarantee. There is an installation fee of
`$300. They do not have T1 feeds at this time. Bloomberg says we can also use their News, but again,
`our application may not be in keeping with their contractual requirements.
`
`Forums and Discussion Groups
`Offering threaded discussion groups is another way to extend the community of trading
`customers. An example would be Silicon Investor. The distinction for the Trading Game is that our
`products may be unique to our service and will generate different discussion topics than general
`market information sources.
`Well Engaged Software offers their Discussions 1.5 as a service which is maintained on their
`servers or as an outright product purchase with a onetime license and optional maintenance packages.
`Product
`0- 50,000 active users$15,000
`50,001 - 150,000 users
`$30,000
`Unlimited users
`$50,000
`Maintenance
`Weekday
`2417
`Service Bureau
`Setup Fee
`<1,000 Active Users
`<5,000 Active Users
`<10,000 Active Users
`<50,000 Active Users
`
`$3,500- $10,000
`$ 500/mo
`$1,750/mo
`$3,000/mo
`$5,000/mo
`
`15% of license annually
`30% of license annually
`
`Chat
`The chat vendors are undergoing rapid aggregation at this time. It is probable that the $1,500-
`$30,000 license fee quoted for iChat software will be reduced.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 15
`
`CONFIDENTIAL
`
`PH00000015
`
`Page 16 of 21
`
`

`
`7. FEATURES NOT INCLUDED IN RELEASE 1.0
`
`There are many requested features which cannot be delivered reliably to heterogenous users
`with current technology. Some of these may change in the next 6-12 months, but the recommendation
`is to assign these to release version 2.0 or 3.0.
`
`• Payment System - the system will be able to accept credit cards, but other
`payment systems with check or wire transfers will be required. E-cash systems
`will probably not be suitable until Rei 2.0
`• Sound - maybe Rei 1, but this is still very buggy and also consumes lots of time
`during initial log in and download.
`• Gallery or Bleachers - still needs to be defined
`• Competitor Tracking - will probably require too much data and slow down trading
`• Avatars or Icons - will probably require too much data and slow down trading
`• Analysis services- Rel2.0
`
`8. APPENDIX
`
`• Client - Client/Server Interface and Server Processes Diagram
`• Server Flow Diagram
`• Transaction Flow Diagram
`• Process Loop Diagrams
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 16
`
`CONFIDENTIAL
`
`PH00000016
`
`Page 17 of 21
`
`

`
`IntErnet
`
`Cliertl Server
`lnt«face
`
`Server Processes
`
`Ticker
`Requests
`
`TTime
`Requests
`
`I
`J
`
`Update
`Requests
`
`l
`J
`
`Big frame
`Requests
`
`1
`J
`
`I
`(
`
`I
`(
`
`Account
`Requests
`
`Login
`Requests
`
`Buy/Sell
`Requests
`
`SOTO
`Request
`Manager
`
`Bigframe
`
`TTime
`
`TTi me Delta
`(Update)
`
`Ticker
`
`'--------'--User Confirmation
`
`Buy/Sell
`Request
`Manager
`
`Distinction of Client - Client/Server Interface and Server Processes
`
`This diagram represents which processes will be executed in the Java client (the browser),
`which need to be maintained between the server and the client, and which take place on the server.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 17
`
`CONFIDENTIAL
`
`PH00000017
`
`Page 18 of 21
`
`

`
`TtckerSOTO
`( Derfved from
`Mar ket Emulator)
`
`Status Update
`SOTO
`
`Full Status
`SOTO
`
`Accounting
`SOTOs
`
`Client
`
`•
`
`Server Flow Diagram
`
`This diagram represents some of the larger function blocks within the server and how they
`trade data with each other.
`
`. I
`
`J
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 18
`
`CONFIDENTIAL
`
`PH0000001 8
`
`Page 19 of 21
`
`

`
`Transaction Flo\-\'
`
`Sell List
`(By Position/FIFO)
`
`Buy List
`(By Position/FIFO)
`
`Tnne
`
`Transaction Flow Diagram
`
`Transaction Flow is the critical process which is central to the trading system. Below the
`TTime line represents the part of the process which takes place after all buys and sells have been
`submitted by traders. The Priority Arbitrator and Match Buy to Sells blocks will potentially be
`complex algorithms which will need to have fine tuning controls for the market maker.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 19
`
`CONFIDENTIAL
`
`PH00000019
`
`Page 20 of 21
`
`

`
`Main proccess bop
`
`Check TTime
`
`Time
`
`ThroV\6
`Excefibn
`
`Handle C I ie nt Request:
`
`Time
`
`TThread
`
`nmegetnme()
`BigFrarne getBigFrarne()
`
`Returns
`Time or
`BigFrarne
`
`Server I nte rface r
`Spawns a
`Serve reo n necti on
`
`ThroV\6
`Excep:bn
`
`TT h read. Request ( )
`
`TThread
`Passes to
`Server I nterfacer.
`request()
`
`Server I nte rface r. Request ( )
`
`Returns
`Confirm(cid:173)
`ation
`
`Spawns a
`Serve reo n necti on
`
`Confirmation communicates any
`errors. An error in a request will flag
`Time to get a BkJFrame to show
`wether the request got through the
`irternetor not. Time will avoid
`Hrapid fire" BigFrame requests.
`Process Loop Diagrams
`
`These process loops represent in more detail how the logic in the client will use the TTime to
`control other processes.
`
`confidential
`
`Trading Game Design Document vl.O
`
`• page 20
`
`CONFIDENTIAL
`
`PH00000020
`
`Page 21 of 21