Patent Publication Number: US-8542921-B1

Title: Systems and methods for remote deposit of negotiable instrument using brightness correction

Description:
BACKGROUND 
     Checks typically provide a safe and convenient method for an individual such as a payor to transfer funds to a payee. To use a check, the individual usually opens a checking account, or other similar account, at a financial institution and deposits funds, which are then available for later withdrawal. To transfer funds with a check, the payor usually designates a payee and an amount payable on the check. In addition, the payor often signs the check. Once the check has been signed, it is usually deemed negotiable, meaning the check may be validly transferred to the payee upon delivery. By signing and transferring the check to the payee, the payor authorizes funds to be withdrawn from the payor&#39;s account on behalf of the payee. 
     While a check may provide a payor with a convenient and secure form of payment, receiving a check may put certain burdens on the payee, such as the time and effort required to deposit the check. For example, depositing a check typically involves going to a local bank branch and physically presenting the check to a bank teller. To reduce such burdens for the payee, systems and methods have been developed to enable the remote deposit of checks. For example, the payee may scan a check in a digital image using a scanner or other imaging device and a computing device. The financial institution may then receive from the payee the digital image of the check. The financial institution may then use the digital image to credit funds to the payee. However, such a technique requires the efficient and accurate detection of the information pertaining to a check in the digital image. Detecting and extracting the information from the digital image is difficult. 
     SUMMARY 
     An image of a negotiable instrument may be taken by an imaging device and provided from a user to a financial institution via a computing device. Any technique for sending the image to the financial institution may be used. The financial institution may process the image using operations such as deskewing the image, dewarping the image, and detecting corners or edges of the check in the image. Brightness correction may then be performed on the image. The negotiable instrument may be deposited in a user&#39;s account using the brightness corrected image. 
     In an implementation, brightness correction may be performed on the image using a histogram of the image with an overlaid reference mark. In an implementation, a computing device of the user may determine brightness correction information of the image and provide the brightness correction information to the financial institution. The financial institution may perform brightness correction on the image using the brightness correction information received from the computing device of the user. 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described below 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 
       The foregoing summary, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the embodiments, there are shown in the drawings example constructions of the embodiments; however, the embodiments are not limited to the specific methods and instrumentalities disclosed. In the drawings: 
         FIG. 1  is a block diagram of an implementation of a system in which example embodiments and aspects may be implemented; 
         FIG. 2  is a block diagram of another implementation of a system in which example embodiments and aspects may be implemented; 
         FIG. 3  is a diagram of an example image comprising check data, background data, and a reference mark that may be used with brightness correction; 
         FIG. 4  is a diagram of an example histogram for an image comprising check data, background data, and a reference mark; 
         FIG. 5  shows a high-level block diagram of an implementation of a system that may be used for the deposit of a negotiable instrument; 
         FIG. 6  shows a data flow diagram of a system for the deposit of a negotiable instrument, in accordance with an example embodiment; 
         FIG. 7  shows a block diagram of a client apparatus for the deposit of a negotiable instrument, in accordance with an example embodiment; 
         FIG. 8  shows a block diagram of a server apparatus for the deposit of a negotiable instrument, in accordance with an example embodiment; 
         FIG. 9  is an operational flow of an implementation of a method that may be used for deposit of a negotiable instrument; 
         FIG. 10  is an operational flow of another implementation of a method that may be used for deposit of a negotiable instrument; and 
         FIG. 11  is a block diagram of an example computing environment in which example embodiments and aspects may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     In the following detailed description of example embodiments, reference is made to the accompanying drawings, which form a part hereof and in which is shown, by way of illustration, specific embodiments in which the example methods, apparatuses, and systems may be practiced. It is to be understood that other embodiments may be used and structural changes may be made without departing from the scope of this description. 
       FIG. 1  is a block diagram of an implementation of a system  100  in which example embodiments and aspects may be implemented. System  100  may include an account owner, referred to herein as a user  102 , and financial institutions  130 ,  140 , and  150 , which may be any type of entity capable of processing a transaction involving a negotiable instrument, such as processing checks and/or providing funds associated with checks. For example, each of the financial institutions  130 ,  140 , and  150  may be a financial services institution such as a retail bank, an investment bank, an investment company, a regional branch of the Federal Reserve, a clearinghouse bank, and/or a correspondent bank. 
     A negotiable instrument typically includes a type of contract that obligates one party to pay a specified sum of money to another party. Negotiable instrument as used herein is an unconditioned writing that promises or orders payment of a fixed amount of money. One example of a negotiable instrument is a check. The check may be taken by the receiving party and deposited into an account at a financial institution of the receiving party. The receiving party may endorse the check and then present it for deposit at a bank branch, via an automated teller machine (ATM), or by using remote deposit. Other examples of negotiable instruments include money orders, cashier&#39;s checks, drafts, bills of exchange, promissory notes, and the like. A money order is a trusted financial instrument that is a payment order for a pre-specified amount of money. A cashier&#39;s check (also known as a bank check, official check, teller&#39;s check, bank draft or treasurer&#39;s check) is a check guaranteed by a bank and may be purchased from a bank. 
     The user  102  may be an individual or entity who owns account  160  that may be held at financial institution  130  and is accessible via an institution system  205 , described further with respect to  FIG. 2 . Account  160  may be any type of deposit account for depositing funds, such as a savings account, a checking account, a brokerage account, and the like. The user  102  may deposit a check  108  or other negotiable instrument in the account  160  either electronically or physically. The financial institution  130  may process and/or clear the check  108  or other negotiable instrument. The user  102  may communicate with financial institution  130  by way of communications network  120  such as an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless fidelity (WiFi) network, a public switched telephone network (PSTN), a cellular network, a voice over Internet protocol (VoIP) network, and the like. The user  102  may communicate with financial institution  130  by phone, email, instant messaging, text messaging, web chat, facsimile, mail, and the like. Financial institutions  130 ,  140 , and  150  also may communicate with each other by way of communications network  120 . 
     In an implementation, the user  102  may receive payment from another individual such as a payor in the form of a check  108  or other negotiable instrument that is drawn from account  170  at financial institution  150 . The user  102  may endorse the check  108  (e.g., sign the back of the check  108 ) and indicate an account number on the check  108  for depositing the funds. It is noted that although examples described herein may refer to a check, the techniques and systems described herein are contemplated for, and may be used for, deposit of any negotiable instrument. Similarly, the techniques and systems described herein are contemplated for and may be used with any form or document whose image may be captured with a scanner, camera, or other imaging device for subsequent storage and/or processing. 
     As described further herein, a digital image of a check or other negotiable instrument may be provided from a user to a financial institution, and the digital image may be processed and funds associated with the check or negotiable instrument in the digital image may be deposited in a user&#39;s bank account. The user  102  may deposit the check  108  into account  160  by making a digital image of the check  108  and sending the image file containing the digital image to financial institution  130 . For example, after endorsing the check  108 , the user  102  may use an imaging device  106  that comprises a camera to convert the check  108  into a digital image by taking a picture of the front and/or back of the check  108 . The imaging device  106  may be a scanner, a camera, a video camera, a web camera, a mobile phone (also known as a wireless phone or a cellular phone), a personal digital assistant (PDA), or any computing device capable of capturing an image of a negotiable instrument, for example. 
     In an implementation, the user  102  may send the digital image(s) to financial institution  130  using the imaging device  106  or a computing device associated with the imaging device. Any technique for sending a digital image to financial institution  130  may be used, such as providing a digital image to a website associated with financial institution  130  from storage, emailing a digital image to financial institution  130 , or sending a digital image in a text message or instant message, for example. 
     Financial institution  130  may receive a digital image representing the check  108  and may use image processing software or other application(s) to obtain the relevant data of the check  108  from the digital image. Image processing may comprise corner detection, perspective correction, and cropping, for example, using any known techniques. Brightness correction may also be performed to enhance the image. As described further herein, brightness correction may include placing a dark (e.g., black) reference mark, such as a cross for example, on the check image, which provides an absolute black reference so that the other color levels may be more easily ascertained (e.g., using a histogram) and adjusted to generate a bi-tonal image which can be read by a financial institution&#39;s image processor more easily. 
     Financial institution  130  may determine whether the financial information associated with the check in the processed image may be valid. For example, financial institution  130  may include any combination of systems and subsystems such as electronic devices including, but not limited to, computers, servers, databases, or the like. The electronic devices may include any combination of hardware components such as processors, databases, storage drives, registers, cache, random access memory (RAM) chips, data buses, or the like and/or software components such as operating systems, database management applications, or the like. According to an embodiment, the electronic devices may include a network-based server that may process the financial information and may receive the digital image from the user  102 . 
     The electronic devices may receive the digital image and may perform an analysis on the quality of the digital image, the readability of the data contained therein, or the like. For example, the electronic devices may determine whether the account number, amount payable, and the like may be readable such that it may be parsed or otherwise obtained and processed by the financial institution  130  to credit an account  160  associated with the user  102  and debit an account associated with the payor. In an implementation, a representative  135  of financial institution  130  may provide assistance to the user  102  and may provide assistance in determining whether the financial information may be readable and/or of a good enough quality to be processed, as described further herein. 
     Upon receipt, processing, and approval of the digital image, financial institution  130  may credit the funds to account  160 . In an implementation, financial institution  130  may process data from the check  108  using data obtained from the digital image, such as financial information and other information from the check  108  (e.g., place of issue, check number, date of issue, payee, amount of currency, signature of the payor, routing/account number in MICR (magnetic ink character recognition) format, transit number, etc.). 
     Financial institution  130  may clear the check  108  by presenting the processed image (which has been processed with brightness correction) to an intermediary financial institution, such as a regional branch of the Federal Reserve, a correspondent bank, and/or a clearinghouse bank. A financial institution receiving the processed image from financial institution  130  may obtain the data pertaining to the check  108  from the processed image. 
     In an implementation, the check  108  may be cleared by presenting the processed image to financial institution  140 , which may be a regional branch of the Federal Reserve, along with a request for payment. Financial institutions  130  and  150  may have accounts at the regional branch of the Federal Reserve. Upon receiving the processed image, financial institution  140  may identify financial institution  150  as the paying bank (e.g., the bank from which the check  108  is drawn). This may be accomplished using a nine-digit routing number located on the bottom left hand corner of the check. A unique routing number is typically assigned to every financial institution in the United States. Financial institution  140  may present the processed image (or a substitute check generated using the processed image) to financial institution  150  and request that the check be paid. If financial institution  150  verifies the check (i.e., agrees to honor the check), financial institution  140  may then settle the check  108  by debiting funds from financial institution  150  and crediting funds to financial institution  130 . Financial institution  150  may then debit funds from account  170 . 
     It will be appreciated that the preceding examples are for purposes of illustration and explanation only, and that an embodiment is not limited to such examples. For example, financial institution  150  may be a correspondent bank (i.e., engaged in a partnership with financial institution  130 ). Thus, financial institution  130  may bypass the regional branch of the Federal Reserve and clear the check directly with financial institution  150 . In addition, account  160  and account  170  may both be held at financial institution  130 , in which case the check  108  may be cleared internally. 
       FIG. 2  is a block diagram of another implementation of a system in which example embodiments and aspects may be implemented. The user  102  is shown along with an institution system  205 . The institution system  205  may be affiliated with financial institution  130 . The user  102  may access the financial institution  130  via the institution system  205  by opening a communication pathway via the communications network  120  using a user computing device  109 . There may be several ways in which the communication pathway may be established, including, but not limited to, an Internet connection via a website  218  of the institution system  205 . The user  102  may access the website  218  and log into the website  218  using credentials, such as, but not limited to, a username and a password. 
     The user  102  may use the imaging device  106  to generate a digital image of the check  108 . The digital image may be used to create a digital image file  136  that may be sent to the institution system  205  and used by the financial institution  130 , in conjunction with the institution system  205 , to process a deposit of the check  108  whose image  137  is comprised within the digital image file  136 . In an implementation, the digital image file  136  may be augmented by secondary data which may be information relating to the deposit of the check  108 , such as an account number and a deposit amount, for example. 
     The user  102  may place the check  108  on a background and generate a digital image comprising an image of the check  108  (e.g., a check image) and a portion of the background (e.g., a background image) using the imaging device  106  that may be standalone or part of a phone or other user computing device. Any background may be used. It is noted that although examples and implementations described herein may refer to a check image and check data, the term “check image” may refer to any foreground image in a digital image (as opposed to the background image) and the term “check data” may refer to any foreground data in a digital image (as opposed to background data such as background data). Thus, the “check image” and the “check data” may refer to the foreground image and foreground data in implementations involving any negotiable instrument, form, or document. In an implementation, the digital image generated by the imaging device  106  comprises check data and background data. The check data pertains to the check image in the digital image and the background data pertains to the background image in the digital image on which the image of the check  108  is displayed. 
     The user  102  may thus generate a digital image of the check  108  using the imaging device  106 , in an implementation. For example, after endorsing the check  108 , the user  102  may use a device such as the imaging device  106  and/or the user computing device  109  for example, to make a digital image of the front sides and/or back sides of the check  108  and to store the digital image(s) in a digital image file. The images of the front side and the back side of the check  108  may be processed using the techniques described herein. The images may be processed as separate files or as images in single file. The images of the front side and the back side of the check  108  may be captured sequentially, e.g., pursuant to the user  102  flipping the check  108  over after an image of the front of the check  108  has been captured. 
     The digital image file  136  comprising an image  137  of the check may be transmitted to the institution system  205 . The user  102  may send the digital image file  136  and any secondary data to the institution system  205  along with a request to deposit the check  108  into an account, such as the account  160 . In an implementation, the user  102  may attach the digital image file  136  to an email and send the digital image file  136  to the institution system  205  using the same device used to make the digital image file  136  of the check  108  or another computing device. However, any technique for sending a digital image file  136  to the institution system  205  may be used, such as providing a digital image file  136  from storage to the website  218  associated with the institution system  205 . 
     The financial institution  130  in conjunction with the institution system  205  may process the deposit request according to the digital image file  136  and any secondary data. Thus, the financial institution  130  in conjunction with the institution system  205  may process the digital image file  136  comprising the image  137  of the check  108  for deposit. 
     In an implementation, the institution system  205  may comprise an image processor  222  that processes the digital image file  136  received from the user computing device  109 . In an implementation, the institution system  205  may retrieve the image  137  of the check  108  from the digital image file  136  and process the check  108  from the image  137  for deposit. The image processor  222  may comprise any known image processing technology, software, or other application(s) to perform operations on the image  137  of the check  108  such as deskewing, dewarping, magnetic ink character recognition, cropping (either automatically, or having the user  102  manually identify the corners and/or edges of the check  108  for example), reducing the resolution of the image, number detection, character recognition, and the like. The image processor  222  may comprise a grayscale converter that may convert the digital image generated by the imaging device  106  to grayscale using known techniques. In photography and computing, a grayscale digital image is an image in which the value of each pixel is a single sample, that is, it carries only intensity information. Images of this sort are composed exclusively of shades of gray, varying from black at the weakest intensity to white at the strongest. Conversion of a color image to grayscale is well known and any known technique(s) may be used. 
     The image processor  222  may also perform brightness correction on the image, e.g., after it has been processed for deskewing, dewarping, edge detection, etc. As described further with respect to  FIGS. 3 ,  4 , and  9 , for example, a black reference mark may be superimposed (e.g., overlaid) on the image of the check  108  (that has been processed thus far), a histogram of the image may be generated using a histogram generator  224 , and the brightness of the image may be corrected (if appropriate) using a brightness corrector  225  and the histogram. A histogram is a well known graph and may be used to display where all of the brightness levels contained in an image are found, from the darkest to the brightest. These values may be provided across the bottom of the graph from left (darkest) to right (brightest). The vertical axis (the height of points on the graph) shows how much of the image is found at any particular brightness level. An example histogram is further described with respect to  FIG. 4 . 
     After the image has been brightness corrected, any image processing technology, software, or other application(s) may be used to obtain the relevant data of the check  108  from the brightness corrected image. The institution system  205  may determine whether the financial information associated with the check  108  may be valid. 
     In an implementation, the image processor  222  may process multiple frames of the image if the image is comprised of multiple frames (e.g., the front side and the back side of a check). For example, after receiving the digital image file  136 , the image processor  222  may retrieve the image(s)  137  of the check  108  and process (e.g., dewarp, deskew, edge detect, brightness correct, etc.) the image  137  or an image based on the image  137  for deposit. The image processor  222  has access to data, files, and documents pertaining to the user  102  as well as any other data, files, and documents that are internal or external to the institution system  205  that may be useful in processing the digital image file  136  and/or the data contained therein. 
     Upon receipt and processing of the digital image file  136  and approval of the check  108  associated therewith, the financial institution  130  may credit the funds of the check  108  to the account  160 . 
     The user computing device  109  may be integral with the device used to make the digital image of the check  108  and/or the digital image file  136  or separate from the device used to make the digital image of the check  108  and/or the digital image file  136 . The user computing device  109  may be a personal computer (PC), a handheld computing device, a PDA, a mobile phone, or a smartphone, for example. The user computing device  109  may comprise the imaging device  106 . An example user computing device  109  is described with respect to  FIG. 11 . 
     In an implementation, the user computing device  109  may be a mobile computing device (such as a handheld computing device, a PDA, a mobile phone, a smart phone, a portable PC, etc.) that comprises a camera which can capture a digital image of the check  108  by taking a picture of the front and/or back of the check  108 . The back of the check  108  may provide endorsement verification, such as the signature of the person or party the check  108  is made out to. The user  102  may send the digital image file  136  to the institution system  205  using the mobile computing device. It is contemplated that any device that is capable of generating a digital image may be used to make a digital image of the check  108  which may be processed as described herein for sending to the institution system  205  as a digital image file  136 . Additionally, a video source may be used to capture a video that may be processed at the user computing device  109  and/or the institution system  205  in accordance with the operations described herein. Such a video source may include a video camera, a web camera, or a video-enabled phone. A live video or a stored video of the check  108  may be captured, processed, and/or transmitted to the institution system  205  for deposit of the check  108 . 
     In an implementation, the user computing device  109  may comprise an image processor  107  that may process the image generated by the imaging device  106 . The image processed by the image processor  107  may be provided to the institution system  205  in the digital image file  136  as the image  137 . The image processor  107  may use any known image processing technology, software, or other application(s) to perform operations on the image of the check  108  generated by the imaging device  106  such as deskewing, dewarping, cropping, and/or edge detection, for example. In an implementation, as described further with respect to  FIG. 10  for example, the image processor  107  may overlay a black reference mark on the image of the check  108  (that has been processed by the image processor  107  thus far) and generate a histogram of the image. A threshold point may be determined using the histogram and the processed image and the threshold information (or brightness information based on the threshold information) may be sent to the institution system  205  for brightness correction of the image as appropriate. 
     The institution system  205  may include a user interface module  220  and a data source access engine  227 . The user interface module  220  may generate and format one or more pages of content  219  as a unified graphical presentation that may be provided to the user computing device  109 . In an implementation, the page(s) of content  219  may be provided to the user computing device  109  via a secure website  218  associated with the institution system  205 . 
     The institution system  205  has the ability to retrieve information from one or more data sources  229  via the data source access engine  227 . Data pertaining to the user  102  and/or the user account  160  and/or processing and clearing of a check may be retrieved from data source(s)  229  and/or external data sources. The retrieved data may be stored centrally, perhaps in storage  208 . Data source(s)  229  may contain data, metadata, email, files, and/or documents that the institution system  205  maintains pertaining to the user  102 , such as personal data such as name, physical address, email address, etc. and financial data such as credit card numbers and deposit account numbers. Such data may be useful for processing the digital image file  136 . Additionally or alternatively, the financial institution  130  or the institution system  205  may access this information when processing or clearing a check. Other information may be provided to the institution system  205  from the user  102 . 
     The user computing device  109  may provide access to a system which is coupled to the institution system  205 . A system may be configured to format and transmit a graphical user interface to the user  102 , and through the graphical user interface provide the user  102  the ability to interact with information that may be maintained, requested, and/or provided by the institution system  205 . As mentioned above, the institution system  205  may provide a unified graphical presentation output. In an implementation, the unified graphical presentation is combined with other materials and transmitted to the user  102 . A user access system may be implemented as a web server in an implementation. The user access system, through the use of any suitable interactive web technology, provides an interactive experience to the user  102  through which access to check processing and clearing data and status and related data can be accomplished. Any technology that provides interactivity through a web browser is considered to be within the scope of the present discussion and may include, without limitation, Hyper-Text Mark-Up Language (HTML), Dynamic HTML (DHTML), JavaScript, and Ajax. 
     The institution system  205  may comprise one or more computing devices  206 . The computing device(s)  206  may have one or more processors  207 , storage  208  (e.g., storage devices, memory, etc.), and software modules  209 . The computing device(s)  206 , including processor(s)  207 , storage  208 , and software modules  209 , may be used in the performance of the techniques and operations described herein. Examples of software modules  209  may include modules that may be used in conjunction with receiving and processing a digital image file  136  comprising an image  137  of the check  108 , retrieving data from the digital image file  136 , performing brightness correction on an image obtained from the digital image file  136 , generating web page content for display, and receiving instructions from the user  102 , for example. While specific functionality is described herein as occurring with respect to specific modules, the functionality may likewise be performed by more, fewer, or other modules. An example computing device and its components are described in more detail with respect to  FIG. 11 . 
       FIG. 3  is a diagram of an example image  250  comprising check data  255  (associated with a check image), background data  260  (associated with a background image), and an overlaid reference mark  263  that may be used with brightness correction. The image  250  may have been generated by an imaging device associated with the user computing device  109 , such as the imaging device  106 , and then processed for dewarping, deskewing, edge detection etc. The image  250  comprises check data  255  that is associated with the check  108 . The image  250  also comprises background data  260  that is associated with the portion of the image that is not associated with the check  108  (e.g., the background on which the check  108  was placed when the image  250  was generated by the imaging device  106 ). An edge  257  separates the check data  255  from the background data  260 . The edge  257  may be detected using known techniques. 
     The reference mark  263  may be overlaid on the thus far processed image such that it covers a portion of the check data  255  and the background data  260 . Although the reference mark  263  is shown as a cross shape, the reference mark  263  may take any shape (e.g., one or more horizontal lines, one or more vertical lines, any pattern, etc.), and have any area, subject to a constraint that the reference mark  263  overlays a portion of the check data  255  and a portion of the background data  260  (if any) separated by a portion of the edge  257  in an implementation. In this manner, distinct areas of density corresponding to the image (e.g., the check data and the background data) and the reference mark overlaid on the image may be provided in a histogram. Light tends to vary from quadrant to quadrant on a check image, and thus a cross may be used to divide the image  250  into quadrants. In an implementation, with the reference mark  263  having a cross shape, the width and height of the cross may be determined based on the width and the height of the image  250 , for example. In an implementation, the height may be approximately twice as large as the width, for example. 
     A histogram may be generated for the image and used in brightness correction.  FIG. 4  is a diagram of an example histogram  400  for an image comprising check data, background data, and a reference mark such as those of  FIG. 3 . The horizontal axis of the histogram  400  represents the grayscale level between 0 and 255, where 0 represents true black and 255 represents true white. The vertical axis represents the amount of the image at a particular grayscale level of the horizontal axis. Any known technique for generating a histogram for a grayscale image may be used. 
     A threshold point  405  (or threshold level) on the histogram may be determined and compared to a predetermined constant value to determine the amount of brightness correction, if any, that is to be applied to the image of the check. Depending on the implementation, the threshold point may be a predetermined location on the histogram curve  407 , such as the minimum grayscale level (e.g., point a, corresponding to the beginning point of the curve  407 ), the highest amount level shown by the curve  407  (e.g., point b, corresponding to the peak of the curve  407 ), or the maximum grayscale level (e.g., point c, corresponding to the ending point of the curve  407 ). 
     In an implementation, if the threshold point  405  is above a predetermined constant value, then an intensity (or brightness) may be added to each of the pixels as brightness correction; otherwise no intensity (or brightness) is added to the pixels of the image. Thus, for example, for an image of a check that is bright, there may be no change (e.g., no brightness is added), and for a dark check (e.g., not enough contrast between the check data and the background data), some brightness may be added. Data may then be obtained more easily from the image of the check. The amount of intensity or brightness that may be added may be a percentage, such as to make each pixel 10 percent brighter, 20 percent brighter, etc., or may be a fixed amount of brightness such that each pixel receives the same amount of additional brightness. 
       FIG. 5  shows a high-level block diagram of an implementation of a system  500  that may be used for the deposit of a negotiable instrument. In an implementation, the user  102  may deposit the funds of a negotiable instrument, such as the check  108 , using the camera functionality in the mobile device  506 . In the example of one person giving a check to another person, this would enable the receiving party to deposit the funds at that time, without physically visiting an ATM or a bank branch. 
     In an implementation, the system  500  may include the user  102  and a depository  504 . The mobile device  506  may comprise a camera  507 , such as a digital camera. Such a mobile device may be called a camera phone. The mobile device  506 , through the camera  507 , has the ability to take or capture a picture or digital image of the check  108  or other negotiable instrument. In an implementation, the camera  507  may take an image of the front of the check  108 . Alternatively, the camera  507  may take an image of both the front and the back of the check  108 . 
     The depository  504  may include a bank in which the user  102  has a deposit account; however, the present disclosure is not limited to just banks. Alternatively, a third party may act as the depository  504  providing functionality to a plurality of users without regard to the bank at which they have deposit accounts, or whether their individual bank allows for the methods and systems described herein. The depository  504 , in an implementation, after receiving the image(s) of the check  108  from the user  102 , may use a clearinghouse  510  to perform the check clearing operations. Check clearing operations are used by banks to do the final settlement of the check  108 , such as removing funds from the account of the payor and transferring those funds to the user&#39;s bank. 
       FIG. 6  shows a data flow diagram  600  of a system for the deposit of a negotiable instrument, in accordance with an example embodiment. A client  620  is one example of the mobile device  506  or the user computing device  109 . In an implementation, a server  622  may be a software component operable by the depository  504 . 
     The client  620  may log in to a remote deposit system executed on the server  622 . The login  625  may serve to authenticate the user  102  as an authorized consumer of the depository  504 . The server  622 , in one example, may send instructions  630  to the client  620  that execute an application on the client  620 . This may include instructions that cause a software object, which may have been previously downloaded and installed on the client  620 , to be executed on the client  620 . In another example, the instructions  630  may include a wholly self-contained application that when delivered to the client  620  will execute and perform one or more operations described herein. In either example, the software object may be configured to make one or more software calls  610  to a digital camera, such as the camera  507 , or other imaging device, associated with the mobile device  506  or the user computing device  109 . This may be through specific software instructions to the camera or imaging device. 
     In an alternate example, the software object may operate through a software abstraction layer, such as an application programming interface (API). The software object developer may only insert code into the software object to call one or more APIs exposed by the software operating the mobile device. One example of such software is Windows Mobile by Microsoft Corporation. In the context of a Windows Mobile device, the Windows Mobile operating system (OS) has one or more APIs exposed to application developers that will translate instructions from applications into instructions operable by the camera  507  on the mobile device  506 . A mobile operating system, also known as a mobile platform or a handheld operating system, is the operating system that controls a mobile device. Other mobiles OSs include Symbian OS, iPhone OS, Palm OS, BlackBerry OS, and Android. 
     The software object may cause the camera  507  to take a picture or capture one or more images of the check  108  being deposited. Each side of the check  108  may be captured by the camera  507  using similar API calls. The images may be stored in an image file  615 . 
     Once the images of one or both sides of the check  108  are captured by the camera  507 , in an implementation, the image file  615  may be operated on by the software object of the client  620 . These operations may include any of the following: deskewing, dewarping, cropping, edge detection, etc., for example. The operation of generating and analyzing a histogram for brightness correction may also be performed by the client  620  and information pertaining thereto may be provided to the server  622 . 
     The image may be also down converted into a grayscale or black and white image, such as either in Joint Photographic Experts Group (JPEG) compliant format or in tabbed image file format (TIFF) for example. In an alternate example, the image may be formatted as a Scalable Vector Graphics (SVG) image. One of the benefits of an SVG file is a large size advantage over JPEG. In the former example, the image at some point before entry into the clearing system may be converted to TIFF format. In an implementation, this may be performed at the mobile device  506 , wherein the camera  507  captures the image in TIFF format. However, the camera  507  of the mobile device  506  may capture the image in JPEG format, which may then be converted into TIFF either at the mobile device  506  or at the server  622 . In the latter example, this may use the transmission of the TIFF image across a communications network which may be more advantageous as TIFF images are typically smaller in file size for the same size of picture as a JPEG formatted image. 
     The software object on the client  620  may operate by performing one or more of the operations described herein and then transmitting an image file  635  (e.g., based on image file  615  that has been processed) to the server  622  after the user  102  confirms that they do wish to deposit the check  108 . Alternately, the software object may capture the image of the check  108  and transmit that image to the server  622  that in turn may perform those operations, verifies that the image quality is within acceptable thresholds, and communicates that verification back to the client  620 , which can then instruct the user  102  to take a picture of the other side of the check  108 . In this example, the image transmitted to the server  622  may be in any format, such as JPEG or TIFF, insofar as the server software has the ability to convert that image into a Check 21 compliant format. Alternately, the bank may output an X9.37 file to the clearing system. The Check Clearing for the 21st Century Act (or Check 21 Act) is a United States federal law that allows the recipient of a paper check to create a digital version, thereby eliminating the need for further handling of the physical document. The Check 21 standard for electronic exchange is defined in the standard DSTU X9.37-2003 (“X9.37”). It is a binary interchange format. 
     The server  622  may confirm (e.g., using a process confirmation  640 ) with the user  102  the transmission, reception, and processing of each side of the check  108  separately, or may confirm both sides at the same time. On the server side, more operations may be performed, such as brightness correction. Where to perform these operations may be determined by the processing power of the mobile device  506  itself, which is typically limited in computational power. However, the present discussion is not limited in any way by discussion of where certain operations are described as operating. The operations of detecting and verifying information may be performed by the client  620  before the information is transmitted along with the image in the image file  635  to the server  622 . Alternately, the software object operating on the mobile device  506  may perform no operation other then capturing images of the front and back of the check  108 , receiving confirmation that the user  102  wishes to proceed, and transmitting those images to the server  622 , wherein the server  622  performs those operations. 
     In an implementation, after the image file  635  has been received by the server  622 , the server  622  may send a process confirmation  640  to the client  620 . The process confirmation  640  may request instructions from the client  620  to continue proceeding with the deposit now that the server  622  has received the image file  635 . In response, the client  620  may send a deposit confirmation  645  to the server  622 , instructing the server  622  to process the deposit of the check based on the image file  635  that had been received by the server  622 . 
       FIG. 7  shows a block diagram of a client apparatus  750  for the deposit of a negotiable instrument, in accordance with an example embodiment. The client apparatus  750  may include one or more software objects operating on the mobile device  506  or other user computing device. The client apparatus  750  may include a communications module  752 , a check processing module  754 , and an image capture module  756 . The client apparatus  750  may receive, in one example, one or more check images  758  as an input and output one or more processed images  760 . 
     In an implementation, the check image(s)  758  may be received following a software call from the check processing module  754  to the image capture module  756 . In such an implementation, the image capture module  756  may include the camera  507  contained within the mobile device  506 . Alternately, the camera  507  may be detachably coupled to the mobile device  506  such as through a secure digital (SD) slot or over any suitable communications bus, such as USB (universal serial bus). In an implementation, the image capture module  756  may retrieve previously captured and stored image files (e.g., in local, remote, or removable storage associated with the client apparatus  750 ) and send the image files to a financial institution (e.g., financial institution  130 , the server  622 , the server apparatus  870  of  FIG. 8 , etc.) for processing. In an implementation, the client apparatus  750  may comprise a browser such as a web browser, for accessing a website on the Internet or other network associated with a financial institution. The user may access the website and select a “capture image” link or similar icon, button or link, for example, displayed on the browser. Such a selection may call the image capture module  756  on the client apparatus  750 . 
     The communications module  752  may be configured, in one example, to receive and send data signals over a suitable communications network. This may include, without limitation, GSM/GPR3, HSDPA, CDMA, TDMA, 802.11, 802.16 and the like. While the bandwidth available to the mobile device  506  may be an implementation concern such discussion is outside the scope of the present discussion and any suitable wireless communications network is considered to be within the scope of the present discussion. With respect to the present discussion, the communications module  752  may receive one or more processed check images  760  from the check processing module  754  and may transmit them over the suitable communications network to the depository  504 . 
     The check processing module  754  may be configured, in one example, to cause the image capture module  756  to capture a digital image of at least one side of a check. The check processing module  754  may then perform one or more processing operations on the image of the check. These processing operations, at a high level, are intended to ensure that the image of the check is suitable for one or more subsequent processing tasks. For instance, if the check is rotated 45 degrees clockwise when captured, the check processing module  754  or a software object operated on the server  622  may be unable to optically detect information on the check. In this example, the check processing module  754  may deskew the image such that the image was no longer rotated. 
     Another aspect of an image that may be processed is a warping of the image. Warping, as used herein, is meant to denote that the check is tilted forward or back with respect to a plane that is perpendicular to a line drawn from the camera lens to the center of the check. Warping, or tilting, of the image may also lead to incorrect optical detection of the check. In an implementation, the check processing module  754  may dewarp the check image such that, in a three-dimensional space, the check would appear to be perpendicular to an imaginary line drawn from the center of the camera lens to the center of the check itself. A warping transformation algorithm (e.g., which may be exposed as a software call) may be used to remove this distortion. 
     The check processing module  754 , in further examples, may perform one or more other cleaning or processing operations. This may include down-converting the image received from the image capture module to a suitable size, such as 200 dots per inch (DPI) resolution or in a resolution range such as 200 DPI to 400 DPI, 300 DPI to 500 DPI, etc., and/or converting the image to grayscale or black and white. Such operation(s) may reduce the file size of the check image. 
     Alternatively, the check processing module  754  may send instructions to the image capture module  756  to cause the image capture module  756  to capture an image of the check at a suitable resolution. The check processing module  754  may additionally perform any of the following operations, in further examples: convert from JPEG to TIFF, detect check information, perform signature detection on the image of the check, and the like. The check processing module  754  may, alternatively, send the captured check image to the server described herein for such processing, and receive confirmation that the operations were completed before further operations can proceed. 
     One of the issues with check processing is to detect the presence of a check against whatever background is present. While a user may be instructed to place the check on a dark or black background, such instructions may not provide a positive user experience. Alternatively or additionally, edge detection may be used to detect the check. Edge detection techniques are well known and any suitable method may be used herein. The check processing module  754  may also perform operations used in brightness correction, such as generating and analyzing a histogram of the image of the check with an overlaid reference mark, further described with respect to  FIG. 10 , for example. 
     While “flat” is a fairly well known term to users, each user&#39;s appreciation of flat with respect to the camera lens of the camera  507  associated with the mobile device  506  may result in a problem with needing to align the check image programmatically or risk rejecting a large number of check images. As the image captured is a set of pixels, a tilted image will result in a jagged polygon rather than a perfect rectangle. Using convex hull algorithms, the check processing module  754  may create a smooth polygon around the boundary and remove the concavity of the check image. Alternatively, a rotating calipers algorithm may be used to determine the tightest fitting rectangle around the check boundary, which can then be used to determine the angle of it, with that angle being used to align the check properly. 
     If user involvement is tolerated, the user may be queried to supply or identify three of the four corners of the check. In such an operation, the fourth corner may be derived, showing the perimeter of the check. This may allow a software object described herein to use less computational resources in processing the image of the check. 
       FIG. 8  shows a block diagram of a server apparatus  870  for the deposit of a negotiable instrument, in accordance with an example embodiment. The server apparatus  870  may include one or more software objects operating on a server operated by the depository  504 . The server apparatus  870  may include a communications module  872 , a check processing module  874 , and a check clearance module  876 . The server apparatus  870  may receive one or more processed images  760  from a mobile device  506  or a client apparatus  750  as an input and may output a file such as a Check 21 compliant file  878 . The Check 21 compliant file  878  may be a file or entry in a record set that is compliant with the clearinghouse rules set forth in the Check 21 Act and may include outputting an X9.37 file, in one example. The communications module  872  may be configured to receive a wireless communication from the mobile device  506  or user computing device  109  over any suitable communications network. 
     The check processing module  874  may be configured, in one example, to perform one or more check processing operations on the processed image(s)  760  that are received. In an implementation, these operations may include any of the operations described herein with respect to the check processing module  754 . The operation of signature verification may be performed by the check processing module  874  of the server apparatus  870  as the server apparatus  870  may interface with other systems of the depository  504  that may maintain previously verified signature samples of the user  102 . Performing signature verification at the client apparatus  750  may be computationally unfeasible; additionally, there may be a security risk if the signature sample is stored on the user&#39;s own device. 
     A cropped grayscale image may be sent to the server apparatus  870 . The server apparatus  870  may perform further processing to remove distortion such as warping. The server apparatus  870  may extract information via a TIFF conversion and determine the DPI and re-scale to the proper DPI (e.g., convert to TIFF and detect the DPI that was used in the grayscale image). In an implementation, DPI detection may run on the client apparatus  750 . The check processing module  874  may perform brightness correction on the processed image(s)  760 , using techniques such as those described with respect to  FIGS. 9 and 10 . 
     The check clearance module  876  may be configured, in one example, to receive a file from the check processing module  874  and may communicate with a check clearinghouse such that a Check 21 compliant file  878  may be delivered to the check clearinghouse, such as the clearinghouse  510 , and funds may be received by the depository  504 . The availability of the funds to the user  102  may be delayed by this operation such that the user  102  only has access to those funds when the depository  504  receives confirmation that the check has cleared. 
       FIG. 9  is an operational flow of an implementation of a method  900  that may be used for deposit of a negotiable instrument. At  905 , a user (e.g., an account owner, payee, etc.) may receive a check from a third party (i.e., a payor). The user may endorse the check by signing the back of the check in the designated field. If the user wishes to deposit the check into an account, such as a savings and/or checking account, they also may write an account number below the signature. The user may convert the check into an image file that comprises electronic data representing an image of the check. For example, the user may create an image file comprising an image of the first side of the check, the second side of the check, or both. In an implementation, the image file may be created using a digital camera or a scanner. The digital camera or scanner may be comprised within a mobile device or other user computing device or may be separate and detachably connectable therefrom. 
     At  910 , the user may transmit the image file to a financial institution, such as a bank, that may be associated with an account for depositing funds. For example, the user may send the image file of the check to the financial institution by attaching the image file to an email. Alternatively, the image file may be sent using various means, including, but not limited to, an Internet connection via a website of the financial institution or a wireless cellular transmission. In an implementation, the image file may be sent to the financial institution via streaming. 
     Additionally, the image file may be augmented by secondary data, which may be information relating to the check, such as an account number, a deposit amount, or a routing number associated with the check, and/or relating to the account for depositing funds, such as the account number and/or the name on the account. The account number may appear on the check itself, below the signature endorsing the check. The account number and/or name on the account also may appear in an email, either with or without the image file, for example. The user may send the image file and the secondary data to the financial institution, using any technique, along with a request to deposit the check into a particular user account. The financial institution may receive the image file pertaining to the check along with financial information pertaining to the account for depositing funds and any secondary data. 
     At  915 , the financial institution may convert the image into grayscale, process the image with operations such as dewarping, deskewing, edge detection, and cropping, for example, and save a copy of the processed image in storage. The processed image may be further processed for brightness correction. At  920 , a reference mark, such as a cross described with respect to  FIG. 3 , may be overlaid on the processed image, e.g., using an image processor or computing device of the institution system. A histogram from the processed image with the reference mark may be obtained at  925 . A threshold point, described above with respect to  FIG. 3 , may be determined for the histogram. 
     At  930 , the copy of the processed image may be retrieved from storage and brightness correction may be performed on it. The threshold point determined at  925  may be compared with a predetermined constant value. If the threshold point is greater than the predetermined constant value, then the intensity of the image (the copy of the processed image) may remain unchanged in an implementation (e.g., no intensity or brightness is added to each pixel in the image). If the threshold point is less than or equal to the predetermined constant value, then the brightness of the image may be corrected by adding a constant amount of brightness (or intensity) to each pixel in the image (the copy of the processed image without the overlaid reference mark). Brightness correction may be used for an image of a dark check on a dark background. In an implementation, a first amount of intensity or brightness may be added to each pixel if the threshold point is greater than the predetermined constant value, and a second amount (greater than the first amount) of intensity or brightness may be added to each pixel if the threshold point is less than or equal to the predetermined constant value. The amount(s) of intensity or brightness to be added may be based on the threshold point, in an implementation. 
     At  935 , the financial institution may parse financial information from the processed and brightness corrected (if any brightness correction has been applied) image of the check. Any known technology may be used to retrieve financial information from the image. Example technologies that may be used by the financial institution may include image editing, filtering to remove imagery except the check in the received image, image sharpening, and technologies to distinguish between the front and the back sides of the check. 
     After retrieving the financial information from the check in an electronic data representation form, the financial institution may determine whether the financial information such as the amount payable to the user, the account associated with the user to deposit funds, an account associated with a payor to debit funds, and a financial institution associated with the payor and/or the user may be valid at  940 . 
     At  990 , if the financial information is determined to be valid, the electronic data representation may be processed by the financial institution, thereby depositing the check in the user&#39;s account. If the financial information is determined to be invalid, then the user may be advised at  945 . For example, the financial institution may transmit an email, a web message, an instant message, or the like to the user indicating that the financial information associated with the electronic data representation may be invalid. The user may determine how to proceed by selecting an option on the web message, replying to the email, or the like. 
     Thus, in an implementation, instructions on how the user would like to proceed may be requested from the user, such as whether the user would like to try the image deposit again (e.g., make another image file using the camera and send it to the financial institution) or whether the user would like assistance from a representative, for example. The user may indicate how they would like to proceed. 
     If the user would like assistance, the financial information may be transferred to a representative for further review at  950 . The representative, such as a customer service representative, a bank teller who may be located at a branch, a virtual bank teller who may be located remotely via an electronic device, or the like, may review the financial information associated with the electronic data representation to determine whether to allow the electronic data representation to be processed by the financial institution. For example, the initial analysis may require a certain quality requirement, a certain readability requirement, or the like, thus, leading to a high failure rate even though the electronic data representation may otherwise be valid. Thus, the representative may review the electronic data representation to determine whether the financial information may be readable and/or of a good enough quality to be processed. If so, the electronic data representation of the financial information may be processed by the financial institution at  990 , thereby depositing the check in the user&#39;s account. 
     The user may receive a notice via email, facsimile, instant message, or mail, for example, that the check has been deposited into the selected account. In an implementation, if the check is not successfully deposited by image deposit, the financial institution may provide additional options to the user on how to redeem the check, such as mailing the check to the financial institution or the like. 
     To credit funds to the account, the bank may generate an Automated Clearinghouse (ACH) debit entry, substitute check, and/or electronic image. ACH transactions typically include payment instructions to debit and/or credit an account. Banks often employ ACH service providers to settle ACH transactions. Examples of ACH service providers include regional branches of the Federal Reserve and the Electronic Payments Network (EPN). The ACH service provider may process the debit entry by identifying the account and bank from which the check may be drawn. If the payor&#39;s bank verifies the transaction, the ACH service provider may settle the transaction by debiting the payor&#39;s bank and crediting the user&#39;s bank. The payor&#39;s bank may then debit the payor&#39;s account. 
       FIG. 10  is an operational flow of another implementation of a method  1000  that may be used for deposit of a negotiable instrument. At  1010 , a user may receive a check from a payor and may endorse the check. 
     At  1020 , the user may open a communication pathway with an institution that may be associated with an account for depositing funds by logging into a website of the institution, for example. There may be several ways in which a communication pathway may be established, including, but not limited to, an Internet connection via a website of the institution. The user may access the website and log into the website using credentials, such as, but not limited to, a username and a password. The user may send a request to deposit the check and may select an account in which to deposit the check. In an implementation, the user may select a “deposit check” option provided on the website, and may enter details such as check amount, date, the account the check funds should be deposited in, comments, etc. 
     At  1030 , a digital image of the check may be created using any of the techniques described herein. In an implementation, the user may use a template (e.g., provided by the institution) to arrange the check for scanning. In this manner, the image may comprise the check image in a predetermined position or arrangement that may be easier for the user computing device and/or the institution to identify and/or process. Alternatively, the user may insert the check into a holder (e.g., provided by the institution). The check may be inserted in the holder in a predetermined position or manner. For example, the check or features of the check such as one or more corners of the check, the signature line, the MICR line, etc., may be aligned with respect to one or more marks or indicators on the holder. It is contemplated that different holders may be used for the front side of the check and for the back side of the check. The positioning or alignment may allow for more efficient processing of the check by the user computing device and/or the institution. 
     At  1040 , using the user computing device, the image may be converted into grayscale using any known technique and the grayscale image may be processed with operations such as dewarping, deskewing, edge detection, and cropping, for example. A copy of the processed image may be saved in storage associated with the user computing device. 
     At  1050 , the user computing device may overlay a reference mark, such as a cross, on the processed image, and a histogram may be obtained of the processed image with the reference mark at  1060 . The user computing device may have a histogram generator module and/or application that may overlay the reference mark and generate a histogram. A threshold point may be determined for the histogram. In an implementation, the user computing device may determine whether the histogram is invalid or cannot be used to determine a threshold point, and if so, the user may be advised and instructed to capture another image (e.g., take another picture) of the check with processing continuing at  1030 . 
     At  1070 , the copy of the processed image may be retrieved from storage and transmitted to the financial institution (e.g., sent as a digital image file to an institution system). Information pertaining to the threshold point from the histogram may also be sent from the user computing device to the financial institution. At  1080 , the financial institution may receive the copy of the processed image and perform brightness correction on the processed image. Brightness correction (e.g., an amount of intensity, if any, to add to each of the pixels of the image) may be determined based on a comparison of the threshold point and a predetermined constant value, as described with respect to  930 , for example. Processing of the image for deposit of the check may continue at  935 , in an implementation. 
       FIG. 11  is a block diagram of 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, 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 above 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. 11 , a system  1100  includes a computer  1110  connected to a network  1114 . The computer  1110  includes a processor  1120 , a storage device  1122 , an output device  1124 , an input device  1126 , and a network interface device  1128 , all connected via a bus  1130 . The processor  1120  represents a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor  1120  executes instructions and includes that portion of the computer  1110  that controls the operation of the entire computer. Although not depicted in  FIG. 11 , the processor  1120  typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the computer  1110 . The processor  1120  receives input data from the input device  1126  and the network  1114  reads and stores code and data in the storage device  1122  and presents data to the output device  1124 . Although the computer  1110  is shown to contain only a single processor  1120  and a single bus  1130 , the disclosed embodiment applies equally to computers that may have multiple processors and to computers that may have multiple busses with some or all performing different functions in different ways. 
     The storage device  1122  represents one or more mechanisms for storing data. For example, the storage device  1122  may include read-only memory (ROM), RAM, magnetic disk storage media, optical storage media, flash memory devices, and/or other machine-readable media. In other embodiments, any appropriate type of storage device may be used. Although only one storage device  1122  is shown, multiple storage devices and multiple types of storage devices may be present. Further, although the computer  1110  is drawn to contain the storage device  1122 , it may be distributed across other computers, for example on a server. 
     The storage device  1122  includes a controller (not shown in  FIG. 11 ) and data items  1134 . The controller includes instructions capable of being executed on the processor  1120  to carry out the functions as previously described herein. In another embodiment, some or all of the functions are carried out via hardware in lieu of a processor-based system. In one embodiment, the controller is a web browser, but in other embodiments the controller may be a database system, a file system, an electronic mail system, a media manager, an image manager, or may include any other functions capable of accessing data items. The storage device  1122  may also contain additional software and data (not shown), which is not necessary to understand the invention. Although the controller and the data items  1134  are shown to be within the storage device  1122  in the computer  1110 , some or all of them may be distributed across other systems, for example on a server and accessed via the network  1114 . 
     The output device  1124  is that part of the computer  1110  that displays output to the user. The output device  1124  may be a liquid crystal display (LCD) well-known in the art of computer hardware. In other embodiments, the output device  1124  may be replaced with a gas or plasma-based flat-panel display or a traditional cathode-ray tube (CRT) display. In still other embodiments, any appropriate display device may be used. Although only one output device  1124  is shown, in other embodiments any number of output devices of different types, or of the same type, may be present. In an embodiment, the output device  1124  displays a user interface. The input device  1126  may be a keyboard, mouse or other pointing device, trackball, touchpad, touch screen, keypad, microphone, voice recognition device, or any other appropriate mechanism for the user to input data to the computer  1110  and manipulate the user interface previously discussed. Although only one input device  1126  is shown, in another embodiment any number and type of input devices may be present. 
     The network interface device  1128  provides connectivity from the computer  1110  to the network  1114  through any suitable communications protocol. The network interface device  1128  sends and receives data items from the network  1114 . The bus  1130  may represent one or more busses, e.g., USB, PCI, ISA (Industry Standard Architecture), X-Bus, EISA (Extended Industry Standard Architecture), or any other appropriate bus and/or bridge (also called a bus controller). 
     The computer  1110  may be implemented using any suitable hardware and/or software, such as a personal computer or other electronic computing device. Portable computers, laptop or notebook computers, PDAs, pocket computers, appliances, telephones, and mainframe computers are examples of other possible configurations of the computer  1110 . For example, other peripheral devices such as audio adapters or chip programming devices, such as EPROM (Erasable Programmable Read-Only Memory) programming devices may be used in addition to, or in place of, the hardware already depicted. 
     The network  1114  may be any suitable network and may support any appropriate protocol suitable for communication to the computer  1110 . In an embodiment, the network  1114  may support wireless communications. In another embodiment, the network  1114  may support hard-wired communications, such as a telephone line or cable. In another embodiment, the network  1114  may support the Ethernet IEEE (Institute of Electrical and Electronics Engineers) 802.3x specification. In another embodiment, the network  1114  may be the Internet and may support IP (Internet Protocol). In another embodiment, the network  1114  may be a LAN or a WAN. In another embodiment, the network  1114  may be a hotspot service provider network. In another embodiment, the network  1114  may be an intranet. In another embodiment, the network  1114  may be a GPRS (General Packet Radio Service) network. In another embodiment, the network  1114  may be any appropriate cellular data network or cell-based radio network technology. In another embodiment, the network  1114  may be an IEEE 802.11 wireless network. In still another embodiment, the network  1114  may be any suitable network or combination of networks. Although one network  1114  is shown, in other embodiments any number of networks (of the same or different types) may be present. 
     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 use 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 may be 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 it may be combined with hardware implementations. 
     Although exemplary embodiments may refer to using 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 above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.