Patent Publication Number: US-2005144189-A1

Title: Electronic item management and archival system and method of operating the same

Description:
RELATED APPLICATIONS  
      The present patent application is a continuation-in-part application of prior filed co-pending U.S. patent application Ser. No. 10/199,950, filed on Jul. 19, 2002, the entire contents of which are hereby incorporated by reference. 
    
    
     BACKGROUND OF THE INVENTION  
      The invention relates to an electronic item management and archival system.  
      Individuals, businesses, government agencies, and other institutions of all types issue checks and similar financial documents to make payments in the United States and internationally. There is a well-defined and well-known process within the banking system that supports checks as a payment mechanism. Included within this process is the practice of imaging checks and performing document management on the imaged checks. Example document management processes include archiving and storing the imaged checks. After the checks are archived and stored, later document management processes can include querying the archive and retrieving stored documents from the archive.  
      Similarly, there are countless numbers of other industries that require archiving, storing, querying, and retrieving of images, audio recordings, or video recordings.  
     SUMMARY OF THE INVENTION  
      The invention provides an electronic item management and archival system for managing and archiving items. Each item includes at least one of image data, audio data, and video data. The system includes an item-generation device configured to provide items and a server in communication with the item-generation device. The server is configured to receive the items from the item-generation device, archive at least one of the received items to an archive, and retrieve at least one of the archived items from the archive. In some embodiments, the server includes architecture that supports a pool of threads promoting multiple, independent archive and retrieve operations concurrently. Some embodiments of the invention can further include a storage device in communication with the server. The storage device is configured to receive the archived items from the server and store the received items.  
      The invention also provides a host machine for an electronic item management and archival system. The host machine includes a communications endpoint that receives items, a processor connected to the communications endpoint, and software executable by the processor. In some embodiments, the software includes instructions that create one or more virtual servers. The one or more virtual servers include at least one server that facilitates independent and concurrent communication between multiple Common Object Request Broker Architecture (CORBA) applications and at least one server that creates and manages an archive.  
      The invention further provides a method of managing an archive having items. Each item including a virtual object and query data associated with the virtual object. Each virtual object is selected from the group consisting of image data, audio data, and video data. The method includes providing a plurality of items, archiving at least one of the provided items to an archive, querying the archive, retrieving at least one of the archived items from the archive, and repeating one or more of the providing, archiving, querying, and retrieving acts. In some embodiments, the method also includes structuring a bus that allows two or more of the providing, archiving, querying, retrieving, and repeating acts to occur concurrently. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       FIG. 1  is a schematic diagram of an Electronic Item Management and Archival (EIMA) system incorporating one embodiment of the invention.  
       FIG. 2  is a diagram of a workstation.  
       FIG. 3  is a schematic diagram showing a distributive archive.  
       FIG. 4  is a schematic diagram showing the interaction of repositories in a distributed network.  
       FIG. 5  is a screen print of the Main Menu of the Host Server.  
       FIG. 6  is a screen print of the Application Server Termination Program Menu.  
       FIG. 7  is a screen print of the File Management &amp; Utilities Menu.  
       FIG. 8  is a screen print of the Match Menu.  
       FIG. 9  is a screen print of an example MCF File List.  
       FIG. 10  is a screen print of the Delete Cycle Menu.  
       FIG. 11  is a screen print of a sample Audit Report.  
       FIG. 12  is a screen print of the Select Services Menu.  
       FIG. 13  is a partial screen print of the System Administration Main Screen.  
       FIG. 14  is a partial screen print of the User Information card.  
       FIG. 15  is a partial screen print of the Print User List dialog box.  
       FIG. 16  is a partial screen print of the Groups card.  
       FIG. 17  is a partial screen print of the Group Control card.  
       FIG. 18  is a partial screen print of the Group List card.  
       FIG. 19  is a partial screen print of the Query Filter List card.  
       FIG. 20  is a partial screen print of the Filter Information card.  
       FIG. 21  is a partial screen print of the Filter Conditions card.  
       FIG. 22  is a partial screen print of the Decision Control Calendar.  
       FIG. 23  is a partial screen print of the Decision Window List.  
       FIG. 24  is a partial screen print of the Decision Window Information card.  
       FIG. 25  is a partial screen print of the Widow Conditions card.  
       FIG. 26  is a screen print of the Batch Selection window.  
       FIG. 27  is a screen print of the View Image window.  
       FIG. 28  is a screen print of the Options Dialog window.  
       FIG. 29  is a screen print of the Magnifying Glass tab of the Options Dialog window.  
       FIG. 30  is a screen print of the Image tab of the Option Dialog window.  
       FIG. 31  is a partial screen print of a Right Click menu for the View Image window.  
       FIG. 32  is a screen print of the EIMA system home page.  
       FIG. 33  is a screen print of the Query screen.  
       FIG. 34  is a screen print of the Open Query Dialog box.  
       FIGS. 35-37  are partial screen prints of example advance queries.  
       FIG. 38  is a screen print having the Query Set text box.  
       FIG. 39  is a screen print of the Result screen.  
       FIG. 40  is a screen print of the Result screen menu.  
       FIG. 41  is a screen print of the Print Setup window.  
       FIG. 42  is a screen print of the Image screen.  
       FIG. 43  is a screen print of the Import Process screen.  
       FIG. 44  is a screen print of the Query Parameters screen.  
       FIG. 45  is a screen print of the Query Viewer screen.  
       FIG. 46  is a screen print of the Maintenance screen.  
       FIG. 47  is a screen print of the Reports window of the Maintenance screen.  
       FIG. 48  is a screen print of an example Report.  
       FIG. 49  is a block diagram representing a method of operation for seal verification.  
       FIG. 50  is a schematic diagram representing the interaction between the CORBA BUS and the archive.  
       FIG. 51  is a schematic diagram of a system, such as, for example, the EIMA system shown in  FIG. 1 , implementing a communication protocol.  
       FIG. 52  is a schematic diagram of another system, such as, for example, the EIMA system shown in  FIG. 1 , implementing a communication protocol and communicating across multiple networks.  
       FIG. 53  is a schematic diagram of a further system, such as, for example, the EIMA system shown in  FIG. 1 , implementing a communication protocol and communication across multiple networks.  
       FIG. 54  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 55  is another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 56  is yet another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 57  is still another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 58  is still another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 59  is still another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 60  is still another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol and illustrating various communication transmissions between a sending device and a receiving device.  
       FIG. 61  is still another schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , implementing a communication protocol.  
       FIG. 62  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating one embodiment of a sorting application.  
       FIG. 63  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating another embodiment of a sorting application.  
       FIG. 64  is a schematic diagram of a system, such as the EIMA system shown in shown in  FIG. 1 , illustrating a further embodiment of a sorting application.  
       FIG. 65  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 66  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 67  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 68  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 69  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 70  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 71  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 72  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 73  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 74  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still a further embodiment of a sorting application.  
       FIG. 75  is a schematic diagram of one embodiment of an archive for use in a system, such as the EIMA system shown in  FIG. 1 .  
       FIG. 76  is a schematic diagram of another embodiment of an archive for use in a system, such as the EIMA system shown in  FIG. 1 .  
       FIG. 77  is a schematic diagram of a further embodiment of an archive for use in a system, such as the EIMA system shown in  FIG. 1 .  
       FIG. 78  is a schematic diagram of still a further embodiment of an archive for use in a system, such as the EIMA system shown in  FIG. 1 .  
       FIG. 79  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating one embodiment of an archive.  
       FIG. 80  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating another embodiment of an archive.  
       FIG. 81  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating a further embodiment of an archive.  
       FIG. 82  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating an data retrieval method and application.  
       FIG. 83  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still another embodiment of an archive.  
       FIG. 84  is a schematic diagram of a system, such as the EIMA system shown in  FIG. 1 , illustrating still another embodiment of an archive. 
    
    
     DETAILED DESCRIPTION  
      The invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “connected,” “coupled,” and “mounted” are used broadly and encompass both direct and indirect connections, couplings, and mountings. In addition, the terms “connected” and “coupled” are not restricted to physical or mechanical connections or couplings. As used herein the terms “machine,” “computer,” and “server” are not limited to a device with a single processor, but may encompass multiple devices (e.g., computers) linked in a system, devices with multiple processors, special purpose devices, devices with various peripherals and input and output devices, software acting as a computer or server, and combinations of the above.  
       FIG. 1  schematically shows an Electronic Item Management and Archival (EIMA) system  100  incorporating one embodiment of the invention. For the embodiment shown and described herein, the EIMA system  100  is based on an open architecture that accepts any type of image, video, or audio data from anywhere; stores, recomposes and/or reformats the image, video, or audio data; and outputs the recomposed or reformatted image, video and/or audio data. For example, the EIMA system  100  can reformat print-stream data for use on the Web, via e-mail, or via fax. The open architecture provides the ability to accommodate new and more efficient technologies while still maintaining the functionality of previous systems.  
      As used herein, the term “image” data refers to data (or a file having data) that represents an image of a physical object. For example, the physical object can be a document (e.g., a financial document) and the “image” is data representing an image of the object. For another example, the physical object can be a form having entered information and the “image” is data representing the completed form. Example original documents include checks (e.g., for a demand deposit account (DDA)), signature cards, driver&#39;s licenses, photographs, applications (e.g., loan applications), reports, and other related documents. The term “video” data refers to data (or a file having data) that represents a plurality of images. The term “audio” data refers to data (or a file having data) that represents one or more sounds. The original image, plurality of images, or sound(s) are referred to as an “actual” object, and the item includes a “virtual” object representing the actual object.  
      Unless specified otherwise, the term “image” is used below to include “image” data, “video” data, or “audio” data representing an object. For simplifying the description below and unless specified otherwise, the EIMA system  100  is described in connection with check processing and the image is an image (front or back) of the check. However, the invention is not limited to check processing, and a claim should not be limited to check processing unless check processing is specifically recited within the claim.  
      Further, while an EIMA system  100  is described in detail below, not all aspects of the system are required in all embodiments. Rather, some embodiments include only some of the components and/or perform only some of the operations described below. Additionally, other embodiments can include additional components and/or include additional operations that are not disclosed below but nonetheless can be incorporated with the EIMA system  100 .  
      I. EIMA System  
      As shown in  FIG. 1 , one embodiment of the invention comprises the EIMA system  100  that includes one or more item-input devices  105 , one or more host servers  110 , one or more workstation computers  115 , and one or more peripheral devices  120 . Each of these elements is described below.  
      A. Item-Input Device  
      In general, the item-input device  105  provides information regarding a plurality of images (e.g., checks) to the host server  110 . As used herein, the term “information” is broadly construed to comprise images and data relating to or obtained from the images. For example, if the provided information relates to checks, then the information may include the front and back images of each check and data (e.g., MICR data obtained from the check) obtained from each check. The image(s) and data for one document form an item. Example item-input devices (also referred to as item-generation devices) include scanners, check transports, video generation devices having a camera or similar component, sound generation devices having a microphone or similar component, and data feeds for receiving data from other devices (e.g., web feeds from other devices or feeds that receive previously stored data including items).  
      The item-input device  105  includes a controller  125  configured to control the input device  105  and/or to receive input data. The controller is configured to provide one or more “threads”  130  of data. Additionally, although only one item-input device is shown in  FIG. 1 , the EIMA system  100  can include multiple item-input devices  105  (a second is shown in phantom) providing multiple “threads” of information to one or more host servers  110  via a network connection  135 . However, unless specified otherwise, the description below is for a system  100  having only one item-input device, and is specifically a check scanner.  
      1. Example Item-Input Device  
      In one embodiment, the item-input device  105  includes a NCR  7780  scanner having multiple scanning components. The scanner scans financial documents (e.g., checks) and obtains related financial data from the document in a well-known manner. For example, the related financial data can include magnetic ink character recognition (MICR) information (account numbers, check numbers and related data, depending on specifics of the documents recorded, and the institution requirements), optical character recognition OCR information, and similar information. The resulting images can be in any format (e.g., jpeg, tif, bit, etc.).  
      The item-input device  110  also includes a controller  125  that, among other things, communicates with the scanner (e.g., via a LAN) to receive information from the scanner and to communicate the information to other components (e.g., to the host server  110 ). Example controllers include a computer (e.g., a PC) having software executed by the computer to configure the computer, a specially designed electronic device having programmable logic executed by the electronic device to configure the device, or application specific or special purpose circuits.  
      The item-input device  110  also has a sorter (e.g., a hard-wired sorter or a virtual sorter), which may be part of the scanner or the controller. The sorter includes a rule-based engine having rules that control the flow of the resulting scanned images and related data. That is, checks are provided to the scanner in a commingled relationship, the scanner scans the checks to create one or more images, the scanner obtains data relating to the checks, and the rule-based engine performs front-end processing on the checks to sort the checks. For a simple example, the rule-based engine may specify that a check having transit number “A” be provided on thread A and a check having transit number “B” be provided on thread B. The rule-based engine can include any number of rules to sort the checks. For other embodiments, the rule-based engine can include rules based on different image (or video or audio) items (e.g., different types of checks, different types of financial documents, etc.). In yet other embodiments, the host server  110  can include the virtual sorter.  
      The controller  125  further includes one or more connections (e.g., an Ethernet connection) that connect the scanner to the host server  110 . The connection between the controller  125  and the host server  110  can be a direct connection or an indirect connection (e.g., via a network such as an intranet or the Internet).  
      As will be discussed further below, information travels throughout the system  100  using “threads.” Each thread  130  contains information (e.g., a plurality of items) having one or more similar characteristics. Because of the similar characteristics, the same operations are performed on the information contained in a thread  130 . For example, the information can be routed to a specific host server  110  or a specific storage device (discussed below). As will become more apparent below, the concept of utilizing multiple threads (and consequently performing multiple processes) can be utilized throughout the whole system  100 .  
      B. Host Server  
      The EIMA system  100  includes a host server  110  that runs software. As used herein the term software is broadly construed to include computer programs, procedures, modules, data, etc. executable by one or more processors. The software includes software modules (also referred to herein as applications) that are executed by the host server to perform one or more processes or supporting functions. Some of the software modules result in the host server having “virtual” servers. The host server  110  is a Hewlett Packard V-Series server in one embodiment of the invention.  
      In some embodiments, the host server  110  receives information, including images and related data, from the item-input device  105 ; processes the information; archives the information; receives instructions or requests from the workstation  115 ; performs operations based on the received instructions or requests; and communicates information to the workstation  115  or to the one or more peripheral devices  120 . An example of such a server is the Titan 4.0 server offered by ImageSoft Technologies of Maitland, Fla.  
      For the EIMA system shown, the host computer includes the servers listed in TABLE 1. It should be noted that not all of the servers described below are required for all embodiments and the EIMA system  100  can include additional servers not described below. The titles of the servers and the division of the functions of the servers are for explanatory purposes only. One or more functions performed by the one of the servers may be combined with other servers.  
                   TABLE 1                       SERVER           NAME   DESCRIPTION                  CORBA   Responsible for facilitating communication between the       Name   different CORBA applications, and for handling server       Server   registrations and requests.       Bus   Responsible for providing application functionality and       Administrator   services (e.g., print, export, repair, import, etc.).       Server       Parameter   Provides a central location for storing parameters that are       Server   used to control the operation of services and applications           on the bus. Its primary role is to store parameters and           track their modification.       Log   Responsible for logging events and storing messages that       Server   are related to bus archive operations.       Set   Responsible for maintaining the sets of data in the       Server   archive and the definition of document types.       Index   Responsible for providing database functionality for       Server   storage and retrieval of query data that is associated with           objects stored in repositories.       Proxy   Coordinates and organizes traffic to the index servers.       Index       Server       Remote   Handles the print and fax capabilities of Export. This       Distribution   server allows users to remotely log in and request a print       Server   or fax job.       Disk   Responsible for data mining and retrieval of objects       Repository   stored on disk.       Server       Optical   Responsible for importing and exporting cartridges from       Administration   the optical jukebox.       Server       Optical   Responsible for running optical services.       Robotics       Server       Optical   Responsible for storage and retrieval of objects stored on       Repository   an optical storage device.       Server       Tape   Responsible for storage and retrieval of objects stored on       Repository   tape.       Server       Repository   Responsible for storage and retrieval of objects stored on       Proxy   RAID, optical, and tape.       Server       Access   Manages user definitions and security permissions for       Server   those users. All access from the Web server interface is           funneled through the Access Server. The Access Server           is the portal through which client applications are           delivered through a graphical user interface (GUI) to the           end user. The Access Server is an application on the           CORBA bus.       Generic   Responsible for the import of data and images during an       Import   Image Capture session.       Server       Repair   Responsible for Repair GUI.       Server       Export   Runs Reconciled Export.       Server                  
 
      The servers provide, among other things, the following services:  
                   TABLE 1A                       SERVICE   DESCRIPTION                  Bus Service   At the service and applications level, the Bus Service is           responsible for coordination of the entire archive. It           coordinates the access that applications need with the           services provided by the Bus Services.       Bus   The Bus Applications service controls communication of       Applications   the applications that provide application functionality       Service   and use of these services on the bus archive.       Repository   Storage and retrieval of objects (images), i.e., RAID,       Service   Optical and Tape, is the responsibility of the Repository           Service. However, the Repository Service is not limited           to these functions.       Indexing   Provides the database functionality for storage and       Service   retrieval of query data that is associated with objects           stored in the Repository Services.       Set Service   Maintains the sets of data in the archive and the           definition of document type (classes).       Parameter   Stores parameters and tracks their modification.       Service   Parameters are stored in tables (e.g., Sybase tables). The           Parameter Service controls the operation of services that           need to reference these parameters.       Log Service   The Log Service provides a centralized method and           location for logging events, and storing messages related           to the operation of the bus archive. The messages are           stored in tables (e.g., Sybase tables).       Redundancy/   Coordination between archives that have parts of their       Replication   data replicated at one or more locations is the function of       Service   the Redundancy/Replication Service.                  
 
      1. “CORBA” Bus  
      Among other things, in some embodiments the servers provide a multiple-threaded bus that allows multiple lines of communication to occur between modules of the system. For the embodiment described herein, the bus is based on a CORBA architecture. Other architectures can also be used without departing from the invention.  
      In general, the Common Object Request Broker Architecture (“CORBA”) is a standard created by the Object Management Group (“OMG”) that enables operation between different computers, operating systems, and programming languages (e.g., distributive computing). The CORBA standard generally specifies how client applications may invoke requests on server objects. CORBA specifies the Object Request Broker (“ORB”) that allows applications to communicate with one another regardless of where the applications reside on a network. Using a standard Internet Inter-ORB Protocol (“IIOP”), a CORBA-based program from a vendor, on almost any computer, operating system, programming language, and network, may communicate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network. The IIOP specifies how ORBs communicate over networks and can utilize TCP/IP implementation of a General Inter-ORB Protocol (“GIOP”). The GIOP defines aspects of ORB communication including how messages are sent, how bytes are ordered, and how parameters are arranged for remote object invocations.  
      Creation of a distributed computing system based on the CORBA standard can generally begin with an outline of desired functionality and translation of the design into software objects. The objects are expressed in terms of Interface Definition Language (“IDL”) interfaces and collected into related modules. In one embodiment of the invention, the IDL is utilized for creation of Application Programming Interface (“API”) definitions that define how the client and host server systems communicate. One or more IDL files are compiled to generate stub code and skeleton code. The stub code becomes the interface that client applications use to initiate an operation from a server and is programming language independent. The skeleton code provides the interface to object implementations that the host and/or virtual servers may provide. Libraries provided through the IDL compilation provide the mechanism for communication between client and host server processes. The CORBA specification ensures that this communication be platform and language independent. Host and/or virtual server applications are created for publishing the object references by name through a naming service and, upon the request of a client application, a reference to a generic CORBA object is returned. This object reference is then narrowed to the stub representation of the remote CORBA object. The client can then invoke operations through the stub reference as if the object was local to the client. Requested operations from the client application are sent to the skeleton reference obtained through the naming service. Using the ORB, CORBA IDL stubs and skeletons serve as a connection between client and server application threads. In addition, each client and server can have threading definitions defined in a Portable Object Adapter (POA), which controls the communication to a CORBA Object by associating the object with the ORB. Each POA service may use single threaded or multiple-threaded communication protocols and the multiple-threaded protocols may be further defined as “pools” of threads or as a thread per client. The machine independence of the CORBA standard, as utilized by embodiments of the invention, allows for multiple processes to communicate across machines, platforms, and languages, thereby providing a distributed computing environment.  
      In another embodiment, the CORBA communication protocols are utilized to abstract client and server interactions. Using the IDL, APIs are created that separate the architecture logic. Therefore, the CORBA communication layer acts to “hide” or “mask” the host and virtual servers from the client or business logic. Each server process in the EIMA system  100  can be defined to utilize the multiple-threaded “pools” of threads, thereby allowing non-blocking calls to be handled from a large number of client applications. Each client application can be handled independently and, therefore, do not block each other during communication with the servers. The name service and event service, defined by the CORBA specification, are used to handle name lookups for services and event routing or channeling. In addition, a host or virtual server may execute multiple Generic-Input Applications (“GIAs”), statement prints, and exports at the same time, all of which may execute independent of each other and interact separately with an archive or database. Implementation of the CORBA bus in this embodiment also includes providing object services for use by multiple distributed object programs. These services include domain-independent interfaces such as the naming service, a trading service, a repository service, an indexing service, a set service, a parameter service, a log service, an application service, and a redundancy/replication service. The services are available to CORBA objects and a client may initiate multiple services if desired. For example, a client application may invoke multiple services when interfacing data with input/output (“I/O”) devices. Alternatively, multiple threads can exist within the services themselves. For example, depending on the operation, a user or client may invoke multiple threads within the repository service. In some embodiments, the EIMA system may also implement a factory concept whereby a server is a service “factory” that handles queries each time a client connects and requests an individual session. Each session manages its own client and then allows for the abstraction and separation of logic for multiple client applications.  
       FIG. 50  schematically shows one embodiment of the interaction between a plurality of applications  5000  (discussed below), the CORBA bus  5005 , and the archive  5010  (discussed below).  
      2. Applications  
      In addition to the software already described above, the host server  110  includes additional modules that interact with the one or more workstations to perform additional operations. This suite of modules generally comprise two sets of modules: 1) management programs and utilities (collectively referred to as management programs), and 2) Web-based user programs. The management programs allow an administrator to control the host server and, more broadly, the EIMA System. The Web-based programs, which run in a Web browser (e.g., Internet Explorer), are accessed from an EIMA Web site and allow users to perform operations (e.g., perform queries, print statements, export objects, etc.) on the archive. Various software modules that interact with the workstation are summarized in TABLE 2 and are further discussed in detail in the operation section. Similar to the servers, not all of the modules described below are required for all embodiments and the host server can include additional modules not described below. The titles of the modules and the division of the functions of the modules are for explanatory purposes only. One or more functions performed by the modules may be combined with other modules. Additionally, the operation section below may include additional modules that are not listed in TABLE 2, but would be apparent based on the description.  
                   TABLE 2                       MODULE NAME   DESCRIPTION                  Server Management   Controls the operation, including starting and stopping,           of the servers.       Image Capture   Imports images or existing databases into the image           archive database.       Image Match   Verifies that data in the Match Control File (MCF)           matches the captured data in the archive.       Reports   Creates various reports.       Text File Batch Query   Lists the required parameters for a text file batch query?       (TFBQ)       Exporting Images   Exports images to a CD-ROM writer.       File Management   Manages files and databases including deleting database           cycles, deleting databases, and migrating from RAID to           optical.       Image Print   Retrieves a subset of images from a database cycle for           statement printing       Repair GUI   Helps control the quality of the Image Capture process by           allowing the user to view images as well as correct MICR           field data.       Optical and Tape   Enables the system to store images on optical disc or       Administration   tape.       Reconciled Export   Exports and distributes the results of a query to a CD-           ROM writer.       NetQuery   A Web-based program that allows a user to query and           view document information and images in a Web           browser       System Administration   A utility that system administrators can use to control           user access and activities in the EIMA system 100.       Decision Support   Support adds the capability to NetQuery to manage           pay/no pay, pay amounts, and other factors for           documents with fields that trigger the capture program&#39;s           Exception Code generator.       TIFF Image Import Utility   Imports TIFF images for the purpose of transferring           images from the main location to a satellite location.       Batch Update   Updates user fields in a query table after the cycle has           been ingested into the archive database       Archive   Store, track, and access images as they are migrated from           one type of storage device to another       Capture Recovery   Rolls back tables and post information regarding the last           item correctly ingested during Image Capture.       Verify Capture   Matches items in the flat file with rows in the Index table           and provides reports with results of the match       MICR Exit   Changes data corresponding to an Image to conform to           the data provided in the MCF.                  
 
      A number of the applications summarized above form a Generic-Input Application (GIA). The GIA is an application that receives data from the scanner  110 , performs operations on the data (e.g., for consistency), and archives the data to one or more databases. The one or more databases form an archive (discussed further below). Example operations performed by the GIA include: Image Capture, Image Match, MICR Exit, Batch Update, and MICR exit.  
      Before proceeding further, it should be noted that an identifier used for identifying a particular component, application, tool, engine, operation, act, button, etc. is for identifying that component, application, tool, engine, operation, act, button, etc. only, and should not be limiting. For example, the term “Image Capture” identifies an application used by the EIMA system  100  for capturing images. Other terms for identifying the application could be used in place of “Image Capture.” 
      The operations of some of the applications in TABLE 2 are briefly described below. A more detailed discussion of these applications are further discussed in the operations section below.  
      a. Image Capture  
      Image Capture allows a user to import images through 1) scanning documents into an archive and then using Image Match (discussed below) to insert images into the database, 2) importing raw files from disk or tape, 3) importing TIFFs or other objects, or 4) importing text documents using the Import Server.  
      b. Image Match  
      Image Match verifies the contents of an image database with a user-supplied match control file (MCF) and prepares the images for Image Print. The Image Match process verifies that all images expected for capture were captured and that no extra images exist. Images referenced in the MCF but not found in the database are referred to as missing items. Images in the database but not referenced by the MCF are called free items. After the images are validated by this process, they can be printed with statements (Match for Print). When Image Match is complete, it generates Missing and Free Items reports and appends a record to an Audit report, which lists the processing statistics.  
      c. Batch Update  
      The Batch Update feature lets the user update user fields in a query table after the cycle has been ingested into the archive database. In Batch Update, the user loads data from a specified source file or tape in a temporary table. This data file can include all or some of the items in a cycle. The EIMA system  100  finds matches in the cycle with items in the file. Only matched items will be updated with the fixed data in the input file. Batch Update is an option that appears at the end of an Image Match session.  
      d. Image Print  
      Image Print controls the statement printing process. It combines statement text data in the print control file (PCF) with the images from the image database to produce statements with images, instead of original items. The resulting imaged statement can be sent directly to the printer and/or to tape for offline printers, mainframe printers, or selective reprints. When the Image Print process has completed, a record that lists the processing statistics is appended to the Audit report.  
      e. Archive and Optical and Tape Administration  
      The archive function is used to store, track, and access images as they are migrated from one type of storage device (discussed below) to another. When images are first captured, they are initially stored on the fastest retrieval media (local hard drive) or RAID. After the images have been retained on the hard drive for a designated period of time, they are migrated to other media for more permanent storage. The archiving and distribution functions enable the system to store images on optical disk or tape.  
      f. Reconciled Export  
      Reconciled Export allows the user to export and distribute the results of a query to a CD-ROM writer. In one embodiment, the exported images are written as compressed, tagged image file format (TIFF) graphic images. You can use Image Library Offline to view and organize the CD-ROM images.  
      C. One or More Peripheral Devices  120 .  
      The one or more peripheral devices  120  include one or more memory devices for, among other things, maintaining the archive. The one or more memory devices can include RAID, optical storage, tape-storage and similar storage devices. The one or more memory devices store a plurality of databases that form an archive, which can be of various types including “local” or “distributed.” As will become more apparent below, a distributed archive can include multiple local archives.  
      1. Local Archive  
      An archive is designed to hold any type of item. That being said it is necessary to have routines to pass items to the archive, export items from the archive, and view items in the archive. In one embodiment, the local archive supports three storage media for image storage and one storage media for indexes.  
      The three media or tiers of the archive are RAID, Optical, and Tape. The composition of the archive is driven by cost, retrieval time, and/or service agreements. Each media has its advantages and disadvantages. RAID is a random accessible media with the highest cost per byte of storage, but it is self-recoverable and very fast. The cost of this media is falling but it still remains expensive per byte compared to other media.  
      Optical is a random accessible media, which uses a jukebox to reduce the number of active drives required to provide a level of service. The media is never brought into direct contact with anything that will damage it and as a result it is a very reliable long-term storage media for high activity with long life. This media is the best of the three for long-term storage and retrievability without a duplicate backup. With the ability to use multiple drives at any point in time, this media is highly accessible at a much lower cost per byte stored and can provide the fast access necessary for on-line queries.  
      Tape is a serial media, which uses a silo to manage the tape media. This is viewed by many institutions as the preferred media for long-term storage even with the need to maintain a duplicate of each media to insure recoverability. The media is brought into contact with the read/write heads and as a result is very susceptible to damage if used highly over a period of time. This media is the least expensive per byte stored but it is also the slowest media. The speed of the retrievals from this media is a direct function of the speed of the drives and the technique used to store the data on the media.  
      Each industry will have its own migration strategies relating to the movement of the images among levels of the archive. There are several methods to achieve this migration. The following discusses the different methods available to the institutions using an archive of the invention. Unlike previous archives, the archive of the invention moves images from any archive tier to any other archive tier. Also, through the use of different capture processes, the objects being received into the archive can be placed on any tier of the archive and any of the distributed archive locations at the same time. There are many considerations to doing this and just because the archive is capable of it does not mean that it is in the institutions&#39; best interest to use this capability. Additionally, it should be understood that other aspects of the EIMA system  100  can use an archive of the prior art. 
          a. Migrate from the RAID Tier to the Optical Tier to the Tape Tier        

      This is the traditional method used by institutions and it allows the institution to purchase the least expensive solution while providing a system that supports good response time and the ability to optimize the data that is stored. This method allows the user to do all repair work on the object and deletion of extra objects prior to the migration to the next level of the archive. Some institutions will migrate from the RAID tier once maintenance is complete to both the Optical and Tape tier at the same time. Many institutions have the ability to store the object at capture time on all Tiers of the archive used by the site. This capability is available through the use of the prime pass capture capability, but the institution looses the ability to optimize the storage of objects identified later. The institution will inherently use more storage because the objects that are deleted during maintenance remain present on the slower tiers of the archive using space even though they are not accessible due to the deletion of the indexes.  
      b. Direct Capture to any Tier  
      This is available with the archive of the invention. In one implementation, the capture controller software takes a match control file (MCF) file from the mainframe that has the database to which the item is to be sent, and the document identification number (DIN) number of the item as part of the MCF entry. This allows the capture controller to read the MCF, populate all the data fields, use the DIN number to pull the item images, and send the item down the thread to the proper database. An advantage to the institution of this type of activity is that it avoids the time-consuming migration process from one media type to another. However, a detriment to the institution is that this method does not provide any method of optimizing the way objects are moved to the slower tiers of the archive so as to allow for retrievals that will roughly match the higher speed tiers of the archive.  
      c. Current Migration Strategy  
      To avoid the need to go through very time consuming reorganizes of the storage, the objects are migrated in large blocks, which, for example, can represent a days capture. Until all the objects in a block have been migrated, the block space cannot be freed for the storage of new objects. This method works well for all parts of the archive that have random access and if the long term archive tier is used very sparingly this method will also work for the serial tier of the archive. Because many institutions want to go to two tier archives it has become necessary to provide a migration strategy that will organize the object placed on the serial media in a way that will facilitate the optimal retrieval of the objects from this tier. The following defines this optimal migration strategy.  
      d. Organized Migration Strategy  
      This method can be used most effectively when an institution has a minimum number of days (e.g., 45 days) of RAID object storage. In this case, the migration takes place over a ten-day period for the previous thirty days of items on the archive. One tenth of the previous 30 days is migrated to tape every day so that after ten days all the items have been migrated. Of course, a different proportion can be used. These items are organized on the tape according to what data elements are used the most to retrieve the object. Once all the items have been migrated from this 30-day period, all the objects are deleted in a way so as to keep the number of days defined in the service level agreement (SLA) on the high-speed tier and the space is freed for the capture of additional objects. Once there is 30 days of un-migrated data on RAID, the 10-day migration cycle begins again. This method of migration is tailored to the maximum retrieval speed of objects on the long-term archive. With 45 days of RAID, the user has the long-term archive optimized on a 30-day bases and the days of storage are used in the following way: 
          First 30 days of storage period is being migrated.     Second 10 days of storage period is used to migrate the objects from the first 30 days.     Third 5 days of storage period is used as safety to insure that if any problems are encountered in the migration there is time to solve the problems and complete the migration.     Once all the 30 days of cycle objects have been migrated, the server proceeds to delete all cycles until no non-migrated cycles remain then.     The process repeats again after 15 days of no activity (when we are again at the 31 day in a new period).        

      e. Capture to Database  
      This capability allows the capture of any object into any database on either a collective basis or an individual object basis. When a capture is started it can be directed into a specific database or, through the use of a front-end capture routine, can route the individual objects to different databases based on the accompanying index data. In the case of an item-processing department, this means that transit items can go to one-database and on-us items to a different database. This also means that the banks that process for other banks can route the items for each of its bank customers to its own database.  
      2. Distributed Archive  
      a. Introduction  
      When an institution outgrows a single site environment or would like to have more than one active system to back-up data, a distributed archive can be used. The distributed archive feature allows some embodiments of the invention comprising the EIMA system  100  to add data to multiple separate archives at multiple locations, while providing many threads of internal archive access. The feature supports maintenance and retrieval of archive data from the various sites, in addition to optional long-term storage sites within the network. Each location has all the capabilities identified as basic to the local archive but, through the distributed archive, capabilities appear to each application (e.g., Export, Statement Print, Query, etc.) as if the plurality of archives are one distributed archive.  
      In one embodiment, the distributed archive is server based and makes full use of the CORBA Bus. The distributed archive server makes all sites look and operate as one. This means that any function that operates at one location can have full access directly to all other locations within the security capabilities allocated to the distributed archive. The speed of the distributed archive is only constrained by the speed of the line connecting the geographically dispersed locations.  
      To manage the network traffic and to eliminate the delivery of duplicates, the distributed archive includes internal rules. Example internal rules include rules for routing request to the fastest service location and rules that allow for the removal of duplicates prior to responding to a query.  
      As shown earlier, through the use of the direct capture to a database capability, there is the ability to deliver items to many databases at the same time with each database on different media and locations. An update capability can be used to automate the updating of all locations that house the same item. This capability makes full use of the distributed archive capability of the system to find all locations housing an item that is being updated and then it also is used to update the same items held in different databases as well as at different geographical locations.  
      In some embodiments, the distributed archive provides the institution with the ability to have different geographical locations, provides full “hot” backup for other locations without forcing the purchase of full redundant hardware at each location and/or different physical servers in a single location (or any combination of physical servers and geographical locations), and/or provides hot backup for other locations (or servers), thus leveraging the use of existing and planed hardware. The loss of a single geographical location does not effect the retrieval of requested information from sites that are operational and, if the same data is redundant in an alternate location, the request is be fully satisfied automatically from the alternate site. If the data is not held at an alternate location or has not arrived at the alternate location, the requesting user is provided with all available data and is notified that a site is down that may have additional data and that the user may want to request that data at a later time. When the site that is down comes back on line, it will connect back into the network automatically and without the involvement of institution personnel.  
      If the distributed archive is used with a hot backup strategy, then it can be coupled with the appropriate migration strategy. If the institution has enough bandwidth on their network, this synchronization is done through the network. If the institution&#39;s network is not robust enough to handle the volume created by image data, it will be moved via tape. When tape is used to synchronize the archives, then, when the tape arrives at the remote location and is loaded into the appropriate tier of the archive, the indexes at the distributed location are updated and a verification record is forwarded to the originating location identifying the fact that the synchronization tape has arrived and is now in the remote location. If no synchronization record arrives after a period of time, a new tape is created to replace the original tape.  
      Although specific installations may vary on the basis of hardware and/or network configuration, the functionality remains the same for some embodiments of the invention. The use of CORBA and Java enable the EIMA system  100  to run on any operating system and hardware, regardless of platform, database, operating system, programming language or network hardware/software used. The distributed architecture is highly scaleable and is sufficiently dynamic to accommodate a verity of potential archive systems. Further, the Java programming enables the system to link to other Web-centric applications (e.g., online banking).  
      In some embodiments, the distributed archive contains multiple sites all of which have the capability of querying across connected sites. A set of user-defined rules determines the level of query capability accorded to each user of the system. Query capability is the functionality of being able to search the system indexes on the basis of an individual object attribute or combination of object attributes to find the token necessary to retrieve the desired object. Query capability can be either local or global. Retrieval of an object on the basis of a call with a token argument is not considered query capability, it is simply a retrieval operation supported by a low-level media specific local index.  
      Upon the completion of either prime pass capture, utilizing Image Import, re-pass capture, MICR repair, match and missing/free item resolution (all of which are discussed further below), a captured items index is stored and available for query and retrieval. If any changes occurred in the index data as a result of any of these activities and the objects have already moved to the alternate location(s), then update index data should automatically be forwarded to all locations now housing the object. Access to these items, as well as items captured at other sites within the distributed environment, will be facilitated by the appropriate distribution Proxy(s). The Proxy Servers provide the ability to submit requests and return responses from multiple distributed locations without any user intervention. This ability to satisfy individual query and retrieval requests by gathering responses from multiple sites is the foundation of Distributed Archive.  
      Items captured at a particular site can remain at that site on any installed and supported media (magnetic disk, optical platter or tape) for as long a period as is suitable to the needs of the installation. This time period could be as short as one day or could be counted in years. Additionally, captured data can be exported in whole or in part to one or more Global Archive Sites at any time and then be deleted from the original source location once it is confirmed that the data has been successfully archived at the new site. This deletion indicator only indicates that the item is eligible for deletion. The actual deletion is governed by the local archive parameters.  
      In a purely geographically distributed archive, indexes reside on the same server as the tables showing the physical address of images on various media. To the system, physical locations may appear as a single virtual index.  
      b. Use of the Distributed Archive in Providing Institutions with Items.  
      In one embodiment, users of the distributed archive are institutions with multiple facilities that are used for item processing. The institutions typically have network connections between the associated sites (e.g., a WAN). However, the system configuration can be adapted based on the user&#39;s access needs, locality of reference, and desire to modify existing network connectivity. The network speed and traffic pattern can dictate the objects are moved via sneaker-net via the high-speed network. An institution having the distributed archive can also be a very large processing center which has many clustered capture platforms, each operating independently, but to the user being viewed as a single unit.  
      In some embodiments, every location is considered a master location; there are no slave or redundant locations. When objects are moved from one location to another, that data is imported into the new location and the introduction of a new item into an archive cause no action except the update of the object and index archive. If any index item is read for the purpose of updating a query, the index item is set to all locations to determine if that index set is held at a different location. All locations that respond instruct to make this index set read only for the duration of the update operation.  
      All updates to the indexes are distributed to all locations having the same index set. This is done by monitoring the write operations, retaining all the changes to the indexes, then issuing a distributed query for the item that was changed and sending the changes to all locations responding that this object is held at the location. If any location fails to respond, the update is held until a response is obtained from the location that the item updated is not housed. Once all sites are updated then the read only lock can be removed from all other locations.  
      Security features exist on two levels in some embodiments: 1) within the application and 2) through the login and password features provided by the database management system. The security facility within the application is used in establishing a connection to the database data server.  
      By consolidating similar objects together, the archive reduces the number of tapes involved in retrieval and makes more objects available on a single tape storage media. As an example, if a subpoena was received for all items that were received for an account over the previous 4 years, this request would be processed as follows:  
      (Present Process) Each cycle is migrated to tape and depending on the size of the tape there can be any number of cycles on a tape. For purposes of this example there will be only one cycle per tape and one required object per tape. With 260 cycles per year this would mean to satisfy this request would mean that it would be necessary to mount 1040 tapes less the number of cycles still on tiers 1 and 2 assuming at least one item is received daily.  
      (Organized Migration Strategy) The number of days of items on a single tape is a function of the number of days of tier 1 storage that the institution has purchased (see Organized Migration Strategy earlier in this document). If there are 45 days of tier 1 storage, then a single tape will have 30 cycles worth of objects for this account grouped together on a single tape. This would mean that to satisfy the request the system would only have to mount 35 tapes less the number of cycles still on tier 1 and 2. This represents 3.37% of the mounts when compared to the prior art systems and the number of mounts will go down in direct relationship to the number of days of tier 1 storage that is maintained.  
      In some embodiments, the virtual sorter front-end to GIA provides the ability to take a feed from any device either prime pass or re-pass and route the objects through the use of rules to any database. The database thread to which the item is routed retains its ability to have a MICR exit tied to that thread only. When the transaction exit capability is added to the virtual sorter the institution now has the ability to populate a transaction identification field identified in the class definition for the type of object being captured. The composition of a transaction is defined by rules contained in the exit and is independent of the rules used to route an object to a database. The application of the transaction rules is done prior to the application of the routing rules.  
      The following example is how item processing can use the above capabilities to maintain the content of a deposit as a transaction: 
          In this case the items are arriving from the prime pass and each deposit ticket precedes the checks associated with the deposit.     The exit rules state that whenever a deposit ticket is encountered a unique identifier is to be generated and inserted into the transaction identification field.     The exit rules further state that the current unique identifier is to be placed in the transaction identification field of any object encountered that is not a deposit ticket.     Once the transaction exit rules have been executed the object proceeds to the routing rules which can state anything, but as an example the following has been defined: any item with this institutions route/transit number will be sent to the On-Us item database, any item having a different route/transit number will be sent to the Transit item database.        

      Once the objects are in the archive the user can make use of the index database and define different views of the archive based on how the user wants to use the items in the archive. The transaction field may or may-not be part of the data used to create these specialized views. In most cases these workflow related archive views will be only available for specified periods of time and will be used for very special work processing.  
      Through the use of this capability the user can structure any views they please of the archive no matter whither the items are held in the archive in different databases at their local facility or at different locations. In the case of the financial institution these views can include: all-items in Capture Sequence, cash letter (which can have multiple document types tied together by unique deposit identification), on-us (or account) number order, route/transit number order, exception items (which can be by type, institution, etc.), high dollar amount, etc.  
      c. Site Management Reports  
      To better manage the distributive archive it may be necessary to provide more and better reports on what is going on within the archive. These reports can take the form of screen and paper reports, and can be used to balance the transaction activity within the archive.  
      As an example of a management report, the system can balance the number of items received from a sorter with the number of items sent. Further, the system can balance the number of images that should have been sent against the number received and archived by database. In one embodiment, these reports address all parts of the system in such a way that there is no function performed in the system without appropriate balancing and management reports. This balancing and management reporting can include: capture, export, print, queries, and inventory.  
      d. Performance Requirements  
      The performance of the distributed archive is largely dependent upon the network configuration. The system architecture is designed to minimize the data to be sent over the network by limiting network activity to remote procedure calls and image movement upon query requests only. Large data movement between archive sites is targeted for high-volume media such as tape. However, nothing in the system design will preclude the use of a network for large-scale image movement for institutions who wish to invest in network communications with sufficient bandwidth to support that activity.  
      e. Export to a Remote Archive  
      Export to a remote archive allows for data captured at any site to be exported to any other location. The export media can be a tape, which can then be physically transported to another site. Alternately, the network connection can be utilized for an export to a remote site. Export can also be directly to an NFS mounted UNIX file system or a PC based Remote File System (RFS).  
      Once transported to the new site, the information can be reingested into the remote archive through the GIA module. Once the data is successfully ingested into the archive a message can be sent to the originating site indicating that the original data has been successfully migrated and it can be deleted when its retention time expires.  
      Due to the large volumes of data to be exported, the exported data will be drawn directly from the local archive as the export is in progress, only a catch large enough to insure maximum network transmission speed will be maintained.  
      f. Example  
      An example of a distributed archive  300  configured in accordance with some embodiments of the invention is shown in  FIG. 3 . Site A sends its data to Site B for backup and Site B sends its data to Site A for backup. Since Site C does not have a tape silo and it keeps only 180 days on raid and optical. Site C sends their data to both Site A and Site B. For this embodiment, there are two copies of Site C&#39;s information. The end result is that there are two copies of all data. Distributive Archive allows multiple copies to be at multiple locations and allows a site (e.g., Site C) to search multiple sites. Site C can use the distributed network to obtain the data as fast as possible and based on its location and the network speed to either Site A or Site B.  
      g. Functional Description  
      For a local archive, a Repository Proxy Server manages communications with Optical Repository, Tape Repository and Disk Repository. For a distributive archive, in one configuration, each repository creates a Remote Repository Proxy. The Remote Repository Proxy communicates with the local Optical Repository, Tape Repository, and Disk Repository, but it will also log into the remote buses locations and communicate with the Optical Repositories, Tape Repositories, and Disk Repositories (See  FIG. 4 ).  
      When the Remote Repository Proxy is called, it is provided with a list of items needed. The indexes are retrieved without starting actual image retrieval until the user tags the image as needed. A similar proxy can be used for the index database.  
      h. Other Peripheral Devices  120   
      As will become apparent below, the one or more peripheral devices  120  can include other devices such as a printer (e.g., Xerox, IBM, and HP-PCL compatible printers) for printing statements, an optical disc writer (e.g., a CD-ROM writer), a communications port for sending facsimile transmissions or electronic communication (e.g., email) transmissions, or other known peripheral devices.  
      D. One or more workstations.  
      In some embodiments, the one or more workstations  115  provides an interface between the EIMA system  110  and a user or administrator, provides requests or instructions (both also referred to as inputs) to the host server  110  (which are initiated by the user or administrator), receives information from the host server  110  (e.g., originating from the archive), and provides information to the user. An example workstation is a personal computer. However, other workstations are possible including Unix machines, laptop computers, handheld devices, Internet appliances, and similar devices. The operation of the workstations for initiating an application (e.g., a query, an export, a statement printing, etc.) are further described in the operations section below.  
      A diagram of one workstation  115  is shown in  FIG. 2 . One specific workstation is an Intel™ based computer employing a Windows™ operating system and an Explorer™ browser. Other types of computers with appropriate operating systems can be used.  
      The workstation  115  includes a communications port  200  for communicating with the host server  120 , one or more input devices, and a visual display unit  205 . In one embodiment, the one or more input devices includes a keyboard  210  and a mouse  220  that allows a user to input data to the workstation  115 . Other data input devices can be used including a keypad, trackball, touch screen, touchpad, pointing stick, microphone or similar device. The input devices  210  and  220  having a corresponding driver program stored in the workstation allowing the workstation to communicate with the input devices  210  and  220 . The corresponding driver program for the mouse  34  is a pointer driver program that generates a “pointer” on the display unit  205 . The pointer driver program allows the pointer to be moved on the visual display unit when a user manipulates the mouse  220  and to select items when the user pushes buttons on the mouse  220  in a prescribed order. Of course other input devices can have corresponding driver programs and can perform functionally similar to the mouse  220 .  
      II. Operation  
      A. General Description  
      While the discussion herein relates to scanned documents (and specifically checks) other objects, including video and audio objects can be imported, archived, and exported. The names of the modules (or applications) below are for explanatory purposes only. The operations performed by most of the modules described below can be extended to other types of objects. Additionally, none of the modules described below are essential to the invention, although many embodiments use many of the modules.  
      1. Image Capture  
      Image Capture allows a user to import images through 1) scanning documents into the EIMA archive and then using Image Match (discussed below) to insert images into the database, 2) importing raw files from disk or tape, 3) importing TIFFs or other objects, or 4) importing text documents using the Import Server.  
      For checks, Image Capture inputs scanned images and associated MICR data and then stores the MICR data in a temporary table. Any records with invalid MICR data are automatically flagged for repair, and Repair GUI (discussed below) is used to validate these records.  
      2. Image Match  
      Image Match verifies the contents of the image database with a user-supplied match control file (MCF) and prepares the images for Image Print. The Image Match process verifies that all images expected for capture were captured and that no extra images exist. Images referenced in the MCF but not found in the database are referred to as missing items. Images in the database but not referenced by the MCF are called free items. After the images are validated by this process, they can be printed with statements (Match for Print). When Image Match is complete, it generates Missing and Free Items reports and appends a record to an Audit report, which lists the processing statistics.  
      3. Batch Update  
      The Batch Update feature lets the user update user fields in a query table after the cycle has been ingested into the archive database. In Batch Update, the user loads data from a specified source file or tape in a temporary table. This data file may include all or some of the items in a cycle. The EIMA system  100  finds matches in the cycle with items in the file. Only matched items will be updated with the fixed data in the input file. Batch Update is an option that appears at the end of an Image Match session.  
      4. Image Print  
      Image Print controls the statement printing process. It combines statement text data in the print control file (PCF) with the images from the image database to produce statements with images, instead of original items. The resulting imaged statement can be sent directly to the printer and/or to tape for offline printers, mainframe printers, or selective reprints. When the Image Print process has completed, a record that lists the processing statistics is appended to the Audit report.  
      5. Archive and Optical and Tape Administration  
      The archive function is used to store, track, and access images as they are migrated from one type of storage device to another. When images are first captured, they are initially stored on the fastest retrieval media (local hard drive) or RAID. After the images have been retained on the hard drive for a designated period of time, they are migrated to other media for more permanent storage. The archiving and distribution functions enable the system to store images on optical disk or tape.  
      6. Reconciled Export  
      Reconciled Export allows the user to export and distribute the results of a query to a CD-ROM writer. In one embodiment, the exported images are written as compressed, tagged image file format (TIFF) graphic images. Image Library Offline can be used to view and organize the CD-ROM images.  
      B. Operation of One Embodiment of the EIMA System  
      1. Overview of the Main Menu of the Host Server as Accessed by a Workstation  
       FIG. 5  is a screen print of the Main Menu  500  of the host server  110  as accessed by a workstation  115 . To access the Main Menu  500 , a user establishes a TELNET session using the workstation  115  to the appropriate host (e.g., Unix) server  110  as is known in the art. The user then enters a login name and password. Assuming the login name and password are correct, the user enters the name of the Main Menu  500  at the prompt (e.g., Unix prompt). The Main Menu  500  then opens. The Main Menu  500  contains options for setting the document type, database, and cycle, and also has options for launching the submenus of system modules.  
      Before most EIMA system  100  procedures can be performed, the user specifies the document type, database, and cycle on which the user wants a particular function to be run. However, setting the database and cycle is not a prerequisite for all EIMA procedures. For example, running Reconciled Export (discussed below) does not require the user to select a database and cycle. The user can tell which document type, database, and cycle is currently selected by viewing the text in brackets ( 505 ,  510 , and  515 ) that appears after the first three main menu options. In the example shown in  FIG. 5 , the selected document type is Check, the database is TestDB — 313, and the cycle is 20010314. The user can change the document type, database, and cycle by entering text in the appropriate field.  
      2. Server Management  
      The user verifies that a server is running by checking if the server&#39;s abbreviation appears in the List of Servers on the Application Server Termination Program menu  600  ( FIG. 6 ). If the server abbreviation appears on the list, then the server is running. If the server abbreviation does not appear on the list, then the server needs to be started.  
      To get to the menu of  FIG. 6 , the user selects the File Management &amp; Utilities Menu option  520  ( FIG. 5 ). At the File Management &amp; Utilities Menu  700  ( FIG. 7 ), the user enters the Drop Application Server(s) option  705 . This results in the Application Server Termination Program Menu  600  being displayed. The Application Server Termination Program Menu  600  provides information on the status of each virtual server. For the embodiment shown in  FIG. 6 , the Application Server Termination Program Menu  600  uses abbreviations, which correspond to the servers shown in TABLE 1, and, if the server is listed, then the server is running. Further, entering the number of a server and then pressing Enter stops that server.  
      3. Image Capture  
      a. Overview  
      Image Capture should be performed for the desired documents before the user runs Image Match or Image Print. The user can import images into the EIMA system using the following methods: 1) Scanning documents into the archive and then using Image Match to insert images into the database, 2) importing raw file data from disk or tape (raw file import is used for testing only), 3) importing objects (e.g., TIFF images), 4) and importing text documents using the Import Server.  
      Image Capture transfers the document images and associated information (MICR code) from the scanning device to the host system, reviews each MICR code for correct syntax, stores the images and associated information in an image database, scans and stores the special images used by Image Print, and/or adds a record to the Audit report that lists the processing statistics. The images and their associated MICR data are supplied from the scanning device(s).  
      (i) Parameters  
      Image Capture requires that the images and associated MICR data for a specific database/cycle name and image capture parameters. The parameters that define Image Capture processing requirements are defined in a Default and Override Parameter files. The Default Parameter file is used by Image Capture each time it is executed. It is also used by all databases in the environment.  
      (ii) Quality Monitor  
      During Image Capture, Quality Monitor can display a sample of the images as they are added to the archive. Quality Monitor displays a new image according to the user-specified time increments (e.g., seconds). See the discussion for Repair GUI below for more information on using Quality Monitor.  
      (iii) Multiple Scanners  
      Multiple scanners are supported by executing separate copies of Image Capture software concurrently. The concurrently running copies of Image Capture can be output to separate databases or the same database. Access to a separate Main Menu  500  is required for each software copy of Image Capture.  
      (iv) MICR Errors  
      The user corrects any MICR errors detected by Image Capture by using MICR Repair. The user performs MICR repair any time after Image Capture is started. After Image Capture and MICR Repair have been completed, the user is ready to initiate the Image Match process to validate images and associated data against the match control file (MCF). After Image Match is complete, the user can run the Image Print process to print images and associated data on customer statements.  
      (v) Batch Tickets  
      If the user runs Incremental Match, the user can scan a batch ticket prior to scanning the corresponding batch of items or type the Batch ID at the Main Menu  500 . A batch ticket is a MICR-encoded document that contains a four-character ID that uniquely identifies the batch. The batch ID is appended to the Match Control File name when the file is brought into the system using File Load. In this way, the scanned images are matched to the correct MCF.  
      b. Image Capture for Systems Using Match  
      The user begins Image Capture when he is ready to scan a new batch of items. If the user uses the Windows version of Quality Monitor, the Quality Monitor program is running on the client. Scanned images are stored in an image database that is identified by a unique combination of database and cycle name. When the user is ready to capture images, the user can create a new database and cycle for the new set of images or can append the images to an existing database. The database and cycle names may be predetermined by predefined procedures and the name can be related to a corresponding match control file (MCF).  
      In one embodiment, the user performs the following acts to capture document data and images into a database cycle: 
          At the Main Menu  500 , the user enters the Capture/Browse Images Menu option  525  resulting in the Capture/Browse Images Menu opening.     In the Capture/Browse Images menu  525 , the user enters a Capture Using GIA gate option. If the system has more than one scanner installed, the user will see a Capture Source Menu to select a scanner. This results in the user connecting to a scanner PC. Typically, the scanner typically comes with a controller PC that communicates with the host system.     When the Ethernet connection to the scanner is complete, the user can then begin scanning documents. The steps for starting a scanner varies based on the scanner type. Two example documents that can be referred to for operating the scanner are DP500 Administrator&#39;s Guide for Unisys Scanners and NCR 7780 Users Guide for NCR scanners, both of which are published by ImageSoft Technologies of Maitland, Fla. A sample of the images can be displayed on the Quality Monitor workstation if that option is activated. As scanned images are added to the system, Image Capture statistics are displayed in a text window. These statistics include total images stored, image size, total MICR defects, and the scanning rate.     After completing the scanning of the items, it is preferable that the user shuts down Image Capture to prevent database corruption. To shutdown Image Capture after items have been successfully scanned, at the scanner controller PC, the user exits the scanner controller program as specified by the scanner when all items have been scanned and the scanner hopper is empty. A message indicating that a successful shut down occurred should appear at the workstation.        

      c. Capture Recovery  
      If Capture terminates as a result of an user error or system problem such as a server returning an exception, the Capture Recovery process can accurately roll back tables and post information regarding the last item correctly ingested. The capture recovery process on the host system is as follows: 
          When Capture is interrupted, Capture Recovery displays information about the last item captured successfully (committed to the database). The user should not rely on the scanner&#39;s report of the last item it captured (scanned) successfully. Rather, the user must use the last item that Titan reports as successfully captured and ingested.     Reboot the scanner controller to flush the scanner buffer.     Reload and scan the items into the scanner that did not get captured successfully.        

      d. TIFF Image Import Utility  
      (i) Overview  
      The user can import TIFF images from tape, CD-ROM, a UNIX processor or other devices for the purpose of transferring images from a main location to a satellite location or for importing special document types. The TIFF Image Import Utility supports  3480  (square tape), Quarter Inch Cartridge (QIC), CD-ROM, UNIX process, 8 mm tape, Digital Linear Tape (DLT), Tiff Import using GiaGate (imports directly into the archive without using Micr Repair/Repair GUI or Image Match), and Import from third party applications.  
      (ii) Importing Tiff Images  
      To import TIFF images, the user performs the following acts to capture images from tape: 
          Initiate two separate Telnet sessions and proceed to the main menu in both Telnet sessions.     Establish the database cycle in both Telnet sessions.     Choose the Capture/Browse Images Menu  525  ( FIG. 5 ) for the first session.     Choose a Capture using GIA gate option (TIFF Import).     Choose the Capture/Browse Images Menu  525  ( FIG. 5 ) for the second session.     Choose Capture Using GIA gate. 
 
 Performing the above acts connects the second work session to the Tape Import Process running in the first session. It also provides information about the number of images sent to the defined database cycle. When all the images are imported, the host displays information in the second session screen that includes how many images you added to the database. It also shows MICR data for the last check images. 
    After the process has ended, the host also displays information in the first session screen that indicates the image count and the number of skipped bytes. It is normal for the process to skip bytes. The user can validate the success of the import process by selecting Browse Item Images from the Capture Menu or viewing images in NetQuery.        

      e. Overview of Importing Images  
      As an alternative to scanning the images directly into the Image Archive database through the Image Capture program, the user can use Image Import to convert an existing image database to the format used by Image Archive and use the Import server to import the images into the archive.  
      (i) Archive Import API  
      Due to the unique aspects of an existing image database, each client may need a specialized interface that connects to Archive Import API. The user can also use a Generic Importing Application offered by ImageSoft Technologies of Maitland, Fla. The Generic Importing Application (GIA) resides over the Archive Import API and acts as a socket server to more easily obtain the images from other platforms.  
      A ScanGate II program resides on the host system and is an import application that receives images from the network and imports them directly into the Archive database using the Archive Import API application. Although ScanGate II can accept images directly from an Image Soft scanner application, its main purpose is to receive images from another image system where the images have already been validated and associated with other control information. Images and data that have been ingested by ScanGate II are not sent to the ImageSoft MICR Repair system.  
      (ii) Image Sets  
      The existing image database may already have assigned names that identify the sets of images, but these names need to be converted to the format used by the Archive. During Image Import, a database/cycle name is assigned to each set of images imported from the image database. For the EIMA system  100  described herein, the cycle name should be in the format YYYYMMDD, which typically represents the original processing date for the set of images. The database name/set name typically represents the customer or business entity owning the images or if desirable this may represent the type of image.  
      4. Image Match  
      a. Overview of Image Match  
      For reconciliation purposes, Image Match is used to verify that data in the user-provided match control file (MCF) matches the captured data in the archive. Image Match also allows the user to view free items, move items, and insert missing items into the archive. The Match Menu also contains an option for clearing the currently selected match file. The Match procedure is performed after the user has scanned MICR data and images and resolved MICR problems, and before images can be queried and viewed in an image viewing program, such as Net Query (discussed below).  
      Image Match also provides ability to add additional search fields to each of the image records using Batch Update. Batch Update allows the user to update the captured data with additional field data that is not part of the original MICR data. For example, the user&#39;s company may require that a microfilm number be added as a search field to all the records in the captured data. Image Match further provides the ability to generate match statistics reports.  
      For the embodiment described herein, Image Match is required for Image Archiving and Distribution and Statement Generation. The Print server is used to organize images before statement generation (discussed below).  
      When documents are scanned, the data from the MICR line is captured and then ingested into the image capture index in the archive. When Image Match is run, data in the MCF is compared to the captured data in the archive. Image Match looks at specific fields in both sets of data, and then attempts to verify if the data matches or does not match. Following the Image Match process, a match statistics summary that details the results of the match session is displayed onscreen.  
      Each MCF record preferably contains MICR data, including the fields required for Image Match, group ID and period in statements, and user fields. Each record in the captured data contains information about the corresponding image including MICR data (made up of the account number, serial number, amount, transaction code, and transit/routing number) and the fields required for retrieving the image from the database (e.g., the image location and the size of the image). The MICR data corresponding to the image may have been changed by a MICR Exit program to conform to the data provided in the MCF.  
      The Match Control Menu (MC) option  530  of the Main Menu ( FIG. 5 ) is used to access the Match Control menu, which includes a perform match option on the Match Menu to initiate match. ScanGate II users do not need to run Image Match for archiving and distribution.  
      b. Types of Match  
      For one embodiment, two levels of match are run. One level or both levels of match can be processed during Image Match. The user sets parameter to determine which fields are used to perform the match assessment. The actual fields that Image Match uses for data verification vary depending on the user&#39;s operational needs.  
      The first level of Image Match is by account field, serial field, and amount field. This type of match attempts to match the two sets of data using the account number, serial number, and amount fields; and then optionally, by the transaction code field and transit routing number field. If Image Match is unable to make a match against these fields, it will try to match the data against the account number field and the serial number field, and then, optionally, using the transaction code field and transit routing number field.  
      The second level of Image Match is by account field and amount field. This type of match attempts to match the two sets of data by comparing the account number field, and amount field, and then, optionally, by the transaction code and transit routing number fields. This match is used only after the other items in an account have been matched by the account number, serial number, and amount fields. Other criteria of levels for performing a match are possible.  
      c. Initiating Image Match  
      The Image Match process allows captured data and images to be available for query and viewing in the Net Query program. After running Image Match, missing and free items are generated, and the user can generate a Free Items report, a Match Statistics report, a Missing Items report, and an Audit report. In addition, Image Match can perform statement printing.  
      During an Image Match session, the user will have an option to run a batch update. Batch Update allows the user to update the captured data with additional field data that is not part of the original MICR data.  
      When performing a match, the match database and cycle should be selected. Additionally, the user should start (if not already running) the CORBA Name Server, the Set Server, the Bus Administrator Server, the Proxy Index Server, the Parameter Server, the Disk Repository Server, the Log Server, and the Repository Proxy Server before performing the match.  
      To run Image Match, the following acts are performed: 
      Open the Match Menu: 
        At the Main Menu  500 , the user enters the Match Control Menu option  530 , resulting in a Match Control menu  800  ( FIG. 8 ) opening. At the Match Control menu  800 , the user navigates the software resulting in the initiation of the Image Match process.     The user then selects the Enter Batch ID option  805 . A Batch ID list appears for the user&#39;s review. At the Batch ID list, the user selects the batches for the matching procedure. After selecting the batches, the user is returned to the Match Menu  800 .     At the Match Menu  800 , the user selects the Load Match Control File(s) option  810 , resulting in an MCF File List being displayed. An example list  900  is shown in  FIG. 9 . The user then selects the correct MCF files from the MCF File List  900  corresponding to the batch files. After selecting the MCF files, the user is returned to the Match Menu  800 .     At the Match Menu  800 , the user selects the Perform Match option  815 . This results in the Image Match process beginning. Upon completion, a summary of the match results displays and then the free item selection prompt appears.     The user can then perform a free item selection. After free item selection is performed, a directory of the defect items is displayed, and then the Batch Update prompt appears. At the Batch Update prompt, the user can populate the captured data with additional field data. A list of match summary results is displayed and then the Image Match process is completed and the user returns to the Match Menu  800 .    
       

      d. Resetting Match  
      The resetting match options clears the temporary match space. For example, if user loads the wrong match file, resetting match will clear the match file, so that the user can load the proper match control file.  
      e. Correcting Free and Missing Items  
      If any missing or free items are noted in the onscreen match results summary, the user can correct these items and then rerun Match. Free items are extra images that have been noted in the capture data, but not in the match control file (MCF). Free items indicate that there is a discrepancy between the number of items in the capture data and the number of items in the MCF.  
      Missing items occur when there are records in the MCF with no corresponding images. There is usually a direct correlation between the number of free items and the number of missing items.  
      Free items can be the result of scanned items that do not belong in the current database cycle or incorrect MICR data. If a large percentage of free items appear on the report, there was likely a mechanical problem during Image Capture. It is possible that the wrong tray was scanned or not all of the trays were scanned. In this case, the user runs Image Capture again. If the percentage of free items is small, the discrepancies are probably the result of incorrect or illegible MICR data. In this case, the user needs to release the images to the MICR Repair workstation for correction. Once the MICR data is repaired, the user should be able to run Match again without error. To correct the unmatched items, the user performs the following acts in this embodiment of the invention: 
          At the Match Menu  800 , the user verifies that the selected document type, match set, and batch ID settings are correct. The user then selects the Free Item Selection option  820 . The system flags the free items for MICR Repair.     The user then uses the MICR Repair workstation discussed below to correct the MICR data for the free items. After completing all the corrections, the user runs Image Match again.     If the report still lists Free Items, then the user either use the MICR Repair Skip command to delete the item if the item is invalid, or corrects the MCF if the item is valid but not found in the MCF.     If there are still missing items listed in the report, then the user either scans the item into the data base and then reruns Image Match if the item is valid, or corrects the MCF if the item is not valid. If the user cannot locate the missing item, then the user can assign a surrogate image in its place. If the missing item is located later, the user can scan the item into the database and then rerun Match.     After all problems have been corrected, the user selects the Free Item Group Move option from the MATCH MENU to move the items into the archive.        

      5. Verify Capture  
      a. Overview of Verify Capture  
      If the image data is captured ‘clean’ (i.e., defective data has been repaired and the MICR exit has taken place), then after capture takes place, the index tables are set as matched. If, however, the user would still like to verify whether all the items that have passed to GIA are actually stored in the archive, then the user can provide a text file containing a user-defined set of fields to be matched against. The match fields can be configured through the parameter service. Verify Capture matches items in the file with rows in the Index table and provides reports with results of the match. Verify Capture provides match statistics, a list of missing items, a list of free items. The differences between Image Match and Verify Capture include: Image Match performs match incrementally, Verify Capture does not, Image Match only matches those items that are marked as “unmatched” and Verify Capture matches items that are already marked as “matched,” Image Match updates a user-specified set of fields from items in the MCF file and Verify Capture does no updates.  
      To perform Verifying Capture, the user navigates from the Main Menu  500  to the Verify Capture option. Upon initiation of Verify Capture, the MCF file is loaded and matched against the database and cycle. The match results are displayed. The user can then generate capture reports.  
      6. Text File Batch Query (TFBQ)  
      a. Overview of Text File Batch Query (TFBQ)  
      To export a selected group of images to media such as a CD-ROM, the user can create a text file that includes query criteria and destination specifications. This file is called a Text File Batch Query (TFBQ).  
      The TFBQ can be created on a PC using any ASCII editor that does not embed formatting characters into the file. The file can also be created on a UNIX system using “vi”, the text editor for Unix systems. Once created the user creates the file, moves or copies the file to a directory on the host system and then executes the file to locate the images.  
      Each TFBQ includes of one or more queries or jobs. Jobs are written using the following guidelines: 
          Each job has at least one valid query ID or an actual query specified.     A job can contain pre-existing NetQuery type query ID&#39;s to be exported and/or the user can specify actual queries to be submitted to Query Server and then exported to Export Server.     Every job has a job name.     Every job has a customer name.     Every job has a job type field.     A job can have multiple destinations denoted with the start/end destination pair.     Every destination has a media ID or destination ID.     A destination has an image format.     Any fields that are not required can be omitted and will receive a default internal value.     Comments within the text file can be specified using a comments character (e.g., #). Anything starting with the character and ending with a newline character will be designated as a comment.        

      7. Exporting Images  
      a. Overview of Reconciled Export  
      Reconciled Export allows the user to export check items and images that meet a specific criteria to a CD-ROM writer (other method of deliveries are possible). Once the job has been exported to the CD-ROM writer, the user can create CD-ROMs that contain the query results of the TFBQ. The CD-ROM&#39;s can then be distributed for viewing with an Image Library Offline program. An example Image Library Offline program is offered by ImageSoft Technologies of Maitland Fla. The scope of items that are exported to the CD-ROM writer is determined by the Export Job&#39;s query criteria. A text file batch query is used to specify each export job&#39;s query definition and destination specifications.  
      Prior to running Reconciled Export, the user should verify that the export job&#39;s query and export destination parameters are defined in the TFBQ, the export job&#39;s TFBQ and corresponding match control file (MCF) are placed in the correct directory, the export job&#39;s parameters are set in the job control file (JCF) and then placed in the correct directory, and the Export server is running.  
      During Reconciled Export, the user reviews the Job List report that is updated after the user starts the export process. The Job List report shows if any missing items have been found for a particular export job. If missing items have been detected, the user should correct these items and then rerun Image Match. A Missing Item report can be generated from the Export Reconciliation Menu. After a successful export, the export job is released to the CD-ROM writer for CD-ROM production.  
      b. Overview of the Job Control File  
      The Job Control File contains the parameters that are used to process an export job in Reconciled Export. These parameters define the export job&#39;s name and the directory locations of the files that contain the query specifications, and the MCF and report data. A job control file can contain multiple export jobs. Before running Reconciled Export, the job control file parameters should be set. The job control file parameters include JOB_NAME, TFBQ_FILE, and MCF_FILE parameters, which are typically required; and REPORT parameters, which is optional. The JOB_NAME parameter designates the name of the export job, which is generated before and after Reconciled Export. The TFBQ_FILE points to the location of the text file batch query (TFBQ) file in EIMA system. The TFBQ file contains the export job&#39;s query criteria and the destination specifications. The MCF_FILE points to the directory location of the match control file (MCF). During Reconciled Export, data in the MCF is compared to the captured data in the archive. The MCF contains the MICR data, the Group ID, and period in statements, and the query fields. The REPORT parameters point to the location of an optional report file.  
      c. Overview of the Job List Report  
      The Job List report is generated and updated during the Reconciled Export process to help the user track the progress of the user&#39;s export jobs. The Job List report shows the before and after status of the export jobs. Before items are exported, the Job List report lists the number of items that will be exported to the CD-ROM writer, and if any missing items were detected. After items have been exported to the CD-ROM writer, the Job List report shows the ID that was assigned to each export job.  
      The Job List report provides the batch that contains the items and images that will be exported to the CD-ROM writer based on the query criteria in the text file batch query (TFBQ), the Name of the job as specified in the job control file, the number of items that met the TFBQ&#39;s criteria and the number of items that will be exported to the CD-ROM writer, the number of items in the batch but missing from the MCF, and the number assigned to the export job. This number assigned to the export job can be used to track the progress of the export job. If the user uses the Job Manager or Resource Manager program, the same export ID number that appears in the Job List report is shown in both of these programs.  
      d. Running Reconciled Export  
      The Reconciled Export process enables the user to export images to a CD-ROM writer by loading the job control file that contains the query specifications. If missing items are detected, the user has the option of viewing a Missing Item Report.  
      To export images to a CD-ROM, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Reconciled Export option, resulting the Reconciled Export Menu.     At the Reconciled Export Menu, the user selects the file he wants to export. A message appears asking if the user wants to run Reconciled Export on this file. If the user answers positively, the user sees a series of messages indicating progress.     Upon completion, an option is given whether the user wants to view the Missing Items Report. If the user answers positively, the user views the Statistics Report.     After viewing the Statistics Report, the user can export the images to CD. If the user answers affirmative, the images are submitted to CD and a job id number is displayed. To track the status of existing export jobs in the EIMA system, the Job Manager program can be used to troubleshoot, customize, control, and monitor jobs by export ID number. The Resource Manager program is also available for creating new media destinations.        

      8. File Management  
      a. Deleting a Cycle  
      The user can delete a database cycle from the following locations:  
                           TABLE 3                                   SERVICE   DESCRIPTION                          RAID repository   Selecting this option deletes the database               cycle from the RAID repository.           IDX service   Selecting this option deletes the database               cycle from the module that keeps track               of item descriptors or query tables.           Set service   Selecting this option deletes the database               cycle from the module that tracks               database and cycle names                      
 
      To delete a database cycle from one or all of the following locations, the user performs the following acts: 
          At the Main Menu  500 , the user selects the File Management &amp; Utilities Menu option  520 .     At the File Management &amp; Utilities Menu  700 , the user selects the Delete Cycle Menu option  710 . The Delete Cycle Menu  1000  opens as shown in  FIG. 10 .     The user then enters the number of the repository or service that the user wants the cycle to be deleted from. The cycle is deleted from the selected location and the Delete Cycle Menu  1000  changes to reflect the remaining locations where the cycle still exists.        

      b. Deleting a Database  
      Deleting a database permanently removes the database from the archive. Before the user deletes a database, the user should delete all cycles within the database.  
      The user performs the following acts to delete a database: 
          At the Main Menu  500 , the user selects the File Management &amp; Utilities Menu option  520 .     The user then selects the Delete Database option  715 . The user can then select a database to delete. That database is deleted from the archive.        

      c. Migrating from RAID to Optical  
      Migrating from RAID to optical allows the user to move a copy of the document data and image files in a particular database cycle from disk (RAID) to an optical device. The migration process enables the user to free up disk space. After the user has successfully migrated the files from disk to optical, the user can delete the database files from disk. The Optical Repository server and the Optical Robotic server need to be running. To migrate images from RAID to Optical, the user performs the following acts: 
          At the Main Menu  500 , the user checks that the correct database and cycle that he wants to migrate to RAID are selected. The user then selects the File Management &amp; Utilities Menu  520  option.     At the File Management &amp; Utilities Menu  700 , the user selects the Start Migration option. The user then chooses the source (e.g., RAID repository) and the destination. Once the source and destination are selected, the migration is performed.        

      d. Restoring from Tape  
      The Restore procedure for multi-file backup is the same as the standard restore procedure except that now the system keeps track of cycles that the user has backed up and their corresponding tape Volume IDs. The system will request that the user mount the specific tape Volume ID for the cycle he has selected to restore.  
      9. Image Print  
      a. Overview of Print Server  
      The purpose of the Print Server is to allow the user to retrieve a subset of images from a database cycle for statement printing. For example, the user can have a database that contains all items for an entire month, or the user may want to pull out items for customers who require statement print. The user uses a match control file to match up the items that he wants to print. The user can then run statement print for the clients that require it.  
      The print server retrieves the objects directly from the archive database. Any objects received and placed into a new cycle are in a format that is immediately viewable by NetQuery. In addition, the Print Server allows the user to export print images to a remote server for printing purposes instead of on the main host system.  
      b. Retrieving Images using the Print Server  
      The following steps refer to two different servers: a main server and a receiving server. To retrieve images using the Print Server, the user performs the following acts: 
          At the Main Menu  500 , the user selects the File Management &amp; Utilities Menu  520  and starts the GIA Server if it is not already running.     From the Main Menu  500 , the user selects the Database containing the source images and one of the cycles containing images.     From the Main Menu  500 , select the Print Server option  535 . The Print Server Menu appears.     The Source Set Dates identify the range of processing dates to determine whether to retrieve an image for printing. If Source Set Dates are incorrect, the user changes the range.        

      The user sets the destination set name that corresponds to the database name. This name should be typed as it exists on the destination server or the execute print function will fail. 
          The user sets the destination cycle date. The user should have already created a cycle with this date on the destination server.     If the user wants to change the print export to a remote machine, then the user types the name of the remote machine. The user is then prompted to enter the name of the port on the host.     The user selects the MCF for MCF File Specification. The system provides a list of all existing Match IDs. The user selects one or all of the available Match IDs.     The user then selects the Execute option. Messages appear indicating the success of the process. Messages are posted to a log report as well. The user can use NetQuery to confirm that the images reached the cycle successfully. If the user runs this process again from a second range of cycles, the additional images will be added to the images already present in that cycle.        

      c. Overview of Image Print  
      Image Print produces account statements with both text and images in some embodiments of the invention. Image Print retrieves images that are predetermined by Image Match from the image database, processes them, blocks them on a page, and formats them for a particular laser printer with the appropriate header information. It then merges the images with statement text data in an output data stream to a designated printer and/or tape drive.  
      (i) Surrogates  
      If the user has defined surrogate images, they will be printed in place of any missing items during the Image Print process. Parameters for surrogate images may be defined using the Parameter Menu.  
      During the Image Print process, communications software controls the actual transmission of documents to the output device. The ability to format customer statements for output to a laser printer, and merge the statement text with the blocked images, is an important Image Print feature.  
      (ii) Different Statement Formats by Database  
      If the user wants to modify the format of statements by groups of account numbers, the user must place all image statements for a set of accounts in a single database and use the Parameter Menu to modify the format parameters. In addition, Image Print parameters provides the user with several options for increasing efficiency and controlling presentation of the final output.  
      Types of parameters the user can change by database include:  
      (a) Page Formatting  
      Arranges text information on statement and image pages. For images, the user can specify page size and margins, page numbering, duplex support, image placement, and image bordering. For text data, the user can specify font, print position, and include text lines on image pages. The user can add text such as serial number and amount on or under the images.  
      (b) Account Separator Images  
      The user can use Account Separator Images to separate multiple accounts associated with the same customer for consolidated printed statements. This is necessary when a customer (single customer number) has several accounts. The user can create up to 99 different line separators by using the Image Match line parameter. The line separator can be a simple as a horizontal line or it can be more elaborate.  
      (c) Statement Splitting  
      Splitting statement printing into batches is a very useful and timesaving function of Image Print. This function enables the user to specify how Image Print processes statement information for maximum efficiency.  
      (d) Good/Bad Split  
      Statements identified as having exceeded a user-specified ratio of missing or bad images can be processed into a separate file for further processing while good statements continue through the printing process unhampered. For example, the user can specify that each statement missing more than three individual images and/or more than 10 percent of total images is bad.  
      Good/bad splitting is executed from the Print Control Menu and is controlled by parameters specified in the default and/or override parameter file. If the specifications designated by the parameters are exceeded, the statements are processed as bad.  
      The user may find it beneficial to use the Good/Bad Split function even if he does not require the statements to be split. This Split function performs many of the same processes as Print, but in a fraction of the time. This provides a way to review for errors before running Print.  
      (e) Volume Split  
      Statements can be sorted into different print files according to their size (volume) as defined by the user in the parameters file. This enables the user to use printing and processing hardware in a more efficient manner. The user can direct large volume files, grouped for example by zip code, to special handling equipment or configure equipment in the fashion which best suits each type of printing session.  
      (f) Defining Output Segments  
      The document sets that are produced by Image Print can be grouped into output segments, so that one segment can be completed and begin printing while later document sets within the same job are still being formatted.  
      (g) Defining the Target Printer  
      Statements can be formatted for a variety of Xerox, IBM, and HP-PCL compatible printers. The target printer may have special parameter requirements.  
      Before running Image Print, the following conditions should exist:  
      Image Print parameters should be defined—Image Print parameters provide information for page formatting, headings, printer channel assignments, splitting routines, etc. As many sets of parameters can be maintained as are required to meet different processing requirements. For example, a banking institution may require one set of parameters for printing account statements and another for money market accounts. During the initial installation period, a trial and error approach to adjusting parameter specifications may be necessary in order to fine tune the statements&#39; final presentation.  
      All required images should be present in the image database—Image Match should have successfully run. All images which are referenced by the Match Control File (MCF) should have been added to the image database by Image Capture. The images remain in the same format in which they were received from the scanner in some embodiments of the invention.  
      The Print Control File should be loaded and ready for processing—For standard Image Print runs, the Print Control File (PCF) is built by the institution&#39;s account processing procedures. The PCF contains the body of the standard statement text and determines the accounts to be printed and their sequence.  
      Image Match processing for the proposed run should be complete—The Image Match process uses information contained in the user-produced Match Control File (MCF). The MCF is generated by the institution&#39;s account processing system and this information is then used for Image Print.  
      d. Printing Directly to HP or IBM Printers  
      Before printing statements, the user defines the print parameters (e.g., identifies page formatting, headings, etc.), defines the load parameters (e.g., identifies where the files are located, PCF exit program to use, etc.), and defines Capture, Match, and Archive Parameters. The Capture, Match, and Archive parameters determine scaling of images, levels of matching, etc. Additionally, the user obtains a Match Control File (MCF), obtains a Print Control File (PCF), and retrieves image objects from different cycles. To print directly to HP or IBM printers, the user performs the following acts: 
          From the Main Menu  500 , the user checks the Database/Cycle name.     Assuming the Database/Cycle name is correct, the user selects the File Load Menu. At the File Load Menu, the user loads the current file load parameters.     The user then selects an input media (e.g., tape, disk, etc.) The Current File Load Media toggles to the media type.     If the input device is tape, then the user loads the tape containing the file; and when the tape drive indicates it is “online,” the user types the input filename. While the file is loading, status messages display indicating if the file was found and if it was loaded successfully.     If the input device is Disk, the user enters the filename.     When the file is loaded, the user can run Image Match as discussed earlier to verify accuracy of the MCF.     After running Image Match, the user loads the Print Control File (PCF). The acts to load the PCF can be similar to the MCF.     From the Main Menu, the user selects the Print Control Menu. The user can run the “Good/Bad Split.” To do this, the user starts the Image Print process for the good items while researching any Missing Items. After correcting the missing items, the user runs Image Match again and prints the remaining “bad” image statements still marked as “bad” by the system. If the user runs Good/Bad split, the user is prompted whether to print all statements, only good statements, or only “bad” statements.     The user should type the letter of choice and press Enter. Statements are printed either to tape or to a specified printer depending on the configuration of the system. While Image Print is running, a processing status message displays on the system console that indicates the number of statements processed. When the Image Print process is complete, messages and processing statistics display on the system console. Press Enter to return to the Print Control Menu.        

      e. Printing to Tape  
      In addition to printing directly to HP or IBM Printers, the user can print to tape. The user first obtains the image objects, MCF and PCF as discussed in the previous section. The user then loads a blank tape into the tape drive. Typically, a minimum of two blank tapes, one for the index and one for the data is required. After loading the tape the user “prints” the information to the tape. When this process is complete, the user takes the data tape to the printer that the user uses for printing the statements. The user loads the tape into the print controller&#39;s tape drive. The user can then print the statements.  
      f. Direct Printing to Xerox HPIP  
      An HPIP server processes the print stream in a manner that replicates data as if it came from a tape. The EIMA includes an HPIP board and HPIP software in a workstation allowing the user to print directly to the printer at a faster speed. The user first obtains the image objects MCF and PCF as discussed earlier.  
      The user then performs the following acts to directly print to the HPIP as follows: 
          On the printer console, the user determines if the SDI (Shared Disk Interface) is already started. If it is not started, then the user starts it.     On the HPIP server, the user stops and starts the spooler as is known in the art.     Also at the HPIP server, the user starts the Print Manager by either clicking the printer icon in the lower-right of the screen or clicking on Control Panel and then clicking on Printers. The Xerox job window should open with an area to display the spooled jobs as they occur.     At the Main Menu  500 , the user confirms that the database and cycle are set correctly. The user then selects the Print Control Menu option and initiates printing. The files are then sent to the Print Manager on the PC, and, then, the PC sends the files to the Xerox console and statements are printed.        

      g. Generating a PCF  
      Using the Print Control File options in the Support Menu, the user can customize bank information and control printing of separator pages. The user performs the following acts to generate a PCF from the EIMA system  100  instead of loading a specific PCF from another system: 
          From the Main Menu  150 , the user selects the Support Menu option. In the Support Menu, the user selects the option for creating a Print Control File (PCF). The user can use standard separator pages. In addition, the user can create or change back information for the statements. The result is a PCF for printing statements. If the user wishes to print images statements via network transmission, this can be done via the Image Export Menu using a TCP/IP connection and BLAST software or using other suitable connections and software.        

      h. Miscellaneous Topics Relating to Printing  
      If the print jobs are large and taking up too much space on the hard drive of the workstations, the user may want to divide the jobs into segments.  
      Occasionally, individual statements may be damaged or lost after they have been distributed to customers. After processing images, some customers delete the images from the database. Deleting the images makes it impossible to recreate the run or perform restarts to reprint lost or damaged statements. Implementing an archiving procedure allows the user to access copies of the text and images required for statement reprinting.  
      Image Print provides a reprint utility that can be used to reprint statements which is archived to tape at the end of each Image Print run. Each run also creates an index that is saved to tape or disk depending on the selection in the parameters. The archive records are similar to the records written to the statement output file, except that each statement is preceded by a header record simplifying the statement identification.  
      The reprint capability enables the user to print a single statement or a range of statements from an index tape. To reprint statements, the user can reprint to a tape first and then print, or can reprint directly to the printer.  
      To reprint, the user performs the following steps: 
          From the Main Menu  500 , the user makes sure the database and cycle names are correct. The user then selects the Print Control Menu option.     The user then selects the reprint option. A UNIX text editor, vi, is loaded with the reprint request selection file. Other editors can be used as well.     The user then specifies the statements to be reprinted. Statement records must be referenced by a customer number. The user can enter as many lines in the request file as are necessary. Customer numbers should be entered in exactly the same format as in the original MCF. The user can print by customer number, print by logical ranges of customer numbers, or print a range of statements based on where they physically fall on the media.     The user then saves the file and is prompted to run Reprint. Assuming the user provides an affirmative response, the user enters a database and cycle name, and is prompted to load the index file or tape. As Reprint processes the request, the user is prompted for input tape numbers as produced by the print program. If the user is reprinting to tape, as each output tape is created, the user is prompted to switch the current tape with a scratch tape. After writing a scratch tape, the user is prompted to replace the input tape. If the user is reprinting directly to the printer, the user does not receive prompts for tapes. The output is sent to the printer.        

      10. Reports  
      a. Overview of Reports  
      To get information about specific activities in the EIMA system, there are several types of reports the user can run. Reports can be viewed onscreen or printed. The system uses a report browser in some embodiments. TABLE 4 below, provides a description of these reports.  
                   TABLE 4                       TYPE OF REPORT   DESCRIPTION                  Audit Reports   Audit reports provide logs of user activity and usage,           including capture data and query activity, in the EIMA           system. Audit reports can be filtered by a particular service.           Each record in an Audit report is preceded by an A.       Log Reports   Log reports show informational error and warning messages           that have been generated by EIMA services. Log reports can           be filtered by a particular service.           In log reports, the following characters appear before each log           record to indicate the type of log message:           I—Indicates that the log message is informational.           W—Indicates that the log record contains a warning.           E—Indicates that the log record contains an error message.       Match Statistics Report   Match statistic reports contain the following information           about a particular Image Match session: The total number of           processed images and statements; the total number of MCF           records read, matched and not matched; and the total number           of records written.       Free Items Report   Free item reports list the images in a particular batch that have           not been requested by the MCF. The report data is sorted by           time of capture.       Missing Items Report   Missing item reports show items that are present in the MCF           but that do not have corresponding images in the database.           The total number of unmatched records appears at the end of           the report.       Cycle Location Report   Cycle location reports list the repository location of cycles in           a particular database.       Optical Jukebox   Optical jukebox occupancy reports display information about       Occupancy Report   the optical jukebox&#39;s platters, slot and volume numbers, side,           and availability.       Tape Repository Reports   Tape repository reports contain information about cycles that           have been migrated to tape; how much space is available on a           specific tape volume; and the current status of tape devices.                  
 
      b. Overview of Audit Reports  
      Audit reports allow the user to find out information about user and system activity by a particular service. The example shown in  FIG. 11  shows a sample Audit Report  1100  that has been imported into an Excel spreadsheet.  
      With reference to  FIG. 11 , the type of report column  1105  contains the alpha code that indicates the report type. In this example, an A indicates that the record contains an audit-related message. The date column  1110  shows the date and time that the message was generated by the service. The source column  1115  lists the service that generated the message.  
      In Audit reports, the message column  1120  contains several fields of data, and a comma separates each field. The fields in the Message column vary depending on the service that generated the message and the activity that was logged. The six fields in TABLE 5, are found in most Audit report records.  
                       TABLE 5                       FIELD #/               POSITION   FIELD   DESCRIPTION                  1   &lt;hostname&gt;   The UNIX host server generating the log.       2   &lt;processname&gt;   The system process that was performed.               Examples of system processes are               Access Factory, Set Utils, Migration               Menu, and GIA-Session.       3   &lt;procpid&gt;   The process ID of the logging program.       4   &lt;date&gt;   The date that the process occurred.       5   &lt;time&gt;   The time that the process occurred.       6   &lt;logtype&gt;   The type of log entry. A log entry               describes the process that occurred.                  
 
      To generate an Audit Report, the user performs the following acts: 
          From the Main Menu  500 , the user selects the Report Menu option  540  thereby opening the Report Menu.     At the Report Menu, the user selects the option for preparing an Audit Report. The user then views the report in the Report Browser.        

      c. Filtered Audit Report  
      The Filtered Audit report allows the user to get information about user and system activity by a particular service or services. The user is able to select which services&#39; messages are included in the report. Information in the Audit report, of one embodiment, is listed by date, message source, and message.  
      To generate a filtered Audit Report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the option for a Filtered Audit Report.     A “Date range? (y/n)” prompt appears. At the “Date range? (y/n)” prompt, the user types y if he wants to specify that only data from a specific date range is included in the report. The user can specify that only data from a specific time period is shown in the Filtered Audit report. To limit the report data to a date range, the user types y and then presses Enter at the “Date range? (y/n)” prompt. At start and end date prompts, the user enters the start and end dates.     A Select Services Menu  1200  then appears ( FIG. 12 ). The Select Services Menu  1200  lists the services that the user can get specific audit information on in the report. The user selects the desired service. Multiple services can be selected. After finishing selections, the user selects the done option. The filtered Audit Report then displays in the Report Browser.        

      d. Overview of Log Reports  
      Log reports contain informational, error, and warning messages that have been generated by specific EIMA system services. In one embodiment, log report records are designated with the following alpha codes: I—Indicates that the message is informational; E—Indicates an error message; W—Indicates a warning message. These alpha codes appear at the beginning of each record in a log report. The Message field in a Log report record contains the actual message that the service generated.  
      The Log report lists informational messages that have been issued by services in the EIMA system  100 . Log report data is organized by date, the service that generated the message, and the log message.  
      To generate a Log report, the user performs the following acts: 
          From the Main Menu  500 , the user selects Report Menu  540 .     At the Report Menu, the user selects the option for generating a Log Report.        

      e. Filtered Log Report  
      The Filtered Log report lists informational messages that have been issued by a particular service or services in the EIMA system  100 . The user is able to select which services&#39; messages are included in the report. Filtered Log report data is organized by date, the service that generated the message, and the log message.  
      To generate a Filtered Log report, the user performs the following acts: 
          From the Main Menu  500 , the user selects Report Menu option  540 .     At the Report Menu, the user selects the options for a Filtered Log Report.     At a “Date range? (y/n)” prompt, the user types y if he wants to specify that only data from a specific date range is included in the report. At the start and end date prompts, the user enters the start and end dates in a year-month-date format. For example, if the user would like to see audit data for Jan. 1, 2001 through Jan. 3, 2001, he would enter 20010101 as the start date and 20010103 as the end date.        

      The Select Services Menu  1200  then appears. The Select Services Menu  1200  was discussed above. The user selects the desired service. Multiple services can be selected. After finishing selections, the user selects the done option. The Filtered Audit Report then displays in the Report Browser.  
      f. Warnings and Errors Log Report  
      The Warnings and Errors Log Report lists error and warning messages that have been issued by various services in the EIMA system  100 . Each record in the Warnings and Errors Log Report contains an entry for the date, the service that generated the message, and the actual warning or error message.  
      To generate a Warnings and Errors Log Report, the user performs the following acts: 
          From the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the option for generating a Warnings and Errors Log Report. The Error/Warning report displays in the Report Browser and the total number of records in the report is displayed above the report.        

      g. Filtered Warnings and Errors Log Report  
      The Filtered Warnings and Errors Log report lists error and warning messages that have been issued by a particular service or services in the EIMA system  100 . The user is able to select which services&#39; messages are included in the report. Each record in the Warnings and Errors Log report contains an entry for the date, the service that generated the message, and the actual warning or error message.  
      To generate a Filtered Warnings and Errors Log report, the user performs the following acts: 
          From the Main Menu  500 , the user selects Report Menu option  540 .     At the Report Menu, the user selects the options for a Filtered Warning and Errors Log Report.     A “Date range? (y/n)” prompt appears. At the “Date range? (y/n)” prompt, the user types y if he wants to specify that only data from a specific date range is included in the report. The user can specify that only data from a specific time period is shown in your Filtered Log report. At the start and end date prompts, the user enters the start and end dates.     The Select Services Menu  1200  then appears. The Select Services Menu  1200  was discussed above.     The user then selects the desired services. Multiple services can be selected. After finalizing selections, the user selects the done option. The Filtered Warnings and Errors Log Report then displays in the Report Browser.        

      h. Understanding the Message Data in an Audit Report  
      Records in an Audit report can contain a variety of log type values. The log type value indicates the activity that a service recorded. The log type value is listed as a Message field in Audit report records. TABLE 6, below, lists the log type values that can appear in Audit and Log reports.  
                   TABLE 6                           VALUE INDICATES THE           FOLLOWING ACTIVITY       LOG TYPE VALUE   OCCURRED:                  LOGIN   A user logged on to NetQuery.       LOGOUT   A user logged out of NetQuery.       CAPTURE   Items were captured from a scanner.       GIA_SESSION   An import session using the GIA server.       QUERY   Generates one entry for each query item.       DISPOSITION   Viewing, faxing, or printing in NetQuery.       TEXT_BATCH_QRY   A text file batch query was generated.       MIGRATION   Migration of images to storage           media devices.       VERIFICATION   Verification of image migration.       DELETION   Cycles were deleted.       SET_PASSWORD   A password was changed.       ADD_USER_GROUP   A user was assigned to a group           in the System Admin program.       ADD_GROUP_CAP   A capability was assigned in the           System Admin program.       DELETE_GROUP_CAP   A capability was deleted in the           System Admin program.       CREATE_USER   A new user ID was created in the           System Admin program.       DELETE_USER   A user ID was deleted in the           System Admin program.       CREATE_GROUP   A new group was created in the           System Admin program.       DELETE_USER_GROUP   A group was deleted from a           user in the System Admin program.       STORE_DOCUMENT   Text documents stored in archive.       STORE_STATEMENT   Account statements stored in archive.       DISTRIBUTE   Query results distributed to media           using Reconciled Export.       EXPORT   Export images to media using           Reconciled Export.                  
 
      i. Log Type Value Processes  
      In an Audit report, the fields following a log type value will vary depending on what log value is listed. To help understand the information in the Message column of a particular Audit report record, the following topics contain descriptions of the fields that follow a specific log type value. These topics are organized by the type of process associated with a particular log type value: Login/Logout, Capture Value, GIA_Session Value, NetQuery Log Type Values, Migration Log Values, Set_Password Value, System Admin Values, Store Values, Export Values, Distribute Log Type Values, Text_Batch Value  
      (i) Fields Following a Login or Logout Log Type Value  
      TABLE 7, below, provides a description of the fields that follow the Login or Logout log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 7                       FIELD #   FIELD   DESCRIPTION                  4   &lt;Date&gt;   The Date the Login or Logout occurred       5   &lt;Time&gt;   The Time the Login or Logout occurred       6   &lt;Log type&gt;   LOGIN and LOGOUT       7   &lt;Wrkst IP&gt;   The workstation IP address       8   &lt;Login ID&gt;   The LOGIN ID of the user who logged               in or out of the NetQuery or Image               Library Offline program        9-14   6 empty fields       15    &lt;Duration&gt;   Length of time in seconds the user               was connected. This field applies to items               with LOGOUT as the Log type.       16-19   4 empty fields       20    &lt;Outcome&gt;   SUCCEED or FAIL                  
 
      (ii) Fields Following a Capture Log Type Value  
      TABLE 8, below, provides a description of the fields that follow the Capture log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 8                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   CAPTURE        7   &lt;IP address&gt;   Workstation IP address used               to issue the command        8   &lt;Login ID&gt;   The name of the user who               opened the Capture session               on the UNIX host system        9-11   3 empty fields       12   &lt;#Images&gt;   Number of images captured               from scanner       13   &lt;# bytes&gt;   Number of bytes received       14-18   5 empty fields       19   &lt;Destination&gt;   The database name used for the capture       20   &lt;cycle&gt;   Cycle receiving the capture               images and data                  
 
      (a) Fields Following a GIA_Session Log Type Value  
      TABLE 9, below, provides a description of the fields that follow the GIA_SESSION log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 9                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   GIA_SESSION        7   &lt;Session Status&gt;   SESSION FAILURE, SESSION               CLOSE FAILED, REGULAR               FILE GENERATION FAILED,               or SESSION COMPLETED        8   &lt;set name&gt;   Database name receiving the images        9   &lt;Set date&gt;   Cycle receiving the images       10   &lt;class name&gt;   Indicates the type of images,               for example, checks       11   &lt;# of items&gt;   # of items imported. 1 item may               represent 2 images if fronts and               backs are imported       12   &lt;# bytes&gt;   # of bytes imported       13   &lt;# failed&gt;   # of items for which insertion failed       14   &lt;additional status&gt;   empty field or “INSERTS DISABLED       15-20   Empty fields                  
 
      (iii) Fields Following NetQuery Log Type Values  
      TABLE 10, below, provides a description of the fields that follow a Query log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 10                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   QUERY        7   &lt;Workstn IP&gt;   If the system uses fixed IP addresses               rather than recycling available IP addresses               as needed, the user can use this field to               identify the workstation that generated               the query.        8   &lt;Login ID&gt;   The Login ID of the user who               generated the query.        9-10   2 empty fields       11   &lt;Qryfile&gt;   The query name as posted from               Image Library. Typically the date and               time of the query.       12   &lt;# images&gt;   The number of images that resulted               from the query.               Note: The total number of images is               provided even if the user stops the query               before completion.       13-20   8 empty fields                  
 
      TABLE 11, below, provides a description of the fields that follow a Query log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas. The DISPOSITION log type value indicates query activity based on each item that is tagged and retrieved individually for display.  
                       TABLE 11                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   DISPOSITION        7   &lt;IP Address&gt;   IP address of the Image               Library workstation        8   &lt;Login ID&gt;   The Login ID of the user who               generated the query       9-17   9 empty fields       18   &lt;itemsize&gt;   Size of items sent from the query               server to the NetQuery workstation       19   &lt;Media type&gt;   UNKNOWN, DISK, OPTICAL, TAPE       20   &lt;Destination&gt;   The destination used for query results               at a NetQuery workstation is               typically DISPLAY                  
 
      (iv) Fields Following Migration Log Type Values  
      TABLE 12, below, provides a description of the fields that follow the MICRATION log type value in an Audit report record. Migration field values indicate that items have been migrated to a storage device. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 12                       FIELD#   FIELD   DESCRIPTION                   6   &lt;log type&gt;   MIGRATION        7   &lt;IP Address&gt;   IP address of the workstation               issuing the command        8   &lt;Login ID&gt;   User who is performing the               migration commands        9-10   2 empty fields       11   &lt;#Images&gt;   The number of images migrated       12   &lt;Type&gt;   This is set to “mig       13   &lt;# bytes&gt;   Number of bytes migrated       14-18   5 empty fields       19   &lt;source   Source media of images:           media&gt;   1 = DASD; 2 = optical; 3 = tape       20   &lt;Destination   Destination media of images:           media&gt;   1 = DASD; 2 = optical;               3 = tape       21   &lt;set name&gt;   Name of the set migrated       22   &lt;set date&gt;   Name of the cycle migrated                  
 
      The following fields indicate that verification of migration was performed. Please note that there are two verification log entries: one is used for the number of images verified and the other is used for verification error count. The only difference between the two is the use of the #Images field.  
                       TABLE 13                       FIELD#   FIELD   DESCRIPTION                   6   &lt;log type&gt;   VERIFICATION        7   &lt;IP Address&gt;   Workstation IP address used               to issue the command        8   &lt;Login ID&gt;   User ID that issued the command        9-10   2 empty fields       11   &lt;#Images&gt;   The number of images verified               or number in error       12   &lt;Type of   The first verification entry is set to           verification&gt;   “ver and reports the # of images               verified successfully, the second               line is set to “err and reports the               # of images with errors       13-14   2 empty fields       15   &lt;verify %&gt;   Percent of migration verified       16-18   3 empty fields       19   &lt;source   Source media of images:           media&gt;   1 = DASD; 2 = optical; 3 = tape       20   &lt;Destination   Destination media of images:           media&gt;   1 = DASD; 2 = optical; 3 = tape       21   &lt;set name&gt;   Name of the set verified       22   &lt;set date&gt;   Name of the cycle verified                  
 
      The DELETION log type value, below, indicates that a cycle has been deleted after migration and migration verification.  
                       TABLE 14                       FIELD#   FIELD   DESCRIPTION                   6   &lt;log type&gt;   DELETION        7   &lt;IP Address&gt;   Workstation IP address used to               issue the command        8   &lt;Login ID&gt;   The User that issued the command        9-18   10 empty           fields       19   &lt;source   Source media of images:           media&gt;   1 = DASD; 2 = optical; 3 = tape       20   empty field       21   &lt;set name&gt;   Name of the set deleted       22   &lt;set date&gt;   Name of the cycle deleted                  
 
      (v) Fields Following a Set_Password Log Type Value  
      TABLE 15, below, provides a description of the fields that follow the SET_PASSWORD log type value in an Audit report record. The SET_PASSWORD value indicates that a login password change occurred. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 15                       FIELD#   FIELD   DESCRIPTION                  6   &lt;Log type&gt;   SET_PASSWORD       7   &lt;IP Address&gt;   Shows if the password change was               generated from the System Administration               application; shows the password change               command comes from NetQuery; shows the               IP address of the UNIX server managing the               query server.       8   &lt;Login ID&gt;   User ID that issued the command               to change password       9   &lt;User ID&gt;   If a system administrator is changing               someone else&#39;s ID, this field shows the               User ID that received a new password. If               this field is blank, this field shows that               the Login ID in field 8 changed their               own password.                  
 
      (vi) Fields Following System Admin Log Type Values  
      TABLE 16, below, provides a description of the fields that follow the ADD_USER_GROUP log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 16                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   ADD_USER_GROUP       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;User ID&gt;   The UserID that received a new               group assignment       10   &lt;Group   The Group that this User ID has           Name&gt;   been assigned.                  
 
      TABLE 17, below, provides a description of the fields that follow the DELETE_USER_GROUP log type value.  
                       TABLE 17                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   DELETE_USER_GROUP       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;User ID&gt;   The UserID that had a previously               affiliated group deleted from it&#39;s               set of groups       10   &lt;Group   The Group that no longer includes this user.           Name&gt;                  
 
      TABLE 18, below, provides a description of the fields that follow the CREATE_USER log type value.  
                       TABLE 18                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   CREATE_USER       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   empty field       10   &lt;User ID&gt;   new User ID that was created       11   &lt;Max   Maximum Retention           Retention&gt;       12   &lt;Default   Default Retention           Retention&gt;       13   &lt;User Dept&gt;   User&#39;s Department       14   &lt;Page Print   Page Print Limit           Limit&gt;       15   &lt;Active&gt;   Whether the user is Active or               not. YES or NO       16   &lt;User   User Description           Description&gt;                  
 
      TABLE 19, below, provides a description of the fields that follow the DELETE_USER log type value.  
                       TABLE 19                       FIELD#   FIELD   DESCRIPTION                  6   &lt;Log type&gt;   DELETE_USER       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;User ID&gt;   User ID that was deleted                  
 
      TABLE 20, below, provides a description of the fields that follow the CHANGE_USERDEF log type value.  
                       TABLE 20                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   CHANGE_USERDEF       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;Sybase ID&gt;   Sybase User ID (numeric)       10   &lt;User ID&gt;   User Name that is being changed.       11   &lt;Max Retention&gt;   Maximum Retention       12   &lt;Default Retention&gt;   Default Retention       13   &lt;User Dept&gt;   User&#39;s Department       14   &lt;Page Print Limit&gt;   Page Print Limit       15   &lt;Active&gt;   Whether the user is Active or not.               YES or NO       16   &lt;User Description&gt;   User Description                  
 
      TABLE 21, below, provides a description of the fields that follow the CREATE_GROUP log type value.  
                       TABLE 21                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   CREATE_GROUP       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;Group Name&gt;   The new Group Name that was created       10   &lt;Group Description&gt;   Description of the Group.                  
 
      TABLE 22, below, provides a description of the fields that follow the ADD_GROUP_CAP log type value.  
                       TABLE 22                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   ADD_GROUP_CAP       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;Group Name&gt;   The Group that received a new capability       10   &lt;Capability&gt;   The Capability that was added to the group.                  
 
      TABLE 23, below, provides a description of the fields that follow the DELETE_GROUP_CAP log type value.  
                       TABLE 23                       FIELD#   FIELD   DESCRIPTION                                            6   &lt;Log type&gt;   DELETE_GROUP_CAP       7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.       8   &lt;Login ID&gt;   User ID that issued the command       9   &lt;Group Name&gt;   The Group that had a capability deleted       10   &lt;Capability&gt;   The Capability that was deleted from the group.                  
 
      (vii) Fields Following Store Log Type Values  
      These log type values indicate specific details about document and statement storage in the archive. TABLE 24, below, provides a description of the fields that follow the STORE_DOCUMENT log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 24                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   STORE_DOCUMENT        7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.        8   &lt;Login ID&gt;   User ID that issued the command        9-11   3 empty fields       12   &lt;# Documents&gt;   The number of documents stored.       13   &lt;# Bytes&gt;   # of bytes that were stored       14-20   7 empty fields       21   &lt;set name&gt;   Database name receiving the documents       22   &lt;cycle date&gt;   Cycle name that received the documents                  
 
      TABLE 25, below, provides a description of the fields that follow the STORE_STATEMENT log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 25                       FIELD#   FIELD   DESCRIPTION                   6   &lt;log type&gt;   STORE_STATEMENT        7   &lt;IP Address&gt;   Workstation IP address that issued               the command.        8   &lt;Login ID&gt;   Login ID of the user who issued the command.        9-11   3 empty fields       12   &lt;#Images&gt;   The number of statements stored.       13   &lt;# bytes&gt;   # of bytes of data stored.       14-20   7 empty fields       21   &lt;set name&gt;   Database name that received the statements       22   &lt;cycle date&gt;   Cycle name that received the statements                  
 
      (viii) Fields Following Export Log Type Values  
      TABLE 26, below, provides a description of the fields that follow the EXPORT_JOBDESTVOL log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas.  
                       TABLE 26                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   EXPORT_JOBDESTVOL        7   &lt;JobID&gt;   System assigned Job ID. (Numeric-8 digits)        8   &lt;Job Name&gt;   The name of the job as entered in Job Manager or via NetQuery.        9   &lt;Job Description&gt;   The description of the job as entered in Job Manager               or NetQuery.       10   &lt;Login ID&gt;   The name of the user who submitted the job.       11   &lt;Customer ID&gt;   The Customer ID who is receiving the export.       12   &lt;Job Type&gt;   The type of job which may be AUTOMATIC,               MANUAL, DEFERRED or UNKNOWN JOB               TYPE.       13-15   3 empty fields       16   &lt;Submit   The date and time the job was first submitted to the           DateTime&gt;   export server. For example May 11 1999 8:20 A.M.       17   empty field       18   &lt;img count&gt;   # of images exported       19   &lt;# bytes&gt;   # bytes       20   &lt;JobDestID&gt;   The job destination ID. (Numeric 8 digits)       21   &lt;Dest ID&gt;   Destination ID.       22-23   2 empty fields       24   &lt;DestState&gt;   Destination state may be: PENDING, READY,               EXECUTING, COMPLETED, STOPPED,               DEFERRED, RESOURCEWAIT, UNKNOWNJOB               STATE.       25   &lt;DestStatus&gt;   The destination status of a job may be               COMPLETED, STOPPED, FAILED,               EXECUTING, NOT STARTED, UNKNOWN               DEST STATUS       26   &lt;Media Type&gt;   General description of the output media. Media               types can include UNIX TAPE, UNIX PRINT,               UNIX FAX, REMOTE FAX, REMOTE PRINT,               REMOTE DISKETTE, REMOTE TAPE,               TRANSMIT, UNIX DISKETTE, CD-ROM or               UNKNOWN MEDIA TYPE.       27   &lt;Img Format&gt;   Image Format may be TIFF, PCL, PS, COF or RAW       28   &lt;Priority&gt;   Priority of the job (1 through 9)       29   &lt;CreateDBF&gt;   Whether the system should generate a DBF (index)               file on this media. TRUE or FALSE       30   &lt;CreateIDX&gt;   Whether an index should be generated. TRUE or               FALSE       31   &lt;CreateMICR&gt;   Whether or not MICR data should be generated.               TRUE or FALSE       32   &lt;# of copies&gt;   Number of copies to be made.       33   &lt;Img/per/page&gt;   For Fax or print, lists the images per page.       34   &lt;Fax Phone&gt;   The fax phone number       35   &lt;volcnt&gt;   Volume Count       36-37   2 empty fields       38   &lt;VolIndex&gt;   Volume Index (count starts at 1)       39   &lt;VolImgCnt&gt;   The number of images placed on the volume       40   &lt;VolByte   The number of bytes for that volume or fax.           Cnt&gt;                  
 
      (ix) Fields Following Distribute Log Type Values  
      TABLE 27, below, provides a description of the fields that follow the DISTRIBUTE log type value in an Audit report record. These fields appear after the log type value in the Message column. Field values are delimited by commas. The DISTRIBUTE value indicates that an export to a remote printer/fax was performed.  
                       TABLE 27                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log Type&gt;   DISTRIBUTE        7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.        8   &lt;Login ID&gt;   The name of the user who sent the request.        9   &lt;Cust ID&gt;   For an immediate request, the Customer               ID displays as USER —         10   &lt;Qryfile&gt;   The name of the query file.       11   empty field       12   &lt;# images&gt;   Number of images       13-15   3   empty fields       16   &lt;#pages/   For Print, the number of pages printed.           phone#&gt;   For Fax, the phone number               of the recipient.       17-19   3 empty fields       20   &lt;Destination&gt;   PRINT, FAX                  
 
      (x) Fields Following a Text_Batch Log Type Value  
      TABLE 28, below, provides a description of the fields that follow the TEXT_BATCH log type value in an Audit report record. The TEXT_BATCH log type indicates that a text file batch query job was exported. These fields appear after the log type value in the Message column. Field values are delimited by commas. The DISTRIBUTE value indicates that an export to a remote printer/fax was performed.  
                       TABLE 28                       FIELD#   FIELD   DESCRIPTION                   6   &lt;Log type&gt;   TEXT_BATCH        7   &lt;IP Address&gt;   Workstation IP address used to               issue the command.        8   &lt;login ID&gt;   The User ID that issued the command               at the Electronic Distribution menu to               process a Text file batch query.        9   &lt;CustID&gt;   Customer ID       10   &lt;Queryfile&gt;   Batch Query filename       11   &lt;QryID&gt;   If your TFBQ includes more than one               query, this field identifies the query               sequence number. For example, the               second query in a batch will have QryID = 2.       12   &lt;# Images&gt;   Number of images resulting from the query.       13-19   7 empty fields       20   &lt;Destination&gt;   The destination used for query results               of a TFBQ. For example, Print, Fax, Database,               CDROM, Diskette, and Tape.                  
 
      j. Image Match Reports  
      (i) Match Statistics Report  
      To view, print, or delete an Image Match report, the user performs the following acts: 
          From the Main Menu  500 , the user selects Report Menu  540 .        

      The user then selects the option for providing a Match Statistics Report. The information contained in the Match Database Statistics report is accumulated during processing. In one embodiment, this report provides run-specific information about the total number of images processed, the total number of statements processed, the total number of MCF records read, matched and not matched, and the total number of records written during the Image Match processing. The Match database statistics report contains the following information:  
                   TABLE 29                       ITEM   DESCRIPTION                  Regular fronts   Lists the total number of image items in the database.       Used fronts   Lists the total image items that have been matched.       Unused fronts   Lists the total number of image items that have not been matched.           These are referred to as free items.       Statements   Indicates the number of unique account numbers processed.       Processed       MCF Records read   Lists the total number of records in the MCF.       Dummy records   Indicates the number of synchronization records corresponding to           no-activity statements or one dummy record per statement. The           value in this field depends on the structure of the MCF.       MCF advertising   Lists the total number of records that have requested advertising       images   images.       MCF advertising   Indicates the total number of advertising images requested by the       images in error   MCF but not found in the database.       MCF records   Specifies the number of MCF records successfully matched to an       matched   item in the database.       Matched on   Indicates the total of images matched on account number, serial       Acct/Ser/Amt   number, and amount.       Matched on Acct/Ser   Indicates the total number of images matched on account and           serial number. The dollar amount did not match and could           contain blanks and/or zeros.       Matched on   Indicates the total number of images matched on account number       Acct/Amt without   and amount. No serial number was present in the MCF.       serial no.       Matched on   Indicates the total number of images matched on the account       Acct/Amt with serial   number and amount. A serial number was present in the MCF but       no.   no matching serial number was found in the MICR data.       MCF records not   Indicates the total number of MCF records for which there was no       matched   match in the database.       % Unmatched   Indicates the number of missing image items expressed as a           percentage of MCF records.       Records written   Specifies the number of records written to each output file.                  
 
      (ii) Free Items Report  
      The Free Items Report lists the images contained in a particular batch of a database cycle that have not been requested by the MCF. The report is sorted by time of capture. To view, print, or delete a Free Items Report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .        

      The user then selects the option for providing a Free Items Report. The report title can contain the date, time, database name, and cycle name. Following is a description of the Standard and Custom Free Items Report fields.  
                   TABLE 30                       ITEM   DESCRIPTION                  Match Status (A/U)   Indicates whether the unmatched record account number is in the           MCF. A indicates that the account number is in the MCF.           U indicates that the account number is not in the MCF.       Account Number-   If the report displays binary zeroes this means that the account       Account number   number could not be read and needs to be repaired using the           MICR Repair module.       Serial number   Serial number       Reference #   Reference number       Amount   Dollar amount.       TranCode   Transaction code       Routing   Transit routing number       Sort Code   Sort Code       Usage records read   Total number of Free Items read.       a - type usage records   Total number of unmatched records having an account number       selected   in the MCF.       u - type usage records   Total number of unmatched records not having an account       read   number in the MCF.                  
 
      (iii) Missing Items Report  
      The Missing Items Report lists any items that are present in the MCF but have no corresponding image in the database. The total number of unmatched records appears at the end of the report. To generate a Missing Items Report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .        

      The user then selects the option for a Missing Items Report. The report title can contain the date, time, database name, and cycle name. Following is a description of the Missing Items Report fields:  
                   TABLE 31                       ITEM   DESCRIPTION                  Comment   Specifies results of Good/Bad Split. Blank indicates that           Good/Bad Split was not run.       Customer Number   Customer number (account number) associated with the           unmatched item contained in the MCF.       Account Number   Account number associated with the unmatched item.       Trcode   Transaction code for the item.       Serial Number   Serial number associated with the item.       Serial Number   Reference number associated with the item.       Reference #       Routing   Routing information associated with the institution processing the           item.       Amount   Dollar amount associated with the unmatched item as found in the           MCF.       Sort Code   Sort code associated with the item.       Unmatched records   Total number of records present in the MCF for which no       read   matching items were found in the image database.                  
 
      k. Cycle &amp; Optical Reports  
      (i) Cycle Location Report  
      The Cycle Location report lists the current location of database cycles by repository. The report indicates if a cycle is located in one or more of the following repositories:  
                   TABLE 32                          Raid Repository   In the report, a “D” indicates that the cycle resides           on RAID.       Optical Repository   In the report, an “O” indicates that the cycle resides           on optical.       Tape Repository   In the report, a “T” indicates that the cycle resides           on tape.                  
 
      To generate a Cycle Location report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the Cycle Location Report option. At this point, the user has the option of viewing the report onscreen, sending the report to a UNIX printer or canceling the report. Upon selecting an option, the report is provided.        

      (ii) Optical Jukebox Occupancy Report  
      The user can generate an Optical Jukebox Occupancy report to get information about the data that has been migrated to optical. To generate an Optical Jukebox Occupancy report, the Optical Administration server should be running. The Optical Administration server and the Optical Repository server should not be running at the same time. The user should stop the Optical Repository Server and then start the Optical Administration server before running the Optical Jukebox Occupancy report.  
      To generate an Optical Jukebox Occupancy report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user then selects the option that generates the Optical Jukebox Occupancy Report. The Optical Jukebox Occupancy Report displays in the Report Browser.        

      l. Tape Repository Reports  
      (i) Overview of Tape Repository Reports  
      Tape Repository Reports allow the user to get specific information about tape devices and data that has been migrated to tape. The following tape reports can be run from the Report menu:  
                   TABLE 33                       REPORT   DESCRIPTION                  Tape Repository   Lists a history of database cycles that have been       Occupancy report   migrated to tape       Tape Repository   Provides the available space on a specific tape       Volume report   volume       Tape Repository   Shows the current status of tape devices       Drive Status report                  
 
      (ii) Tape Repository Occupancy Report  
      The Tape Repository Occupancy report provides a history of database cycles that have been migrated to tape. This report contains the following information:  
                   TABLE 34                       INFORMATION   DESCRIPTION                  Set   Lists the document type and database cycle that has           been migrated       Date Written   Shows the date (month-date-year format) that the           cycle was migrated to tape.       Volume   Lists the internal volume number of the tape that the           cycle has been migrated to.       Images   Lists the total number of images in the migrated cycle.                  
 
      To generate a Tape Repository Occupancy report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the option to create a Tape Repository Occupancy Report. The Tape Repository Occupancy report displays in the Report Browser.        

      (iii) Tape Repository Volume Report  
      The Tape Repository Volume Report shows the amount of available storage space on your tape volumes. This report contains the following information:  
                   TABLE 35                       INFORMATION   DESCRIPTION                  Volume   Lists the internal volume number of each tape volume.       Type   Shows the date (month-date-year format) that the cycle           was migrated to tape.       Status   Indicates if the tape volume is available for reading           or writing.       Available Space   Lists the available storage space in megabytes       (MB)   (MB) on the tape volume.                  
 
      To generate a Tape Repository Occupancy report, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the option to create a Tape Repository Volume report. The Tape Repository Volume report displays in the Report Browser.        

      (iv) Tape Repository Drive Status Report  
      The Tape Repository Drive Status report provides status information about tape storage devices. This report contains the following information:  
                   TABLE 36                       INFORMATION   DESCRIPTION                  Drive   Lists the drive that the tape storage device is           assigned to.       Host   The UNIX host server that the tape storage device is           mounted on.       Device   The path that the tape device resides in.       Device Type   Shows details about the tape storage device hardware.       Status   Indicates if the tape volume is available for reading           or writing.       Use   Lists if the tape device can be read or written to           (R = Read, W = Write).                  
 
      The user performs the following acts to generate a Tape Repository Drive Status report: 
          At the Main Menu  500 , the user selects the Report Menu option  540 .     At the Report Menu, the user selects the option to create a Tape Repository Drive Status Report. The Tape Repository Drive Status report displays in the Report Browser.        

      11. Tape Administration  
      a. Overview of Tape Administration  
      The Tape Administration menu contains options for managing tape volumes that contain Titan cycles, which have been migrated from RAID to tape. The Tape Administration menu includes tasks for verify tape drive availability, mount and unmount tape volumes, add and remove tape volumes to and from the tape silo, remove tape volume data, place a tape drive online or offline, and recover a failed tape drive.  
      While tape volumes are in the tape silo, users can query tape data through the NetQuery program. The tape silo&#39;s robotic arm transfers tapes into the tape drives as tape volumes are requested for migration and querying purposes. The number of tapes that can be stored in your tape silo depends on the make and model of the equipment.  
      b. Checking the Availability of a Tape Drive  
      The user can view the read/write capability of tape drives that are not currently in use by selecting the Check drive status option on the Tape Repository Administration Menu. The Drive Status report lists the following information about each available tape drive:  
                   TABLE 37                       INFORMATION   DESCRIPTION                  Drive   The directory location of the tape drive on the           UNIX system       Host   The computer that the tape device is connected to       Device   The filename and location of the tape drive&#39;s device           file       Device Type   The type of tape device       Status   The current activity of the tape drive; a tape drive may           be shown as Available, Writing or Reading       Use   The read/write permissions of a tape drive       Volume   If a tape is in the drive, this column shows the six-digit           volume ID assigned to the tape volume                  
 
      To generate an onscreen Drive Status report that displays tape drive availability, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Tape Administration Menu  545 .     At the Tape Repository Administration Menu  545 , the user selects the option for checking the Drive Status report option. The user can then note which tape drives are available.        

      c. Mounting a Tape Volume  
      Tape volumes should be mounted to make them accessible for reading or writing. The Mount option on the Tape Administration menu allows the user to instruct the tape silo to load a specific tape volume into a particular tape drive.  
      To mount a tape volume into a tape drive, the user performs the following acts: 
          At the Main Menu  500 , the user selects the Tape Administration Menu option  545 .     At the Tape Repository Administration Menu, the user selects the option for mounting a specific volume in a drive. A Drive Status Menu displays. The Drive Status menu lists the currently available tape drives. Only tape drives that are available for mounting are shown in this report.     The user selects the number of the drive that the user wants to mount. A prompt then displays for entering the number of the tape volume that the user wants to mount into the drive.        

      12. Optical Administration  
      a. Overview of Optical Administration  
      Optical Administration is used to transfer images and related database files to and from optical cartridges stored in a jukebox. This transfer is called “migration”, or most commonly “optical migration”. The Optical Administration application includes an Optical Migration procedure and Optical Administration procedure.  
      Optical Administration allows the user to migrate your data from: RAID to Optical, Optical to RAID, Optical to Optical, Optical to Tape, and Tape to Optical. Optical Administration Procedure allows the user to add and remove cartridges from the jukebox.  
      Each jukebox has its own Optical Administration database. Each jukebox has an assigned identifier (e.g., OR1, OR2, OR3, etc). Each jukebox&#39;s optical system uses three servers, which are listed below:  
                   TABLE 38                       SERVER   DESCRIPTION                  Optical Robotics   Should be running to perform optical services.       Server       Optical Repository   Used for viewing and migrating images stored       Server   on an optical disk.       Optical Administration   Used for importing and exporting cartridges       Server   from the jukebox.                  
 
      b. Optical Cartridges  
      The optical system supports two types of optical cartridges: reusable (Erasable Optical Cartridge) and write once, read many (WORM). The user uses the Erasable Optical Cartridges for data that he does not require permanently. Once the user no longer require that data on a reusable optical cartridge, he can erase it and reuse the cartridge. Alternatively, the user uses WORM cartridges when he requires a permanent record of the data. A Jukebox Occupancy Report is available to describe the contents of your system jukeboxes.  
      The following describes the optical storage process data flow for one embodiment: 
          Run ImageCapture and ImageMatch (or import the images using another method).     Copy the images from disk to optical cartridge.     Delete the images from the disk. If the user generates a query using NetQuery, and the user has previously migrated the images to optical cartridges, and if the cartridge containing the results of the query is located in the jukebox, then the system immediately sends the query results to NetQuery.        

      c. Other Applications  
      While Section 2B describes operating one embodiment of the EIMA system  100 , other methods of operation can be used as well. Additionally, the sections below describe other applications that are used by other embodiments of the invention.  
      D. System Administration  
      1. Introduction to System Administration  
      a. Overview of System Administration  
      System Administration is a utility that system administrators can use to control user access and activities in the EIMA system  100 . The administrator must have administrative rights to log on to System Administration.  
      When a user logs on to the EIMA system  100 , the system checks the user&#39;s password and capabilities and then grants access to programs based on the user&#39;s security level or capabilities. The system administrator is responsible for assigning capabilities to each group. Users cannot log on to the system until the system administrator has added the user account to System Administration.  
      The administrator can perform the following tasks in System Administration: 1) create and manage user accounts, 2) create and manage groups, 3) assign groups to users, 4) set group permissions, 5) create filters to control data access, 6) define weekends and holidays in the calendar, and 7) create decision-making windows.  
      The System Administration module in the embodiment described herein, utilizes a Java Plug-in.  
      b. System Requirements  
      The table below lists the hardware and software requirements of a workstation  115 , for one embodiment, that calls System Administration.  
                   TABLE 39                       COMPONENT   RECOMMENDATION                  Processor   Pentium II or better, 200 Mhz       Minimum Hard Drive Space   6-10 Megabytes       Recommended RAM   64 MB       Operating systems   Windows NT, Windows 95 and 98, Unix, Linux       Screen Resolution   800 × 600 pixels. For instructions on changing your           screen resolution, see Changing Your Screen Resolution.       Web Browser   Internet Explorer 5.5 or Netscape Navigator 4.7       Plug-ins   Java ™ 2 Runtime Environment, Standard Edition           including the Java ™ Plug-in download. For more           information about this plug-in, please read Overview of           the Java Plug-in.                  
 
      c. Running System Administration  
      The first time the administrator logs on to the EIMA Web site, the administrator will be prompted to download and install the Java Plug-in if it is not already installed on your computer. The Java Plug-in is required to run the System Administration applet.  
      To begin logging on to the EIMA system  100  (specifically the host server  110 ), the administrator enters the address of the EIMA Web site in the Address bar of the Web browser. After the login information has been authenticated, the administrator is able to access System Administration and any other EIMA applications for which the administrator has been granted permissions to use. The administrator must have administrator capabilities to use System Administration.  
      d. Overview of the System Administration Screen  
      After the user launches System Administration, the System Administration Main Screen  1300  ( FIG. 13 ) loads in the Web browser. For the embodiment shown, the System Administration screen is divided into two panes: the left pane  1305  and the right pane  1310 . A split bar  1315  separates these two panes. Of course, other arrangements are possible.  
      The currently selected option in the left pane  1305  controls the content of the right pane  1310 . The left pane  1305  contains five main menu items. Double-clicking a menu item in the left pane  1305  expands or collapses the options under the menu item. The following main menu items are available in the left pane:  
                   TABLE 40                       ITEM   DESCRIPTION                  User Admin   Contains options for listing and adding user accounts       Group Admin   Contains options for listing and adding groups       Query Filter   Contains options for listing and adding query filters       Admin       Calendar   Contains an option for setting the decision control       Admin   calendar       Decision   Contains options for setting decision-making time limits       Window   for exception items       Admin                  
 
      The right pane  1310  displays the tab or tabs for the selected option in the left pane. Clicking a menu item option changes the content of the right pane  1310 .  
      The split bar  1315  is the horizontal line that separates the left pane  1305  and the right pane  1310 . The administrator can adjust the size of the right and left panes by clicking-and-dragging the split bar to the right or left.  
      e. Java Plug-in  
      In one embodiment, System Administration is a Web-based Java applet that is embedded in HTML, although other architectures can be used as well. The System Administration applet runs in a Web browser and is part of the EIMA system Web page. To run System Administration, the Java Plug-in should be installed on the client workstation  115 .  
      2. Listing Users  
      a. Overview of Users  
      The administrator can view user accounts and their descriptions in the Users List. The User Name column contains the account name; the Description column provides more details about the account.  
      The administrator performs the following acts to display all user accounts: 
          If the User Admin options are not visible in the left pane, the administrator double-clicks User Admin. The User Admin menu expands.     The administrator clicks the List Users  1320  option. The User List is displayed in the right pane  1310 , as shown in  FIG. 30 .        

      A user is an individual who can log on to the EIMA Web site and perform specified activities in EIMA applications. Users with similar access rights are usually members of the same group; however, a user may belong to more than one group. Group membership designates the activities that a user can perform in the EIMA system.  
      b. Adding a User  
      The administrator can begin to add a new user by clicking the Add User option  1325  under User Admin in the left navigation pane. The administrator supplies the following information for each new user account: 1) name of the account, 2) description, 3) password, and 4) group assignment. To assign a group to a user, the administrator should have already added the group to System Administration.  
      The administrator performs the following acts to add a new user account to the EIMA system: 
          If the Add User option  1325  in the left pane is not visible, the administrator activates the User Admin option  1330 . The User Admin menu expands.     Under the User Admin menu, the administrator activates the Add User option  1325 . The User Information card  1400  displays in the right pane  1310 , as shown in  FIG. 14 .     In the User Name text box  1405 , the administrator types the full name of the user account. In the Password text box  1410 , the administrator types the password for the user account. In the Confirm Password text box  1415 , the administrator re-enters the same password that was entered earlier. In the Description text box  1420 , the user types a description for the user account.        

      The administrator selects the appropriate options as needed:  
                   TABLE 41                       OPTION   DESCRIPTION                  User Must   This option forces the user to change the account       Change   password the next time he or she logs on to the EIMA       Password at   system. By default, this option is already selected.       Next Logon       Account   This option deactivates the user account and does not       Disabled   allow the user to log on to System Administration.       Password   This option lifts the x-day mandatory password       Never   change option from the user account. The user will       Expires   not be required to change their password after x days.       User Cannot   This option prevents the user from changing the       Change   account password.       Password                  
          The administrator clicks the Groups tab. The Groups card displays (discussed below).     The administrator clicks a group in the left box, then click the Add button. The group is added to the right list box and the user account is assigned to the group.     The administrator clicks the “Go” button  1425 . The administrator can later modify the user account.        

      c. Printing a User List Report  
      The administrator can print a report that lists all the users and groups in the EIMA system  100 . The first part of the report contains a list of current users; the second part of the report lists group information. The following data is included in the report: user name and description, group names, and password and account status of each group.  
      The administrator performs the following steps to print a User List report: 
          If the User Admin options are not visible in the left pane  1305 , the administrator double-clicks User Admin  1330 . The User Admin menu expands.     The administrator activates the List Users option  1320 . The User List is displayed in the right pane  1310 .     Below the User List, the administrator clicks the Print User List button  1335 . The Print User List dialog box  1500  opens as shown in  FIG. 15 .        

      In the Print User List dialog box, the administrator modifies the following settings as needed.  
                   TABLE 42                       SECTION   DESCRIPTION                  Orientation   Select Portrait to print images across the short side       Section   of the page. Select Landscape to print images           across the long side of the page.       Margins   Click the Units down-arrow, then select a unit of       Section   measurement. Enter the desired margin sizes in the Left,           Right, Top and Bottom text boxes. Click the Resolution           down-arrow, then select 150, 300 or 600. Select the Print           margins option to print the margins on the page.       Text   Click the Font down-arrow, then select a font for the report.       Properties   Select the Size down-arrow, then select the font size       Section   for the report.                  
          In the Print User List dialog box, the administrator clicks the “Go” button  1505 . The report is printed.        

      d. Removing a User Account  
      The administrator can permanently delete a user account using System Administration. Deleting a user account prevents the user from logging on to the EIMA system. User accounts are deleted in the Users card.  
      The administrator performs the following acts to remove a user account using System Administration: 
          If the User Admin options are not visible in the left pane  1305 , the administrator double-clicks User Admin  1330 . The User Admin menu expands.     Under User Admin, the administrator activates the List User option  1320 . The User List displays in the right pane  1310 .     In the right pane  1310 , the administrator clicks the row that contains the user account to delete which highlights the row in the user table.     The administrator activates the Deleted Selected User button  1340 . The application deletes the user account and removes the row from the user table.        

      e. Changing a User Password  
      There are two ways to change a user&#39;s password. As the system administrator, she can change a user&#39;s password from the Users card. Users also can change their own passwords.  
      f. User Information Card  
      (i) Overview of the User Information Card  
      The User Information card  1400  is where user account information is entered and modified. The User Information card is comprised of the User and Group cards. The following table contains a description of the fields and options in the User card:  
                   TABLE 43                       FIELD OR           OPTION   DESCRIPTION                  User Name   Enter a descriptive name for the user account.       Text Box       Password   Enter the password that the user will use to log into the       Text Box   EIMA system.       Confirm   Re-enter the same password that was entered into the       Password   Password text box.       Text Box       Description   Enter a word or phrase that further describes the user       Text Box   account.       User Must   Select this option to force a user to change his or her       Change   password at next log on.       Password       at Next Login       Option       Account   Select this option to prevent a user from logging on to the       Disabled   EIMA system.       Option       Password   Select this option to allow a user to log on the EIMA       Never Expires   system with the same password for an unlimited       Option   period of time.       User Cannot   Select this option to prevent a user from changing his or       Change   her password.       Password       Option                  
 
      (ii) Overview of the Groups Card  
      The Groups card  1600  ( FIG. 16 ) is where the administrator assigns or unassigns a group or groups to a user account. The following table contains a description of the Groups card&#39;s fields and options:  
                   TABLE 44                       FIELD OR           OPTION   DESCRIPTION                  User Name   Displays the name of the user account that is currently       Field   open for editing.       Available   Contains a list of all groups in the EIMA system.       Groups   Depending on the number of existing groups, you may       List Box   need to scroll through the list to see more group names.       Add/   Clicking the Add button when a group is highlighted in the       Remove   Available Groups list box moves the group to the Selected       Buttons:   Groups List.           Clicking the Add All button moves all groups to the           Selected Groups List.           Clicking the Move button when a group is highlighted in           the Selected Groups list box moves the group to the           Available Groups list box, and unassigns the group.           Clicking the Move All button moves all groups in the           Selected Groups list box to the Available Groups list box.       Selected   Displays any groups that are currently assigned to the user.       Groups       List Box                  
 
      3. Group Administration  
      a. Overview of Groups  
      A group is a collection of users with common capabilities and limitations. Groups allow the administrator to control user access and activity in the EIMA system  100 . The Group Admin menu is located in the left pane  1305  and contains options for creating and managing groups. In one embodiment, the administrator can double-click Group Admin option  1335  to expand or collapse its options.  
      A group is made up of the following information:  
                   TABLE 45                       INFORMATION   DESCRIPTION                  Group name   Name assigned to a collection of users.       Description   Provides additional information about the group. This           field also appears in the Group List window.       Available Query   Sets the date range that group members can query       Date Range   document items.       Capabilities   Defines the activities group members can perform in           the EIMA system. Capabilities also control what           programs group members can access.       Databases   Lists the databases that group members can query.       Filters   Restricts the information that group members have           access to.       Users   User accounts assigned to the group.                  
 
      b. Overview of Capabilities  
      A capability restricts or permits the activities that members of a group can perform in the EIMA system  100 . Capabilities also control what applications a user can access. Capabilities are assigned at the group level.  
      There are several predefined capabilities available in the Capabilities card of the Group Information tabbed pane  1705  ( FIG. 17 ). Capabilities are assigned when the administrator creates or modifies a group.  
      The following table defines each of the predefined capabilities listed in the Capabilities card of the Group Information tabbed pane.  
                   TABLE 46                       CAPABILITY NAME   DESCRIPTION                  ADMINISTRATION   Can view and assign categories to groups in the           System Administration program.       CONFIGURATION   Can see and select the Configuration category.       DEFINE CALENDARS   Can define holiday and business days on the decision           calendar and open decision windows.       DEFINE DECISION   Can determine the amount of time for a decision       WINDOWS   window.       DEFINE GROUPS   Can create, change or delete groups.       DEFINE USERS   Can create, change or delete users.       EXPORT 8 MM TAPE   Can select a customer profile that exports images to           8 MM tape.       EXPORT CDROM   Can create a customer profile that exports images to a           CD-ROM.       EXPORT DAT   Can create a customer profile that exports images to           DAT tape.       EXPORT DATABASE   Can create a customer profile that exports images to a           new database/cycle.       EXPORT DISKETTE   Can create a customer profile that exports images to           diskette.       EXPORT DLT   Can export images to DLT tape.       EXPORT QIC TAPE   Can create a customer profile that exports images to           QIC tape.       EXPORT REMOTE FAX   Can create a customer profile that exports images to a           remote fax on the UNIX system.       EXPORT REMOTE PRINT   Can create a customer profile that exports images to a           remote printer on the UNIX system.       EXPORT SQUARE TAPE   Can create a customer profile that exports images to           square tape.       EXPORT TAPE   Can select a customer profile that exports images to           tape.       EXPORT TRANSMIT   Can create a customer profile that exports images to a           modem.       IMMEDIATE REMOTE FAX   Can submit fax job requests to the UNIX host system           and bypass the Electronic Distribution Menu.       IMMEDIATE REMOTE   Can submit print job requests to the UNIX host system       PRINTER   and bypass the Electronic Distribution Menu.       NETQUERY   Can access the NetQuery program and execute           queries.       QUERY   Grants access to the Query module. The QUERY           capability allows users to see and to select the Query           tab.       SHOW DATABASE   Can see and select databases from the Available           Databases and Assigned list boxes in NetQuery.       SUPERUSER   Can create, change or delete customer profiles and           also assign these profiles to any group. Users           assigned to the SuperUser capability have full viewing           and reading abilities on all databases and can export to           all media types.       SYSTEMADMINISTRATION   Can access the System Administration program.                  
 
      c. Adding a Group  
      The administrator can begin to add a new group by clicking the Add Groups option under Group Admin  1335 .  
      The administrator performs the following acts to add a new group to System Administration: 
          If the Group Admin options are not visible in the left pane, the administrator double-clicks Group Admin option  1335 . The Group Admin menu expands.     The administrator activates the Add Groups option. The Group control card  1700  displays in the right pane  1310  as shown in  FIG. 17 .     In the Group Name text box  1705 , the administrator types a name for the group. In the Description text box  1710 , the administrator types a description for the group. In the Available Query Date Range text box  1715 , the administrator types the number of days prior to the current date that he wants group members to be able to query the selected databases.     The administrator clicks the Users tab. The administrator activates a user account in the Available Users list box, then activates the Add button. The administrator can repeat as needed.     The administrator clicks the Documents tab. The administrator activates a document type in the Available Documents list box, then activates the Add button. The administrator can repeat as needed.     The administrator clicks the Databases tab. The administrator activates a database in the Available Databases box, then activates the Add button. The database is added to the Selected Databases list box. The administrator can repeat as needed.     The administrator clicks the Capabilities tab. The administrator activates a capability in the Available Capabilities list box, then activates the Add button. The administrator can repeat as needed.     The administrator clicks the “Go” button  1720 . The group is saved and displayed in the Group List. The administrator can later modify the Group.        

      d. Removing a Group  
      The administrator can delete a group from the EIMA system. The administrator performs the following steps to remove a group: 
          If the Group Admin options are not visible in the left navigation pane  1305 , the administrator double-clicks Group Admin  1335 . The Group Admin menu expands.     The administrator clicks the List Groups option. The Group List card  1800  ( FIG. 18 ) displays in the right pane  1310 .     In the right pane  1320 , the administrator activates the row that contains the group the administrator wants to delete. The group is highlighted in the group table.     The administrator activates the Delete Group button. The group is deleted.        

      e. Group Information Card  
      (i) Overview of the Group Information Card  
      The Group Information card  1720  is where group account information is entered and modified. The Group Information card contains the following cards: Group card, Users card, Documents card, Databases card, and Capabilities card.  
      (ii) Overview of the Group Control Card  
      The Group Control card  1700  is where the operator enters or views the name, description, and available query dates for a group account. The Group Control card  1700  is located in the Group Information card. The following table contains a description of the Group Control card&#39;s fields and options:  
                   TABLE 47                       FIELD OR OPTION   DESCRIPTION                  Group Name Text Box   Enter a descriptive name for the group account.       Description Text Box   Enter a word or phrase that further describes           the group.       Available Query Date   Enter the number of days prior to the current       Range (in days)   date that you want group members to be able to           query the selected databases. For example,           you would enter 10 in this text box if the           administrator wanted users in the group to only           have access to data that is dated 10 days           from the current day.                  
 
      (iii) Overview of the Users Card  
      The Users card is where the administrator assigns users to and remove users from a group, and is located in the Group Information card. The following table contains a description of the Users card&#39;s fields and options:  
                   TABLE 48                       FIELD OR           OPTION   DESCRIPTION                  Group Name   Displays the name of the group account that is currently       Text Box   open for editing.       Available   Contains a list of users in the EIMA system 100.       Users List       Box       Add/Remove   Clicking the Add button when a user is highlighted in the       Buttons   Available Users list moves the user to the Selected           Users list. Clicking the Add All button moves all users in           the Available Users list to the Selected Users list.           Clicking the Remove button when a user is highlighted           in the Selected Users list moves the user to the Available           Users list, unassigning the user from the group. Clicking           the Remove All button moves all users in the Selected           Users list to the Available Users list.       Selected   Displays users that are currently assigned or going to be       Users List   assigned to the group account.       Box                  
 
      (iv) Overview of the Documents Card  
      The Documents card is where the administrator assigns a document type to or remove a document type from a group. The Documents card is located in the Group Information card. The following table contains a description of the Documents card&#39;s fields and options:  
                   TABLE 49                       FIELD OR           OPTION   DESCRIPTION                  Group Name   Displays the name of the group account that is currently       Text Box   open for editing.       Available   Contains a list of all document types in the EIMA system.       Documents       List Box       Add/   Clicking the Add button when a document is highlighted in       Remove   the Available Documents list moves the document to the       Buttons   Selected Documents list. Clicking the Add All button           moves all documents in the Available Documents list to           the Selected Documents list. Clicking the Remove button           when a document is highlighted in the Selected Documents           list moves the document to the Available Documents list.           Clicking the Remove All button moves all documents in           the Selected Documents list to the Available Documents           list.       Selected   Displays all document types that are currently assigned or       Documents   are going to be assigned to a group account.       List Box                  
 
      (v) Overview of the Databases Card  
      The Databases card is where the administrator assigns a database to or remove a database from a group. The Databases card is located in the Group Information card. The following table contains a description of the Databases card&#39;s fields and options:  
                   TABLE 50                       FIELD           OR       OPTION   DESCRIPTION                  Group   Displays the name of the group account that is currently       Name   open for editing.       Text Box       Available   Contains a list of all the databases in your Titan system.       Databases       List Box       Add/   Clicking the Add button when a database is highlighted in the       Remove   Available Databases list moves the document to the Selected       Buttons   Databases list. Clicking the Add All button moves all           databases in the Available Databases list to the Selected           Databases list. Clicking the Remove button when a database           is highlighted in the Selected Databases list moves the           document to the Available Databases list. Clicking the           Remove All button moves all documents in the Selected           Databases list to the Available Databases list.       Selected   Displays all databases that are currently assigned or are going       Databases   to be assigned to a group account.       List Box                  
 
      (vi) Overview of the Capabilities Card  
      The Capabilities card is where the administrator assigns capabilities to or remove capabilities from a group. The Capabilities card is located in the Group Information panel. The following table contains a description of the Capabilities card&#39;s fields and options:  
                   TABLE 51                       FIELD OR           OPTION   DESCRIPTION                  Group Name   Displays the name of the group account that is currently       Text Box   open for editing.       Available   Contains a list of all the capabilities in your Titan system.       Capabilities       List Box       Add/Remove   Clicking the Add button when a capability is highlighted in       Buttons   the Available Capabilities list moves the capability to the           Selected Capabilities list. Clicking the Add All button           moves all capabilities in the Available Capabilities list to           the Selected Capabilities list. Clicking the Remove button           when a capability is highlighted in the Selected           Capabilities list moves the capability to the Available           Capabilities list. Clicking the Remove All button moves           all capabilities in the Selected Capabilities list to the           Available Capabilities list.       Selected   Displays all capabilities that are currently assigned or are       Capabilities   going to be assigned to a group account.       List Box                  
 
      4. Query Filter Admin  
      a. Overview of Query Filters  
      A query filter selectively screens a group of users from querying specific data in a database cycle. The administrator can use query filters to limit a group&#39;s ability to retrieve and view only items that meet the conditions of the filter. Query filters are assigned at the group and document type levels. The administrator can use query filters when it is appropriate to limit user access to just a portion of the document items in a database.  
      The administrator assigns the following items when creating a query filter:  
                   TABLE 52                       ITEM   DESCRIPTION                  Group   The query filter is applied to all databases that are           assigned to the group.       Document   The type of document the filter affects. The query filter is       type   applied to all databases that contain the document type.       Conditions   A set of restrictions that identify the documents a group           can retrieve or view.                  
 
      For example, the administrator may not want a user group to be able to view all document items in a check cycle. To prevent the user group from querying and retrieving every document in the cycle, the administrator can create a query filter that limits the group to retrieving only document items within a range of routing numbers. This filter will be applied to each database that is assigned to the user group and contains the same document type.  
      b. Overview of Query Filter Conditions  
      Query filter conditions define the query restrictions of a filter. A condition places a restriction that limits the values users can retrieve from a query field. A condition can be as simple as restricting a group from querying a range of account numbers or as complex as restricting a group from querying specific values in several query fields. The administrator can place several conditions in the same query filter.  
      Conditions are entered in the Filter Conditions card. Prior to setting query filter conditions, the operator should select the following items: the range of document items that you want to prevent the group from retrieving, the range of document items that you want the group to be able to retrieve, the query fields that will be affected by the conditions, and how the conditions will be constructed in the Filter Conditions grid. The administrator can use both comparison and logical operators to set field conditions. An operator is text that specifies what operation can be performed on the elements in a condition.  
      c. Overview of Comparison and Logical Operators  
      By using comparison and logical operators in query filter conditions, the administrator can restrict users from retrieving records that contain a particular query field value. Comparison and logical operators can be added to a query filter condition in the Filter Conditions grid.  
      A comparison operator compares two values and then returns an answer that is based on the result of the comparison. Comparison operators are available in the first column of the Filter Conditions table. Clicking a cell in this column opens a drop-down list of the following logical operators:  
                   TABLE 53                       OPERATOR   DESCRIPTION                  Equal   Retrieves records that contain an exact value in the current           field.       Greater Than   Retrieves records that are greater than a certain value in the           current field.       Less Than   Retrieves records that contain less than a certain value in           the current field.       Greater   Retrieves records containing values that are greater than or       Than or   equal to a certain value in the current field.       Equal       Less Than   Retrieves records containing values that are less than or       or Equal   equal to a certain value in the current field.       Not Equal   Retrieves records that do not equal a specified value for the           current field.       Like   Retrieves records that contain a string of values in the           current field.       Between   Retrieves records containing values that fall between a           range of values in a certain field. When the Between           operator is selected, the administrator needs to enter           a second value for the row in the Value2 cell. The           Value2 field is only active when the Between           operator is selected.                  
 
      A logical operator tests if a particular argument is true or false and then performs an action based on the result. Logical operators are available in the Operators column in the Filter Conditions table. The administrator uses the following logical operators in a filter condition:  
                   TABLE 54                       OPERATOR   DESCRIPTION                  OR   Use the OR operator to test if one or another argument       operator   is true and then return any matching records that           contain either arguments.       AND   Use the AND operator to test if all arguments are       operator   true and then receive matching records that           contain the argument.       NOT   Use the NOT operator to exclude an argument from       operator   your query results and then receive only those records           that do not contain the argument.       Parenthesis ( )   Use parenthesis to enclose a logical statement in           an advanced query.                  
 
      d. Displaying Query Filters  
      The administrator can view a list of existing query filters in the Query Filters card. The administrator performs the following acts to display the query filters list: 
          If the Query Filter Admin options are not visible in the left pane, the administrator double-clicks the Query Filter Admin option  1345 . The Query Filter Admin menu expands.     The administrator activates a List Filters option. The Query Filter List card displays in the right pane  1310 , as shown in  FIG. 19 .        

      e. Viewing Query Filter Information  
      The administrator can view existing query filters in the Filter Information card  1905 . The Filter Information card  1905  contains the Query Filters and Filter Conditions tabs. The Query Filter tab contains the following information: name and description of the query filter, and group and document type assignment.  
      The Filter Conditions tab contains the condition of the query filter. The administrator performs the following acts to view the settings for an existing query filter. 
          If the Query Filter Admin options are not visible in the left pane, the administrator double-clicks the Query Filter Admin option  1345 . The Query Filter Admin menu expands.     The administrator activates the List Filters option. The Query Filter List card  1905  displays in the right pane, as shown in  FIG. 19 .     The administrator activates the row that contains the desired query filter. The Filter Information card displays, as shown in  FIG. 20 . To view the description, group and document type fields, the administrator clicks the Query Filter tab. To view the query filter conditions, the administrator clicks the Filter Conditions tab.        

      f. Adding a Query Filter  
      The administrator can create a query filter to limit members of a group from querying and viewing certain documents. Query filters are added from the Query Filter List card. The administrator can set multiple conditions in the same query filter. The administrator performs the following acts to create a query filter: 
          If the options under the Query Filter Admin menu are not visible, the administrator double-clicks the Query Filter Admin  1345  in the left pane  1305 .     In the left pane  1305 , the administrator activates the Add Filter option. The Filter Information card opens in the right pane, as shown in  FIG. 20 .     In the Query Filter Name text box  2005 , the administrator enters a name for the query filter. In the Description text box, the administrator enters a description for the query filter.     The administrator activates the Group down-arrow, and selects the group to which he wants to assign the query filter.     The administrator activates the Document Type down-arrow, and selects the document type. The filter only applies to the document type that the administrator selects.     In the Filter Information card, the administrator clicks the Filter Conditions tab. The Filter Conditions card  200  opens, as shown in  FIG. 21 .     The administrator locates and scrolls to the query field that he wants to set a condition on. Next to this query field, he clicks in the Logical Operators column  2105 . A drop-down list of logical operators opens. The administrator selects a logical operator from the drop-down list.     The administrator enters an appropriate value in the Value1 cell  2120 .     If needed, the administrator enters an appropriate value in the Value2 cell  2125 .     The administrator can repeat the above acts as needed.     The administrator clicks the “Go” button  2130  and the query filter is created.        

      The administrator can change the definition of a query filter. The following query filter settings can be modified: description, group, document type, and conditions.  
      g. Query Filter Information Card  
      (i) Overview of the Query Filter Information Card  
      The Query Filter Information card  2000  is where query filter information and conditions are entered and modified. The Query Filter Information card  2000  includes the Query Filter and Filter Condition cards.  
      (ii) Overview of the Query Filter Card  
      The Query Filter card is where the administrator enters query filter settings. The following table contains a description of the fields in the Query Field card:  
                   TABLE 55                       FIELD OR           OPTION   DESCRIPTION                  Query Filter   Enter a descriptive name for the query filter.       Name       Text Box       Description   Enter a word or phrase that further describes the query       Text Box   filter.       Group   Click the Group down-arrow and then select a group       List Box   name. The query filter will be assigned to the selected           group.       Document   Click the Document Type down-arrow and then select a       Type   document type. The query filter will be applied to the       List Box   selected document type.                  
 
      (iii) Overview of the Filter Conditions Card  
      After setting up the name, description, group, and document type for a query filter, the administrator can define the filter&#39;s conditions. Filter conditions allow the administrator to restrict the document items that a group can query and view. Filter conditions are entered in the Filter Conditions grid.  
      A condition limits the values users can retrieve from a query field by specifying criteria on a particular query field in a table. Conditions are applied to any databases that are assigned to the selected group and contain the selected document type and query field.  
      The Filter Conditions grid contains the following columns:  
                   TABLE 56                       COLUMN   DESCRIPTION                  Op column   Clicking in this column opens a drop-down list of logical           operators.       FieldName   Contains the query fields on which you can set       column   conditions. The administrator can change the currently           displayed query field by clicking in this column and then           selecting a different field.       Operators   Contains comparison operators. Clicking in this column       column   opens a drop-down list of comparison operators.       Value 1 and   Enter the numerical or text values that restrict what query       Value2   field values the group can query.       columns                  
 
      5. Calendar Administration  
      a. Overview of the Decision Calendar  
      The decision calendar is an electronic calendar that is used to schedule a company&#39;s decision-making and non-decision making days in the EIMA system. The calendar works with decision windows to control when users can make decisions on positive pay products in the NetQuery program.  
      Decision windows rely on the electronic calendar&#39;s settings to determine decision and non-decision making days. The administrator defines the company&#39;s calendar year on the electronic decision calendar before creating a decision window.  
      The administrator does not need to set the decision calendar if an institution is not using NetQuery&#39;s positive pay module.  
      On the Decision Control Calendar  2200  ( FIG. 22 ), each square block (e.g. square  2205 ) designates a day of the month. Calendar days are highlighted white, green, blue or red. Of course other colors or indicators can be used. The color of a square indicates whether the day is a business day, holiday, Saturday or Sunday. The legend to the right of the calendar identifies what each color represents. In the embodiment described herein, the Table below defines each color.  
                           TABLE 57                                   COLOR   DESCRIPTION                          White   Business/decision-making days           Blue   Holiday/non-decision making days           Red   Saturday/non-decision making day           Green   Sunday/non-decision making day                      
 
      By default, the following days are scheduled as decision-making days on the calendar: Monday, Tuesday, Wednesday, Thursday, and Friday. The administrator can change the status of a day by activating its square on the calendar. Changes are applied to the current month by clicking the Modify Current Month Definition button  2210 . The administrator can reverse edits by clicking the Reset Calendar button  2215 .  
      By default, users are unable to make decisions on Saturdays, Sundays, and holidays. To allow users to make decisions on Saturdays, Sundays or holidays, the administrator should change the day&#39;s color to white.  
      6. Decision Window Administration  
      a. Overview of Decision Windows  
      A decision window defines the time frame that a group can make pay or no pay decisions on exception items in the NetQuery program. Decision windows allow the administrator to control the exact dates and times that a group can make decisions on positive pay items.  
      When the administrator creates a decision window, he will need to provide the following information: name and description of the decision window, group and document type assignment, conditions of the window (start and end times), and possible override conditions.  
      b. Listing Decision Windows  
      The administrator can view existing decision windows in the Decision Window List  2300  ( FIG. 23 ). The following information is shown: the name of the decision window, description, and the assigned document type and group. The administrator performs the following acts to display all decision windows: 
          If the List Decision Window option is not visible in the left pane, the administrator double-clicks the Decision Window Admin option  1350 . The Decision Window Admin menu expands.     The administrator activates the List Decision Window option. The Decision Window List  2300  is displayed in the right pane, as shown in  FIG. 23 .        

      c. Overview of Window Conditions  
      A window condition sets the duration of a decision window by defining the window&#39;s start and end times. The administrator enters window conditions in the Window Conditions card.  
      The following paragraphs define the fields in the Window Conditions card.  
      Start Delay Text Box  
      The administrator enters the number of days from today&#39;s date forward on which the administrator wants the decision window to go into effect. Entering “0” applies the decision window immediately (today). Weekends and holidays are not counted toward the start delay time.  
      Start Time Text Box  
      The start time determines the time that users can begin to make decisions on exception items in NetQuery. The administrator enters the exact time that he wants the decision window to be applied and then selects AM or PM from the drop-down list to the right of the field.  
      Days Open Text Box  
      The Days Open and Time Open text boxes work together to calculate the duration of a decision window. In the Days Open text box, the administrator enters the total number of days that he wants the decision window to last.  
      Time Open Text Box  
      If the administrator wants to extend the length of a decision window by a few or several hours, he enters the number of hours in the Time Open text box. This entry is based on a 24-hour clock.  
      Example Date Text Box  
      This text box defaults to the current date. This value is used to calculate the start date of the decision window in the Translation of Decision Window text box.  
      Translation of Decision Window Text Box  
      This text box is for viewing purposes. After entering values in the Window Condition section, the administrator has the option of clicking the “Go” button to display a summary of his decision window settings in the Translation of Decision Window text box. If there is an error in the summary, he can make the appropriate corrections.  
      d. Overview of Override Conditions  
      The administrator can “override” or “supersede” the conditions of a decision window by entering an exception time in the Override Condition section of the Window Conditions card. An override condition extends the decision-making time frame of a decision window.  
      The following paragraphs define the fields in the Override Condition section of the Window Conditions card.  
      Date Text Box  
      The administrator enters the date that he wants to be used to calculate the start date for the override.  
      Start Delay Text Box  
      The administrator enters the number of days forward from the date displayed in the Date text box on which you want the override to go into effect.  
      Start Time Text Box  
      The start time determines the time that the override condition begins. The administrator enters the exact time that he wants the override to be applied to the decision window and then select AM or PM from the drop-down list to the right of the field.  
      Days Open Text Box  
      The Days Open and Time Open text boxes work together to calculate the duration of the override condition. In the Days Open text box, the administrator enters the total number of days that he wants the override condition to last.  
      Time Open Text Box  
      If the administrator wants to extend the length of an override condition by a few or several hours, he enters the number of hours in the Time Open text box.  
      e. Creating a Decision Window  
      The administrator can begin to create a decision window by clicking the Add Decision Window option under Decision Window Admin in the left pane. The administrator should supply the following information for the decision window: name and description, group and document type assignment, window permissions, start date and duration of the window, and possible override conditions.  
      The operator performs the following acts to create a decision window: 
          If the Add Decision Window option in the left pane is not visible, the administrator double-clicks the Decision Window Admin option  1350 . The Decision Window Admin menu expands.     Under the Decision Window Admin menu, the administrator activates the Add Decision Window option. The Decision Window Information card  2400  displays in the right pane  1310 , as shown in  FIG. 24 .     In the Decision Window Name text box  2405 , the administrator enters a name for the decision window. In the Description text box  2410 , the administrator enters a brief description for the window.     The administrator clicks the Group down-arrow  2415  and selects a group assignment for the decision window.     The administrator clicks the Document Type down-arrow  2420  and selects a document type assignment for the decision window.        

      The administrator selects or deselects the following decision window options as needed:  
                   TABLE 58                       DECISION           WINDOW   DESCRIPTION                  Decision   When this option is selected, decisions can be made.       Allowed   When this option is not selected, decisions cannot be           made for this document type.       Specify   Select this option to establish a time limit for       Decision   decisions. When this option is not selected, decisions       Window   can be made continuously without a time restriction.                  
          The administrator clicks the Window Conditions tab. The Window Conditions card  2500  displays, as shown in  FIG. 25 .     In the Start Delay text box  2505 , the administrator enters the number of days from today on which he wants the decision window to go into effect. Enter “0” to apply the decision window immediately (today).        

      In the Start Time text box  2510 , the administrator enters the exact time that he wants the decision window to start. 
          In the Days Open text box  2515 , the administrator enters the total number of 24-hour days that the decision window should last. If this time is less than 24-hours, enter “0” and then enter the number of hours in the Time Open text box.     In the Time Open text box  2520 , the administrator enters an additional number of hours for the decision window to extend the decision window by a few or several hours. These hours are added to the number of days already entered in the Days Open text box.     In the Window Condition section, the administrator activates the “Go” button  2525 . The site displays a summary of the decision window conditions in the Translation of Decision Window text box  2530 . The administrator verifies that the text in the Translation of Decision Window text box  2530  is correct. If the translation is incorrect, the administrator returns to the appropriate text boxes and modify the values. If the administrator is satisfied with the decision window, he saves the decision window and displays the new window in the Decision Window List  2300 .        

      f. Overriding a Decision Window  
      The administrator can make exceptions to the duration of a decision window by entering override conditions in the Override Condition section of the Window Conditions card. The administrator should have already created or started creating a decision window. The Window Conditions card should be open. In the Override Condition section, the administrator performs the following acts to add override conditions to a decision window: 
          In the Date text box, the administrator enters the date that he wants to be used to calculate the start date for the override.     In the Start Delay text box, the administrator enters the number of days from the current date on which he wants the override to go into effect. Enter “0” to apply the override immediately (today).     In the Start Time text box, the administrator enters the start time for the override.     In the Days Open text box, the administrator enters the number of days that he wants the override to last.     In the Time Open text box, the administrator enters the additional number of hours that he wants the override to last.     In the Window Conditions card, the administrator clicks the Go button. Saves the changes to the decision window and displays the Decision Window List card.        

      g. Modifying a Decision Window  
      The administrator can edit the definition of an existing decision window. To begin editing a decision window, the administrator double-clicks the decision window row in the Decision Window List or clicks the decision window row and then click the Modify Decision Window button  2305 .  
      The operator performs the following acts to modify a decision window: 
          If the List Decision Window option is not visible in the left pane  1305 , the administrator double-clicks Decision Window Admin  1350 . The Decision Window Admin menu expands.     The administrator clicks the List Decision Window option. The Decision Window List  2300  displays in the right pane, as shown in  FIG. 23 .     The administrator clicks the row that contains the decision window he wants to modify. The row is selected.     The administrator clicks the Modify Decision Window button  2305 . The Decision Window Information card  2400  opens.     The administrator edits the text boxes that contain the values he wants to change.     The administrator can click the Window Conditions tab. The Window Conditions card  2500  opens.     The administrator can then edit the text boxes that contain the values he wants to change.     After modifying the decision window, the administrator clicks the “Go” button  2535 . The changes are saved to the decision window.        

      h. Decision Window Information Card  
      (i) Overview of the Decision Window Information Card  
      The Decision Window Information card is where decision window information and conditions are entered and modified. The Decision Window Information card is comprised of the Decision Window and Window Conditions cards.  
      (ii) Overview of the Decision Window Card  
      The Decision Window card is where the administrator enters or views the name, description, and other settings for a decision window. The Decision Window card is located in the Decision Window Information card. The following table contains a description of the fields and options in the Decision Window card:  
                   TABLE 59                       FIELD OR           OPTION   DESCRIPTION                  Decision   Enter a descriptive name for the decision window in the       Window   Decision Window Name text box.       Name       Text Box       Description   Enter a word or phrase that describes the decision window.       Text Box   Click the Group down arrow to view and then select the       Group Down   group that you want the decision window to be applied.       Arrow       Document   Click the Document Type down arrow to view and then       Type Down   select the document type that will be affected by the       Arrow   decision window.       Decision   Select this option to allow users in the selected group to       Allowed   make decisions on items in the document type. When       Option   this option is not selected, decisions cannot be made           for this document type.       Specify   Select this option to establish a time limit for decisions.       Decision   When this option is not selected, decisions can be       Window   made continuously without any time restrictions.       Option                  
 
      (iii) Overview of the Window Conditions Card  
      The Window Conditions card is where the administrator enters criteria settings for a decision window, and is located in the Decision Window Information card. The following table explains the fields and options in the Window Conditions card of the Window Conditions section:  
                   TABLE 60                       FIELD OR           OPTION   DESCRIPTION                  Start Delay   Enter the number of days forward that the administrator       Text Box   wants the decision window to go into effect. This           number will be added to the date that is displayed in the           Example Date text box. Enter “0” to have the decision           window applied on the same date that appears in the           Example Date text box.       Start Time   Enter the exact time that the administrator wants the       Text Box   decision window to start. Click the Start Time down-arrow           and then select AM or PM.       Days Open   Enter the total number of 24-hour days that the       Text Box   decision window should last. If this time is less than           24-hours, enter “0” and then enter the number of           hours in the Time Open text box.       Time Open   Enter the additional number of hours that the       Text Box   administrator wants to extend the decision window           by. These hours are added to the number of days           already entered in the Days Open text box.       Example   By default, the current date is displayed in this text       Date Text   box. Enter the date that the administrator wants       Box   to be used as the base start date for the decision window.       Translation   You can click the Save Record (e.g., Go) button.       of Decision   The Translation of Decision Window feature is       Window   provided to assist the administrator in determining       Text Box   if his window conditions are correct. If he finds           that the translation displayed in this text box is incorrect,           the administrator will review and then edit the appropriate           fields in the Window Condition section.                  
 
      The following table explains the fields and options in the Override Condition Section.  
                   TABLE 61                       FIELD OR           OPTION   DESCRIPTION                  Date Text   Enter the date that the administrator wants to be used to       Box   calculate the start date of the override.       Start Delay   Enter the number of days forward from the date       Text Box   displayed in the Date text box on which the administrator           wants the override to go into effect. Enter “0” to have           the override take effect on the same date that appears           in the Date text box.       Start Time   Enter the start time for the override.       Text Box       Days Open   Enter the number of days that the administrator wants the       Text Box   override to last.       Time Open   Enter the additional number of hours that the administrator       Text Box   wants the override to last.                  
 
      E. Repair Graphical User Interface (GUI)  
      1. Introduction to Repair GUI  
      a. Overview of Repair GUI  
      The functions of the Repair GUI are similar to the MICR Repair and Quality Monitor modules in that Repair GUI helps control the quality of the Image Capture process by allowing the user to view images as well as correct MICR field data. The Repair GUI may also be customized to meet specific needs.  
      The Repair GUI has two operating modes: Repair mode and Monitor mode. When the user logs into the Repair GUI, the user chooses whether to use its monitor or repair capabilities. The user enters the Repair mode to correct any scanning errors that corrupted MICR data. The user may also use it after the image matching (Image Match) process to correct free items. The fields that appear in the Repair GUI are defined by a system administrator.  
      During Image Capture, the user can enter Monitor mode to display samples of the images as they are scanned. If the user spots scanning errors, the scanner can be adjusted, enabling immediate correction.  
      b. Terminology  
      In general, UNIX menus refer to databases and cycles, while some PC applications (including Repair GUI) refer to set names and set dates. In general, the following terms are defined as below.  
                   TABLE 62                       TERM   DESCRIPTION                  Set Name (or just   A Database that has been matched (or entered).       Set)       Set Date   The Cycle of the Database that was matched.       Database   Usually refers to a superset (a container) for database files. In           Repair GUI it is the generic name given to a group of cycles, all           contained under the database name. It is analogous to a named           directory or folder, which contains a number of related files.       Cycle   Refers to a database file name, which is based on a date/cycle of           document scanning. Generally the cycle is the calendar-based date           the scan is run, and is incremented daily. The format varies, but is           usually of the form year-month-day. With this format a scan           database run on 3 Jan. 2000 will be the cycle value 20000103.           However, the specifics of the format and value will depend on           institution&#39;s requirements.       Free items   Are those items that were scanned into the cycle but not listed in the           Match Control File.       Match Control   Is a database file containing the information required to relate a       File (MCF)   scanned image to the MICR data for each scanned object.       Objects   Refers to scanned documents, such as checks. The term is also           applied to the database representation of these documents, both           image and MICR data.       MICR   Is the acronym abbreviation for magnetic ink character recognition.           Magnetic ink is used for printing on checks and similar documents,           thus recording information in a machine-readable format. In the           case of checks and some other documents it is often in a form that is           also readable to humans. Sometimes the magnetic ink becomes           smudged or otherwise damaged and the machine cannot read this           information reliably. In these cases the data representing the           scanned document (e.g. a check) is recorded (flagged) as in need of           repair. A human operator is then called on to determine the correct           information and enter that correct information using Repair GUI&#39;s           MICR Repair function (Repair).       Timeout value   Is the number of seconds that the Repair GUI will wait for a           response from the server before it prompts the user for a choice of           either canceling an action or continuing to wait on its completion.                  
 
      c. How Repair Works  
      Repair mode is used for correcting any scanning errors detected by Image Capture or Image Match. The corrections are made to the database index, which is where the data is stored. The database index contains the image location, MICR data, and any other data associated with the image. Repair is usually performed any time after Image Capture has detected faulty data or to correct free items remaining after Image Match.  
      During Image Capture, the scanner scans the items (documents, such as checks) and reads the MICR data. MICR data is the record of field values for a number of variables printed (in magnetic ink) in specific locations on the original document. Field values may include account numbers, check numbers and related data, depending on specifics of the documents recorded, and the customer requirements. The scanned digital images and associated MICR data are sent to the UNIX host, where Image Capture stores the images in an image database and records the image location and associated field value data in the database index.  
      Image Capture passes the data through a series of validations. Validation fails if there is one or more unreadable characters, a missing field, or the number of characters is incorrect. The data may fail validation because the scanner did not read it correctly. Situations that may result in unreadable data include: a document is fed at an angle into the camera area, labels are incorrectly placed, or the image has marks or scratches across the MICR data area.  
      If any of these situations should occur, it becomes necessary to fix the data contained in the database index file. The index is flagged for each image that has a detected problem.  
      During repair, each index item needing repair is displayed on the workstation one at a time. The operator enters the missing or corrected data. The scanned images themselves are not changed. Instead, the data stored in the database index is corrected.  
      2. Repair GUI/Host System  
      a. Starting and Killing the Repair Server  
      Before starting a Repair GUI session on the workstation, the user should first start the repair server. Starting the repair server was discussed earlier. After the user is finished with the Repair GUI session, the user kills (i.e., stops) the repair server.  
      3. Repair GUI/PC Module  
      a. Starting Repair GUI  
      The Repair GUI Repair mode can be used anytime after Image Capture identifies an item with duplicate or unreadable data. If the user needs to enter data for an empty field or to edit other data that the system has not tagged as needing repair, he creates a Repair Set while in Monitor mode. From the workstation, the user initiates Repair by performing the acts below: 
          Ensure that the PC workstation is powered on, Windows is running, and the repair server is started. The user then starts the Repair GUI.     Once the Repair GUI application is running, the user logs in. Two login branches are available at this point: Standard login, which assumes that the Host, Port number, and Timeout value, are already set and appropriate; and Advanced login, which permits changes to server, including Host, Port number, and/or Timeout value.     The user chooses a type of login and enters his User Name and Password. The Repair function is now active.     From the Main Menu, the user selects a Session/Get Set Names option. The Repair List window appears.     From the Repair List window, the user selects the SetName, SetDate and Batch ID he wishes to repair. The document type of each set is also displayed in this window. In this list the user is permitted to see only those sets the user group(s) that he belongs to as a Repair GUI user. The user groups are established by the system administrator.     After the user has made his selection of SetName, SetDate, and Batch ID, the images and editable data will appear.        

      b. Navigating Repair GUI  
      The Repair GUI main screen contains the image(s) and the image&#39;s respective associated field data. The user can cycle through the images and change field data by use of various image controls. The screen includes two image windows. The image displayed in the first window defaults to the object&#39;s front view. The image displayed in the second image window defaults to the back view. The user can force the image back view to appear in the first window, by selecting Options/Swap Image. The user may also specify a third image window.  
      The user can also enlarge and shrink the image windows and arrange them as desired by clicking and pulling on the window&#39;s borders. Further, the user can also click and drag the mouse to zoom in on a specific rectangular section of an image.  
      The user can browse through the images and further manipulate them by clicking on image manipulation buttons. The following table explains the navigational functions of the various buttons in the image windows:  
                   TABLE 63                           FUNCTIONAL       BUTTON NAME   DESCRIPTION OF BUTTON                  First Item button   Returns to and displays the first image           (and associated data) in the currently selected           set, cycle and batch.       Previous Item button   Displays the previous image (and           associated data).       Next Item button   Displays the next image (and associated           data).       Fit current image in   The user clicks this button after he has       window button   zoomed in and wishes to view the image           at normal size again.       Rotate Clockwise button   Rotates the current image 90 degrees           clockwise.       Rotate Counter-clockwise   Rotates the current image 90 degrees       button   counter-clockwise.       Mirror Horizontally   Mirrors the current image around the       button   horizontal axis.       Mirror Vertically button   Mirrors the current image around the           vertical axis.                  
 
      c. Creating Shortcuts  
      Repair GUI contains two separate types of keyboard shortcuts: Old Style Shortcuts and Stored Field Values shortcuts. Old Style Shortcuts are shortcuts that are set by the software. Stored Field Value shortcuts are created by the user.  
      Stored Field Value shortcuts are useful if the user uses certain fields that consistently contain the same values. Simple keystroke shortcuts allow the user to enter the field values he sets for each keyboard shortcut. For the embodiment described herein, the shortcuts involves pressing the &lt;CTRL&gt; key and a single-digit number. For instance, the user can define a stored field value so that when he hits &lt;CTRL&gt;+1, the field is filled with the pre-set Value.  
      To define Stored Field Value shortcuts, the user performs the following acts: 
          From the main menu, the user selects an Edit Stored Field Values option. The Stored Field Values dialog box appears.     In a Field column, the user enters a field number (1 through 0) to be associated with the keyboard shortcut. Field numbers correspond to the order the fields are listed on-screen. Therefore, if the user is attempting to set up a shortcut for the Account field, and this is the first field listed on-screen, then he would put a 1 in the Field column next to whatever shortcut he likes. It is recommended that the user uses &lt;CTRL&gt;+1 for the first field, &lt;CTRL&gt;+2 for the second field, etc. The zero in the Field column indicates the 10th field.     In the Value column on the right, the user enters the values he wishes to insert when he hits the respective shortcut keys. The values may contain numbers or letters and should be as long as the field in which they are going to be inserted.     The administrator clicks “OK” to accept the shortcuts, or clicks “Cancel” to reject them. These shortcut values are saved by the Repair GUI and remain until they are changed.        

      d. Repairing Items  
      After the user selects the repair set, he can resize the image by dragging the borders of the window. The user can also resize the Fields window so that the fields are more visible.  
      For each image, the user examines the field data in the information line and edit that data as needed. The user may define special characters that appear in place of unclear and missing characters using the parameters file that is associated with each database. For instance, the user might use an “!” to appear in place of unclear characters and an “M” in place of missing characters.  
      The user clicks the Update button to save changes and move to the next item. If the user is uncertain whether the item needs updating, the user can click “Skip” to move the current item to the end of the file. If an item does NOT need updating, the user clicks Update without making changes, so the item does not reappear.  
      If certain fields have been defined as “Mandatory”, the user will not be able to proceed if a Mandatory field contains no data. If the user clicks Update, the user will receive a warning message. (e.g., “This operation will permanently remove this item. Continue? You will be unable to proceed to the next item until you select either Yes or No.”)  
      The Fields window&#39;s title bar lists the errors contained in the current batch. When the user clicks the Update button, this number decreases.  
      When there is no longer a number in the title bar of the Fields window, the current batch has been totally repaired. Additionally, no images will appear on-screen.  
      e. Deleting Items  
      To delete the current image, along with its accompanying data, the user clicks the Delete button. Since this will permanently delete the item from the database, a confirmation request message appears. The item is removed from the database when the user confirms the request.  
      f. Customizing Repair GUI  
      Within repair GUI, the user has options to customize the application. These are available from the Options menu. These options are available for both Repair and Monitor modes. The following is a list of available options:  
                   TABLE 64                       OPTION   DESCRIPTION                  Login on Startup   Automatically causes the Login window to appear           after the user launches the application. Saves the extra           step of clicking the Login button.       Get Sessions   Automatically causes the Repair List window to       After Login   display after the user logs in, so he can immediately           choose a Set Name, Date and Batch.       Confirm   This will cause a dialogue box to appear, to confirm       Disconnect   that the user wants to exit the program.       on Exit       Auto GetFirst   If this option is selected, the first image is       on GetSession   automatically displayed after a set has been selected.           If this option is not selected, when a new cycle is           selected any image on-screen from the previous cycle           will remain on the screen until the First Item button is           clicked.       One Step   Main Menu/Option/One Step Cycle Selection is a       Cycle Selection   useful tool when the user has many cycles and           databases on the system. If the One Step Cycle           Selection is selected, then all database names, cycles,           and batch id&#39;s are displayed at once. If One Step           Cycle Selection is not selected, then only the database           names are listed. Select the database, and then all the           cycles for that database will be displayed. Next, select           a cycle, and all the batch id&#39;s display. Finally, select           the batch id the user wants.                  
 
      For the embodiment described herein, these preferences are automatically saved to the registry so that next time you run the application they will be loaded.  
      g. Available Options  
      The following table describes various options available in Repair GUI.  
                   TABLE 65                       MENU SELECTION/BUTTON   DESCRIPTION                  Session or Login Button   Log in to Repair GUI in either Repair or Monitor           mode.       Session or Select Repair Set   Select the Set Name, Date and Batch of images the       Button   user wishes to repair or monitor.       Session or Logout Button   Logs out of the current mode.       Session/Exit   Exits Repair GUI.       Options/Login on Startup   Automatically causes the Login window to appear           after you launch the application. Saves the user the           extra step of clicking the Login button.       Options/Get Sessions After   Automatically causes the Repair List window to       Login   display after you login, so the user can immediately           choose a Set, Name, Date and Batch.       Options/Confirm Disconnect on   This causes a dialogue box to appear confirming that       Exit   the user wants to exit the program.       Options/Reset Window Positions   If the images begin to display improperly because of           re-sizing of windows, select this option to correct the           problem.       Options or Set Timer Button   Set the delay before image updates in seconds.       Options/Swap Images   Swaps back and front of image in the current view.       Options/Auto GetFirst on   If this option is selected, the first image is       GetSession   automatically displayed after a set has been selected.       Options/Advanced/Create Repair   Marks a subset of items for repair. When this option       Set   is selected, the user can specify a search criterion that           will mark the appropriate fields for repair.       Options/Advanced/Delete Repair   Deselects the items marked by Create Repair Set.       Set       Options/Advanced/Class Groups   Enables the user to define groups of fields that appear           in the Repair GUI.       Options or Delete Button   Deletes image and data currently on-screen.       Options/Edit Stored Field Values   Allow the user to create shortcuts for fields that           repeatedly have the same data.       Options/Enable Old Style   When this is checked, the user can use &lt;Page Down&gt;       Shortcuts   to fill all the viewable fields with nines, or use &lt;Page           Up&gt; to blank out the current field.       First Image Button   First Image Button. Displays first image and           associated data in database.       Last Image Button   Displays last image and associated data in database.       Previous Image Button   Displays previous image and associated data in           database.       Next Image Button   Displays next image and associated data in database.       Scale to Fit Button   Fits image in current window. Used to display image           at normal size after zooming in on image.       Rotate Clockwise Button   Rotates image 90 degrees clockwise.       Rotate Counter-clockwise Button   Rotates image 90 degrees counter-clockwise.       Mirror Horizontally Button   Mirrors the current image around the horizontal axis.       Mirror Vertically Button   Mirrors the current image around the vertical axis.       Update Button   Click after correcting field data.       Skip Button   If field data is OK, click to skip to the next image in           database.                  
 
      4. Monitor Mode  
      a. Overview of Monitor Mode  
      Repair GUI&#39;s Monitor mode is used in conjunction with the UNIX-based Image Capture program to monitor the documents scanned into database files. This option helps to ensure the accuracy of the data. The user can compare the data recorded from the scanning operation to the data on the associated image. By doing spot checks the user can detect scanning errors or burned out scanner light bulbs, and reset the scanner if necessary.  
      There are two ways to use the monitor capability: while the items are being scanned and after items have been scanned into a database. The Repair GUI should not be started until after capture has begun. This is because the capture process creates the Batch ID that the Repair GUI needs in order to retrieve the images.  
      b. Initiating Image Capture  
      The operator performs the following acts to initiate Image Capture: 
          At the UNIX host system, from the Capture/Browse Images Menu, the user starts Image Capture. The user enters a database/cycle name for the group of images to be scanned.     At the PC workstation, the user selects the Repair GUI application.     Once Repair GUI is running, the user clicks the Login button. The Login window appears.     The user then enters the User Name and Password, and selects Monitor Mode. If the user wishes to change the server, he clicks the Advanced button and specify the Host, Port Number and the Timeout value.     The user clicks “OK” to finish the login.     At the main window, the user clicks the Select Repair Set button or select Session/Get Set Names. The Repair List window appears.     Highlight the SetName, SetDate and Batch to work with. This will be the same name as chosen in step  2  for the database cycle name.     The user clicks Select to continue and start the scanning operation.     The user views selected document images. During Image Capture, to view the images on the PC as they are scanned, the user clicks the Repair GUI buttons to change images as described above. The user can also set the timer to automatically update the images for spot checking image quality. The Repair GUI monitor then displays a sampling of the images after they are added to the database.     When the user has finished viewing images, he selects Session/Exit.        

      c. Setting the Timer  
      The Monitor mode timer can be set to display a new scanned image at intervals (integer seconds) controlled by the user. To set the timer, the user should already have selected a SetName, SetDate and Batch repair set. If the timer is set when the scanner is not running, then the same image will be refreshed, over and over as long as the button remains active.  
      d. Reviewing Previously Scanned Documents  
      The process is the same as for reviewing scanning images (Initiating Image Capture) except there is no need to start the scanner. Additionally, there is no need to set the timer since all the images have already been scanned. The user can use the navigation buttons to view the images.  
      In one embodiment, the Field portion of the screen is “greyed-out” when in Monitor mode (instead of having a “white background” as during Repair mode). This is to prevent the user from editing fields in Monitor Mode. Instead, the user is simply viewing the images and their associated data. If there is a need to edit field data, the user uses the Repair mode.  
      5. Repair Sets  
      a. Overview of Repair Sets  
      For the system described herein, there are two methods available for updating field data: Batch Update (discussed earlier), and Repair GUI. Repair GUI allows the user to create repair sets. Repair sets let the user mark a subset of items in a cycle for repair. The user creates the repair sets while in Monitor mode, but the repair sets the user creates are accessed and modified in Repair mode.  
      The repair set process works in much the same way as a query filter. The user may want to repair only images that have amounts between $100 and $500, for instance, or to repair images that have only a particular serial number (or series of serial numbers). If an item in a cycle fits the criteria defined for the repair set, it is “tagged” as having an error. The user can delete the repair set later, and subsequently “un-tag” the items.  
      b. Creating Repair Sets  
      The user performs the following acts to create a Repair Set: 
          The user logs into Monitor Mode and clicks on the Select Repair Set button to open the Repair List window.     The user clicks on a Set Name.     The user selects the Repair Set option to mark a subset of items for repair (thus creating a repair set). A Repair Items Criteria window appears, which displays a vertical column list of fields that are open for repair. The user can use that list of fields to filter the items to be repaired. The list contains three columns from left to right: Field, Operator, and Value.     To create a selection criteria expression for a repair set, the user double-clicks on one of the field names in the Field column. A window for that field appears to allow the user to create an item filter expression for the field.     The user selects an operator to use to filter items.     The user types a value into the blank box that appears to the right of the Operator selection buttons.        

      Operator definitions are provided below.  
                   TABLE 66                       OPERATOR   DEFINITION                  =   equal to       !=   not equal to       &lt;   less than       &gt;   greater than       =&lt;   less than or equal to       &gt;=   greater than or equal to                  
 
      If the user selects equal to (=) or not equal to (!=), a Range check box will appear, for specifying a range of values. To specify a range for the field, click the Range check box. The window is then enhanced with a pair of data entry windows, so the user can enter the minimum and maximum values in the spaces provided. For convenience, in the window space below the range values, the Amount window will display any previously entered ranges from which the user may select.  
      For example, if the user needs to create a repair set that includes all capture dates between January 1 and January 15 of the year 2000. In this example, the user selects the Operator=(equals) and clicks the Range check box that appears. When the user clicks the Range box, two unlabeled data entry windows will also appear. In the left data entry window the user enters 0000000020000101 (year 2000, 1St month, 1st day). In the right data entry window the user enters 0000000020000115 (year 2000, 1 st  month, 15 th  day). 
          The user clicks OK to return to the Repair Items Criteria window. Repeat the procedure for any other available fields, as needed.     When finished, the user clicks “OK”. Clicking “OK” starts the process that marks the applicable items for repair.        

      6. Class Groups  
      a. Overview of Class Groups  
      The Class Groups option enables the user to define the fields that appear for each document or image class in the system.  
      The user may classify fields as:  
                   TABLE 67                       FIELDS   DESCRIPTION                  Mandatory   The field must be filled and may not be left empty.       Optional   The field is available for edit, but the field may be left empty.       Read Only   Editing of the field is not permitted, but it may be viewed.                  
 
      Each user that is allowed to perform repairs must be assigned permission to do so through the use of class groups. The system administrator defines class group fields that certain user groups may view via the assigned class groups. The user can add and delete class groups. Inadequate class groups cannot be modified, only deleted and recreated (added).  
      b. Adding Class Groups  
      To give a user group permission to repair a class, the user performs the following acts: 
          From the main menu, the user selects the Class Groups option. A Classes window appears, listing all the classes defined in the database.     On the folder tree that appears, the user clicks on the “+” next to Classes to open the Classes folder. Locate under each specific class are the Fields for that class and any class Groups that have already been created. The user clicks a “+” or “−” to expand and contract the tree as needed. The defined Class Groups are listed under the Groups folder for each class. Each user group that can repair that document class is listed in the Groups folder. The Fields folder lists the fields that can be viewed for repair via Repair GUI.     To add a new group to a class, the user highlights the desired class and clicks the Add Group button. The Add Group for class xxxx window appears. Only the user groups that the user (as the Repair GUI user) are a member of will be listed in the User Group list box. If the user has something other than a class highlighted, he will receive an error message stating “You must select a class in order to add a group.”    In the Description field, the user enters a description of the class group that will appear in the tree under Groups.     The user uses the User Group list box to select the desired User Group.     For each category (e.g., Optional Editable Group Fields, Mandatory Editable Group Fields or Read Only Group Fields), the user selects the fields to be included by highlighting them in the Class Fields column and clicking the Add Fields button, to transfer them to the appropriate Group Fields column. If the user changes his mind about a field, the user clicks the Remove Fields button to transfer unwanted fields from the applicable Group Fields column back to the Class Fields column.     When finished, the user clicks “OK”.        

      F. Reconciliation  
      1. Overview of Reconciliation  
      Reconciliation provides for manual batch reconciliation of Free Items and matching Missing Items into the archive.  
      Free Items are images scanned during the capture process that the system is unable to match with any item from the Match Control File (MCF). The client site provides MCFs. The MCF is used to enable the system to link images and Magnetic Ink Character Recognition (MICR) data read from the images to the respective object&#39;s data that is stored in the MCF. The MCF theoretically should contain the correct information for every object captured.  
      Missing items are those items identified in the client-supplied Match Control File (MCF) that do not have identified object images (and MICR data) with which they can be matched. This usually occurs because the images captured have faulty MICR fields that the system could not read, or the matching image objects were not scanned in.  
      In one embodiment, reconciliation runs on the client using Java Runtime Environment (JRE), Java Advanced Imaging (JAI), and CORBA. Other environments are possible.  
      Reconciliation displays each Free Item, along with the most likely missing items from the Match Control File (MCF) for that batch. When a user chooses (and confirms) the Match Control File row that is appropriate for a free item, the data for the Free Item is modified to equal that Match Control File data. The application then marks that image as Matched and that image is immediately available for querying and other archive functions, such as export and statement print. In order for the Missing Item Report, Free Item Report, and Match Statistics to be updated, the user must also select the “Update Match Reports” option from the UNIX Match Menu.  
      2. Logging In  
      The user performs the following acts to login in the Reconciliation application: 
          The user launches the Reconciliation application. The Login screen displays.     The user types their user name and password. If the Reconciliation program capability has been assigned to the user name, then the user will be logged into Reconciliation successfully. The Batch Selection window displays.        

      3. Batch Selection Window  
      The Batch Selection window  2600  ( FIG. 26 ) provides access to three levels of nested folders. This is a hierarchical window, where the user can expand and contract the tree structure. A Database Icon contains one or more Cycle Icons, each of which contains one or more Batch Icons.  
      The user double clicks a Database Icon  2605  to display its available cycles. The user double clicks a Cycle Icon  2610  to display its available batches. The user double clicks a Batch Icon to reconcile that batch.  
      The information in parenthesis, located to the right of the batch ID number  2615  (0000 in the example in  FIG. 26 ), indicates the number of free items and missing items contained in that batch.  
      4. View Image Window  
      The View Image window  2700  ( FIG. 27 ) provides four main areas of information:  
                   TABLE 68                       AREA   DESCRIPTION                  Free and Missing   Indicates the number of free items that are       Items Remaining   remaining in the batch being reconciled, while       Area (2705)   reminding the user which database and cycle he is           working in.       Images (2710)   Provides front and back views of the document           being reconciled. Magnification of the image           within front and back windows is available by           clicking on the image and dragging. Magnification           controls are available in the right click menu, under           Options.       Free Item   Shows the MICR information at scan/capture time       MICR   for the document, while the questionable item (in       Information (2715)   this case ‘Serial’) is displayed on a background.       Missing Items   Provides a list of the missing items that are nearest       Table (2725)   matches to the doubtful value contained in the Free           Item MICR Information line.       Window   The View Image window also contains two sets of       Adjustment (2725)   image window adjustments. Clicking and dragging           sideways on the border between the two images           enlarges one image while reducing the other.           Clicking on the border under both images and           dragging it up or down allows the user to increase           or decrease the vertical size of both images.                  
 
      Clicking one of the arrows results in extreme movement of the image border in the direction of the arrow clicked. For example, if in the image above the user clicks the window adjustment arrow that points to the right, the border will move to the right edge of the application window, enlarging the front view of the check, while the back of the check will be hidden. To view only the back of the check, the user would click the left-pointing arrow.  
      Matching, deleting, skipping, options, and other controls are available through a “right click” menu. “Right click” anywhere on the screen to access this menu.  
      5. Options Dialog Window  
      An Options Dialog window is accessed by either “right clicking” on the View Image window. The Options Dialog window is made up of three tabs that allows the user to adjust the following qualities:  
                   TABLE 69                       QUALITY   DESCRIPTION                  Font   Used for setting Font type, size, and style for fonts used in           the Reconciliation application&#39;s View Image window.           This group of controls also includes a font preview window.       Magnifying   Used for setting the height and width of the magnifying       Glass   glass, and the magnifier&#39;s magnification level. This           group of controls also includes a preview window.       Image   Check boxes are used for independently setting whether           each front or back image displayed is displayed in a ‘fit to           window’ format (which can produce stretched images),           or ‘real view’ format, which may show only a portion           of the image at a time.                  
 
      6. Setting Font Options  
      The user performs the following acts to set the font options. 
          From the View Image window, the user “right clicks” his mouse anywhere on the View Image window. The Options Dialog window  2800  displays ( FIG. 28 ).     In the Name selection box  2805 , the user selects a font name. The result is shown in the Preview box  2810  at the top.     The user clicks and drags the Size slider  2815  to change the font size. The result is shown in the Preview box  2810 .     In the Style selection box  2820 , the user selects a style for the font. The result is shown in the Preview box  2810 .     The user then clicks the “OK” button  2825  when the font Name, Size and Style is properly set. The Options Dialog window  2800  closes, and the View Image window  2700  now is displayed using the font Name, Size and Style chosen.        

      7. Setting Magnifying Glass Options  
      The user performs the following acts to set the magnifying glass options: 
          From the View Image window the user “right clicks” his mouse anywhere on the View Image window  2700 . The Options Dialog window  2800  displays.     The user clicks the Magnifying Glass tab. The Magnifying Glass tab fully displays  2900  ( FIG. 29 ).     The user “clicks and drags” the Height slider  2905  to the magnification to use. The result is shown in the Preview box  2910  at the center.     The user “clicks and drags” the Width slider  2915  to the width of the magnifying glass to use. The result is shown in the Preview box  2910  at the center.     The user “clicks and drags” the Magnification Factor slider  2920  to the magnification level to use. The result is shown in the Preview box  2910  at the center.     The user then clicks the “OK” button  2925  when the font Height, Width and Magnification Factor is properly set. The Options Dialog window closes, and the magnifying glass now uses the height, width and magnification chosen.        

      8. Setting Image Controls  
      The user performs the following acts to set the image controls: 
          From the View Image window the user “right clicks” his mouse anywhere on the View Image window  2700 . The Options Dialog window  2800  displays.     The user clicks the Image tab near the top. The Image tab  3000  ( FIG. 30 ) fully displays.     The user clicks the Front checkbox  3005  to enable or disable Fit to Window Front Image.     The user clicks the Back checkbox  3010  to enable or disable Fit to Window Back Image.     The user clicks the “OK” button  3015  when the image options are set. The Options Dialog window  2800  closes, and the images are displayed with the settings you have chosen.        

      9. Matching Items  
      The user performs the following acts to match items: 
          The user launches the Reconciliation application. The Login window displays.     The user types in their user name and password, and presses the Enter key. The Batch Selection window  2600  displays.     The user clicks in the folder structure to select a single database name/cycle/batch. The Batch ID is highlighted, and shows the number of Free Items and Missing Items in that batch that need reconciling.     The user presses enter. The View Image window  2700  displays the first free item in the selected batch, and a list of entries in the MCF that most likely correspond to the free item. The field data that does not match the MCF entry is displayed in pink. Of course, a different color can be used.     The user uses the cursor (arrow) keys to scroll through the Missing Items Table  2720  until he has highlighted an entry that matches the image. As each entry is highlighted, any free item field data that does not match the selected MCF entry is highlighted in pink.     The user presses Enter and selects “match” from a popup menu. This will force a match between the selected MCF data and the free item image. A Match Configuration Dialog box displays for confirmation.     The user selects “yes” or “no”. If the user selects “Yes,” the next free item displays in the View Image window. If the user selects “No,” the display returns to the same Image window without having saved any changes.     If the user wants to skip the next image without matching, the user “right clicks” on the screen, and clicks Skip.     When finished reconciling, the user closes the application.        

      10. Deleting Free Items  
      The user performs the following acts to delete free items. 
          In the View Image window, the user “right clicks” anywhere on the screen. A Right Click menu displays  3100  ( FIG. 31 ).     The user selects Delete. The Delete Confirmation Dialog box displays.     The user confirms his request.        

      G. NetQuery  
      1. Introduction to NetQuery  
      a. Overview of the NetQuery Program  
      NetQuery is a Web-based program that allows a user to query and view document information and images in a Web browser, such as Internet Explorer or Netscape Navigator. The client side of the application uses Java Applets that is embedded in HTML. By entering the address of the EIMA system Web site in the Address bar of the Web browser, the user is able to log on to the Web site and then start NetQuery.  
      There are three main screens that make up the NetQuery applet: Query screen, Result screen, and Image screen. Queries are created in the Query screen, query results are displayed in the Result screen, and query documents are displayed in the Image screen.  
      b. System Requirements  
      Table 70 lists the hardware and software requirements for one embodiment of a workstation  115  utilizing NetQuery.  
                   TABLE 70                       COMPONENT   RECOMMENDATION                  Processor   400 Mhz Pentium II       Minimum Hard   6-10 MB of free hard disk space       Drive Space       Recommended    128 MB       RAM       Operating systems   Windows NT, Windows 95 and 98, Unix, Linux       Screen Resolution   800 × 600 pixels. For instructions on changing your           screen resolution, see Changing Your Screen           Resolution.       Colors   Over 256       Web Browser   Internet Explorer 5.5 or Netscape Navigator 4.08       Plug-ins   Java ™ 2 Runtime Environment, Standard Edition           including the Java ™ Plug-in download. For more           information about this plug-in, please read Overview           of the Java Plug-in.                  
 
      c. Using NetQuery for the First Time  
      The operator should log on to the EIMA system Web page before launching NetQuery. After the operator&#39;s login information has been authenticated, the operator has access to NetQuery and other programs that they have permission to use.  
      To log on to the EIMA Web site, the operator performs the following acts: 
          Open the Web browser at the client, and navigate to the Login page of the EIMA system. The EIMA system Login page is displayed in the Web browser.     At the Login screen, the user enters a user name and a user ID. Assuming the user is a valid user, the Java Plugin is downloaded and installed at the client and then the EIMA system home page  3200  is displayed in the Web browser as shown in  FIG. 32 .     On the Main Menu, the user selects the Query tab  3205 . The NetQuery hyperlink is loaded in the left pane  3210  of your Web browser for access by the user.     To end a session, the user can log out by clicking Logout  3215  on the menu panel. Logging out returns the user to the Login page.        

      d. Overview of the Java Plug-in  
      To run NetQuery, the Java Plug-in should be installed at the client. The Java Plug-in is part of the Java 2 Runtime Environment, Standard Edition download. The Java Plug-in is an accessory program that allows the client to run Java applets and JavaBeans components in Internet Explorer or Netscape Navigator.  
      2. Query Screen  
      a. Overview of Queries  
      A query is a request for document items in a particular database cycle. Queries are defined and executed from the Query screen. To retrieve specific document records, the user must set criteria for the query. Criteria is a set of limiting conditions that retrieves a specific set of records. The user can construct a simple or advanced query in the Query screen. A simple query allows the user to search for documents using a comparison operator. An advanced query allows the user to search for documents using both comparison and logical operators. The user can also set criteria on the same field multiple times. When the user executes a query, the query request is sent to the server. The server searches for records in the specified database(s) and then returns only those records that meet the criteria. Query results are displayed in the Results screen.  
      By default, the Query screen does not contain any information. The user creates the query by performing the following acts: 
          Selecting the document type for the query.     Selecting the database or databases.     Changing the default date range.     Typing query criteria in the Query Definition Grid.     Executing the query.        

      b. Overview of the Query Screen  
      The Query screen  3300  ( FIG. 33 ) opens after the user launches NetQuery from the main menu ( FIG. 32 ). The user creates, saves, opens, and executes queries from the Query screen. In this screen, the user can also print a copy of the current settings, access help about the program, and navigate to other query sets.  
      The upper portion  3305  of the Query screen is where the user selects the document type, database, and date range for a query. The lower portion of the Query screen contains the Query Definition Grid  3310 . Of course, different arrangements are possible.  
      Table 71 provides a description of the buttons in the Query screen.  
                   TABLE 71                       NAME   DESCRIPTION                  Open Query Button   Opens an existing query file.       Save Query   Saves a query.       Definition Button       Advanced Query   Changes the Query screen to Advanced Mode.       Style Button       Simple Query Style   Changes the Query screen to Simple Mode.       Button       Print Button   Prints a copy of the current settings in the Query screen. The           following fields are printed: name, query date range; query           style; document type; all fields in the Query Definition Grid; and           the assigned databases.       Reset Button   Returns the default settings to all the fields in the Query screen.           Clicking the Reset button clears your selections and criteria           entries.       Help Button   Opens a second browser window that contains information about           NetQuery.       Add Button   Moves the selected database(s) from the Available Databases list           box to the Selected Databases list box. Databases in the Selected           Databases list box will be queried.       Add All Button   Moves all databases in the Available Databases list box to the           Selected Databases list box. Databases in the Selected Databases           list box will be queried.       Remove Button   Moves the selected database or databases from the Selected           Databases list box to the Available list box. Databases in the           Available list box will not be queried.       Remove All Button   Moves all databases from the Selected Databases list box to the           Available Databases list box. Databases in the Available list box           will not be queried.       Calendar Button   Opens a calendar where you can select a date. This button is           located next to the From Date and To Date fields.       New Query Button   Creates a new query set. Clicking this button opens a new Query           screen.       Close Current   Closes the current Query screen without saving the query. This       Display Button   button appears greyed out when there is only one query set open.       Go Button   Executes the current query and retrieves query results. The           keyboard shortcut for this button is ALT + G.       Save Image Button   Saves currently displayed image to your local hard drive as a           GIF-formatted image file. A Save Image dialog box will be           displayed that permits you to select the location for the GIF file.                  
 
      These buttons or options are used to navigate between query sets.  
                           TABLE 72                                   NAME   DESCRIPTION                          View Query Screen Button   Switches to the Query screen from               the Result or Image screen.           View Result Screen Button   Switches to the Result screen from               the Query or Image screen.           View Image Screen Button   Switches to the Image screen from               the Query or Result screen.                      
 
      c. Overview of the Query Definition Grid  
      The Query Definition Grid  3310  is where the user establishes search criteria for a query. For the embodiment shown, the grid is located below the From Date and To Date text boxes in the Query screen. Each row in the Query Definition Grid contains a query field where the user can set up your search criteria. The Query Definition Grid contains the following columns:  
                   TABLE 73                       COLUMN   DESCRIPTION                  FieldName   Contains fields that can be queried       Operators   Contains a drop-down list of comparison operators       Value1 and Value2   Contains search values                  
 
      When the Query screen is in Advanced mode, an “Op” column appears in the Query Definition Grid. The “Op” column contains a drop-down list of logical operators. The user can set criteria on any field in the Query Definition Grid. Search criteria is set by selecting a comparison operator from the “Op” or Operators columns and then typing a search value in the Value1 and Value2 fields.  
      d. Overview of Comparison Operators  
      The user selects a comparison operator in the Query Definition Grid  3310 . A comparison operator compares two values and then returns a query result that is based on the outcome of the comparison. The following operators are available from the Operators column in the Query Definition Grid:  
                   TABLE 74                       OPERATOR   DESCRIPTION                  Equal   Retrieves records that contain an exact value in the current           field.       Greater Than   Retrieves records that are greater than a certain value in the           current field.       Less Than   Retrieves records that contain less than a certain value in           the current field.       Greater Than   Retrieves records that contain values that are greater than or       or Equal   equal to a certain value in the current field.       Less Than   Retrieves records that contain values that are less than or       or Equal   equal to a certain value in the current field.       Not Equal   Retrieves records that do not equal a specified value for the           current field.       Like   Retrieves records that contain a string of values in the           current field. For example, to locate all documents that           contain the “Mc” prefix in the Account Name field,           use the Like operator to search for these records by           typing Mc in the Value1 cell.       Between   Retrieves records that contain values falling between a           range of values in a certain field. When the Between           operator is selected, the user needs to type a second value           for the row in the Value2 cell. The Value2 field is only           active when the Between operator is selected.                  
 
      e. Changing the Mode of the Query Screen  
      The operator can switch the Query screen between Simple mode and Advanced mode. Simple mode is used to create basic queries and is the Query screen&#39;s default setting. Advanced mode is used to create complex queries that contain logical statements.  
      f. Creating a Basic Query  
      The user performs the following acts to define and then execute a basic query: 
          At the Query screen  3300 , the user clicks the Document Type down-arrow  3315 , and selects a document type. The availability of document types and databases are based on the user permission settings.     In the Available Databases list box  3320 , the user activates (e.g., click on with the pointer) the database that query is performed within, and then the database is added to the Assigned Databases list box. The user can select multiple databases.     To set a beginning or from date, the user clicks on the calendar button  3325  next to the From Date text box. A calendar then opens as a Java applet. The user then clicks a day on the calendar. The calendar closes and the date is inserted into the From Date text box.     To set an ending or to date, the user clicks the calendar button next to the To Date text box, and then clicks a day on the calendar. Alternatively, the user can also type the beginning and ending dates directly into the From Date and To Date text boxes. If the user does not select or type a date range, NetQuery will query all available dates in the selected databases.     Next, the user clicks the Equal cell next to the query field for which he wants to set criteria. By default, the Equal operator is assigned to all fields. The user selects a comparison operator from the drop-down list.     The user then clicks the query field&#39;s Value1 cell and then types an appropriate value. The user confirms the entry (e.g., by pressing Enter).     If needed, the user clicks in the query field&#39;s Value2 cell and then types a second value.     After the user is finished setting criteria, he clicks the “Go” button  3330 . The host executes the query and, then, opens and closes a Status message box, and displays the query results in the Results screen.        

      g. Querying Multiple Databases  
      The user can query several databases at the same time. In one embodiment, only databases that contain the currently selected document type are displayed in the Available Databases list box.  
      h. Saving a Query  
      Once the user has defined a query in the Query screen, the user can save the query settings to a file. Saving a query to a file enables the user to reuse the query definition in future queries.  
      i. Deleting a Query  
      The user can delete existing queries that have been saved under a group of which he is a member. Queries are deleted from an Open Query Definition dialog box.  
      j. Opening an Existing Query  
      The user can open an existing query file and then execute or modify the query as needed. Query file availability is based on group membership.  
      The user performs the following acts to open an existing query file in the Query screen: 
          First, the user clicks the Open Query button  3335 . The Open Query Definition Dialog box  3400  opens as shown in  FIG. 34 .     The user clicks the Group down-arrow  3405 . A drop-down list of groups opens.     The user then selects a group name. The group&#39;s queries are displayed in the Available Files list box  3410 .     Next, the user clicks a query file in the Available Files list box  3410 .     In the Open Query Definition dialog box, the user clicks the “Go” button  3415 . The query definition opens in the Query screen.        

      k. Printing a Query Definition  
      The user can print a copy of the current settings in the Query screen. In one embodiment, the following fields are printed: name of the query file, query mode—advanced or simple, document type, selected query databases, and the query&#39;s date range.  
      The user can adjust the print setup including the orientation (e.g., print images in portrait or landscape), set the margins, set the resolution, and set the text properties (font, size, etc.).  
      l. Overview of Advanced Queries  
      An advanced query is a request that contains one or more logical operators in its search criteria. The user can set search criteria on the same field multiple times in an advanced query. When the Query screen is set to Advanced mode, the Op column is available in the Query Definition Grid. Clicking a cell in the Op column opens a drop-down list of logical operators.  
      The user can select the following logical operators for an advanced query:  
                   TABLE 75                       OPERATOR   DESCRIPTION                  OR operator   Use the OR operator to test if one or another argument           is true and then return any matching records that           contain either arguments.       AND operator   Use the AND operator to test if all arguments are           true and then receive matching records that contain           the argument.       NOT operator   Use the NOT operator to exclude an argument           from your query results and then receive only those           records that do not contain the argument.       Parenthesis ( )   Use parenthesis to enclose a logical statement in           an advanced query. Parentheses affect the order that           statements in the Query Grid are executed.                  
 
      m. Examples of Advanced Queries  
       FIG. 35  shows an advanced query that uses the OR logical operator and the AND logical operator to search for records.  FIG. 36  shows an advanced query that contains four conditions which use the OR logical operator.  FIG. 37  shows an advanced query that contains the AND logical operator and uses parenthesis to enclose three OR statements.  
      n. Creating an Advanced Query  
      The user performs the following acts to define and then execute an advanced query: 
          If the logical operators column is not visible in the Query Definition Grid, the user clicks the Advanced mode button  3340 . The Query screen switches to Advanced mode.     At the Query screen, the user selects or types the appropriate options from the following fields as needed: document type, available databases, and From Date and To Date (all of which were discussed above).     In the Query Definition Grid, the user locates the field that he wants to set criteria for. The user clicks in the Operators column and selects a comparison operator.     Next, in the Value1 cell, the user enters a search value. If the user selects the Between operator in step  3 , the user enters a second value in the Value2 cell. The search criteria for the field is typed into the first row of the Query Definition Grid. This sets the search criteria for the first field.        

      The user can repeat the above step for additional search criteria. Upon entering the desired criteria, the user can click the Go button. The query is executed and then the query results are displayed in the Results screen.  
      3. Navigating Between Query Sets  
      a. Overview of Query Sets  
      A query set is inclusive of the Query, Result, and Image screens and contains the following information: query definition, result set, and image set. The user can have multiple query sets open in the same session. With reference to  FIG. 38 , the Query Set text box  3800  displays the number of the open query set, as well as the total number of query sets. The navigational buttons  3805  to the right and left of the Query Set text box allows the user to move between query sets. The Query Set text box  3800  and navigational buttons  3805  are located in the Query, Result, and Image screens. For example, if there are three query sets open, and the second query set is active, the Query Set text box  3800  displays “2 of 3.” 
      4. Result Screen  
      a. Overview of Query Results  
      Query results are the matching document records returned by a query. When the user executes a query, any records that match the search criteria of the query are displayed in the Result screen  3900  ( FIG. 39 ). In the Result screen  3900 , query results are organized into rows. The column labels at the top of each column identify the column data. Each row represents a record in the query results set and each row contains field data.  
      The user can perform the following actions on query results: tag items for viewing and print tagged items. The Tag column  3905  is used to select an item for viewing or printing. Query results are not returned in the following situations: there is no database selected, the user does not have permissions to query items in the selected date range, or there are no items that match the search criteria.  
      The user can perform the following tasks in the Results screen: view items in the results set, tag items, sort the results set, retrieve item images, navigate between query results sets, and print items.  
      b. Overview of Query Result Grid Menu  
      The user can “right click” on the results grid, to display the Results Screen menu  4000  ( FIG. 40 ). The menu has the following options:  
                   TABLE 76                       OPTION   DESCRIPTION                  Configure   Displays the Grid Configuration panel, which allows the       Query Results   user to configure the look and feel of the results grid.       Grid       Copy   Copies selected rows to the clipboard. This menu           option is available when contiguous rows are selected.           The grid supports multiple interval row selection, which           means that you can select a series of rows by dragging           the mouse or by pressing the CTRL key and clicking on           individual rows.       Tag Selected   Tags the selected rows. This menu option is available       Item (s)   when one or more rows are selected.       Untag   Untags selected rows. This menu option is available       Selected   when one or more rows are selected. This option will       Item (s)   not check if the row is tagged, it will untag the items           independent of its current tag.       Invert Tags   Inverts the tag state of the selected items. Therefore if       of Selected   an item is tagged, it will untag the item. The menu       Item (s)   option is available when one or more rows are selected.                  
 
      The table below provides a description of the fields and buttons in the Results screen.  
                   TABLE 77                       NAME   DESCRIPTION                  Document   The Document Type field displays the type of documents in       Type Field   the results set.       Navigational   Moves through pages of a results set.       Buttons       (Top of       Result       Screen)       Tag All   Selects all of the items in the result set. Click the button       Button/   again to deselect tagged items.       Untag       Button       Sort Button   Sorts the results in the set. Clicking this button opens the           Sort dialog box where you can change sort fields.       Remote   Prints or faxes tagged items to a remote printer or fax on       Print/Fax   the UNIX system.       Button       Print Button   Prints a copy of the tagged items in the Results screen to a           local network printer.       Reset Button   Returns the state of Tag column to its previous state.       Help Button   Opens a second browser window that contains information           about using the NetQuery program.       New Query   Starts a new query set. Clicking this button opens a new       Button   Query screen.       Stop   Interrupts the transfer of query images to your screen. Any       Retrieving   images that have been downloaded before clicking this       Results   button will be displayed in the Image screen.       Button       Close    Closes the current Result screen and returns to the Query       Current   screen.       Display       Button       Go Button   Executes an image query and displays images for tagged           items in the Image screen. The keyboard shortcut for this           button is ALT + G.       Status Bar   Displays the number of items returned in the results set.                  
 
      c. Tagging Items and Retrieving Images  
      After a query is executed, matching items are displayed in the Result screen. To view images, the user should tag any items that he wants to view. To tag an item, click in the checkbox next to the item. Tagging an item places a checkmark in the Tag column. After items have been tagged, the user is ready to submit an image query. An image query retrieves the documents for all tagged items and displays the images in the Image screen. The user should execute a query and receive query results before retrieving images.  
      d. Sorting Query Results  
      The user can change how items in the results set are sorted. The sort feature allows the user to organize items by a particular field or fields. A field can be sorted in ascending or descending order. Clicking the Sort button opens the Sort Result dialog box, where sort fields are selected. The user can sort using one or more fields (e.g., sort using a first field and then, sort using a second field). Different sort fields include, but is not limited to, Transit Routing, Account, Master Account, Serial, Transaction Code, Amount, Posting Date, DIN, Exception Code, and Decision Type.  
      e. Changing Column Order  
      For printing or viewing purposes, the user may want to change the order of columns in the Results screen. The user can rearrange columns by clicking-and-dragging a column label to a new position in the results list.  
      f. Printing Query Results to Local Printer  
      The user can print a list of the currently tagged items, and/or the items themselves. In one embodiment, the fields that print under the image are defined in a Sybase table user settings.  
      A Print Setup window  4100  ( FIG. 41 ) can be used to control the format of the hard copy. The window shown includes an orientation section  4105 , a text properties section  4110 , a logo section  4115 , a margins section  4120 , a print quality section  4130 , and an options section  4140 .  
      Additionally, field information can print under each image. The ‘number of image info lines’ parameter, defined in user settings, tells the system how many fields to print/fax under check images. If this parameter is not defined in user settings, then the default is 3. The fields the user chooses to be printed must be a subset of the items selected for the results list.  
      g. Viewing Multiple Query Results  
      If the user has several query sets open, he can switch between the open query results.  
      h. Navigating in the Result Screen  
      The navigational buttons at the top of the Result screen allow the user to move through the pages of query results for one query set. The navigational buttons at the lower-left corner of the Result screen allows the user to switch between query sets. Clicking one of these buttons displays the results of the selected query set. Of course, other locations for the buttons is possible.  
      5. Image Screen  
      a. Overview of the Image Screen  
      The Image screen  4200  ( FIG. 42 ) displays document images for any items the user has tagged. This screen  4200  opens after the user submits an image query from the Result screen  4000 .  
      The user can perform the following tasks in the Image screen: adjust image magnification, rotate images on the screen, invert or reverse image colors, print images to a local network printer or a remote printer on the UNIX system, view document information, access help about NetQuery, and navigate between query sets.  
      The table below provides a description of the buttons in the Image screen.  
                   TABLE 78                       NAME   DESCRIPTION                  Document Type Field   The Document Type field displays the type of documents           contained in the query set images.       Navigational Buttons   Use the Image navigational buttons at the top of the Image           screen to move between images in a query set.       Remote Print/Fax   Prints or faxes a document to a remote printer or fax on the       Button   UNIX system.       Print Button   Prints a copy of the currently displayed image to a local network           printer.       Add/Remove   Displays the Document Information window. This window is       Document   located at the bottom of the Image screen and displays the       Information Button   image&#39;s data field information. Use the Remove Document           Information button to close the Document Information window.       Reset Button   Reloads the current document in the Image screen.       Help Button   Opens a second browser window that contains information about           using the NetQuery program.       Zoom In Button   Increases the size of the current image in the Image screen.       Zoom Out Button   Decreases the size of the current image in the Image screen.       Zoom Box   To manually change the magnification of an image, double-click           in the Zoom box and then type a magnification percent.       Scale To Fit   Fits the entire width of the image in the Image screen.       Horizontally Button       Scale To Fit In   Fits the entire image in the Image screen.       Window Button       Previous Page Button   Displays the previous view of the current item.       Next Page Button   Displays the next view of the current item.       Rotate Left Button   Rotates the image left 90 degrees.       Rotate 180 Degrees   Rotates the image 180 degrees.       Button       Rotate Right Button   Rotates the image right 90 degrees.       Invert Button   Reverses the colors of the image.       Navigational Buttons   See Quick Guide to Navigational Buttons.       (Below the display       area.)       Cancel Button   Interrupts the transfer of images to your computer. Any images           that have been downloaded before you click this button will be           displayed in the Image screen.       New Query Button   Creates a new query set.       Close Current   Closes the Image screen and returns to the Result screen.       Display Button       Go Button   The Go button is greyed out and cannot be used in the Image           screen.                  
 
      b. Viewing Document Information  
      The user can view document information for images in the Image screen  4200 . The document information window  4205  contains the field data for the current image and is displayed in a separate window at the lower-end of the Image screen  4200 . The Document Information window  4205  contains two rows: The first row consists of field labels; the second row contains the corresponding field values for the image.  
      c. Navigating Between Images In a Query Set  
      The navigational buttons at the top of the Image screen allow the user to move between and display images in a query set. The Next Item button  4210  displays the next image in the query set. The Previous Item button  4215  displays the previous image in the query set. The Last Item button  4220  displays the last image in the query set. The First Item button  4225  displays the first image in the query set.  
      d. Changing the View of an Image  
      Most items or images are comprised of more than one view. For example, a check is made up of both a front view and a back view. Each view of an image is displayed on a separate page in the Image screen. The Next button displays the next view of the image. The Previous button returns to the previous view of the image.  
      6. Decision Support  
      a. Overview of Decision Support  
      Support adds the capability to NetQuery to manage pay/no pay, pay amounts, and other factors for documents with fields that trigger the capture program&#39;s Exception Code generator. Decision Support allows the user to access items with an Exception Code greater than zero, and change pay/no pay decisions. The user can then update the database using this changed information.  
      Index fields added to NetQuery, to accommodate Decision Support, include: Exception Codes, Decision_Type Codes, New_Pay_Amount, and New_Serial. These index fields are editable with Decision Support turned on, and in Image mode, where the user can see the document and the database information at the same time.  
      (i) Overview of Exception Codes  
      If an item matches any qualifiers, the item has an Exception Code of 1, or greater. Items that do not match any of the qualifiers have an Exception Code of 0. The user&#39;s policy may be that items will only be reviewed for payment decisions if the items match one of your qualifiers, such as high dollar amount, stale payment date, invalid signature, and/or endorsement missing.  
      b. Overview of Decision Type Codes  
      Decision Support provides a set of Decision Type codes to accommodate pay/no pay decisions. The number of codes can be expanded to provide for each institution&#39;s particular needs. Decision Type code values are available for editing when Decision Support is active, and the Image screen is displayed.  
      Standard check-related Decision Type codes are: pay, post dated, stale dated, pay w/new account, pay w/new serial, pay w/new amount, stop payment, endorsement irregular, signature irregular, check altered, and amounts differ. The user may have additional or different Decision Type codes available.  
      c. Using Decision Support  
      The user performs the following acts to use Decision Support: 
          The user logs in to NetQuery and click on the Query tab. The NetQuery and Decision Support buttons display in the left pane and the right pane will display the Query screen.     The user clicks on the Decision Support button.     From Available Databases, the user chooses one of more databases to be queried.     The user selects the query criteria and date range to be used in the query.     The user clicks the “Go” button. The Results screen will display, showing the results of the query. The Results screen will display the additional Decision Support Fields, but they will be blank and will not be accessible. Decision Support fields are accessible for editing in the Image screen, where the user can see the document image, and so have the information needed to make judgements.     The user “tags” items of interest and click the View Image Screen button.     The user clicks the “Go” button. After the Image screen appears, inspect the selected document and change the Decision Support fields as judgement requires.        

      Decision Support-specific fields include:  
                   TABLE 79                       FIELD   DESCRIPTION                  Exception_Code   Indicates a fault was detected for the item during           the image capture process. Exception Codes higher           than zero (0) indicate problems. The criticality of           the problem is indicated by the magnitude of the           number (up to 10) assigned to the Exception Code.       Decision_Type   Change the Decision Type field to indicate the           reason for altering the item&#39;s fields.       New_Pay_Amount   When the amount field is to be changed, type           the new pay amount into this field.       New_Serial   When the item&#39;s serial number was originally           recorded incorrectly, type the correct serial number           in this field.                  
          When finished, the user clicks the “Go” button. The decision support changes will update in the database.     The user “views” the changed information.     If required, the user can distribute the changed information by print or fax. The user can distribute the changed information by tagging desired items in the Results screen, and clicking the Remote Print/Fax button.        

      7. Manual Update  
      a. Overview of Manual Update  
      Manual Update allows simple manual adjustments to document MICR data.  
      When the user makes manual changes and then clicks the “Go” button, the database is updated with the changes the user has made.  
      b. Performing Manual Updates  
      The user performs the following acts to perform a manual update: 
          The user logs in to NetQuery and clicks the Query button. The Manual Update button displays, along with other purchased functions.     The user clicks the Manual Update button. The standard Query screen displays.     The user makes a query and tag items.     The user clicks the “Go” button. The images are retrieved, and displayed. The check data boxes are now editable. If the user double-clicks on a data box, it will be selected for editing. The user may select one or more characters individually using the text tool, which will replace the cursor when the user moves the cursor over the data box. The user can also double-click again to select the entire value.     When done, the user clicks the “Go” button. The changes you have made will be saved to the database. The changes will not be displayed unless the user runs a query again. The changes are made in the database, but the PC memory will not update until another query is run.        

      8. Grid Configuration Panel  
      a. Overview of Grid Configuration Panel  
      By “right clicking” the Query screen, Image screen, or the Result screen the user can access the Grid Configuration panel. The Grid Configuration panel allows the user to set the display factors discussed below for the specific display screen.  
                   TABLE 80                       OPTION   DESCRIPTION                  Header (Body)   This drop down control displays all the fonts that are       font name   available on the system. Some of the fonts that can not be           displayed (i.e. Windings, Symbol, Monotype, Marlett,           Outlook, Bookshelf) are automatically filtered. It is not           possible to screen all fonts that can not be displayed,           therefore it is possible that you will select a font that           won&#39;t work. If this occurs try a different font.       Header (Body)   The font size in points. Allowable sizes are 9 pt to 20 pt.       font size       Header (Body)   The font style. Available font styles are Plain, Italic, and       font style   Bold.       Colors   Pressing any of the buttons displays the Select a Color           dialog (shown below), which allows you to select the           desired color for the desired component.       Show Grid   Toggles the grid lines on or off. If Show Grid Lines is       Lines   off, both the Show Horizontal Lines and Show Vertical           Lines options will be disabled and no lines will be           displayed. If Show Grid Lines is on, both the Show           Horizontal Lines and Show Vertical Lines options           will be enabled, but only the line(s) selected           will display.       Cancel   Pressing the Cancel button cancels all changes.                  
 
      Clicking the “Go” button applies all your changes and saves all the parameters. When the font is changed, the width of all the columns is recalculated to be able to display the information. The only grid that may not be adjusted optimally is the Query Definition grid. This is because the grid is not allowed to grow beyond the bounds of the applet. All other grids are contained in a scroll pane and are allowed to grow past the edge of the applet.  
      H. Seal Verification  
      1. Overview  
      In another application, the object checks are encoded with a “secured seal” that contains specific information (e.g., check value, payee, date, check number, branch name, MICR information, etc.) about a check. When the check is presented at the bank for payment, the scanner includes an application that deciphers the “secured seal” to allow for verification that the check was properly issued and has not been altered. An example application for obtaining information from a seal or watermark is offered by Signum Technologies. In one specific embodiment, data is encoded and printed as a seal, watermark, diagram, picture, illustration, stamp, figure, or similar item (collectively referred to as a “seal”). Upon scanning the image, the application enlarges the seal and obtains the encoded data using a key. The application then decodes the obtained data.  
      In one embodiment, the obtained from the seal is imported into the host server  110  as an XML file along with the associated check image. A character recognition engine processes the check image by recognizing the payee and CAR amount of the check. The recognized results are then validated against the seal along with other check data passed by the scanner. The results are viewed via a document query application (e.g., NetQuery) and displayed in a standard report. Another embodiment  4900  is schematically shown in  FIG. 49 .  
      2. Import Utility Service  
      a. Description  
      The import utility service captures the document data and images into the EIMA system  100  for the recognition process. The import service essentially locates the document image files from the network accessible directory, places the document image files in a specified location for recognition, and inserts the corresponding document data into the database for processing. In one embodiment, the document data that is inserted into the database for processing contains the following information:  
                   TABLE 81                       INFORMATION   DESCRIPTION                  Document Key   This is an optional string value that is used to identify           the document on the source system.       Form ID   An integer value that is used to identify the Form           definition that is to be used during the recognition           process.       Image File   A string value that is the path and filename of the           TIF file for the specified document.       Zone data   For each field of data that is to be recognized from a           document, specific zone information is required.           The zone data includes: zone name, actual,           recognized       Zone Name   The name of the specific zone as specified in the           form definition. (Payee Name, $ Amount, Account           Number, Check Serial Number, Routing Number).       Actual   The actual value of the specific zone.       Recognized   The recognized value of the specific zone. This           value will be compared with the actual value for           data validation.                  
 
      b. Importing Objects.  
      To import the objects of interest, the user performs the following acts: 
          The user accesses the EIMA System web site and enters the import application.     The user enters his login ID and password. Assuming the information is correct, the application is provided to the user.     The user enters the server name that holds the desired database, and the database name where the document information is stored. The Import Process screen  4300  ( FIG. 43 ) is displayed.     The user then selects the XML source directory and the Tiff file source directory. The source and Tiff file directory are the network accessible directories where the image files and corresponding image data are located. The user then clicks the Start button  4305  to start the import process.        

      Once the import process is initialized, the application is in an “In Process” mode and the screen displays the XML filename, date and time of the import process and the number of documents that are being imported to EIMA system  100 . To stop the import process or clear the display, the user clicks the stop or clear list buttons  4305  or  4310 . When all the files have been imported to the database, the application continues to check the source directory and imports documents that are available from that directory. This window can be minimized so the import process application runs in the background.  
      c. Error Handling  
      (i) Invalid Form ID  
      An invalid form id error occurs when the form id in the XML file does not correspond to the form id defined in the application. When this happens, an error message is displayed. The user has the option to continue with the import process or stop the process. Selecting the former resumes the import process and the next document in the XML file is selected for processing. Selecting the latter stops the import process.  
      (ii) Image File Error  
      An image file error occurs when the image file (Tiff image and associated XML data) does not exist in the directory. When this happens, an error message is displayed. The user has the option to continue with the import process or stop the process. Selecting the former resumes the import process and the next document in the XML file is selected for processing. Selecting the latter stops the import process.  
      (iii) Database Transaction Error  
      Network failures, performance, or licensing issues are some incidents that can cause a database transaction error to occur. When this happens, the import application raises the specific error and the import process is halted. The user should fix the error before resuming the process.  
      3. Recognition  
      a. Description  
      The Recognition application processes the document images that are ready for recognition. In one embodiment, the application processes the images on a FIFO (First In First Out) basis. FIFO is determined by the order of the documents imported into the host system  110 . Character recognition is performed on the specified zones on a document and the necessary data is updated in the database.  
      b. Launching the Recognition Application. 
          The user accesses the EIMA System web site and launches the seal verification application.     The user enters his login ID and password. Assuming the information is correct, the application is provided to the user.     The user enters the server name that holds the desired database, and the database name where the document information is stored. The Recognition window is displayed.     The user clicks the start button to start the recognition process. The recognition application will continuously poll the database for images to recognize.        

      4. Document Query  
      a. Description  
      The document query application displays images and data for specific documents that have passed or failed the data validation process. Document records that have gone through the recognition process are marked as either pass or fail depending on the validation of the “recognized” and “actual” data values from the seal. Each specific document whether it passes or fails can be viewed in the document query application for a limited period of time (e.g., 15 days prior to the current date).  
      b. Launching the Document Query Application  
      To launch the document query application, the user performs the following acts: 
          The user accesses the EIMA System web site and enters the Document Query application.     The user enters his login ID and password. Assuming the information is correct, the application is provided to the user.     The user enters the server name that holds the desired database, and the database name where the document information is stored. A query parameters screen is displayed.     The user enters the start and end dates for querying the document records. The account number, which is optional, can also be entered if the user wants to query a specific document. Checking the query exception box will only display items that have failed the validation process.     The user clicks the “Run Query” button  4405 . A first image of a check along with the recognized and seal value results are displayed for review.        

      c. Use of “Hot” Keys  
      Each toolbar on the Query Viewer screen  4500  ( FIG. 45 ) is associated with a “hot” key of the user keyboard. The user uses the hot key to review the document. Of course other keys or other methods can be used to perform the specialized tasks below.  
                   TABLE 82                       KEY   DESCRIPTION                  Previous or next   Allows the user to cycle through the previous or next       arrow (F1 &amp; F2   document record.       respectively)       Print (F3)   Prints the current page or selected pages.       Rotate (F4)   Rotates the check image clockwise.       Zoom In (F5)   Magnifies the check image.       Zoom Out (F6)   Minimizes the check image.       New Query (F7)   Enables user to perform a new query.       Tab   Use your tab key to tab through each of the fields in           the document. As you tab through a field, that area on           the check image will be highlighted.                  
 
      5. Error Viewer  
      a. Description  
      The Error Viewer application contains document record(s) resulting from a recognition error. A recognition error occurs when an image that is corrupted or does not exist in the directory is introduced in the host system  110 . When this happens, the document record is flagged and routed to the error viewer application. The user cannot make any corrections or modifications to the document data but can only save or mark the document record for deletion.  
      6. Launching the Error Viewer Application  
      To launch the Error Viewer application, the user performs the following acts: 
          The user accesses the EIMA System web site and enters the Error Viewer application.     The user enters his login ID and password. Assuming the information is correct, the application is provided to the user.     The user enters the server name that holds the desired database, and the database name where the document information is stored. Document records that have been marked for deletion are deleted instantaneously from the system and are not reported. Document records that are saved are reported on the Line Item and Exception reports as a “character recognition (CR) error”.        

      7. User Maintenance/Reports  
      a. Description  
      The maintenance application provides the system administrator the capability to add and update the user profile information, as well as view the list of active and inactive users. A user can also generate reports from the maintenance application. The reports display the results of the document data that have gone through recognition and subsequent validation in the Atlantis system. There are three basic reports that can be generated from the application.  
                   TABLE 83                       REPORT   DESCRIPTION                  Line Item   Displays both pass and fail values including actual and       Report   recognized data for each item. Items that failed validation           are highlighted.       Exception   Displays failed values including actual and recognized       Report   data for each item.       General   Displays statistics on the processed documents.       Summary       Report                  
 
      b. Launching the User Maintenance Application.  
      To launch the User Maintenance application, the user performs the following acts: 
          The user accesses the EIMA System web site and enters the User Maintenance application.     The user enters his login ID and password. Assuming the information is correct, the application is provided to the user.     The user enters the server name that holds the desired database, and the database name where the document information is stored. The User Maintenance screen  4600  ( FIG. 46 ) is displayed. A user maintenance window  4602  displays a list of active and inactive users. This information is displayed by status level then by the user&#39;s last name.     The user clicks the User Profiles button  4605 .        

      (i) Adding New Users  
      Only the system administrator has the capability to add new users to the system. From the user maintenance window, the user selects the new button  4610 . The user details window is displayed. The administrator can then enter the user&#39;s first and last name, assign a username and password, and Designate the level and status of the user.  
      (ii) Updating Current Users  
      To update current users, the user selects a user and clicks the details button  4615  from the user maintenance window. The user can then update the profile information.  
      c. Reports  
      From the maintenance window  4600 , the user can click on the reports button  4620  to create a report. The reports window  4700  ( FIG. 47 ) is displayed to the user. The user can then select a report. In one embodiment, an Excel file is generated from the list of reports. The user can also save the report to a directory. An example report  4800  is shown in  FIG. 48 . The following items can be indicated in some reports.  
                   TABLE 84                       ITEM   DESCRIPTION                  No Seal   Indicates that no seal value was found for the payee name,       Found   dollar amount, account number, check serial number or           routing number.       Not   Indicates no MICR value found on the dollar amount, account       available   number, check serial number or routing number. Can           also indicate low confidence during recognition.       CR Error   Indicates a recognition processing result that fell           below the defined acceptance level.                  
 
      I. Database Maintenance Plan Application  
      The Database Maintenance Plan application is used to help an institution set up the core maintenance tasks that are necessary to ensure that their database performs well, is regularly backed up in case of system failure, and is checked for inconsistencies. The Database Maintenance Plan application creates a Server job that performs these maintenance tasks automatically at scheduled intervals.  
      The maintenance tasks that can be scheduled to run automatically are: 
          backing up the database and transaction log files and retain them for a specific period of time,     reorganizing the data on the data and index pages by rebuilding indexes so that future growth is faster (this ensures that database pages contain an equally distributed amount of data and free space, which allows future growth to be faster),     compressing data files by removing empty database pages, and updating index statistics to ensure the query optimizer has up-to-date information regarding the distribution of data values in the tables (this allows the query optimizer to make better judgments about the best way to access data because it has more information about the data stored in the database),     performing internal consistency checks of the data and data pages within the database to ensure that a system or software problem has not damaged data, and     backing up the database and transaction log files (this allows you to create a history of backups to be used in the event that you need to restore the database to a time earlier than the last database backup).        

      The results generated by the maintenance tasks can be written as a report to a text file, HTML file, or even e-mailed to an administrator. One or more of the tasks performed by the Database Maintenance Plan application are discussed above in connection with other applications. However, the Database Maintenance Plan application provides an administrator with a single tool to coordinate all of the tasks.  
      J. EIMA Communications Protocol  
      Some embodiments of the EIMA system  100  employ a communications protocol between system components (described above) and/or other components external to the EIMA system  100 . Adherence to this protocol can improve system performance by increasing communications speed, improving communications reliability, and/or providing improved control over the order and transmission of data with and within the EIMA system  100 .  
      The EIMA system  100  can employ a protocol for sending and receiving data from one or more sending devices to one or more receiving devices. In some embodiments, the EIMA system  100  can employ a protocol for providing reliable intra-system and inter-system communication of data between one or more networks and/or components (e.g., devices, applications, and the like).  
      As used herein and in the appended claims, the term “data” refers to information in any form that can be transmitted, received, processed by machine, regardless of the location of such data in a system, whether the data is stored or in transit between locations (e.g., regardless of whether at a sending device or at a receiving device as described in greater detail below). Such data can be in any amount, and can be in one or more discrete amounts or can be in a continuous stream. In some embodiments, “data” includes one or more items or item portions, representations of items, portions of such representations, information related to or regarding such items, instructions, commands, and/or portions of instructions or commands. For example, in some embodiments of the EIMA system  100  adapted for use in processing financial items (such as bank checks, deposit or withdrawal transaction receipts or other records, and the like), data can include electronic representations of such items (e.g., scanned copies of checks or check portions, text representative of information on the checks or check portions, and the like), accompanying information regarding the financial transactions of which the items are a part, information regarding where the items are stored, to be stored, or have been stored, and the like. In these and other embodiments, data can include items (or portions thereof) that represent or define identification cards, photographs, graphics of any type, sound recordings, legal documents, and any other element of information desired.  
      As used hereafter and in the appended claims, the term “item” refers to any document or document portion in electronic form (whether originally in such form or otherwise). In some embodiments, an “item” can include, be accompanied by, or be otherwise associated with information of or relating to the document or document portion. An “item” can be of any type, such as items of or relating to financial transactions, individual identification and/or access, legal transactions, and the like. By way of example only, financial instruments of any type (e.g., checks, withdrawal records, deposit records, funds transfer records, certificates of deposit, bonds, loan records, and the like) are all considered to be “items” employed in financial transactions.  
      As shown in  FIG. 1 , the protocol can be implemented within the EIMA system  100  itself, such as, for example, for communications between a host server  110  and one or more workstations  115 , or between any of the system components illustrated in  FIG. 1 . In some embodiments, the protocol can be implemented by the EIMA system  100  for sending or receiving data from another network or external component (e.g., device, application and the like). Although the protocol described in greater detail below is described herein as applied to an Electronic Item Management and Archival (EIMA) system  100  (e.g., for management of imaged checks as described above by way of example only), it should be noted that other systems and networks that send data from one network, device, or application to another network, device, or application can use the communication protocol to conduct the transfer of data.  
      In some embodiments, the communication protocol of the present invention can be implemented by a system  5100  (shown in  FIG. 51 ) for providing reliable communication between one or more networks and/or one or more internal or external components (e.g., devices, applications, and the like). With respect to the embodiments and examples discussed hereinafter regarding the communication protocol, the terms “networks”, “components”, “devices”, “applications”, and the like refer to elements, whether physical or virtual, for sending and receiving data to and from various locations, physical or virtual.  
      As shown in  FIG. 51 , the system  5100 , such as, for example, the EIMA system  100  shown in  FIG. 1 , can implement a communication protocol for sending data from one or more sending devices  5105  to one or more receiving devices  5110 . For example, in some embodiments, the system  5100  can include multiple sending devices  5105 , such as, a first sending device  5115  and a second sending device  5120 , and multiple receiving devices  5110 , such as, a first receiving device  5125 , a second receiving device  5130 , a third receiving device  5135 , and fourth receiving device  5140 . In other embodiments, the system  5100  can include more or fewer sending and/or receiving devices than shown and described. Also, more or fewer and/or different communication paths can exist between the sending and receiving devices illustrated in  FIG. 51  (and  FIGS. 52-54  described in greater detail below).  
      The sending devices  510 S can include any component (e.g., device, application, and the like) that can send data to another location internal to or external from the system  5100 . In some embodiments, the location can be a physical device internal to or external from the system  5100 . In other embodiments, the location can be another network or a virtual location residing in the system  5100  or external to the system  5100 . For example, the sending devices  5105  can include a workstation, a computer, a server, a database, any input and output device (“I/O device”) (e.g., another computer, a hand-held device or personal digital assistant (“PDA”), a printer, a fax machine, a scanner, and any other device operate to receive one or more inputs for processing and/or to generate one or more outputs), a router, a bridge, and the like. Also, the sending devices  5105  can include one or more sending applications  5305  resident at the sending location (e.g., the sending device  5105 ), any of which can include an application that generates or formats the data to be sent to the receiving devices  5110 . The receiving devices  5110  can include any component that can receive data from another component or location. For example, the receiving device  5110  can include a workstation, a computer, a server, a database, an I/O device (e.g., another computer, a hand-held device or PDA, a printer, a fax machine, a scanner, and the like), a router, a bridge, and the like.  
      In some embodiments, the communication protocol can be implemented to send data between various networks. In these embodiments, the sending devices  5115  and the receiving devices  5110  can be located in different networks. For example, as shown in  FIG. 52 , the system  5100  can include two networks  5150  and  5155 . The first sending device  5115 , the second sending device  5120 , the first receiving device  5125 , and the fourth receiving device  5140  can be included in a first network  5150 , and the second receiving device  5130  and the third receiving device  5135  can be included in a second network  5155 . In other embodiments, any number of sending and/or receiving devices  5105 / 5110  can be located in any number of different networks as desired, and can be distributed in any manner in such networks.  
      Also, in some embodiments, such as, for example, the embodiment shown in  FIG. 53 , the communication protocol can be implemented to exchange data between one or more systems. As shown in  FIG. 53 , the first sending device  5115 , the first receiving device  5125 , and the second receiving device  5130  can be included in a third network  5160 , and the second sending device  5120 , the third receiving device  5135 , and the fourth receiving device  5140  can be included in a fourth network  5165 . In this embodiment, a first system  5170  can include the third network  5160  and a second system  5175  can include the fourth network  5165 . In other embodiments, the communications protocol of the present invention can be implemented to exchange data between any number of different systems, any one of which can include one or more networks.  
      With reference now to  FIG. 54  by way of example only, in some embodiments the system  5100  can include one or more components that can serve as both a sending device  5105  and a receiving device  5110  (these devices are denoted with the reference number  5105 / 5110 ). The exemplary system  5100  illustrated in  FIG. 54  includes a first sending/receiving device  5180 , a second sending/receiving device  5185 , and a third sending/receiving device  5190 . In some embodiments, all sending devices  5105  can have the capabilities to also receive data, and/or all receiving devices  5110  can have the capabilities to send data. In other embodiments, the system  5100  can include any number and combination of sending devices  5105  dedicated to sending data, receiving devices  5110  dedicated to receiving data, and sending/receiving devices  5105 / 5110  capable of performing both functions. In those embodiments employing one or more sending/receiving devices  5105 / 5110 , any number of such devices can be used solely to send data or to receive data (although capable of performing both functions).  
      As shown in  FIGS. 51-54 , the sending devices  5105 , the receiving devices  5110 , and the sending/receiving devices  5105 / 5110  (referred to hereinafter as included in the sending devices  5105  and receiving devices  5110  unless specified otherwise) can communicate over various communication links  5200 . The communication links  5200  can include preexisting links, direct links, indirect links, and the like, can include any type and combination of communications links such as, for example, wireless links, telephone lines, electrical power lines, dedicated cables, Internet links, Intranet links, and the like, and can include any number and combination of one-way and two-way communications links. As shown in  FIG. 54 , for example, the communication links  5200  can include a one-way communication link  5205 , a two-way single communication link  5210 , a communication link  5215  comprising two one-way communication links, and the like.  
      In some embodiments, a sending device  5105  can send data to a single receiving device  5110  or any number of additional receiving devices  5110 . The sending device  5105  can implement the communication protocol of the present invention to send the data as multiple unicasts to the various receiving devices  5110 . The sending device  5105  can also or instead implement the communication protocol to send the data as a multicast to the various receiving devices  5110  or as a broadcast.  
      With reference now to  FIG. 55 , some embodiments of the communication protocol according to the present invention can include at least two applications: a communication protocol sending application (“CP-S”)  5310  and a communication protocol receiving application (“CP-R”)  5320 . Either or both “applications” can be hardware and/or software based, and can include one or more programs and/or functions. In some embodiments, the CP-S applications  5310  and the CP-R application  5320  can manage or control the transfer of data between the sending device  5105  and the receiving device  5110 . In other embodiments, the CP-S application  5310  and the CP-R application  5320  can assist with the transfer of data.  
      In some embodiments, every sending device  5105  has a dedicated CP-S application  5310  with which to interface, and every receiving device  5110  has a dedicated CP-R application  5320  with which to interface. In other embodiments, two or more (or all) sending devices  5105  employ the same CP-S application  5310  to interface with the CP-R application  5320  of the receiving device(s)  5110  and/or two or more (or all) receiving devices  5110  employ the same CP-R application  5320  to interface with the CP-S application  5310  of the sending device(s)  5105 . In the embodiments in which one or more (or all) sending devices  5105  and/or receiving devices  5110  are sending/receiving devices  5105 / 5110  (e.g., devices that have the capability to both send data and receive data), each sending/receiving device  5105 / 5110  can have a dedicated or non-dedicated CP-S application  5310  with which to interface when sending data and a dedicated or non-dedicated CP-R application  5110  with which to interface when receiving data. According to this embodiment, for example, the sending device  5105  of  FIG. 55  (which, in this embodiment, is a sending/receiving device  5105 / 5110 ) can also connect to a CP-R application  5320  to receive data. Similarly, the receiving device  5110  of  FIG. 55  (which, in this embodiment, is a sending/receiving device  5105 / 5110 ) can also connect to a CP-S application  5310  to send data.  
      In some embodiments, a CP-S application  5310  and a CP-R application  5320  can be included in a single application, such as, for example, a communication protocol managing application (“CP-M”). In these embodiments, the CP-S application  5310  and the CP-R application  5320  are sub-applications of the CP-M application. Also, in some embodiments, the CP-M application can perform the functions of both the CP-S application  5310  and the CP-R application  5320 . With respect to the embodiments and examples discussed hereinafter regarding the communication protocol, the term “CP-S application” refers to the portion of the communication protocol implemented for sending data, and the term “CP-R application” refers to the portion of the communication protocol implemented for receiving data. Hereinafter, the terms “CP-S application” and “CP-R application” can be separate applications, sub-applications, functions of a single application, and the like. For example, in an exemplary embodiment, the CP-S application  5310  of  FIG. 55  can be a sub-application of a first CP-M application or a function of a first CP-M application. Similarly, the CP-R application  5320  of  FIG. 55  can be a sub-application of a second CP-M application or a function of a second CP-M application. In another exemplary embodiment, the CP-S application  5310  of  FIG. 55  can be a first sub-application or a first function of a CP-M application, and the CP-R application  5320  of  FIG. 55  can be a second sub-application or second function of the CP-M application.  
      The CP-S application  5310  can run on any one or more sending devices  5105  or can run on another device, such as, for example, a server, a workstation, and the like. Similarly, the CP-R application  5320  can run on any one or more receiving devices  5110  or can run on another device, such as, for example, a server, a workstation, and the like. As shown in  FIG. 55 , the sending device  5105  is shown establishing a connection with the CP-S application  5310 . In the illustrated embodiment, the CP-S application  5310  is shown as a separate application running in a separate environment. In other embodiments, the sending device  5105  and the CP-S application  5310  can run in the same environment. Also shown in  FIG. 55 , the receiving device  5110  is shown establishing a connection with the CP-R application  5320 , and is shown as a separate application running in a separate environment. In other embodiments, the receiving device  5110  and the CP-R application  5320  can run in the same environment.  
      As described above, in some embodiments, two or more sending devices  5105  communicate with a single CP-S application  5310 . By way of example only, if two or more sending devices  5105  are individual applications running on a single device (e.g., a server, workstation, and the like) or if two or more sending devices  5105  are included in a single network (e.g., a local area network), the two or more sending devices  5105  can communicate with the same CP-S application  5310  that may or may not be running on the same device or network. Similarly, each receiving device  5110  may or may not have a dedicated CP-R application  5320 .  
      Either or both of the CP-S application  5310  and the CP-R application  5320  can include one or more application programming interfaces (“APIs”) for submitting and receiving data, and in some cases for performing other functions (e.g., retrieving session status, and the like). In some embodiments, the APIs can be implemented by a user to provide details regarding the data transfers between the sending device  5105  and the receiving device  5110 . In other embodiments, the APIs can be activated automatically (e.g., open and run automatically without a user prompt) and can provide details to a user regarding the automatic functions being currently performed or previously performed by the communication protocol. For example, either or both of the CP-S application  5310  and the CP-R application  5320  can include one or more APIs, such as a Listen API, a Connect API, a Send Data API, a Receive API, a Close API, or additional APIs (described in greater detail below). In some embodiments, these APIs may require a user prompt or may not require any user prompts. When one or more sending devices  5105  and/or receiving devices  5110  establish one or more connections with one or more CP-S applications  5310  and/or CP-R applications  5320 , the sending device  5105  or receiving device  5110  can automatically call various APIs to assist with data delivery and other functions, as discussed below, or one or more users can initiate the call to various APIs to assist with data delivery and other functions.  
      According to some embodiments of the present invention, either or both of the sending device  5105  and the receiving device  5110  can create or establish a session to send and receive data through the communication protocol. In some embodiments, the term “session” refers to the continuous connection and one or more transmissions of data between at least one sending device  5105  and at least one receiving device  5110 . In other embodiments, the term “session” refers to one or more connections, either continuous or discontinuous, and one or more transmissions of data between at least one sending device  5105  and one receiving device  5110 . In further embodiments, the term “session” refers to one or more connections, either continuous or discontinuous, and an intended amount of transmission of data to take place between at least one sending device  5105  and one receiving device  5110 .  
      A session can include various connections between different components. For example, a first session in the communication protocol can include a first connection between the sending device  5105  and the CP-S application  5310 , a second connection between the receiving device  5110  and the CP-R application  5320 , and a third connection between the CP-S application  5310  and the CP-R application  5320 . In other embodiments, the first session can include additional connections between the sending device  5105  and another component, between the receiving device  5110  and another component, between the CP-S application  5310  and another component, and/or between the CP-R application  5320  and another component. For example, the first session may include an additional fourth connection between a second receiving device  5110  and the CP-R application  5320 , an additional fifth connection between a second receiving device  5110  and a second CP-R application  5320 , and/or an additional sixth connection between the second CP-R application  5320  and the CP-S application  5310 . In some embodiments, either one, some or all of the connections in a session can be permanent connections (i.e., the connection is always established), automatic connections (i.e., the connection is automatically established and prompted by an event, such as a boot-up), manual connections (i.e., the connection must be established by a user), or other suitable connection types.  
      In an exemplary embodiment of the present invention illustrated in  FIG. 55 , the sending device  5105  can establish a connection with the CP-S application  5310 , and the receiving device  5110  can establish a connection with the corresponding CP-R application  5320 . As shown in  FIG. 55 , the sending device  5105  creates a connection  5340  with the CP-S application  5310 , and the receiving device  5110  creates a connection  5350  with the CP-R application  5320 . The connection  5340  can be an automatic connection that takes place in response to some event, such as, for example, when the sending device  5105  is activated (e.g., powered up), when a program loads, when data is generated by a program or application, when data is received through an input, in response to a command, and the like. In other embodiments, the connection  5340  can be a connection that requires a user prompt or command for activation. For example, a user can run a Connect API and command that the connection  5340  be established. Similarly, the connection  5350  can be an automatic connection that takes place in response to some event (e.g., power up, loaded program and the like) or can be a user-prompted connection. In some embodiments, such as the embodiment illustrated in  FIG. 55 , the connection  5350  (e.g., automatic or user-prompted) established between the CP-R application  5320  and the receiving device  5110  can include a registration. In these and other embodiments, the connection  5340  (e.g., automatic or user-prompted) established between the CP-S application  5310  and the sending device  5105  can also include a registration.  
      Referring to  FIG. 55 , for example, when a receiving device  5110  registers with a CP-R application  5320 , the receiving device  5110  can transmit certain registration data to the CP-R application  5320 . For example, the receiving device  5110  can provide identification information to the CP-R application  5320 , such as, for example, an IP address, a receiver identification number, a serial number, a receiver port number, and the like. The receiving device  5110  can also provide additional information to the CP-R application  5320 , such as, for example, the device&#39;s current status (e.g., Connected, Registered, Listening, and the like), and other information. Registration can aid the CP-R application  5320  to route incoming data to the appropriate receiving device  5110 , such as in the event that multiple receiving devices  5110  establish connection with a common CP-R application  5320 . In some embodiments, the CP-S application  5310  and the sending device  5105  of  FIG. 55  can perform a registration process in a similar manner as discussed above.  
      In some embodiments, the receiving device  5110  can establish various connections with multiple CP-R applications  5320 . Similarly, the sending device  5105  can establish various connections with multiple CP-S application  5310 . In further embodiments, the receiving device  5110  can establish simultaneous connections with one or more CP-R applications  5320  and with one or more CP-S applications  5310  (in those embodiments where the receiving device  5105  is a sending/receiving device, such as the sending/receiving device  5105 / 5110  shown in  FIG. 55 ). Similarly, the sending device  5105  can establish simultaneous connections with one or more CP-S applications  5310  and with one or more CP-R applications  5320  (in those embodiments where the sending device  5105  is a sending/receiving device, such as the sending/receiving device  5105 / 5110  shown in  FIG. 55 ).  
      Once a receiving device  5110  establishes a connection  5350  with the CP-R application  5320 , the CP-R application  5320  can transmit an acknowledgement transmission  5355  to the registered receiving device  5110 . In such cases, the acknowledgement transmission  5355  can include a registration acknowledgement transmission including such information as information regarding the CP-R application  5320 , any data transmitted by the receiving device  5110  during registration, and the like. Similarly, once a sending device  5105  establishes a connection  5340  with the CP-S application  5310 , the CP-S application  5310  can transmit an acknowledgement transmission (not shown) to the sending device  5105 . Such an acknowledgement transmission can include any of the data referred to above with reference to the CP-R acknowledgement transmission.  
      In some embodiments, the receiving device  5110  can call a Listen API once the connection  5350  is established between the receiving device  5110  and the CP-R application  5320 . The Listen API can allow the receiving device  5110  to listen for incoming connections from one or more sending devices  5105 . In some embodiments, the CP-R application  5320  can update the status of the receiving device  5110  from Connected to Listening, for example, when the receiving device  5110  calls for the Listen API. In some embodiments, the receiving device  5110  automatically connects to the Listen API once the connection  5350  between the receiving device  5110  and the CP-R application  5320  is established. In other embodiments, the receiving device  5110  does not need to call or connect with an API, such as the Listen API, to listen for incoming data. In some embodiments, the receiving device  5110  can connect and call the Listen API on multiple CP-R applications  5320 , such as to receive data from multiple CP-S applications  5310  concurrently.  
      Once a sending device  5105  establishes a connection  5340  with the CP-S application  5310 , in some embodiments the sending device  5105  calls the Connect API to begin data transmission. In some embodiments, calling the Connect API can be a separate step for the sending device  5105 . In other embodiments, the Connect API can be automatically called when the sending device  5105  establishes the connection  5340  with the CP-S application  5310 . In further embodiments, the Connect API can be automatically called when the sending device  5105  receives data to be transmitted (e.g., received data through an input port) or generates data to be transmitted (e.g., data generated by another application or program). In still further embodiments, the Connect API can be called or prompted by a user.  
      When the Connect API is successfully called and connected, the sending device  5105  can send the data (i.e., data to be sent to the receiving device  5110 ) to or through the CP-S application  5310  by sending the data to or through the Connect API. In some embodiments, the data can be sent automatically or when prompted by a user. In some embodiments, the sending device  5105  sends the data to the Connect API as well as information regarding the destination of the data. In other embodiments, the information regarding the destination of the data is included in the data itself or in registration information sent to the CP-S application  5310  earlier (as described above). If desired, such information can include one or more addresses in one or more fields of the data.  
      In other embodiments, once a connection  5340  between the sending device  5105  and the CP-S application  5310  is established, the sending device  5105  can “send” data to the CP-S application  5310 . In these embodiments, “sending” the data to the CP-S application  5310  can include the sending device  5105  copying or transferring the intended data to one or more blocks of persistent storage as dedicated or allocated by the CP-S application  5310 . This can be prompted or aided with or without the Connect API.  
      In further embodiments, the Connect API can utilize the destination information to contact each destination CP-R application  5320  via a connect transmission  5370 . In some embodiments, the connect transmission  5370  can also include and perform a two-way handshake process to establish a connection with the CP-R application(s)  5320 .  
      In some embodiments, such as the embodiment illustrated in  FIG. 55 , the Connect API of the CP-S application  5310  can utilize the data from the sending device  5105  (or destination information received in any other manner as described above) to create a Connect packet to send to the various destination CP-R applications  5320  in the connection transmission  5370 . In some embodiments, the Connect packet includes various information regarding the sending device  5105 , the destination, and the like. In these and other embodiments, the Connect packet can establish a connection between the CP-S application  5105  and the CP-R application  5110 , and can indicate to the CP-R application  5110  that data is to be sent to the CP-R application  5110 . In some embodiments, the Connect packet can be an indicator that the CP-R application  5110  should allocate the proper resources (e.g., memory, persistent storage, bandwidth and the like) for receiving data from the CP-S application  5105 .  
      In some embodiments, the Connect packet can include identification information of the sending device  5105 , the CP-S application  5310 , the receiving device  5110 , and/or the CP-R application  5320 . The Connect packet can be used to verify whether the intended receiving device  5110  is registered or not. The Connect packet can be transmitted as a broadcast from the CP-S application  5310  to all CP-R applications  5320  included in the system  5100 , can be transmitted as one or more multicasts to any number of the CP-R applications  5320 , can be transmitted as one or more unicasts to any number of the CP-R applications  5320 , or can be transmitted in any other manner. In an exemplary embodiment of the present invention by way of example only, the CP-S application  5310  can transmit the Connect packet (e.g., the connect transmission  5370 ) as multiple unicasts, such that each CP-R application  5320  included in the system  5100  receives a Connect packet unicast.  
      In some embodiments, when the CP-R application  5320  receives the Connect packet from the CP-S application  5310  and the receiving device  5110  has established a connection  5350  with the CP-R application  5320 , the CP-R application  5320  can reply to the CP-S application  5310  with a connect reply transmission or acknowledge transmission  5375 . In some embodiments, the acknowledge transmission  5375  can include a Connection Success packet, if a session (e.g., a connection between a sending device  5105  and a receiving device  5110  through the communication protocol) is established, or a Failure to Register packet, if a session fails to establish.  
      In some embodiments, after the CP-R application(s)  5320  respond with a Connection Success packet in the acknowledge transmission  5375 , the CP-S application  5310  allocates resources (e.g., memory, communication paths, bandwidths, and/or other resources) for the session. However, this memory and resource allocation by the CP-S application  5310  can be performed at an earlier or later time, if desired. Similarly, in some embodiments the CP-R application(s)  5320  allocate resources (e.g., memory, communication paths, bandwidths, and/or other resources) in advance of or upon receiving data to be sent to the receiving device(s)  5110 . For example, the CP-R application(s)  5320  can allocate such resources upon receiving a Connect packet, which can include information (described above) by which the CP-R application(s)  5320  can determine how such resources will be allocated. In other embodiments however, such resource allocation can occur at another stage, such as after a receiving device  5110  creates a connection  5350  with a CP-R application  5320 , or after the CP-R application begins receiving a communication  5385  to be transmitted to the receiving device  5110  (described in greater detail below). In such embodiments, resource deadlock can be reduced or delayed.  
      In some embodiments, the CP-S application  5310  transmits a session identification number or other session identification information to one or more of the sending devices  5105  and/or to one or more of the CP-R applications  5320  to identify and/or record the session. The session identification number or session identification information can be sent at the beginning of, at the end of, or during the session. In some embodiments, the session identification number or information can be used by the sending device  5105  during data submission and can be unique within each location, sending device  5105  or CP-S application  5310 .  
      The CP-S application  5310  can begin to receive the data from a sending device  5105  if a connection (e.g., a session) is established with one or more destination CP-R applications  5320 . In other embodiments, the CP-S application  5310  can begin to receive the data from the sending device  5105  regardless if a connection (e.g., a session) is established with each destination CP-R application  5320 . In some embodiments, when a connection fails, the Connect API can notify the sending device  5105  and/or a user. If desired, the sending device  5105  can interrupt the data transmission to the CP-S application  5310  until all connections have been re-established, or can instead continue to transmit data.  
      In some embodiments, and with reference now to  FIG. 56 , the sending device  5105  or a user can invoke a Send Data API prior to sending a first data transmission  5380 . A Send Data API can be invoked in some cases regardless of whether a Connect API is first invoked as described above (in which case any of the acts initiated by the Connect API described above can be initiated by the Send Data API, if desired). The Send Data API can allow the sending device  5105  to submit the first data transmission  5380  to the corresponding CP-S application  5310 . For example, the first data transmission  5380  may include a single portion of data, such as, for example, a single packet or item. In some embodiments, the first data transmission  5380  may include multiple portions of data, such as, for example, multiple data items or packets.  
      When the CP-S application  5310  receives the first data transmission  5380  (or each portion of data included in the data transmission  5380 ), in some embodiments the CP-S application  5310  can store the data in a data list. The data list can be stored in any type of memory, such as persistent storage (e.g., non-volatile memory) or volatile memory. In these and other embodiments, the CP-S application  5310  can generate a data identification number (“dataID”) and can store the data and dataID (e.g., a tuple &lt;dataID, data&gt;). The data and dataID can be stored in any memory accessible to the CP-S application, such as in the data list. In some embodiments, the data list can be stored in memory that was previously allocated by the CP-S application  5310  for this particular session. For example, the data list can be stored on a persistent storage  5382  or in any other memory desired. The tuple can also be pushed into a memory buffer allocated by the CP-S application  5310  prior to transmission, such as a memory buffer allocated by the CP-S application  5310  after session establishment.  
      In some embodiments, the CP-S application  5310  formats the data received from the sending device  5105 , such as by placing the data in tuple format (if not already in such format) and/or in other formats, placing the data and/or data tuples into packets, preparing the data for transmission to the CP-R application  5320 , and the like. Any protocol can be employed by the CP-S application to format the data, such as, for example, Internet Protocol (IP), a propriety protocol, an encrypted protocol, and the like. In other embodiments, the CP-S application  5310  performs no formatting of the data received from the sending device  5105 . In further embodiments, another application can format the data. In those embodiments in which formatting is performed by the CP-S application  5310 , such formatting can be performed while the sending device  5105  continues to transmit the remaining data to the CP-S application  5310  or can be performed after the sending device  5105  transmits all session data to the CP-S application  5310 .  
      During or after the data transmission  5380 , the CP-S application  5310  can send a data transmission  5385  to the intended CP-R application(s)  5320 . This data transmission  5385  can include a single unicast transmission, a single multicast transmission, multiple unicast transmissions, multiple multicast transmissions, a single broadcast, and the like. This data transmission  5385  can include the data transmitted in the data transmission  5380  from the sending device  5105  to the CP-S application  5310  and/or can include the tuples formatted by the CP-S application  5310  as described above. For example, a data transmission thread included in the CP-S application  5310  can constantly check the persistent storage or memory buffer (if employed) allocated by the CP-S application  5310  and can transmit the data and/or tuples via the data transmission  5385  to the intended destination CP-R application(s)  5320 . In those embodiments in which the data and/or tuples are stored in memory (e.g., persistent storage  5382 ) by the CP-S application as described above, even if a failure occurs during data delivery, the CP-S application  5310  can be adapted to later re-transmit some or all of the data and/or data tuples via the data transmission  5385  when the system  5100  or connections recover.  
      As described above, in some embodiments the CP-R application  5320  can allocate resources (e.g., memory, communication paths, bandwidths, and/or other resources) upon receiving the data transmission  5385  from the CP-S application  5310 . Regardless of when this resource allocation is performed, in some embodiments the CP-R application  5320  invokes a session setup procedure if the status of the receiving device  5110  is Listening or Connected. In some embodiments, a session setup procedure performed by the CP-R application includes storing session data or information in a persistent table or other memory. For example, the session data can include such information as receiving device identification, IP addresses of the CP-S application  5310 , session identification information, information regarding the data, and the like. The session setup procedure can also or instead include creating a memory buffer  5390  for holding the incoming data before long-time storage, allocating a persistent block or other memory for the receiving device  5110  to store the latest acknowledgements and/or to return session information to the receiving device  5110 , and the like.  
      As described above, in some embodiments the CP-R application  5320  can store the data transmitted by the data transmission  5385  from the CP-S application  5310  to the CP-R application  5320  in a memory buffer  5390  allocated by the CP-R application  5320  for the intended receiving device  5110 . In some embodiments, the CP-R application  5320  extracts the data included in the tuples (if in tuple form), and can store the extracted data and/or the tuples in the memory buffer  5390 . The CP-R application  5320  can allocate one or more memory buffers  5390  for each receiving device  5110  that establishes a connection  5350  with the CP-R application  5320 . The CP-R application  5320  can also allocate a memory buffer  5390  for every data transmission  5385  intended for a particular receiving device  5110  from one or more sending devices  5105  or CP-S applications  5105 . In other embodiments, the CP-R application  5320  can allocate other types of memory for data storage.  
      As described above, in some embodiments the receiving device  5110  receives an acknowledgement transmission  5355  when a session is established. In these embodiments, the acknowledgement transmission  5355  can include session identification information, CP-S application identification information and IP address, and other data relevant to the session, the sending device  5105 , the receiving device  5110 , the CP-S application  5310 , and/or the CP-R application  5320 . In other embodiments, the receiving device  5110  can receive an acknowledgement transmission  5355  in response to a receiving device  5110  establishing a connection  5350  with the CP-R application  5320 , or in response to the CP-R application  5320  receiving the data transmission  5385  from the CP-S application  5310 .  
      In some embodiments, the receiving device  5110  can send a receive request  5400  to one or more CP-R applications  5320  prior to, during, or subsequent to the reception of the data transmission  5390  by the CP-R application(s)  5320 . The receive request  5400  can include calling a Receive API to retrieve any data included in the memory buffer  5390  of the CP-R application  5320 . Upon receiving the receive request  5400  (e.g., the Receive API), the CP-R application  5320  can retrieve the data tuple(s) or packet(s) stored in the memory buffer  5390 , and can transmit the data in a data transmission  5405 . This data transmission  5405  can include one or more data transmissions being sent from the CP-R application  5320  to the receiving device  5110 . In some embodiments, the CP-R application  5320  can transmit tuples or data stored in the memory buffer  5390  one at a time, or can instead transmit two or more tuples or data at the same time. In the event that the buffer  5390  of the CP-R application is empty, the CP-R application can block or deny the request  5400  by the receiving device  5110 .  
      In other embodiments, the CP-R application  5320  can transmit the data transmission(s)  5405  to the intended one or more receiving devices  5110  upon the reception of the data transmission  5390 . In further embodiments, the CP-R application  5320  can transmit the data transmission(s)  5405  to the intended one or more receiving devices  5110  upon the reception of all of the data transmissions  5390  sent by the CP-S application  5310 . In still further embodiments, the CP-R application  5320  can transmit a select number of data transmissions  5405  to the intended one or more receiving devices  5110  upon the reception and formatting of the select number of data transmissions  5390  sent by the CP-S application  5310 .  
      Prior to, during, or after the last data transmission  5405  to the receiving device  5110  (e.g., the completion of the data transmission  5405 ), the receiving device  5110  in some embodiments can send a receipt transmission  5410  to the CP-R application  5320 . The receipt transmission  5410  can include an acknowledgement of the status of the data transmission  5405 , such as, transmission successful, transmission complete, transmission interrupted, or the like. In some embodiments, the receipt transmission  5405  can be sent after the data transmission  5405  has been processed by the receiving device  5110 , although in other embodiments the receipt transmission  5405  is sent prior to being processed by the receiving device  5110  (such as after the last portion of the data transmission  5405  has been received at the receiving device  5110 , after the receiving device  5110  stores the information included in the data transmission  5405  into a local disc or any other memory, and the like).  
      In some embodiments, the CP-R application  5320  can save the information received (e.g., the data or data tuples) into a persistent storage accessible by the CP-R application, although in other embodiments, this information is not saved in such a memory. Also, in some embodiments the CP-R application can retransmit any part or all of the data back to the CP-S application  5310  in a latest receipt transmission  5430 . For example, the latest receipt transmission  5430  can include an acknowledgement message stating the transmission was successful, and may or may not include some or all of the data transmitted to the CP-R application  5320  from the CP-S application  5310 .  
      In some embodiments, such as the embodiment illustrated in  FIG. 57 , the sending device  5105  can transmit a closing request  5440  after the sending device  5105  successfully submits all the data to the CP-S application  5310 . The closing request  5440  can include invoking a Close API. The closing request  5440  can inform the CP-S application  5310  that there is no more data to be transmitted. Upon reception of the closing request  5440  in some embodiments, the CP-S application  5310  marks the session as closed internally. In those embodiments in which data of the transmission is stored by the CP-S application in a memory  5382  as described above, this data can remain in such memory  5382  as long as desired. For example, the data and/or resources related to the corresponding session can be purged immediately after transmission of the data  5385  to the CP-R application  5320 , can be purged by the CP-S application  5310  after the CP-S application  5310  receives a successful latest receipt transmission  5430  from one, some, or all of the intended CP-R applications  5320 , can be purged by the CP-S application upon receipt of a closing confirmation transmission  5455  (described below), or can be purged at a later time as desired.  
      In some embodiments, when the CP-S application  5310  receives all the latest receipt transmissions  5430  and each latest receipt transmission  5430  indicates that data transmission was successful, then the CP-S application  5310  can send a closing command  5450  to one or more of the destined CP-R applications  5320 . Alternatively, such a command  5450  can be generated and sent when fewer than all of the latest receipt transmissions  5430  are received and/or when fewer than all indicate that data transmission was successful. In some embodiments, the closing command  5450  includes a single closing packet containing an indicator to the CP-R application to close the session, although any additional information can also be transmitted in the same or other packets (e.g., session identification information, and the like). Upon reception of the closing command  5450 , the CP-R application  5320  can clear any amount of resources corresponding to that particular. Also upon reception of the closing command  5450 , in some embodiments the CP-R application transmits a closing confirmation transmission  5455  acknowledging that the session has been closed on the CP-R application&#39;s end. In some embodiments, the CP-S application  5310  can then purge any amount of resources for that particular session and/or any amount of data stored by the CP-S application as described above. This purging can take place when the CP-S application  5310  receives confirmation from all the CP-R applications  5320  or from any desired number of the CP-R applications. If the CP-S application  5310  does not receive confirmation from all (or the desired number) of the CP-R applications  5320 , in some embodiments the CP-S application  5310  retransmits the closing command  5450  periodically to all un-acknowledged CP-R applications  5320  until confirmation is received.  
      In some embodiments, the communication protocol can include an automatic recovery function that can be performed when failures(s) occur during data transmission. In some embodiments, the communication protocol can include another application, such as, for example, a automatic recovery management application, for controlling and managing automatic recoveries. In other embodiments, the automatic recovery function can be included in any one or more of the CP-S application  5310 , CP-R application  5320  and CP-M application. In further embodiments, the automatic recovery management application can be included in an API, such as the Recovery API. In the exemplary embodiment of  FIGS. 58-60 , the automatic recovery function is included in one or both of the CP-S application  5310  and the CP-R application  5320 . However, it should be noted that the automatic recovery function described in the following examples can be included in a separate application running in the same environment as the CP-S application  5310  or CP-R application, or can be a separate application running in another environment.  
      The CP-S application  5310  includes the automatic recovery function in some embodiments of the present invention. The CP-S application  5310  can employ a recovery thread that periodically verifies whether a session needs to be recovered. The automatic recovery function can prompt the CP-S application  5310  to recover a “silent” sub-session (e.g., a time period in which there is no data being transferred to the corresponding CP-R application  5320  and/or there is no acknowledgment being sent to the CP-S application  5310 ) of one or more sessions. In some embodiments, the CP-S application  5310  can check the session-specific information maintained in memory (e.g., persistent storage) in order to determine whether a “silent” sub-session needs recovery.  
      The CP-S application  5310  can include a session table on persistent storage in some embodiments of the present invention. The session table can include various information relating to the session, such as, for example, the type and amount of data sent and to be sent (e.g., data tuples, one or more data transmissions, and the like), one or more receipt transmissions sent by a corresponding CP-R application  5320 , the type and amount of data that has been acknowledged by a corresponding CP-R application  5320 , and the like. Any of this information can be employed by the CP-S application  5310  to determine or verify whether an interruption in communication has occurred, and whether a session needs recovery.  
      In some embodiments, the session table can include a data list including some or all of the data intended to be transmitted to a corresponding CP-R application  5320 . The data list can be a primary data list (as described above) or a secondary or back-up data list. In either case, this data list can be arranged by each data tuple, can be arranged by data transmissions (e.g., data arranged and separated into discrete transmission blocks that can be sent in separate data transmissions), or in any other manner desired. The session table can further include one or more parameters to further describe the information stored in the session table, such as, for example, a sent identifier and an acknowledged identifier. In some embodiments, the sent identifier can describe or identify what data has been sent by the CP-S application  5310  and can be updated whenever a data transmission is sent. Also, in some embodiments, the acknowledged identifier can describe or identify what data has been acknowledged by a corresponding CP-R application  5320  and can be updated whenever a receipt transmission is received.  
      The session table can also or instead include other identifiers, such as a previous sent identifier and a previous acknowledged identifier. The previous sent identifier can describe or identify the last data to be sent by the CP-S application  5310 , and the previous acknowledged identifier can describe or identify the last data to be acknowledged by the CP-R application  5320 .  
      In some embodiments of the present invention, the CP-S application  5310  can set all of the sent identifiers for every data (e.g., data tuple, item, data transmission, and the like) to a certain value that represents the data as not being sent, such as, for example, a “not sent” value, a “0” value, a “−1” value, or another value. Similarly, the CP-S application  5310  can set all of the acknowledged identifiers for every data (e.g., data tuple, item, data transmission and the like) to a certain value that represents the data as not being acknowledged, such as, for example, a “no acknowledgement” value, a “0” value, a “−1”, value or another value. Alternatively or in addition, the previous sent identifier and the previous acknowledged identifier can also be set to respective values that represent no data being sent and no data being acknowledged, respectfully.  
      When data transmission between the CP-S application  5310  and the CP-R application  5320  begins, the sent identifiers and the acknowledged identifiers can be updated whenever data is sent and acknowledged, respectfully. In some embodiments, the CP-S application  5310  can periodically run the recovery function to update the previous sent identifier and the previous acknowledged identifier. The CP-S application  5310  can automatically run the recovery function and/or the recovery function can be prompted by a user. When the recovery function runs in some embodiments, the previous sent identifier and the previous acknowledged identifier can each check what parameters have been updated. Once the first data (e.g., data tuple, data transmission, item, and the like) is sent, the sent identifier for that parameter can be updated to a value that represents the data as being sent, such as, for example, a “sent” value, a “1” value, or another value. Similarly, once the first data is acknowledged by the CP-R application  5320 , the acknowledged identifier for that parameter can be updated to a value that represents the data as being acknowledged, such as, for example, an “acknowledged” value, a “1” value, or another value. Accordingly, the recovery function can recognize that certain parameters have been updated and can store that data, a data identification number, or other information in the corresponding previous sent identifier and/or previous acknowledged identifier. Whenever a value of either the sent identifiers or acknowledged identifiers is updated, the previous sent identifier or the previous acknowledged identifier can store the updated identifier.  
      In some embodiments, a silent sub-session is recognized when a period of time elapses without an update in the previous sent identifier or the previous acknowledged identifier. For example, in the embodiment illustrated in  FIG. 58 , a silent sub-session can occur when the receiving device  5110  experiences a crash or a loss of communication as shown in  FIG. 58 , or when the sending device  5105  experiences a crash or a loss of communication as shown in  FIG. 59 . In these exemplary cases, the CP-R application  5320  and the receiving device  5110  can run in the same environment, and/or the CP-S application  5310  and the sending device  5105  can run in the same environment.  
      In the example shown in  FIGS. 58 and 59 , a silent sub-session occurs after the CP-S application  5310  transmits N communications to the CP-R application  5320 , but identifies that only N-m communications have been acknowledged. In this example, the N communications (e.g., data as stored in the data list) each include sent identifiers set to the value representing the data as being sent, and the N-m communications (e.g., data as stored in the data list) each include an acknowledged identifier set to the value representing the data as being acknowledged. Also, the data list includes m communications having an acknowledged identifier set to the value representing the data as not yet being acknowledged. The previous sent identifier includes the last data out of N communications that was sent to the CP-R application  5320 , while the previous acknowledged identifier includes the last data out of N-m communications that was acknowledged by the CP-R application  5320 .  
      As shown in  FIG. 58 , after the receiving device  5110  re-establishes a connection  5460  with the CP-R application  5320  (which may or may not include another registration and acknowledgement transmission  5355  as described above), one of the CP-S application  5310  and the CP-R application  5320  can attempt to re-establish communication with the other. Similarly, as shown in  FIG. 59 , after the sending device  5105  re-establishes a connection  5462  with the CP-S application  5310  (which may or may not include another registration as described above), one of the CP-S application  5310  and the CP-R application  5320  can attempt to re-establish the communication with the other application. In some embodiments, such as the embodiment shown in  FIG. 58 , once the CP-S application  5310  identifies a silent sub-session, the CP-S application  5310  can send one or more connect transmissions with or without waiting for another elapsed period of time. The one or more connect transmissions can include one or more the connect transmissions  5370  as described earlier or one or more re-connect requests. In other embodiments, the CP-S application  5310  can wait for a signal from the CP-R application  5320  to re-establish communication. Once communication has been re-established between the CP-S application  5310  and the CP-R application  5320 , the CP-S application  5310  can transmit the remaining m communications to the CP-R application  5320  in one or more remaining data transmissions  5465 .  
      In some cases, such as the example illustrated in  FIG. 60 , the system  5100  can experience a network crash. In these cases, the CP-S application  5310  can stop sending re-connection transmissions to the CP-R application  5320  after a certain time period or after a certain number of re-connection transmissions. The CP-S application  5310  and/or the CP-R application  5320  can periodically attempt to send transmissions to each other to check the status of the network (e.g., connected, failure and the like).  
      As discussed previously, a sending device  5105  can communicate with a first CP-S application, such as the CP-S application  5480  shown in  FIG. 61  to send data to one or more receiving devices  5110 . Similarly, a receiving device  5110  can receive data from multiple sending devices  5105 . As shown in  FIG. 61 , the sending device  5105  can continue to send data to a receiving device  5110 , such as the second receiving device  5485 , regardless of the status of the transmission of data between the sending device  5105  and another receiving device  5110 , such as the first receiving device  5490  whose data transmission has experienced an interruption  5495 .  
      K. Data Organizing, Sorting, Routing and Exporting  
      The EIMA system  100  according to some embodiments of the present invention can include a method and application for organizing data of any type and in any form, such as items, item information, session information, and the like. The method and application can also sort and route data, and/or can be used for the acquisition and migration of data. As mentioned previously, in some embodiments the EIMA system  100  can accept any type of data from a variety of different input devices that can be remote, local, internal to the system  100  or external to the system  100 . As also mentioned, in some embodiments the EIMA system  100  can store, recompose and/or reformat data received from input devices, and in some cases can output the recomposed or reformatted data.  
      In some embodiments, the EIMA system  100  can receive various data from one or more data-input devices  105 , and implements one or more sorting applications  5505  to acquire, sort, route, migrate, output and/or store the data, whether recomposed, reformatted, or in their original form, into one or more peripheral devices  120 .  
      For example, a user may wish to have data routed and stored in one or more particular manners, any of which can be enabled by sorting applications  5505  according to the present invention. In the case of a financial institution by way of example only, the financial institution may receive large amounts daily of financial items, such as check images, deposit/withdraw requests and the like, that have been or will be processed by the financial institution and any affiliates, division, branches or entities related to that particular institution. The large amounts of data need to be routed and stored in a fairly accessible manner. Such data can be stored on various types of storage media, such as on RAID, optical storage, or other random accessible media, on tape or on other serial media, and the like. Typically, random accessible media can be more costly than serial media, but can allow for faster retrieval of data stored thereon. With the limitations and characteristics of available media types in mind, the financial institution may wish to employ different types of media for data having different characteristics (e.g., age, type, size, format, and the like). For example, the financial institution may want to store all data of a current month on random accessible media for short-term, quick retrieval storage, and then route the data to serial accessible media at the end of the current month for long term, slow retrieval storage.  
      Another exemplary application (in which data sorting applications  5505  according to the present invention can be employed) relates to the manner in which data is organized by a user. A user may wish to have data organized in one or more particular manners, any of which can be enabled by sorting applications  5505  according to the present invention. In the case of a financial institution by way of example only, the financial institution may wish to organize items or transaction data in each media according to various criteria, such as account number, date, and the like. The financial institution can implement one or more sorting applications  5505  to organize the items or transaction data as it desires. Such organization can include the acquisition, analysis, sorting, routing, migration, formatting, recomposition, output, and/or storage, of the transaction data or items (among other possible functions performed on the transaction data or items) as discussed in greater detail below.  
       FIGS. 62-74  illustrate a number of different embodiments of the EIMA system  100  (shown in varying degrees of detail) in which the EIMA system  100  implements one or more sorting applications (also referred to as “sorters”)  5505 . The sorters  5505  can be employed to assist in acquiring data from various inputs internal or external to the system  100  and to migrate the data to various locations or destinations  5510  (among other possible sorter functions described above). The sorter(s)  5505  can be resident in any one or more components of the EIMA system  100 , such as in a server (e.g., the host server  110 ), a peripheral device (e.g., peripheral device  120 ), a device controlling or monitoring one or more of the peripheral devices  120 , a workstation (e.g., workstation  115 ), an archive device, or another system component. The destination  5510  for a particular piece of data can be a local destination, such as local destination  5515  (e.g., a location within the peripheral device  120  or other component running that particular sorter  5505 ) or a remote destination, such as remote destination  5520  (e.g., a location within a remote peripheral device  120  or any other component remote from the sorter  5505 ). In some embodiments, local destinations  5515  can refer to those destinations included within the EIMA system  100  (e.g., internal destinations or locations), and remote destinations  5520  can refer to those destinations not included within the EIMA system  100  (e.g., external destinations or locations). Also, the destination  5510  for a particular piece of data can be a local destination with respect to a system component (e.g., a location within the peripheral device  120  or other component running that particular sorter  5505 ), or a remote location with respect to a system component (e.g., a location within a remote peripheral device or any other component remote from the sorter  5505 ).  
      As mentioned previously, one or more sorters  5505  can route data from various sources to one or more appropriate destinations  5510 . Also, one or more sorters  5505  can route commingled image and index data from various internal and external sources to one or more appropriate destinations  5510 . For example, after an external party (e.g., device, network, system, and the like that is external to the EIMA system  100 ) captures a first data and inputs the first data into the EIMA system  100 , a sorter  5505  included in the EIMA system  100  can “read” the first data, format the first data to be compatible with the system  100 , and route the first data to an appropriate destination  5510 .  
      In any of the embodiments shown in  FIGS. 62-74 , the sorter  5505  can include a rules engine or rules executor  5525  and one or more instructions or rules sets  5528 . A rules set  5528  can further include one or more instructions (e.g., rules, commands, software loops, and the like) for acquiring data, sorting data, routing data, migrating data, outputting data, storing data addressing data, identifying data (e.g., identifying particular documents or types of documents), demultiplexing commingled acquisition data (e.g., taking an item having a text file and an image file, separating the two files and routing, addressing, or identifying each file separately), multiplexing acquisition data (e.g., taking a text file and a corresponding image file, combining the two files and routing, addressing or identifying the combination of the two files) replicating data (e.g., copying data to additional destinations), formatting data, transaction branding (e.g., branding or identifying various data belong to the same transaction, as discussed below), auditing, and the like.  
      For example, a rule set  5528  can be an XML-based file having various instructions or rules that a particular sorter  5505  executes. In other embodiments, other types of files (e.g., based on other languages or file formats) can be employed as desired. The rule set(s)  5528  can be accessible to users through one or more application menus included in the EIMA system  100 , such as application menus accessible via a workstation  115 , input data device  105 , or server  110 . In some embodiments, each sorter  5505  can have one or more exclusive rule sets  5528 . In other embodiments, some rule sets  5528  are accessible by and can be used by multiple sorters  5505 , and in further embodiments, all rule sets  5528  are accessible by and can be used by all sorters  5505 .  
      The rule set  5528  can include any number and type of different rules and/or subfiles further defining the rule set  5528 , one or more rules within the rule set  5528 , or still other rules (e.g., outside of the rule set  5528 ). As will now be described in greater detail, a rule set  5528  can include any one or more of the following elements (among others): chains, paths, documents, evaluating rules, handling rules, routing rules, accumulating rules, reporting rules, naming rules, identifying rules, transaction rules, and the like. By way of example only, the sorter  5505  illustrated in  FIG. 62  includes a XML-based file rule set  5528  having at least one of each of these elements.  
      A chain of the rule set  5528  (e.g., the XML-based file) can be a portion of the rule set  5528  that enables the rules executor  5525  to perform a set of instructions in a certain order. The instructions can be various rules, such as any of the rules mentioned above with regard to the rule set  5528 .  
      In some embodiments, a path includes a subset of a chain that includes the individual instructions and the order in which each rule or instruction will be executed.  
      Documents, for example, can be references within the rules that define various input and output data types and can further provide instructions for parsing the various data types. A number of different types of documents can be employed by the sorter  5505  to process data. For example, an input “document” can include a capture data stream or item providing instructions on how to parse information from an item received by the sorter  5505  or how to parse information from other data received by the sorter  5505 . In some embodiments in which items being processed are recognized as checks, such an input document labeled “check” can include definitions for various check fields, such as the MICR line, payee name, account number and the like, and can include instructions on how to parse the various fields of the item (e.g., check). As another example, an output “document” can be a field map as to how data will be incorporated into certain outputs. As a further example, an input document labeled “identification card” can included definitions for various identification card fields, such as the identification picture, name, address, and the like, and can include instructions on how to parse the document (e.g., identification card). In still further examples, other documents referenced by the sorter  5505  to process data include documents for processing driver&#39;s licenses, insurance cards, communication transmissions, electronic mail messages, and other items.  
      In some embodiments of the present invention, evaluating rules are employed by the rules executor  5525  to perform comparisons of data being processed by the sorter  5505 . In some instances, the evaluating rules perform comparisons such as equal to, greater than, less than, greater than or equal to, less than or equal to, one of, and the like. Evaluating rules can be linked with common binary expressions such as “AND” and “OR” expressions in some embodiments, and can further be defined to perform more complicated comparisons. In some embodiments, the evaluating rules can perform comparisons and can assign a confidence level according to the comparison.  
      Handling rules are instructions or rules on how to process modify, and manage various types of data received for processing by the sorter  5505 . For example, handling rules can include instructions or commands that manipulate the data itself, such as rules to format different types of data, to create duplicate copies of certain data, to separate data (e.g., parts of a data item), and the like.  
      Routing rules can be instructions or rules that determine the destination(s) of output data. A destination can be local or remote. Data can be sent to any number of local and/or remote destinations, and to any combination of such destinations as desired. By way of example only, a destination can be a local or remote GIA, file system, archive, IP address, peripheral device, and the like. Routing rules can also be implemented for exportation of data to a user. For example, routing rules can be executed to route all data pertaining to a particular client during a certain time period to one or more destinations specified in the routing rules (e.g., a local or remote user&#39;s archive, CD-ROM, and the like) in one or more manners also specified in the routing rules (e.g., by e-mail, facsimile, and the like).  
      The accumulation rule can include various instructions for accumulating information about data sorted by the system  100 . For example, an accumulation rule can include such rules as an audit rule or a statistic rule. The audit rule can create an audit trail of input data and/or output data. The audit rule can further be defined to only create an audit trail of certain types of input data and/or output data. The statistic rule can return information on any statistic for input data and/or output data. For example, the statistic rule can calculate how much data (e.g., how many items) has been sorted by a particular sorter  5505  over a certain period of time, can calculate the percentage of various types of data input to and/or output from the system  100 , and can perform other statistical functions. The accumulation rules can also include any other type of rules employed to generate historical and/or bibliographical information about input and/or output data. Data produced by the accumulation rules can be used for the report rules (described below).  
      Report rules can include instructions for the rules executor  5525  to produce one or more reports, such as a text report or an XML-based report. Such reports can be prepared to log and/or determine any number of different types of activities of one or more sorters  5505 , and can also or instead be prepared to provide information regarding the data processed by the sorter(s)  5505 . By way of example only, one or more report rules can be used to provide an audit trail for data movement, the amount of data sent to a system component (e.g., a particular storage device) over a period of time, or for other purposes.  
      Naming rules can be used to “build” files or outputs for reports, audit trails, or other information generated by the accumulation rules, report rules, or otherwise by the rule executor  5525 . The naming rule can allow the rule executor  5525  to properly identify files or outputs it creates. In some instances, the naming rule can be used to rename data (e.g., reformatting data, adding identification information (such as a header address or other information) to the data, and the like).  
      Identifying rules can include instructions for the sorter  5505  regarding how to identify different types of data (e.g., as defined by the document rules) and can include instructions regarding which rules to apply for that particular type of data. For example, the identifying rules can include instructions for the rule executor  5525  regarding how to identify and process “check” data as defined in the document labeled “check” (described above). Identifying rules can also add information from one piece of data to another piece of data, such as to associate one or more items or other data with other items or data. In some embodiments, the identifying rules can include instructions for separating and identifying parts of a data input or output. Also, in some embodiments the identifying rules can include instructions that implement one or more documents.  
      In some embodiments, the EIMA system  100  is capable (through a sorter  5505  or otherwise) of attaching one or more identifiers to data being processed in the EIMA system  100 , thereby helping to identify, categorize, and/or sort the data. Alternatively or in addition, an identifier can help to associate data with other data. To this end, transaction rules can include instructions regarding how to attach certain types of transaction identifiers to certain types of data. In some embodiments, transactions can include checks, signature cards, loan documents, identification cards (e.g., driver&#39;s licenses, identification badges, and the like), account statement pages, remittance invoices, insurance policies, G/L tickets and adjustments, and the like. By enabling the sorter  5505  to identify, categorize, and/or sort a data provided with a transaction identifier (or to associate the data with other data), data can be organized to any extent desired.  
      By way of example only, a transaction identifier can allow a sorter  5505  the capability to organize data within a peripheral device  120  (such as a database) or any other system component according to transaction type. As another example, a transaction identifier can enable organization or association of items by a common deposit, a common loan application, or any other common identifier regardless of whether the data is the same or different in class or type. For example, a user may deposit several checks at a financial institution using a single deposit slip. When each item (e.g., each check and the single deposit slip) is captured by the EIMA system  100  and received by a sorter  5505 , the sorter  5505  can provide the same transaction identifier to each item that was included in the deposit transaction (e.g., each check and the single deposit slip). In this manner, the items can be stored, queried and searched for by the transaction identifier.  
      The rule set(s)  5528  included in a sorter  5505  can have any number of additional rules defining other functions to be performed in processing data in the EIMA system  100 . In some embodiments, the rule set(s)  5528  can be modified and/or rewritten to include additional functional rules and/or to modify existing rules. If desired, the rule set(s)  5528  can have any format (e.g., an XML-based format in some cases) allowing a user to easily access and modify the rule set  5528 .  
      For example, other types of rule set(s)  5528  can include additional rules for handling and processing image replacement documents (“IRDs”) (e.g., an electronic truncated form of an electronic check) as well as checks. Such rule set(s)  5528  can be able to recognize various stages (e.g., original forward processed, subsequent forward processed, original return process, subsequent return process, and special IRD requests) of generation of IRD processing, and how to process the IRD during each stage.  
      The number of rules and the type of rules can vary from sorter  5505  to sorter  5505  in the EIMA system  100 . In some embodiments, the number of rules  5528  executed by the rules executor  5525  depends upon the type of data processed. In other embodiments, the rules executor  5525  executes all of the rules  5528  for all data processed. Also, in some embodiments, the type of rule(s)  5528  executed by the rules executor  5525  depends upon the type of data processed. The rules executor  5525  can automatically execute the appropriate number and/or type(s) of rules  5528  when data is processed, or can be commanded to do so (such as, for example, by a user).  
      The EIMA system  100  can include one or more sorters  5505  that may run on any of the components of the EIMA system  100 . In some embodiments (such as those illustrated in the figures), one or more sorters  5505  run on one or more peripheral devices  120  in the EIMA system  100 , such as a database, a device that controls or monitors the peripheral device  120 , or another type of peripheral device. The sorter(s)  5505  can run as a service on a particular device, and in some cases can boot and run automatically or when a user boots the device and/or opens or runs another application, service or program (e.g., an operating system or another software program). In some embodiments, the sorter(s)  5505  only runs when a user commands the sorter(s)  5505  to do so.  
      Two exemplary embodiments of the EIMA system according to the present invention are illustrated in  FIGS. 62 and 63 . In both embodiments, the EIMA system  100  includes a single or main sorter  5530  to manage and route all incoming data (although additional sorters  5505  can be employed as described above). The main sorter  5530  can manage and route the data to one or more peripheral devices  120  or to other components within and/or outside of the EIMA system  100 . As mentioned previously, the main sorter  5530  can be resident in a server, such as, for example, the host server  110 ; a peripheral device, such as, for example, one of the peripheral devices  120 ; a device controlling or monitoring one or more of the peripheral devices  120 ; a workstation, such as, for example, the workstation  115 ; an archive device; or another component within or outside of the EIMA system  100 . In each of the exemplary embodiments of  FIGS. 62 and 63 , the main sorter  5530  runs on an archive device  5535  for storing data being processed. The archive device  5535  can include, but is not limited to, a database, an optical storage disk, RAID, tape and the like.  
      As shown in  FIGS. 62 and 63 , the main sorter  5530  in each of the illustrated exemplary embodiments can receive incoming data  5540  from one or more data-input devices  105 . The main sorter  5530  can route the data to one or more appropriate destinations  5510  according to the rules  5528 . In both embodiments, the main sorter  5530  can route data to one or more local destinations  5515  and/or to one or more remote destinations  5520 . However, in the exemplary embodiment of  FIG. 62 , the main sorter  5530  can include a set of rules, such as rule set  5528 , that can allow the rules executor  5525  to exhibit the behavior of a Generic-Input Application (GIA) in order to function with existing storage devices that implement GIAs. In the exemplary embodiment of  FIG. 63 , the main sorter  5530  can route data to local destinations  5515  and/or remote destinations  5510  via local GIAs  5550  and/or remote GIAs  5555 .  
      In other embodiments, the EIMA system  100  can include multiple sorters  5505  to manage and route incoming data. For example, the EIMA system  100  can include a sorter  5505  in any number of the peripheral devices  120  and/or other EIMA system components (e.g., workstation(s)  115 , input data device(s)  105 , server(s)  110 , and the like), or can include a dedicated sorter  5505  in each peripheral device  120  and/or other EIMA system component. The EIMA system  100  can also include multiple sorters  5505  in one or more of the peripheral devices  120  and/or other EIMA system components. By way of example only, a server  110  can include two sorters  5505  to handle and sort two different types of data. The server  110  can also include a main sorter  5530  to sort and route data to one or more other sorters  5505  that are local or remote to the main sorter  5530 . The other sorter(s) can then ultimately sort and route data to one or more final destinations  5510 .  
      As another example, in some embodiments (such as the embodiment illustrated in  FIG. 64 ), the EIMA system  100  includes a main sorter or first sorter  5530 . The first sorter  5530  can be a master sorter that controls and/or overrides additional sorters  5505  included in the system  100 . Alternatively or in addition, the first sorter  5530  can be an interface or an intermediate sorter that can route data from one or more data-input devices  105  or from any other device. In some embodiments, the first sorter  5530  runs on a host server  110 , although the first sorter  5530  can run on any other EIMA system component as desired. Also, in some embodiments, the first sorter  5530  can process or route all data that is inputted into the system  100 . In other embodiments, the first sorter  5530  routes or processes some of the data inputted into the system  100 . In either case, the first sorter  5530  can receive data routed by additional sorters  5505 .  
      In the illustrated exemplary embodiment of  FIG. 64 , the main sorter  5530  receives all incoming data  5540  from one or more data-input devices  105 . In this embodiment, the main sorter  5530  runs on a host server  110  of the EIMA system  100 . However, as described above, in other embodiments, the main sorter  5530  runs on another device, such as, for example, another server, a peripheral device  120  (as shown in  FIG. 63 ), a workstation  115 , and the like. With continued reference to the exemplary embodiment of  FIG. 64 , the main sorter  5530  can route the data  5540  to one or more additional sorters  5505  located on the host server  110 , on another peripheral device  120 , on any other component of the EIMA system  100 , and/or on a device external to the EIMA system  100 . In some embodiments, the main sorter  5530  can also route the data  5540  directly to one or more local or remote destinations  5510 .  
      In the exemplary embodiment of  FIG. 64 , the main sorter  5530  can route data  5540  to a second sorter  5560  located on a peripheral device  120  (such as a first archive database  5565 ) and/or to a third sorter  5570  located on another peripheral device  120  (such as a second archive database  5575 ). The main sorter  5530  can include a rules executor  5525  implementing a first rule set  5528 . Also shown in  FIG. 64 , the second sorter  5560  can include a rules executor  5525  implementing a second rule set  5568 , and the third sorter  5570  can include a rules executor  5525  implementing a third rule set  5578 . In some embodiments, each rule set in the EIMA system  100  (e.g., the first, second, and third rule sets  5528 ,  5568 ,  5578  in the embodiment of  FIG. 64 ) includes the same rules. In other embodiments, one or more rule sets  5528 ,  5568 ,  5578  differ from the other rule set(s)  5528 ,  5568 ,  5578 . Also, one or more of the rule sets  5528 ,  5568 ,  5578  can be formatted differently and/or can be accessible in a different manner (e.g., through a different application) than the other rule sets  5528 ,  5568 ,  5578 .  
      As shown in  FIGS. 65 and 66 , the first sorter  5530  can be included on a peripheral device  120 , such as an archive database  5610  having local destinations  5515 , and can route data  5540  to one or more additional sorters  5505 , such as a second sorter  5620  located on a second archive database  5620  and/or a third sorter  5630  located on a third archive database  5635 . The sorters  5505  can also interface and route data  5540  to one or more GIAs  5650  included on one or more of the peripheral devices  120  (see, for example,  FIG. 65 ).  
      As mentioned previously, the sorter  5505  can receive data from various sources, internal or external to the EIMA system  100 . In some embodiments, the sorter  5505  can also receive commingled data from one or more sources internal or external to the EIMA system  100 . By way of example only, the EIMA system  100  can receive commingled data  5680  (e.g., combined check image and issue file, for example) from an external party. In this exemplary embodiment, the sorter  5505  can separate commingled item  5680  and/or can extract one or more parts from the commingled item  5680 . In either case, the sorter  5505  can process a commingled item  5680  to produce one or more sub-items from the commingled item  5680 . Sub-items or parts of a commingled item  5680  can be processed in the EIMA system  100  in any of the manners described above and using any of the system structures described above with reference to the embodiments of  FIGS. 62-66 .  
      Any part of separated commingled data or a data portion can be routed to any destination  5510  desired. By way of example only, and with reference to  FIG. 67 , a sorter  5505  included in an archive database  5690  (or in any other EIMA system component) can receive commingled data  5680  from any location, internal or external to the EIMA system  100 . In some cases, the commingled data  5680  is provided by an external device and the commingled data  5680  can be formatted, named, and/or encoded using a different protocol than the EIMA system  100 . The sorter  5505 , according to some embodiments of the present invention, can parse the commingled data  5680  in accordance with the rule set  5528 , and can extract one or more portions of data (e.g., a first data portion  5705  and a second data portion  5710 , a first item from another item, and the like).  
      As shown in  FIG. 67 , the sorter  5505  can route the first data portion (e.g., a first sub-item)  5705  to a first destination  5720  and can route the second data portion (e.g., a second sub-item)  5710  to a second destination  5725 . The destinations  5720 ,  5725  can be any local or remote device, application, system or other location. In the embodiment of  FIG. 67  for example, the first destination  5720  can be a local destination  5515  within the peripheral device  120  (such as a first database collection within the archive database  5690 ), and the second destination  5725  can also be a local destination  5515  within the peripheral device  120  (such as a second database collection within the archive database  5690 ). As shown in  FIG. 68 , in some embodiments the sorter  5505  can route a data portion (e.g., sub-item  5705  and/or sub-item  5710 ) to multiple destinations  5510 .  
      In some embodiments, the EIMA system  100  can include a combination of sorters  5505  for handling various types of data. By way of example only, the EIMA system  100  can process data pertaining to financial transactions, such as check images, deposit slips, commingled data (e.g., data containing one or more check images and one or more issue files, for example), issue files, IRDs, and the like. In this example, the EIMA system  100  can include one or more sorters  5505  for handling non-commingled data only, one or more sorters  5505  for handling commingled data only, one or more sorters  5505  for handling portions of commingled and/or non-commingled data only, one or more sorters  5505  for handling non-commingled data and commingled data, one or more sorters  5505  for handling commingled data and portions of non-commingled data, one or more sorters  5505  for handling non-commingled data and portions of commingled data, one or more sorters  5505  for handling selected data, a combination of the previously-listed sorters, or the like.  
      In some embodiments, commingled data (e.g., those received from an external party  5750  or from any other source) can proceed to two or more sorters as they are processed in the EIMA system  100 . For example, and with reference to  FIG. 69 , commingled data  5750  from an external party can be imported by a first sorter  5755  included in a peripheral device  120  or other system component (e.g., a first archive database  120  in  FIG. 69 ), which can route data portions or separated parts of commingled data to a second sorter  5790  included in a second, external peripheral device  120  or other external component (e.g., a second, external archive database  5795  in  FIG. 69 ) and/or to a third sorter  5800  included in a third, external peripheral device  120  or other external component (e.g., a third, external archive database  5805  in  FIG. 69 ). The first sorter  5755  can route sub-items or other portions of data pertaining to a first criteria (e.g., data for storage at “SITE A”) to a local destination  5515  on the first database  5780  (e.g., “SITE A”), and/or can route sub-items or other portions of data pertaining to other criteria (e.g., data for storage at “SITE B” or “SITE C”) to one or more other sorters  5505  (e.g., the second sorter  5790  of the second database  5795  and/or the third sorter  5800  of the third database  5805 ) included in other external peripheral devices  120  or components (e.g., “SITE B” or “SITE C”).  
      Regardless of whether data is received from within the EIMA system  100  or from an external party or location, some embodiments of the present invention provide one or more sorters  5505  that store data within the EIMA system  100  while transmitting a copy thereof to another location  5510  (or transmit the data to another location  5510  while storing a copy thereof within the EIMA system  100 ). By way of example only, the sorter  5755  in  FIG. 70  can receive data from an external party  5750 , store the data in one or more destinations  5510  within the system  100  and transmit a copy of the data to another destination  5510 . In this exemplary embodiment, the sorter  5755  receives data relating to various customers, and routes the data to a destination  5510  internal to the EIMA system  100 . In addition, the sorter  5755  transmits the data pertaining to a certain customer to that customer&#39;s own destination  5820 , such as a server or archive database of the customer.  
      Also, a sorter  5505  according to the present invention can receive data from multiple sources and can route and store data in a redundant manner. As shown in  FIG. 71  by way of example only, a first sorter  5850  included on a first peripheral device  5855  (or other component of the EIMA system  100 ) can receive data from a first input source  5858 , and a second sorter  5860  included on a second peripheral device  5865  (or other component of the same EIMA system  100  or a different system) can receive data from a second input source  5868 . The first input source  5858  can input data for the first sorter  5850  as well as the second sorter  5860 . Similarly, the second input source  5868  can input data for the second sorter  5860  as well as the first sorter  5850 . That is, both the first input source  5858  and the second input source  5868  can input a commingled data stream of first sorter data and second sorter data. Upon reception, the first sorter  5850  can store the first sorter data (e.g., data pertaining to “SITE A”) on the first peripheral device  5855  and route the second sorter data (e.g., data pertaining to “SITE B”) to the second sorter  5860 . Upon reception, the second sorter  5860  can handle the commingled data stream in a similar manner as the first sorter  5850 .  
      Also shown in  FIG. 71 , in some embodiments the first sorter  5850  can store the entire commingled data stream from the first input source  5858  (e.g. all data pertaining to “SITE A” and all data pertaining to “SITE B”) in the first peripheral device  5855  and can route the entire commingled data stream from the first input source  5858  to the second sorter  5860  for redundant storage in the second peripheral device  5865 . Likewise, the second sorter  5860  can store the entire commingled data stream from the second input source  5868  in the second peripheral device  5865  and can route the entire commingled data steam from the second input source  5868  to the first sorter  5850  for redundant storage in the second peripheral device  5865 . In some embodiments, the first sorter  5850  or the second sorter  5860  can store and route only certain amounts or types of data for redundant storage in accordance with one or more rule sets  5528 . In other embodiments, both the first sorter  5850  and the second sorter  5860  can store and route only certain amounts or selected types of data for redundant storage in accordance with one or more rule sets  5528 . In either case, the rule set(s)  5528  in some embodiments are accessible by a user to set or modify the number and/or types of data for such redundant storage.  
       FIG. 72  also illustrates redundant storage with multiple sorters  5505  and destinations  5510 . As shown, the exemplary EIMA system  100  of  FIG. 72  can receive commingled data from multiple input sources  5870 . The EIMA system  100  can include a first archive database  5875  (e.g., “SITE A”), a second archive database  5880  (e.g., “SITE B”) and a third archive database  5885  (e.g., “SITE C”), and a sorter  5505  running on or otherwise associated with each database. In an exemplary embodiment, the sorters  5505  can route and sort the commingled data such that all data is stored on the first database  5875  and the second database  5880  and that only the data pertaining to (or for storage on) the third database  5885  are stored on the third database  5875 . In other embodiments, this EIMA system  100  can be re-configured so that any other combination of data can be stored in each database ( 5875 ,  5880 ,  5885 ). Also, any number of input sources  5870  and any number of sorters  5505  capable of storing data on any number of associated EIMA system storage components (e.g., databases  5875 ,  5880 ,  5885 ) can be employed for redundant or non-redundant data storage as desired.  
       FIG. 73  illustrates yet another embodiment of an EIMA system  100  similar to the redundant storage system shown in  FIG. 72 . However, the sorters  5505  associated with each database are included in dedicated servers  5890  (rather than on the databases  5875 ,  5880 ,  5885  themselves). As discussed above, in other embodiments the sorters  5505  can run on any other component of the EIMA system  100 , or on a combination of different types of components of the EIMA system  100 . In the embodiments illustrated in  FIGS. 72 and 73 , each sorter  5505  can implement the same or different rule sets  5528 .  
      In some embodiments, the sorter  5505  can also be implemented for exporting data from one or more archives and even from the EIMA system  100 . For example, one or more sorters  5505  can further include one or more rules  5528  for storing or copying data onto various portable media types, such as, for example, compact disks (e.g., CD-ROMs) or for storing or copying data to a remote location internal to or external from the system  100  (e.g., via batch transfer of such data performed on a regular schedule or when triggered by any event, via a continuous feed of such data, and the like). The one or more rules  5528  can be implemented during sorting of the data (e.g., when input data is being sorted to an archive) and/or during retrieval of the data (e.g., when a query requires retrieval of data from the archive).  
      L. Tape Migration  
      As shown in  FIG. 74 , the use of one or more sorters  5505  in an EIMA system  100  according to the present invention can produce a more efficient process or method for routing and storing large amounts of data through the use of the rules executor  5525  and rule sets  5528  (which can be dynamic rules sets in some embodiments). Such sorter(s) can enable the EIMA system  100  to route and migrate selected data (e.g., those meeting certain criteria such as those of a particular customer, those relating to a particular type of transaction, and the like) in particular manners rather than routing and migrating entire volumes of data in a non-discriminating fashion.  
      For example, in many conventional systems, data migration from fast or short-term storage to slower or long-term storage involves the movement of all related and unrelated data (e.g., all transactions of a financial institution) occurring over a business day or other period of time. Such migration can result in inefficient long-term storage of such data, making later reference and retrieval of such data difficult and cumbersome. In the exemplary embodiment of  FIG. 74 , data (e.g., items) for various customers are ingested into a fast or short-term first archive  6005 , such as tier one RAID for a specified retention period, and are ingested into the archive  6005  on a daily bases (e.g., once every business day). In this example, the retention period for ingested data is thirty-five (35) business days, although other periods of time are possible. At the end of this period, the data is migrated to another archive  6010 , such as a slower or long-term tape silo. Accordingly, each day a relatively large amount of related and unrelated data (representing a set of items ingested in one day or “business cycle”) is migrated to another archive  6010 . This standard migration process can be typically implemented twenty (20) times each month (one time for each business day), producing twenty (20) tapes a month or two-hundred forty (240) tapes a year. Rapid and simple reference to any particular data (e.g., all items relating to a particular customer, all items relating to a particular transaction occurring over a period of time, and the like) on such tapes is generally not possible.  
      However, by employing one or more sorters  5505  according to the present invention, data can be migrated on a more intelligent basis (i.e., after being sorted or otherwise organized to some extent via the sorters  5505 ). For example, a sorter  5505  in any of the EIMA system embodiments described herein can migrate sorted data to a secondary archive  6010 . Because the data have been processed by the sorter(s)  5505 , and in some embodiments have been routed, stored, filed, and/or identified by the sorter(s)  5505 , the data can be migrated based upon customer name or identifier, account, transaction type, transaction amount, date, time, or any other criteria or combination of criteria. In the second exemplary embodiment of  FIG. 74 , for example, the data can be migrated based upon customer, thereby enabling a smaller amount of data (i.e., for one customer rather than all customers) to be migrated less frequently. In this embodiment, data for each customer are migrated once a month, producing one tape a month or twelve (12) tapes a year—due to the ability of the sorter(s)  5505  to process and route data as described above. Reducing the number of long-term storage tapes increases the speed and efficiency of tape queries for an individual customer (since there are less tapes to query and search). For example, if a customer&#39;s data for thirty (30) days can be written to only a single tape, then a query spanning one year (e.g., a request to pull certain data for that customer over one year) will invoke only twelve (12) tape mounts.  
      Migration of data as just described can be performed regardless of the location of the data to be migrated and regardless of the destination location of such data. For example, the data being migrated can be in tier one RAID at one location operated or controlled by one user and can be migrated to a tape silo at another location operated or controlled by the same or a different user internal to or external from the system  100 .  
      M. Multidimensional, Distributed and Transactional Archives  
      In some embodiments of the sorter  5505  according to the present invention, the sorter  5505  can route, migrate, and/or store data as described above based upon any number of different data parameters. For example, in EIMA systems  100  used for banks and other financial institutions, such parameters can include, without limitation, customer number, account number, transaction amount, transaction date, transaction time, routing number, document identification number, and the like. The ability to route, migrate, and/or store data based upon two or more of these data parameters enables the creation and maintenance of multi-dimensional archives, each having any number of dimensions that permit data storage in any arrangement desired, and in some cases data query in each dimension or combination of dimensions.  
      A multi-dimensional archive  7500  is presented by way of example only in  FIG. 75 . In this archive  7500 , data can be arranged according to certain parameters. The table  7510  illustrated in  FIG. 75  includes various data pertaining to certain items (e.g., checks). Lines  1 - 7  of the table  7510  contain data from seven different checks paid from a single account. As also shown in  FIG. 75 , the data from table  7510  is arranged by one or more sorters  5505  in the multidimensional archive  7500  by customer data (or account data), amount data, or date or time data. By sorting and storing data in this manner, information can quickly be retrieved or accessed through different criteria or parameters. For example, data can be accessed by a date parameter as shown in  FIG. 76 , can be accessed by a location parameter as shown in  FIG. 77 , or can be accessed by an account parameter as shown in  FIG. 78 . It will be appreciated that other archives having the same or different numbers of dimensions corresponding to any number of different data parameters can be created and maintained, any of which enable the routing, migration, and/or storage of data by one or more sorters  5505  based upon such parameters, and which enable the query and retrieval of data based upon any one or more of such parameters.  
      As shown in  FIG. 79 , the EIMA system  100  can include one or more multidimensional archives  7500  to organizing and retrieving data (e.g., items). According to one or more rule sets  5528 , in some embodiments one or more sorters  5505  route and store data into the multidimensional archives  7500  through a data staging facility  7515 . That is, the data staging facility  7515  can be the interface between the sorter(s)  5505  and the multidimensional archives  7500 . As shown, the data staging facility  7515  can write and store data to a media or item database  7516  and to a description database  7518 . In some embodiments, the item database  7516  (which is a multidimensional database or archive  7500 ) stores and arranges the data according to certain parameters, and the description database  7518  (which is also a multidimensional database  7500 ) stores a description of the arrangement and data of the media database  7516 . The data staging facility  7515  can store the data in the item database  7516  and write a description to the description database  7518 .  
      To retrieve data stored in the multidimensional database(s)  7500 , an application  7520 , such as NetQuery and the like, can produce a query for one or more archives  7500  to retrieve certain types of data. A processor  7530 , such as a multidimensional query processing program (“MQP”) as shown in  FIG. 79 , can process the query on any one or more attributes or parameters (e.g., account number, date, location, and the like). In some embodiments, the processor  7530  accesses the description of the item database  7516  through the description database  7518 , thereby obtaining the layout of the database or archive  7500  and how the data is arranged or clustered within the archive  7516 .  
      When the processor  7530  identifies the data that satisfy the query, the processor  7530  can send a request for the appropriate data (e.g., one or more check images or check files) from the database  7516  to a media retrieval facility  7535 . The media retrieval facility  7535  can retrieve the data of a specific query as defined or requested by the processor  7530 . The media retrieval facility  7535  can access or retrieve the data for a query using any one or more attributes of the data. The retrieval facility  7535  or another system component can then either display the data (e.g., results of the query) for a user or can send the data to another application or program for display, printout, or other presentation.  
      The EIMA system  100  can also include a distributed (or distributive) archive for managing various local archives within the system  100 . The local archives can be arranged throughout a geographic location of any size. The distributed archive can provide one or more users an augmented, unified view of and access to all of the data available at each local archive.  
      In some embodiments, such as the embodiment illustrated in  FIG. 80 , the EIMA system  100  includes one or more applications  7705  for sorting, storing, managing or retrieving data to or from one or more archives, such as, for example, one or more local archives  7710 . The applications  7705  can include one or more sorters  5505 , a NetQuery application, a query application, and the like. In some embodiments, the applications  7705  can be included at a particular local site (e.g., a site having a local archive) and may only have direct access to that corresponding local archive  7710 , such as, for example, application  7720  and local archive  7725  in the example illustrated in  FIG. 80 .  
      The system  100  can also include one or more distributed archives  7730 . The distributed archives  7730  can provide one or more services, such as a repository service, a set service and an index service (all previously discussed) on a distributed level. The distributed archives  7730  allows one or more applications  7705  to have access to all of the local archives. For example, the distributed archive  7730  can include a distributed index service which includes the index service of each local archive  7710  in a unified view (e.g., accessible by any device providing a graphical user interface). As shown in  FIG. 80 , the distributed archive  7730  can run as an application on the local archives  7710 , providing a user with a unified view of the local archives collectively, singularly, or in any combination of the local archive services.  
      As discussed previously, the system  100  may employ redundant storage to back-up various data. If a malfunction occurs at the local archive  7725 , the application  7720  can access any redundant and remote data storage through the distributed archive  7730 , and in some embodiments does so automatically. As shown in  FIG. 81 , the distributed archive  7730  can be available to at least one application at each local site  7740 , as well as other applications resident at different local sites  7740 .  
      In some embodiments, an archive (e.g., database) can also be sorted or organized by transactions. In these embodiments, one or more sorters  5505  can include a transaction identifier for each item (such as a financial document) by assigning the same transaction identifier to item belong to the same transaction. The items can be stored in the archive by one or more parameters including transaction identifier. In some embodiments, for example, items (e.g., checks) can be stored in an archive by a first parameter, such as a payee name or customer number, and can further be stored by the transaction identifier.  
      N. Query Applications  
      In some embodiments, the EIMA system  100  can provide various applications or methods for retrieving data from an archive, such as a tier one RAID storage or tier three tape storage. For example, the system  100  can include one or more query applications for retrieving data from one or more archives. The query applications can include application where the request is submitted from a remote user across the Internet or another network (e.g., NetQuery). Alternatively or in addition, the query applications can include an application where the request is submitted using query markup language (QML) in a text format. In such embodiments, a user can submit the request in a text format written in QML through an email, a graphical user interface (GUI) or another suitable input. The query applications can also include an application where one or more requests are submitted in batches for processing. In any of these embodiments, each query application can include similar rules  5528  as described above for processing and managing the queries. In some embodiments, the queries are managed and processed by one or more sorters  5505  in a similar manner as incoming data (described above with reference to sorter processing of incoming data). In other embodiments, the sorters  5505  can include one or more different rules  5528  for processing and managing queries.  
      As just mentioned, in some embodiments sorter(s)  5505  (described in greater detail above) can be used to process query requests from a user. By directly or indirectly accessing the EIMA system  100 , such as through a workstation  115  or other device, a user can request the retrieval of particular data or data that satisfies certain criteria (e.g., all checks issued on a certain day from a certain account number). Employing one or more of the rule set(s)  5528  used to organize the data in the system  100 , the sorter  5505  can intelligently route the request to the appropriate peripheral device  120 , server  110 , or other system component(s) that can process the request. In some embodiments, the sorter  5505  can also produce an audit trail or report of the requests, can record and produce statistics regarding the requests, and/or can delete or ignore duplicate requests that have already been processed.  
      As mentioned previously, the EIMA system  100  can also provide a query application that retrieves data from various queries or requests in batches. The query application can arrange the queries in batches or groups depending on certain parameters and criteria. An example of a query application and method of operation is illustrated in  FIG. 82 .  
      In some embodiments, the EIMA system  100  can provide various applications or methods for retrieving data from an archive, such as a tier one RAID storage, a tier three tape storage, or any other storage device or system. For example, the EIMA system  100  can provide a query application that retrieves data from various queries or requests in batches. The query application can arrange queries in batches or groups depending one or more parameters and criteria. An example of a query application and method of operation is illustrated in  FIG. 80 .  
      In an exemplary embodiment, the query application is used in a system, such as the EIMA system  100 , for data retrieval from a variety of large archives. For example, the EIMA system  100  can include multiple archives, such as multiple tier one RAID storage archives, hundreds of tier three tape storage archives, and hundreds of tier two optical disk storage archives. The query application of the present invention can reduce the amount of time spent by the EIMA system  100  to retrieve the data results of various queries submitted for system processing. As discussed in greater detail below, the query application of the present invention can also reduce the amount of reads or hits performed on the various archives.  
      As shown in  FIG. 80 , the EIMA system  100  can include a query application  8005  including one or more user interfaces, such as windows or sub-applications  8010 . In some embodiments, the query application  8005  can include a query window  8015  and a results window  8020  that are accessible by one or more users. The query application  8010  can run on one or more devices included in the system  100 , such as, for example, one or more servers  110 , one or more workstations  115 , one or more peripheral devices  120  and the like.  
      In some embodiments, the query window  8010  can provide an interface between the query application  8005  and one or more users. A user can enter one or more queries for particular data through the query window  8010 . In some embodiments, the query window  8010  can support multiple queries (e.g., data requests) from one or more users. The system can be configured to receive such queries from one or more users internal or external to the EIMA system  100 . For example, the query application  8005  can support one or more queries from external users through the communication protocol discussed earlier.  
      The query application  8005  can group various queries into one or more batches according to one or more query parameters. The query application  8005  can also group various queries into one or more batches and further group the queries into sub-batches within a particular batch based upon query parameters. In an exemplary embodiment of the present invention, the queries are arranged according to an initial query parameter, such as a priority. In this exemplary embodiment, a user can assign a priority code to one or more queries submitted to the query application  8005 . The priority code can include two values, such as a first value indicating high priority and a second value indicating low priority. In other embodiments, the priority code can include additional and/or different values (e.g., low, medium, or high priority, a priority selected from a scale of 1-10, and the like).  
      In further embodiments, the query application  8005  itself can assign a priority code to each submitted query according to various rule sets, such as the rule sets  5528  included in one or more sorters  5505 . In such cases, the rule sets  5528  can assign priority codes based upon any number of different parameters or combinations of parameters, such as query length (the anticipated amount of time the query will take to execute), the particular fields of the query, the data targeted by the query, the user submitting the query, the number of queries being submitted or already submitted by the user, the location of media that will need to be retrieved and searched to execute the query (e.g., searches requiring tape loading and unloading as opposed to searches requiring only reference to information in RAID, searches requiring fewer tape loading and unloading operations than other searches, and the like), the queries already being executed or to be executed by the query application  8005  (e.g., searches that are similar to others already being performed or to be performed, searches calling for reference to the same storage media, etc.), any combinations of these parameters, and the like. Alternatively or in addition, the query application  8005  can assign a priority code based upon such parameter(s) without reference to the rule sets  5528 .  
      If desired, queries can be batched using one or more query parameters, such as, for example, the user who requested the query, the time query was submitted, the selected fields of the query, the data targeted by the query, and the like. Using the same query parameter(s) or one or more different query parameters, the query application  8005  can further group the queries into one or more sub-batches.  
      In the exemplary embodiments in which a priority code is used for batching queries, the query application  8005  can organize the queries into two or more batches according to priority. As stated previously, the query application  8005  can also arrange the queries into additional batches according to the priority assigned to each query and/or can further organize the batches into sub-batches according to additional information. When the query application  8005  arranges the batches (e.g., a first group of batches including a high-priority batch and a low-priority batch), the query application  8005  can send one or more batches to a job queue  8030 .  
      By way of example only, the query application  8005  can send low-priority batches to the job queue for further grouping while the queries included in higher-priority batches are processed immediately to produce the results (e.g., data satisfying the query) for a user. Such results can be presented to a user in any manner, such as by displaying results in the results window  8020  in the illustrated embodiment of  FIG. 80 . Since the high-priority queries are processed immediately, the job queue  8030  can hold the low-priority batch until an appropriate time comes to process such queries. For example, an appropriate time can include a time after which the high-priority queries have been processed, a time in which little activity is conducted by the system  100 , a scheduled time, and the like. In other embodiments, the job queue  8030  can further group the high-priority and/or low-priority queries into sub-batches or additional batches.  
      In some embodiments, a scheduler  8040  (e.g., a scheduling application, routine, and the like) can determine when an appropriate time occurs for low-priority queries to be processed, or more broadly, for queries of any type to be processed. Also, in some embodiments, the scheduler  8040  can also determine in what order to process the queries and/or can further group queries or types of queries (e.g., grouped by priority, user, requested data, and the like) into sub-batches or additional batches. For example, the scheduler  8040  can further group low-priority queries according to the expected amount or type of data retrieved from such queries. In some cases, the scheduler  8040  can determine the amount of data to be retrieved and the location of the data to be retrieved for each query. For example, in some embodiments the scheduler  8040  can group and process the queries by where the retrieval data is located within one or more archives  8050 , such as RAID, optical disk, tapes, and the like. In these embodiments, the scheduler  8040  can access a certain optical disk or tape and retrieve the data pertaining to several queries rather than processing each query one at a time (which could require accessing the same optical disk or tape several times).  
      In some embodiments, the scheduler  8040  can interface with one or more sorters  5505  for routing queries and/or retrieved data. In other embodiments, the scheduler  8040  can interface with the multidimensional query processing application  7530  (if employed) to access one or more multidimensional archives, such as a media database  7516  and a description database  7518  as described above.  
      O. Content Addressed Storage  
      In some embodiments, the EIMA system  100  or other systems can employ content addressed storage (CAS) as an archive (e.g., database). An example of a CAS can include a magnetic disk-based Write-Once, Read-Many (WORM) device, such as a Centera™ storage system or device manufactured by EMC.  
      The EIMA system  100  can include several different archives, such as optical disks, magnetic tape storage, RAID storage, CAS (e.g., one or more disk-based WORM devices), and the like. In some embodiments, the EIMA system  100  can use one type of storage, such as a faster accessible storage device, to store information regarding data stored in another type of storage, such as a slower accessible storage device.  
      In one embodiment, for example, a first archive, such as a RAID database can be store an index or a table of information detailing where data (e.g., items such as checks) is stored on a second archive, such as Centera storage. As shown in  FIG. 83 , the RAID database  8305  includes a first table  8310  and a second table  8315 . In other embodiments, the database  8305  can include more or fewer tables than shown and described. The first table  8310  and the second table  8315  each includes information regarding a C-clip  8320  in the Centera storage  8330 . The C-clips  8320  provide information regarding where data  8340  (referred to as “tags”) is located within the Centera storage  8330 . As shown in  FIG. 83 , each C-clip  8320  includes an entry  8345  in either the first table  8310  or the second table  8315 .  
      In another embodiment, for example, such as the embodiment illustrated in  FIG. 84 , the system  100  can run a script to reformat the addressing of C-clips  8320 . The “collapser” script modifies the tags  8340  saved in the Centera storage  8330 . The script allows multiple tags  8340  to be identified a collapsed C-clip  8350 . As shown in TABLE 85, data (tags) numbered  1  through  114 , for example, are assigned to a different C-clip numbered  1  through  114  according to  FIG. 83 . Using the collapser script, all of the tags number  1  through  114 , for example, can be saved to a single C-clip numbered  1 .  
                   TABLE 85                                              Cycle xyz/File1 = C-clip 1 = Toptag1 = Tag1   Cycle xyz/File 1 = C-clip 1 = Toptag1 = Tag 1       Cycle xyz/File1 = C-clip 2 = Toptag2 = Tag2   Cycle xyz/File 2 = C-clip 1 = Toptag1 = Tag 2       Cycle xyz/File1 = C-clip 113 = Toptag113 = Tag113   Cycle xyz/File113 = C-clip 1 = Toptag1 = Tag 113       Cycle xyz/File1 = C-clip 114 = Toptag114 = Tag114   Cycle xyz/File114 = C-clip 1 = Toptag1 = Tag 114                  
 
      In some embodiments, reducing the number of C-clips in Centera storage can reduce the amount of memory required when data is accessed. In some embodiments, reducing the number of C-clips can also improve the speed of data retrieval from Centera storage.  
      The embodiments described above and illustrated in the figures are presented by way of example only and are not intended as a limitation upon the concepts and principles of the present invention. As such, it will be appreciated by one having ordinary skill in the art that various changes in the elements and their configuration and arrangement are possible without departing from the spirit and scope of the present invention as set forth in the appended claims.