DOCUMENT PROCESSING SERVICES

FIELD OF THE INVENTION

[0001] The present invention relates generally to techniques for providing document processing systems, and, in particular, a system and method for providing distributed processing systems for implementing document processing services.

BACKGROUND

[0002] Document processing operations may involve distributed processing. A document processing device may be managed by an application running on a computer to which the document processing device is connected, e.g., using a Universal Serial Bus (USB) connection, local area network (LAN ₃ or other interface. The application may remotely stop and start a scanning process, handle exceptions in the scanning process, etc. Further, such a remote application may perform analysis and/or reporting operations. For example, an image may be scanned by a document processing device and provided to a computer for analysis. Further, an image may be scanned by the document processing device, analyzed by the device or the computer, and further results of such analysis may be sent to a computer at a second location for reporting and archiving purposes, or for further analysis.

[0003] Accordingly, present document processing architectures generally require a one- to-one relationship between a controller application and a document processing device, where the application is running on a computer, i.e., a device controller, to which the document processing device is locally connected. Further, the device controller in the document processing device generally operates in the same operating system environment, e.g., a Microsoft® Windows® environment. To control a document processing device, the controller application generally communicates with the document processing device through an application programming interface (API). A controller application may thus control one or more document processing devices. However, multiple devices in an environment generally may only communicate with only one controller application, and in fact generally with only one instance of the controller application. Thus, a controller application generally communicates asynchronously with a document processing device.

[0004] In present architectures for document processing, it is generally difficult for multiple document processing devices to communicate with one or more instances of one or more control applications. In fact, present control applications are often limited to communicating with one document processing device at a time. It is further very difficult to connect devices and applications in different operating system and program code development environments.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates an exemplary document processing system.

Figures 2 A - 2E illustrate exemplary flows of data according to various embodiments.

Figure 3 provides a detailed illustration of exemplary applications and application services.

Figure 4 illustrates a user interface provided by a discovery manager, according to an embodiment.

Figure 5 illustrates a user interface for an exception handler, according to an embodiment.

Figure 6 illustrates a user interface for configuring and requesting the generation of reports, according to an embodiment.

Figure 7 illustrates an exemplary summary level read rate report, according to an embodiment.

Figure 8 illustrates an exemplary detail level report of a read rate by document type- according to an embodiment.

Figure 9 illustrates an exemplary process flow for processing documents in the system of Figure 1.

Figure 10 illustrates exemplary process flow for processing an individual document in the system of Figure 1.

Figure 11 illustrates exemplary process for subscribing to events published by a device service, and for receiving such events in the system of Figure 1.

DETAILED DESCRIPTION

I. SYSTEM OVERVIEW

[0005] Figure 1 illustrates an exemplary document processing system 100, including a network 101 that connects computers 105, 115, and 145, and also a database server 140 and document processing devices 150. Computer 105 includes one or more document processing applications 110. Computer 115 includes application services 130 and device service 135. Further, a document processing device 120 is connected to computer 115, e.g., by a Universal Serial Bus (USB) connection. Further, application services 130 may be embedded in a standalone document processing device 150. It is to be understood that applications 110 may be included on computer 115 or some other computing device connected to network 101 in addition to or alternatively to computer 105. Similarly, computer 115 need not be connected to device 120, and application services 130 and device services 135 could be included on computer 105 in addition to or alternatively to computer 115.

[0006] In the present exemplary illustration of system 100, computers 145 are distinguished from computer 115 in that computers 145 do not include application services 130, but are connected to at least one document processing device 120 and include device services 135. Further, standalone document processing devices 150 are similar to document processing devices 120, but have embedded device services 135 and application services 130, and are connected directly to network 101. A database server 140 or the like may be used for storing Images and information about images provided by document processing devices 120 and/or 150.

[0007] Network 101 is generally a packet network. Accordingly, network 101 may be an Internet Protocol (IP) network or the like such as is known for transporting digital data packets. For example, network 101 may use protocols such as user datagram protocol (UDP), transmission control protocol (TCP), hypertext transfer protocol (HTTP), etc. Further, network 101 may include a variety of networks such as a wide area network (WAN), e.g., the Internet, a local area network (LAN), etc.

[0008] Computers 105, 115, and 145 may be any one of a number of known computing devices, such as a desktop computer, a laptop computer, a handheld computer, thin client, ,

etc. Further, computer 145 could in fact be custom hardware, e.g., a device referred to as a "smartbox" that does not perform general computing operations but is configured to execute device services 135 and to support a peripheral device such as a device 120. Computers 105, 115, and 145 may connect to network 101 through any one of a number of protocols, such as those mentioned above. Further, the connection of a computer 105, 115, or 145, or 150 to network 101 may be either wired or wireless.

[0009] Document processing applications 110 may include a variety of different software applications for accessing, controlling, and/or receiving data from devices 120 and/or 150. Specific examples of applications 110 are discussed in more detail below with reference to Figure 3.

[0010] Document processing devices 120 may include any device that includes a processor and memory, and that may be configured to capture document images. As mentioned above, devices 120 are generally configured to be connected to a computer 105, 115, or 145, e.g., through a USB connection. Devices 120 communicate with device services 135 on computer 105, 115, 145, etc., which services 135 hi turn may communicate with one or more applications 110. Exemplary document processing devices 120 may include the SourceNDP, MyVision X ₅ UEC Series, NDP 110, NDP Quantum Series, NDP 850, 1150, and 2000, etc., all manufactured by Unisys Corp. of Blue Bell, Pennsylvania. However, devices manufactured and/or sold by other vendors may also be used.

[0011] Application services 130 may be accessed by applications 110 to locate, configure, query, etc. device services 135. Application services 130 are discussed in more detail below with reference to Figure 3.

[0012] Database server 140 may be connected to one of computers 105 or 115, but is generally accessible through network 101. Database server 140, as mentioned above, may be used for storing images captured by devices 120 and/or 150, as well as data about such images. Database server 140 generally includes a relational database management system (RDBMS), as is well known. An RDBMS generally employs the well known Structured Query Language (SQL) in addition to a language for creating, storing, editing, and executing stored procedures, such as the PL/SQL language mentioned above. However, it is to be

understood that database server 140 may include some other kind of database such as a hierarchical database, a set of files, an application database in a proprietary format, etc. Database server 140 generally includes a computing device employing a computer operating system such as one of those mentioned elsewhere herein, although database server 140 may be included in one or more of computers 105, 115, etc.

[0013] Document processing devices 150 may include any device that includes a processor and memory, and it may be configured to capture document images, and further that may be configured to include device services 135, e.g., as embedded software as well as application services 130. Accordingly, document processing devices 150 may communicate with application services 130 through network 101 or as embedded within a device 150. Exemplary document processing devices 150 may include the devices mentioned above manufactured by Unisys Corp., or similar devices, provided that such devices are configured to include device services 135 and plug-in 136.

[0014] In general, computers 105, 115, and 145, database server 140, and document processing devices 120 and 150, may include one or more computing devices configured to communicate through network 101. As mentioned above, network 101 may include one or more networks, e.g., a local area network (LAN), wide area network (WAN), the Internet, or other network(s) for exchanging digital information, as is well known. Computing devices such as the foregoing may include any one of a number of computing devices, including, without limitation, a computer workstation, a desktop, notebook, laptop, or handheld computer, or some other computing device as is generally known, such as a Java™-enabled cellular telephone or similar device. Further, computing devices such as the foregoing may employ any of a number of computer operating systems, including, but by no means limited to, known versions and/or varieties of the Microsoft® Windows® operating system, the Unix operating system (e.g., the Solaris® operating system distributed by Sun Microsystems of Menlo Park, California), the AIX UNDC operating system distributed by International Business Machines of Armonk, New York, and the Linux operating system. In an embodiment, document processing devices 120 and 150 include the Windows CE operating system distributed by Microsoft Corporation of Redmond, Washington. Further, in an

embodiment, computers 105 and 115 include the UNIX operating system and computer 145 includes the Windows operating system.

[0015] Further, computing devices such as the foregoing may each include instructions executable by one or more computing devices such as those listed above. Such instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Microsoft .NET, Java™, C, C++, Visual Basic, Java Script, Perl, etc. For example, in an embodiment, device services 135 and application services 130 are written according to .NET. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of known computer-readable media.

[0016] A computer-readable medium includes any medium that participates in providing data (e.g., instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

II. DATA FLOWS

[0017] Applications 110, application services 130, and device services 135 may communicate according to an asynchronous model using Web Services Eventing (WS- Eventing) as described, for example in Don Box, Luis Felipe Cabrera, et aL, Web Services Eventing (WS-Eventing) dated August 2004 and published by the World Wide Web Consortium on March 15, 2006 on its website at www.W3C.org, the contents of which are fully incorporated herein by reference in their entirety. In the asynchronous model, applications 110 subscribe to application services 130, and an application 110 accordingly receives information published by application services 130 to which it has subscribed. Services 130 and 135 may be described according to an extensible markup language (XML) format such as Web Service Definition Language (WSDL) as is known for use in conjunction with WS-Eventing. WSDL is described in Erik Chϊistensen, Francisco Curbera et al., "Web Services Description Language (WSDL) 1.1," dated March 15, 2001 and published by the World Wide Web Consortium on its website at www.W3C.org, the contents of which are fully incorporated herein by reference in their entirety. As described in the WSDL 1.1 document, WSDL includes support for Simple Object Access Protocol (SOAP), and in fact SOAP may be used in conjunction with WSDL in certain embodiments.

[0018] Events generated by services 130 and 135 are described in further detail below. However, it should initially be understood that services 130 and 135 generate various events that may be stored and/or acted upon by applications 110. Such events may include document images provided in real-time or near real time, other data events such as magnetic ink character recognition (MICR) code lines or optical character recognition (OCR) code lines, errors, warnings, information about image quality including image quality defects, user interface inputs, e.g. a user selection of a pushbutton on a device 120 or 150, a powering on or off of a device 120 or 150, etc. Further, applications 110, application services 130, and device services 135 may communicate according to a polled processing mode in which an application 110 must make a specific function or method call to an application service 130 to obtain information about a document processed by a document processing device 120 or 150.

[0019] Figures 2 A, 2B ₅ 2C, 2D and 2E illustrate exemplary flows of data according to various embodiments.

[0020] Turning first to Figure 2 A, application 110 is shown as sending a request 205 to device service 135. Such a request 205 may be a call to a method or function made available by device service 135. For example, a request 205 may be provided according to WSDL as described above. Methods made available by device service 135 according to an embodiment are discussed further below, and specific examples are described further in Table 1 below. Briefly, such methods may allow for configuration of a device 120 or 150, for an instruction to return information regarding a document scanned by device 120 or 150, for a request for information regarding status or state of a device 120 or 150, etc.

[0021] Figure 2A further illustrates an image 210 being acquired by a device 150. Note that a device 120 along with a computer 145 could have as easily been included in Figure 2A in lieu of the device 150 illustrated therein. As mentioned above, in an embodiment, devices 120 and 150 operate to scan documents, thereby rendering images 210. Request 205 may be a request for information about image 210 and/or for image 210 itself. Information about images 210, devices 120 and 150, etc. that may be obtained from device service 135 according to an embodiment is discussed further below, and moreover specific examples are provided in Table 2 below. Further, in addition to devices 120 and 150, other types of devices may be controlled by device services 135 including plug-in 136, such as devices that may work in conjunction with document processing devices 120 and 150, e.g., fingerprint scanners, magnetic stripe readers, display and printing devices, etc.

[0022] Information about images 200 and, devices 120 and 150, etc. may be provided by device service 135 in a message 215. As further shown in Figure 2 A, in response to request 205, device service 135 provides image 210 along with message 215 to application 110. Advantageously, message 215 and image 210 may be events that are provided asynchronously by device service 135 to application services 130 and/or applications 110.

J0023] As discussed further below, device service 135 may perform limited processing with regard to an image 210. Accordingly, application 110 may send a request 206, along with image 210, to an application service 130 for further processing of the image 210. For example, as described further below, an application service 130 may analyze the quality, usability, etc. of the image 210. Results of such analysis, or any information in response to

the request 206, may be provided by application service 130 to application 110 in a message 220. Like message 215, message 220 may be an event provided asynchronously by application service 132 application 110. Further, as discussed below with reference to Figure 2E, device services 135 can send requests and receive messages from application services 130 without intervention from applications 110. In fact, if desired, device services 135 may perform substantially all of the operations of application services 130.

[0024] Figure 2B illustrates a flow of data according to an embodiment that is slightly different than the flow illustrated in Figure 2A, As shown in Figure 2B, request 206 and image 210 are provided to application service 130 directly by device service 135. Image 210 and message 220 are provided from application service 132 application 110 as discussed above with respect to Figure 2A.

[0025] Figure 2C illustrates yet another flow of data according to an embodiment. As shown in Figure 2C ₅ application 110 sends a request 225 to application service 130. Request 225 is similar to request 205 discussed above with respect to Figure 2 A, but calls a method or function in application service 130, rather than a method or function in device service 135. Application service 130 then sends a request calling a method or function in device service 135. In response, device service 135 provides image 210 and message 215 to application service 130, which in turn provides image 210 and message 220 application 110 as discussed above.

[0026] Figure 2D illustrates yet another flow of data according to an embodiment. In this embodiment, application service 130 is not included, or is at least bypassed. Application 110 sends request 205 to device service 135. In response to request 205, device service 135 sends image 210 and message 220 directly to application 110.

[0027] Figure 2E illustrates yet another flow of data according to an embodiment. In this embodiment, application 110 sends a request 225 to device service 135, which in turn sends a request 230 to application service 130. Request 230 is similar to other requests described above, and is a request from device service 135 to application service 130 on behalf of application 110 to perform an operation provided by application service 130. Message 220

in response to requests 230, and indirectly in response to request 225, is provided to application 110 through device service 135.

[0028] It is to be understood that embodiments are possible and likely in which data flows through elements not shown in Figures 2A-2E. For example, an application programming interface (API) may be interposed between application 110 on the one hand, and services 130 and 135 on the other, so mat application 110 may communicate through a single interface with both services 130 and 135. Similarly, an intermediate programming layer may allow services 130 and 135 to communicate with multiple applications 110 through a single interface. Further, although network 101 is not shown in Figures 2A-2D, it is to be understood that application 110, application services 130, and device services 135. may communicate via network 101 as discussed above with reference to Figure 1.

[0029] Moreover, embodiments including flows of data different from those illustrated in Figures 2 A - 2E are possible. In particular, Figures 2 A - 2E each show a single application 110 and a single device 150 associated with a single device service 135. However, as better seen in Figure 1, applications 110 and device services 135 may have a many-to-many relationship. Thus, multiple applications 110 may subscribe to a single event source, e.g., a device service 135. Conversely, a single application 110 may subscribe to events from multiple event sources, e.g., device services 135, application services 130, etc.

[0030] Further, as will be clear below, many requests 205, 206, etc. will result in a message 215, 220, etc. without an image 210. Indeed, applications 110 and/or application services 130 may subscribe to events that are published as an image210, a message 215, 220, etc., and therefore a request 205, 206, etc. from a client is not necessary to trigger a message 215, 220, etc. In general, services 130 and 135, and applications 110, follow the known publish-and-subscribe model according to which events are published to client applications by web services. Accordingly, event subscriptions persist even when devices 120 and 150 are powered off, and an application 110 generally may not only subscribe to receive events from a service 130 or 135, but may also unsubscribe from, renew, etc. such services. Services 130 or 135 may grant or deny subscriptions, e.g., grant or deny access to an

application 110, grant or deny renewals, provide multiple subscriptions to multiple applications for multiple event types, etc.

IH. APPLICATIONS AND SERVICES

[0031] Figure 3 provides a detailed illustration of exemplary applications 110, application services 130, and device services 135.

[0032] In general, services 130 and 135 provide the advantage of allowing coming processing operations, standards, regulatory rules, etc. to be maintained in a way that is transparent to a potentially large and potentially diverse groups of applications 110. For example, rules for image compression, encryption, formatting of various document fields, image usability analysis, image quality analysis, funds transfer rules, exception handling, error reduction, and many more kinds of rules may be updated in services 130 and/or 135 independently of, and without making any changes to, applications 110. Further updates to services 130 and/or 135 will be very quickly and efficiently deployed to all client applications 110.

[0033] As described in further detail below, various application services 130 and device services 135 may accept various inputs and provide various outputs. Some inputs may be provided by a user, and some outputs may be viewed by a user. Accordingly, it is to be understood that applications 110 may include one or more graphical user interfaces (GUIs) or the like to allow a user to provide such inputs and to view such outputs. Generally such GUIs are provided in a known web browser or the like according to program instructions on computer 105.

A. APPLICATION SERVICES

[0034] Applications services 130 in an embodiment run in a Windows XP environment on a computer such as computer 115. Application services 130 may include a discovery service 302, image services 304, and entitlement service 316, a parameter service 318, and a result service 320. Application services 130 generally include a client interface that is an application programming interface or the like through which methods in an application service 130 may be called by clients such as applications 110. Further, application services 130 may publish events through the client interface. For example, such a client interface

may accept input and provide output formatted according to extensible Markup Languag (XML).

[0035] Discovery service 302 may be used by an application 110 to determine the identities and locations of document processing devices 120 and 150 and services 130 and 135 for which the application 110 may subscribe to receive information and/or provide input. Discovery service 302 thus essentially provides a directory or registry for dynamically locating devices 120 and 150 and device services 135. For example, such a registry may be formatted according to the known Universal Description, Discovery, and Integration (UDDI) standard, and may include a description and a physical location i.e., a Uniform Resource Locator (URL) for each device and service entered in the registry. Applications 110 may locate devices 120 and 150 and/or services 130 and 135 automatically, e.g., according to program instructions. Application 110 may also include a graphical user interface (GUI) or the like, e.g., such as may be displayed in a web browser or the like, to allow a user to specify or to manually determine a physical location for devices 120 and 150 and/or services 130 and 135. Such a GUI may also be used to allow a user to determine whether devices 120 and 150 and/or services 130 and 135 automatically located by an application 110 should be subscribed to.

[0036J One or more image services 304 may provide one or more renditions of a scanned document image, e.g., in a known format such as that set forth by the Joint Photographic Experts Group (JPEG), or the Comite Consultatif International Telephonique et Telegraphique (CCITT), etc. Such image renditions may be displayed in an interface provided by application 110, e.g., in a display of computer 105. Further, image services 304 may provide a variety of image analysis operations, and image renditions may be provided in conjunction with such operations.

[0037] Image services 304 may include character recognition services 306 such as courtesy amount recognition (CAR) and legal amount recognition (LAR). Such character recognition services may make use of Intelligent Character Recognition (ICR) technology. As is known, ICR may use information obtained from Optical Character Recognition (OCR) and/or Magnetic Ink Character Recognition (MICR).

[0038] Image services 304 may further include image quality services 308 that perform image quality analyses, thereby providing real-time or near real time assessments or offline of image quality to applications 110. For example, as is known, the American National Standards Institute (ANSI) has approved the X9.100-180 Specifications for Electronic Exchange of Check and Image Data. Accordingly, image services 304 may be configured to detect image quality defects as defined in the foregoing specifications, and may further be configured to generate Image Quality Flags (IQFs) for one or more image renditions of a document processed by a document processing device 120 or 150.

[0039] An IQF is generally activated when a particular image quality metric exceeds one or more predetermined thresholds, e.g., thresholds defined according to user input. An IQF may be dependent upon a specific image rendition, e.g., whether the image rendition is a black/white or a grayscale rendition. Further, an IQF may be dependent upon a particular portion of a document processed in a device 120 or 150, e.g., whether the front or the back of a document is being processed. Providing an IQF to application 110 at tbe time of document capture allows problems with image capture to be quickly corrected, and for images to be efficiently recaptured to ensure that only quality images are presented through application 110. For example, it may be possible to easily remedy detected streaks in an image by simply cleaning a camera. It further may be possible to easily repair a folded comer of a document, or to correct the backwards feed of a document into a device 120 or 150.

[0040] In conjunction with analyzing image quality, image services 304 may further include image usability services 310 that provide an assessment of image usability. As is known, the Check Processing for the 21st Century Act mandates that banks accept image replacement documents (IRDs), which are defined in the American National Standard Specifications for an Image Replacement Document - IRD, X9.100-140 (ANS X9.100- 140). Image quality analysis that generates IQFs generally applies to an entire document. Accordingly, even where no IQFs are raised, a document may be unusable for its intended purpose, e.g., because a particular portion or field in a document is unreadable or unusable. For example, a document may be broken into various sections or fields, and various usability tests may be applied to each such field. For example, fields that might be assessed on the front and back of a check include date, payee name, courtesy amount, legal amount,

signature, memo line, and endorsement. A usability assessment may determine whether a document image retains sufficient information "with respect to each field, and may further assess the legibility of each field.

[0041] Image services 304 may further include image security services 312. Image security services 312 generate a digital signature for images captured in document processing devices 120 and 150 using image data and a private key that is part of a public/private key pair, such key pairs being well known. Digital signatures may be stored in files on a computer, in database 140, in devices such as devices 120 and 150, etc. The use and benefits of digital signatures for documents such as financial instruments, e.g., checks, are well known.

[0042] Image services 304 may further include image processing services 314. As mentioned above, image services 304 may provide one or more renditions of an image captured in device 120 or 152 and application 110. Post-capture processing on such images may be performed by image processing services 314. For example, it may be desirable to select a portion of a rendered image for storage or further analysis, to convert a grayscale image to a black/white image, etc.

[0043] Entitlement service 316 validates the feature or features of image services 304 that an application 110 is entitled to access. For example, application 110 may generate a license request to entitlement service 316 to authorize particular features of image services 304, e.g., licensed features or features that a user of application 110 has purchased. Entitlement service316 may also store usage information in database 140, and/or report usage information to a remote server over network 101.

[0044] Parameter service 318 is responsible for storing parameter file structures, e.g., in database server 140. Accordingly, parameter service 318 allows image services 304 to retrieve parameter files at runtime. Further, parameter service 318 may synchronize parameter structures being used simultaneously by multiple instances of image services 304. Parameters stored in parameter files and placed in parameter structures for image services 304 include values for IQFs, discussed above, values indicating portions of a document of interest to image usability services 310, etc.

[0045] Results service 320 allows for storage of image results from image services 304 on an asynchronous basis. That is, results service 320 supports audit logs and image processing results from multiple applications 110 running at different times and possibly across different networks, involving different or possibly the same devices 120 and 150. In an embodiment, results data is saved in an XML file format in database server 140. Further in an embodiment, results service 320 uses known Microsoft Message Queuing (MSMQ) technology to manage the receipt and storage of results.

B. DEVICE SERVICES

[0046] With respect to a device 120, a device service 135 runs on a computer 145 to which the device 150 is connected, e.g., via a Universal Serial Bus (USB) connection. Further, device service 135 in an embodiment runs in a Windows CE environment on devices 150. Device service 135 may be accessed by applications 110 and/or application services 130 to control some or all of the operation of devices 120 and 150. Device service 135 generally supports the capture of an image by a device 120 or 150, and renders an image, e.g., in a JPEG format. Further, device service 135 generally includes all or a subset of the operations provided by application services 130, including operations substantially as described above with respect to image quality service 308 and image security service 312.

[0047] Device service 135 includes methods that may be called to configure most if not all of the configurable settings in a device 120 or a device 150, as well as methods that may be called to obtain information concerning a present status of various aspects of a device 120 or a device 150. Such methods are generally called by formatting and providing an XML document to device service 135, e.g., according to WSDL as described above. Methods included in device service 135 in an exemplary embodiment include those described below in the section headed "Exemplary Services Methods."

[0048] Device service 135 generally includes a client interface that is an application programming interface or the like through which methods in device service 135 may be called by clients such as applications 110 and application services 130. Further, device service 135 may publish events through the client interface. For example, such a client interface may accept input and provide output formatted according to XML.

C. PLUG-IN

[0049] In some cases, device 150, and/or device service 135, or application service 130 may include a plug-in 136 that works in conjunction with device service 135. Plug-in 136 is generally a module of a device service 135 or application service 130, and may include a dynamic link library (DLL) or the like. Advantageously in the case of a device 150, plug-in 136 may be compiled for a native environment, e.g., for the native environment of device 150, and men may be downloaded to device 150 for execution.

[0050] Example of operations performed by plug-in 136 include providing processing rules governing the endorsement of a document, the "pocket" of a device 150 to which a document is sent, capturing a document image, identifying a type of document, etc. may be implemented using plug-in 136 on device 150. Native code for device 150 provides the advantages of increasing programming flexibility and further generally providing execution times that are shorter than could be obtained with non-native code, because control decisions are made according to instructions executed in a processor in device 150, rather than by a remote application 110 or a remote application service 130. Thus, a method in device service 135 may be called to initiate document processing, whereupon device service 135 may instruct plug-in 136 to commence such processing, and whereupon processing rules implemented in plug-in 136, such as the afore-described rules, are used to process documents in device 150. However, such native code is more difficult to port to other hardware platforms. A plug-in may also be included as part of devices services 135 and application services 130 to control decisions based on custom application software.

[0051J Device service 135 may include program instructions for downloading and installing plug-in 136, e.g., an InstalIFile() method as described below in Table 1. For example, plug-in 136 may be downloaded to a device 150 from a computer such as computer 105 or computer 115. Plug-in 136, e.g., as a module within device service 135, may receive instructions or requests from device service 135, and may provide information to device service 135 to be used, e.g., in messages 215.

D. APPLICATIONS

[0052] Although shown running on computer 105 in Figure 1, applications 110 may be installed and run on multiple computing devices including multiple programming and operating system environments. For example, while certain applications 110 may run in some form of a Windows environment, other applications 110 may run in some form of a UNIX environment. A wide variety of applications 110 are possible, including a configuration application 350, a test application 352, an image analyzer 354, a discovery manager 356, an entitlement manager 358, an exception handler 360, and image security manager 362, a reporting/data mining application 364, and image archive 366. As illustrated in Figure 2, applications 110 generally communicate with services 130 and 135 through network 101.

[0053] Configuration application 350 is generally used to obtain information about, and to configure, a device 120 or 150. To perform these operations, configuration application 350 communicates with device services 135 associated with the device 120 or 150 to be configured. In general, such elements may include items such as the speed at which a feeder in a device 120 or 150 operates, a format (e.g., JPEG, etc.) for an image captured by device 120 or 150, a physical length of documents whose images are to be captured by the device 120 or 150, a configuration for a magnetic ink character recognition (MICR) reader, a configuration for an optical character recognition (OCR) reader, etc., to name but a few. Numerous other elements that may be configured in a device 120 or 150 according to exemplary embodiments are described below. Also described below are methods in device service 135 that may be called by configuration application 350 to configure a device 120 or 150.

[0054] Test application 352 is sometimes referred to as an "exerciser." Test application 352 may communicate with application services 130 and/or device service 135 to initiate, control, and receive information about documents processed by devices 120 and 150. The purpose of test application 352 is to provide for the testing or trial of application services 130, device service 135, and/or devices 120 or 150. Accordingly, test application 352 may invoke generally any method made available by services 130 or 135. Further, test application 352 may generally subscribe to any event published by services 130 or 135.

[00551 Image analyzer 354 generally subscribes to events published by device services 135 and image services 304. For example, character recognition services 306 may provide image analyzer 354 with information about the content of a document, e.g., the amount of a check obtained by courtesy amount recognition (CAR) and/or legal amount recognition (LAR) technologies. Image quality services 308 may provide an IQF as described above. Further, image analyzer 354 may obtain usability assessments provided by image usability services 310. Image analyzer 354 may obtain information from image security services 312, or such information may be provided to image security manager 362, discussed below. Further, image analyzer 354 may obtain one or more renditions of the document image, e.g., in JPEG, TIF, CCITT formats, etc., from image processing services 314.

[0056] Discovery manager 356 provides a user interface, generally a GUI, to discovery service 302. A user interface 400 provided by discovery manager 356 in a standard web browser according to an embodiment is shown in Figure 4. Registry tree 405 includes devices 120 and 150 and services 130 and 135 that may be accessed by applications 110. Specifically, items listed in Registry tree 405 not preceded by a "+" or "-" icon are. devices 120 or 150, or services 130 or 135, that may be accessed by applications 110. Items preceded by a "+" or "-" icon are categories of devices 120 or 150, or services 130 or 135 included in registry tree 405 to support navigation by a user. As shown in Figure 4, user interface 400 includes a form field for specifying an access point 410, e.g., a uniform resource locator (URL) or other network address for a device 120 or 150 or service 130 or 135. In general, through interface 400, a user may add or delete entries to registry tree 405, or otherwise edit registry tree 405.

[0057] Entitlement manager 358 provides a user interface to allow a user to request and obtain entitlement to services 130 and 135 through entitlement service 316. Entitlement manager 358 may also be used to monitor usage of services 130 and 135 to ensure compliance with a license for such services.

[0058] Exception handler 360 displays information relating to exceptions reported by services 130 and/or 135. Generally an exception refers to an item that is not correctly processed by a device 120 or 150. With respect to an exception, exception handler 360 may

display some or all of the following: a message describing the exception, a list of documents , including, if applicable, code lines, for which exceptions have been raised, and images, if available, of exception documents. Exceptions are generally events passed from devices 120 or 150 to exception handler 360. Exception handler 360 may also receive warnings, which are similar to exceptions, but relate to items whose processing could indicate a problem with a device 120 or 150 even if the item was correctly processed.

[0059] Figure 5 illustrates a user interface 500 for exception handler 360, according to an embodiment. Subscription window 505 lists services 130 and/or 135 to which exception handler 360 has subscribed. Exception window 510 lists exceptions reported to exception handler 360. Messages window 515 displays any textual messages or descriptions related to an exception highlighted in exception window 510. Images window 520 displays an image, if any, for a document related to a highlighted exception in window 510.

[0060] Image security manager 362 generally interacts with image security service 312. Image security manager 362 is used to set security options, generate key pairs, export certificate requests, and import certificates for image security provided by services 130 arid/or 135. Further, image security manager 362 may be used to activate image security for image 210, which is processed through device service 135 according to what is sometimes referred to as "level-2" security because it requires a password. The password is used to activate image security after the security system has been idle for a configurable period of time.

[0061] Reporting/data mining application 364 is used to log and provide reports on character recognition data and other results of processing documents in devices 120 and 150. Such data is generally stored in database server 140, sometimes only for a predetermined period of time in order to avoid exceeding space constraints. Figure 6 illustrates a user interface 600 for configuring and requesting the generation of reports, according to an embodiment Standard reports that may be provided in an odd event include a read rate and misread rate (RR/MR) report showing character recognition performance for one or more fields on a document, a volume report showing a number of documents processed within a specified period of time, an error report displaying a percentage of documents that have

recognition error codes returned from character recognition engines in services 130 and/or 135 , a reject report that displays a percentage of documents with an unsuccessful recognition field status, and a throughput report that displays a number of documents processed over time. User interface 600 includes a tab 605 for summary reports, a tab 610 for detail reports, a tab 615 for RR/MR report, in a tab 620 for viewing reports. For example, Figure 7 illustrates an exemplary summary level read rate report, according to an embodiment. Figure 8 illustrates an exemplary detail level report of a read rate by document type, according to an embodiment.

[0062] It is to be understood that some or all of the foregoing applications 110 may be combined or consolidated into a single application 110, or at least fewer applications 110 that are described above. Further, such applications 110 may be presented in a single or common graphical user interface. For example, test application 352 and image analyzer 354 may often be combined into a single application and/or presented in a single graphical user interface.

IV. PROCESS FLOWS

[0063] Figure 9 illustrates an exemplary process flow 900 for processing documents in system 100. It is to be understood that the flow of data, e.g., requests, messages, events, etc., in process flow 900, and also process flow 1000 described below, may occur as described above with respect to Figures 2A-2D.

[0064] In step 905, discovery manager 356 accesses discovery service 302, which is used to discover available devices 120 and/or 150 along with associated device services 135. Accordingly, particular devices 120 and/or 150 that are available, e.g., via network 101, may be selected for processing documents. Further, particular application services 130 and/or device services 135 may be selected for processing documents.

[0065] Next, in step 910, entitlement manager 358 accesses entitlements service 316, which is used to confirm a user's right to access and use the devices 120 and/or 150 and services 130 and/or 135 selected in step 905. The remaining description of process 900 assumes that such entitlements were confirmed in step 910.

[0066] Next, in step 915, configuration application 350 is used to configure devices 120 and/or 150 selected in step 905. Certain items that may be configured were mentioned above, and further detailed examples are provided below of numerous elements in devices 120 and/or 150 that may be configured. Configuration application 350 generally also selects or identifies a set of parameters to be used by application services 130 in processing documents. Examples of such parameters are provided above.

[0067] Next, in step 920, parameter service 318 loads, e.g. into a memory of computer 115, parameters identified in step 915 above.

[0068] Next, in step 925, document processing is commenced. For example, an application such as test application 352, sometimes referred to as an "exerciser," may be used to initiate and control document processing in system 100. As discussed above, in some embodiments, device 150 may include plug-in 136, which plug-in 136 may provide processing rules for controlling processing of documents in device 150.

[0069] Next, in step 930, image analyzer 354 receives renditions of images 210 and information about such images, e.g., events 215, e.g., from image services 304. A process whereby image analyzer 354 receives such images 10 is discussed in more detail below with reference to Figure 10.

[0070] Next, in step 935, test application 352 determines whether any exceptions have been received concerning documents being processed in system 100. For example, if a feeder is jammed, a document attempted to be processed is the wrong size, etc., an exception may be raised and provided by device service 135. If an exception is raised, step 940 is executed next. Otherwise, process 900 proceeds to step 945.

[0071] In step 940, test application 352 determines whether exception received in step 935 has been handled. Test application 352 may be programmed to wait a certain amount of time for exception to be handled, or to receive the user input indicating that an exception has been handled, e.g., that a jammed feeder has been cleared. If test application 352 receives an indication that an exception has not been handled, process 900 ends. However, if an exception is handled, process 900 returns to step 930.

[0072] In step 945, test application 352 determines whether devices 120 and/or 150 selected in step 905 have run out of documents, been powered off, or otherwise are indicated to have completed processing documents. If so, process 900 ends. However, if documents remain to be processed, process 900 returns to step 930.

[0073] Figure 10 illustrates an exemplary process flow 1000 for processing an individual document in the system of Figure 1.

[0074] In step 1005, image analyzer 354 requests an image 210 and information about the image 210. As discussed above, in many embodiments, image 210 and message 215 are provided to image analyzer 354 by application services 130 and/or device services 135, and therefore step 1005 may be unnecessary.

[0075] Next, in step 101O ₅ device 120 or 150 captures a document image 210.

[0076] Next, in step 1015, device service 135 publishes one or more events related to document image 210 to one or more applications 110, application services 130, etc. For example, device service 135 may cause the document image 210 captured in step 1010 to be provided to image services 304 and/or may provide oiher information as mentioned above.

[0077] Next, in step 1020, image services 304 analyze the image 210, e.g., as described above with reference to Figure 3.

[0078] Next, hi step 1025, image services 304 provide the results of the analysis performed in step 1020, generally along with the image 210, to image analyzer 354, e.g., as an event 215.

[0079] Next, in step 1030, image analyzer 354 generally displays at least some of the information received in step 1025 in a user interface, and also stores such information, e.g., a log, and database server 140, etc.

[0080] Following step 1030, process 1000 ends.

[0081] Figure 11 illustrates exemplary process 1100 for subscribing to events published by device service 135, and for receiving such events.

[0082] In step 1105, a client such as an application 110, application service 130, etc. requests a subscription from device service 135.

[0083] Next, in step 1110, using known authentication techniques, device service 135 determines whether to provide the subscription requested in step 1105. For example, authentication may be performed by standard web services procedures such as security features provided by .NET. Further, this step 1110 is omitted in some embodiments; it is not necessary for device service 135 to authenticate subscribers.

[0084] Next, in step 1115, device service 135 creates a subscription for the requesting application 110, application service 130, etc. Device service 135 may include a registry or other database of subscribers to which device service 135 is to publish various events. Device service 135 generally makes available multiple events to clients such as applications 110, application services 130, etc. Note that it is generally not necessary or desirable for most clients to subscribe to all of the events published by a device service 135.

[0085] Next, in step 1120, device service 135 publishes events to clients such as applications 110, application services 130, etc. that have requested them.

[0086] Next, hi step 1125, device service 135 determines whether it has received a request to cancel a subscription from a client, e.g. an application 110, an application service 130, etc. If so, step 1130 is executed next. Otherwise, step 1135 is executed next.

[0087] In step 1130, the subscription indicated in step 1125 is canceled. Process 1100 ends following step 1130.

[0088] In step 1135, device service 135 determines whether a subscription has expired. Such a determination is generally made periodically for all subscriptions registered in a device service 135. If a subscription has expired, step 1140 is executed next. Otherwise, process 1100 returns to step 1120.

[0089] In step 1140, device service 135 determines whether it has received a request to renew the subscription determined to be expired in step 1135. If so, step 1145 is executed next. Otherwise, process 1100 ends.

[0090] In step 1145, device service 135 determines whether to graαit the request for renewal received as discussed above with respect to step 1140. If the request for renewal is not to be granted, process 1100 ends. Otherwise, step 1150 is executed next.

10091) In step 1150, the subscription that was the subject of the renewal request received as discussed above with respect to step 1140 is renewed. Step 1120 is then executed following step 1150.

V. EXEMPLARY SERVICES METHODS

[0092] Table 1 lists and describes methods made available by devices service 135 in an embodiment. These methods are listed by way of example only, and other methods may be included in device service 135. Moreover, certain of these methods, and also other methods, may be made available by applications services 130.

Table 1

[0093] In an embodiment, methods in device services 135 and application services 130 may be called by sending a message according to Simple Object Access Protocol (SOAP) in an XML format generally also in accord with WSDL, mentioned above. For example, a segment of XML that might be used to call the "GetDocument()" method listed above could be defined as follows:

<xs:element name-"GetDocument"> <xs : complexType>

<xs:sequence> <xs:element minOccurs- ' 1 " maxθccurs=" 1 " name="GetDocumentData" type="tns:CTGetDocumentData" /> </xs:sequence> </xs:comρlexType> </xs:elemen1>

<xs: complexType name='CTGetDocumentData'>

<xs:sequence minOccurs=T maxθccurs- r> <xs:element name='Timeout' type-xs:integer' default- 100 O'/>

</xs:sequence> </xs:complexType>

[0094] The "timeout" element is a value is in milliseconds, e.g., the "GetDocumentQ method must respond to the above call in 1000 milliseconds. Bi some embodiments, if the timeout value used to call "GetDocument()"is larger than a HTTP timeout value, the method request will timeout at the HTTP level before this timeout is reached.

[0095] In addition, a segment of XML that could be output by device service 135 as the result of a call to the GetDocument() method could be:

<xs:element name='GetDocumentResponse ^l > <xs : complexType name=' CTGetDocumentResult'> <xs: sequence minθccurs ^=l l' maxOccurs=T> <xs:element nanαe='Status' type='tns :CTisStatus' /> <xs:element name^'DocumentResurt' type='tns :CTDocumentResulf /> <xs:element name="ResultCode" type="tns:STResponseCode" minOccurs="0" maxθccurs=" 1 " default - 'Success"/>

<!— Low-level exception information that may be useful to service personnel — > <xs : element name="Detail" type="xs: string" minOccurs="0" maxθccurs=" 1 " /> </xs:sequence> </xs:complexType> </xs:element>

[0096] An explanation of the elements in the above segment of XML is found in Table 3 below.

VI. EXEMPLARY DEVICE SERVICES DATA ELEMENTS

[0097] In an embodiment, methods in device service 135, and events generated by device service 135, accept as input and provide as output XML documents including elements formatted according to certain defined data types. These data types are sometimes referred to as "complex types" because they may include more than one element. Further, as seen in

Table 2 below, some complex types are nested within other complex types, such nesting being well known with respect to XML documents. In this exemplary embodiment, defined complex data types include, but, as should be clear from Table 2, are not limited to, the following:

(0098] A ResponseCode data type allows for response code values to be returned from methods in device service 135.

[0099] A ServiceState data type describes the state of the called device service 135.

[0100] A TransportState data type described the state of a device 120 or 150 associated with the called device service 135.

[0101] A ServiceStatus data type provides status information concerning a device 120 or 150 associated with the called device service 135.

[0102] A Capabilities data type is used to describe the functional capabilities of the document processing device 120 or 150 associated with the service 135.

[0103] A Configuration data type defines the configuration of a device service 135 and a device 120 or 150 that the service 135 is controlling. The Configuration datatype includes other complex types, as seen in Table 3 below.

[0104] Table 2 lists data types used for methods provided, and events generated, by device services 135. Table 2 further lists elements included within each data type. These elements may be included in XML messages to and from device service 135. References to a "device" in Table 2 are to a device 120 or 150.

Table 2

VII. EXEMPLARY EVENTS

[0105] Table 3 provides an exemplary but certainly not exhaustive list of events that may be included in messages 215 and 220 from device service 135 in an embodiment.

Table 3

[0106] Table 4 provides an exemplary list of elements that may be included in a DocumentResult event, according to an embodiment. It is to be understood that not all elements listed below must be, or generally are, included in a particular event, and further that other elements are possible.

Table 4

[0107] Table 5 provides an exemplary list of elements that may be included in a Warning event, according to an embodiment. Again, it is to be understood that not all elements listed below must be, or generally are, included in a particular event, and further that other elements are possible.

Table 5

CONCLUSION

[0108] With regard to the processes, systems, methods, heuristics, etc, described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claimed invention.

[0109] Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent to those of skill in the art upon reading the above description. The scope of the invention should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the arts discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the invention is capable of modification and variation and is limited only by the following claims.

[0110] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those skilled in the art unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as "a," "the," "said," etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.