Image processing

Abstract

An image of a check may be presented for payment in a banking system in place of the physical paper check. The check to be deposited can be collected from a depositor using a scanner. A web site, accessed through a depositor's web browser, can be used to drive the process of collecting the check, but in some contexts (e.g., in less popular computing environments, such as those that do not run the most popular operating systems), it is economically infeasible to obtain the certificates that would be used to allow a program executing in the web browser to control the scanner. Thus, a depositor can be instructed to capture and upload images of the check in the form of files, where the image files are then presented for payment through a banking system.

Description

BACKGROUND

A check is a negotiable instrument. Formally, a check is an order that a “drawer” (the party who writes the check, and from whose bank account the money is to be drawn) issues to a “drawee bank” (the bank at which the drawer's money is located), and the order instructs the drawee bank to pay a “payee” (the party to whom the check is written). A check is negotiated by the payee's presenting the check to the drawee bank. The presentment process is normally initiated by the payee's bank, which presents the check to the drawee bank when the payee deposits the check with his or her bank.

Presentment of a check is normally done through the Federal Reserve or a commercial banking system. Traditionally, the mechanism by which this presentment occurs is by tendering the paper check through the banking system. The paper check is physically transmitted to the drawee bank, which either accepts and pays the paper check upon receipt, or declines payment and returns the paper check. Technological and legal developments, such as procedures set forth in the Check-21 law, allow images of checks (sometimes referred to as “substitute checks”) to be presented electronically without presentment of a paper copy. Thus, starting the presentment process may involve collecting an image of the check rather than obtaining the original paper check. Check scanners have traditionally been available to read the Magnetic Ink Character Recognition (MICR) line at the bottom of the check, and this information can be used for presentment. However, it is possible to present an ordinary image of a check, where the image is collected with ordinary image scanning equipment.

A customer can take the paper check to a bank for deposit and have the bank scan the check to obtain an image. However, it is also possible to collect the image of the check from the customer who is depositing the check.

SUMMARY

An image of a check to be presented for payment can be collected from a banking customer using the customer's scanning equipment. The customer can scan the check into one or more files (e.g., one file for the front, a second file for the back). The files can then be uploaded to a server operated by the customer's bank, and the images contained in the files can be presented through the banking system for payment by the drawee bank.

The customer's bank may operate software, such as software provided on a web site, that guides the customer through the process of obtaining the check images. For example, the customer may visit the bank's web site, and the web site may instruct the customer to obtain images of both sides of the check, may instruct the customer how to position the check in the scanner, may instruct the customer as to what image format and/or resolution to use, etc. The web site may also guide the user through the process of delimiting the boundary of the check, such as by identifying a corner of the check. The bank's software can also perform certain verifications on the check, such as verifying the check against legibility and/or size standards, verifying that there is an endorsement on the back of the check, verifying that the amount of money written on the check matches the amount that the customer has indicated in a deposit request, etc.

This summary is provided to introduce a selection of concepts in a simplified form that are further described in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a user interface that requests that a depositor enter an amount of a deposit.

FIG. 2 is a diagram of a user interface that requests that a depositor provide an image of a first side of a check.

FIG. 3 is a diagram of a user interface that requests that a depositor provide an image of a second side of a check.

FIG. 4 is a flow diagram of an example process whereby an image of a check is received and presented for payment.

FIG. 5 is a diagram of an example user interface in which a user marks a boundary of a check.

FIG. 6 is a flow diagram of various stages that can be performed after an image of a check is received by a bank from a depositor.

FIG. 7 is a block diagram of an example environment in which checks may be deposited and presented.

FIG. 8 is a block diagram of an example computing environment in which example embodiments and aspects may be implemented.

DETAILED DESCRIPTION

A web site can guide a user through the process of collecting images of a check to be deposited. In some cases, the web site can provide software, such as a browser-executable applet, that drives the process of collecting images by operating the customer's scanner. For example, after the customer enters an amount of a check to be deposited, the software provided on the web site can instruct the user to place the check in the scanner bed and to click a button when ready. The software can then cause the scanner to be started, can collect the image in an appropriate format and resolution, and can then upload the image for deposit. The software can repeat the process for both sides of the check, in order to obtain images of the front and the back.

Having the web site drive the image-collection process may be simple for the customer (e.g., the bank depositor who uses the web site), since the customer may not have to address issues such as what to name the file, what format or resolution to use. Having the web site drive the process also may avoid, for the customer, the process of identifying particular files to be uploaded. However, certain permissions may be used in order to allow the web site's software to operate the scanner. Scanners are normally operated by a device driver, such as a TWAIN driver. For security reasons, the driver may require certain certificates to be used before allowing a program to operate the scanner that the driver controls. Since users often transparently download programs to run in their web browsers without realizing that they are downloading programs, programs such as applets, scripts, etc., that run in web browsers often present a particular security risk, and a driver may require such a program to obtain a certificate before it allows the program to control the scanner. Each scanner (or the scanners within a brand-mate family), may have its own driver. The drivers may be different for different operating environments—e.g., the same scanner may use a different driver depending on whether it is being operated from an environment based on one of the WINDOWS operating systems, an environment based on one of the operating systems used in APPLE computers, an environment based on a version of the LINUX operating system, etc. Each driver may use different certificates. Moreover, the different environments may use various different environment-specific technologies to allow the scanner to be controlled from a remote web server. Since the bank that operates the web site does not know what scanning equipment or operating environment its customer will be using, it may need to obtain a large number of certificates, and may need to interface with a large number of different technologies, to support a large number of scanner-environment combinations, in order to allow its software to control scanners for a variety of customers.

At present, most consumers use computers whose environment is based on one of the WINDOWS operating systems. Thus, it may make sense from a cost-benefit perspective, for a bank to obtain the certificates to operate a wide variety of scanners in environments based on the WINDOWS operating systems, and to support the technology that allows the scanner to be controlled within that environment. However, it may not make sense from a cost-benefit perspective for the bank to obtain the certificates to operate lesser-used scanners, or scanners in environments other than those based on the WINDOWS operating systems. Thus, an alternative mechanism for obtaining an image of the check may be used. One example of such a mechanism is to have the customer scan an image of the check (or separate images of the front and back of the check) into a file, and then upload the file(s) to the bank's server for presentment through a banking system.

Turning to the drawings, FIGS. 1, 2, and 3 show examples of user interfaces that could be presented to a user in order to obtain a deposit amount and the appropriate check images. These user interfaces could be presented through a web site—e.g., by delivering to a depositor's computer or other machine, web pages that cause these user interfaces to be displayed on the depositor's browser. However, these user interfaces could be presented using any mechanism.

In FIGS. 1-3, the depositor is asked to enter an amount of a check to be deposited, and is then asked to provide scanned images of the front and back of the check. Thus, in FIG. 1, user interface 100, the depositor is requested to enter the amount of a check to be deposited into box 102. This amount can be entered in the form of text. When the depositor has entered the amount of the check to be deposited, the depositor may click button 104, indicating that he or she is “finished.” FIG. 1 shows an example in which the depositor is requested to enter an amount of a single check to be deposited. However, the depositor could also be given a set of boxes to enter an arbitrary number of checks, or could be asked to enter an aggregate amount of a deposit covering several checks, or could be asked for an amount of a deposit in any other way.

FIG. 2 shows user interface 200, which requests that the depositor enter a name of a file containing an image of the front of the check to be deposited. The name, and optionally the path, of the file can be entered into box 202. When the depositor has entered the name of the file, he or she can click button 204 to indicate that he or she is “finished” entering the name. The name can be entered either by the depositor typing the name as text into box 202. Or, as another example, the depositor can be presented with a file navigation user interface 206. The depositor may click button 208 (“browse”) to access file navigation user interface 206. File navigation user interface 206 may show the depositor's local and/or network folder structure, and allow the depositor to navigate through folders and files to obtain the name of the file containing the image. When the depositor has selected the name of the file, the name (or name and path) of the file may appear in box 202 as if the depositor had typed the name (or name and path). User interface 200 could also include information and/or instructions for the depositor about the rules that govern the nature of the image to be provided—e.g., text could be displayed or communicated in user interface 200 that advises the depositor as to the format of the image to be provided (e.g., JPEG), the resolution of the image (e.g., 200 dpi), other parameters (e.g., turning on grayscale for the scan), etc. As another example, the depositor could be shown examples of “good” and “bad” scans—e.g., an image could be shown to the depositor indicating an example of scan that would be accepted, and another image could be shown to the depositor indicating an example of a scan that would not be accepted. A scan that would not be accepted might be shown as being smudged, or crooked, or obscured in some manner. There are a variety of reasons for which a scan might not be accepted, and examples demonstrating any one or more of these reasons could be shown to the depositor.

FIG. 3 shows user interface 300, which is similar to user interface 200 but asks the depositor to enter the name of a file containing an image of the back of the check instead of the front. Like user interface 200, user interface 300 may have a box 302 into which the depositor can enter the name of the file containing the appropriate image, a button 304 that the depositor can click when he or she is finished entering the file name, a browse button 306 that the depositor can use to access a file navigation user interface similar to that shown in FIG. 2 and previously discussed. Additionally user interface 300 may inform and/or instruct the depositor as to issues concerning format, resolution, other parameters, etc.

FIG. 4 is a flow diagram of an example process whereby an image of a check is received and presented for payment. It is noted that the process of FIG. 4, as well as the process discussed subsequently in connection with FIG. 5, are both described, by way of example, with reference to a web server that interacts with a depositor by communicating through a network with a browser running on the depositor's machine. However, these processes may be carried out in any system, and are not limited to the scenarios described. Moreover, these flow diagrams show examples in which stages of a process are carried out in a particular order, as indicated by the lines connecting the blocks, but the various stages shown in these diagrams can be performed in any order, or in any combination or sub-combination.

At 402, an amount of a check to be deposited is received. For example, a user interface (such as user interface 100, shown in FIG. 1) may be used to ask a depositor for the amount of a check to be deposited. As previously noted, the depositor may be given the opportunity to enter an amount of a single check, a list of amounts for plural checks, an aggregate total amount of plural checks, etc. At least one such amount is received at 402.

At 404, a name of a file that contains an image of the front side of the check is received. For example, a user interface (such as user interface 200, shown in FIG. 2) may be used to obtain the name (or name and path) of a file that contains an image of the check. The user may have already scanned the check and placed the image in a file, or the user can be instructed to scan the check (or a side of the check) at the time that the file name is to be received. The file whose name is entered may be uploaded to a server, such as a web server operated by the bank with which the check is to be deposited.

At 406, a name of a file that contains an image of the back side of the check is received. For example, a user interface (such as user interface 300, shown in FIG. 3) may be used to obtain the name (or name and path) of a file that contains an image of the check. As with 404, the user may already have scanned the check into an image file, or can be instructed to do so. The file whose name is entered may be uploaded to a server, such as a web server operated by the bank with which the check is to be deposited.

At 408, the boundaries the check are received. For example, the user may be asked to draw a boundary on the image to indicate which part of the image is the check, and which part is merely background due to the fact that amount of area scanned is generally larger than a check. One way to obtain an indication of the location of this boundary is to ask the user to scan the check by placing the top and left edges of the check directly abutting the top and left sides of the scanner bed. Thus, the top and left edges of the boundary of the check are defined by the edges of the scanning sight. Presuming that the check is a rectangle, the bottom and right edges that define the remaining portion of the boundary can be indicated by a single point in the bottom, right corner of the check. An example of this technique is shown in FIG. 5.

FIG. 5 shows a check 502, which has been scanned. Sight 504 indicates the area that has been scanned, and it can be seen that left edge 508 and top edge 510 of check 502 abut the left and top edges of the scan sight. By placing a marker (such as dot 506) in the right, bottom corner of the check, the rectangular boundary of the check is defined. Thus, it can be determined from the position of the marker which portion of sight 504 contains an image of a side of check 502, and which portion contains background. The portion that contains the image can later be used to present the check for payment through a banking system. It is noted that the marker can be positioned through various mechanisms. For example, a web server that implements the process of collecting a deposit request and check images from a depositor can download software (e.g., a plug-in, an applet, a script, etc.) that executes in the depositor's browser and allows the depositor to position a marker such as dot 506 with a pointing device, such as a mouse, trackpad, etc. This program could be used to place the marker on the image before the image is uploaded to the bank's server. As another example, the bank's server could receive the image, and then send a copy or modified version of the image back to the depositor's web browser to be operated on the program. For example, after the upload of the image, the bank's web server could cause a new window to be opened with a page containing the image, and a script, applet, plug-in, etc., that allows the depositor to place the marker. Any mechanism to allow the depositor to place the marker could be used.

Returning to FIG. 4, certain types of verifications may be performed (at 410) on the check images that have been received. For example, the images could be verified to determine they are in an acceptable format, at an acceptable resolution, or that the amount of the check shown on the front of the check matches the amount stated by the depositor, or that the back of the check contains an endorsement, or that the check complies with size standards (or other standards) according to applicable law such as the Check-21 law. In one example, the system may check that the images are in the JPEG format, or that the images are at least 200 dpi in resolution, or that the capture of the image preserves grayscale. Resolution and/or grayscale can be addressed as part of the process of verifying that the image is in an acceptable format, or compliance with resolution and grayscale parameters could be checked separately. A comparison of the amount of the check as stated by the depositor with the amount written on the check can be performed by using optical character recognition (OCR) on the check to determine the amount that it states. Or, as another example, the check could be examined by a human and compared with the amount entered by the depositor. Similarly, the presence of an endorsement on the image of the back of the check could be detected using OCR (or some other type of image processing), or could be evaluated by a human.

At 412, the images of the front and back of the check are presented for payment through a banking system. For example, a banking system such as the Federal Reserve or a commercial banking system may operate a server to which these images can be provided, and the images can be presented to the drawee bank through such system. An example of a banking system is shown in FIG. 7, and is discussed subsequently.

FIG. 6 shows an example of various stages that can be performed after an image of a check is received by a bank from a depositor. For example, when images of a check are from a depositor by the bank's web server, certain processing can be performed on the image to prepare the check for presentment through a banking system. FIG. 6 shows examples of stages of such processing. It should be noted that 602, 604, and 606, as shown in FIG. 6, provide additional detail of features that are discussed previously in connection with 410 in FIG. 4.

At 602, the files containing the image may be evaluated to determine whether they are in an appropriate format. For example, features of the images, such as file format (e.g., JPEG, GIF, TIF, etc.) may be evaluated. In one example, the depositor may be instructed to upload the images in JPEG format, and an image may be rejected if the evaluation at 602 determines that the image is in a different format. Additional features that may be evaluated include resolution of the image, the presence of grayscale, compliance with legal standards such as Check-21, etc.

At 604, a verification may be performed to determine that the amount of money written on the check corresponds to the amount of the check reported by the depositor. For example, the image of the front of the check can be evaluated by an OCR process, read by a human, etc., and this amount can be compared to the amount of the deposit as entered by the depositor.

At 606, the image of the back of the check may be evaluated to determine the presence of an endorsement. For example, an OCR process, or other type of image processing, may be performed to determine whether the image contains an endorsement. Or the image can be given to a human to evaluate for the presence of an endorsement.

At 608, the images of the check may be converted to an appropriate format for presentment through a banking system. For example, the banking system may impose certain standards such as file format, headers, metadata, etc. The images may be modified and/or packaged to comply with these standards prior to presentment of the check images through a banking system.

FIG. 7 shows an example environment in which checks may be deposited and presented. Depositor 702 may be a customer of financial institution 712. Financial institution 712 may, for example, be a bank, but could also be any other type of financial institution, such as an investment company, an insurance company, etc. Depositor may operate a computer 704, which may be located at depositor 702's residence, but could also be located in any other place. Computer 704 may be connected to image capture device 706, which may be a scanner, camera, etc. Computer 704 may be connected to other machines through network 708. The Internet is an example of network 708, although computer 704 could be connected to other machines through any network.

One example of a machine that computer 704 could be connected to through network 708 is server 710, which, in this example, is a server operated by depositor 702's financial institution 712. Server 710 may operate software that implements a web site, and depositor 702 may use that web site to interact with financial institution 712, for example by tendering checks for deposit into an account with financial institution 712 through the web site. As previously discussed, one way that a depositor could tender a check for deposit is to provide scanned images of the check and to upload the images to a web site associated with a bank. If depositor 702 uses image capture device 706 to scan images of a check, and then uses a browser running on computer 704 to upload such images to server 710 through network 708, then this scenario would be one example of the subject matter described herein. However, the subject matter described herein encompasses other scenarios.

Financial institutions 716 and 718 are financial institutions such as banks, investment companies, insurance companies, etc. They may also include a clearinghouse or a national central bank (such as the Federal Reserve or a branch thereof). Financial institutions 712, 716, and 718 may communicate with each other via a network 714. Network 714 may be a publicly-accessible network, such as the Internet, but also may be a private network. For example, financial institutions 712, 716, and 718 may have security issues when they communicate with each other that do not apply to ordinary communications, and thus network 714 may provide security features that network 708 does not. However, network 714 could be any type of network.

Account 722, in the example of FIG. 7 is an account that depositor 702 maintains at financial institution 712. Depositor 702 may be in possession of a check that is drawn against account 724 maintained at financial institution 718 (in which case financial institution 718 is the drawee). Depositor 702 may deposit the check into account 722 by delivering the check to financial institution 712, where such delivery may be in the form of physical delivery of the original paper check, sending an image of the check, etc. Upon receipt of the check (whether in paper form, image form, or otherwise), financial institution 712 may clear the check by presenting the check through a banking system, such as banking system 720. Presentment of the check may be made directly to drawee financial institution 718, or could be made to an intermediary financial institution, such as a branch of the Federal Reserve, a correspondent bank, a clearinghouse, etc. The intermediary bank can be a government actor (as in the case of the Federal Reserve in the United States, or the central bank of another country), or it could be a commercial actor, such as a correspondent bank or clearinghouse.

In one example, the check is cleared by presenting the check to financial institution 716, which may, for example, be a regional branch of the Federal Reserve, along with a request for payment. Financial institutions 712 and 718 may each have accounts at financial institution 716. Financial institution 712 may create a substitute check using an image provided by depositor 702, and may present the substitute check to financial institution 716. Upon receiving the substitute check, financial institution 716 may identify financial institution 718 as the drawee bank—e.g., by using the nine-digit routing number that is normally printed on checks in the United States. Financial institution 716 may then present the substitute check to financial institution 718 and request that the check be paid. If financial institution 718 agrees to honor the check, then financial institution 716 may then settle the check by debiting funds from an account of financial institution 718 and crediting funds to an account of financial institution 712.

It will be appreciated that the preceding examples are for illustration, and not limitation. For example, financial institution 718 may have a relationship with financial institution 712, and financial institution 712 may use this relationship to clear the check directly with financial institution 718, while bypassing the Federal Reserve, other national central bank, or clearinghouse. In addition, accounts 722 and 724 could be held at the same financial institution 712, in which case the check may be cleared internally.

The subject matter described herein may be implemented through the use of a computer system, or other type of device that has some computing mechanism(s). FIG. 8 shows an example computing environment in which example embodiments and aspects may be implemented. The computing system environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality.

Numerous other general purpose or special purpose computing system environments or configurations may be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers (PCs), server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the previously-described systems or devices, and the like.

Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.

With reference to FIG. 8, an example system for implementing aspects described herein includes a computing device, such as computing device 800. In its most basic configuration, computing device 800 typically includes at least one processing unit 802 and memory 804. Depending on the exact configuration and type of computing device, memory 804 may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 8 by dashed line 806.

Computing device 800 may have additional features/functionality. For example, computing device 800 may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 8 by removable storage 808 and non-removable storage 810.

Computing device 800 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computing device 800 and includes both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 804, removable storage 808, and non-removable storage 810 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computing device 800. Any such computer storage media may be part of computing device 800.

Computing device 800 may also contain communications connection(s) 812 that allow the device to communicate with other devices. Communications connection(s) 812 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.

Computing device 800 may also have input device(s) 814 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 816 such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here.

It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an API, reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

Although example embodiments may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described previously. Rather, the specific features and acts described previously are disclosed as example forms of implementing the claims.

Claims

1. An image processing system comprising: a memory;a processor in communication with said memory;wherein the processor is configured to: transmit a browser-executable applet to a remotely located depositor computing device to generate a user interface for display at the depositor computing device;cause the depositor computing device via the applet to display alignment instructions for aligning a negotiable instrument in an image region of an image capture device of the depositor computing device, and for adding a user input marker at the user interface to identify at least one edge of the negotiable instrument;receive a file transmitted from the depositor computing device comprising an image of the negotiable instrument and the user input marker; anddetermine which portion of the image to present for processing based on the user input marker.

2. The image processing system of claim 1, wherein the depositor computing device is a handheld device.

3. The image processing system of claim 1, wherein the user input marker comprises where, in the image, a corner of the negotiable instrument is located.

4. The image processing system of claim 1, wherein the user input marker indicates which part of the image comprises the negotiable instrument and which part comprises background.

5. The image processing system of claim 1, wherein the processor is further configured to: receive the image of the negotiable instrument from the depositor computing device; andtransmit a copy of the received image back to the depositor computing device along with instructions to modify the interface to accept placement of the user input marker on the copy of the image.

6. The image processing system of claim 1, wherein the processor is further configured to: analyze an image format of the image of the negotiable instrument; andwhen the image format fails to comply with a predetermined image format, reject the image of the negotiable instrument.

7. The image processing system of claim 1, wherein the processor is further configured to, after receiving the image of the negotiable instrument: transmit, via a network to the depositor computing device, a system image of the negotiable instrument, the system image being based on the image of the negotiable instrument; andcause the depositor computing device to display the system image for receiving the user input marker from a user via manual input on the displayed system image.

8. The image processing system of claim 7, wherein the processor is configured to transmit software for execution on a browser of the depositor computing device for enabling a user of the depositor computing device to place the user input marker on the system image.

9. The image processing system of claim 7, wherein the system image comprises a modification of the image of the negotiable instrument.

10. The image processing system of claim 8, wherein the transmitted software for execution, in response to receipt of the system image at the depositor computing device, is configured to cause the depositor computing device to display the system image in a new window on the depositor computing device for input of the user input marker on the displayed system image.

11. The image processing system of claim 1, wherein the file comprises a first image of a first side of the negotiable instrument and a second image of a second side of the negotiable instrument; and wherein the user input marker received from the depositor computing device comprises a first user input marker identifying where, in the first image, a first edge of the first side of the negotiable instrument is located and a second user input marker identifying where, in the second image, a second edge of the second side of said negotiable instrument is located.

12. The image processing system of claim 11, wherein the first user input marker is indicative of a first corner the negotiable instrument in the first image; and wherein the second user input marker is indicative of a second corner the negotiable instrument in the second image.

13. A processor-implemented negotiable instrument deposit method, comprising: with a processor of an image processing system, transmitting a browser-executable applet to a remotely located depositor computing device;generating via the applet a user interface at the depositor computing device for controlling image capture of a negotiable instrument;causing the depositor computing device via the applet to display alignment instructions for aligning the negotiable instrument in an image region of an image capture device of the depositor computing device, and for adding a user input marker at the user interface to identify at least one edge of the negotiable instrument;receiving at the processor a file transmitted from the depositor computing device comprising an image of the negotiable instrument and the user input marker; anddetermining which portion of the image to present for processing based on the user input marker.

14. The method of claim 13, wherein the user input marker is a representation of a manual input from a pointing device of the depositor computing device.

15. The method of claim 14, further comprising: analyzing, with the processor of the image processing system, an image format of the image of the negotiable instrument; andwhen the image format fails to comply with a predetermined image format, rejecting the image of the negotiable instrument.

16. The method of claim 15, further comprising the processor, after receiving the image of the negotiable instrument: transmitting, via a network to the depositor computing device, a system image of the negotiable instrument, the system image being based on the image of the negotiable instrument; andcausing the depositor computing device to display the system image for receiving the user input marker from a user via manual input on the displayed system image.

17. The method of claim 16, wherein the system image comprises a modification of the image of the negotiable instrument.

18. The method of claim 13, wherein: receiving the file comprises receiving a first image of a first side of the negotiable instrument and a second image of a second side of the negotiable instrument; andreceiving the user input marker received from the depositor computing device comprises a first user input marker indicating where, in the first image, a first edge of the first side of the negotiable instrument is located and a second indication indicating where, in the second image, a second edge of the second side of the negotiable instrument is located.

19. The method of claim 13, wherein the user input marker identifies where in the image an edge of the negotiable instrument is located and comprises a point at a corner of the negotiable instrument.

20. A non-transitory computer-readable storage medium comprising computer-readable instructions configured for execution using a processor of an image processing system, the instructions configured, upon execution to: transmit a browser-executable applet to a remotely located depositor computing device to generate a user interface for display at the depositor computing device;cause the depositor computing device via the applet to display alignment instructions for aligning a negotiable instrument in an image region of an image capture device of the depositor computing device, and instructions for adding a user input marker at the user interface to identify at least one edge of the negotiable instrument;receive a file transmitted from the depositor computing device comprising an image of the negotiable instrument and the user input marker; anddetermine which portion of the image to present for processing based on the user input marker.