Method and apparatus for distributing files on a file storage device5678046Abstract A method and apparatus for storing and retrieving images of documents, e.g. checks. The method comprises placing a plurality of documents in a document imaging machine and forming an electronic image of each document, storing each electronic image in an electronic storage device, providing at least one user interface device in communication on a communication link with the electronic storage device, placing a request for at least one document image on the user interface device, transmitting the request by the communication link to the electronic storage device, searching the electronic storage device for the requested electronic image of the document, retrieving the at least one electronic image or providing an indication that the image was not found, storing the electronic image, if found, in an electronic file, for transmission to the user interface device at user option, providing the electronic image to the user interface device at command of a user at the user interface device for storage at the user interface device and displaying the requested electronic image on a display of the user interface device. Preferably, the electronic, images are stored with embedded identifying information in a TIFF.RTM. (trademark of Aldus Corp.) file format and the check images can be displayed on a display device which permits the user to view both sides of the checks simultaneously and perform functions such as zooming and rotation of the images. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Type of Check Request/Checks Written
______________________________________
health insurance refunds
1/2000
personal income tax refunds
1/200
social security payments
1/100
welfare payments 1/50.
______________________________________
To accommodate these requests, financial institution customers often maintain their own extensive check libraries. Often such customer-maintained check libraries are kept on microfilm, which can be made by the customer itself from the returned check or can be purchased directly from the financial institution. The financial institution's seven year library of check microfilm is often used as a backup source for check copies. In some cases, due to the cost of maintaining an archive, and fulfilling payee requests, the bank's seven-year library is the customer's primary source. Furthermore, depending on the type of customer and account, the institution is often subpoenaed by the government to produce photocopies or originals from its seven year library. Whether the original checks are kept or they are reduced to microfilm, and regardless of whether it is maintained by the payor bank or the customer, it is readily understood that there are many costs associated with maintaining a check archive and retrieving check copies upon request. For example, the production and manipulation of microfilm libraries is a labor intensive process and the quality of the photocopies produced is often low. Although storing a high resolution digital image of the front and rear surface of a check could be used as a potential replacement for microfilm, the cost of storing all checks in such format, and the difficulty inherent in locating and retrieving them, made this storage media impracticable in the past. To fulfill its customers' requests or comply with subpoenas, countless man-hours of searching are required to locate copies of the requested instruments. Due to the immense volume of stored information, the average turn-around time--the time elapsed from when the request is made until the copy is received--for fulfilling such requests can vary from a minimum of 24 hours to one to two weeks or more. Importantly, if a check copy cannot be found or its quality is too poor to reconcile the inquiry, the payor may be required to write the check again and send it to the recipient--incurring the expense of double payment despite the expense of maintaining a check library, and searching for a check. Further, to facilitate processing of checks, the banking industry has, for many years, used a Magnetic Ink Character Recognition (MICR) line on each check. The MICR line of a check is a series of alpha-numeric digits encoded on a check in magnetic ink. The MICR line is also optically readable. A MICR line is found along the bottom of most checks. The encoded information in the MICR line usually includes the account number and check number. Where the check writer (or some intermediate in the check handling process) chooses, the encoded information in the MICR line also includes the amount of the check. Frequently, a large company that prints its own checks may encode the check amount in the MICR line. Normally, when a check is processed, the information contained in the MICR line is scanned, interpreted, and becomes part of the bank's electronic record of the check. While previously many banking institutions were forced to maintain large staffs of people to handle manually the time-consuming and tedious task of processing check copy requests, it is desirable to provide a system whereby a customer of the banking institution can request, retrieve, and display copies of checks and, preferably, generate correspondence with a copy of a check, i.e. a check image, all without bank staff involvement. Thus, the present application is directed to an automated system which retains images of the front and back of each check and data associated with that check. The associated data includes the account number, the check number and the check amount as well as image data. The system allows a user to request, retrieve and display check copies with turnaround time much faster than in the prior art. SUMMARY OF THE INVENTION There are obvious inefficiencies in the current methods of handling customer service inquiries about checks and in the present costly and labor intensive paper and microfilm archives required to support such inquiries. The invention provides a new financial services product and computer system. In particular, it is an object of the present invention to provide a new method and apparatus for providing traditional features of bank services related to check microfilm and commercial paper archives in electronic form. It is another object of the invention to provide a new method and apparatus for capturing, processing and storing check images for on-line access. It is yet another object of the invention to provide a new method and apparatus for communication for the purpose of requesting and receiving check images. It is yet a further object of the invention to provide a new method and apparatus for locally storing, displaying and utilizing check images in industry standard computer office automation environments. It is yet a further object of the invention to provide an electronic check storage and retrieval system which eliminates the need to maintain costly and inefficient microfilm or paper check archives. It is yet a further object of the present invention to provide a document storage and retrieval system which is applicable to documents other than checks and commercial paper instruments. It is yet still another object of the invention to provide a system which facilitates error correction in the MICR line of checks, and furthermore which facilitates such error correction in an efficient manner, requiring a small number of keystrokes or minimal operator interaction to accomplish such error correction. It is furthermore an object of the invention to provide at the financial service customer's request, a system with the ability on a daily basis to scan a customer's paid checks at a resolution level superior to that available from traditional microfilm and photocopy methods and in excess of all readability requirements for the customer service investigation functions described above as well as other applications such as signature verification, check fraud evaluation, return item processing, etc. It is another object of the invention to provide a system having the ability to index and store check images in a relational database supporting appropriate access and inquiry requirements. It is furthermore an object of the invention to provide a system having the ability to create a permanent, reliable, legal and auditable store record of check images, superior to that available in the current system of microfilm, photocopy and paper records. It is also an object of the invention to provide a system having the ability for the financial services institution customer or user to request access to images in an efficient, reliable and orderly way that allows for the maintenance of both electronic and permanent records of the inquiries for both management and audit control. It is furthermore an object of the invention to provide a system allowing a requester user to transmit check copy requests to the financial institution and receive information back (e.g. the electronic check images) by means of a new method consistent with current telecommunications file transfer standards. It is furthermore another object of the invention to provide a system having the ability to return electronic check images at the customer's request in the following ways: a - by direct and immediate on-line transmission, b - by electronic batch request and batch return of files of check image requests and check images, c - by bulk transmission of image files according to standing orders (e.g. all return items, all items above $1,000, etc.) d - by delivery on magnetic or other media such as magnetic tape or disk, e - by delivery on electronic optical or other media such as WORM disk, CD-ROM or magneto-optical disk, etc. f - by all of the above ways of returning the image supported by an implementation of industry standard image formats with new features specifically designed to support the recipient's effective handling of individual electronic check images or arbitrarily large files of electronic check images. It is yet still a further object of the invention to provide a system having the ability to display the received electronic images in a windowed graphical user interface consistent with industry standard office automation and computer workstation environments. It is yet still another object of the invention to provide a system having one or more user workstations where a user has the ability to manipulate the displayed, received image in a manner required to support the objectives of the underlying check investigation applications (e.g. to enlarge, enhance, rotate, etc. the image). It is yet still a further object of the invention to provide a system having a user workstation where the user can review and maintain the local database of check images within the constraints of the possibly limited local disk space available to industry standard office automation and computer workstation environments. It is yet still a further object of the invention to provide a system having the ability to create reports and audit records of all check image related events at the requester workstation level. It is yet still a further object of the invention to provide a system having the ability to accomplish all the above functions when the requester's workstation is part of an industry standard LAN environment and software and/or data and/or telecommunications support are executed at the LAN server level. It is yet another object of the invention to provide a system having the ability to accomplish all the above functions (save the last mentioned) when the recipient wishes to originate and/or receive transmissions from a mainframe computer system. As is evident from the above description of current check processing system, a highly sophisticated problem is presented when copies of hundreds or thousands of checks requested by a customer or customers need to be processed by a banking institution and the need arises to verify the check information. The system described herein provides a solution to this problem. For example, the inventive system can accomodate all the check image requests generated at today's largest check processing institutions on their peak days. The invention provides a solution to this customer service problem which heretofore involved intensive manual processing. The invention provides an electronic document image storage and retrieval system including a customer service workstation that can request, retrieve, display, manipulate and print copies of documents, particularly checks, and furthermore create correspondence for a client incorporating copies of document images. The system of the invention includes an electronic host archive storage and retrieval system for storing and retrieving copies of checks or check images. This host archive system is linked via a communications link, e.g., modems and telephone line, to one or more generally remotely located customer workstations. For the purpose of this application, a customer is the customer of the banking institution and which utilizes a workstation according to the invention to request and retrieve copies of checks from the banking institution. For the purpose of this application, an operator, user or requester is the individual who operates a workstation according to the invention. For the purpose of this application, a workstation or image station may be a standard desktop computer that utilizes a graphical user interface. Also, a workstation preferably has local magnetic disk storage or other storage, contained in the unit or is linked to a magnetic disk drive or other storage unit via a network communications device commonly referred to as a file server. In the invention, use is made of multi-tasking and multi-windowing environments such as Microsoft Windows.TM. or IBM OS/2 .TM. to provide a graphical interface for the system of the invention that the operator uses to interact with the retrieved check image copies. According to the invention, the operator or customer can make requests by account number and check number for a specific check at the local workstation. The requests are stored locally until the operator is ready to forward the requests to the banking institution. Once an operator is ready to forward the requests to the banking institution, the workstation will dial the host computer controlling the archive system at the banking institution. Once connected to the host computer, the host will prompt the operator or customer for a user-ID and password to initiate the file transfer. Once the ID and password are verified, the requests are translated into a file and transferred to the host archival system. After a predetermined processing time to retrieve and sort the check images, the workstation operator can initiate a download or file transfer from the host archival system. The host system will transfer a front image and a separate back image for each check. Each check image has the MICR line information embedded in the check image file for identification. The identification information contains the account number, the check number, amount and date of the check. Once downloaded to local storage of the workstation, the system software resident at the workstation will read the data stored within each check image file to obtain the account number, check number and amount of the check. When check images are received at the local workstation, the system software will correlate the check request entry with the check images. The filename of the check in the local database as well as a status field will be updated so as to indicate that the item has been downloaded, processed and received from the host archive system. Once all of the downloaded check images have been processed, they are available for review by the operator. According to the invention, an operator can select a menu item to present a Select/Display screen at the workstation that lists alpha-numerically the downloaded checks and those requests for check download which are pending. On this Select/Display screen, an operator has the option to sort the check images by account number/check number, amount, a user reference number, status and date. Status indicates whether the item is Pending, Received or Exported. A pending item is a request that has been sent or uploaded to the host archive but not yet downloaded. A Received item is an item that has been downloaded to the workstation, processed and is ready for viewing. An Exported item is a check image that has been downloaded to the workstation but not requested. According to the invention, a customer has an option of indicating if it wants all check images sent to the workstation (exported) without the need to request each image specifically. Preferably, according to the invention, an operator may click with a mouse or other pointer device to select an item indicated on a screen display of the workstation or select an item for viewing by using cursor arrow keys of a computer keyboard and striking the enter or return key. Once selected, the system will read the file names for the front and the back of the check images. The system of the invention preferably will read and display the front and back check images into a separate window for each check image. The separate windows for each front and back check image are referred to herein as a check-centric display interface. This check-centric display optimizes (i.e. minimizes) the amount of time a user would have to search for information on the check images. According to the invention, the front of the check may be displayed in maximum width horizontally in the left window. The back of the check then may be displayed in the right window vertically and enlarged to display the endorsement section. The endorsement section of a check is the section where a payee would indicate its account number and signature or endorsement stamp. This feature saves the operator from rotating the check image vertically in order to read the endorsement. At this point, an operator has the option of manipulating the check image to enhance the readability of the information. The system of the invention provides a toolbar or button zone, preferably as a screen icon, for each check display window. The operator may, for example, enlarge, reduce, rotate relative left, rotate relative right, invert the image absolute 180 degrees, and invert the colors of the image from black on white background to white on black background. The inverting of colors from black to white helps an operator read check endorsement stamps that federal and banking institutions use to indicate processing. Thus, an operator or customer may obtain information regarding where the check was presented for payment. According to the invention, a facility to highlight a specific area of a check image has been provided for fast enlargement. This facility allows an operator to zero in on specific information and enlarge it so it is more readable to the human eye. In addition to the toolbar or button zone, an operator may select the manipulation options from a menu zone that lists all the options in text rather than graphical representation. Furthermore, to expedite the selection process, the system will allow a user to select the manipulation options by clicking a mouse or other pointer device's button on any area of a check display window to display a pop-up list of the manipulation options in text. In addition to the Select/Display screen to select a specific check, the system preferably has two navigation buttons located at the bottom of the screen. One button is a graphical representation of an arrow facing down to move forward through the local database of check images. Another button is a graphical representation of an arrow facing up to move backward in the local database of check images. Once the operator operates these navigation buttons, the system will automatically display next/previous check images in a default order (account number and check number) or any other order specified by the user. These navigation buttons allow an operator the ability to quickly review the downloaded check images. This is a significant improvement over manually handling physical paper checks. A facility to store a customer account number is also provided by the invention. An operator can add or delete any corresponding account numbers that are supplied to and processed by the host archive system. This account number facility allows a customer to manage its accounts without the intervention of the banking institution. Further, the Select/Display screen will read this account number file to facilitate the fast selection of the specific account number from a graphical list box. Further according to the invention, a database maintenance facility is provided to manage downloaded check images. The invention provides a configuration parameter to indicate when a check image should be listed in the database maintenance screen. This configuration parameter is used to indicate the threshold number of calendar days before a check image should be included in a database maintenance screen report. Each downloaded check image is stored locally at the workstation. It is conceivable that at some point in time the check images available for downloading will exceed the amount of physical storage space available at the workstation. An operator can select the database maintenance option to purge or physically delete check images and the corresponding database record. An operator preferably has two options according to the invention: one is to select a check individually for deletion and the other is to delete all the check images and entries that appear in the database maintenance screen. A facility to copy the front or back check image to a temporary storage area, e.g., a Microsoft Windows.TM. clipboard, is provided. The ability to share the image with other desktop applications improves the operator's ability to create correspondence or additional documentation in today's office computing architecture. According to the invention, a facility to incorporate the check images into customer correspondence is preferably provided. An operator may select a document template that is created with an industry available word processing package. The document and check images are merged along with address information of the recipient (payee) to create a document that can be sent to the payee to confirm that the check was received by the payee and paid. An operator may print out the document to send to a payee via conventional mail delivery service such as the Postal Service. However, if the system software is installed on a workstation that supports outgoing fax services via modem communications, an operator may fax the correspondence directly to a payee's fax machine. This automated correspondence processing represents a significant improvement in the time it takes to prepare correspondence and send it to a payee. The objects of the invention described above are achieved by a method for storing and retrieving images of documents comprising placing a plurality of documents in a document imaging machine and forming an electronic image of each document, storing each electronic image in an electronic storage device, providing at least one user interface device in communication on a communication link with the electronic storage device, placing a request for at least one document image on the user interface device, transmitting the request by the communication link to the electronic storage device, searching the electronic storage device for the requested electronic image of the document, retrieving the at least one electronic image or providing an indication that the image was not found, storing the electronic image, if found, in an electronic file, for transmission to the user interface device at user option, providing the electronic image to the user interface device at command of a user at the user interface device for storage at the user interface device and displaying the requested electronic image on a display of the user interface device. The objects of the invention are furthermore achieved by apparatus for storing and retrieving images of documents comprising a document imaging machine for receiving a plurality of documents and forming an electronic image of each document, an electronic storage device for storing each electronic image, a user interface device in communication on a communication link with the electronic storage device, the user interface device having an input device for placing a request for at least one document image and for transmitting the request on the communication link to the electronic storage device, a computer for searching the electronic storage device for the requested electronic image of the document and for retrieving the at least one electronic image or providing an indication that the image was not found, an electronic file for storing the electronic image, if found, for transmission to the user interface device at user option, the computer adapted to provide the electronic image to the user interface device at command of a user at the user interface device for storage at the user interface device, and a display for displaying the requested electronic image at the user interface device. According to the preferred embodiment of the method of the invention, the step of forming an electronic image comprises forming an electronic image of two sides of a two sided document. Also according to the preferred embodiment, the step of storing each electronic image in an electronic storage device comprises storing the electronic image in amass storage device. Further according to the preferred embodiment, the step of storing in amass storage device comprises storing each electronic image in an electronic optical storage device. According to the preferred embodiment, the document comprises a check and the step of placing a request for a document image comprises entering an account number and a check number for the requested check. Also according to the preferred embodiment, the step of placing a request for a document comprising a check further comprises entering an amount of the check. According to the preferred embodiment, the step of placing a request for a document comprising a check further comprises entering a user defined reference field. Furthermore, according to the preferred embodiment, the step of transmitting the request over the communication link comprises transmitting the request over a telephone communication link. Also according to the preferred embodiment, the documents comprise checks each having a magnetic ink code line thereon, and the invention further comprises electronically reading and decoding the magnetic ink code line to form decoded magnetic ink coded data and the step of storing comprises merging the electronic image and the decoded magnetic ink coded data into a tagged image file format (TIFF.RTM. ›a registered mark of Aldus Corp.!) file, with the decoded magnetic ink coded data stored in a tag field in the TIFF file, each check being associated with a TIFF file, and storing the TIFF file in the electronic storage device. According to the preferred embodiment, the invention further comprises storing the TIFF file in a queue prior to transmitting the TIFF file to the electronic storage device. Also according to the preferred embodiment, the invention further comprises forming a plurality of the TIFF files for respective checks and storing the plurality of TIFF files in the queue, grouping a plurality of the TIFF files into a binary large object (BLOB) and transmitting the BLOB to the electronic storage device. According to the preferred embodiment, the invention further comprises forming a plurality of BLOBs and transmitting each BLOB to the electronic storage device. In accordance with the preferred embodiment, the invention further comprises generating an index record for each of the plurality of TIFF files in the BLOB, and storing each index record in an index database. According to the preferred embodiment of the invention, the step of generating an index record comprises generating the decoded magnetic ink coded data for each check and a BLOB pointer to the BLOB containing the image of a particular check. In the preferred embodiment of the invention, the step of storing each electronic image in an electronic storage device comprises bundling a plurality of the images together in a grouping and storing the grouping as a unit in the electronic storage device, to increase the speed at which images can be stored in and retrieved from the electronic storage device. According to the preferred embodiment of the invention, the step of searching the electronic storage device for the requested electronic image comprises searching the index database by using the account number and check number of the requested check, thereby determining the BLOB containing the image of the check, and using the determined BLOB pointer to find the check image in the electronic storage device. According to the preferred embodiment, the invention further comprises the step of checking for errors in the decoded magnetic ink coded data. In the preferred embodiment, the invention further comprises the step of correcting the decoded magnetic ink coded data comprising determining if the decoded data requires correction, assigning a specified character to characters requiring correction in the decoded data, displaying the uncorrected decoded data on a display device with the specified character replacing characters requiring correction, entering data to replace the specified characters, and replacing the specified characters with the entered data. According to the preferred embodiment, the invention further comprises checking if the number of characters in the data entered is equal to the number of specified characters and if so replacing only the specified characters with the entered data; if the number of characters in the data entered is less than the number of specified characters, replacing all the decoded data with the entered data; and if the number of characters in the entered data is greater than the decoded data, generating a warning message to confirm that the entered data is longer than the decoded data prior to replacing the decoded data with the entered data. According to the preferred embodiment of the invention, the step of displaying the requested document image comprises displaying a screen identifying at least one document, and further comprising selecting at least one document for display on the display. In the preferred embodiment of the invention, the document is a check having two sides, and wherein the step of displaying the requested electronic image comprises displaying an image of each side of the check. Still further in accordance with the preferred embodiment of the invention, the check has a front and a back side and the step of displaying comprises displaying the front side of the check in a first screen window in an initial horizontal format for normal reading by a user and displaying the back side of the check having an endorsement thereon in a second screen window so that the endorsement is disposed in an initial format horizontally for normal reading by a user. According to the preferred embodiment of the invention, the first and second screen windows are displayed simultaneously. According to the preferred embodiment, the invention further comprises providing user operated controls to allow selected ones of enlarging and reducing the size of the displayed images of the front and back sides of a check, rotating the images to improve readability and scrolling through the images. According to the preferred embodiment, the invention further comprises the step of providing a word processing function for the creation of a secondary document and loading the requested document image into the secondary document. According to the preferred embodiment, the invention further comprises providing the user defined reference field back to the user at the user interface device to enable sorting of check images according to the user reference field. According to the preferred embodiment, the invention further comprises sorting the check images provided to the user interface device from the electronic storage device by at least one of account number, check number or amount. In accordance with the preferred embodiment, the invention further comprises storing request data for each requested check at a local database at the user interface device, and the step of displaying the requested electronic image comprises selecting an image for display, comparing the request data for the requested check to the electronic file supplied from the electronic storage device and displaying the electronic image whose request record coincides with the data representing the requested check. Thus the invention provides solutions to the problems of customer service regarding processing of requests for copies of checks and delivering copies of checks to customers by providing an all electronic check image requesting, retrieval and delivery system. Other features and advantages of the present invention will become apparent from the following detailed description of the invention. BRIEF DESCRIPTION OF THE DRAWING(S) The invention will now be described in greater detail in the following detailed description with reference to the drawings in which: FIG. 1 is a block diagram which gives an overview of the electronic check image storage and retrieval system including a check image archive (host) system and a plurality of customer service workstations or check image stations; FIG. 2 is a block diagram showing further details of part of the host system and a customer service workstation, and the connection therebetween; FIG. 3 is a more detailed block diagram of part of the host system and the manner in which check images are made and queued in the host archive system; FIG. 4 is a further detailed block diagram of a portion of the host system which facilitates repair of checks in which errors are present; FIG. 5 is a more detailed diagram of one embodiment of part of the host system showing how check images are stored in/retrieved from the mass storage device of the host archive system; FIG. 5A shows the normal and repass processing employed by the check reader/sorter device utilized in the invention to generate check images and data; FIG. 5B shows further process steps used in the invention to store check images; FIG. 5C shows the Requester Process implemented at the host system when it processes a check request from a workstation; FIG. 5D shows the Retrieval Process implemented at the host system when it processes a check request from a workstation; FIG. 5E shows how a check image is recovered by the host system; FIG. 5F shows the Reject/Repair Flow Process; FIG. 5G shows the Data Entry procedure implemented during the repair process; FIG. 5H shows a representation of the data entry screen utilized in the check repair process; FIG. 5I shows another embodiment of part of the host system, particularly, the image storage station. FIG. 6 shows the top level menu options presented at the workstation screen; FIG. 7 shows functions under the "File" option in the top-level menu of FIG. 6; FIG. 8 shows the front and back check image window screen; FIG. 9 shows the tool-bar displays shown in FIG. 8; FIG. 10 shows the Enter Check Request screen displayed by selecting the Enter Check Request option of the menu of FIG. 7; FIG. 11 shows the Select/Display Check Images screen containing a plurality of check items; FIG. 12 shows the format of a screen report that formats and displays checks requested by the user; FIG. 13 shows the screen employed to allow log-on to the host system by a user; FIG. 14 shows a screen which is employed in generating correspondence with a client incorporating the check images; FIG. 15 is another prompt screen to ensure that the user has sufficient download capacity; FIG. 16 is an example of the Enter Check Request screen after entry of four checks; FIG. 17 shows the front and back check image screens showing the front and back image of a representative check; FIG. 18 shows the check image screen with a pop-up window showing the options under the View option of the top level menu; FIG. 19 shows the use of the highlight and enlarge facility of the system showing how check images can be highlighted and thereby enlarged by the user on the screen, as well as showing the rotate facility in the "BACK OF CHECK" window; FIG. 20 shows the options available under the Options Menu of the top level menu; FIG. 21 shows the Setup Options screen; FIG. 22 shows the Account Maintenance screen; FIG. 23 shows the Image File Maintenance screen; FIG. 24 shows the Customer Information screen employed in entering document header data to be inserted into documents incorporating check images that are sent to a client; FIG. 25 shows a document selection dialog screen for allowing the selection of a particular letter template; FIG. 26 shows such a letter from a template; FIG. 27 shows the overall flow process of creating requests for checks at a workstation, retrieving check images, downloading the images to the workstation for display, and creation of correspondence incorporating the check images to be sent to a customer; FIG. 28 depicts the communication protocol used between the host system and a customer workstation for transmitting requests to the host; and FIGS. 29-30 depicts the communication protocol used between the host system and a customer workstation for downloading check images. DETAILED DESCRIPTION OF THE INVENTION 1. Introduction Referring now to the drawings wherein like numerals indicate like elements, FIG. 1 is a block diagram of the overall electronic check image storage and retrieval system according to the present invention. The system comprises a check image archive system 8, also known and referred to herein as the host system 8, and at least one customer workstation 7, also known and referred to herein as an image station 7. Preferably, there are a plurality of workstations 7. The workstations 7 may be remotely located from the host system 8 and also from each other. The host system 8 includes at least one sort station 2, which preferably is a check imaging and sorting machine and a controller, as known in the art. Sort station 2 receives checks 1, generates digital images of the checks, decodes the MICR line of each check and sorts them to one of a plurality of pockets, to be described in more detail below. The sort station 2 is coupled to a host system communication link or network 3 such as a LAN, WAN or bus, as known in the art. Also coupled to the network 3 are at least one repair station 4, an image storage station 5 and an output station 6. The repair station 4 is provided to permit checks which have not been normally processed to be repaired, i.e., to have any errors in the decoded MICR corrected, as explained more fully below. The image storage station 5 includes a digital mass storage device, to be described in greater detail below, which stores digital images of the checks generated by the sort station 2 as well as identifying information to enable the images to be retrieved. The output station 6 controls communication and transmissions between the host system 8 and the customer workstations 7 and provides data comprising the digital images of the checks and check identifying data to the customer work stations 7 on request. Additionally, the output station 6 provides other output, including, for example, tape, CD-ROM and/or WORM output of electronic check images for the bulk export of check images. These components of the host system 8 will be described in more detail below. As will be evident, more than one sort station 2 can be provided to improve throughput. Similarly, a plurality of repair stations 4, image storage stations 5 and output stations 6 can also be provided. FIG. 2 shows the customer workstation 7, its communication link 11 with the output station 6 of the host system 8 and the output station 6 itself in greater detail. Output station 6 includes a communication station 600 and an export station 610. The communication station 600 provides communication control between the host system 8 and each of the customer work stations 7. The communication station 600 includes an output controller 602, an output queue storage device 601, and an output gateway 603 having at least one modem 604, ISDN (Integrated System Digital Network) controller 605, or other communication device for communication with a workstation 7, as explained more fully below. The export station 610 of the output station 6 includes a bulk export controller 611, which is preferably coupled to at least one device capable of exporting, or providing as an output, a large amount of data comprising digital images of checks processed by the host system 8. In accordance with this capability, bulk export controller may be coupled to a digital storage device such as a tape drive 612, CD-ROM recorder 613, WORM drive 614, and/or any other suitable device. Each customer workstation 7 includes a workstation computer 701 and a display device 701A for displaying check images and other screen information. The computer 701 is coupled to a local storage device 702. The workstation computer 701 is also preferably coupled to a printer 703 for printing images of checks as well as other documents incorporating check images, for example. In the preferred embodiment, the customer workstation 7 is coupled to a modem 10 which transmits/receives information over a telephone line 11 connected to a modem 604 of the output station 6. The output controller 602 is coupled to output queue device 601 and the network 3. According to the preferred embodiment, the output controller 602 may be a SUN SparcStation 2. The output queue device 601 may be a LAID disk array. The device 601 is provided for the storage of customer, user and account information and temporary storage of check image requests and check images requested by one or more of the workstations 7 and which are to be downloaded to one or more of the workstations 7. As described, the communication gateway 603 preferably includes a plurality of modems 604, one or more ISDN controllers 605 and/or other communication equipment to form a suitable communication link 11 to provide requested check images to one or more customer workstations 7 located at the customer sites or elsewhere. The bulk export controller 611 of the export station 610 may provide output to devices to deliver check images and other data to customers in mediums other than by on-line communication. For example, the bulk export controller may write check images and data to the tape drive 612, the CD-ROM recorder 613 or the WORM drive 614 or on any other suitable media or for transmission by any other means. The export station 610 is useful for the large scale delivery or transmission of check images to customers who must process requests for large numbers of checks or who require, for example, that all checks paid by them be provided to them. FIG. 3 shows the sort station 2 in greater detail. The sort station 2 comprises a sorter 200, having an input hopper 203, imaging device 204, optical character reader (OCR) 206, MICR reader 205, and a plurality of sort pockets 208, 209 and 210. Checks are conveyed mechanically along a track 220 which connects the various stations, eventually being sorted to and deposited in one of the pockets 208, 209 and 210. In the embodiment illustrated, 6 normal processing sort pockets have been shown, although there can be a larger or smaller number of such pockets. The track 220 is not shown in detail in FIG. 3, because its construction, employing a mechanical track and mechanical elements including motors, belts, rollers, etc., is well known. The sort station 2 also includes a control computer 201 and a storage device 202. The control computer 201 is coupled to the host system network With reference to FIG. 3, checks 1 are fed into input hopper 203 of the sorter 200. The checks 1 are then conveyed along the track 220 sequentially to digital imager 204 and MICR line reader 205. The check images made by the imager are passed to the Optical Character Recognition device (OCR) 206. After the MICR line is decoded by station 205, the checks 1 are passed to one of the eight output pockets, i.e. the repair pocket 208, the repass pocket 209 or one of the six normal sort pockets 210. Checks 1 that are routed to the repass pocket 209 are again placed in the input hopper during the repass run of the sorter 200. During the repass run, checks 1 are manually placed in the input hopper 203 as shown by dashed lines 207, processed to the repair pocket 208 (described in greater detail below), one of the six normal pockets 210 or killed (removed from processing). According to the preferred embodiment, the sorter 200 may be an NCR 7780 check reader/sorter, which processes approximately 370 checks/minute. The control computer 201 controls the operation of the sorter 200. The control computer 201 may be an NCR 486 type computer or any other suitable device. Storage device 202 is operatively coupled to the control computer 201, as is the network 3. In the preferred embodiment, the storage space 202 may be a RAID disk array. In the preferred embodiment, the array 202 may comprise three disks of about one gigabyte each. The amount of storage space is not crucial. Enough must be provided to serve its purpose, which is to provide temporary storage of check images and associated data before the images are provided on the network 3. Additionally, the storage device 202 is useful to queue check images when processing in an off-line mode, storing checks without transmitting the check images across the network 3. This is useful especially if the network 3 goes down, and it is still desired to continue the operator intensive check sorting and processing function implemented by the sorter 200 and store the resultant images. Generally, to process a check 1, it is fed into the input hopper 203 of the sorter 200. The check 1 is transported along the mechanical track 220 and reaches the imager 204 which generates digital images of the front and back of the check 1. The digital image of at least the MICR line of the check 1 is passed to the OCR device 206 which, through optical character recognition, decodes the MICR characters optically from the image. When the check 1 reaches the MICR reader 205, the MICE is then magnetically decoded, as known in the art. In accordance with the preferred embodiment of the invention, the digital images of the front and back of the check 1 are merged, by the control computer 201, into a single TIFF (Tagged Image File Format) file 22. Additionally, the control computer 201 preferably merges the decoded raw MICR, a parsed MICR, the customer ID, the work date, the processing date and time, a machine ID and a repair ID into the TIFF file 22 as tag fields. The control computer then stores the TIFF file 22 in queue 24, repair queue 25 of the storage device 202, or on storage space 505 (FIG. 5) of the image storage device. In a preferred embodiment, queues 24 and 25 are FIFO (first-in-first-out) queues. FIG. 4 shows the repair station 4 in greater detail. The host system network 3 is coupled to a repair controller 401. The repair controller 401 is coupled to a display 402 and a keyboard 403. The repair station 4 is provided for an operator to repair data associated with check images prior to storing the image for customer retrieval in the host system 8. FIG. 5 shows one embodiment of the image storage station 5, containing the check image mass storage device, in greater detail. The host system network 3 is coupled to a storage space 505 via an image storage controller 501. The image storage controller 501 is also coupled to an image storage device 502. The image storage device 502 preferably is a mass storage device, e.g., a Kodak 6800 optical jukebox. The storage space 505 is provided for temporary storage to maintain administrative data (or meta-data) for the image storage device 502. The network 3 is also coupled to an index database controller 510. The index database controller 510 is coupled to an index database device 511. In the preferred embodiment, the image storage controller 501 and the index database controller 510 may be Sparcstation 20 computers manufactured by SUN and the index database device 511 may be a RAID disk array. FIG. 5I shows an alternative embodiment of the image storage station. As in FIG. 5, the host system network 3 is coupled to an image storage controller 501. The image storage controller 501 is coupled to a storage space 505 and an image storage device 502. The storage space 505 and image storage device 502 are provided for the same purpose as before. In this alternative embodiment, however, no index database device 511 or controller 510 is necessary. With reference to FIGS. 3 and 5, when at least a predetermined number of TIFF files 22 on storage space 505 await processing by the image storage controller 501, they are grouped by account number and written to the image storage device 502 as a Binary Large OBject (BLOB) 26. Once the BLOB 26 is successfully written, information for each TIFF file 22 is sent to the index database controller 510 and written to the index database 30 as an index record 28. After the index records 28 are written, the TIFF files 22 are deleted from storage space 505. Each BLOB contains a header 38 and a variable number of TIFF files 22. The header 38 contains data which can be used to locate and extract a TIFF file 22 from the BLOB 26. The indexing of the TIFF files 22 referred to above is carried out by creating an index record 28 (FIG. 5) for each TIFF file 22. The index record is written to the index database 30 which is stored in the index database device 511. As shown, each index record 28 includes the account number 34, check number 35 and amount 37 for a particular check 1, the work date 39, and a BLOB pointer 36 to the particular BLOB containing that particular check comprising a location code 40 and a BLOB file name 41. Heavy reference lines 31 are provided in FIG. 5 to illustrate this relationship. 2. Host System Architecture Details of each of the components of the host system 8 will now be described. With reference again to FIG. 1, in the preferred embodiment of the invention, the host system 8 consists of several pieces of hardware connected to each other via the network 3, which may be, for example, a 10 Base-T Ethernet network, preferably running TCP/IP and NFS. As described previously, the network 3 is connected to the sort station 2, the repair station 4, the image storage station 5 and the output station 6. More specifically, the network 3 is connected to the control computer 201 (FIG. 3), the repair controller 401 (FIG. 4), the index database controller 510 (FIG. 5), the image storage controller 501 (FIGS. 5 and 5I), the output controller 602 (FIG. 2) and the bulk export controller 611 (FIG. 2). a. Sort Station 5 i. Sorter 200 With reference now to FIG. 3, the check sorter 200 may be a medium speed check processing machine, e.g. an NCR type 7780, enabled with both front and back of check imaging capability. In a preferred embodiment, as shown in FIG. 3, the sorter 200 is also provided with a MICR line reader which decodes the check MICR line. Also in the preferred embodiment, the MICR line decoding function is also accomplished by decoding the MICR line from a portion of the image made by the imaging capability of sorter 200. The control computer 201 is coupled to the sorter 200 and interfaces with the network 3. The control computer 201 controls the functionality of the sorter 200 and converts the front and back check image and the MICR line, as decoded by the sorter 200, into a single TIFF file 22. Once complete, the TIFF files 22 are written to storage space 505 (FIGS. 5 and 5I) for later storage by the image storage controller 501. Due to its direct connection to the control computer 201, however, storage space 202 is intended to function as the site for TIFF file 22 storage in the event that the network 3 is temporarily not functioning. With this configuration, the operator intensive work, e.g. processing of checks 1 through the check sorter 200, can proceed without interference in the event of a network 3 problem, and the TIFF files 22 can later be written to storage space 505. The sorter 200 decodes the MICR line of each check. For each check with a successfully decoded MICR line, front and back digital images of the check and other data generated by the sorter 200 are converted into a single TIFF file 22 for each, and stored in the storage space 505. Where the MICR line is not successfully decoded, however, and less than a predetermined number of errors are present, the digital images and data requiring repair are sent to a repair queue 25 of the storage space 202. Repair station 4, which will facilitate repair of questionable or incompletely decoded MICR data from the sorter 200, obtains its input from the repair queue 25. This is accomplished via a suitable network connection, preferably an NFS mount, between the control computer 201 and the repair station 4. Where more than predetermined numbers are present, the images and data are discarded. A file system, e.g., a UNIX based file system, is used to store the TIFF files 22 in the storage space 505 while they await processing by the image storage station 5 (FIG. 5). It was found that overburdening a single directory by storing all of these files in a single location of storage space 505 can cause degradation in file insertion and extraction times. Overburdening a directory depends upon the particular hardware and file system used. Generally, when a directory has many entries and becomes very long, searching the directory may require many disk reads and compares, and, accordingly, the time required to store or retrieve a file rises dramatically. This is referred to as the directory being overburdened. This characteristic, for any particular file system, can be measured by empirical experimentation in a particular configuration. In the preferred embodiment, using the UNIX file system and hardware described, a directory with more than several thousand files is overburdened. According no the invention, to alleviate overburdening, a multiple directory structure and round-robin directory allocation is used no prevent over-population of a single directory. Preferably, ten directories are used to receive the incoming files. This number was determined experimentally, based upon the components employed and the throughput desired. Accordingly, in the preferred embodiment, files are written to a specific directory until the number of files within that directory reaches the currently configured maximum amount allowed for the directory. Files are then sent to the next directory and when that directory is full, to the next one, etc. Accordingly, each TIFF file 22 written to storage space 505 is written to the appropriate directory to await processing by the image storage station 5. The image storage controller 501 reads files from the earliest written directory first. As a directory of storage space 505 empties out, the image storage controller 501 begins reading files from the next directory. In other words, if files were stored in the first directory first, and then in the second directory, the image storage controller 501 will process the files in the first directory first, and subsequently, it will process the files in the second directory, etc. As should be evident to one of skill in the art, the number of directories used, and the maximum number of files per directory, can be configured according to need. As also should be evident to those of skill in the art, the considerations for configuration include: the number, size and rate of files expected; the average and maximum number of files pending in storage space 505; the characteristics of the file system; and the characteristics of the hardware. In the preferred embodiment, the number of directories utilized and the maximum number of files contained in any directory can be reconfigured as appropriate. b. Control Computer 201 Referring now to FIG. 3, where the path of the paper check 1 is shown by the darkened line 220, as described previously, the sorter 200 processes each check 1 by feeding it from the input hopper 203, along the mechanical track 220 past individual stations where the various check processing functions of imaging and MICR line reading are performed. Each check 1 is sent to one of the output pockets 208, 209 and 210. Control of the movement of each check 1 down the track 220 (and the operation of the sorter 200 generally) is directed by a program, e.g., in C language, written to run on the control computer 201. Information on programming the illustrative NCE 7780 check sorter 200 is available in the NCR 7780 Application Support Environment manual NCE Enhanced IPS Application Programming (DI-2430-A) and will not be discussed herein. In the preferred embodiment of the invention, the imager 204 generates digital images of the front and back of each check using a pair of cameras (not shown), as known in the art, which convert the analog image data of the front and back of the checks into digital image data. MICR reader 205 captures the information magnetically encoded in the MICR line of the check for inclusion in the TIFF file 22. The information magnetically encoded in the MICR line includes the account number, the check number and often includes the amount. As in any character recognition operation, especially one employing mechanical movement of documents, errors can be introduced into the process. A common problem in check processing is when two checks 1 pass down the track 220 at the same time, commonly referred to as a piggy-back. In a standard check processing environment, this could result in the second check being missed by the check sorter. In an image capture environment, this situation will result in the front image of the first check being associated with the back image of the second check. In addition, a more significant problem results from the information extracted from the MICR line being incorrect. An example of these problems is where a MICR line read error results from the second check's MICR line information "bleeding" through the first check, resulting in incorrect information being received by the MICR reader 205. Thus, the check image would be stored in a storage device under an incorrect account number, making it, for all practical purposes, unretrievable. In order to identify this situation and take corrective action while the checks 1 are still in the sorter 200, a "best read" comparison is performed on the data retrieved from the MICR line prior to making the decision relating to which of the output pockets 208, 209, 210 to send the check 1. As is well known in the art, in character recognition, whether optical or magnetic, an algorithm determines what character is represented to a given confidence level. Below that confidence level, the algorithm will not determine what the character is. A "best read" is determined by the sorter 200, from the results of the decoded MICR from the OCR 206 and the MICR reader 205, in accordance with a known technique, not described in detail here. In the preferred embodiment, the check sorter 200 is instructed to provide a "best read" on the MICR line, and returns a decoded MICR line with "|" characters replacing any questionable data in the MICR line. If the "best read", i.e., the decoded MICR line contains no "|" characters, the control computer 201 causes the check image to be converted to a TIFF file 22 and directs the check to one of the six normal output pockets 210. The front and back check digital images are converted from the camera digital image format, e.g., NCR image format, into a standard Tagged Image File Format (TIFF, which is a registered trademark of ALDUS Corp.) The front and back digital images are combined into a single TIFF file 22 along with other data, described below, relating to the check and its processing. The TIFF file 22 is in industry standard TIFF format. The non-image data is given TIFF tags and stored within the file as financial information. The following fields are each stored as tag fields:
______________________________________
Raw MICR line
A copy of the MICR line as received as "best
read" from the check sorter 200, in reverse
order.
Parsed MICR line
MICR line data, parsed to remove bank
information, leaving the account number,
check number and amount in proper order.
Account number
Account number of the check.
Check number
The cheek number.
Amount The amount of the check.
Customer The customer ID for this check.
Work Date Date checks were processed.
Machine ID ID of check sorter which processed the check.
Capture Date/Time
Time and date when image was generated.
Repair ID Repair Station ID used to repair this check.
Repair Date/Time
Time and date when check was repaired.
______________________________________
When inconsistencies exist between the optically and magnetically decoded MICR lines or, where one or more characters were not decoded by either the MICR reader 205 or the OCR device 206, the check 1 can either be directed to the repass pocket 209 for re-processing on the sorter 200 or to the repair pocket 208 for MICR line correction at the repair station 4 (FIG. 1). Referring now to FIGS. 5A and 5B for procedure and FIG. 3 for hardware, two distinct processing modes are established for the sorter 200, normal mode (FIG. 5A) and repass mode (FIG. 5B). The objective of the normal mode is to process all checks 1 as quickly as possible. Checks 1 are processed from the input hopper 203. If checks 1 are present in the input hopper 203 (step 214), a check 1 is automatically removed from the input hopper 203 and processed. During processing, the MICR line is decoded by the OCR device 206 (see step 216) and the MICR reader 205 (see step 215) as described above. Some of the time the "best read" contains "|" characters, and therefore, errors. This can result if one or more characters are not recognized by either of the decoders. The reasons for such non-recognition are well known in the art. If the "best read" contains "|" characters, errors are present (250). If no errors are present, the sorter 200 is controlled to send check 1 to one of the normal pockets 210 (see 251), the image and associated data are converted to a TIFF file (252) and the merged TIFF file 22 is written to the storage space 505. (See 253). Where "best read" contains "|" characters, the number of such characters is compared with a threshold number (260). Checks 1 containing some "|" characters, but fewer than the threshold level, are sent to the repair pocket 208 (see 261) and the associated image for that check is sent to a repair queue 25 (see 262). Checks 1 with an equal or a greater number of inconsistencies than a threshold number are sent to a repass pocket 209 (see 263) and the associated image is discarded. In a preferred embodiment, the threshold number of "|" characters, or errors, is four, meaning that if there are four or more errors, or unreadable characters, the check is sent to the repass pocket. Normal processing continues until there are no more checks 1 in the input hopper 203 (see 214), at which time normal processing is complete (265). After all checks 1 have been processed in normal processing, the operator may switch to the repass mode (FIG. 5B). The objective of the repass mode is to have an operator review each check 1 having a number of inconsistencies at or above the threshold level, individually. If the number of errors is still at or above the threshold when the check is reprocessed, the operator determines the disposition of the check 1. In repass mode, checks in the repass pocket 209 are moved to the input hopper 203 and again conveyed along the track 220. A "best read" is again obtained for the check. The repass mode differs from normal processing only in the way checks are handled if a threshold number or more errors are present. If the number of errors is equal to or greater than the threshold for this second processing, the check is stopped in the track 220 and the image is displayed on the console 211 along with the decoded MICR line (see 271). The operator can decide to accept the check 1 (see 272), which causes the check 1 to be guided to the repair pocket 208 (see 261) and the image is sent to the repair queue 25 (see 262), to facilitate later correction at the repair station 4. The operator can also decide to reprocess the check 1 on the sorter 200 (see 275), at which time the operator removes the check 1 from the track 220 and places it in the input hopper 203 (see 276). The image and data associated with that check 1 are then discarded (see 264). If the operator chooses not to accept (272) or reprocess (275) the check 1, the check must be killed by removing the check from processing (step 278). The image and data associated with that check 1 are also discarded (see 264). A check 1 is killed if, for instance, the check 1 is for an account other than the account currently being processed. When the operator chooses to kill a check, the number of expected checks and the dollar total of the expected checks will be reduced appropriately. Repass processing continues until there are no more checks 1 in the repass processing pocket 209 (see 214), at which time repass processing is complete (265). In addition to controlling the sorter 200, several ancillary functions are also resident in the control computer 201. These include maintaining statistics and performing file maintenance. c. Repair Station 4 Turning now to FIG. 4, repair station 4 comprises a repair controller 401 display device 402, a keyboard 403, and temporary storage device 404. In the preferred embodiment, controller 401 may be a PC, e.g., an NCR 486 PC, connected to the network 3 via a TCP/IP protocol. It preferably utilizes the Network File System (NFS) to read its input from the queue 25 of the storage space 202 (FIG. 3). It writes the corrected files in the form of TIFF files 22, via NFS, to the storage space 505. In the event that the network 3 is unavailable, for example, due to network 3 failure, the corrected TIFF files 22 are written to the corrected files database 405 on the temporary storage device 404. When the network 3 becomes available, the TIFF files 22 are then written to the storage space 505. The repair station 4 is designed to expedite the correction of MICR line data which fails to meet acceptance criteria when it is decoded by the check sorter 200. The repair station 4 provides the operator with a convenient and efficient method of correcting MICR line information for a potentially large number of checks. Reject percentages, i.e., the percentage of checks which cannot reliably have the MICR decoded--vary by account from under 1% to over 6%. The processing followed by the repair station 4 facilitates rapid correction of a large volume of MICR lines. With reference now to FIG. 5F, once initiated, the repair station 4 automatically searches the repair queue 25 of storage space 202 for items needing repair 140). Preferably, the system follows FIFO logic, by account, for presenting items requiring repair to the operator. The check image and partially decoded data for each item requiring repair is presented to the operator (142). After displaying the images and the data on the repair station display device 402 (142), the repair station 4 checks each of the three data fields that were encoded in the MICR line, specifically, the account number, the check number and the amount, and highlights the first field requiring correction to the operator (144). In the preferred embodiment, the first field containing errors is highlighted in reverse video. The operator can now enter the corrected data on the keyboard 403 (146). FIG. 5H shows the display screen of the repair station 4 which will be provided on the display 402. A data entry field 192 is provided at the very bottom of the screen FIG. 5H), and is used as a single point of entry for all three fields. Preferably, the field highlighted on the screen is the only field which will be affected by data entry. Once corrected data is entered by the operator, the repair controller 401 checks the next field for errors (147), and if necessary, highlights it for correction (steps 146, 148). After all data fields are corrected (147), the repair controller 401 displays a release message (150). By pressing the return or enter key on the keyboard 403, the repaired item is then released. When a repaired item is released, image and data associated with that item are removed from the repair queue 25 and converted into a TIFF file 22, as above. The TIFF file 22 is written to the storage space 505. After releasing the item, the repair station automatically returns to the step of finding the next item needing repair (140). Thus, the design of the repair station 4 encourages the use of a minimal number of keys by the operator to facilitate rapid processing. In the preferred embodiment, the specific logic employed in data entry also speeds up the repair process implemented by the repair station 4. FIG. 5G shows in detail the process carried out by step 146 of FIG. 5F. Each of the three fields contains the decoded data, as derived from the MICR line. Any character for which the recognition confidence falls below the acceptable level is flagged by the use of a single character, e.g., the "|" character (160). Accordingly, if a single or small number of characters in a large field need correcting, the repair function allows correcting only the single or few characters marked with a "|". According to the preferred embodiment of the invention, therefore, if the number of characters entered by the operator is equal to the number of "|" characters in the field being repaired, then only the "|" characters will be replaced (162, 164). The replacement characters are used to replace the "|" characters one for one in the order entered (166). Thus, once the replacement characters are entered, they will automatically replace the "|" characters in the order entered. This saves unnecessary data entry. Only the characters to be corrected need be entered. According to the preferred embodiment, if the number of characters entered is not equal to the number of "|" characters (164) and less than or equal to (168) the number of characters in the data field requiring repair (including "|" characters), the new data will automatically replace all existing data (170). Further, according to the preferred embodiment, if the number of characters entered is greater than the number of characters in the data field being repaired (including "|" characters), a warning message requiring the operator to confirm that the new entry is longer than the current data (172) will be displayed. If the operator confirms, then the new data replace the current data (174, 170). If the operator does not confirm, the workstation software resumes at step 160 and the operator may reenter the data. The screen layout of the repair station is, accordingly, designed to clearly identify what data fields require correction and also to relieve the operator from having to search the screen to find the incorrect information. The repair screen 179 (FIG. 5H), generated by the repair controller 401 on the display device 402, displays both the front 182 and back 180 image of the check, along with three fields showing the account number 186, check number 188 and amount 190. As mentioned above, a single input field 192 is present on the repair screen 179. Preferably, the back image 180 of the check is displayed on the top of the screen since it is the image least relevant to the repair task. The front image 182 of the check is displayed below the back image 180. Directly below the front image, and aligned with the displayed MICR line 184 are the account number 186, check number 188 and amount 190 fields. The data fields show the values of the three fields as determined by the sort station 2. Alignment with the actual MICR data 184 aids in rapid identification of necessary corrections. The repair function highlights the field being worked on by showing the data in reverse video. At the very bottom of the screen, directly under the three data fields 186, 188, 190, is the single data entry field 192 by which the operator enters the new data for correcting the incorrect data, as described. By utilizing a single data entry field, the operator can focus attention on one location on the screen and avoid wasting time searching the screen for the next area of the screen requiring attention. d. Image Storage Station 5 With reference now to FIG. 5 and 5I, which show two alternative embodiments of the image storage station 5, the TIFF files 22 are stored on an image storage device 502, which preferably comprises a mass storage device. Further, the image storage station runs a pair of asynchronous processes, described below, the Requester Process and the Retrieval Process, to process incoming requests for check images from a customer workstation 7. In a first embodiment, shown in FIG. 5I, the image storage station 5 comprises an image storage controller 501 coupled to the network 3, an image storage device 502 and a storage space 505. In a second embodiment, shown in FIG. 5, the image storage station additionally comprises an index database controller 510 coupled to the network 3 and an index database device 511. In the preferred embodiment of the invention employing either embodiment of the image storage station 5 of FIG. 5 or 5I, the image storage device 502 is a Kodak 6800 optical disc library system configured in its "A" option. This configuration consists of a single drive and 50 slots for 50 fourteen inch 10.4 GB optical platters. The device 502 is controlled by the image storage controller 501, preferably a SUN SparcStation 20 computer running AMASS 4.2.1 software. Further, according to the preferred embodiment, the storage device 502 communicates with controller 501 via a SCSI connection for data transmission and an RS-232 connection for robotics control. These are shown only schematically in FIGS. 5 and 5I by the line 501A. By mass storage device standards, an optical disk jukebox such as the Kodak 6800 is a relatively slow device. This storage device is used in the preferred embodiment of the invention as the preferred image storage device 502, however, because of its half-terabyte capacity, and low cost per unit of storage. Other devices could also be used. In the preferred embodiment, the image storage device 502 contains a single drive, and up to 50 optical platters. Request File Processing A customer desiring a check image can cause a workstation 7 to transmit a request file to the host system 8. The operation of the workstation 7 and creation of requests will be described in greater detail below in connection with the detailed description of the workstation. The request file from the workstation 7 is stored on the output queue device 601 (FIG. 2) until it can be processed. The following is a description of request file processing. Generally, a request file can contain a request for one or more check images. When a requested check image is found, it is queued on the output queue device 601 for later transmission to the customer workstation 7. Request file processing is performed by a pair of asynchronous processes, the Requester Process and the Retrieval Process. In the embodiment of FIG. 5, the Requester Process runs on the index database controller 510. In the embodiment of FIG. 5I, it runs on controller 501. The Requester Process analyzes each request made in each request file stored in output queue device 601 to determine whether the requested image exists in the image database 503, and if so, where the image is located. The Requester Process places each request which can be satisfied into a data structure called the request data structure for subsequent processing by the Retrieval Process. The Retrieval Process reads requests from the request data structure and retrieves the check image files, depositing them in the appropriate user's download directory on the output queue device 601 of the output station 6. With reference both to FIGS. 5 and 5I, TIFF files 22 containing front and back check images and the embedded MICR line and optionally other data are written to the storage space 505, as described above, by the sort station 2 and the repair station 4. The TIFF files 22 awaiting processing by the image storage controller 501 are maintained on the storage space 505 in a round robin directory structure described above. The image storage controller 501 archives the TIFF files 22 to the image storage device 502 where they can be found and retrieved by the Requester Process and the Retrieval Process. The image storage controller 501 preferably uses a UNIX file system as a means of storing and retrieving files on the image storage device 502. Preferably, the image storage device 502, which in the illustrated embodiment is an optical storage device, is a write-once read-mostly (WORM) type device. Once data is written, it cannot be erased. As will be evident to one of skill in the art, to permit the addition of files and directories to the image storage device 502, the administrative information (also known as meta-data), such as the directory structure of image storage device 502, is maintained on storage space 505. A UNIX-type file system is used to maintain the data on the image storage device 502. The number of files (e.g. TIFF files 22 or BLOBs 26) stored on the image storage device 502 is potentially enormous, i.e., several orders of magnitude larger than an optimum size for a UNIX-type file system directory. As is known in the art, in a UNIX-type file system, each directory and file name consume resources. Since UNIX-type file systems implement directories as a linear list of file names, directory search and insertion times are, essentially, a linear function of the number of names in the directory. As a consequence, very large directories are inefficient, also known as overburdened. To prevent overburdening of a directory on the image storage device 502, causing, e.g., a deterioration in insertion, deletion and retrieval response times because too many files are stored in a single directory, the invention uses a method of distributing the files over a number of directories on the image storage device 502. As is known on UNIX-type file systems, every file must have a unique file name including its path, i.e. no two files of the same name can be stored in the same directory. In the present invention, an algorithm is used to break down the information unique to a given file into a path and file name. As input, the algorithm requires a unique string of digits (or characters) corresponding to a file to be stored, and constructs therefrom a unique path and file name insuring sufficient distribution over the file system directories. The algorithm also requires a prespecified maximum directory size. For any given UNIX-type file system, the size can be determined empirically, or as is evident to one skilled in the art, calculated, by using the approximate number of files to be stored, the population characteristics of the unique identifiers, and the characteristics of the file system and the storage device. With the above-described inputs, the algorithm outputs a path and file name under which the file is stored to the image storage device 502. Unlike hashing algorithms, which are known in the art, it is evident that no decoding algorithm (save removing path separation characters) is required to correlate the path and file name with the underlying unique string identifying the file. It can be seen from the following illustrative embodiment that, for a given unique identifier, the algorithm can be used to limit the number of files which will be placed in any directory. For example, where one to nine digit numbers represent the entire population of unique identifiers, it can readily be seen that the one billion unique files can be stored using ten thousand "root" directories, each comprising one thousand sub-directories, and each sub-directory having one hundred unique files. The algorithm to segment purely numeric unique identifiers can be described as follows. First, leading zeroes are removed from the unique identifier. Subsequently, the least significant n digits form the rightmost, or file name segment. If less than n digits are present in the unique identifier, all digits present form the rightmost or file name segment. Next, the remaining digits are segmented into a minimum number of segments, such that no segment is longer than m digits. If the segments are not equally sized, the largest segment or segments are used for the most significant digits in the unique identifier. Thus, as is evident from the above, the total number of possible sub-directory entries in a parent directory will be at least as large as the total number of possible entries in each one of its first level sub-directories (children directories). In the preferred embodiment, n=2 and m=4, this can be seen from the following table:
______________________________________
Unique
Identifier
First Second Third
Length Segment Length
Segment Length
Segment Length
(Digits)
(Digits) (Digits) (Digits)
______________________________________
1 1
2 2
3 1 2
4 2 2
5 3 2
6 4 2
7 3 2 2
8 3 3 2
9 4 3 2
10 4 4 2
______________________________________
Thus, for example, where the unique identifier is seven digits long, or more, the first and second segments are used as the path, i.e., the name of subdirectories, and the third segment is used as the file name. Where the unique identifier is six digits long, the first segment is used as the path and the second segment is used as the file name. For example, the unique identifier "123456789" would have a path (i.e., list of directories) and file name of "1234/567/89", whereas the unique identifier "1234" would have a path (i.e., list of directories) and file name of "12/34" In the preferred embodiments, only digits (0 through 9) (and, as described below, the "." character) are used in the unique identifier. One of ordinary skill can, however, see that the algorithm is equally well adapted to unique identifiers containing any number of characters. Furthermore, in the preferred embodiment, the algorithm is optimized for use with unique identifiers of one to nine digits; however, it can readily be seen that any number of digits or characters could be accommodated. i. First Embodiment In a first embodiment (FIG. 5I), in order to spread out the files over as many directories as necessary to maintain satisfactory response time, preferably each account is given a separate directory. Although the check images, and therefore the TIFF files 22, in the host system 8 can be uniquely identified by account number, check number and optionally check amount, only part of this information is used in the above algorithm. Preferably, a subdirectory exists for each account for which check images are to be archived. The check number is used, according to the above algorithm, to return segments used for the path within the account directory, and as part of the file name. The amount is appended to the last segment returned by the algorithm to create a file name. Thus, check number 123456 in the amount of $222.22 drawn on account 33333 would have a path and file name, picnorially shown, of: 33333 (directory) 1234 (sub-directory) 56.22222 (file name) Accordingly, check number 1234567 for the same amount, drawn on the same account would have a path and file name, pictorially shown, of: 33333 (directory) 123 (sub-directory) 45 (sub-directory) 67.22222 (file name) As can be seen from the examples, the amount is appended to the last segment returned by the algorithm to create a unique file name. The image storage controller 501 stores each TIFF file 22 which was placed in the round-robin directory structure on the storage space 505. The TIFF file is stored on the image storage device 502 in its appropriate directory, under the name constituted as described above. (1) Requester Process With reference to FIG. 5C, a Requester Process is generated (spawned) on the image storage controller 501 by the output controller 602 for each request file on the output queue device 601. The Requester Process writes each check image request therein to a request queue on the image storage controller 501 in order to serialize the individual check requests. See step 90. In the illustrative embodiments, the request queue is a UNIX FIFO queue. The Requester Process reads (92) the request queue mn a FIFO fashion, and processes each request independently. The Requester Process analyzes each check image request in the request queue to determine whether or not one or more TIFF files 22 corresponding to that request, is present on the image storage device 502. The Requester Process uses the algorithm, as described above, to turn the account number, check number and amount into a path and file name of one or more TIFF files 22 which satisfy this request (93). If the amount of the check is not present, a wildcard search, as known in the art, can be performed. If the TIFF file 22 exists, the meta-data on storage space 505 can be interrogated to determine the platter upon which the TIFF file 22 is present. For each request for which a TIFF file 22 is located (94) an entry is inserted in a request data structure specifying the location of the TIFF file 22 which will satisfy the request (98). For example, the path and file name, along with the platter location (volume and side) are passed to the Retrieval Process via a request data structure. Preferably the request data structure comprises the following fields: volume; side; priority; username; customer name; request date; request time; account; check number; check amount; and request number (in batch). In the case where more than one TIFF file 22 is located to satisfy a particular request, for example, where two checks have the same account and check numbers and no amount was specified in the request, an entry in the request data structure is made for each TIFF file 22, that satisfies the request (98). If no TIFF file 22 can be located for a particular check request (94), the Requester Process places the request into the request data structure corresponding to the "not found" directory (96), in other words, specifying the location of a "Check Not Found" image. (2) Retrieval Process Turning now to FIG. 5D, the Retrieval Process processes each request which has been placed in the retrieval data structure. In order to minimize platter thrashing, all requests are sorted for retrieval. Preferably, the request data structure is set up to have sortable fields corresponding to the physical characteristics, e.g., platters and sides, of the image storage device 502. Since the Requester Process has determined the location for each request, the Retrieval Process simply sorts all of the requests by platter and then by platter side. The Retrieval Process first checks if there are check image requests pending for the platter currently in the drive (1118). If there are, the Retrieval Process then checks to see if there are any requests for the side of the platter currently under the read heads of the optical storage device (1120). If there are no requests for the current side, the platter is then flipped (1124). The Retrieval Process then first verifies that the request is made by an authorized user (1110) or an authorized account. This check to confirm that the user is authorized is done by verifying that the account with which the request check is associated is on the user's valid accounts file, which file is maintained on the output queue device 601. Once the user has been verified, the Retrieval Process confirms that the account number of the check requested is in the user's valid accounts file. This is done by reference to the list of the accounts a user is permitted to access, which is maintained in an accounts file on the output queue device 601. If the user is not authorized, or if the account number selected is not in the valid accounts file, the Retrieval Process will generate a "Check Not Found" check image to return to the user (1116), thus not giving any further information to anyone trying to access an account for which they have not been authorized. If the user and account are authorized, the image storage device is accessed, and the TIFF file 22 corresponding to the request is read (1122) from the image storage device 502. The Retrieval Process then re-inspects the request data structure to see if any other requests for this platter are pending (1118). If there are, they are fulfilled as above (1118, 1120, 1110, 1122). If there are no other requests for the current platter, the Retrieval Process requests the platter (1128) with the most outstanding requests in the request data structure, and mounts that platter (1130). The Retrieval Process satisfies each request as described above. The TIFF file 22 contains images of both the front and back of the check, as well as tagged data fields containing the raw MICR line, the parsed MICR line, the account number, the check number, the amount, and the customer ID. The Retrieval Process generates two TIFF format files from this TIFF file 22: one comprising the front image (the ".f file") and one comprising the back image (the ".b file") of the check. As discussed above, TIFF tags are utilized to store descriptive data about the check directly in TIFF files 22 and the TIFF format .f and .b files. The MICR line and all of the other non-image tagged data fields are placed in both files. This information may be used by the customer workstation 7 to identify each file and match the .f and .b files to the specific request. The front image file and the back image file preferably are named utilizing a sequential number scheme to insure uniqueness. The file name extensions may be used to identify front (.f) and back (.b). All generated "Check Not Found" files are in the TIFF format as well, and contain the requested account number and check number of the check requested. If amount was specified in the request, preferably it too is placed in the "Check Not Found" file if the image was not found. This ensures consistent processing in identifying this image file with the request on file at the customer workstation 7. ii. Second Embodiment With reference to FIG. 5, the required throughput of the huge number of TIFF files 22 which must be written to and read from the image storage database 503 residing on the relatively slow optical media creates a bottleneck, thus presenting a performance problem. The TIFF files 22 can not, without the means described below or equivalents to the means described below, be written to the image storage device 502 at a pace comparable to the throughput of the sort station 2. Accordingly, in the first embodiment, there exists a need to cache a greater number of TIFF files 22 in storage space 505 during peak processing times. Thus, the storage space 505 in the embodiment of FIG. 5I allows for temporary storage during peak processing times when the image storage device 502 cannot receive images at the rate at which they are generated. According to the embodiment of FIG. 5, another solution to the problem is to write a smaller number of larger files to the image storage device 502 to improve throughput. This can be achieved by bundling a number of TIFF files 22 into a BLOB 26. The total number of files stored in the image storage device 502 is thereby reduced by a factor of one/the number of TIFF files 22 bundled into each BLOB 26. In the preferred embodiment, fifty TIFF files 22 are bundled into each BLOB 26. With reference to FIG. 5, the index database 30 resides on the index database device 511 controlled by the index database controller 510. In the preferred embodiment, the index database 30 is accessed using a database engine, e.g., Sybase or Informix program as known to those in the art, and the index database device 511 is a RAID disk array. TIFF files 22 containing both front and back check images and the non-image tag data are written to the round robin directory structure on the storage space 505 coupled to the image storage controller 510, as described above, by the sort station 2 and the repair station 4. The rate at which these files are created, and therefore become ready for storage, may be greater than the rate at which the individual TIFF files 22 can be indexed and stored by the image storage station 5. As will be discussed in more detail below, the image storage controller groups the TIFF files 22 in the round-robin directories of the storage space 505 by account number. When a predetermined number of TIFF files 22, preferably for one account, are present, the image storage controller 501 groups these files into a Binary Large Object (BLOB) 26, and writes the BLOB 26 to the image storage device 502. As will be evident to one of skill in the art, the BLOB 26 need not comprise only TIFF files 22 from one account. Preferably, provision is also made to flush a particular account from the round-robin directories, or all pending TIFF files 22, even when less than the predetermined number of TIFF files 22 are present. This is done, for example, when daily processing for a particular day or account is complete. In that case, a BLOB may be written to the image storage device 502 consisting of less than the predetermined number of TIFF files 22. The BLOB 26 contains a header 38 and a plurality, illustratively, fifty TIFF files 22 each representative of one check. The BLOB header 38 comprises the fields listed below. The following fields occur once at the beginning of each BLOB 26:
______________________________________
Field Description
______________________________________
Byte Order Intel or Motorola
Version Number Software version
Account Number Self-explanatory
Customer ID Self-explanatory
Date committed Date placed in archive
Number of checks
Number of TIFF files 22 in BLOB 26
File length Total file length
CRC value For error correction
______________________________________
The following fields occur in the header 38 once for each TIFF file 22 contained in the BLOB 26:
______________________________________
Check Number Self-explanatory
Amount Self-explanatory
Start Offset Offset of TIFF file 22 in BLOB 26
Length Length of TIFF file 22
______________________________________
The BLOB 26 also contains each of the plurality of TIFF files 22 stored at the offset and having the length indicated. Once assembled, the BLOB 26 is given a unique sequence number. According to the algorithm described above, the sequence number is used to determine a path and file name on the image storage device 502 at which to store the BLOB 26. The image storage controller 501 then writes the BLOB 26 to the image storage device 502 under the path and file name determined. After the write function has been successfully completed, the image storage controller 501 sends the account number for the the check images stored in the BLOB 26, along with the check number and amount associated with each of the TIFF files 22 and the sequence number of the BLOB 26 in which they were stored, to the index database controller 510. The index database controller 510 then creates an index record 28 in the index database 30 for each of the TIFF files 22 stored on the image storage device 502, i.e, in a BLOB 26. The TIFF files 22 that have been written on the BLOB 26 are then deleted from storage space 505. Each index record 28 contains information pertinent to one check 1, for example, an index record may include:
______________________________________
Field Description
______________________________________
Account Number 34
Self-explanatory
Check Number 35
Self-explanatory
Amount 37 Self-explanatory
Work Date 39 Date check was processed
Location Code 40
Image storage device 502 containing the
BLOB 26 (i.e., support for multiple
image storage devices)
BLOB File Name 41
Sequence number for BLOB 26
______________________________________
Preferably, the location code 40 (that indicates which image storage device 502 has been used to store the image where multiple devices 502 are used), and the BLOB file name 41, which is a sequential number assigned to the BLOB 26, together, form a BLOB pointer 36. Since TIFF files 22 in the host system 8 can be uniquely identified by account number, check number and optionally check amount, this information, as stored in the index record 28, is preferably used as primary keys to the index database 30. The work date may be used as an alternate key. (a) Requester Process With reference to FIG. 5C, a Requester Process is generated (spawned) on the image storage controller 501 by the output controller 602 for each request file on the output queue device 601. The Requester Process writes each check image request therein to a request queue on the index database controller 501 in order to serialize the individual check requests. See step 90. In the illustrated embodiment, the request queue is a UNIX FIFO queue. The Requester Process reads (92) the request queue in a FIFO fashion, and processes each request independently. The Requester Process performs a search of the index database 30 for each check image request in the request queue to determine whether or not an index record exists corresponding to that request, and thus, the check image is present on the image storage device 502. Where the check image is present, the Requester Process obtains its location e.g., a BLOB pointer 36 and passes this information to the Retrieval Process via the request data structure. Preferably the request data structure comprises the following fields: volume; side; priority; username; customer name; request date; request time; account; check number; check amount; request number (in batch); and the sequence number of the BLOB 26 in which the TIFF file 22 exists. For each check image request, to determine whether a corresponding TIFF file 22, and therefore a check image is present on the image storage device 502, the Requester Process queries the index database 30 (93). Preferably, for each request for which an index record 28 is located, the meta-data on storage space 505 is interrogated to determine the platter and side upon which the BLOB 26 containing the corresponding TIFF file 22 is located (93). If an index record is found (94) an entry is then inserted in the request data structure specifying the location of the BLOB 26 containing the TIFF file 22 which will satisfy the request (98). In the case where more than one index record 28 is located to satisfy a particular request, for example, where two checks have the same account and check numbers and no amount was specified in the request, an entry in the request data structure is made for each index record 28, and thus TIFF file 22, that satisfies the request (98). If no index record 28 is found for a particular check request (94), the Requester Process places the request into the request data structure corresponding to the "not found" directory (96), in other words, specifying the location of a "Check Not Found" image. (b) Retrieval Process Turning now to FIG. 5D, the Retrieval Process processes each request which has been placed in the retrieval data structure. The Retrieval Process in the second embodiment functions essentially the same as the Retrieval Process of the first embodiment of the image storage station 5. However, in this second embodiment Retrieval Process, once the user and account are authorized, and the image storage device 502 is accessed, instead of reading a TIFF file 22, the BLOB 26 containing the desired TIFF file 22 is read. Thus, turning to FIG. 5E, for every read request (e.g. step 1122 of FIG. 5D), the Retrieval Process reads the BLOB 26 containing the TIFF file 22 from the image storage device 502 (1131). The TIFF file 22 is then extracted from the BLOB 26 (1132) using the header 38 information. Subsequently, as performed in the first embodiment Retrieval Process, .f (front) and .b (back) files are created from the TIFF file 22. e. Output Station 6 i. Communication Station 600 Turning to FIG. 2, the communication station 600 includes an output controller 602 that controls the electronic interface between the customer workstation 7 and the host system 8. A communication gateway 603 is provided for communication between the host system 8 and the individual workstations 7. The communication gateway 603 is coupled to the output controller 602. For example, the communication gateway may comprise six modems 604 and/OR an ISDN controller 605. In the preferred embodiment, the modems 604 may be Telebit 3000 14,400 bps modems providing dial-up capability, and the ISDN controller 605 may, for example, be a Combinet 400. Six modems 604 are preferred to support, for example, six concurrent dial-up sessions with six customer workstations 7. The output controller 602 is also coupled to the output queue device 601. The output queue device 601 is used to store customer, user and account information, check requests transmitted by customers, and check image files that are to be automatically downloaded to customers' workstations 7 via the communication gateway 603 mentioned above. In the preferred embodiment, the output queue device 601 may be a RAID disk array. In the preferred embodiment, the output controller 602 may be used to create customers, users and accounts. These functions are described in more detail below. ii. Export Station 610 The Export Station 610 controls bulk export of check images. For example, check images can be sent to clients on a periodic cycle, e.g., daily, weekly, monthly, etc. A variety of export media are available, for example, CD-ROM and digital tape. The bulk export controller 611 is linked to the Network 3 and one or more recording devices, such as a CD-ROM recorder 613, a tape drive 612 or a worm drive 614. Check images can be recorded, using the recording devices (612, 613, 614), for forwarding or archival purposes. The check images recorded for forwarding to a customer are in the form of .b (back) and .f (front) files, discussed below. The Export Station 610 controls all physical devices for media output, i.e., output to CD-ROM, tape or other media. Export of check images via electronic transmission are controlled by the output controller 602. Each output media necessitates different data preparations, as are known in the art. The Export Station 610 controls these preparations. f. Customer/User Subsystem A Customer/User Subsystem is provided both to control and maintain customer and user access, and to maintain each customer's data integrity. The Customer/User Subsystem data resides on the output queue device 603 and the Customer/User subsystem is preferably operated on the output controller 602. A Customer maintenance function is provided which allows a host system 8 operator to establish and maintain customers and accounts. When a customer is established in the host system 8, a customer directory is created, this directory may reside on the index database device 511. Likewise, when an account is added, the Customer maintenance function automatically establishes a sub-directory for that account within the customer's directory. The Customer maintenance function also allows the entry and maintenance of users. Each new user added to the system is associated with an already existing customer and is assigned a directory on the output queue device 601. A password is established for each user. A list of the accounts the user is permitted to make requests against are maintained in a valid accounts file in the user's directory. g. Mass Storage Considerations Check images are uniquely identified by account number, check number and optionally amount. These three fields comprise the key to a single check/single file implementation. Performance limitations of the mass storage device, and in particular, the optical jukebox used in the preferred embodiment, make a single check/single file implementation infeasible for the present system. An optical jukebox is preferably used in the invention in order to provide large amounts of cost effective storage. Thus, a new implementation, i.e., multiple check/single file system, is provided by the invention. In view of the limit on the number of files imposed by the AMASS 4.2.1 implementation of the UNIX File System used in the preferred embodiment (other file systems could be used), and in order to improve throughput in writing to the mass storage device 502, the invention implements a multiple check/single file database as follows: Individual check image files (TIFF files 22) are grouped in batches (BLOBS 26) prior to being written to the image database 503 on the image storage device 502, thus effecting a multiple check/single file database. In accordance with the invention, by grouping, for example, fifty check image files (TIFF files 22) into a single larger file (BLOB 26) of approximately 1 MB, write time to the device 502 is reduced from approximately 20 seconds down to approximately 2 seconds. In order to maintain access to each check in the fifty checks/single file model, a front-end database (index database 30) is utilized. The index database 30 is keyed by account number, check number and optionally amount. For each TIFF file 22, the index record 28 of the index database 30 points to the fifty check file (BLOB 26). This pointer is used to extract the 50 check file from the storage device 502. The particular TIFF file 22 is extracted from the BLOB 26 by pointers contained in a header in the BLOB 26 itself. In the preferred embodiment, to facilitate accessing a single TIFF file 22 from the BLOB 26, offset pointers are used to identify the starting offset of each of the TIFF files 22 in the BLOB 26. These offsets are maintained as a table at the start of the BLOB 26. 3. Customer Workstation 7 The host system 8 has now been described. The following description relates to the structure and function of a customer workstation 7, used by a customer to request and retrieve check images from the host system 8. Referring again to FIG. 2, the customer workstation 7 comprises a workstation computer 701 coupled to a local storage device 702 and optionally to a printer 703. The workstation computer 701 is also coupled to a display 701A, a keyboard input device 701C, and preferably to a mouse or other pointing device 701B. The workstation computer 701 may be a 486 based personal computer running the Microsoft Windows.TM. operating environment. Another operating system could also be used, e.g. IBM OS/2 or Sunsoft Solaris. The local storage device 702 can be a local hard disk drive or a connection such as a network connection to other storage space which is accessible to the workstation computer 701. The storage device includes a plurality of directories 702A, 702B. Directory 702A stores files including the workstation software (not shown) and other data 710, 715, 720, 725, the details these files will be discussed in more detail, below. The workstation computer is preferably coupled to a modem 10 which can be used to communicate with the host system 8 over a dial-up telephone line 11. The customer workstation 7 can, however, be coupled to any suitable communication device instead of the modem 10, and thereby communicate with the host system 8. In the preferred embodiment, each workstation computer 7 is a Microsoft Windows.TM. based system that allows users to request, receive, and display images of checks that have previously been captured and stored in the above described host system 8. It will be apparent to one of skill in the art that the described workstation software can be written for any window based or non-window based operating environment, and reference herein to the functionality of the workstation software as it pertains to Windows.TM. is merely for convenience. Furthermore, it is understood that the organization of the functions, menus and sub-menus of the workstation software was designed with the Windows.TM. operating environment in mind, and can be easily modified to accommodate and/or take advantage of any operating environment upon which one of skill in the art would implement it. As already described, the host system 8 captures and stores images of checks for the customer's designated accounts and maintains them in an archive for up to seven years or more. Workstation software resides on the local storage device 702 and is accessible to the workstation computer 701. The workstation software allows the user to initiate requests for check images, download those images to the customer workstation 7, and view or print the downloaded images as desired. The workstation software also provides utilities to assist the user in managing the number of images retained on the local storage device 702. In addition, if the user has a word processor, for example, Microsoft Word.TM. or any other suitable word processing software, available to the workstation, the workstation software can be configured to allow automatic insertion of check images into pre-defined wordprocessing documents. In a preferred embodiment, the workstation software provides all communication, logon, file transfer, display, and print capabilities the user will need to request, receive, display, and print the check images. Microsoft Windows.TM. is a graphical environment that allows applications to run with a common set of procedures for organizing, controlling, and accessing the information on the screen. As well known, it utilizes a pointer, sizable windows, scroll bars, buttons, drop down menus, drop down boxes, icons, and a variety of other graphical user interface devices that give the user great flexibility in interacting with the workstation 7. Windows.TM. is well-known and need not be addressed in detail here. For more information, the reader is referred to one of the many texts and manuals that have been written on the subject. However, a few general items should be noted. As will be evident from the following, Windows.TM. generally provides several different ways of performing most functions. To perform a given operation, the user may have the option of using one or more of the following: a mouse or other pointing device, the keyboard, function keys, toolbar buttons, etc., as well known. Often there are multiple ways of initiating or carrying out a given operation. The system of the invention follows this philosophy, and the descriptions in this patent application will not repeatedly describe all the methods for initiating or carrying out a given operation in the Windows.TM. environment. However, these methods generally include the use of a mouse or other pointing device or a keyboard to access a menu or toolbar, the latter discussed in more detail below. In the preferred embodiment, at the workstation 7, menus appear on a display device as a series of words across the top of a window, as shown, for example, in FIG. 6, displaying the top level menu, also known as the primary or main menu (as is customary in Windows.TM.). Each selection on the menu has one of its letters underlined, and can be accessed with either the keyboard or the pointing device. As is customary in Windows.TM., only the functions currently available are displayed in dark type. Functions that are unavailable are "greyed" out (displayed in lighter type). A greyed function becomes darkened when it becomes available. It is a general convention to reference a particular operation by listing each menu and option which must be selected to initiate that operation. For example, File/Exit means select the Exit option from the File menu. This nomenclature is well known in the art, and will be used, as appropriate, herein. Additionally, graphical user interfaces such as Windows.TM. have "buttons." A button is a region of the screen which may look like a real button or key on a keyboard, and when pointed to and clicked upon using either the pointing device or keys on the keyboard, selects the option described by the screen button. Alternatively, a touch sensitive screen, as known in the art, could be used. Often an OK button is used to indicate that the input on a screen is accepted, or that one may continue. One button is normally programmed to be the default button; the default button is activated, as if it was clicked, when the <Enter> or <Return> key is depressed. As in Windows.TM. generally, control buttons may be activated by appropriate devices, e.g., by clicking the left mouse button on the desired button or by pressing Alt and the underlined letter of the desired button, e.g., Alt-Y for Yes. a. Startup The workstation software is installed on the customer workstation, as is customary in Windows.TM.. By default, the workstation software is stored in the default drive of the local storage device device 702 and resides in the default directory 702A. In the preferred embodiment, the installation process causes the operating environment to display an icon representative of the workstation software. This icon is displayed so that a user may easily access the workstation software. The workstation software is started as is appropriate from the operating environment. In Windows.TM. this may usually be performed by "double clicking" on an icon representing the workstation software. In the preferred embodiment, when the workstation software is started, an initial screen is provided which displays the copyright and other information. Clicking on the OK button (the default button) or pressing <Enter> allows the user to proceed. In the preferred embodiment, the initial screen is replaced with a prompt requesting the user to decide whether to perform image file maintenance at that time. A Yes and a No button are presented to the user. Image file maintenance provides an opportunity to purge old items and free up space on the local storage device 702. The user must select the Yes or the No button. Clicking the No button (the default button) or pressing <Enter> causes the workstation software to proceed to its main window as depicted generally in FIG. 8. Clicking the Yes button proceeds to image file maintenance prior to g | ||||||