Patent Application
20070136198
The present invention relates to check image processing, and in particular to a method for facilitating the tracing and/or auditing of operations performed during the processing of check images.
Traditionally, businesses have deposited checks received from, for example, customers by physically taking them to a branch of their bank and depositing them over the counter with a teller or dropping them into a night deposit box. The actual physical presentation of checks to be deposited was necessary because, under prior banking laws, the depository bank had to present the original of each check to the corresponding paying bank in order to clear the check. This changed in October of 2004 with the enactment of The Check Clearing for the 21st Century Act, commonly referred to Check 21. Check 21 removed the legal requirement that an original paper check had to be presented to obtain payment. Instead, banks can now use digital images to transport check data from the bank of first deposit to the paying bank. If the paying bank cannot process a check image, the image can be printed, according to certain specifications, to create what is known as a substitute check, which is the legal equivalent of the original paper check. Check 21 has thus opened the door for remote check deposit solutions wherein check images, rather than original paper checks, are used to make deposits, thereby enabling businesses to eliminate trips to the bank. In addition, the use of check images also reduces check transportation costs among banks and improves funds availability.
As will be appreciated, a number of operations are performed on a check image as it moves through the check processing/clearing system from the time it is first created and transmitted for deposit to the time it reaches the bank on which it is drawn. It is desirable for the various parties involved in processing/clearing the check to be able to audit the movement of the check image through the system and, in particular, to be able to identify what person and/or process performed an operation such as scanning the check to create the check image or performing optical character recognition on the check image to obtain data therefrom such as the amount of the check. Thus, there is a need for a method or methods for facilitating the tracing and/or auditing of operations performed during the processing/clearing of check images.
The present invention relates to a method of processing a check using a check processing device prior to, for example, electronically depositing the check. The method includes receiving authentication information, such as a PIN, token or biometric information, from an operator of the device, receiving amount information indicating an amount of the check from the operator, and creating a check image file that includes an electronic image of the check. The method further includes adding at least the authentication information, the amount information, and, optionally operator identifying information, to the check image file as embedded data to create a new check image file, and creating a signed check image file that includes the new check image file and a digital signature of the new check image file created using a private key, such as a private key specific to the operator or the device. The method may then further include transmitting the signed check image file to an upstream processor, such as a bank of first deposit.
The method may also further include creating a signed deposit file that includes a deposit file and a digital signature thereof, wherein the digital signature of the deposit file is created using the same private key. The deposit file includes the signed check image file for the check and one or more additional signed check image files for one or more additional checks.
In an alternative embodiment, the present invention relates to a method of processing a plurality of checks using a check processing device prior to, for example, electronically depositing the checks. The method includes receiving authentication information from an operator of the device and creating a signed amount file, wherein the signed amount file includes an amount file and a digital signature thereof created using a private key, such as a private key specific to the operator or the device, and wherein the amount file includes amount information for each of the checks received from the operator. Next, a check image file is created for each of the checks that includes an electronic image of the check. At least the authentication information is then added to each of the check image files as embedded data to create a respective new check image file for each of the checks. The method then further includes creating a signed check image file for each new check image file, wherein each signed check image file includes the new check image file and a digital signature thereof created using a private key. Finally, the method includes creating a signed deposit file that includes the signed amount file, each of the signed check files and a digital signature of the signed amount file and each of the signed check files that is created using the private key.
The invention also relates to a method of processing a check at an upstream location, preferably after it has been processed by one of the above methods. For example, the upstream location may be a bank of first deposit. The method includes receiving a check image file that includes an electronic image of the check and amount information indicating an amount of the check, and performing OCR on the electronic image using an OCR process to obtain an OCR amount for the check, wherein the OCR amount has a confidence score assigned by the OCR process. If the confidence score exceeds a predetermined threshold level or if the OCR amount matches the amount information, the method further includes (i) adding the OCR amount to the check image file as embedded data to create a first new check image file, and (ii) creating a first new signed check image file that includes the first new check image file and a digital signature of the first new check image file created using a private key specific to the OCR process. If, however, the confidence score does not exceed the predetermined threshold level and if the OCR amount does not match the amount information, the method further includes (i) adding second amount information that is read by an operator to the check image file as embedded data to create a second new check image file, and (ii) creating a second new signed check image file that includes the second new check image file and a digital signature of the second new check image file created using a private key specific to the operator.
In an alternative embodiment, the invention relates to a method of processing a check at an upstream location that includes receiving a deposit file that includes an amount file and a plurality of check image files preferably created as described in one embodiment above. The amount file includes a plurality of amounts corresponding to a plurality of checks being deposited, wherein the check is one of the plurality of checks. The check image files include a check image file for the check that includes an electronic image of the check. The method further includes performing OCR on the electronic image using an OCR process to obtain an OCR amount for the check that has a confidence score assigned thereto. If the confidence score exceeds a predetermined threshold level, the method includes (i) adding the OCR amount to the check image file as embedded data to create a first new check image file, and (ii) creating a first new signed check image file that includes the first new check image file and a digital signature thereof created using a private key specific to the OCR process. If the confidence score does not exceed the predetermined threshold level but a second OCR amount having a second confidence score exceeding the predetermined threshold level can be obtained by re-performing OCR on the electronic image using the OCR process and one of the amounts as a hint, the method includes (i) adding the second OCR amount to the check image file as embedded data to create a second new check image file, and (ii) creating a second new signed check image file that includes the second new check image file and a digital signature thereof created using the private key specific to the OCR process. If, however, the confidence score does not exceed the predetermined threshold level and if a second OCR amount having a second confidence score exceeding the predetermined threshold level cannot be obtained, then the method includes (i) adding second amount information read by an operator to the check image file as embedded data to create a third new check image file, and (ii) creating a third new signed check image file that includes the third new check image file and a digital signature thereof created using a private key specific to the operator.
Finally, the invention relates to a method of processing a check at an upstream location, preferably after the check was previously processed by another upstream processor such as a bank of first deposit. The method includes receiving a check image file that includes an electronic image of the check and amount data indicating an amount of the check, and determining whether the amount data is to be trusted using information associated with the check image file and one or more pre-defined rules. If it is determined that the amount data is to be trusted, the method includes using the amount data to process the check. If, however, it is determined that the amount data is not to be trusted, the method includes performing OCR on the electronic image to obtain an OCR amount and using the OCR amount to process the check. The amount data may have been generated by an OCR process or an operator, in which cases the information associated with the check image file relates to an identity of the OCR process or the operator, as appropriate. In addition, the check image file may be part of a signed check image file including a digital signature created using a private key of the OCR process or the operator, as appropriate. In this case, the information associated with the check image file that is used to determine whether the amount data is to be trusted may include the public key that corresponds to the private key.
Therefore, it should now be apparent that the invention substantially achieves all the above aspects and advantages. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
The accompanying drawings illustrate presently preferred embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the principles of the invention. As shown throughout the drawings, like reference numerals designate like or corresponding parts.
The method begins at step 5, where an operator of a the scanning device at a first location, such as a location of a party depositing one or more checks, provides authentication information unique to that operator to the scanning device, such as through a keyboard or other input device, and obtains the first check to be processed. The authentication information is any type of information that may be used to uniquely identify the device operator, such as, without limitation, a personal identification number (PIN), a token or biometric information such as a fingerprint or retinal scan. Next, at step 10, the operator inputs information indicating the amount for the current check into the scanning device, which in this case is the first check to be processed. At step 15, the current check is scanned using the digital scanner to create a check image file (as used herein, the term “file” shall refer to a collection of data, such as may form an electronic image) in any one of a number of different known electronic image formats. Then, at step 20, the amount information that was input by the operator, the authentication information that was input by the operator, and, optionally, information identifying the scanning device, such as the serial number thereof, is added to the check image file as embedded data by the scanning device. As another option, MICR line information read by the scanning device may be added to the check image file as embedded data. Such embedded data may include, for example, data tags that are added to an image file such as a JPEG file. As will be appreciated, such embedded data does not get displayed as part of the image, but instead is data that becomes linked with the image and that may be later obtained therefrom.
Next, at step 25, a message digest of the check image file, including the embedded data, which was created in step 20 is created. The message digest may be any type of known digest or hash, such as an MD5 digest. At step 30, a signed check image file is then created. In particular, the signed check image file is created by signing (encrypting) the message digest with an operator specific private key to create a digital signature and combining the check image file with the digital signature in a data file. The data file may also include a public key certificate having the public key that corresponds to the specific private key issued by a public key infrastructure or another key certification authority. Preferably, each operator of the scanning device has his or her own private key that is stored in a vault or the like and released as a result of the provision of the authentication information in step 5. The private keys may be stored on the scanning device itself in secure memory, or, preferably, they may be stored remotely from the scanning device, in which case the private keys are maintained by a key management system and are provided to the scanning device as needed. Alternatively, the private key used in step 30 could be a private key assigned to the particular scanning device being used.
At step 35, a determination is made as to whether there are more checks that need to be processed. If the answer is yes, then at step 40, the next check is obtained and the method returns to step 10 and the check is processed as described above. If, however, the answer at step 35 is no, meaning that all of the checks to be processed have indeed been processed, then the method proceeds to step 45. In step 45, a signed deposit file is created by (i) creating a message digest, such as an MD5 digest, of a file that contains the signed check image file for each of the checks, (ii) signing (encrypting) the message digest with the operator specific private key to create a digital signature, and (iii) combining the file that includes each of the signed check image files with the digital signature in a data file (which may also include the public key certificate). Then, at step 50, the signed deposit file is electronically transmitted to an upstream processor, such as, for example, a bank of first deposit, over a public and/or private communication network or networks.
At step 75, a message digest of the check image file, including the embedded data, is then created. At step 80, the message digest created in step 75 is signed (encrypted) using an operator specific private key to create a digital signature, and a signed check image file is created by combining the check image file, including the embedded data, with the digital signature (the file may also include the public key certificate). As was the case in step 30 of
As alternative, the process in
At step 110, the first check to be processed is obtained. At step 115, the current check, in this case the first check, is scanned to create a check image file. Next, at step 120, the authentication information that was input and, optionally, information identifying the scanning device is added to the check image file as embedded data. Then, at step 125, a signed check image file is created by creating a message digest of the check image file, including the embedded data, signing the message digest with the operator specific private key (or alternatively a scanning device private key) to create a digital signature, and combining the check image file, including the embedded data, and the digital signature in a data file (which may also include the public key certificate). At step 130, a determination is made as to whether there are additional checks to be processed. If the answer is yes, then, at step 135, the next check is obtained and the method proceeds to step 115 for further processing of the check as described above. If the answer is no at step 130, meaning all of the checks in the batch have been processed, then the method proceeds to step 140.
At step 140, a signed deposit file is created by (i) creating a message digest of a data file consisting of the signed amount file and each signed check image file, (ii) signing the message digest with the operator specific private key (or a scanning device private key) to create a digital signature, and (iii) combining the singed amount file, each signed check image file and the digital signature in a data file. Then, at step 145, the signed deposit file is transmitted to an upstream processor, such as, for example, a bank of first deposit.
The method begins at step 150, if appropriate, wherein the signed deposit file is received by the upstream processor, e.g., the bank of first deposit. At step 155, a determination is made as to whether the signed deposit file can be authenticated. As is known, this authentication is performed by (i) obtaining the public key that corresponds to the private key used in the method of
If the answer is yes at step 155, meaning that the signed deposit file can be authenticated, then, at step 165, then the first signed check image file is obtained from the signed deposit file. Also, if checks in question have been processed according the method of
If, the answer at step 170 is yes, meaning that the current signed check image file can be authenticated, then the method proceeds to step 190, where the input amount information is extracted from the check image file (this is the amount information that was previously input by the operator of the scanning device). Next, at step 195, optical character recognition (OCR) is performed on the check in the check image file to obtain the amount of the check therefrom. A particular type of software, commonly referred to as courtesy amount recognition (CAR) software and legal amount recognition (LAR) software (CAR/LAR software), is able to obtain from each check image the courtesy amount (which is the numerical dollar amount written on the check) and the legal amount (which is the dollar amount of the check written out in words). CAR/LAR software is well known in the art, and is commercially available from a number of different vendors such as Wausau Financial Systems and A2iA Corp.
As is known, most CAR/LAR software provides a confidence score each time it performs a read operation which indicates a relative confidence, typically expressed as a percentage, in the accuracy of the dollar amount obtained from a check image as a result of the read. Thus, at step 200, a determination is made as to whether the OCR score is below a predetermined threshold value. If the answer at step 200 is no, meaning that the OCR score is sufficiently high, then, at step 205, the OCR output is added to the check image file as additional embedded data (i.e., in addition to the data that was embedded in the method of
If, however, the answer at step 200 is yes, meaning that the score was not high enough, then, at step 210, a determination is made as to whether the OCR output matches the input amount that was extracted at step 190. If the answer is yes, then the method proceeds to step 205, wherein the OCR output is added to the check image file as additional embedded data. Again, the name, version number and/or manufacturer of the OCR software may also be added to the check image file as additional embedded data. Following step 205, the method proceeds to
Referring to
Referring to
If, however, the answer at step 285 is yes, meaning that both the signed deposit file and the signed amount file have been authenticated, then, at step 290, the first signed check image file is obtained from the signed deposit file. At step 295, a determination is made as to whether the signed check image file can be authenticated using the digital signature thereof and the appropriate public key as described elsewhere herein. If the answer at step 295 is no, then, at step 300 the upstream processor starts a fraud discovery or investigation process for the check shown in the current check image file. Then, at step 305, a determination is made as to whether there are more checks in the signed deposit file left to be processed. If the answer is no, the method ends. If, however, the answer is yes at step 305, then, in step 310, the next signed check image file is obtained from the singed deposit file and the method returns to step 295 for further processing as described herein.
If the answer at step 295 is yes, meaning that the signed check image file in question can be authenticated, then, at step 315, optical character recognition (OCR) preferably using CAR/LAR software is performed on the check in the check image file. At step 320, a determination is made as to whether the OCR score is lower than a predetermined threshold. If the answer at step 320 is no, then, at step 325, the OCR output is added to the check image file as additional embedded data. The name, version number and/or manufacturer of the OCR software may also be added to the check image file as additional embedded data. If, however, the answer at step 320 is yes, meaning that the OCR score was low, then, at step 330, a determination is made as to whether or not the OCR score can be improved to a level above the predetermined threshold using any one of the amounts contained in the amount file as a hint. Preferably, step 330 is performed as described in co-pending application Ser. No. 11/252,044, filed on Oct. 17, 2005 and entitled “Method for Remote Check Capture,” assigned to the Assignee hereof, the disclosure of which is hereby incorporated by reference. If the answer at step 330 is yes, meaning that the OCR score has been improved such that it exceeds the predetermined threshold value, then the method proceeds to step 325, wherein the OCR output is added to the check image file as additional embedded data. Again, the name, version number and/or manufacturer of the OCR software may also be added to the check image file as additional embedded data. If, however, the answer at step 330 is no, meaning that none of the amounts contained in the amount file was able to cause the OCR score to be improved above the predetermined threshold level, then, at step 335, wherein an operator visually reads an amount from the check image. Then, at step 340, the operator read amount and, optionally, operator identifying information is added to the check image file as additional embedded data.
Referring to
Referring to
The method begins at step 385, wherein the signed check image file to be processed is received by the upstream processor. Next, at step 390, a determination is made as to whether the signed check image file can be authenticated using the digital signature contained therein and the appropriate corresponding public key as described elsewhere herein. If the answer at step 390 is no, then, at step 395, the upstream processor begins a fraud discovery or investigation process for the check in the signed check image file. If, however, the answer at step 390 is yes, then, at step 400, a determination is made as to whether the amount data contained in the signed check image file can be trusted. Preferably, the determination at step 400 is based upon a set of one or more business rules established by the particular upstream processor. In essence, these business rules are established to determine whether or not a new OCR should be performed on the check image at this stage based upon whether, as established by this particular upstream processor, the OCR or other operator input that was performed with respect to the signed check image file by a downstream processor should be trusted. In other words, at step 400, this upstream processor is, on a signed check image file by signed check image file basis, making an educated choice as to whether to again OCR the check image in question. This is beneficial because, as will be appreciated by those of skill in the art, OCR processing is expensive and time and resource consuming. The determination made in step 400 may be based on a number of different factors such as, without limitation, the identity of the downstream processor, i.e., bank, that provided the signed check image file, the identity of the operator that input information relating to the signed check image file, and/or the identity of the software package and/or version thereof that was used in a downstream process to perform OCR on the check image and thereby add data to the signed check image file. The particular information used to make this decision in each case is, as described elsewhere herein, may be provided as part of the embedded data included in the check image file, or alternatively, as data included with the check image file. In one particular embodiment, the determination made in step 400 may be based on the public key that is used to authenticate the signed check image file (obtained form the public key certificate included therewith or obtained from a certificate authority), in which case it is determined wither the public key is specific to a trusted operator or OCR process (a databases may be maintained for this purpose).
If the answer at step 400 is yes, meaning that the amount data in the signed check image file can be trusted according to the predetermined business rule or rules, then, at step 405, the amount data from the signed check image file is used for processing the check by the upstream processor. If, however, the answer at step 400 is no, meaning that it has been determined that the amount data cannot be trusted for the signed check image file, then, at step 410, OCR is performed by the upstream processor on the check in the check image file. Next, at step 415, a determination is made at step 415 as to whether the OCR score is below a predetermined threshold level. If the answer at step 415 is no, then, at step 420, the OCR amount is added to the check image file as additional embedded data and a new signed check image file is created by generating a message digest of the check image file (including the additional embedded data), signing the message digest with a private key of the upstream processor (in particular of the OCR process used by the upstream processor) to create a digital signature, and combining the check image file and the digital signature. The name, version number and/or manufacturer of the OCR software may also be added to the check image file as additional embedded data. Then, at step 425, the OCR amount generated in step 410 is used for processing the check by the upstream processor.
If, however, the answer at step 415 is yes, then, at step 430, a determination is made as to whether the OCR output matches the amount data contained in the new signed check image file (i.e., the OCR or operator input amount provided in the downstream process, whichever the case may be). If the answer at step 430 is yes, then the method returns to step 420. If, however, the answer at step 430 is no, then, at step 435, an operator visually reads the amount from the check image in the signed check image file. Then, at step 440, the operator read amount is added to the check image file as additional embedded data and a new signed check image file is created in the manner described in connection with step 420 (except, preferably, a private key of the operator is used). Then, at step 445, the operator read amount is used for processing the check by the upstream processor. It should be noted that the concept shown in
While preferred embodiments of the invention have been described and illustrated above, it should be understood that these are exemplary of the invention and are not to be considered as limiting. Additions, deletions, substitutions, and other modifications can be made without departing from the spirit or scope of the present invention. Accordingly, the invention is not to be considered as limited by the foregoing description but is only limited by the scope of the appended claims.
