Abstract:
Systems and methods of selling employee stock options (ESOs) and other compensation instruments. The method may comprise the steps of receiving a sale order for the employee stock options from a seller, where the sale order indicates the price of the employee stock options to be sold and the number of employee stock options to be sold. The method may also comprise the step of determining a winning bidder, from the at least two bidders, of an auction for the employee stock options based on bids submitted by the at least two bidders that specify a price for the employee stock options. The method may further comprise suspending the auction until there are qualifying bids from at least two bidders. The method may also comprise transferring a derivative in place of the employee stock options to the winning bidder, wherein the derivative entitles the holder thereof to buy a quantity of securities of an issuer at the price. The method may also comprise transferring net proceeds from the sale of the employee stock options to an account of the seller.

Description:
BACKGROUND 
       [0001]    The present invention is related generally to systems and methods for selling employee stock options or other instruments provided as part of a compensation program. 
         [0002]    Many corporations issue stock options to some of their employees as part of their compensation plans. Employee stock options (“ESOs”) are option contracts that give the employee the right, but not the obligation, to buy a certain amount of shares in their employer (the stock issuer) at a predetermined price (“the strike price”). In most circumstances, an employee must wait a specified period (the “vesting period”) before being allowed to exercise the options. Also, ESOs are generally not transferable. 
         [0003]    An ESO is considered to be “underwater” or “out-of-the-money” when the strike price is greater than the price at which the stock is trading. When an ESO is underwater, it typically has little or no value to the employee, although it may have a higher theoretical option value. 
         [0004]    Published U.S. patent application Pub. No. 2005/0114242 discloses a system and method for the transfer of ESOs. In the process described in this published patent application, the issuer (e.g., the employer) issues a transferable ESO to an employee. A holding entity, through its broker-dealer, creates a bid for the ESO, which is submitted to the employee, who can decide whether or not to sell the ESO at the bid price. If the employee decides to sell the ESO, the broker-dealer buys the ESO from the employee for the bid amount with either cash or stock. 
         [0005]    In another embodiment disclosed in the above-mentioned published patent application, the issuer issues ESOs to an employee having the conventional restrictions on transferability. At some point in time, the issuer determines that some of the employee&#39;s ESO should be transferable. The issuer, working with the broker-dealer, determines which of the employee&#39;s ESOs should be transferable. The broker-dealer then develops an option-price grid for those ESOs. The option-price grid is a grid that indicates the price for the ESOs based on the strike price for the ESOs and the trading price of the issuer&#39;s stock. After receiving the option-price grid, the employee has a period of time to decide whether to sell the ESOs at the price indicated by the option-price grid. If the employee decides to transfer the ESOs, the employee transfers the ESOs to the issuer. The issuer receives the payment for the ESOs from the broker-dealer and, in exchange, the issuer transfers amended ESOs to the broker-dealer. The employee also receives the payment for the options transferred to the issuer. 
       SUMMARY 
       [0006]    In one general aspect, the present invention is directed to systems and methods for selling employee stock options (ESOs) or other instruments provided as part of a compensation program. According to various embodiments, the method may comprise the step of receiving bids from at least two bidders. The bids may each indicate a quantity of the ESOs to be bought at an offer price. The method may also comprise the step of receiving a sell order from a seller (e.g., an employee having ESOs) where the sell order indicates the number of ESOs to be sold. The sell order may also indicate the price and/or the strike date for the ESOs. A winning bid may be selected in an auction-type format, where the winning bid has the highest offer price and a bid size quantity that is at least the number of ESOs to be sold. 
         [0007]    After a winning bid is selected, the issuer of the stock underlying the ESOs may then issue a derivative (e.g., a warrant, an over-the-counter (OTC) option, etc.) to replace the ESOs, which derivative is eventually transferred to the winning bidder. There may be more than one winning bidder if more than one winning bidder submits the highest offer price. In such circumstances, the ESOs may be awarded pro rata to the winning bidders. Also, the net proceeds from the sale of the employee stock options are transferred to an account of the seller. The derivative issued to replace the ESOs may entitle the holder thereof (e.g., the winning bidder unless subsequently transferred) to purchase a specified quantity of shares of stock (or other securities as the case may be) issued by the issuer, the quantity corresponding to the quantity of options (or other instruments as the case may be) sold pursuant to the sale order. 
         [0008]    Further, the auction may be suspended until such time as there are at least two bidders with qualifying bids, e.g., non-zero price bids with quantities equal to or greater than the quantity to be sold in the auction. Also, various bidder protection and bidder anonymity safeguards may be used. The anonymity safeguards may include that the identity of the winning bidder and/or the winning offer price is not revealed to the nonwinning bidders. Also, the sale orders and the bids of other bidders may not be revealed to the other bidders. 
         [0009]    In another general aspect, the present invention is directed to an ESO transaction system. According to various embodiments, the system may comprise at least one transaction engine for executing ESO transactions. In various implementations, the transaction engine may be programmed to suspend execution of a transaction (e.g., an auction) when there is less than two bidders with qualifying bids. 
         [0010]    In various embodiments, the system may also comprise an analytics engine in communication with the transaction engine. The analytics engine may be configured to compute statistics associated with transactions performed through the ESO transaction system. For example, the analytics engine may be configured to provide the seller with various data, including an ESO price from the highest pending bid, an estimated fair price of the ESOs, a premium value over the intrinsic value of the ESOs, etc. The analytics engine may also be configured to provide the various bidders with their success rate in transactions handled by the system over a given amount of time. Various other analytics regarding transactions performed by the system may be provided to the issuer of the ESOs. 
         [0011]    These and other features of the present invention will be apparent from the description below. 
     
    
     
       FIGURES 
         [0012]    Various embodiments of the present invention are described herein by way of example in conjunction with the following figures, wherein: 
           [0013]      FIG. 1  is a diagram of an employee stock option transaction system according to various embodiments of the present invention; 
           [0014]      FIG. 2  is a flow chart of a process by which an AMM system may communicate bids to the transaction system according to various embodiments of the present invention; 
           [0015]      FIG. 3  is a chart illustrating the transaction process according to various embodiments of the present invention; 
           [0016]      FIGS. 4 and 5  are diagrams illustrating a settlement process for the sale of employee stock options according to various embodiments of the present invention; 
           [0017]      FIGS. 6-10  and  12  are screen shots of user interfaces that an employee may access according to various embodiments of the present invention; 
           [0018]      FIG. 11  is a diagram of a process flow of a method for determining a fair value of an employee stock option according to various embodiments of the present invention; and 
           [0019]      FIGS. 12-21  are screen shots of user interfaces the issuer (or somebody acting on behalf of the issuer) may access according to various embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0020]    The present invention is directed generally to systems and methods for transacting sales of employee stock options (ESOs) or other instruments provided as part of a compensation program (such as restricted stock). Various embodiments of the present invention will be described below in connection with ESOs, but it should be recognized that the embodiments are generally applicable to these other instruments as well. The term “compensation instruments” is used herein to refer to both ESOs and such other instruments provided as part of compensation program (including restricted stock or other types of equity or debt securities or derivatives) unless otherwise noted. 
         [0021]      FIG. 1  is a diagram of an ESO transaction system  10  according to various embodiments of the present invention. An ESO typically specifies an exercise (or strike) price and an exercise (or strike) date. The ESO entitles the employee (assuming the ESOs have vested) to purchase stock of the issuer (e.g., the employee&#39;s employer) at the strike price on or before the strike date. The transaction system  10  may permit one or more sellers  12  holding ESOs issued by an issuer  14  to sell their ESOs to one or more bidders  16 . In various embodiments, the bidders  16  may be chosen by invitation. For example, the bidders  16  may be invited to participate by an administrator of the transaction system  10 , by the issuer  14  of the ESOs, etc. In  FIG. 1 , only three sellers  12  and three bidders  16  are shown for the sake of simplicity. There may, of course, be more or fewer sellers and bidders. 
         [0022]    The sellers  12  (e.g., employees of the issuer  14  having ESOs) may submit sell orders for some or all of their ESOs to the transaction system  10  via a communications network, such as a secure TCP/IP network  18 . Because corporate employers typically issue numerous ESOs to their employees having different strike prices and/or different strike dates, the sellers  12  may specify the option grant from which the seller  12  wishes to sell ESOs as well as the number of options they wish to sell in their sell order using a web-based interface, as described in more detail below. By specifying the option grant, the strike date and strike will be known. Typically, all ESOs in an option grant awarded to an employee will have the same strike price, although an employee may be awarded numerous option grants, some or all having different strike prices. The sell order may be received by one or more host computer systems (referred to hereinafter as “host”)  19  associated with the transaction system  10  and routed to a transaction engine system  24  by a router  26 . 
         [0023]    A product may be considered an ESO having a certain strike price and/or strike date. For ESOs having a strike date more than two years away, the strike date may be truncated to two years for ESOs sold through the transaction system  10 . Because companies typically award option grants to different employees and at different times, there may be numerous options with different strike prices (e.g., different products issued by the issuer  14  over time). To efficiently handle the numerous possible products, the transaction engine system  24  may include a number of parallelized transaction engines  28 . Each transaction engine  28  may be provisioned to handle the transactions for different groupings of products. That is, for example, a first transaction engine may be provisioned to execute the transactions for products having a strike price between $0 and $150, a second transaction engine may be provisioned to execute the transactions for products having a strike price between $150 and $300, a third transaction engine may be provisioned to execute the transactions for products having a strike price greater than $300, and so on. In various embodiments, the different transaction engines  28  may conduct transactions for different products (e.g., different strike prices) in parallel. Data regarding the products may be stored in a products database  33 . The router  26  may route messages pertaining to a seller&#39;s sell order to the appropriate transaction engine  28  based on the product specified in the seller&#39;s sell order. Three transaction engines  28  are shown in the example of  FIG. 1 , although it should be recognized that the number of transaction engines  28  may be scaled accordingly, based on the number of products, for example. 
         [0024]    As shown in  FIG. 1 , the transaction system  10  may also include an analytics engine  36 . The analytics engine  36  may analyze the transactions executed by the transaction system  10 , and various outputs of the analysis, in the form of charts and tables, for example, may be served to the sellers  12 , the issuer  14 , and the bidders  16  via the TCP/IP network  18 , as described in more detail below. The charts and tables may be contained in web pages that are served to the sellers  12 , the issuer  14 , and the bidders  16  by a server  20  of the host  19 . 
         [0025]    The bidders  16  may place bids using automated market-maker (AMM) systems  30 . The bidder AMM systems  30  may communicate with the transaction system  10  via a two-way communication link  32 , such as a leased communication link.  FIG. 2  is a simplified diagram of the process flow by which one of the AMM systems  30  may communicate bids to the transaction system  10  according to various embodiments of the present invention. At block  40 , the transaction system  10  may authenticate the AMM system  30 . This may be done by a bidder authentication server (not shown) associated with the transaction system  10 . Once the AMM system  30  is authenticated, at block  42 , the transaction system  10  may serve a file to the AMM system  30  containing a listing of the products. The product listing may correspond to the options granted by the issuer  14  and may specify, for example, the strike price and/or strike date for each ESO. For ESOs where the strike date is more than two years away, the strike date may be truncated to two years. At block  44 , the AMM system  30  may transmit a file to the transaction system  10  containing its bids for the various products. The bids may specify a price and quantity for each product. At step  46 , a router  34  (see  FIG. 1 ) may route messages to the appropriate transaction engines  28  based on the bids from the AMM system  30 . That is, the router  34  may route bid information for certain products to the transaction engine  28  that is handling the transactions for that product. The transaction engines  28  may add the bid information to their book in order to execute the transactions, as described in more detail below. 
         [0026]    During the time the system  10  is active (e.g., market hours), each bidder may be required to continuously maintain a qualifying bid for each product handled by the transaction system  10 , unless the bidder  15  or its corresponding AMM  30  is disabled by technical difficulties. The qualifying bids for each product may also have a required minimum number of options (e.g., 1,000 options). For example, each bidder may be required to maintain a bid on 1,000 options of each product handled by the transaction system  10 . In various embodiments, a zero dollar bid, (e.g., a bid offering nothing for the minimum number of options) may be acceptable. That is a zero dollar bid may be considered to be a qualifying bid. A bidder may be motivated to submit a zero dollar bid, for example, for a product that is far “out of the money.” 
         [0027]    According to various embodiments, the transaction system  10  may require that the price bids from the bidder  16  be in certain size increments, such as five-cent increments, for example. In such embodiments, to accommodate various AMM systems  30 , the transaction system  10  may also interpret certain bids, such as one cent bids, as qualifying zero dollar bids. Zero dollar bids and bids treated as zero dollar bids may be qualifying bids as far as the above-described requirement that all invited must continuously maintain qualifying bids, but such bids may be treated as being incapable of winning the auction by the transaction system  10 . If all of the bidders make zero dollar bids, the auction may be suspended until such time as there is at least one valid non-zero dollar bid. 
         [0028]    Preferably, as described further below, the various bidders  16  are not aware of any other bidder&#39;s bids. In various embodiments, the bidders  16  also may not be aware of how many other bidders, if any, are active, or even if any sell orders are pending. 
         [0029]    In various embodiments, sellers may be permitted to submit a sell order at any time. During market hours, the sellers may be provided with an indication of the highest pending bid for a given product before making a sell order for that product. Orders submitted aftermarket hours may be queued for execution during market hours on the next trading day. In order to promote fairness, there may be a limit on the number of options a seller may sell in one transaction. That limit may match the minimum bid number and may be 1,000 options, for example. That is, in any one transaction, a seller may be prohibited from offering more than 1,000 options at a particular strike price/strike date. A seller may be permitted, however, to place several orders to sell options having the same strike price and/or strike date such that, in the aggregate, more than 1,000 options are offered. 
         [0030]    According to various embodiments, sellers may be permitted to place market orders, limit orders, or both. A market order is an order to sell the ESOs at the highest bid price available when the order is considered. A limit order is an order in which the seller specifies the price (e.g., a “limit” or “reserve” price) for the ESOs. When the specified price is reached or exceeded, the options are sold at the bid price. In various embodiments, the limit order may also set forth a time period. If the specified price is not reached within the time period, then the order may be cancelled. Also, in some embodiments, a seller may be prohibited from placing sell orders (either limit or market orders) for ESOs that are close to expiration, such as within six months of expiration. 
         [0031]    Sell orders may be processed by the transaction system  10  on a first-in, first-out basis (or queue). Such a first-in, first-out time order may also apply in embodiments where sellers are allowed to submit both market and limit orders. According to various embodiments, there must be a required minimum number of active bidders (e.g., two bidders who have made the required minimum bid) for a transaction to occur; otherwise, the transaction is suspended. That is, for example, the transaction engines  28  may be programmed to handle a queued order only if there are at least two bidders whose bid size is greater than the number of options in the queued order. As described in more detail below, the transactions may be suspended until such time that one or more of the AMM systems  30  can refresh their bids so that there are at least two participating bidders. It will also be appreciated that the minimum number of bidders may be greater than two as well. 
         [0032]    According to various embodiments, the sale of the ESOs may be conducted according to an auction. For example, the highest bid pending when a sell order is considered wins the auction. If a tie occurs, the order may be split pro rata among the winning bidders. Any remaining odd share may be awarded randomly to one of the winners. 
         [0033]    Preferably, the auctions follow certain bidder anonymity safeguards. For example, only the winning bidder may be notified that it has won the order. The other bidders may not be notified that they lost the order and, in various embodiments, the nonwinning bidders may not even be aware that an order has been considered. That is, in various embodiments, the bidders are not made aware of the sale orders in the execution queue (whether market or limit orders), and the nonwinning bidder may not even know that an auction has occurred. The winning bidder(s), of course, receive notification of their winning bids. Also, the bidders preferably are not made aware of the bids by the other bidders. Further, the identity of the winning bidder(s) is preferably not revealed to the nonwinning bidders. In various embodiments, however, each of the bidders may be provided with a success rate, or “batting average,” information regarding their bidding that discloses to each of the bidders individually and privately the percentage of sell orders won by the bidder in each product category, as described in more detail below. In such an embodiment, the transaction engines  28  may be programmed to: (i) not notify the bidders of bids from other bidders; (ii) not notify the bidders of the sale orders in the queue prior to the auction; (iii) not notify the nonwinning bidders that the at least one winning bidder has been determined for the auction; and/or (iv) not notify the nonwinning bidders of the identity of the at least one winning bidder. 
         [0034]    Although most of the embodiments described herein require at least two bidders, in other embodiments of the present invention, there may be no requirement regarding the minimum number of bidders. For example, in such embodiments, only one bidder may participate. Some or all of the above-described anonymity safeguards may apply in such auctions. 
         [0035]    According to various embodiments, after a bidder wins an order for a given product, the bidder&#39;s current size bid for the product may be decremented accordingly. If, as a result, the bidder&#39;s current bid for the product is for fewer shares than the next sell order for that product in the queue, the transactions may be suspended until the bidder (e.g., its associated AMM system  30 ) has refreshed its bid to the minimum amount (e.g., 1,000 shares). For systems supporting limit orders, the sale of limit orders may not be guaranteed if a limit price is reached and bids at the limit are exhausted before all limit orders at that price are filled. 
         [0036]    Because ESOs are typically not transferable, upon the successful completion of transactions (preferably at the end of the day) the issuer  14  may be notified of the ESOs sold through the transaction system  10 . The issuer  14  may then rescind the ESOs and in their stead issue replacement derivations (e.g., warrants, over-the-counter (OTC) options, etc.) to purchase stock of the issuer at the strike price. According to various embodiments, the derivations issued by the issuer  14  in place of the sold ESOs may have an expiry that is equal to the lesser of the current term on the sold ESOs or some predetermined time period, such as two years. The issued derivations may then be delivered to the winning bidder, and an account of the seller may be credited with the sale proceeds (less tax withholdings). In various embodiments, the issued derivations may be delivered to the winning bidder through an intermediary, for example, as described in more detail below. 
         [0037]      FIG. 3  is a chart showing an example of how a number of bids and sell orders for a particular product may be executed. In this example, the products are ESOs with a strike price of $350, and the minimum number of bidders is three. It will be appreciated that other various embodiments may have a minimum number of bidders higher or lower than three. The transaction for the first order in the queue may commence at 9:30 a.m. EST. At this time, bids from three bidders are present: 
         [0000]                                                  Bidder   Quantity   Price                                Bidder 1:   1,000 Options   $100       Bidder 2:   1,000 Options   $90       Bidder 3:   1,000 Options   $99                    
The first sell order, considered at 9:30:01 am EST is for 800 options. Based on the pending bids, Bidder 1 wins, and 800 options (i.e., the winning allotment) are decremented from Bidder 1&#39;s bid size quota offer. Accordingly, Bidder 1&#39;s pending bid is now for 200 options. At 9:30:02, Bidder 3 updates his bid to $102, and the system  10  attempts to consider a second sell order for 500 options. It can be seen, however, that the pending bid of Bidder 1 is still less than the minimum requirement and also less than the amount of the second sell order. Accordingly, there are only two bidders with qualifying bids. Because the minimum number of bidders in this example embodiment is three, consideration of the second sell order may be suspended until the AMM system for Bidder 1 can refresh its bid.
 
         [0038]    Bidder 1 refreshes its bid to 1,000 options at $99 by time 9:30:06. Accordingly, all three bidders now have qualifying bids. Based on the pending bids, Bidder 3 wins the second sell order, and 500 options (the winning allotment for the second transaction) are decremented from Bidder 3&#39;s option bid size. By 9:30:08, Bidder 2 has refreshed its bid to $103, and a third sell order for 400 options is considered. Although Bidder 3&#39;s bid is now for 500 options at $102, it may still be a qualifying bid because it recites a number of options (e.g., 500) greater than the number recited by the third sell order (e.g., 400). Accordingly, because there are three qualifying bids pending, the third sell order is won by Bidder 2, and Bidder 2&#39;s pending bid is decremented accordingly. 
         [0039]    Because there are no more sell orders in the queue, no transactions are executed at time 9:30:09. Bidder 2 and Bidder 3 are still in the process of refreshing their bids at this point, but because both Bidders 2 and 3 have a pending bid for at least 500 options, a sell order of 500 options or less (including either a limit or market order) could have executed at this time had it been in the queue. By time 9:30:10, the bids for both Bidder 2 and Bidder 3 have been refreshed, but there are still no sale orders in the queue, so the bidders will have to wait for the next transaction. 
         [0040]    If a bidder does not refresh its bids within a certain time period (e.g., two minutes), the transaction system  10  may consider that bidder to be out of the auction. If the minimum number of required bidders is still satisfied without the lost bidder, the transactions may proceed without that bidder. However, if the minimum number of required bidders is not satisfied without the lost bidder, the ESO transactions may be suspended until such time as there is a sufficient number of bidders. 
         [0041]    Limit orders may be executed in a time sequence, too. For example, if a limit order for a particular product is placed prior to a market order for the same product, if a bid meeting or exceeding the limit price specified in the limit order is received and that meets or exceeds the number of options being sold in the limit order, the limit order will be filled before the market order. In such a circumstance, the bid from the winning bidder may have to be refreshed before the next order in the queue is executed. 
         [0042]    According to various embodiments, the transaction system  10  may also implement bidder protections. For example, the bidder protections may protect a bidder from winning too many transactions in a certain time period. For example, if a particular bidder wins bids for ESOs within a certain time frame (e.g., five seconds) or number of auctions that exceed a predetermined threshold quantity (e.g., ten thousand ESOs across all products), the transaction system  10  may suspend auctions involving that bidder and send a communication to the bidder (e.g., an email) querying whether it intended to win all of those auctions. Such a bidder may be suspended from all auctions until it confirms that it intended to win the auctions. Such bidder protection mechanisms may be provided by a bidder protection engine (not shown) of the transaction system  10 . The bidder protection engine may aggregate and analyze the auction data from across all of the transaction engines  28  to implement such bidder protections. The bidder protection engine may also initiate the communication to a bidder who wins too many auctions in the defined time period. 
         [0043]    According to various embodiments of the present invention, employees with ESOs may sign or otherwise assent agreement to a new covenant that makes the ESOs transferable to a particular party, such as the entity operating the transaction system  10  (e.g., an “auction agent”), if sold through the program associated with the transaction system  10 . For ESOs that are sold through the program, the sellers  12  may sell their ESO to the auction agent. The issuer  14  may then rescind the ESOs and, as described further below, issue in their stead the replacement derivatives (e.g., warrants, options (e.g., OTC options, etc.) that the auction agent may sell to the winning bidder. The proceeds from the sale may then be transferred to the seller  12  (less tax withholdings, etc.). The replacement derivatives sold to the winning bidder may or may not have restrictions on transferability. If they do not have such restrictions, the replacement derivatives may be sold/bought in an aftermarket. 
         [0044]      FIGS. 4 and 5  illustrate a process by which the sale of the ESOs may be settled. For purposes of the illustrated embodiment, settlement may occur through the Depository Trust Company (“DTC”)  62 . The DTC is a central securities certificate depository owned by brokerage houses through which members effect security deliveries between each other via computerized bookkeeping entries, although it should be recognized that in other embodiments a different repository may be used. 
         [0045]    According to the illustrated embodiment, at the end of the day (e.g., after the time period for the transactions has ended), starting at step  50 , the transaction system  10  may notify the plan administrator  64  of all the executed orders (e.g., market and limit orders) that occurred during the day. The plan administrator  64  may be the entity which administers the employee stock option plan of the issuer  14 . As part of this step, the transaction system  10  may deliver a file to the plan administrator  62  that, for each transaction executed during the day, identifies: the seller ID, the grant ID, the trade ID, the grant price, the quantity, the trade price, etc. Similarly, at step  51 , the transaction system  10  may notify the issuer  14  (and/or its transfer agent (not shown)) of the transactions executed during the day. The data delivered to the issuer  14  (and/or its transfer agent) may be similar to the data delivered to the plan administrator  64 . 
         [0046]    According to various embodiments, step  51  may be performed before step  50 , or the steps could be performed simultaneously. Also, either or both of the notifications of steps  50  and  51  may occur in real time or near real time. That is, for example, according to various embodiments, the issuer  14  (and/or its transfer agent) may be notified of each executed transaction shortly after the transactions are completed throughout the day, whereas the plan administrator  64  may be notified at the end of the day of all transactions that occurred during the day. 
         [0047]    At step  52 , the transaction system  10  may establish two missions with the DTC  62 . One mission may be the establishment of a receivable to accept the derivatives issued by the issuer  14  to replace the sold ESO. This receivable account may be associated with the system  10  and/or an administrator or provider of the system  10  (e.g., the plan administrator, a third-party financial institution, etc.). The second mission may be a DVP (delivery versus payment) order to deliver the derivatives (when received) to an account of the winning bidder  16  in exchange for payment of the sale proceeds from the winning bidder  16 . As indicated in  FIG. 4 , steps  50 - 52  may occur the day (denoted as “Day T”) of the executed transaction. 
         [0048]    At step  53 , the issuer  14  (and/or its transfer agent on behalf of the issuer  14 ) may rescind the seller&#39;s ESOs and, in their place, write the corresponding replacement derivatives, and deliver the derivatives to the DTC account associated with the transaction system  10  created in step  52 . 
         [0049]    Upon receipt of the replacement derivatives at the DTC account associated with the transaction system  10 , the DVP order may be triggered. As such, at step  54 , the winning bidder  16  may accept the issued derivatives into its DTC account from the DTC account associated with the system  10 . A simultaneous transfer of finds covering the sale price may be made to the DTC account associated with the transaction system  10 . Accordingly, in various embodiments, the replacement derivatives may be issued to the transaction system administrator, who in turn sells them to the winning bidder. 
         [0050]    At step  55 , the funds may be transferred from the DTC account associated with the transaction system  10  to the plan administrator  64  (e.g., minus any commission due to the system administrator  10 ). According to various embodiments, the transfer may use the Fedwire electronic transfer system. This transfer may also be a nightly feed for all proceeds for Day T. At step  56 , the transaction system  10  may receive from the DTC  62  a report detailing all activity in its DTC account and all pending DVP missions. At step  57 , the transaction system  10  may transfer to the plan administrator  64  a file detailing all settlements for the day as well as any outstanding transactions awaiting payment from bidders  16 . 
         [0051]    At step  58 , the plan administrator  64  may deposit the net proceeds from the ESO transactions in the employees&#39; accounts  65  (less tax withholding, for example). At step  59 , the plan administrator  64  may deliver the tax withholding to the issuer  14  (and/or its transfer agent) via Fedwire, for example. At step  60 , the plan administrator  64  may report the sellers&#39; supplemental income from the sale of the ESOs to the payroll administrator  66  for the issuer  14 . And at step  61 , the plan administrator  64  may send a batch file to the transaction system  10  with confirmation of all settlements on day T. 
         [0052]    According to various embodiments, as indicated in  FIG. 4 , steps  53 - 54  may occur the following business day after the sale of the ESOs (Day T+1), steps  55 - 57  may occur within two business days following the transaction (Day T+2), and steps  58 - 61  may occur within three business days following the transaction (Day T+3). That way, settlement may occur within three business days following the transaction. In other embodiments, settlement may occur in fewer or more than three business days. According to various embodiments, however, the entity associated with the transaction system  10  may be responsible for paying the seller on day T+3. That way, if for some reason the winning bidder fails to pay in time, the seller may still get paid on day T+3, and it is up to the entity associated with the transaction system  10  to recover the sale proceeds from the winning bidder. 
         [0053]    Additionally, according to various embodiments, a single entity may play one or more of the roles illustrated in  FIG. 5 . For example, the entity employing the transaction system  10  may also be the plan administrator  64 . That entity, for example, could also be a bidder  16  in the transactions. 
         [0054]    As described above, the auctions may be executed using a first-in, first-out time order based on the received sale orders. In another embodiment, the sale orders may be aggregated. For example, the ESOs from a number of sale orders received in a defined time period may be aggregated and auctioned one or more lots (e.g., lots of 1000 options). The defined time period may be a number of minutes, a number of hours, or a trading day, for example. Thus, for example, all the sale orders received in a trading day for each product may be aggregated at the end of the day, with the options divided into lots and auctioned at the end of the day (or other defined time period). 
         [0055]    According to various embodiments, if the transaction system  10  detects that a seller has placed a sell order for ESOs that it has also exercised, the transaction system  10  may cancel (or bust) the sale order. The transaction system  10  may perform this operation based on data received from the plan administrator  64  regarding ESOs exercised by employees. 
         [0056]    Referring back to  FIG. 1 , a seller  12  may access the transaction system  10  via the network  18  to sell his/her ESOs. First, the seller  12  may go through a registration and authentication routine to verify the identity of the seller  12 . Data regarding the sellers, including their option grants, may be stored in the seller database  31 . Once access to the system is gained, the server  20  may serve an interactive web-based user interface to the seller  12  through which the seller  12  can view his/her options, submit orders to sell ESOs, and analyze the transactions in order to evaluate whether he/she should hold the ESOs or sell them.  FIGS. 6-10  and  12  are examples of screen shots of the web-based user interface according to various embodiments of the present invention. 
         [0057]      FIG. 6  is an example of a screen shot of a web page that displays an overview of the seller&#39;s ESOs. The overview display may be obtained by activating the “Overview” link in the menu field  98 . As seen in the illustrated example, in the upper right portion, the screen shot may include a field  99  that lists the current trading price of the stock of the issuer  14 , its change relative to the previous trading day, and the present date/time. The screen shot may also include a table  100  listing in tabular form the number of the option grants, the dates the option grants were awarded to the seller by the issuer, the dates the options expire, the dates the options become fully vested, and the strike price of the options. This data may be stored in the seller database  31  (see  FIG. 1 ). Also as seen in  FIG. 6 , the table  100  may also include the number of available options for each grant. The number of available options may be broken down by the number that are vested, the number that are unvested, and the number that are held. The number of options that are held may be the sum of the vested and unvested options. 
         [0058]    The table  100  may also include a column  102  listing the approximate intrinsic value of the vested options for each option grant based on the current trading price for the stock. The available vested intrinsic value may be determined based on the difference between the trading price for the stock underlying the ESOs (e.g., the stock issued) and the strike price for the ESOs. The available vested intrinsic value may be computed by the analytics engine  36  (see  FIG. 1 ) based on, for example, one or more data feeds  39  from market exchanges regarding the current trading prices of options for stock issued by the issuer  14 . 
         [0059]    The table  100  may also include a portion  104  that lists the approximate proceeds the seller could realize by selling his/her ESOs using the transaction system  10 . The analytics engine  36  may compute the estimated proceeds based on transaction data regarding similar ESOs. The transaction data may be stored in the database  35  (see  FIG. 1 ). When the estimated proceeds are greater than the estimated intrinsic value (see column  102 ), there may be an incentive for the seller to sell his/her ESOs rather than to hold them. 
         [0060]      FIG. 7  is an example of a screen shot through which the seller  14  may place sell orders for his/her ESOs. This screen shot may be obtained by activating the “Sell Options” in the menu field  98 . This screen shot may include a table  110  that provides an overview of the options the seller has available to sell. In such a transaction system, it may be preferable that the seller can only sell vested options. Thus, only the option grants where at least some of the options have vested may be shown in the table  110 . As shown in the illustrated example, the table  110  may include a portion  112  that lists data regarding the numbers of the option grants granted to the seller, the award date of the option grants, the date the options will expire if sold through the transaction system  10 , the strike price for the options, and the number of shares of each option grant that have vested. In the illustrated embodiment, the options issued by the issuer  14  expire on the earlier of the two years from the transaction date and the actual expiration date. Thus, in the illustrated embodiment, the option expiration is listed as 15-May-2008, which is two years from the current date (see field  99 ). 
         [0061]    The table  110  may also include a column  114  that lists the estimated available proceeds from selling the vested ESOs through the transaction system  10 . Again, the analytics engine  36  may compute this value based on past transaction data stored in the database  39 . 
         [0062]    As mentioned before, there may be a limit on the number of shares/options a seller can sell via the transaction system  10  in one transaction. In one embodiment, the limit may be one thousand shares/options. Accordingly, the table  110  may also include a field  116  that lists the current price for one thousand options at the specified strike price for each available option grant. The field  116  may also indicate whether that price is rising or falling, as well as the change in price over the previous trading day. The change may be displayed in absolute terms (as shown in  FIG. 7 ), by percentages, or both. 
         [0063]    In addition, the table  110  may include a field  118  where the seller may place the sell orders. Using a drop-down window  120 , for example, the seller may specify a market or limit order type. In field  122 , the seller may specify the number of options to be sold. Again, the ESO transaction rules may place a limit on the maximum number of options that can be sold in a transaction (e.g., 1,000 options). If the seller specifies a limit order, the seller can specify the limit price and the limit expiration in the fields  124  and  126 , respectively. The seller can place the order by activating the “Place Order” icon  128 . The orders may then be received by the transaction system  10  via the network  18 , with the router  26  routing messages to the appropriate transaction engines  28  based on, for example, strike price. The transaction engines  28  may then add the order to their transaction queue, as described above. 
         [0064]      FIG. 8  is an example of a screen shot the seller may view to view his/her pending sale orders. The screen shot of  FIG. 8  may be obtained by activating the “Pending Orders” link in the menu field  98 . This screen shot may include a table  130  listing the pending sale orders of the seller. The table  130  may include, for example, an alphanumeric order ID assigned to each pending order, the date the order was submitted, the order type, the date the order is good until (for limit orders), the strike price, the number of options to be sold, the limit price (for limit orders), and the status of the sale. According to various embodiments, the table  130  may also include an icon  132 , the activation of which may allow the seller to cancel the order. For example, some types of sell orders (e.g., various limit sell orders) may be cancelable by the seller  12 . 
         [0065]      FIG. 9  is an example of a screen shot the seller may view to view his/her order history. The screen shot of  FIG. 9  may be obtained by activating the “Order History” link of the menu field  98 . According to various embodiments, this screen shot may include a drop-down window  140  where the user may select the type of order status for the orders to be viewed. Using the drop-down window  140 , the seller may select, for example, all orders (as shown in the example of  FIG. 9 ), filled orders, cancelled orders, or pending orders. 
         [0066]    The user interface of  FIG. 9  may also include a table  142  that includes data regarding the order that satisfies the order status filter setting set in the drop-down window  140 . For each order that satisfies the order status filter setting, the table  142  may list in tabular form the order ID, the date the order was submitted, the order type, the strike price, the number of options sold (or to be sold), the limit price (for limit orders), the status of the sale order (e.g., filled, cancelled, pending, etc.), the date/time the order was executed or cancelled, the sell price, and the estimated gross proceeds. The estimated gross proceeds may be computed by multiplying the sale price by the number of options sold. 
         [0067]    As seen in the lower left portion of the screen shot of  FIG. 9 , the “Order History” user interface may also provide a command field  144  by which the seller can order a file (such as a PDF or Excel file) for exporting via the network  18  that contains the data of the table  142 . 
         [0068]    The seller may be able to view additional seller-oriented analytics regarding the transactions by clicking on the “Analytics” tab in the menu field  97 . The analytics may be determined by the analytics engine  36  and served to the seller  12  via the host  19 .  FIG. 10  is a screen shot of an exemplary seller analytics user interface according to various embodiments of the present invention. According to the illustrated embodiment, the employee may select between analytics regarding the ESO by selecting the “Options Research” link in menu field  148  or analytics regarding the stock underlying the ESOs (e.g., the stock issued by the issuer) by selecting the “Market View” link in the menu field  148 . 
         [0069]    In the example of  FIG. 10 , the “Options Research” link is selected. As a result, the chart shown in the user interface of  FIG. 10  conveys information about the selling of ESOs using the transaction system  10 . As shown in the illustrated embodiment, the interface may include a time frame field  150  where the user may select the time frame over which the transaction data is to be analyzed. In this example, the possible time frame selections include the current week, the prior (or last) week, the current period (e.g., the current yearly quarter), past yearly quarters, the year to date, or past years. In this example, the current period is selected. 
         [0070]    The user interface may also include a strike price selection field  152 . This field may be populated with the strike prices of the option grants issued to the employee. In this example, the employee has option grants with four different strike prices: $300, $257, $232, and $215. Each strike price may be associated with a unique identifier for the charts  154 - 160 . The identifier may be a unique color or hatching symbol for each strike price. The employee may select which strike prices he/she wishes to analyze by selecting the corresponding check boxes in the field  152 . 
         [0071]    Based on the employee&#39;s time period selection in the field  150  and the strike price selections in the field  152 , the analytics engine  36  may compute various metrics related to the ESOs, which may be displayed in the charts  154 - 160  in the user interface. The chart may include a first chart  154  which shows the number of transactions per day for the specified strike prices over the specified time period. A second chart  156  may depict the sales history for the specified strike prices over the specified time period. The sales history chart  156  may indicate the daily high and low sale price for the specified strike prices. In this example, it can be seen that the $300 ESOs sold for between about $60 and $70 over the specified time period, and that the $257 ESOs sold for between about $30 and $40. 
         [0072]    A third chart  158  may show the premium over the intrinsic value of the ESOs that may be realized through selling the ESOs through the transaction system  10 . The intrinsic value may be computed by the analytics engine  36 , as described above, by subtracting the strike price of the ESOs from the trading price for the stock. The premium over the intrinsic value may be determined by the analytics engine  36 , according to one embodiment, by subtracting the intrinsic value from the best price on the previous transaction day for options having the same (or a substantially similar) strike price. Using radio buttons  162 ,  164 , the employee may select whether to have the chart  158  show the premium in terms of actual dollars or by a percentage of the intrinsic value. 
         [0073]    A fourth chart  160  may depict the indicative sale price of the ESOs versus an estimated fair value price for the ESOs for the specified strike prices. The indicative price may be determined by the analytics engine  36  based on the transaction data for ESOs sold through the transaction system  10  with the same or similar strike prices. The estimated fair value price may be a price designed to indicate what the options would trade for in an over-the-counter options market. 
         [0074]      FIG. 11  is a flow chart of a process the analytics engine  36  may use to compute the estimated fair value price for the ESOs. Starting at step  170 , the analytics engine  36  may determine the closest nonemployee options for the issuer&#39;s stock that are similar to the employee&#39;s ESO in terms of strike price and expiration date. According to various embodiments, the analytics engine  36  may employ a nearest-neighbor algorithm to determine the closest nonemployee options, preferably giving priority to expiration date over strike price. The data for the nonemployee options may be stored in a database or obtained from the data feed  39 . At step  172 , the analytics engine  36  may use a reverse Black-Scholes model to compute the implied volatility of the nonemployee options. Then, at step  174 , the analytics engine  36  may use a forward Black-Scholes model to compute the fair value of the ESOs using the implied volatility determined at step  172 . 
         [0075]    According to various embodiments, the analytics engine  36  could also be customizable for different issuers. For example, the interpolation functions used in the Black-Scholes models may be how deep into the money or how out of the money the ESOs of the issuer are. 
         [0076]    Referring back to  FIG. 10 , each of the charts  154 - 160  may include an “Enlarge View” button  166 , which, when activated by the user, may bring up an enlarged view of the selected graph  154 - 160 . 
         [0077]      FIG. 12  is an example screen shot of a user interface that may be displayed to the employee when the “Market View” link in the field  148  is selected. This user interface may include a number of charts  180 - 186  that convey information about the issuer&#39;s stock. The first chart  180  may be a table that lists information about the present trading of the issuer&#39;s stock. The information may include the last trade price, the time of the last trade, the change in price, the previous closing price, price ranges over various time periods, trading volume, market capitalization, etc. The analytics engine  36  may obtain this information from the data feed  39  and/or a database. 
         [0078]    A second chart  182  may chart the stock price and the volume traded for the issuer&#39;s stock over the selected time frame. A third chart  184  may show the price for long dated (e.g., expiration at least two years away) listed options for the issuer&#39;s stock versus the strike price for the options. A fourth chart  186  may depict the volatility in the stock price. In a chart timeline selection field  188 , the employee can select the time period over which the market view metrics are to be shown in the graphs  182  and  186 . In addition, like the “Options Research” interface of  FIG. 10 , some of the charts  180 - 186  may include an “Enlarge View” button  166 , which, when activated by the user, may bring up an enlarged view of the selected graph. 
         [0079]    According to various embodiments, the issuer  14  and/or entities acting on behalf of the issuer may also log into the transaction system  10  via the network  18  to view issuer-related analytics pertaining to the sales of the ESOs. The analytics may be determined by the analytics engine  36  based on, among other things, data stored in the databases  31 - 35  as well as data from the data feeds  39 .  FIGS. 13-21  are examples screen shots of user interfaces that the issuer  14  may access to view such issuer-related analytics pertaining to the sales of the ESOs. 
         [0080]    As shown in the example of  FIG. 13 , the issuer  14  may select which types of analytics to view from a menu field  200 . According to various embodiments, possible options include an executive overview, analytics pertaining to the value of the ESOs, employee metrics, transaction metrics, external metrics, bidder analytics, and site usage. Of course, in other embodiments, different and/or additional types of analytics may be used. 
         [0081]      FIG. 13  is an embodiment of an interface conveying executive overview information. In a time frame selection menu field  202 , the user may select the desired time frame over which the transaction data is to be analyzed. The illustrated interface includes three charts (although in other embodiments, a different number of charts could be displayed). A first chart  204  may graph the number of ESOs available to be sold via the transaction system  10  (which is a function of the number of ESOs granted to employees that have vested) versus the number of options sold using the transaction system  10  over the selected time frame. 
         [0082]    A second chart  206  may be a bar chart that shows the cumulative total value realized by employees through the ESO sale program. A third chart  208  may convey information to compare the cumulative percentage of options sold through the ESO sale program over the selected time period versus the cumulative percentage of options exercised by employees (that is, exercised outside of the ESO sale program). In the illustrated embodiment, the chart  208  is a bar chart where the cumulative percentage of options exercised is at the bottom portion of the bars, and the cumulative percentage of options sold via the ESO sale program is on the upper portion of the bars. The two conditions may be demarcated by different colors or shading (as in the illustrated embodiment of  FIG. 13 ) or by different hatching patterns. In other embodiments, different types of charts may be used to graphically convey this or similar information. 
         [0083]      FIG. 14  is an example of an interface the issuer  14  may use to view information about the value of the ESOs. The issuer  14  may access the interface by selecting the “Option Value” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include two charts. The first chart  210  may be a table that displays information about the ESOs sold via the transaction system and those exercised outside of the ESO sale program. In a time period selection field  202  the user may select the desired time period, and in a strike price selection field  214  the user may select the range of strike prices for which the user wishes to review the data. According to various embodiments, per the selected time frame from selection field  202 , the table may list the following data pertaining to the ESOs: the number of ESOs sold in the ESO sale program; the number of ESOs exercised outside of the ESO sale program; the total value of the ESO sales using the transaction system  10 ; the total value of the ESO exercised outside of the ESO sale program; the total value of the ESOs sold in the transaction system above their intrinsic value; the number of employees newly registered with the transaction system; the percentage of registered employees using the transaction system; and the average number of bids per transaction (e.g., per auction). Using a scroll bar  216 , the user may scroll horizontally through the range of time periods. 
         [0084]    The option value interface may also include, as shown in the illustrated embodiment of  FIG. 14 , a second chart  218  which conveys information to compare the cumulative percentage of options sold through the ESO sales program over the selected time period versus the cumulative percentage of options exercised by employees (that is, exercised outside of the ESO sales program). This chart may be similar to the chart  208  of  FIG. 13 , for example. 
         [0085]      FIG. 15  is an example of an interface the issuer  14  may use to view employee metrics. The issuer  14  may access the interface by selecting the “Employee Metrics” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include three charts. The first chart  220  may be a table that displays information about employee usage of the ESO sales program. In a time period selection field  222  the user may select the desired time period, and in a strike price selection field  224  the user may select the range of strike prices for which the user wishes to review the data. According to various embodiments, per the selected time frame from selection field  222 , the table may list the following data pertaining to employee usage of the ESO sales program: average number of transactions (e.g., sales through the ESO sales program) per employee; average option value per employee; average number of limit orders per employee; percentage of registered users using the ESO sales program; and percentage of total employees that are registered. 
         [0086]    Charts  226  and  228  may convey demographic information about employee usage of the ESO sales program for the selected time period. The chart  216 , for example, may be a bar chart that charts the total proceeds of the ESOs by employee, where the total proceeds include the intrinsic value of the ESOs and the premium gained through selling the ESOs through the ESO sales program. The intrinsic value may be shown at the bottom portion of the bars, and the premium may be shown on the upper portion of the bars. The two conditions may be demarcated by different colors, shading or hatching patterns, for example. 
         [0087]    The chart  228  may be a bar chart that charts the average value of sales by employee. The employees may be segmented by usage of the transaction system (e.g., frequent, average, occasional) and/or by location. 
         [0088]      FIG. 16  is an example of an interface the issuer  14  may use to view transaction metrics. The issuer  14  may access the interface by selecting the “Transaction Metrics” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include a table  230  listing transaction-related information. According to various embodiments, per the selected time frame from selection field  222 , the table  230  may list the following data pertaining to the ESO sales program: number of employees active in the transaction system; number of open orders; number of filled orders; number of cancelled orders; and number of busted orders. An order may be considered busted, for example, if it is detected that the employee also submitted an order to exercise the ESOs outside the ESO sales program. 
         [0089]      FIG. 17  is an example of an interface the issuer  14  may use to view metrics relating the external markets. The issuer  14  may access the interface by selecting the “External Metrics” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include tables  240 ,  242 . Table  240  may list data regarding sales of the ESOs through the transaction system  10  and data regarding sales of ESOs by the plan administrator. According to various embodiments, the table  240  may include first and second portions  248 ,  249  that, per the time periods selected in the menu field  244 , list the following data regarding sales of ESOs through the transaction system and sales by the plan administrator, respectively: sale volume (e.g., number of options); range of strike prices; minimum sales price; and maximum sales price. 
         [0090]    The table  242  may list data regarding sales of nonemployee options for the issuer&#39;s stock. The sales data may be from an options exchange, such as the CBOE. The analytics engine  36  may receive the sales data for such nonemployee options from the data feed  39 . According to various embodiments, the table  242  may list the same data for the nonemployee options sold on the options exchange as in the table  240 . 
         [0091]      FIGS. 18 and 19  illustrate an example of an interface the issuer  14  may use to view bidder analytics. The issuer  14  may access the interface by selecting the “Bidder Analytics” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include a chart  250  showing the success ratio of various bidders (or “Batting Average”). In the illustrated example, the chart  250  shows that Bidder 1 won between about 33% and 39% of the transactions over the selected time frame, Bidder 2 won between about 28% and 36% of the transactions, and Bidder 3 won between about 29% and 40% of the transactions. 
         [0092]    The bidder analytics interface may include a second chart  252  (shown better in  FIG. 19 ) that may be a table that, according to various embodiments, may list, per the selected time periods and per bidder, the following data: number of winning bids; number of tied bids; number of bids won by $0.05 to $0.10, the number won by $0.15 to $0.50, the number won by $0.55 to $1.00, and the number won by more than $1.00; number of bids lost by $0.05 to $0.10, the number lost by $0.15 to $0.50, the number lost by $0.55 to $1.00, and the number lost by more than $1.00; when losing, the average percentage off from the winning bid; the cumulative position of each bidder (in dollars); the lowest daily quoted price over the intrinsic value; the highest daily quoted price over the intrinsic value; and the end of day daily quoted price. 
         [0093]      FIG. 20  is an example of an interface the issuer  14  may use to view an overview of the transactions. The issuer  14  may access the interface by selecting the “Big Board” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include a chart  260  that lists various transaction-related data for ESOs at different strike prices. The transaction-related data may include: the option expiration; the indicative price (e.g., the current highest bid, as of the time when the auction data was last compiled); the relative change (e.g., the change in price from a prior auction, such as the last auction on the previous day or the immediately preceding auction); the winning bidder; and ranges of bids. 
         [0094]      FIG. 21  is an example of an interface the issuer  14  may use to view statistics related to usage of the transaction system. The issuer  14  may access the interface by selecting the “Site Usage” link in the menu field  200 . As shown in the illustrated embodiment, the interface may include a chart  270 . The chart  270  may be a table that, per the selected time periods, lists various data regarding usage of the transaction system, including, for example: number of registered users; users who have partially completed registration; users who looked at the help page; users who visited certain pages; total hits; new users; unique users; users who placed market orders; users who placed limit orders; users who cancelled an order, etc. 
         [0095]    According to various embodiments, the bidders  16  may also log into the transaction system  10  via the network  18  to view bidder-related analytics pertaining to the transactions for the ESOs. For example, according to various embodiments, a bidder  16  may access charts like the charts  250 ,  252  of  FIG. 18 , although the charts served to the bidders may, for example, only contain data with respect to the particular bidder accessing the analytics, and not the data for other bidders. 
         [0096]    As used herein, the term “engine” refers to one or more processors that execute computer software code which, when executed by the processor(s), cause the processor(s) to perform the particular function of the engine. The code may be stored on a computer readable medium. 
         [0097]    While several embodiments of the present invention have been described herein, it should be apparent that various modifications, alterations and adaptations to those embodiments may occur to persons skilled in the art. For example, certain steps of the processes described above may be performed in different orders and/or simultaneously. Also, the illustrated screen shots are merely exemplary of types of information and how information may be displayed to different end users. It is therefore intended to cover all such modifications, alterations and adaptations without departing from the scope and spirit of the present invention as defined by the appended claims.