Abstract:
Disclosed herein is a method and apparatus for hardware-accelerating various data quality checking operations. Incoming data streams can be processed with respect to a plurality of data quality check operations using offload engines (e.g., reconfigurable logic such as field programmable gate arrays (FPGAs)). Accelerated data quality checking can be highly advantageous for use in connection with Extract, Transfer, and Load (ETL) systems.

Description:
CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED APPLICATION 
     This patent application is a divisional of U.S. patent application Ser. No. 12/121,473, filed May 15, 2008, now U.S. Pat. No. 8,374,986, the entire disclosure of which is incorporated by reference herein. 
    
    
     FIELD OF THE INVENTION 
     The present invention is generally directed toward the field of stream processing, particularly the use of stream processing in a system such as a business rules engine, an event stream processor, and a complex event stream processor. 
     TERMINOLOGY 
     The following paragraphs provide several definitions for various terms used herein. These paragraphs also provide background information relating to these terms.
     GPP: As used herein, the term “general-purpose processor” (or GPP) refers to a hardware device having a fixed form and whose functionality is variable, wherein this variable functionality is defined by fetching instructions and executing those instructions (for example, an Intel Xeon processor or an AMD Opteron processor), of which a conventional central processing unit (CPU) is a common example.   Reconfigurable Logic: As used herein, the term “reconfigurable logic” refers to any logic technology whose form and function can be significantly altered (i.e., reconfigured) in the field post-manufacture. This is to be contrasted with a GPP, whose function can change post-manufacture, but whose form is fixed at manufacture.   Software: As used herein, the term “software” refers to data processing functionality that is deployed on a GPP or other processing devices, wherein software cannot be used to change or define the form of the device on which it is loaded.   Firmware: As used herein, the term “firmware” refers to data processing functionality that is deployed on reconfigurable logic or other processing devices, wherein firmware may be used to change or define the form of the device on which it is loaded.   Coprocessor: As used herein, the term “coprocessor” refers to a computational engine designed to operate in conjunction with other components in a computational system having a main processor (wherein the main processor itself may comprise multiple processors such as in a multi-core processor architecture). Typically, a coprocessor is optimized to perform a specific set of tasks and is used to offload tasks from a main processor (which is typically a GPP) in order to optimize system performance. The scope of tasks performed by a coprocessor may be fixed or variable, depending on the architecture of the coprocessor. Examples of fixed coprocessor architectures include Graphics Processor Units which perform a broad spectrum of tasks and floating point numeric coprocessors which perform a relatively narrow set of tasks. Examples of reconfigurable coprocessor architectures include reconfigurable logic devices such as Field Programmable Gate Arrays (FPGAs) which may be reconfigured to implement a wide variety of fixed or programmable computational engines. The functionality of a coprocessor may be defined via software and/or firmware.   Hardware Acceleration: As used herein, the term “hardware acceleration” refers to the use of software and/or firmware implemented on a coprocessor for offloading one or more processing tasks from a main processor to decrease processing latency for those tasks relative to the main processor.   Enterprise: As used herein, the term “enterprise” refers to any business organization or governmental entity that stores and/or processes data (referred to as “enterprise data”) as part of its ongoing operations.   Database: As used herein, the term “database” refers to a persistent data store with indexing capabilities to expedite query processing. Various database management system (DBMS) implementations might be categorized as relational (RDBMS), object-oriented (OODBMS), hierarchical, etc.; however, the dominant architecture in today&#39;s industry is a relational, row-column, structured query language (SQL)-capable database. An ANSI-standard SQL database engine is a mature software architecture that can retrieve structured data in response to a query, usually in an efficient manner.   Structured Data: As used herein, the term “structured data” refers to data that has been normalized and persisted to a relational database. Normalization is the data design process of putting data into a tabular, row-column format and abstracting duplicate data into separate tables. Structured data in relational columns is capable of being indexed with B-tree indexes, significantly speeding access to the data in these columns. In SQL terms, structured columns have size limits. These columns may have constraints and referential integrity applied to them in order to ensure consistent data quality. Examples of common structured SQL datatypes are: INT(eger), NUMBER, CHAR(acter), VARCHAR, DATE, TIMESTAMP.   Unstructured Data: As used herein, the term “unstructured data” refers to data that falls outside the scope of the definition above for structured data. Thus, the term unstructured data encompasses files, documents or objects with free form text or embedded values included therein. This data includes the complete set of bytes, often including binary-format data, that was used by the application that generated it. Examples of unstructured data include word processing documents (e.g., Microsoft Word documents in their native format), Adobe Acrobat documents, emails, image files, video files, audio files, and other files in their native formats relative to the software application that created them. In SQL terms, unstructured columns have very large, if not unlimited size. Common examples of unstructured SQL datatypes are: BLOB, TEXT, XML, RAW, and IMAGE. Unstructured objects may also be stored outside the database, for example in operating system files. Access to these external objects from within the database engine uses links in the metadata in the database table to the storage location.   

     There are a number of reasons why XML will not normally be categorized as “structured” as that term is used herein:
         XML may have large or unlimited sized values   XML often does not have strongly enforced datatyping   XML has a flexible schema   XML values in elements and attributes is often not as rigidly conformed and carefully cleansed as traditional “structured” database columns
 
