Patent Publication Number: US-7711622-B2

Title: Financial statement and transaction image delivery and access system

Description:
FIELD OF THE INVENTION 
     The invention relates generally to systems for delivering financial information, and more particularly, to systems for delivering and accessing financial statements and processed financial transaction documents. 
     BACKGROUND OF THE INVENTION 
     In recent years, the use of online banking by commercial and retail customers has increased significantly. Online banking has been found to be much more desirable and efficient than traditional banking. Increasing emphasis is being directed to the use of electronic bank statements, checks, deposit slips and other documents, rather than the paper documents themselves. The use of these images can significantly reduce the expense, need and demand for the use of hard copy documents by customers. 
     There is, however, an element that is missing in the process. Customers who still use paper transactions along with their online banking are not able to effectively integrate those paper documents with their automated systems. Bank customers do not have the ability to keep imaged copies of bank statements, checks, deposit slips and other documents, on their own computers. 
     There are three common methods of making banking documents available to customers. First, the customer can receive the physical documents, checks, deposit slips, and other documents. The documents are then filed and are available for manual retrieval for viewing and copying. Customers may also scan the individual documents for placement in computer folders. 
     This method has many disadvantages. The bank must retain and mail the documents to the customer. This is a costly and inefficient process. The customer must physically store those documents, requiring the labor to do so and the space to accomplish this. Retrieval must be done manually, which is a tedious and costly process. Individual copies or scans must manually be made of the required documents. The documents must be returned to the file and properly archived. This is a very costly process due to associated labor, storage and operational inefficiencies. 
     An alternative to this system is sending copies of the documents, minimized in sheets, rather than sending the actual documents to the customer. From the customer standpoint, this system has the same drawbacks of maintaining the original documents. In addition, however, making copies for use by the customer is more difficult because of the decreased size and legibility of the copies of the document originals. 
     A second method involves banks providing CDs of the imaged documents for their customers. Single CDs are created for each customer and mailed. Customers must load the CD and viewer software onto their computers and register each CD before searching. Then customers must search each CD in order to view and use the images. Generally, each CD contains a maximum of one month of data. Therefore, databases must be searched individually and cross database searching is not possible. 
     The CD system is very cumbersome for the bank. Single CDs must be made for each customer. The CDs must be physically delivered to the customer by mail or courier. The system is generally only viable for large commercial customers making this type of image delivery unavailable for the majority of customers. 
     From the customer&#39;s standpoint, the information is not immediately available due to processing and mail time. Large customers may need the information as close to real time as possible in order to properly manage cash and lockbox situations. The CD system does not allow for this timely delivery. 
     Also, the use of CDs is inefficient. Even when the information from numerous CDs is loaded on the customer&#39;s computer, there is no ability to search across all information. The database on each CD represents only one month of bank images and must be searched individually. 
     The third method is to provide customers with online access to the images of their documents. In order to access the account information online, customers must log on to the bank Web site and enter the secure section. Then they can search, view and print out the documents individually. This system also has significant drawbacks. 
     If the server is unavailable, or customers do not have online access at the time the information is needed, online banking can be very frustrating. Since images must be accessed individually, there is no easy way to compile the imaged documents for a particular purpose. For example, it is difficult, if not impossible for a customer to create folders of vendor or supplier specific images. Customers, likewise, cannot feasibly create a folder of images for a given day or month. Even if the time were taken to manually organize all the desired images, the data could not be searched. 
     On the bank&#39;s side, customer information must be retained in the bank&#39;s online server for a significant period of time. Retrieval of specific information for a customer query after the information is removed from the online server is a costly process for the bank and the customer. The research process to find needed transactions not located on the banks server is very inefficient. The search process is time consuming, tedious and almost cost prohibitive for the bank and its customers. 
     A modification of this method is to allow customers online access to or download ability of PDF files of their documents. This has many drawbacks for the customer. The information is not indexed so even basic searches are difficult and cumbersome. Additionally, making copies of individual documents is generally impossible for most customers. 
     With the methods used currently, there is no effective way to allow customers to become paperless with regards to bank data. Previously, this technology has been unavailable. 
     SUMMARY OF THE INVENTION 
     The present invention gives financial institutions, such as banks, the ability to provide paperless banking to their customers. Although the technological implementation of the invention is complex, the process of using the invention is made very simple for the customer. A customer-level software application is made available to customers on the bank&#39;s Web site for download. Customers can then install the software on their own computers. 
     When images are produced or received by the bank, those images are extracted from the image server, indexed by an indexer, and made available for download. An email is generated and sent to customers informing them that their bank statements, check, deposit slip and other images are available electronically from the bank. 
     Customers then log on to the bank&#39;s secure Web site and download a file containing their banking images. The provided software application then opens with the downloaded file expanded for immediate use and available for viewing and searching. 
     Using the provided software application, customers can efficiently review their documents. The imaged documents are high quality digital images making them acceptable as proof of payment and are identical to the hard copy original documents. The downloaded financial transaction document images are automatically organized in folders according to the time period provided. Customers can search one or all folders of the imaged documents on their computers and retrieve all desired images. With the provided software application, customers can print, email and manage a single document or an entire folder of documents. 
     Another version of the present invention for large commercial customers is also very simple. Software can be downloaded directly onto computers or servers at the customers&#39; locations, or downloads can be managed by a network administrator. 
     Images can be indexed as they are produced, and the download can be accomplished automatically on the Internet or by sending a secure FTP download. It is also possible to send the images to the customer and have the indexing completed at the customer&#39;s location. 
     With the provided software application, customers can review their documents very quickly. Each imaged document appears exactly as the hard copies of those documents. Customers can also create custom folders to organize their documents. They can search that folder along with all folders of document images on their computers and retrieve desired images. They can print, email and manage a single document or an entire folder of documents. 
     For very large commercial customers, the benefits are extremely important from a cash management standpoint. Information can be provided to customers daily, if required, within a short time after the images are generated or received. The folder can be immediately sent to the customer electronically. The images are then available for the customer to identify relevant information about transactions based on the data contained in the image. The images can also be used to reconcile accounts receivable, accounts payable, lock boxes and other financial management elements. 
     Images can also be used for customer support purposes. The images can be quickly searched to locate information for customer or supplier inquiries. The images can then easily be emailed or copied and mailed or faxed to the inquiring party. 
     For customers, the benefits of going paperless are clear. They have a single location of imaged banking data and a simple interface for accessing the data. The present invention provide customers with immediate access to their information, better organization and control, and a cleaner and more accurate audit process. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a flow chart illustrating one embodiment of a check and statement delivery system integrated into an existing CD-based check image delivery system. 
         FIG. 2  is a flow chart illustrating one embodiment of a customer notification process for a check and statement delivery system. 
         FIG. 3  is a flow chart illustrating one embodiment of a customer application for searching and viewing financial statements and check images. 
         FIG. 4  is a screenshot illustrating the computer screen layout of one embodiment of a customer application for searching and viewing financial statements and check images. 
         FIG. 5  is a flow chart illustrating one embodiment of a system and method for generating, indexing, and delivering financial statements and check images to a customer. 
         FIG. 6  is a flow chart illustrating the data synchronization process of the system and method of  FIG. 5 . 
         FIG. 7  is a flow chart illustrating the batch preprocessing process of the system and method of  FIG. 5   
         FIG. 8  is a flow chart illustrating the statement splitting process of  FIG. 7 . 
         FIG. 9  is a flow chart illustrating the check image splitting process of  FIG. 7 . 
         FIG. 10  is a flow chart illustrating the indexing process of the system and method of  FIG. 5 . 
         FIG. 11  is a flow chart illustrating the statement and check image packaging process of the system and method of  FIG. 5 . 
         FIG. 12  is a flow chart illustrating the archive creating process of the system and method of  FIG. 5 . 
         FIG. 13  is a flow chart illustrating the process of data transport process of the system and method of  FIG. 5 . 
         FIG. 14  is a functional flow diagram of one characterization of the check and system delivery method according to the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates one embodiment of a financial transaction image and statement delivery system  100  integrated into an existing CD-based check image delivery system. A data extraction process  120  is used to extract stored data from an image server  110  into both a pre-existing CD-based check data delivery process  130  and into a new, downloadable archive-based statement and transaction image delivery process  140 . The new statement and transaction image delivery process  140  places downloadable customer data packages  150  on a web server  160 . Customers then download these customer data packages  150  to their workstations  170 . 
       FIG. 2  illustrates one embodiment of a customer notification process  200  for the financial transaction image and statement delivery system  100  of  FIG. 1 . In step  210 , a customer  250  is notified, for example via an e-mail, of the availability of a downloadable indexed customer data package  150 . The customer  250  then connects through the internet  230  to the web server  160  where the data package  150  is stored, and downloads the data package  150  to the customer&#39;s local storage  260 . The customer has a client application  270  that is operable to open up the data package  150 , extract and store the contents locally, and make the contents and the index available for viewing and searching within the client application  270 . 
       FIG. 4  is a screenshot  400  illustrating the screen layout of one embodiment of a client application  270  for searching and viewing financial statements and transaction images. The client application  270  lists a plurality of selectable hypertext-formatted transaction statements in a first window area  410  in the upper left region of the layout. Each of the listed transaction statements is associated with a searchable index of the processed financial transactions listed within the statement. The client application  270  can load multiple transaction statements simultaneously and search across multiple transaction statement indexes simultaneously. Selected statements or selected checks, deposit slips, debit notes, or other imaged financial transaction documents are displayed in a second window area  420 . 
     When a financial transaction statement is displayed in the second window area  420 , any checks listed in the second window area  420  are hypertext linked so that they can be selected. Upon selection of one of the check numbers  425 , the corresponding cancelled check image is displayed in the second window area  420 . 
     Below the first window area  410 , a search manager  430  is provided that allows a customer to select or input a range of transaction dates with which to confine a financial transaction image search. The search manager  430  also provides a drop-down list  432  that allows the customer to search for either “all” the financial transaction images within the selected transaction date range, only those financial transaction images that match an input “amount,” only those financial transaction images that match an input “amount range,” only those financial transaction images that match an input “check number,” or only those financial transaction images that match an input “check number range.” Other embodiments of the search manager  430  may provide other searchable fields, such as check date (as opposed to the cleared transaction date) or recipient name. 
     After the customer enters the search criteria and selects the “Search” button  434 , the financial transaction images matching the search criteria are displayed in a third window area  440  directly below the second window area  420 . The search results are listed under various fields, such as date  441 , account number  442 , check number  443 , and amount  444 . Selection of any of these fields causes the search results to be sorted, in ascending or descending order, by the selected field. 
       FIG. 3  illustrates the searching capabilities of the client application  270  for searching and viewing financial statements and check images. In step  310 , the customer opens the client application  310  simply by clicking on the downloaded indexed customer data package  150 . In step  320 , the customer inputs search parameters—e.g., a transaction date or date range, a check amount or check amount range, and/or a check number or check number range—into the search manager  430 . In step  330 , the search is performed across all the saved indexed financial transaction image archives  340  and the matching images are retrieved. In step  350 , the customer may select any of the search results and thereby view the corresponding financial transaction image in the second window area  420 , and view, print, and e-mail the images. The customer can also create folders—for example of tax-significant transactions—and drag and drop selected images into those folders. 
       FIG. 5  is a flow chart illustrating one embodiment of a financial statement and document delivery and access system  500 . The system comprises a system-level data processor  570  serving one or more financial institutions to provide statements and processed financial transaction document images to their customers. The system-level data processor  570  is in communication with a data store  580  for the serviced financial institution. 
     The system-level data processor  570  runs one or more software programs that are operable to retrieve a composite statement batch file of monthly (or quarterly or other periodic) transaction statements for a group of customers or accounts for which statements are routinely prepared on a given day of the month (or quarter or year or other period); convert the composite statement batch file into hypertext-formatted transaction statements for each customer or account for that period; retrieve a composite financial transaction document image archive that contains cancelled check images (and images of other processed financial transaction documents such as deposit slips) corresponding to the transactions listed in the transaction statements in the composite statement batch file; convert the composite financial transaction document image archive into individual image files for each processed transaction; identify the individual image files that correspond to each hypertext-formatted transaction statement; store each hypertext-formatted transaction statement and its corresponding processed financial transaction images under a common parent directory; generate hypertext links between the transactions listed on the hypertext-formatted transaction statements and the corresponding processed financial transaction document images; for each hypertext-formatted transaction statement, generate a searchable index of the corresponding processed financial transaction document images; and generate an archive file containing the hypertext-formatted transaction statement, the corresponding transaction document images, and the searchable index. 
     Many financial institutions routinely generate monthly transaction statements for different batches of customers or customer accounts on different consistent days of the month. For example, a group of approximately 5% of a bank&#39;s customers&#39; financial statements might be consistently generated and mailed out on the 1 st  day of the month, a group of another 5% of a bank&#39;s customers&#39; financial statements might be generated and mailed out on the 2 nd  day of the month, and so on. (Frequently, Saturdays, Sundays, and holidays are omitted). The financial statement and document delivery and access system  500  is designed to interface with such an existing system. 
     At regular intervals, the system-level data processor  570  runs a data synchronization process  510  to download batches of statements and images from the financial institution&#39;s image server. The data synchronization process is illustrated in  FIG. 6  and explained further below. Step  512  illustrates the system-level data processor  570  waiting for a batch to be downloaded. If a data processing error is encountered while waiting for batch synchronization, in step  513 , the system-level data processor  570  runs a process to handle the data processing problem. Once a batch is successfully downloaded, then the system-level data processor  570  runs a process  514  to validate the input path to the downloaded batch. If the input path is valid, then in step  516  the system-level data processor updates the data processing log  585  and in step  518  updates the batch log  575 . If the input path is invalid, then in step  517 , the system-level data processor  570  runs a process to handle the source data problem. 
     After completing step  518 , the system-level data processor  570  runs the following sequence of processes: a process  520  to preprocess the batch (described further in connection with  FIGS. 7-9 ); a process  530  to index the statements, check and other financial transaction images (described further in connection with  FIG. 10 ); a process  540  to package each group of statements, check and other financial transaction images associated with a given customer or customer account (described further in connection with  FIG. 11 ); a process  550  to archive the packages into a single downloadable file (described further in connection with  FIG. 12 ), and a process  560  to deliver the archives to the customer (described further in connection with  FIG. 13 ). As each of these processes  520 - 560  is completed, the system-level data processor  570  reports each success or error on the data processing log  585 . 
       FIG. 6  illustrates the data synchronization process  510  of the system and method of  FIG. 5 . In step  610 , the system-level data processor  570  synchronizes its own image archive  675  with the image archive  665  maintained on the pre-existing image server  670  serving the financial institution. As part of this synchronization process, one or more composite multi-page image files  615  (typically TIFF-formatted image files), typically comprising hundreds or thousands of check and other financial transaction images processed by the financial institution on a given day, are copied from the institution&#39;s image archive  665  to the system image archive  675 . 
     In step  620 , the system-level data processor  570  synchronizes its own statement processing archive  695  with the statement processing archive  685  maintained by or on behalf of the financial institution. As part of this synchronization process, a multi-statement batch file  625  is copied from the institution&#39;s statement processing archive  685  to the system statement processing archive  695 . The batch file  625  is typically in the form of an ASCII text and ASCII-formatted file comprising hundreds or thousands of statements processed by the financial institution on a given day. Banks conventionally simply print this batch file  625  out onto bank letterhead and mail the statements to their customers. As explained further in connection with  FIG. 8 , the present invention uses this same batch file  625  to generate hypertext-formatted statements in which the font, font size, and spatial layout of the text is identical or nearly identical to the font, font size, and spatial layout of the text on the paper statements conventionally mailed to customers 
     After a new statement batch file  625  is copied, in step  630 , the system-level data processor  570  records the event in the data processing log  585 . Then, in step  640 , the system-level data processor  570  sets a query processor flag to “run” in a query service configuration file  645 . 
     In one embodiment, a query is constructed that provides the image server database  680  with a statement date and asks the Image Server database  680  to return a text file  655  that lists every account number for which a statement has been created on that date, the transactions that took place during the statement period, the name and location of the multi-page image file(s)  615  containing check and other financial document images corresponding to those transactions, and the starting and ending bytes of the corresponding check and other financial transaction images in the composite multi-page image file(s)  615 . In other embodiments, information from the composite statement batch file may be parsed to further populate the query service configuration file  645  with more specific information—for example, a particular account number or range of account numbers—with which to query the image server database  680 . 
     In step  650 , information from the query service configuration file  645  is used to query an image server database  680  hosted by the image server  670 . The query returns an image list  655  identifying the account numbers, and for each account number the transactions that took place during the statement period, including the transaction posting date, the serial number. The image list also includes the name and location of the corresponding multi-page image file(s)  615  containing the corresponding check and other financial document images corresponding to the listed transactions, and the starting and ending bytes of the corresponding images in the composite multi-page image file(s)  615 . The system-level data processor stores the image list  655  in the statement processing archive  695 . The image list  655  is later used to derive check image files for each cancelled check from the composite multi-page image file(s)  615 . 
       FIG. 7  illustrates the batch preprocessing process  520  of the system and method of  FIG. 5 . The process begins by reviewing the batch log file  575 , and in step  710 , verifying the path to the multi-statement batch file  625 . If the path is verified, then a process  720 , further described in connection with  FIG. 8 , is executed to split the multi-statement batch file  625  into individual statements. If this process is successful, then in step  730 , the path(s) to the multi-page image file(s)  615  is/are verified. If the paths are found to be valid, then a process  740 , further described in connection with  FIG. 9 , is executed to split the multi-page image file(s)  615  into individual check, deposit slip/record, and debit record images. If this process is successful, then in step  750 , statements for which there has been no account activity that would result in any transaction images are identified, and these statements are processed in step  760 . If at any point in the batch preprocessing process  520  an error is encountered, the error is reported in the batch log file  575 . 
       FIG. 8  illustrates the statement splitting process  720  of  FIG. 7 . In step  810 , the data processor  570  evaluates the number of accounts in the statement batch file  625 . If there is more than one account, then in step  820 , the statement batch file  625  is split into temporary individual statement files  825 . Then a loop process  830  is executed for each account statement  825 , in which in step  840  a statement directory  845  is created and in step  850  a hypertext statement  855  is generated. The hypertext statement  855  is formatted to include the financial institution&#39;s letterhead and to look like mailed paper versions of statements customarily mailed out by the financial institution. The results of this process  830  are then documented in the batch log  575 . 
       FIG. 9  illustrates the financial transaction image splitting process  740  of  FIG. 7 . The financial transaction image splitting process  740  includes a loop process  910  in which the data processor  570  loads the image list  655  into a memory array and a series of steps are executed for each transaction document image. For each image, in step  920  the corresponding multi-page TIFF-formatted image file  615  is located. When located, in step  925  the batch log  575  is updated, and in step  930 , the located image file  615  is split into individual TIFF-formatted image files  935 . In step  940 , the individual TIFF-formatted image files  935  are converted into JPEG-formatted images  945 . In step  950 , an HTML-formatted check page  955  is created for, and linked to, each JPEG-formatted image  945 . The HTML-formatted check page  955  and associated JPEG-formatted images  945  are stored under a common parent directory  965 . After steps  920 - 950  are completed for each image in the image list array, then in step  970  an indexer run script  975  is created for use by the indexing process  530 . The financial transaction image splitting process  740  concludes with a cleanup routine  980 , during which temporary files, such as the individual TIFF image files  935 , are deleted, and the batch log  575  is updated. 
       FIG. 10  illustrates the indexing process  530  of the system and method of  FIG. 5 . In an embodiment actually reduced to practice, the indexing functions are carried out by an indexer  1050  running on a fast and efficient Linux-based operating system, separate from the data processor  570 , which runs a Windows-based operating system. To accommodate this setup, in step  1010 , the html check pages  955  are copied from the storage associated with the data processor  570  to a data store  1055  accessible to both the data processor  570  and the indexer  1050 . In step  1015 , the indexer run script  975  is copied to the data store  1055 . In step  1020 , an indexer flag  1025  is set (or created). In one embodiment, the indexer flag  1025  is set by creating a simple file. 
     Meanwhile, in step  1045 , the indexer  1050  looks for the indexer flag  1025 , and when one is detected, in step  1060  it retrieves the indexer run script  975 . In step  1065 , the indexer  1050  resets the indexer flag  1025  (which in one embodiment involves simply renaming the file that acts as the flag). In step  1070 , the indexer  1050  validates the indexer run script  975 . In step  1075 , the indexer  1050  executes the indexer run script  975  to generate indexes of the transaction dates, transaction amounts, and check numbers of the checks listed on the transaction statement. Once the indexing is complete, then in step  1080  the indexer generates the corresponding indexes  1090  and sets an indexer done flag  1035  (in one embodiment this is accomplished by creating a simple indexer done file). If any errors occur in steps  1060 ,  1065 ,  1070 , or  1075 , an error notification process  1085  is executed. 
     Turning back to the indexing process running on the data processor  570 , in step  1030 , the data processor  570  waits for an indexer done flag  1035  to be set (or created) and placed on the data store  1055  to indicate that the indexer  1050  has run. After the indexer done flag  1035  is read, the data processor  570  runs a cleanup process  1040 , which moves the indexes  1090  to another location and deletes and/or moves various other files. 
       FIG. 11  is a flow chart illustrating the statement and check image packaging process  540  of the system and method of  FIG. 5 . The packaging process  540  runs a loop  1110  in which a series of steps are executed for each account. In step  1120 , the number of check directories is counted. If more than one is found, then in step  1130  the check directories are combined. In step  1140 , the check and statement directories are combined. In step  1150 , background images  1155  used to render the bank&#39;s letterhead are inserted in or linked to the statement pages  855 . The background images  1155  are duplicated and placed in every statement directory  845  so that they will reside within each database, so that each viewed statement will look like a mailed statement. 
       FIG. 12  illustrates the archive creating process  550  of the system and method of  FIG. 5 . The archive creating process  550  runs a loop  1210  in which a series of steps are executed for each account directory. In step  1220 , the contents of the account directory are copied to a backup location for disaster recovery. In step  1230 , the contents of the account directory are zipped into a single archive file  1245 . In step  1240 , the archive file  1245  is provided with a consistent, application-specific file format extension. In the reduced-to-practice embodiment, the extension is “.ocz”, and the installation program provided with the client-based application  270  causes the customer&#39;s computer to associate the “.ocz” file format extension with the client-based application  270 , so that when the customer executes a command to open a “.ocz” file, the client-based application  270  automatically extracts the archive&#39;s contents, stores the contents locally, and makes the contents and index available for perusal within the client-based application program  270 . In step  1250 , the data processor  570  verifies the archive file  1245  before deleting the original account directory in step  1260 . After steps  1220  through  1260  are repeated for each account directory, then in step  1270  the batch log is updated. 
       FIG. 13  illustrates the data transport process  560  of the system and method of  FIG. 5 . The data transport process  560  executes a loop process  1310  for all of the account archives. In step  1320 , the account archive file  1245  is copied to the delivery point (i.e., the bank&#39;s disk storage allocated to the web delivery system for serving the archives). The data processor  570  updates the batch log  575  in step  1330  and deletes the original archive file  1245  in step  1340 . After completing the loop process  1310  for all of the account archives, the data processor  570  once again updates the batch log  575 . 
       FIG. 14  is a functional flow diagram of one characterization of the check and system delivery method  1400  according to the present invention. In step  1410 , retrieve a composite statement batch file of monthly (or quarterly or other period) transaction statements for a given day of the month (or quarter or other period). In step  1415 , convert the composite statement batch file in to hypertext-formatted monthly (or quarterly or other period) transaction statements for each customer or customer account. In step  1420 , query the image database server to identify locations of images in the composite processed financial document archive. In step  1425 , retrieve the composite processed financial document image archive containing cancelled check images, deposit slips, and other processed financial transaction images for the given day of the month, quarter, or other period. In step  1430 , convert the composite financial document image archive into individual image files for each transaction listed in the transaction statement. In step  1435 , generate hypertext links between the transactions listed on the hypertext-formatted transaction statements and the corresponding processed financial transaction images. In step  1440 , for each hypertext-formatted transaction statement, generating a searchable index of the corresponding processed financial document images. In step  1445 , generate an archive file containing the hypertext-formatted monthly transaction statement, the corresponding processed financial document images, and the searchable index. In step  1450 , deliver the archive file to the corresponding customer over the Internet. In step  1455 , provide customers with a client-based application program for installation on their computers that is operable to open up the archive file, extract and store the contents locally, and make the contents and index available for viewing and searching within the client-based application program. In step  1460 , cause the customer&#39;s operating system to associate the archive file extension with the client-based application program. 
     Persons of ordinary skill in the art, enlightened by the present specification and those incorporated by reference, will understand how to build a system or write software code capable of carrying out the inventive concepts disclosed herein. 
     Although the foregoing specific details describe a preferred embodiment of this invention, persons reasonably skilled in the art will recognize that various changes may be made in the details of the method and apparatus of this invention without departing from the spirit and scope of the invention as defined in the appended claims. Therefore, it should be understood that, unless otherwise specified, this invention is not to be limited to the specific details shown and described herein.