Abstract:
A method and system for accelerating the decoding and filtering of market data to provide reduced latency of the message data while maintaining or increasing throughput and mining market data for subsequent reporting. One or more financial market data streams are directed to one or more portals for introduction to a multiplexing switch. The financial market data streams are combined at the multiplexing switch and provided to a hardware line handler to de-multiplex the combined data stream into first and second streams. The first and second data streams are processed in first and second filter stacks in parallel to identify packets originating from sources of market data. The first and second streams comprising data packets originating from the sources of market data are combined and then decoded to obtain a financial data stream. The financial data stream may be further processed. The financial data stream may then be evaluated in accordance with rules established by a user. A hardware based smart router may be used to facilitate the execution of trades based on embedded routing rules.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. §119(e) from provisional applications No. 61/106,521 and 61/106,526, both filed Oct. 17, 2008. The 61/106,521 and 61/106,526 applications are incorporated by reference herein, in their entireties, for all purposes. 
     
    
     BACKGROUND 
       [0002]    Financial markets have undergone changes, both regulatory and in practice. Regulatory changes such as Regulation National Market System (Reg NMS) in the US and the Markets in Financial Instruments Directive (MiFID) as promulgated by the European Union have fostered increased competition by enabling new execution venues to compete on a more level playing field. The regulatory demands for best execution require consolidation of market data from multiple trading venues and the processing of price updates which are now approaching the millions of messages per second mark. 
         [0003]    In order to maintain a competitive edge, trading firms have responded by changing their trading strategies and trading platform architectures to increase the speed of trading and cater to this ever-increasing volume growth. These firms and execution venues are adapting their trading architecture for ultra-low latency, removing unnecessary network hops, increasing market data distribution bandwidth and developing optimized software solutions on horizontally scalable low cost server platforms. 
         [0004]    Latency is the time necessary to process the sale of a security and then to report that sale to the market. Latency time is typically measured in milliseconds. Low latency architecture for trading and reporting platforms is thus concerned with the efficiencies to be gained through changes in software approach and in the use of hardware solutions to reduce latency time. In the search for even lower latency, statistical arbitrage and algorithmic traders are also locating their price injectors as close to the trading engine as possible, leading to a growth in co-location services offered by execution venues. The challenges facing trading firms and execution venues can be summarized in terms of: 
         [0005]    Capacity—which is moving from hundreds of millions to billions of order messages per day; 
         [0006]    Throughput—which is moving from about a hundred thousand messages per second to millions of messages per second; and 
         [0007]    Latency—which is moving from milliseconds to microseconds. 
         [0008]    While progress has been made in the development of low latency trading architectures, software-only solutions typically suffer from higher intrinsic latency and degraded performance in faster markets. This intrinsic latency is due to the introduction of outliers, a failure to keep up, the need for higher server capacity. 
         [0009]    Latency is inherent in the very software design architectures commonly used to facilitate exchange through the World Wide Web. While promoting design efficiency, architectures such as XML and Web Services actually foster latency when financial data streams are moving across platforms. Additionally, some software based solutions do not detect when data packets have been dropped from a data stream. Thus, when the stream is parsed and then re-directed, if a data packet is missing there is no high speed approach to re-attaching or re-creating the packet. This problem creates false or inaccurate trades because key data is missing when the data is formatted for end or dependent use. These problems necessarily impact statistical arbitrage and algorithmic traders. 
       SUMMARY 
       [0010]    Embodiments herein provide systems and methods for utilizing a hardware acceleration solution that is capable of providing ultra-low latency with ultra-high throughput while maintaining consistent performance under a diverse range of market conditions. Other embodiments provide systems and methods for maintaining the sequential integrity of data packets while maintaining consistent performance under a diverse range of market conditions. The systems and methods further provided for accelerating the decoding and filtering of message data to provide reduced latency of the message data while maintaining or increasing throughput. 
         [0011]    An embodiment provides a method for accelerating the decoding and filtering of message data to provide reduced latency of the message data. One or more data packets that arrive at a network interface are read and passed through a protocol processing pipeline. A determination is made whether or not a data packet contains financial message data by inspecting a header of each of the data packets. When the inspected data packet does not contain financial message data, the inspected data packet is discarded. When the inspected data packet contains financial message data, the data packet is forwarded to a filter. The packet is filtered in accordance with parameters established by a system user to select specific information of relevance to the system user. A low-latency data transfer application programming interface is used to transfer the relevant data through a high speed peripheral bus to a software subsystem of a host system. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0012]      FIG. 1  is a pictorial schematic representing a system according to an embodiment. 
           [0013]      FIG. 2  is a flow diagram illustrating a process by which data streams are processed with low latency according to an embodiment. 
           [0014]      FIG. 3  is a block diagram illustrating a coprocessor configured to receive and process data from a single market according to an embodiment. 
           [0015]      FIG. 4  is a block diagram illustrating a coprocessor configured to receive and process multiple market data inputs according to an embodiment. 
           [0016]      FIG. 5  is a block diagram illustrating a configuration of distributed line handlers according to an embodiment. 
           [0017]      FIG. 6  is a block diagram illustrating a coprocessor configured to perform ultra-low latency market data processing, execution and smart routing capabilities across two or more markets simultaneously according to an embodiment. 
           [0018]      FIG. 7  is a relationship diagram of the order routing engine according to an embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    Embodiments herein provide systems and methods for utilizing a hardware acceleration solution that is capable of providing ultra-low latency with ultra-high throughput while maintaining consistent performance under a diverse range of market conditions. Other embodiments provide systems and methods for maintaining the sequential integrity of data packets while maintaining consistent performance under a diverse range of market conditions. The systems and methods further provided for accelerating the decoding and filtering of message data to provide reduced latency of the message data while maintaining or increasing throughput. 
         [0020]      FIG. 1  is a high level pictorial schematic of a system according to an embodiment. The system  100  comprises an add-on card  101  and a CPU  110 . The add-on card  101  and the CPU  110  communicate via a high-speed interface  108 . 
         [0021]    The add-on card  101  comprises a network port  102 , a network port  104 , and a co-processor  106 . In an embodiment, add-on card  101  utilizes a co-processing architecture that may be configured to be plugged-in to a standard network server or stand-alone workstation. As illustrated, add-on card  101  includes network ports  102  and  104 , however this is not meant as a limitation. Additional ports may be included on add-on card  101 . In an embodiment, the network ports  102  and  104  provided connectivity to wired and fiber Ethernet network interfaces. 
         [0022]    The network ports  102  and  104  are interoperably connected to the co-processor  106 . The co-processor  106  may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any form of parallel processing integrated circuit. The direct connection of the network ports to the coprocessor  106  eliminates one of the major contributors to latency in a hardware/software co-processing system that arises from the peripheral bus transactions between the system architecture (the co-processor architecture) and a network device. 
         [0023]    The add-on card  101  implements a high-speed interface  108  such as HyperTransport, PCI-Express or Quick Path Interconnect to transfer data to and from the host system central processing unit (CPU)  110  with the highest bandwidth and lowest latency available. In an embodiment, the add-on card  101  is implemented to replace a central processing unit (CPU) in a socket on the motherboard of a host computing device (not illustrated). 
         [0024]    Additionally, the system  100  may implement filtering on the content of the messages arriving, which filtering can be customized to a user&#39;s needs. By way of illustration and not by way of limitation, filtering may be performed by symbol, message type, price and volume. The filtering process acquires only the information that is of relevance to the user thereby reducing the CPU  110  loads for processing the feed. Messages can also be translated into a binary structure that can be read directly from the user&#39;s application, avoiding any processing time associated with converting message formats on the CPU  110 . 
         [0025]    In the case where filtering on symbols is required, some incoming message formats have the symbol in every message, so the system  100  may parse the message, read the byte location for the symbol, and filter thereupon. In some compacted message formats (e.g., FAST), the first message in a packet of multiple messages may contain the symbol and the following messages do not. In this case, the symbol is stored from the first message and reinserted into the subsequent messages for filtering purposes. 
         [0026]    In some message formats, for example ITCH, the symbol may not be in any message within a packet. Instead, the order number for each message is included, which can be cross-referenced to the symbol number, which is stored in a memory (not illustrated) connected to the system  100 . 
         [0027]      FIG. 2  is a flow diagram illustrating a process by which data streams are processed with low latency according to an embodiment. While two streams and two interfaces are illustrated, this is not meant as a limitation. There can be more than one inbound data stream; thus, there can be multiple network interfaces. Additionally, a single interface (e.g.,  200 ) can be used to provide stream data to the illustrated paths as indicated by the dotted line connect from interface  200  to the Ethernet filter  206 . 
         [0028]    System  100  reads all data packets that arrive at the network interface and passes the packets through the protocol processing pipeline. At each protocol layer, the headers of the received data packets are inspected to assess whether the source IP address is a known source of financial message data. In an embodiment, data streams A and B maybe redundant streams that will contain the same data. 
         [0029]    The system  100  integrates parsing of several protocol layers in parallel using multiple pipelines. A separate pipeline is run for each network port. This means that a complex protocol stack can reliably run at wire-speed (capacity of the physical interface) without missing a single data packet. Importantly, each protocol layer only requires a small number of extra pipeline stages, which may add extra latency (measured in tens of nano-seconds) but with no effect on data throughput. As illustrated in  FIG. 2 , the standard protocols that are handled in the hardware device include: Ethernet; IP; UDP multicast or unicast, and TCP. However, this is not meant as a limitation. Other protocols may also be handled in a pipeline. 
         [0030]    The data streams are received at Ethernet filters (blocks  204  and  206  respectively). Each Ethernet filter operates to filter the network signal. If a data packet does not satisfy the protocol of the Ethernet filters, or if the packets do not come from a known source of financial protocol information, they are either discarded or passed up to the operating system network stack to emulate the behavior of a standard network interface card (NIC) (block  220 ). This allows the device to exist seamlessly on an existing network, with the operating system handling standard house-keeping protocols such as ARP, ICMP, IGMP, etc., as will be further described below. 
         [0031]    The data streams are then passed to IP protocol filters to test the data stream against the internet protocol and to again determine if a packet comes from a known source of financial protocol information (blocks  208  and  210  respectively). If a data packet does not satisfy the protocol of the IP filters, or if the packet does not come from a known source of financial protocol information, the packet is either discarded or passed up to the operating system network stack to emulate the behavior of a standard network interface card (block  220 ). 
         [0032]    The data streams are passed to UDP filters (blocks  212  and  214  respectively). The UDP filters ( 212  and  214 ) are employed to test the data stream against the UDP protocol and to determine if a packet comes from a known source of financial protocol information. If the data packet does not satisfy the protocol of the UDP filters, or if the packet does not come from a known source of financial protocol information, the packet is either discarded or passed up to the operating system network stack to emulate the behavior of a standard network interface card at (block  220 ). 
         [0033]    Packets containing financial protocol information are passed through decoders (blocks  213  and  215  respectively) to obtain the feed sequence number and then routed to one of a pair of redundant user datagram protocol (UDP) multicast feeds (A/B Arbitrage block  216 ) where the packets are assembled into a single stream. The system  100  can read the feeds simultaneously because of the nature of the parallel pipelines for each feed. The system  100  does so by taking the next sequence numbered packet from whichever feed arrives first (sometimes referred to herein as “arbitrage”). If, for example, the next expected packet does not arrive on either feed, the hardware device will flag the packet source that there is a gap and initiate recovery. 
         [0034]    As each numbered packet is processed, it is directed through a decoder (block  218 ). The decoder parses the message protocol to obtain financial market data. The financial data is then processed in the appropriate format such as standard FIX (financial information exchange), FAST (FIX adapted for streaming), ASCII or other binary format. The data stream and its component packets are then converted from an ASCII to a binary format for filtering. It is noted that the data may then be either passed onto a software host unprocessed or partially or entirely converted into a binary format as noted herein. 
         [0035]    In an embodiment, the data stream may be normalized (block  222 ). In this embodiment, the financial data parsed from the data stream may be optionally converted into a single format, either proprietary or standard. The normalized format may contain additional fields than that of the incoming format. If that is the case, some fields will not be completed and some may need to be calculated from the incoming data, often via a buffer of data accumulated over multiple messages. Some fields in the incoming format may not have an equivalent in the normalized format, so this data would be dropped. 
         [0036]    The data stream may be directed through one or more user-defined filters  230  which may defined by a system user to produce custom formatted data for use by the software subsystem of central processing unit  110 . By way of illustration and not by way of limitation, filtering can be performed by symbol, message type, price and volume. In the case where filtering on symbols is required, some incoming message formats have the symbol in every message. In this environment, the user defined filters  230  may read the byte location for the symbol and filter on the location. In some compacted message formats (e.g., FAST), the first message in a packet of multiple messages may contain the symbol and the following messages do not. In this case, the symbol may be stored from the first message and reinserted into the subsequent messages for filtering purposes. 
         [0037]    In some message formats, for example ITCH, the symbol may not be in any message within a packet. Instead, the order number for each message is included, which may be cross-referenced to the symbol number, which is stored in a memory (not illustrated). 
         [0038]    The filtered data is then sent to the host CPU (execution server)  110  (block  224 ) utilizing a low latency data transfer (LLDT) API  224  to a physical layer  226  to access the high speed peripheral bus  108 . The financial data is sent directly to the execution server  110  of the host system. 
         [0039]    In an embodiment, the low-latency data transfer (LLDT) API has both a hardware and software component. The LLDT abstracts communications through any high-speed peripheral bus, such as PCI Express, HyperTransport or QuickPath Interconnect. Transmission of data is carried out via simple calls to the API. Several independent virtual channels may operate over one physical interface; and, data transfer to the host server is via direct memory access. The mixture of hardware and software combined with a consistent API enables a combination of software and hardware solutions (short time to market) to be migrated to hardware over time (for lower latency) with no changes required on the server side. 
         [0040]      FIG. 3  is a block diagram illustrating a coprocessor configured to receive and process data from a single market according to an embodiment. A co-processor architecture  300  is configured with input ports  312  (only one input port is illustrated for clarity, a line handler  314 , a market  1  feed handler  316 , and a protocol stack  320 . Inbound line A  302  and line B  304  are market data, from a single market, and are multiplexed through a switch  310  into one of the co-processor board network inputs at  312 . The hardware line handler  314  will de-multiplex the market data input and process the data streams in parallel as illustrated in  FIG. 2  and as previously described through the decoder stage (see,  FIG. 2 , block  218 ). 
         [0041]    The market  1  feed handler  316  performs normalization (see,  FIG. 2 , block  222 ). The market  1  feed handler  316  may also be configured to perform the functions of user defined filter  230  (see,  FIG. 2 ) as previously described. Financial data that is parsed and normalized will interface with the API  318  for routing to a server  330  for evaluation. The filtered data is then sent to the CPU (execution server)  330 , utilizing a low latency data transfer (LLDT) API  318  to access the high speed peripheral bus. 
         [0042]    In an embodiment, the server  330  comprises a CPU and applications that may be executed by the CPU to evaluate the financial data in accordance with rules established by a user. In an embodiment, the user rules determine when to execute a financial transaction. In this embodiment, when a financial transaction is deemed appropriate by the user rules, the server  330  issues ordering instructions that are forwarded to the API  318  for formatting into a protocol appropriate to a selected market to which the order is to be directed. The formatted order is then passed through TCP/IP stack  320  for delivery to the selected market. Additionally, the CPU  330  may retain and then mine parsed data. Thus, in addition to processing financial data relative to orders and sales, the co-processor architecture can also reliably facilitate the capture of market data that can be structured and repackaged as determined by parameters established by the user. 
         [0043]      FIG. 4  is a block diagram illustrating a coprocessor configured to receive and process multiple market data inputs according to an embodiment. A co-processor architecture  400  is configured with input port  1   412 , input port  2   412  and input port “N”  416 , a line handler  418 , a market  1  feed handler  420 , a market  2  feed handler  422 , a market “N” feed handler  424  and a protocol stack  428 . Inbound feeds from multiple markets (illustrated as market  1  feed  402 , market  2  feed  404 , and market “N” feed  406 ) are multiplexed through a switch  410  into one of the co-processor board input ports. By way of illustration and not by way of limitation, the network ports may be 1 or 10 Gigabit network ports. The hardware line handler  418  de-multiplexes each of the market feeds and processes the data streams in parallel as illustrated in  FIG. 2  and as previously described through the decoder stage (see,  FIG. 2 , block  218 ). 
         [0044]    The market feed handlers  420 ,  422  and  424  perform normalization (see,  FIG. 2 , block  222 ) and may also be configured to perform the functions of user defined filter  230  (see,  FIG. 2 ) as previously described. Financial data that is parsed and normalized will interface with the API  426  for routing to a server  450  for evaluation. The filtered data is then sent to the CPU (execution server)  450 , utilizing a low latency data transfer (LLDT) API  426  to access the high speed peripheral bus. 
         [0045]    In an embodiment, the server  450  comprises a CPU and applications that may be executed by the CPU to evaluate the financial data in accordance with rules established by a user. In an embodiment, the user rules determine when to execute a financial transaction. In this embodiment, when a financial transaction is deemed appropriate by the user rules, the server  450  issues ordering instructions that are forwarded to the API  426  for formatting into a protocol appropriate to a selected market to which the order is to be directed. The formatted order is then passed through TCP/IP stack  428  for delivery to the selected market. Additionally, the CPU  450  may retain and then mine parsed data. Thus, in addition to processing financial data relative to orders and sales, the co-processor architecture can also reliably facilitate the capture of market data that can be structured and repackaged as determined by parameters established by the user. 
         [0046]    The result is a consolidated feed of market data with only the relevant filtered and normalized data passing between the co-processor architecture and the CPU  450 . Where there is a requirement to consolidate more markets than there are available network inputs then multiple processor boards may be connected together with a high speed data interconnect. 
         [0047]      FIG. 5  is a block diagram illustrating the configuration of distributed line handlers according to an embodiment. The configuration of the line handlers  510  will enable the assembly of a consolidated market feed from  500 , where the capacity of a set of markets exceeds the capacity of a single virtual local area network (VLAN). Pairs of line handlers  510  are assigned to a number of feeds  500  each from different markets. In this configuration the line handlers  510  may broadcast the feed using, for example, multicast groups (for network segmentation purposes). Other protocols, such as TCP/IP or unicast, could also be used. Another line handler would read the multicast group(s) and filter only the stocks the particular server requires. Thus, with a minor network delay, only the system user could assemble consolidated feeds and watch how to slice an order into the market or markets simultaneously or over time. The initial receiving line handler will not pass the input data via the CPU  520  or  525 , but straight out from the co-processor board, which may be daisy chained as outlined above to eliminate network delay. A hardware accelerated reliable multi-cast messaging protocol is embedded within a coprocessor to enable high throughput, low latency communication between the broadcast and receiving/filtering line handlers. The application of the hardware accelerated reliable multi-cast messaging protocol has wide applicability to more general messaging problems, where high throughput, low latency and reliability are important and is not limited to the distribution of market data. 
         [0048]      FIG. 6  is a block diagram illustrating a coprocessor configured to perform ultra-low latency market data processing, execution and smart routing capabilities across two or more markets simultaneously according to an embodiment. In this embodiment, the co-processor architecture  600  is configured to receive line A and line B data feeds from multiple markets (illustrated as market  1  input  602 , market  2  input  604 , and market  3  input  406 ). The line A and line B data feeds from market  1  are received at co-processor  600  input  612 . The line A and line B data feeds from market  2  are received at co-processor  600  input  614 . The line A and line B data feeds from market  3  are received at co-processor  600  input  616 . The inputs from the multiple markets are multiplexed into two or more network inputs connected directly to the co-processor architecture  600  via network ports. By way of illustration and not by way of limitation, the network ports may be 1 or 10 Gigabit network ports. The hardware feed handler  618  de-multiplexes the feeds and performs line A and line B arbitrage (see,  FIG. 2 , block  216 ) in parallel. The market feed handlers  620 ,  622  and  624  perform market data filtering (see,  FIG. 2 , block  218 ) and normalization (see,  FIG. 2 , block  222 ). 
         [0049]    The result is a consolidated feed of market data with only the relevant filtered and normalized data passing between the co-processor architecture  600  and the CPU  650 . Where there is a requirement to consolidate more markets than there are available network inputs then multiple processor boards will be connected together with a high speed data interconnect. 
         [0050]    The filtered data is then sent to the CPU (execution server)  650 , utilizing a low latency data transfer (LLDT) API  628  to access the high speed peripheral bus. Additionally, the CPU  650  is used, among other tasks, to retain and then mine parsed data. Thus, in addition to processing financial data relative to orders and sales, the co-processor architecture can also facilitate the capture of market data that can be structured and repackaged as determined by parameters established by the system operator. 
         [0051]    A consolidated order book is maintained in memory (not illustrated), with only the relevant filtered and normalized data passing between the co-processor  600  and the CPU  650 . Proprietary modules  652  on the server can then determine arbitrage and execute opportunities across the multiple markets and pass routing rules and executions to a hardware based smart router  626  located on the co-processor  600  for accelerated execution. 
         [0052]    Combining the hardware accelerated multi-market feed with an accelerated execution capability and a hardware based smart router will enable the bulk of the data processing to take place on the co-processor board  600 , removing considerable server load and reducing latency. 
         [0053]      FIG. 7  is a block diagram illustrating a routing engine according to an embodiment. Many financial products are traded across multiple markets such as Market A (block  702 ), Market B (block  704 ), and Market C (block  706 ). Market data from these markets are fed to UDP filters (blocks  710  and  712 ), processed and captured (block  720 ) as previously described. Orders are fed to a TCP stack (block  714 ) and to protocol APIs (blocks  722 ,  724  and  726 ). Because the liquidity may not always be on the same market, traders will therefore search across multiple markets for the best price and even split an order across multiple venues. The calculation of where to execute orders is complicated and involves accumulating knowledge of markets over time. There is, however, commonality between the execution features required by most trading groups, so an API  730  that abstracts that commonality from the proprietary code adds value for the trader. The API  730  illustrated herein allows the trader to specify a set of order routing preferences to an order routing engine  728  and get feedback from the engine on the status of orders. Using the API  730 , the trader can keep complete control of his proprietary models  740  yet leverage the power of off-the-shelf acceleration. The API  730  rests on top of a software library  760  in the hardware accelerator  750  which communicates with the order routing engine  728 . 
         [0054]    The order routing engine  728  executes orders according to the preferences expressed by the trader through the API  730 . A database of market performance and current pricing is built up through feedback through the order execution links with the exchanges and through the market data feeds. This database is used as a means of establishing parameters for the order routing engine  728 . 
         [0055]    The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Further, words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of a processes or method. Rather, these words are simply used to guide the reader through the description of the methods. 
         [0056]    Reference will now be made in detail to several embodiments of the invention that are illustrated in the accompanying drawings. Wherever possible, same or similar reference numerals are used in the drawings and the description to refer to the same or like parts or steps. The drawings are in simplified form and are not to precise scale. For purposes of convenience and clarity only, directional terms, such as top, bottom, up, down, over, above, and below may be used with respect to the drawings. These and similar directional terms should not be construed to limit the scope of the invention in any manner. The words “connect,” “couple,” and similar terms with their inflectional morphemes do not necessarily denote direct and immediate connections, but also include connections through mediate elements or devices. 
         [0057]    Furthermore, the novel features that are considered characteristic of the invention are set forth with particularity in the appended claims. The invention itself, however, both as to its structure and its operation together with the additional object and advantages thereof will best be understood from the following description of the preferred embodiment of the present invention when read in conjunction with the accompanying drawings. Unless specifically noted, it is intended that the words and phrases in the specification and claims be given the ordinary and accustomed meaning to those of ordinary skill in the applicable art or arts. If any other meaning is intended, the specification will specifically state that a special meaning is being applied to a word or phrase. Likewise, the use of the words “function” or “means” herein is not intended to indicate a desire to invoke the special provision of 35 U.S.C. 112, paragraph 6 to define the invention. To the contrary, if the provisions of 35 U.S.C. 112, paragraph 6, are sought to be invoked to define the invention(s), the claims will specifically state the phrases “means for” or “step for” and a function, without also reciting in such phrases any structure, material, or act in support of the function. Even when the claims recite a “means for” or “step for” performing a function, if they also recite any structure, material or acts in support of that means of step, then the intention is not to invoke the provisions of 35 U.S.C. 112, paragraph 6. Moreover, even if the provisions of 35 U.S.C. 112, paragraph 6, are involved to define the inventions, it is intended that the inventions not be limited only to the specific structure, material or acts that are described in the preferred embodiments, but in addition, include any and all structures, materials or acts that perform the claimed function, along with any and all known or later-developed equivalent structures, materials or acts for performing the claimed function. 
         [0058]    The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. 
         [0059]    The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of the computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function. 
         [0060]    In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disc storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. 
         [0061]    Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as cellular, infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically and discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer-readable medium, which may be incorporated into a computer program product. 
         [0062]    The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an,” or “the,” is not to be construed as limiting the element to the singular.