Although the concept of “semi-structured” data with flexible schemas is emerging, particularly for XML, for present purposes everything that has not been normalized and persisted to a relational database will be considered unstructured data. As such, a column that is of the XML datatype would thus fall under this present definition of “unstructured data”.
       Bus: As used herein, the term “bus” refers to a logical bus which encompasses any physical interconnect for which devices and locations are accessed by an address. Examples of buses that could be used in the practice of the present invention include, but are not limited to the PCI family of buses (e.g., PCI-X and PCI-Express) and HyperTransport buses.   Pipelining: As used herein, the terms “pipeline”, “pipelined sequence”, or “chain” refer to an arrangement of application modules wherein the output of one application module is connected to the input of the next application module in the sequence. This pipelining arrangement allows each application module to independently operate on any data it receives during a given clock cycle and then pass its output to the next downstream application module in the sequence during another clock cycle.   

     BACKGROUND OF THE INVENTION 
     Enterprises such as corporations, institutions, agencies, and other entities have massive amounts of data for which analysis is needed to enable decision making processes, and computerized systems based on business rules have arisen to aid enterprises&#39; decision-making capabilities in this regard.  FIG. 1  illustrates a basic exemplary process flow for such a rule-based system. The flow of  FIG. 1  relies on two elements—a fact  100  and a rule  112 . Facts  100  are typically characterized as tuples, with each tuple comprising an identifier  106 , at least one attribute  108  and at least one value  110  corresponding to the attribute. The identifier  106  is a unique string that identifies the fact  100 . An attribute  108  is a string that identifies a particular feature of the fact  100 , and the value  108  is a value for that particular feature. It should be understood that a fact  100  can have multiple attributes  108  and corresponding values  110 . A rule  112  generally comprises one or more conditions  114  and one or more actions  116  to be taken if the conditions are satisfied. As such, rules  112  can be characterized with the form: if CONDITION(s) then ACTION(s). It should be understood that rules  112  may include multiple conditions  114  with potentially complicated inter-relationships among the conditions. At step  102 , a check is performed to see if fact  100  satisfies a rule  112 . In the event the fact satisfies the rule, one or more action(s)  116  are triggered. To perform such a check, step  102  tests for valid (identifier, attribute, value) tuples that satisfy a condition  114 . It should be noted that for facts the three fields can only take on specific values (based on the values of the bit string which represents the fact), whereas for rules, the constituent fields can be represented by a variable. 
     A variety of systems have been developed to provide rule-based decision-making capabilities to enterprises. Examples of these systems include event processors, complex event processors (CEPs), and business rules engines. An event processor and a complex event processor can be distinguished from a business rules engine in that an event processor and a complex event processor are “feed forward” systems in that they do not feed result information from the business rule condition checking process back into the event processor or complex event processor to determine further actions that need to be taken. In contrast, a business rules engine employs some form of inferencing intelligence at the output of the business rule condition checking process to feed all or a select subset of the results back into the business rules engine to determine further actions that need to be taken. A complex event processor can be distinguished from an event processor in that a complex event processor can take into consideration multiple events when deciding whether a particular business rule condition has been satisfied. 
     An algorithm that has arisen to implement a rule-based system exemplified by  FIG. 1  (typically for business rules engines) is known as the Rete algorithm. See Forgy, Charles, “RETE: A fast algorithm for the many pattern/many object pattern matching problem”, Artificial Intelligence, Vol. 19, p. 17-37, 1982, the entire disclosure of which is incorporated herein by reference. The Rete algorithm derives its efficiency by exploiting the modular nature of rules; rule-checking is performed as a series of steps which represent the rules to determine if one or more corresponding actions are to be initiated. 
     The inventors believe that conventional implementations of computerized rule-based systems do not perform exceptionally well, particularly in instances where the size of the rule set is large and growing, where the size of the data volume is large and growing, and/or where there is a need for low latency with respect to making a business rule-based decision after first receiving the pertinent data. For example, the inventors believe that conventional business rule processing systems which rely on analyzing data stored using database technology such as a conventional RDBMS (which are optimized for large-scale permanent storage and carefully-tuned query performance) have difficulty keeping up with the demands of very high speed data streams and thus serve as a potential bottleneck in a rule-based decision-making system. Thus, as enterprises&#39; rule sets and data volumes continue to grow in size and complexity and as data transfer speeds continue to increase, the inventors further believe that time will exacerbate this problem unless a better solution for business rule processing is devised. 
     SUMMARY OF THE INVENTION 
     In an effort to address this need in the art, the inventors herein disclose a technique for hardware-accelerating the process of determining whether data within a data stream satisfies at least one rule condition of a rule. The data streams, as represented by a stream of bits, may include structured and/or unstructured data. Based on such a hardware-acceleration rule condition check operation, a rule condition check result is generated to indicate whether a data stream portion (such as a record or field) satisfies any rule conditions. Preferably, the rule condition check result is generated only when a data stream portion satisfies a rule condition. However, this need not be the case. It should also be understood that the rule condition check result can be expressed in any of a number of ways. For example, a rule condition check result can be expressed as a bit value (or bit values) in a register within a system. A rule condition check result can also be expressed as one or more bits that are added to an existing record (such as by adding a field to a record to express the rule condition check result or by adding a bit to an existing field of a record to express the rule condition check result). As yet another example, a rule condition check result can be expressed as a new record that is inserted into the data stream. 
     Based on the rule condition check results, enterprises can take desired actions with an extremely low degree of latency, particularly relative to a conventional rule-based decision-making system which relies on software executed by a main GPP for the system to determine whether various data records satisfy pre-defined rule conditions. With embodiments described herein, data is streamed into a coprocessor, and rule condition check results based on a plurality of different rule conditions can be generated at bus bandwidth rates, thereby leading to dramatic improvements in rule-based decision-making latency. 
     In doing so, the present invention preferably harnesses the underlying hardware-accelerated technology disclosed in the following patents and patent applications: U.S. Pat. No. 6,711,558 entitled “Associated Database Scanning and Information Retrieval”, U.S. Pat. No. 7,139,743 entitled “Associative Database Scanning and Information Retrieval using FPGA Devices”, U.S. Patent Application Publication 2006/0294059 entitled “Intelligent Data Storage and Processing Using FPGA Devices”, U.S. Patent Application Publication 2007/0067108 entitled “Method and Apparatus for Performing Biosequence Similarity Searching”, U.S. Patent Application Publication 2008/0086274 entitled “Method and Apparatus for Protein Sequence Alignment Using FPGA Devices”, U.S. Patent Application Publication 2007/0130140 entitled “Method and Device for High Performance Regular Expression Pattern Matching”, U.S. Patent Application Publication 2007/0260602 entitled “Method and Apparatus for Approximate Pattern Matching”, U.S. Patent Application Publication 2007/0174841 entitled “Firmware Socket Module for FPGA-Based Pipeline Processing”, U.S. Patent Application Publication 2007/0237327 entitled “Method and System for High Throughput Blockwise Independent Encryption/Decryption”), U.S. Patent Application Publication 2007/0294157 entitled “Method and System for High Speed Options Pricing”, U.S. patent application Ser. No. 11/765,306, filed Jun. 19, 2007, entitled “High Speed Processing of Financial Information Using FPGA Devices” (and published as U.S. Patent Application Publication 2008/0243675), U.S. patent application Ser. No. 11/938,732, filed Nov. 12, 2007, entitled “Method and System for High Performance Data Metatagging and Data Indexing Using Coprocessors” (published as U.S. Patent Application Publication 2008/0114725), U.S. patent application Ser. No. 11/938,709, filed Nov. 12, 2007, entitled “Method and System for High Performance Integration, Processing and Searching of Structured and Unstructured Data Using Coprocessors” (published as U.S. Patent Application Publication 2008/0114724), and U.S. patent application Ser. No. 12/013,302, filed Jan. 11, 2008, entitled “Method and System for Low Latency Basket Calculation” (published as U.S. Patent Application Publication 2009/0182683), the entire disclosures of each of which are incorporated herein by reference. 
     It should be understood that the range of actions which can triggered by the accelerated rule condition check operations described herein are virtually limitless and can be tailored to meet the particular needs of a practitioner of embodiments for the invention. Exemplary actions may include sending an alert to a designated person or group of persons, invoking a particular process within an enterprise computing system, deleting a record, placing a record into a holding queue, routing a record to a particular destination, etc. Furthermore, with respect to the conceptual “event/condition/action” (ECA) framework discussed in connection with  FIG. 1 , it should also be understood that an action corresponding to a rule can also include the act of generating the rule condition check result. The presence of the rule condition check result could then trigger additional secondary actions (such as an application which monitors the value of a particular register that stores rule condition check results to decided whether a certain functional action should be triggered). It should also be understood that the action that is triggered by satisfaction of a rule can be performed using a coprocessor or other processing device within an enterprise computing system. 
     The data streams being operated upon by the embodiments of the present invention preferably comprise a plurality of records or events as represented by bit strings. It should be noted that the terms records and events are used interchangeably herein. A data record or event signifies a fact  100  such as that described in connection with  FIG. 1 . 
     Many enterprises have one or more data feeds where extremely high volumes of data events are constantly streaming into the enterprise&#39;s computing system. To provide an enterprise with actionable intelligence capabilities with respect to such data streams, the inventors disclose various embodiments which accelerate the operations needed to determine which incoming events satisfy which pre-defined rules. Examples of operations which can be hardware-accelerated in accordance with various embodiments of the present invention include rule condition check operations (such as matching operations, range check operations, and threshold check operations), aggregate value computation operations, derived value computation operations, filtering operations, path merging operations, and formatting operations. It should be noted that the rule condition check operations can be performed directly on data values within the events themselves or on data values derived and/or aggregated from data values within the events themselves. 
     Preferably a pipeline is arranged in a coprocessor to check the incoming data streams against the rule conditions of the enterprise&#39;s business rules. Even more preferably, such a pipeline includes a plurality of different parallel paths for performing different ones of these checks simultaneously with one another. 
     Further still, the accelerated operations described herein are preferably deployed by an enterprise in systems such as event stream processors, complex event stream processors, and business rules engines. 
     Examples of the myriad of beneficial business rule-based applications for embodiments of the invention include data quality checking (particularly in data integration systems such as Extract, Transfer, Load (ETL) systems), security monitoring for transactions such as credit card transactions, financial market monitoring, data routing within an enterprise based on data content, Rete network acceleration, and others, as explained in greater detail below. 
     These and other features and advantages of the present invention will be apparent to those having ordinary skill in the art upon review of the following description and drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  depicts an exemplary process flow for a rule-based system; 
         FIG. 2( a )  illustrates an exemplary event stream processing appliance in accordance with an embodiment of the present invention; 
         FIG. 2( b )  illustrates an exemplary event stream processing appliance in accordance with another embodiment of the present invention; 
         FIG. 2( c )  illustrates an exemplary event stream processing appliance in accordance with yet another embodiment of the present invention; 
         FIGS. 3( a ) and ( b )  illustrate exemplary printed circuit boards for use in the appliances of  FIGS. 2( a )-( c ) ; 
         FIG. 4  illustrates an example of how a firmware pipeline can be deployed across multiple reconfigurable logic devices; 
         FIG. 5  is a high level block diagram view of how a coprocessor can be used perform a rule condition check operation on data that streams therethrough; 
         FIG. 6  depicts an exemplary matching module that can be deployed on a coprocessor to check incoming events against a plurality of standing rule conditions; 
         FIGS. 7( a )-( g )  depict exemplary firmware pipelines and firmware modules within those pipelines that can be used to perform rule condition check operations on an incoming stream; 
         FIG. 7( h )  depicts an exemplary data stream that has been partitioned into records and fields; 
         FIG. 8( a )  depicts an exemplary rule condition checking pipeline with multiple rule condition checking paths; 
         FIG. 8( b )  depicts an example of how streams within the multiple paths of  FIG. 8( a )  can be merged together; 
         FIGS. 8( c )-( e )  depict additional exemplary rule condition checking pipelines with multiple rule condition checking paths; 
         FIG. 9  depicts another exemplary embodiment for a multi-path rule condition checking pipeline; 
         FIG. 10  depicts an exemplary record and field identifier module for the pipeline of  FIG. 9 ; 
         FIG. 11  depicts an exemplary field selection module for the pipeline of  FIG. 9 ; 
         FIG. 12  depicts an exemplary regular expression pattern matching module for the pipeline of  FIG. 9 ; 
         FIG. 13( a )  depicts an exemplary secondary matching module for the pipeline of  FIG. 9 ; 
         FIG. 13( b )  depicts an exemplary mode of operation for the secondary matching module of  FIG. 13( a ) ; 
         FIGS. 14( a ) and ( b )  depict an exemplary word parsing module for the pipeline of  FIG. 9 ; 
         FIG. 15  depicts an exemplary exact/approximate word matching module for the pipeline of  FIG. 9 ; 
         FIGS. 16( a ) and ( b )  depict an exemplary record appendage formatting module for the pipeline of  FIG. 9 ; 
         FIGS. 17( a ) and ( b )  depict an exemplary record join module for the pipeline of  FIG. 9 ; 
         FIG. 18  depicts an exemplary record and field delimiter insertion module for the pipeline of  FIG. 9 ; 
         FIG. 19( a )  depicts an exemplary embodiment for a complex event stream processor appliance; 
         FIG. 19( b )  depicts an exemplary mode of operation for a complex event generator such as that of  FIG. 19( a ) ; 
         FIG. 20  depicts an exemplary environment in which an event stream processing appliance can be employed to provide business rule processing for an enterprise; 
         FIG. 21( a )  depicts an exemplary event stream processing pipeline configured for data quality checking; 
         FIG. 21( b )  depicts an exemplary mode of operation for a range check module within the pipeline of  FIG. 21( a ) ; 
         FIG. 22  depicts an exemplary event stream processing pipeline configured to process incoming credit card transaction records; 
         FIG. 23  depicts an exemplary mode of operation for a range check module within the pipeline of  FIG. 22 ; 
         FIGS. 24( a )-( c )  depict an exemplary mode of operation for a derived value check module within the pipeline of  FIG. 22 ; and 
         FIGS. 25( a ) and ( b )  depict exemplary embodiments for a hardware-accelerated Rete network. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       FIG. 2( a )  depicts an exemplary embodiment for an event stream processing appliance  200  which can be used to accelerate business rules processing. While an embodiment of appliance  200  can be referred to as a business rules engine, it should be noted that functionalities in addition to business rules processing can be supported by appliance  200 ; for example, appliance  200  could also be used to generate metadata (including indexes) for streaming data as explained in the above-referenced and incorporated U.S. patent application Ser. No. 11/938,732, and appliance  200  could also be used to integrate, process, and search both structured and unstructured data as explained in the above-referenced and incorporated U.S. patent application Ser. No. 11/938,709. 
     Preferably, appliance  200  employs a hardware-accelerated data processing capability through coprocessor  450  to analyze an incoming data stream against a set of business rules. Within appliance  200 , a coprocessor  450  is positioned to receive data that streams into the appliance  200  from a network  420  (via network interface  410 ). Network  420  preferably comprises an enterprise network (whether LAN or WAN), in which various disparate data sources are located. It should be understood that the data streaming into the appliance  200  through enterprise network  420  can be data that is received by network  420  from external sources such as the Internet or other communication networks. Such incoming data may comprise both structured and unstructured data as appliance  200  can provide beneficial business rules analysis for both. 
     The computer system defined by processor  412  and RAM  408  can be any commodity computer system as would be understood by those having ordinary skill in the art. For example, the computer system may be an Intel Xeon system or an AMD Opteron system. Thus, processor  412 , which serves as the central or main processor for appliance  200 , preferably comprises a GPP. 
     In a preferred embodiment, the coprocessor  450  comprises a reconfigurable logic device  402 . Preferably, data streams into the reconfigurable logic device  402  by way of system bus  406 , although other design architectures are possible (see  FIG. 3( b ) ). Preferably, the reconfigurable logic device  402  is a field programmable gate array (FPGA), although this need not be the case. System bus  406  can also interconnect the reconfigurable logic device  402  with the appliance&#39;s processor  412  as well as the appliance&#39;s RAM  408 . In a preferred embodiment, system bus  406  may be a PCI-X bus or a PCI-Express bus, although this need not be the case. 
     The reconfigurable logic device  402  has firmware modules deployed thereon that define its functionality. The firmware socket module  404  handles the data movement requirements (both command data and target data) into and out of the reconfigurable logic device, thereby providing a consistent application interface to the firmware application module (FAM) chain  350  that is also deployed on the reconfigurable logic device. The FAMs  350   i  of the FAM chain  350  are configured to perform specified data processing operations on any data that streams through the chain  350  from the firmware socket module  404 . Preferred examples of FAMs that can be deployed on reconfigurable logic in accordance with a preferred embodiment of the present invention are described below. 
     The specific data processing operation that is performed by a FAM is controlled/parameterized by the command data that FAM receives from the firmware socket module  404 . This command data can be FAM-specific, and upon receipt of the command, the FAM will arrange itself to carry out the data processing operation controlled by the received command. For example, within a FAM that is configured to perform an exact match operation, the FAM&#39;s exact match operation can be parameterized to define the key(s) that the exact match operation will be run against. In this way, a FAM that is configured to perform an exact match operation can be readily re-arranged to perform a different exact match operation by simply loading new parameters for one or more different keys in that FAM. 
     Once a FAM has been arranged to perform the data processing operation specified by a received command, that FAM is ready to carry out its specified data processing operation on the data stream that it receives from the firmware socket module. Thus, a FAM can be arranged through an appropriate command to process a specified stream of data in a specified manner. Once the FAM has completed its data processing operation, another command can be sent to that FAM that will cause the FAM to re-arrange itself to alter the nature of the data processing operation performed thereby. Not only will the FAM operate at hardware speeds (thereby providing a high throughput of data through the FAM), but the FAMs can also be flexibly reprogrammed to change the parameters of their data processing operations. 
     The FAM chain  350  preferably comprises a plurality of firmware application modules (FAMs)  350   a ,  350   b , . . . that are arranged in a pipelined sequence. However, it should be noted that within the firmware pipeline, one or more parallel paths of FAMs  350   i  can be employed. For example, the firmware chain may comprise three FAMs arranged in a first pipelined path (e.g., FAMs  350   a ,  350   b ,  350   c ) and four FAMs arranged in a second pipelined path (e.g., FAMs  350   d ,  350   e ,  350   f , and  350   g ), wherein the first and second pipelined paths are parallel with each other. Furthermore, the firmware pipeline can have one or more paths branch off from an existing pipeline path. A practitioner of the present invention can design an appropriate arrangement of FAMs for FAM chain  350  based on the processing needs of a given application. 
     A communication path  430  connects the firmware socket module  404  with the input of the first one of the pipelined FAMs  350   a . The input of the first FAM  350   a  serves as the entry point into the FAM chain  350 . A communication path  432  connects the output of the final one of the pipelined FAMs  350   m  with the firmware socket module  404 . The output of the final FAM  350   m  serves as the exit point from the FAM chain  350 . Both communication path  430  and communication path  432  are preferably multi-bit paths. 
     The nature of the software and hardware/software interfaces used by appliance  200 , particularly in connection with data flow into and out of the firmware socket module are described in greater detail in the above-referenced and incorporated U.S. Patent Application Publication 2007/0174841. 
       FIG. 2( b )  depicts another exemplary embodiment for appliance  200 . In the example of  FIG. 2( b ) , appliance  200  includes a relational database management system  304  that is in communication with bus  406  via disk controller  414 . Thus, the data that is streamed through the coprocessor  450  may also emanate from RDBMS  304 . 
       FIG. 2( c )  depicts another exemplary embodiment for appliance  200 . In the example of  FIG. 2( c ) , appliance  200  also includes a data store  306  of unstructured data that is in communication with bus  406  via disk controller  416 . Thus, the data that is streamed through the coprocessor  450  may also emanate from data store  306 . Furthermore, any unstructured data that is streamed through coprocessor  450  for business rules processing can optionally be stored within data store  306 . 
       FIG. 3( a )  depicts a printed circuit board or card  330  that can be connected to the PCI-X or PCI-e bus  406  of a commodity computer system for use as a coprocessor  450  in appliance  200  for any of the embodiments of  FIGS. 2( a )-( c ) . In the example of  FIG. 3( a ) , the printed circuit board includes an FPGA  402  (such as a Xilinx Virtex II FPGA) that is in communication with a memory device  332  and a PCI-X bus connector  334 . A preferred memory device  332  comprises SRAM and DRAM memory. A preferred PCI-X or PCI-e bus connector  334  is a standard card edge connector. 
       FIG. 3( b )  depicts an alternate configuration for a printed circuit board/card  330 . In the example of  FIG. 3( b ) , a bus  336  (such as a PCI-X or PCI-e bus), one or more disk controllers  338 , and a disk connector  340  are also installed on the printed circuit board  330 . Any commodity disk interface technology can be supported, as is understood in the art. In this configuration, the firmware socket  404  also serves as a PCI-X to PCI-X bridge to provide the processor  412  with normal access to any disk(s) connected via the private PCI-X bus  336 . It should be noted that a network interface can be used in addition to or in place of the disk controller and disk connector shown in  FIG. 3( b ) . 
     It is worth noting that in either the configuration of  FIG. 3( a )  or  3 ( b ), the firmware socket  404  can make memory  332  accessible to the bus  406 , which thereby makes memory  332  available for use by an OS kernel as the buffers for transfers to the FAMs from a data source with access to bus. It is also worth noting that while a single FPGA  402  is shown on the printed circuit boards of  FIGS. 3( a ) and ( b ) , it should be understood that multiple FPGAs can be supported by either including more than one FPGA on the printed circuit board  330  or by installing more than one printed circuit board  330  in the appliance  200 .  FIG. 4  depicts an example where numerous FAMs in a single pipeline are deployed across multiple FPGAs. 
       FIG. 5  depicts at a high level a coprocessor  450  that receives an incoming data stream and performs a rule condition check operation  500  on data within the received data stream against at least one rule condition (and preferably plurality of rule conditions) to generate rule condition check results for the data stream. An action engine  502  then takes one or more actions based on rule condition results produced as a result of the rule condition check operation  500 . Examples of different hardware-accelerated rule condition check operations  500  will be described in greater detail hereinafter. In an exemplary embodiment, these operations are carried out in firmware deployed on reconfigurable logic. It should also be understood that the action engine  502 , need not, but may also be implemented on coprocessor  450 . For example, coprocessor  450  can be configured to communicate with an action engine that is implemented as software executing on a processor within an enterprise&#39;s computing system other than a coprocessor  450 . Any of a number of components within an enterprise computing system may serve as an action engine. For example, a database system can be configured to serve as an action engine (e.g., by handling and storing data within a record in a particular manner based on a rule condition result associated with that data). 
       FIG. 6  depicts an exemplary embodiment wherein rule condition check operation(s) performed by coprocessor  450  includes a matching operation. Such a matching operation can be extremely useful for rule conditions which require a determination to be made as to whether a particular string or string pattern is present in a record. It is believed by the inventors that in conventional business rules engines, where software executed by a main GPP is used to match fact data with rule conditions for an assessment of whether any facts satisfy any rule conditions, this matching process accounts for the vast majority of processing time.  FIG. 6  thus presents a solution for rules-based system to greatly accelerate this matching process by performing the matching process at hardware speeds. In this example, the data stream takes the form of a stream of data events  600 . Each event  600  can be considered a data record as represented by a bit string. It should be well understood that the coprocessor  450  can be configured to receive the bits of the bit string as multiple bytes every clock cycle. Furthermore, each record preferably takes the form of (identifier, attribute, value) as explained above in connection with  FIG. 1 . However, other forms of data within a data stream  600  can be processed by coprocessor  450 . For example, the “attribute” for a record can be presumed from the nature of the record itself, which may be the case for instances where records within the data stream include documents such as word processing files. Thus, it should be understood that the data within data stream  600  need not be rigidly formatted into identifiers/attributes/values. 
     In the example of  FIG. 6 , coprocessor  450  includes a matching module  602 . This matching module  602  may be implemented in firmware on reconfigurable logic. Matching module  602  maintains a rule set  604 , wherein rule set  604  comprises a plurality of rule conditions  606 . Each rule condition effectively serves as a key against which the events are queried to determine if there are any events which match any rule conditions. Upon detection of a match between an event and a rule condition, the matching module  602  generates a rule condition check result for that event such that the coprocessor  450 . In an exemplary embodiment, this rule condition check result can take the form of one or more bits that are representative of the existence of a match between an event and a rule condition. As previously explained, the coprocessor can use any of a number of techniques for expressing such rule condition check results. One technique can be used where the event stream itself is enriched. For example, one or more bits can be appended to an existing event which matches one or more rule conditions to identify which rule condition(s) were satisfied. Also, a new event can be generated in response to a detected match, wherein the new event identifies the event and the rule condition(s) for which a match was found. An event stream output from the coprocessor  450  which has been enhanced with rule condition check results can be referred to as enriched event stream  608 . Also, various techniques can be used to encode an identification of matching rule conditions in a bit string. For example, each position in a bit string can be associated with a different rule condition, and the matching module  602  can be configured to set a particular bit position high in response to finding a matching between an event and the rule condition corresponding to that bit position. As another example, hashing can be used to encode an identification of matching rule conditions in a bit string. 
     Any of a number of matching techniques can be used to perform the matching operation of matching module  602 . For example, hardware-accelerated matching techniques can be used such as those described in the above-referenced and incorporated U.S. Pat. Nos. 6,711,558 and 7,139,743 and U.S. Patent Application Publications 2006/0294059, 2007/0130140, and 2007/0260602. The 2007/0130140 publication describes a technique whereby a data stream can be inspected at hardware speeds to assess whether any data serves as a match to any of a number of regular expression patterns. As such, the technology disclosed in the 2007/0130140 publication can preferably be used by matching module  602  to detect any matches to rule conditions  606  which are expressed as regular expression patterns. Also, the 2007/0260602 publication discloses a technique whereby a data stream can be inspected at hardware speeds to query a given window of the data stream against a large number of standing keys (of various lengths) to determine whether the data stream window is an approximate match (within a definable degree of tolerance) to any of the keys. It should be understood that the technology of the 2007/0260602 publication can also be used to support exact match operations by simply setting the tolerance degree to a value of zero. As such, the technology disclosed in the 2007/0260602 publication can be used by matching module  602  to detect any exact or approximate matches with respect to rule conditions  606  which are expressed as words. Additional examples of hardware-accelerated matching techniques which can be used by matching module  602  include the exact matching technique known as the Rabin-Karp Search (RKS) (see Brodie, Benjamin C., Roger D. Chamberlain, Berkley Shands, and Jason White, “Dynamic reconfigurable computing,” in Proc. Of 9 th  Military and Aerospace Programmable Logic Devices International Conference, September 2006, the entire disclosure of which is incorporated herein by reference) and the approximate matching technique known as the k-sub matching algorithm (see the above-referenced and incorporated article Brodie, Benjamin C., Roger D. Chamberlain, Berkley Shands, and Jason White, “Dynamic reconfigurable computing,” in Proc. Of 9 th  Military and Aerospace Programmable Logic Devices International Conference, September 2006). 
     The enriched event stream  608  produced by coprocessor  450  can optionally then be passed along to downstream processing entities which are configured to take additional actions in response to the detected rule condition matches. As noted above, such an action engine  502  can be implemented in either hardware and/or software deployed on the coprocessor  450 , a main processor for the system, and/or other processing device. However, it should be understood that the coprocessor  450  of  FIG. 6  can itself be considered an ECA rule-based system in that the classic “If CONDITION(s) then ACTION(s)” conceptual framework of a rule  112  is met in that the actions specified by rule conditions  606  are exemplified by the generation of the rule condition check results. Thus, if “Rule Condition  1 ” is satisfied, then the action to be taken can be the exemplary action of “generating a rule condition check result that is indicative of Rule Condition  1  being satisfied”. 
     The hardware-accelerated rules-based decision-making system of  FIG. 6  can be used for a myriad of applications, with particular benefits for applications which require latency-sensitive rules-based decision-making, examples of which are explained in greater detail below. 
     It should also be understood that the coprocessor  450  in a rules-based decision-making system may optionally employ modules in addition to or different than matching module  602 .  FIG. 7( a )  depicts an embodiment of coprocessor  450  wherein a pipeline  710  (preferably a firmware pipeline deployed in reconfigurable logic) employs a filtering module  700  upstream from the matching module  602 . The filtering module  700  is configured select/deselect data within an incoming event stream  600  to generate a reduced event stream  702 . For example, an enterprise may only wish for the matching module  602  to process certain records, certain fields, and/or certain fields of certain records. Thus, filtering module  700  can be configured such that only the appropriate data will be processed by matching module  602 . The selection of which data will be passed by the filtering module  700  is preferably based on the value(s) in one or more specified fields of event stream  600 . In doing so, the filtering module  700  may also employ its own matching module to find matches between fields that are selected for further processing and fields within an event stream. Furthermore, it should be noted that the output  704  of the matching module  602  can optionally be passed to one or more downstream modules, as explained in greater detail hereinafter. 
     It should also be noted that pipeline  710  may optionally employ a plurality of parallel paths, as shown in  FIG. 7( b ) . Each path preferably employs a filtering module  700  and a rule condition checking module such as matching module  602 . Preferably, the matching module  602  within a particular path is configured with a different rule condition set relative to the matching modules within other paths. For example, one path may employ a matching module configured to perform checks on rule conditions which require exact/approximate string matching while another path may employ a matching module configured to perform checks on rule conditions which require regular expression pattern matching. Thus, each filtering module  700  can operate to reduce the event stream  600  within its path to a reduced event stream  702  that is appropriate for the rule set used by that path&#39;s matching module. 
     In many instances, it will be desirable for the pipeline  710  to possess the capability to perform complex event stream processing. With complex event stream processing, the question of whether a rule is satisfied may require rule conditions which depend upon multiple events or events within different streams. As such, it is beneficial for coprocessor  450  to possess the ability to cache a desired window of received events and rule condition check results. In this manner, determinations can be made as to whether a rule condition whose satisfaction requires consideration of multiple events. To provide such caching capabilities, pipeline  710  employs a windowing module  720 , as shown in  FIG. 7( c ) . Windowing module  720  preferably implements the ability to declare that certain events within stream  704  are to be cached/persisted in memory for future reference. Such cached events can be stored in available memory such as RAM that is accessible to the pipeline (see, e.g., memory device  332 ) or other storage such as a hard disk drive  724 , as shown in  FIG. 7( d ) . Preferably, the windowing module  720  employs some form of a timeout value  726  that is used to decide when events are to be flushed from the cache. The windowing module  720  can be configured to maintain and track different timeout values for each cached event. Optionally, the window (or windows) of events which are maintained as history by the windowing module can be configured to slide over the course of the event stream such that it maintains a history of the most recent k events at any given time using one or more shift registers or the like rather than timeout values. 
     It may also be desirable for pipeline  710  to include a join/correlation module  730 , as shown in  FIG. 7( e ) . The role of module  730  would be to merge two or more windows of events from the windowing module  720  into a single stream  732 , wherein stream  732  comprises events with values that are joined from the multiple windows. It should be understood that the streams being joined can be joined on any of a number of system-defined join keys. For example, it may be the case that incoming stream  722  may include multiple streams whose records are interleaved with each other. For example, stream  722  may include a first conceptual stream which comprises financial market events (e.g., stock trades) and second conceptual stream which comprises news reports from a news feed. The events from these two conceptual streams may be interleaved within stream  722 . The join/correlation module  730  can then merge these two conceptual streams into a single stream using a join key. For example, perhaps a practitioner of pipeline  710  desires to merge records which are news articles about Acme Corp. with records that are stock transaction events for Acme Corp. Thus, Acme Corp. can be used as a join key such that a stock transaction record within an event window available to module  730  having the ticker symbol for Acme Corp. will be merged with a news record within an event window available to module  730  that contains the word “Acme”. If necessary, the join/correlation module  730  can maintain its own caching capabilities (such as one like that shown for windowing module  720 ) to retain a desired history of the event windows. It should also be understood that rather than receiving a single physical stream with multiple interleaved conceptual streams, the join/correlation module can be configured receive multiple physical streams (with each of these physical streams comprising a single conceptual stream or multiple conceptual streams). 
     Optionally, the join/correlation module  730  may employ additional features such as a join to static data from a database. With a join to static data, the data to be joined would be read from a static database such as external database  734 . In this way, a join operation can operate to add data which is stored in the database to the streaming records. An example of a join to static data that can be performed by pipeline  710  involves joining a stream of transaction records with data from a customer master table that is stored in a database  734 . Using a join key such a name field in the stream of transaction records and a name field in the customer master table, joins can be performed on transaction records and customer data from the table that share the same value in a name field. 
     Another feature that can be performed by a join/correlation module is an approximate join. Continuing with the example above, an approximate join between a stream of transaction records and data from a customer master table, wherein the approximate join is based on a join key that is a name field, will support joins where there is only an approximate match and not an exact match between the values in the name fields of the transaction records and the customer table. Thus, a transaction record with a name field value of “John A. Smith” can be joined with customer data associated with a name field value of “John Smith” even through the two field values do not exactly match. As such, the join/correlation module  730  would employ approximate matching functionality that performs an approximate match operation between the values in the fields defined by the join key that are under consideration for a possible join. If the approximate match operation results in a determination that the two values are sufficiently similar, then the join is performed. Approximate matching technology such as the kinds previously discussed can be used for this functionality. It should also be understood that approximate joins need not be limited to joins on data stored in a database  734 . Approximate joins can also be performed on multiple streams available to module  730 . Furthermore, the approximate nature of the approximate join need not only be defined by approximate word matching operations. For example, with approximate joins on multiple data streams, it should be noted that because the time dimension of the multiple streams may not exactly align with each other, the value matching of the approximate join may be based on time intervals rather than exact times. Thus, if a time stamp field of records within two streams is used as a join key, then an approximate join operation can be configured such that any time stamp value within a range of time stamp values for the two streams will be deemed a match. To implement this functionality, a range check operation such as the ones described herein can be performed. 
     Pipeline  710  may also be configured to include an aggregation module  740 , as shown in  FIG. 7( f ) . Aggregation module  740  is preferably configured to perform aggregations based on pre-defined mathematical expressions. As such, aggregation module preferably maintains or have access to data storage capabilities such as on-chip memory or memory  332 . Optionally, these aggregations may operate on the windows of events produced by the windowing module (and present in the output of the join/correlation module  630 ). An example of an aggregation module is depicted in  FIG. 19( b ) , discussed hereinafter. Additional examples of aggregation operations that may be performed include moving average computations, volume weighted average pricing (VWAP) operations, risk analysis operations, etc. 
     In instances where the event stream  600  does not possess a record/field format for its data (or possesses a record/field format that is not recognized by pipeline  710 ), pipeline  710  may also employ a record and field identifier module  750  at its head, as shown in  FIG. 7( g ) . The record and field identifier module  750  is configured to partition the event stream  600  into a record-delimited and field-delimited event stream  752  that is understood within pipeline  710 . Preferably, a priori knowledge exists about the format of the incoming events so that appropriate tables can be maintained and accessed by module  750  when partitioning the event stream. For example, it may be known a priori that a certain bit string (or certain bit strings) will serve as a record delimiter. Furthermore, it may be known a priori that certain fields will begin at certain offsets within a record (e.g., a byte  10 , field x begins, at byte  13 , field y begins, etc.). Alternatively, it may be known a priori that certain field delimiters can be present in records, and module  750  can be configured to recognize these delimiters and possibly replace them with a field delimiter format that is internal to pipeline  710 . However, it should further be noted that module  750  can also be configured to “learn” the formats of incoming records and use this learned knowledge to perform the partitioning. 
       FIG. 7( h )  depicts an exemplary record and field delimited stream  752 . The record and field identifier module  750  inserts appropriate record delimiters (RDLs)  762  into the stream to separate the different data events from each other. Preferably, each RDL  762  also serves as a record identifier  106  as discussed above for facts  100 . Moreover, the data within each event may be categorized into one or more fields, with each field being identified by a field delimiter (FDL)  764 . Following each FDL  764  is the data  766  corresponding to the value for that field. It should be readily understood that FDLs  764  correspond to the attribute identifiers  108  discussed above for facts  100  and that data  766  corresponds to the values  110  discussed above for facts  100 . Thus, stream  752  comprises a plurality of events/records  760  partitioned by RDLs  762 , with each record being partitioned into field-delimited data  766  (via FDLs  764 ). Thus, filtering module can rely on the partitions within data stream  752  when making decisions as to which records and fields will be passed to downstream modules. It should also be noted that the terms “record delimiter” and “field delimiter” can be alternatively referred to as “record identifier” and “field identifier” respectively. 
     It should also be understood that the arrangements for pipeline  710  shown in  FIGS. 7( a )-( h )  are exemplary only and different pipeline arrangements can be implemented with different module orders within the pipeline, different module interconnections within the pipeline, and/or different modules altogether within the pipeline. For example, the windowing module  720  can be configured to pass its event windows back to the matching module  602  so that rule conditions across an entire event window can be checked. Also, an additional rule condition checking module (or modules) can be located downstream from the windowing module  730  to provide rule condition checking for complex events. Further still, various modules could be added/deleted to/from the pipeline  710  depending upon the needs of a given rule set or stream conditions. 
       FIG. 8( a )  illustrates an embodiment wherein coprocessor  450  employs a plurality of parallel paths  800  for checking rule conditions. Each path may comprise a pipeline  710  such as any of those shown in  FIGS. 7( a ), 7( c ), 7( e ), 7( f ), and 7( g ) , and will operate to produce a path-specific stream  802  of events and rule condition check results. A path merging module  804  is positioned to receive the streams  802  and merge them into the output stream  608 . In this manner, path merging module  804  provides similar functionality as the join/correlation module  730  discussed above.  FIG. 8( b )  depicts an exemplary path merging operation. In this example, the rule condition checking paths  800  operate to append, onto records which have fields that satisfy a rule condition, a field  820  corresponding to the rule condition check result. This enrichment field  820  includes a bit string whose values are indicative of which rule conditions that the record&#39;s fields satisfied (either directly or indirectly). Thus, continuing with an example where the enrichment field is directly indicative of which rule conditions are satisfied, the enrichment field  820  for record  760  within stream  802   1  (from path  800   1 ) indicates that rule condition # 5  was satisfied. The enrichment field  820  for record  760  within stream  802   2  (from path  800   2 ) indicates that rule condition # 2  was satisfied. Thus, to merge the enrichment fields from the two paths together, the path merging module  804  operates to essentially combine the enrichment fields  820  for the record within streams  802   1  and  802   2  to create a combined enrichment field  822  for that record in output stream  608  which indicates that record  760  satisfied both rule condition # 2  and # 5 . In this example, the path merging module  804  produces the combined enrichment field  822  in the output stream  608  by ORing together the fields  820  in the path output streams  802 . However, it should be understood that any of a number of techniques can be used to represent rule condition check results within each stream  802  and to combine the rule condition check results within streams  802 . For example, rather than ORing together the different fields  820  for a record in streams  802 , the path merging module  804  can be configured to concatenate the different fields  820 . In such a case, the enrichment field  820  for a record in a particular stream  802  would only identify the rule conditions which are pertinent for the path  800  of that stream  802 . Another way to merge fields  820  would be for instances where both paths result in the same rule being satisfied, then this could be indicated in field  822  by summing the bit strings of the individual streams. 
       FIG. 8( c )  depicts an alternate embodiment wherein the coprocessor  450  also includes a bypass path  810  that feeds into the path merging module  804 . In instances where a filtering module  700  is used within any of paths  800 , with use of the bypass path  810 , the path merging module  804  will be able to take into consideration any records and fields which may have been filtered out of the path streams when it assembles the enriched output stream  608 . Thus, the path merging module  804  will have an unmolested event stream into which to insert the rule condition check results generated by paths  802 . 
       FIG. 8( d )  depicts an embodiment for coprocessor  450  corresponding to that of  FIG. 8( a )  wherein a record and field identifier module  750  is positioned to receive the incoming stream  600  and partition the event stream into appropriate records and fields.  FIG. 8( e )  depicts an embodiment for coprocessor  450  corresponding to that of  FIG. 8( c )  wherein a record and field identifier module  750  is positioned to receive the incoming stream  600  and partition the event stream into appropriate records and fields. In this embodiment, bypass path  810  is preferably configured to communicate the partitioned event stream to the path merging module  804 . 
       FIG. 9  depicts an exemplary pipeline  900  (preferably deployed in firmware on a coprocessor  450 ) that is configured as a rules-based decision-making system. This exemplary pipeline  900  comprises three parallel paths—a first path wherein rule conditions are checked using a regular expression pattern matching module  904 , a second path wherein rule conditions are checked using an exact/approximate word matching module  910 , and a third path which serves as a bypass path  810 . At the head of pipeline  900  is a record and field identifier module  750  which creates the partitioned data stream received by the three paths. A first record join module  914  operates to join the streams emanating from the first two paths, while a second record join module  914  operates to join the merged stream of the first two paths and the original stream of the bypass path  810 . Downstream from the second record join module  914  is a record and field delimiter insertion module  916 . The first path preferably comprises a field selection module  902 , a regular expression pattern matching module  904 , and a secondary matching module  906  as shown in  FIG. 9 . The second path preferably comprises a field selection module  902 , a word parsing module  908 , an exact/approximate word matching module  910 , and a record appendage formatting module  912 . 
       FIG. 10  depicts an exemplary embodiment for a record and field identifier module  750 . A command parser  1000  is configured to receive command data for the module  750  (preferably by way of firmware socket module  404 ) and configure module  750  such that it operates as desired (e.g., instructions that identify the bit strings to be used as a record delimiter and the bit strings to be used as field delimiters). Data table  1002  stores one or more field delimiters eligible for insertion into the event stream to delineate field boundaries within data. Each field delimiter may be configured to impart meaning to the data values corresponding to a particular field. Also, each field delimiter can be configured to indicate an ordered location for a particular field within a record (e.g., field  1  should be before field  2  within a record, and so on). It should also be noted that each field delimiter may also optionally be simply a delimiter that does not itself contain any metainformation about the nature of its corresponding field. Data table  1004  stores one or more record delimiters for insertion into the event stream to delineate record boundaries within data. Optionally, each record delimiter can be configured to uniquely identify each record. To do so, a counter can be employed to populate the record delimiter table with the record delimiter to be used for each incoming record. The record delimiter can also be a bit string that is unique relative to other data within the stream but is not otherwise uniquely indicative of a particular record. In such instances, a downstream module can then assign a unique identifier to each record that has been marked with such an RDL. Data tables  1002  and  1004  can be maintained in available on-chip memory or other accessible memory such as memory  332 . 
     Field and record splitter  1006  operates to parse the raw data stream  600  to identify where record delimiters and field delimiters from tables  1002  and  1004  should be inserted. Splitter  1006  is preferably provided with (offset, length) pairs which indicate where the different fields exist relative to the start of each record. Upon encountering a location where an FDL needs to be inserted, the splitter  1006  can access table  1002  to retrieve the appropriate FDL and insert that FDL into the record at that location. In this manner, the field and record splitter  1006  is able to produce an output stream  752  of data events that are partitioned into records and fields. 
       FIG. 11  depicts an exemplary embodiment for a field selection module  902 , which serves as a filtering module  750  as previously described for the first and second paths of pipeline  900 . Each field selection module  902  is configured to reduce the data stream within its path to only records and fields that are to be considered against that path&#39;s rule set. A command parser  1100  is configured to receive command data for the module  902  (preferably by way of firmware socket module  404 ) and configure module  902  such that it operates as desired (e.g., instructions that identify the records and fields that are to be passed to or blocked from the output stream  1106 ). Field select table  1102  stores identifiers for the fields which are to be passed to (or blocked from) the output stream  1106  of selected data fields. The output of a field selection module  902  will be a stream  1106  of select data fields and their corresponding values. It should be understood that field selection module  902  may optionally be configured to retain the record identifiers in the output stream of select fields, which can enhance the throughput of the pipeline  900  so that stalls during merging operations are minimized. However, optionally, the pipeline  900  can be configured to process the select fields of a single record at a time within the pipeline paths, in which case the field selection modules  902  could also strip out the record identifiers from each record. 
     It should be understood that the field selection module  902  in each path of pipeline  900  can be configured to pass different fields based on the rule conditions within each path&#39;s rule set. That is, if incoming event stream  752  includes records partitioned into multiple fields, where one field is relevant to a rule condition within the first path&#39;s rule set but not any rule condition in the second path&#39;s rule set, then the field selection module  902  for the first path would be configured to pass that field while the field selection module  902  for the second path would be configured to block that field. In this manner, the field selection module  902  serves to lower the processing workload of downstream modules in each path. 
       FIG. 12  depicts an exemplary regular expression pattern matching module  904 . A command parser  1200  is configured to receive command data for the module  904  (preferably by way of firmware socket module  404 ) and configure module  904  such that it operates as desired (e.g., instructions that identify the regular expression patterns to serve as keys for the matching engines  1202 ). Preferably, module  904  employs a plurality of parallel regular expression pattern matching engines  1202 . In an exemplary embodiment, each engine  1202  is configured to detect a different regular expression pattern. Thus, one engine  1202  can operate to detect a credit card number pattern while another engine  1202  can operate to detect a social security number pattern. The stream  1106  of select data fields are broadcast to all of the matching engines  1202  to assess whether any of the data within the fields of stream  1106  match any of the data patterns keyed into the regular expression pattern matching engines  1202 . As noted above, the regular expression pattern matching engines preferably employ the technology disclosed in the above-referenced and incorporated U.S. Patent Application Publication 2007/0130140. Output logic  1204  serves to merge the matching fields output of the different engines  1202  together into an output stream  1206  of matching fields. In doing so, logic  1204  preferably enhances the output stream  1206  with an indication of which patterns were found to be present in a given input event. 
     It should be noted that module  904  is preferably only configured to output a match if any field within stream  1106  contains a data pattern which matches a regular expression pattern key. However, a given rule condition may require that the regular expression pattern key appear in a particular field of data. Thus, consider an example where a rule condition requires that regular expression A be present within field  3  of a record and where another rule condition requires that regular expression B be present within field  5  of a record. If a record with regular expression B within field  3  and regular expression A within field  5  is received by module  902 , then module  902  will output two matches. However, to assess whether these two matches actually satisfy the rule conditions, a secondary check is needed to find if the match occurred for a valid field-regular expression combination. To accomplish this purpose, pipeline  900  employs secondary matching module  906 . 
     An exemplary embodiment for a secondary matching module  906  is shown in  FIG. 13( a ) . A command parser  1300  is configured to receive command data for the module  906  (preferably by way of firmware socket module  404 ) and configure module  906  such that it operates as desired (e.g., instructions that identify valid match/field pairs). Preferably, module  906  employs a table  1302  which defines the combinations of regular expression patterns and fields which are valid rule conditions. Table  1302  can be maintained in available on-chip memory or other accessible memory such as memory  332 . Thus, continuing with the example from above, regular expression A and field  3  would be a valid pair, and regular expression B and field  5  would be a valid pair. The valid match filter  1304  operates to inspect the stream  1206  of matching fields to identify those field/pattern combinations within stream  1206  which have a corresponding pair in table  1302 . Those field/pattern combinations with a corresponding pair in table  1302  are then passed along in the output stream  1306  of valid matching data fields. 
       FIG. 13( b )  depicts an exemplary mode of operation for secondary matching module  904 . To facilitate the operation of the valid match filter  1304 , it is preferred that each regular expression pattern matching engine  1202  insert a bit string  1310  within each matching field that identifies the particular regular expression pattern which served as a match to the data field.  FIG. 13( b )  depicts an exemplary matching record  1308  with such a regular expression identifier  1310 . Table  1302  preferably stores data that is indexed in addresses  1314  that correspond to fields of the records. The table stores a column  1316  that contains a regular expression identifier for the regular expression pattern that is a valid pair with that table address&#39;s corresponding field. The table also preferably stores a column  1318  that contains a rule condition identifier for the valid field/regular expression pattern pair. Thus, as a record  1308  is received by filter  1304 , a lookup  1312  is performed in table  1302  using the field delimiter  764  of the record as an index to thereby retrieve the regular expression identifier  1320  and rule condition identifier  1332  for the table entry stored in the address defined by the index. Filter  1304  then performs a comparison  1322  between the regular expression identifier  1310  in record  1308  and the regular expression identifier  1320  retrieved from table  1302 . If there is not a match between the two, then filter  1304  drops record  1308 . If there is a match between the two, then filter  1304  replaces the regular expression identifier  1310  in record  1308  with the retrieved rule condition identifier  1332  for inclusion as a new field  1330  within a record  1334  to be output from the filter  1304  as part of stream  1306 . Thus, because field  3  of record  1308  produced a pattern match with regular expression A (thereby satisfying rule condition # 7 , the output record within stream  1306  will include a bit string  1330  that identifies rule condition # 7  as having been satisfied. 
     It should be noted that each field indexed by table  1302  may have multiple associated regular expression pattern identifiers. In such instances, it should also be noted that table  1302  can be alternatively configured such that the regular expression identifiers are used to index table entries, with the table entries being populated by field delimiters and rule condition identifiers. 
     The second path of pipeline  900  preferably includes a word separator module  908  downstream from that path&#39;s field selection module  902 . An example of such a word separator module  908  is depicted in  FIGS. 14( a ) and ( b ) . A command parser  1400  is configured to receive command data for the module  908  (preferably by way of firmware socket module  404 ) and configure module  908  such that it operates as desired (e.g., instructions that identify how to recognize white space within the data stream and how to separate the words delineated by the recognized white space). Preferably, module  908  employs a table  1402  which defines the data characters (or groups of characters) to be recognized as white space that separates words within data  766  of the fields within stream  1106 . Table  1402  can be maintained in available on-chip memory or other accessible memory such as memory  332 . Word separator module  1404  thus operates to parse data  766  found in input stream  1106  into its constituent words for output via stream  1406 . Operation  1410  operates to get the next character C within data  766 . A comparator  1412  then compares this character C t  with white space characters stored in table  1402 . If no match is found, then C t  forms part of the current word  1420  and operation  14110  gets the next character within data  766 . If comparator  1412  does find a match with a white space identifier, then operation  1414  retrieves a currently stored value for prevmatch (i) from register  1418 . If this value is 0, then operation  1416  sets prevmatch equal to t. If this value is not zero, then C t  forms the end of word  1420  for output from the word separator  1404 . The value prevmatch will thus be assigned the current value of the white space match (which is “t” in this example) so that the next time there is a white space match, then the next word can be ascertained. Also, the value for prevmatch is preferably reset to zero when a new field is input into the word parsing module. It should also be noted that the word separator  1404  can maintain a count of characters within each field so that it can also produce a position identifier for each word  1420  that identifies an offset for that word within a field or record. 
       FIG. 15  depicts an exemplary exact/approximate word matching module  910 . A command parser  1500  is configured to receive command data for the module  910  (preferably by way of firmware socket module  404 ) and configure module  910  such that it operates as desired (e.g., instructions that identify the strings to serve as keys for the matching engines  1502  and identify the exact or approximate nature of the matching operations). Preferably, module  910  employs a plurality of parallel exact/approximate word matching engines  1502 . The word stream  1406  is broadcast to all of the matching engines  1502  to assess whether any of the words with stream  1406  match (either exactly or approximately depending upon how engines  1502  are configured) any of the strings keyed into the matching engines  1502 . Optionally, each word matching engine  1502  can be configured to check for the presence of strings of a particular length within the word stream  1406 . Thus, a first engine  1502  can be configured to check for the presence of particular strings of length  3  within stream  1406 , while a second engine  1502  can be configured to check for the presence of particular strings of length  4  within stream  1406 , and so on. The exact/approximate word matching engines  1502  can employ any of the word matching technology discussed above for matching module  602 . Output logic  1504  serves to merge the matching words output from the different engines  1502  together into an output stream  1506  of matching words within the select fields. 
       FIGS. 16( a )  and (b) depict an exemplary embodiment for a record appendage formatting module  912 . Module  912  is configured to receive the hit stream  1506  from module  910  and format those hits into an appropriate bit string that is to be appended to the original record. A command parser  1600  is configured to receive command data for the module  912  (preferably by way of firmware socket module  404 ) and configure module  912  such that it operates as desired (e.g., instructions that identify how hits within stream  1506  should be formatted into a bit string to be appended to the record). An answer formatter  1602  then creates an appropriately formatted bit string for each incoming hit within stream  1506  to output a stream  1604  of field delimited matching words for the records together with the bit strings to be appended to the records. For example, as shown in  FIG. 16( b ) , a stream of hits in the form of pairs of matching words and their offsets within a field can be received and examined by the formatter at  1610 . Formatter can then assemble an output field with each word positioned at the offset defined by the received word/offset pair. 
       FIGS. 17( a ) and ( b )  depict an exemplary embodiment for a record join module  914 . Record join module  914  operates to merge two incoming streams into a single stream of merged events. A command parser  1700  is configured to receive command data for the module  914  (preferably by way of firmware socket module  404 ) and configure module  914  such that it operates as desired (e.g., instructions that identify how the streams are to be merged (e.g., what join keys are to be used). Each incoming stream is buffered in a record queue  1702 , and the queued records are processed by record merge logic  1704  to produce an output stream of merged records. Preferably, a record identifier is used as the join key, and there is preferably a one-to-one mapping of records coming into the record merge logic  1704  and records coming out of the record merge logic  1704 . For example, it may be the case that different fields of a particular record was processed in both of the rule condition checking paths of pipeline  900  such that each path made enhancements to that record. The record merge logic  1704  for module  914   1  shown in  FIG. 9  will then operate to merge the enhancements from the two instances of the record in the two record queues  1702  to output a single instance of the record in the output stream (wherein the output record contains the enhancements from both paths).  FIG. 17( b )  illustrates an exemplary operation in this regard, where two streams with different fields of the same record are present in queues  1702 . Each field identifier FDL will impart meaning as to how the fields are to be ordered within the merged output record  1720 . A field identifier will be retrieved from the queues  1702  at  1710 . A comparator  1712  will then look at these field identifiers to identifier an order for them. The field identifier with the highest order will be appended at  1714  to record  1720  while the field identifier with the lowest order will be retained for comparison with the next field identifier from the other stream. In this manner, record merge logic  1704  will ensure that the fields in the output record possess the appropriate order. 
     While record join module  914   1  receives input streams from the two rule condition checking paths of pipeline  900 , record join module  914   2  will receive as input streams the merged stream output by module  914   1  and the original partitioned event stream  752  produced by module  750  (by way of bypass path  810 ). Thus, the record merge logic  1704  of module  914   2  will operate to merge the enhanced records into the original partitioned event stream  752 . 
       FIG. 18  depicts an exemplary embodiment for a record and field delimiter insertion module  916 . Module  916  operates to receive the stream  1808  of enhanced records produced by the second record join module  914   2  and reformat the RDLs and FDLs as needed for the records to be processed by any downstream applications. This reformatting may take the form of returning the records to their format upon entry into pipeline  900  as stream  600 , formatting the RDLs and FDLs to a new format expected by downstream applications, or some combination of the two to thereby produce the output stream  608  of enhanced data events. It should also be noted that the enhancement fields  820  within stream  1808  may need to be partitioned into records and/or fields in a manner that will be understood by downstream applications. As can be seen from  FIG. 18 , the exemplary embodiment for module  916  preferably shares the same architecture (a command parser  1800 , field and record delimiter tables  1802  and  804 ) and logic  1806 ) as the previously described record and field identifier module  750 . 
     The enhanced records within  608  can then be streamed out of coprocessor  450  and returned to software running on the host system (e.g., software running on processor  412 ) or elsewhere within an enterprise computing system where post-processing in an action engine based on the enhancements can occur (if necessary) and the records can be inserted into an appropriately selected location in a relational database, saved to file, etc. within the enterprise computing system. It should also be noted that the stream  608  can be passed to additional modules within coprocessor  450  for post processing if desired. 
     It should be noted that pipeline  900  is also only exemplary in nature as different arrangements of paths and modules can be configured to meet a particular rule set. For example, it may be desirable to also employ a secondary matching module  906  in the exact/approximate word matching path. 
     It may also be desirable to process event streams against rule conditions that require consideration of multiple events, a process known as complex event processing (CEP).  FIG. 19( a )  depicts an exemplary complex event processing system  1900 . Multiple streams of data are handled by individual rule condition checking pipelines  900  which serve as event stream processors for individual events. The output of each individual pipeline  900  is then passed to a complex event generator  1902 . Complex event generator  1902 , which is also preferably implemented in firmware on coprocessor  450 , is preferably configured to aggregate the multiple enhanced streams that it receives and check for satisfaction of rule conditions across multiple events. Local storage  1904  is provided within system  1900  so that the complex event generator  1902  can examine a history of received events when checking for satisfaction of rule conditions which span multiple events. Preferably, upon detecting a pattern across multiple events that satisfies a particular rule condition, complex event generator  1902  is configured to insert a new event into the stream, wherein this new event indicates the existence of the detected pattern. 
       FIG. 19( b )  depicts an example of a task which could be performed by a complex event generator  1902 . In this example a threshold check operation is performed, namely, an enterprise would like to know when an aggregate sales amount for a particular item corresponding to rule condition # 7  (as determined by the processing performed by pipelines  900 ) exceeds a threshold amount. Such a task requires an aggregation of multiple events (i.e., sales transaction records for that item). Local storage  1904  preferably includes a table which tracks an aggregate value  1912  and corresponding alarm threshold  1914  for a plurality of items, with each item being determinable from a corresponding rule condition identifier  1910 . Thus, pipelines  900  can be thought of as scanning the event streams for sales transactions with an item number field equal to a particular serial number to determine which rule condition will be applicable (e.g., If “Item Number=ABCD123”, then “Flag the Record as Satisfying Rule Condition # 1 ”, If “Item Number=EFGH456”, then “Flag the Record as Satisfying Rule Condition # 2 ”, and so on). The table in storage  1904  preferably indexes the running aggregate value  1912  and alarm threshold  1914  pair by rule condition identifier  1910 , as shown in  FIG. 19( b ) . 
     Thus, as an enhanced record  1908  is received by the complex event generator  1902 , a lookup  1916  can be performed in the table using the rule condition identifier  1330  in record  1908  to retrieve the running aggregate value x and alarm threshold y for that rule condition identifier (see retrievals  1920  and  1928  in  FIG. 19( b ) ). Then an adder  1922  can sum the sales amount  1918  found in record  1908  with the current running aggregate value x to thereby compute new running aggregate value x new    1924 . At step  1926 , this x new  can be written back to the table to reflect the latest sales transaction. Also, a comparator  1930  can make a comparison between the computed x new  value and the retrieved alarm threshold y. If x new &lt;y, then no action needs to be taken (see stop step  1932  of  FIG. 19( b ) ). If x new ≧y, then step  1934  operates to create a new event for insertion into the stream which indicates the existence of the alarm condition. 
     It should be understood that such aggregation processing could also be performed within a pipeline such as pipeline  900  if an appropriate aggregation module is located downstream from a matching module. It should also be understood that the aggregation processing shown by  FIG. 19( b )  is exemplary only and any of a number of types of aggregation processing could be performed by complex event generator  1902 . 
       FIG. 20  depicts an exemplary environment in which a rule-based stream processing appliance  200  can be effectively employed. Appliance  200  can be configured as a business rules engine, an event stream processor, or a complex event stream processor as desired.  FIG. 20  depicts an enterprise computing system  2004  that receives a large volume of incoming data from the a network  2000  (such as the Internet or other data communication networks including PSTN, T1 lines, WANs, LANs, VPNs, and the like). After this incoming data passes enterprise firewall  2002 , it can be streamed through appliance  200  which receives the firewall output as an input data stream. Optionally the firewall output can also be passed directly to enterprise network  420  without passing through appliance  200  such that both appliance  200  and enterprise network  420  receive the firewall output. 
     Appliance  200  can thus be used to generate rule condition check results (and optionally additional secondary actions) for the incoming data stream as that data reaches the enterprise and before it lands in data storage somewhere within enterprise network  420 . The data processed by appliance  200  can also include data originating from within the enterprise computing system  2004 . Furthermore, appliance  200  can optionally be configured to output its generated rule condition results for delivery (or make its generated rule condition results available) to other processing entities within enterprise network  420  where rule-based post-processing can occur (such as taking one or more actions based on which rule conditions are shown to be satisfied within the enhanced stream produced by appliance  200 ). Further still, one or more terminals within enterprise network  420  can be configured to interface with appliance  200  to define the rule conditions and modules to be deployed in appliance  200 . 
     Accelerated stream processing in accordance with the embodiments of the present invention provides a myriad of beneficial uses. For example, one area where the inventors believe that a great need exists for low latency event stream processing is data quality checking and data integration.  FIG. 21( a )  depicts an exemplary pipeline  2100  which is configured to check data quality for a plurality of fields within a data stream  2102  (such as an XML data stream). Pipeline  2100  is preferably deployed on a coprocessor  450  in firmware. Each path&#39;s field selection module  910  can be configured to strip out fields within each record that are not relevant to that path&#39;s data quality checking task. 
     The first path of pipeline  2100  is configured to perform a range check operation on data fields within stream  2102  for which a rule exists that requires the data value for those fields to fall within specified ranges. Thus, field selection module  902   1  is preferably configured to only pass fields within stream which have range constraints. Downstream from module  902   1  is a range check module  2104 . If range check module  2104  detects that a particular field&#39;s data value is outside of the range specified for that field by a rule condition, then range check module  2104  preferably produces a rule condition check result indicative of this error condition. In this way, the record with the invalid data range can be passed to an exception handling routine before being loaded into storage such as a database or the like. 
       FIG. 21( b )  depicts an exemplary mode of operation for the range check module  2104  of  FIG. 21( a ) . Module  2104  preferably maintains (or has access to) a data table  2120 . Data table  2120  stores a plurality of pairs of lower limits  2124  and upper limits  2126  indexed by a value  2122  corresponding to a field within stream  2102 . Table  2120  can be populated with appropriate range limits for each field based on data quality rules for each field. As module  2104  receives a record  2118 , module  2104  performs a lookup  2128  in table  2120  to retrieve the lower/upper limit pair indexed by a field identifier for that record&#39;s pertinent field. A comparator  2136  then compares value  2130  with the retrieved lower limit  2132 . If value  2130  is less than the retrieved lower limit  2132 , then module  2104  operates to add one or more bits to record  2118  to flag that record for an out of range value with respect to the pertinent field&#39;s lower limit. Preferably concurrently with the comparison performed by comparator  2136 , comparator  2140  compares value  2130  with the retrieved upper limit  2134 . If value  2130  is greater than the retrieved upper limit  2134 , then module  2104  operates to add one or more bits to record  2118  to flag that record for an out of range value with respect to the pertinent field&#39;s upper limit. It should also be noted that an indirection table can be used by module  2104  to indirectly map a field identifier to entries in table  2120 , thereby allowing the entries in table  2120  to be indexed in consecutive addresses. 
     The second path of pipeline  2100  is configured to perform a character check on those data fields within stream  2102  for which the characters must fall within a particular character set (e.g., the characters must be a number, must be a letter, must be a member of the ASCII character set, etc.). Thus, field selection module  902   2  is preferably configured to only pass fields within stream which have a particular character set constraint. Downstream from module  902   2  is a character parsing module  2106 . Character parsing module  2106  operates to separate the characters within the select data fields. Character parsing module  2106  preferably operates in the manner of word parsing module  908  albeit for characters rather than words. Thereafter, character check module  2108  operates to determine if any character within the select field is not a member of the defined character set for that field. If module  2108  detects that a particular character value is not a member of a character set for that field as defined by a rule condition, then module  2108  preferably produces a rule condition check result indicative of this error condition. In this way, the record with the invalid character can be passed to an exception handling routine before being loaded into storage such as a database or the like. Module  2108  preferably operates using an exact matching module such as one based on the technology described above in connection with matching module  602 . 
     The third path of pipeline  2100  is configured to perform a value check on those data fields within stream  2102  for which the value must be a member of a limited set of possible values (e.g., a “color” field which must take one value that is a member of the set {red, blue, green, white, black}). Thus, field selection module  902   3  is preferably configured to only pass fields within stream which have a particular member set constraint (e.g., only the “color” fields of records within stream  2102  are passed by module  902   3 ). Downstream from module  902   3  is an exact word matching module  2110  that is keyed with the members of the pertinent member set (e.g., the keys are {red, blue, green, white, black}). If word matching module  2110  determines that the field value is not a member of the member set defined by the rule condition, then module  2110  preferably produces a rule condition check result indicative of this error condition. In this way, the record with the invalid field value can be passed to an exception handling routine before being loaded into storage such as a database or the like. Module  2110  preferably operates using an exact matching module such as one based on the technology described above in connection with matching module  602 . 
     It should be noted that modules  2104 ,  2108 , and/or  2110  can also be configured to generate one or more new events to indicate these error conditions rather than augmenting each of the affected records themselves. 
     Pipeline  2100  can be advantageously used in a data integration system such as an extract, transfer, load (ETL) system to provide an efficient means for ensuring that only quality data gets loaded into an enterprise&#39;s database(s). It should be understood that other data quality checking operations can be performed by a pipeline such as pipeline  2100  in a data integration system. For example, an additional data quality checking operation can be performed to identify whether data within select fields are properly formatted (e.g., ensuring that a bit length for a select field satisfies a rule condition, ensuring that a data value for a select field is right or left justified as required by a rule condition, etc.). 
     Another area where the inventors believe that a great need exists for low latency event stream processing with respect to business rules is the processing of high volumes of transactions such as credit card transactions.  FIG. 22  depicts an exemplary pipeline  2200  which is configured to process a high volume data stream  2202  of credit card transactions. Pipeline  2200  is preferably deployed on a coprocessor  450  in firmware. Each path&#39;s field selection module  902  can be configured to strip out fields within each credit card transaction record that are not relevant to that path&#39;s rule-based processing task. 
     The first path of pipeline  2200  is configured to check each transaction record for a valid credit card number. Thus, field selection module  902   1  is preferably configured to pass only the credit card number field of each record. An exact word matching module  2204  is configured with the set of valid credit card numbers as keys. Thus, if the credit card number within the credit card number field of a record within stream  2202  is valid, then module  2204  will find a hit on one of its stored keys. If a hit is not found on one of the stored keys, then one or more bits can be added to the pertinent record to indicate the error condition. Based on this error condition, an enterprise can be timely informed of the attempted use of an invalid credit card number and can decline authorization for the transaction. 
     The second path of pipeline  2200  is configured to provide security based on a range check for the purchase amounts in credit card transaction records. In many instances of credit card fraud, the perpetrator will attempt to test the validity of a stolen card number by first seeing if he/she can obtain a approval for a very small transaction with the stolen card number. If approved, the perpetrator later attempts a much larger purchase. Another risk posed with respect to credit card fraud is where the perpetrator attempts to purchase extremely expensive items with the stolen card number. While a large purchase amount itself may not necessarily indicate a credit card number is being fraudulently used, a cardholder or credit card company may nevertheless want to be timely informed when large purchases are made. To provide low latency warnings regarding such low value and high value credit card transactions, the second path of pipeline  2200  employs a range check module  2206  that operates in a manner similar to that described in connection with  FIG. 21( b ) . Field selection module  902   2  preferably operates to strip out fields from credit card transaction records so that only the fields pertinent to the range check remain (for example, the fields that identify a credit card number and purchase amount). Thereafter, range check module  2206  operates to generate a rule condition check result indicative of the security risk anomaly if a record&#39;s purchase amount is less than a lower alarm limit or higher than an upper alarm limit. 
       FIG. 23  depicts an exemplary mode of operation for range check module  2206 . Range check module  2206  maintains or has access to data table  2220 . Table  2220  preferably stores a lower alarm limit  2224  and upper alarm limit  2226  as pairs that are indexed by a value such as credit card number  2222 . When the pertinent fields of a credit card transaction record  2218  are processed by module  2206 , a lookup  2230  is performed in table  2220  using the credit card number  2228  within the record to thereby retrieve the pertinent lower alarm limit  2232  and the pertinent upper alarm limit  2234 . A comparator  2238  performs a comparison operation between the record&#39;s purchase amount  2236  and the retrieved lower alarm limit  2232 . If the purchase amount is less than or equal to the retrieved lower alarm limit, the module  2206  operates to add one or more bits to the pertinent record to flag it for an alarm as to the low purchase amount (step  2242 ). Concurrently with the operation of comparator  2238 , comparator  2240  performs a comparison operation between the record&#39;s purchase amount  2236  and the retrieved upper alarm limit  2244 . If the purchase amount is greater than or equal to the retrieved upper alarm limit, the module  2206  operates to add one or more bits to the pertinent record to flag it for an alarm as to the large purchase amount (step  2244 ). Such rule condition check results as provided at  2242  and  2244  allows a credit card company to make timely decisions such as denying the transaction, putting a hold on any further transactions with that credit card number, and contacting the card holder to inquire about the purchase. 
     The alarm limits present in table  2220  can be defined for each credit card number by a credit card company based on their knowledge in the industry or even defined by credit card holders themselves. Appropriate command instructions (received by pipeline  2200  by way of firmware socket module  404 ) can be used to populate table  2220  with appropriate values. It should be noted that a credit card company may optionally choose to use the same alarm limits for all credit card numbers, in which case the credit card number-based lookup into table  2220  would not be needed, and field selection module  902   2  can be configured to also strip out the credit card number field from each record. It should also be noted that an indirection table can be used by module  2206  to indirectly map each credit card number to entries in table  2220 , thereby allowing the entries in table  2220  to be indexed in consecutive addresses. Such an indirection table could be particularly useful if a credit card company chose to associate alarm limits with sets of credit card numbers rather than each credit card number individually. It should further be noted that modules  2204 ,  2206 , and/or  2208  can also be configured to generate one or more new events to indicate these security risk conditions rather than augmenting each of the affected records themselves. 
     The third path of pipeline  2200  is configured to provide security based on rule condition checks for various derived values generated from the credit card transaction records. Module  2208  can be configured to compute any of a number of derived values that may be relevant to security issues. For example, an unusually large purchase amount may be a cause for alarm. However, statistical processing is needed to keep track of values such as the historic average purchase amount for a credit card number and the current month&#39;s average purchase amount for a credit card number and to make decisions as to what qualifies as unusual purchasing activity. Another indicator for a security risk would be a sudden surge in the number of transactions over periods such as months, days, etc. To be timely warned of such potentially problematic situations, low latency aggregation and derived value computations are needed within pipeline  2200 . A derived value check module  2208  can provide such functionality. 
       FIGS. 24( a )-( c )  depict an exemplary mode of operation for a derived value check module  2208 . Module  2208  preferably maintains or has access to data table  2400 . Table  2400  preferably stores a plurality of values which are indexed by a value such as credit card number  2404 . Examples of values which can be stored in table  2400  in association with each credit card number are a historic transaction count  2406  (which is representative of the total number of purchases made with a credit card number since that credit card number&#39;s inception), a current month transaction count  2408  (which is representative of the total number of purchases made with a credit card number over the course of the current month), a current day transaction count  2410  (which is representative of the total number of purchases made with a credit card number over the course of the current day), a historic average purchase amount  2412  (which is representative of the average purchase amount for a single transaction with a credit card number since that credit card number&#39;s inception), a current month average purchase amount  2414  (which is representative of the average purchase amount for a single transaction with a credit card number over the course of the current month), and a current day transaction count alarm threshold  2416  (which is representative of the number of transactions for a credit card number which, if reached in a single day, will set of an alarm to warn of potentially fraudulent activity). It should be readily understood that more or fewer values could be stored by table  2400 . 
     As shown in  FIG. 24( a ) , as module  2208  receives a record  2218 , a lookup  2402  can be performed in table  2400  to retrieve the pertinent stored values associated with the record&#39;s credit card number  2228 . Upon retrieval of the historic transaction count  2418  pertinent to record  2218 , an adder  2420  operates to increment that historic transaction count to a new value  2422  which is then written back to table  2400  to update the card number&#39;s historic transaction count value. Thereafter, at step  2426 , module  2208  operates to perform a statistical operation such as computing a new value for the historic average purchase amount. To do so, the historic gross purchase amount can be computed by multiplying the retrieved historic transaction count  2418  by the retrieved historic average purchase amount  2424 . Thereafter, the current record&#39;s purchase amount  2236  can be added to the historic gross purchase amount and then divided by the new historic transaction count  2422  to arrive at the new value  2428  for the historic average purchase amount. This value  2428  can then be written back to table  2400 . Thereafter, at step  2430 , statistical processing can be performed to determine if the new historic average purchase amount  2428  exceeds some frame of reference with respect to the old historic average purchase amount  2424 . For example, an increase in value that exceeds some frame of reference may cause module  2208  to add one or more bits to the record  2218  to flag it for an alarm (step  2432 ). 
     As shown in  FIG. 24( b ) , similar processing as that shown in  FIG. 24( a )  can be performed by module  2208  with respect to monthly numbers. Thus, adder  2442  operates to increment the current month&#39;s transaction count  2440  to a new value  2444  which is then written back to table  2400  to update the card number&#39;s current month transaction count value. Thereafter, at step  2448 , module  2208  operates to perform a statistical operation such as computing a new value for the current month&#39;s average purchase amount. To do so, the current month&#39;s gross purchase amount can be computed by multiplying the retrieved current month&#39;s transaction count  2440  by the retrieved current month&#39;s average purchase amount  2446 . Thereafter, the current record&#39;s purchase amount  2236  can be added to the current month&#39;s gross purchase amount and then divided by the new current month&#39;s transaction count  244  to arrive at the new value  2450  for the current month&#39;s average purchase amount. This value  2450  can then be written back to table  2400 . Thereafter, at step  2452 , statistical processing can be performed to determine if the new current month&#39;s average purchase amount  2450  exceeds some frame of reference with respect to the old current month average purchase amount  2446 . For example, an increase in value that exceeds some frame of reference may cause module  2208  to add one or more bits to the record  2218  to flag it for an alarm (step  2454 ). 
       FIG. 24( c )  depicts a mode of operation for module  2208  with respect to daily numbers. Adder  2462  operates to compute a new value  2464  for the current day&#39;s transaction count using the retrieved current day&#39;s transaction count  2460 . The new value  2464  is written back to table  2400 . One security test for module  2208  is to see if the current day&#39;s transaction count has exceeded an alarm threshold. To do so, comparator  2468  performs a comparison operation between the new current day transaction count  2464  and the retrieved current day transaction count alarm threshold  2466 . If the current day&#39;s transaction count  2464  exceeds this threshold, then module  2208  operates to add one or more bits to the record  2218  to flag it for an alarm (step  2470 ). Also, simultaneously with comparator  2468 , the module  2208  can perform a statistical operation at step  2472  using data such as the new current day transaction count value  2464 , the retrieved current month average purchase amount  2446 , and the record&#39;s purchase amount  2236  to determine whether an alarm should be raised. If so, at step  2474 , module  2208  operates to add one or more bits to the record  2218  to flag it for an alarm. 
     It should be noted that the types of operations performed by module  2208  with respect to  FIGS. 24( a )-( c )  are exemplary only, as a derived value check module  2208  can be configured to compute any of a number of derived values for rule condition checking. For example, the balance limits for a credit card number can be computed and tracked using module  2208  as transactions corresponding to new purchases stream in, together with the generation of attendant rule condition check results using balance-based rule conditions. 
     Appropriate command instructions (received by pipeline  2200  by way of firmware socket module  404 ) can be used to populate table  2400  with appropriate values for values such as threshold  2416 . It should be noted that an indirection table can be used by module  2208  to indirectly map each credit card number to entries in table  2400 , thereby allowing the entries in table  2400  to be indexed in consecutive addresses. 
     Another area where the inventors believe that low latency event stream processing can provide significant advantages is with respect to the routing and secure storage of information such as social security numbers and credit card numbers within an enterprise. In many instances, an enterprise may choose (or may be required by law) to handle sensitive personal information in a more secure manner than other forms of enterprise data. Examples of such information which warrants specialized handling include social security numbers and credit card numbers. Such data may need to be specially encrypted and/or stored in particular databases. To comply with such requirements, it is desirable for an event stream processing appliance  200  to implement business rules which identify those incoming data events which contain such specialized information and then ensure that those data events are properly handled and routed within the enterprise computing system. Thus, a coprocessor within appliance  200  can employ a regular expression pattern matching module to detect which incoming data events contain patterns indicative of a social security number (e.g., nnn-nn-nnnn), a credit card number (e.g., nnnn-nnnn-nnnn-nnnn), and the like. Upon detection of such patterns in the incoming data events, those data events can be flagged with rule condition check results for special handling, which may include encryption and/or storage in particular databases. Based on such enhancements within the data events, other components within enterprise computing system can ensure that the sensitive data events are routed to appropriate handling routines. 
     Yet another area where the inventors believe that low latency event stream processing can provide significant advantages is enterprise protection of trade secrets. In such an instance, an enterprise may wish to employ appliance  200  of  FIG. 20  to also monitor outgoing data that is to be communicated outside the enterprise firewall to destinations within network  2000 . Thus, a coprocessor within appliance  200  can scan outgoing data streams for the presence of data which matches bit strings corresponding to an enterprise&#39;s trade secrets. For example, if an enterprise maintains a valuable trade secret for “Formula X”, it can program appliance  200  with a rule that essentially declares: “if “Formula X” is present within an outgoing data event, then block transmission of that data event until released by a person with appropriate authority.” A matching module within the coprocessor can then detect whether “Formula X” is present in an outgoing data event. Upon detecting the presence of “Formula X” in the outgoing data event, the coprocessor can re-direct the outgoing event to a holding queue from which it will only be released in the event of approval by a person with appropriate authority. The matching module for this trade secret protection functionality can be programmed with a number of keys that are indicative of an enterprise&#39;s trade secrets (e.g., chemical formulae, customer lists, sales numbers, etc.) such that all outgoing data events are inspected to assess whether a trade secret will be potentially released. 
     Additional areas where the inventors believe that low latency event stream processing based on business rules would be helpful include the acceleration of XML payloads, streaming SQL, the processing of financial market feeds to provide functions such as financial risk management, processing high volume transactional data other than credit card transactions (e.g., general sales transactions, telephone call records, etc.), security incident monitoring and prevention, the collecting of auditing data for compliance monitoring, applications needing low latency aggregation and statistical computations, monitoring sensor data streams (e.g., RFID), the monitoring of pharmaceutical sales records to detect potential “hot spots” where an epidemic may be breaking out, and the monitoring of sales transactions to identify where inventories need to be quickly replenished. 
     Another beneficial application for low latency event stream processing is the acceleration of a Rete network.  FIGS. 25( a ) and ( b )  depict an exemplary embodiment for a hardware-accelerated Rete network  2500 . Preferably, the Rete network  2500  is deployed in whole or in part on coprocessor  450 . The upper right hand corner of  FIGS. 25( a ) and ( b )  depict an exemplary rule set for Rete network  2500 . In this example, rule R 1  requires that rule conditions C 1 , C 2 , and C 3  be satisfied, rule R 2  requires that rule conditions C 1 , C 2 , C 4 , and C 5  be satisfied, and rule R 3  requires that rule conditions C 1 , C 2 , C 4  and C 3  be satisfied. 
     Alpha nodes  2504  receive an incoming fact stream and test these facts individually against the different rule conditions of the rules. The hardware-accelerated rule condition check operations described herein can be used by alpha nodes  2504  for this purpose (such as the matching operations, range check operations, threshold check operations, etc. as described above). Preferably, the alpha nodes  2504  are configured to perform these rule condition check operations for the different conditions on each fact in parallel with one another. Any facts which satisfy C 1  are stored in alpha memory  2506 . Any facts which satisfy C 2  are stored in alpha memory  2508 . Any facts which satisfy C 3  are stored in alpha memory  2510 . Any facts which satisfy C 4  are stored in alpha memory  2512 , and any facts which satisfy C 5  are stored in alpha memory  2514 . Preferably, these alpha memories are deployed in available memory space of the coprocessor  450 . Furthermore, preferably the alpha nodes  2504  are deployed as firmware application modules in a processing pipeline of coprocessor  450 . 
     Beta nodes within the Rete network then operate to check for whether any of the facts in the alpha memories satisfy the joinder of different rule conditions required by the rule set. Preferably, the beta nodes are also deployed on the coprocessor  450 . Beta node  2518  reads facts out of alpha memory  2506  and compares those records with dummy data within a dummy top node to store any matching facts in beta memory  2520  corresponding to Cl. Given that this is the topmost beta node in the network  2500 , all facts within memory  2506  will be written to memory  2520 . Thus, the Rete network  2500  can eliminate the dummy top node  2516 , beta node  2518 , and beta memory  2520  if desired. 
     Thereafter, beta node  2522  will read facts out of alpha memory  2508  and facts out of beta memory  2520  to find if any of the facts are overlapping. If so, these facts satisfy both C 1  and C 2 , and the beta node  2522  writes these facts to beta memory  2524 . 
     Next, beta node  2526  reads facts out of alpha memory  2512  and beta memory  2524  to find if any of the facts are overlapping. If so, these facts satisfy C 1 , C 2 , and C 4  and the beta node  2526  writes these facts to beta memory  2532 . In parallel with beta node  2526 , beta node  2528  operates to read facts out of alpha memory  2510  and beta memory  2524  to find if any of the facts are overlapping. If so, these facts satisfy C 1 , C 2 , and C 3 , thereby meeting the requirements of rule R 1 . Beta node  2528  writes these R 1 -compliant facts to beta memory  2530 . Thus, any facts (or combination of facts) present in memory  2530  are known to satisfy rule R 1 . 
     Next, beta node  2534  reads facts out of alpha memory  2510  and beta memory  2532  to find if any of the facts are overlapping. If so, these facts satisfy C 1 , C 2 , C 4 , and C 3 , thereby meeting the requirements of rule R 3 . Beta node  2534  writes these R 3 -compliant facts to beta memory  2538 . In parallel with beta node  2538 , beta node  2540  operates to read facts out of alpha memory  2514  and beta memory  2532  to find if any of the facts are overlapping. If so, these facts satisfy C 1 , C 2 , C 4 , and C 5 , thereby meeting the requirements of rule R 2 . Beta node  2536  writes these R 2 -compliant facts to beta memory  2540 . Thus, any facts present in memory  2538  are known to satisfy rule R 3  and any facts present in memory  2540  are known to satisfy R 2 . 
     Preferably, the beta nodes are also deployed in the coprocessor  450  (preferably as firmware application modules within the coprocessor&#39;s processing pipeline). Furthermore, the beta memories are also preferably deployed in available memory space of the coprocessor  450 . Through hardware-acceleration of the alpha nodes and beta nodes in pipelined firmware application modules, the inventors believe that dramatic improvements in performance can be made for Rete networks. 
     While for the preferred embodiments disclosed herein the coprocessor  450  comprises a reconfigurable logic device  402  such as an FPGA, it should be noted that the coprocessor  450  can be realized using other processing devices. For example, the coprocessor  450  may comprise graphics processor units (GPUs), general purpose graphics processors, chip multi-processors (CMPs), dedicated memory devices, complex programmable logic devices, application specific integrated circuits (ASICs), and other I/O processing components. Moreover, it should be noted that appliance  200  may employ a plurality of coprocessors  450  in either or both of a sequential and a parallel multi-coprocessor architecture. 
     The modules described herein can be readily developed as firmware application modules by a practitioner of various embodiments of the invention using the techniques described in the above-referenced and incorporated U.S. Patent Application Publication 2006/0294059. 
     While the present invention has been described above in relation to its preferred embodiments, various modifications may be made thereto that still fall within the invention&#39;s scope. Such modifications to the invention will be recognizable upon review of the teachings herein. Accordingly, the full scope of the present invention is to be defined solely by the appended claims and their legal equivalents.