DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 6/4/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 8 and 9, filed 3/3/2026, with respect to the rejection(s) of claim(s) 1-20 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Ethington. The reference of Ethington is an IDS reference filed on 6/4/2026. The Ethington reference discloses using a browser API to send a front image of a check to a server. After the front image information is approved, the back image is requested at the computer or phone that contains the web browser or software. The user goes through a similar scan process on the back side of the check in order to send through the browser API or, some other API controlling communication, the back side image to the server. This is taught below in col. 86, ll. 55-58 (421) and col. 91, ll. 10-34 (437) and col. 6, ll. 53-col. 7, ll. 58, col. 8, ll. 29-37 (34)-(39) and (42). Therefore, based on this reference performing the transfer of information through an API to another server, this performs the features of the claims regarding the API requests of the front side and back side of the document.
Thus, based on the above, the features of the claims are disclosed below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolchin (US Pub 2023/0052197) in view of Tidwell (US Pub 2005/0125351), Joseph (US Pub 2024/0193556), Heit (US Pub 2015/0142645) and Ethington (USP 11295377).
Re claim 1: Kolchin ‘197 discloses a computer implemented method for providing exception handling during a document upload process of a document, the method comprising:
receiving, from an upload application on a user device, a front image of the document to be uploaded to a user account (e.g. the user sends a request for deposit of a check. The user mobile device is used to perform the capturing of the check, which is taught in ¶ [68], [79]. A server can be used in the processing and OCR of the received images, which is taught in ¶ [46] and [47]. The front and the back of the check can be sent to the server for processing, which is taught in ¶ [120], [121] and [185].);
[0046] The systems may be deployed in a number of ways, including on a stand-alone computing device, a set of computing devices working together in a network, or a web application. Persons of ordinary skill in the art will recognize a web application as a particular kind of computer program system designed to function across a network, such as the Internet. A schematic illustration of a web application platform is provided in FIG. 5. Web application platforms typically include at least one client device 120, which is a computing device as described above. The client device 120 connects via some form of network connection to a network 121, such as the Internet. The network 121 may be any arrangement that links together computing devices 120, 122, and includes without limitation local and international wired networks including telephone, cable, and fiber-optic networks, wireless networks that exchange information using signals of electromagnetic radiation, including cellular communication and data networks, and any combination of those wired and wireless networks. Also connected to the network 121 is at least one server 122, which is also a computing device as described above, or a set of computing devices that communicate with each other and work in concert by local or network connections. Of course, practitioners of ordinary skill in the relevant art will recognize that a web application can, and typically does, run on several servers 122 and a vast and continuously changing population of client devices 120. Computer programs on both the client device 120 and the server 122 configure both devices to perform the functions required of the web application 123. Web applications 123 can be designed so that the bulk of their processing tasks are accomplished by the server 122, as configured to perform those tasks by its web application program, or alternatively by the client device 120. Some web applications 123 are designed so that the client device 120 solely displays content that is sent to it by the server 122, and the server 122 performs all of the processing, business logic, and data storage tasks. Such “thin client” web applications are sometimes referred to as “cloud” applications, because essentially all computing tasks are performed by a set of servers 122 and data centers visible to the client only as a single opaque entity, often represented on diagrams as a cloud.
[0047] Many computing devices, as defined herein, come equipped with a specialized program, known as a web browser, which enables them to act as a client device 120 at least for the purposes of receiving and displaying data output by the server 122 without any additional programming. Web browsers can also act as a platform to run so much of a web application as is being performed by the client device 120, and it is a common practice to write the portion of a web application calculated to run on the client device 120 to be operated entirely by a web browser. Such browser-executed programs are referred to herein as “client-side programs,” and frequently are loaded onto the browser from the server 122 at the same time as the other content the server 122 sends to the browser. However, it is also possible to write programs that do not run on web browsers but still cause a computing device to operate as a web application client 120. Thus, as a general matter, web applications 123 require some computer program configuration of both the client device (or devices) 120 and the server 122. The computer program that comprises the web application component on either computing device's system FIG. 4 configures that device's processor 200 to perform the portion of the overall web application's functions that the programmer chooses to assign to that device. Persons of ordinary skill in the art will appreciate that the programming tasks assigned to one device may overlap with those assigned to another, in the interests of robustness, flexibility, or performance. Furthermore, although the best known example of a web application as used herein uses the kind of hypertext markup language protocol popularized by the World Wide Web, practitioners of ordinary skill in the art will be aware of other network communication protocols, such as File Transfer Protocol, that also support web applications as defined herein.
[0068] The system of the present disclosure is also configured to generate a secured mobile check as part of a good check assurance practice in conjunction with the mobile remote deposit capture (mRDC) process. The system is configured to allow a merchant, when the merchant needs to accept a check from a client, to perform the following steps. The merchant can a. immediately deposit the check using a camera of the mobile device (by scanning front and back of a check), b. run that check and associated client's information through bad check database (run the name of the client or account and routing number through database to check against the transaction history and see if there were any red flags associated with bounced checks, or any other delinquencies by the client/consumer); wherein c. the client, in turn, can provide guarantee of a good check using any of the following methods (“QR pledge”): credit card, crypto tokens, any other asset classes (promissory notes, brokerage account, HELOT, or other suitable financial instruments), thereby allowing the merchant to tap into QR pledge assets of the client in case the client's check is bounced.
[0079] Modern banks still process paper checks, which are usually transmitted as images, once scanned via the mobile remote deposit capture (mRDC). The system of the present invention allows a user to scan images of both sides of a check using a mobile computing device such as a smart phone or the like (just like a typical modern banking), however, the system of the present disclosure provides the ability to access mobile check deposits to any sub-account, unlike with a typical modern banking system wherein the access is granted for only the main account holder.
[0120] The system of the present invention also provides for depositing the front of the check only (not the backside of the check) for mobile deposit mRDC transactions. Most of the modern checks have the same back of the check and most banks usually do not even require checks to be endorsed. The system of the present disclosure is configured to detect a typical check template for a type of check, based on proportions. Usually either small size for personal check (6″×2¾″) and bigger size for business check (8¼″×3″), or cashiers check (3.5×8.5); and then automatically add a required text information in the endorsed area, which is typically “For Deposit Only” or “Mobile Deposit” plus sometimes a bank account number of the merchant or other information as required by the bank of the processor. This approach increases the speed of the transactions, because the consumer does not have to take a photo of the backside. The system generates the back of the check for processors and can endorse it by inserting a signature either electronic (such as/Joe Doe/for example) or actual signature of the consumer stored in a database, if endorsement is required by the bank; if bank does not require endorsement, then backside won't contain a signature.
[0121] The system of the present disclosure is configured to provide for multiple check depositing with a mobile phone. Currently there are two check depositing solutions on the market: single check mobile deposits, which are very slow, or a portable check scanning machine, such as Panini X for PC, which is expensive. The system of the present disclosure is configured to take a picture of multiple checks at the same time, create a bi-tonal image, geometrically position and correct the image, and then divide the image into separate checks either on the mobile device or on the server. Then each check, including the amount, will be verified manually or electronically using OCR technology (a user will verify and confirm the amount for each check). After that the backside of the check can be added as described above, and then both sides can be converted to the appropriate format (tiff, jpg, png, etc.) and the check can be sent for processing to the bank. In some instances, a standard desktop scanner can be used or any other image-capable device; and then a user can upload an image of multiple checks to the system.
[0185] Since some banks don't like the universal backside of the check or pay close attention to it, the system is configured to capture backside of the check for checks over certain age (e.g., over 3 months old) and/or over certain amount (e.g., over $1,000) and/or for certain banks.
detecting, based on performing an instant optical character recognition (OCR) the front image of the document, content of the document (e.g. the content of the checks front and back are recognized in order to determine if the correct information is detected, which is taught in ¶ [120] and [121] above.),
wherein the instant OCR comprises an OCR process that is performed automatically (e.g. a check can be re-submitted for an automatic OCR a second time, which is taught in ¶ [152].); and
[0152] The system can also allow for a bad check interception due to an error. In a situation when a check was optically recognized by an OCR engine, but there is a mistake in the MICR line/code, possibly due to signature or other obstructions, a bank would return such a check with an error “unable to locate account” or any other check errors. In accordance with the method of the present invention, to improve the user (merchant) experience, the system is configured to intercept this bad check, re-run it through another OCR or through manual review and automatically resubmit this check again without merchant's involvement.
initiating the exception handling based on the content of the document including an exception to a standard format for a document type of the document (e.g. the invention performs a process of correcting errors or abnormalities detected from the OCRed document that is not considered as the standard of information on check, see ¶ [147]-]156].),
[0144] The system of the present invention allows for detecting unusual lower and upper limits of a user input. To deposit a check (or process a card) a merchant usually has to manually enter the amount into the system's application. However, zeros are always missing because it's easier to type in $1.00 instead of $100.00. When processing transactions for certain industries/certain merchants, the algorithm of the present invention can learn a typical amount that is usually being deposited, such that if the transaction is too small or too large, in addition to OCR recognition the software can flag the transactions with an unusual amount for either processor processing, algo processing, merchant processing or checkwriters processing by making one of them confirm and double check an unusually low or high amount.
[0147] The system is further configured to assist users in cases when a background of a scanned check is too light for detection thereby providing a solution that would tell a user that they need to use a darker background; the scanned check should have darker or sharper background to see better edges, because the OCR engine needs to distinguish the borders of the paper check and to do that, the dark background is required. So, to avoid this type of error (inability to detect check borders), the software can detect it, warn the users, and explain to them what to do to avoid frustration associated with the described-above problem. The system can provide users with recommendations to change the background when scanning a check (put a check on the dark background, for example).
[0148] The system of the present invention is designed to detect an incorrectly printed MICR line. Because the OCR engine needs to see special account/routing/check # delimiters at the bottom of MICR line of the check. So, if some of the delimiters are missing or incorrect, it would cause an OCR. To avoid this type of error (missing delimiters), the system of the present invention can detect it, warn the user and either send a check for manual processing or automatically fix the problem by adding a virtual delimiter so that the OCR machine can pass it.
[0149] The system also allows for a one click copying of transaction approval number by allowing users to copy transaction approval # (authorization code showing that transaction went through) with just one tap. Since merchants need to save the approval # and paste it to other applications such as scheduling or accounting, etc., the system makes it easier for them such that instead of highlighting and writing it down manually, the system can allow the users to save the approval code in the phone buffer by simply tapping on it.
[0150] The system of the present invention is equipped with wrong check amount flagging capabilities. As was discussed earlier in the instant application, there might be situations when the application-entered check amount is incorrect and differs from the written-on-the-check amount. There are processes to review it automatically and manually as was discussed earlier. The users of the application (i.e., merchants) need a way to flag an incorrect amount to be able to easily resolve the issue. The system provides a “flag wrong amount” feature, which is a button that would automatically send a notification to the team or directly to a partner to review the amount and adjust it accordingly and allowing merchants to change the incorrect amount after the check has been processed.
[0151] The system is also configured to provide the check image security (MICR line). Paper checks have exposed routing and account numbers (MICR line) and it might not be safe and non-compliant with the PCI payment card industry standard to save and show images of checks. The method of the present invention provides a solution that includes the following steps: blurring the MICR line after a predetermined amount of time; deleting the MICR line after a predetermined amount of time; and partially blurring/deleting the MICR line after a predetermined amount of time. An admin might have access to override this, which can be reversable for it can be restored, if needed. Also, in case a check doesn't go through or in case of similar authorization/clearance events, the MICR line will be made automatically available.
[0152] The system can also allow for a bad check interception due to an error. In a situation when a check was optically recognized by an OCR engine, but there is a mistake in the MICR line/code, possibly due to signature or other obstructions, a bank would return such a check with an error “unable to locate account” or any other check errors. In accordance with the method of the present invention, to improve the user (merchant) experience, the system is configured to intercept this bad check, re-run it through another OCR or through manual review and automatically resubmit this check again without merchant's involvement.
[0153] After a check has been deposited into the check21 system, merchants and banks don't know what to do with them. Since a check becomes a legal digital copy after being scanned, it can be given back to the check writer and/or discarded if the OCR system decides that the check is legible enough and will not require re-scanning. The detection and prediction of that is usually done upon recognizing MICR characters in real-time on the scanning device or on the server. The system of the present invention is configured to make determination whether to keep the check or discard based on the assigned confidence level the scan is correct (for example, if the confidence level is more than 90% then it's okay to discard).
[0154] The system also provides for bad check management method. Since Check21 images are returned electronically to the system by the bank, for a large merchant it's important to manage all bad checks in one place. The system includes a “Dispute” page that would be further divided into “unrecoverable” (stopped, closed account, etc.) and “recoverable” checks (NSF, etc.). Unrecoverable checks can only be submitted along with an issuing bank letter or other official confirmation that can be delivered physically or electronically that the check is now good and can be redeposited. Recoverable checks can be re-run by simply pressing a resubmit button. A bad check notification is usually sent to a customer (by email, sms, msgr, etc.), but the dispute panel will also have “read”/“unread” status so that the merchant can make sure no checks are missed.
[0155] Bad checks can also be assigned further for sub-users (such as an accountant) to follow up on and to either recover the debt or make notes and to write it off and to account for it. Bad check's images will be sent to sub-users along with the description of the problem.
[0156] The system of the present invention further includes security and readability features. For example, the checks that don't have a clear picture will be identified and dynamically asked for a re-scan via an additional pop-up screen/window in the system's application. For security, checks can be assigned a risk score based on the following factors. [0157] 1. Must be Personalized. Complete name and address pre-printed by the bank (no P.O. Boxes). [0158] 2. Date must be current, i.e., never post-dated. [0159] 3 Bank I.D. # [0160] 4 Payee must be your company. [0161] 5 Amounts written and numerical must be the same. [0162] 6 Bank name and address must be printed on the check. [0163] 7 Bank and customer computer numbers must be printed on check. [0164] 8 Customer signature—Must be signed in your presence. [0165] 9. Approximately 85% of all bad checks are written on accounts only a few months old and bear check numbers between 101 and 150—this can be detected by software/method of the present invention.
wherein the exception handling comprises:
sending a prompt to the document upload application (e.g. the user’s application can receive a prompt for re-scan or to warn a user about an issue with the scanning or OCR of a check, which is taught in ¶ [147]-[156] above. In addition, a check writer can be sent a prompt to confirm an amount on a check, which is taught in ¶ [144] above.);
receiving, from the document upload application and responsive to sending the prompt, a request to trigger a secondary review process for the document during the document upload process; triggering, based on receiving the request, the secondary review process (e.g. after receiving a prompt to enter missing information, such as a date or signature, the user can enter in the information that was reported as missing in to the application. The response in fixing the error will cause a check to be submitted with the missing information in order to be reviewed by the merchant or server to complete the transaction, which is taught in ¶ [120], [121] above and [113] and [171]-[176].); and
[0113] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants.
[0114] With reference to the earlier discussion of sending a confirmation link to confirm/accept terms of credit card or mRDC transactions, there are several ways to deliver the link which are provided by the system of the present invention:
[0115] 1. by scanning a dynamic QR-code on the 2nd phone (merchants' phone),
[0116] 2. by sending an email,
[0117] 3. by sending an SMS message from the server (from the application with a button), and additionally,
[0118] 4. by sending an SMS from the merchant's phone directly (as a regular person to person sms, not from the server), wherein the system of the present invention (iWallet) is configured to (ii) generate an url link and enable the merchant to copy the link and send an sms message to the consumer outside of the iWallet and (ii) also can send a text to the merchant with the link, which is especially relevant in situations where telephone operators such as Verizon blocks text messages from IP phone coming from the server.
[0119] The system of the present invention is also configured to allow for offline mobile check transactions uploads (mRDC). In case a merchant's mobile phone doesn't have a connection, the system enables the merchant to upload an image of the check into the application memory and upload it later to the cloud when the connection is restored. Thus, the image of the check is stored in the local memory of the mobile phone and once the connection is established, the image is uploaded to the cloud/server or (ii) it can be encrypted image with public key and then once uploaded to the server, the service can process it, decrypting using private key. The same approach can be used for consumers when a consumer's mobile phone does not have a connection.
[0171] The system provides for automatic recognition of batch discrepancies (batch is a number of checks per day that is sent for secondary manual review) and connecting them to incorrectly processed checks. It's common in check21 situations to have a user enter an incorrect amount. In these instances, a check might be automatically adjusted by the bank and then the whole daily batch will be affected. In accordance with the method of the present invention, the system can analyze the check and ask for manual/human overview to 100% understand where the discrepancy came from.
[0172] The system is configured to automatically recognize missing signature (or date, etc.) error in a situation when a check writer forgets to write down a signature on a check or date the check. The system's OCR software can detect this condition and warn the user (merchant or check writer) thereby preventing the merchant from depositing bad checks.
[0173] The system is also designed to automatically reach out to a check writer in case of a missing signature or date to get an electronic signature or date (to sign a digital copy of the check).
[0174] The system provides the ability for a check writer to securely self-upload a check image (send bill) rather than having merchant taking a picture. It is usually common for a merchant to deposit a check of the payee (check writer). However, the system now has a way to send to the check writer a link, which will allow the payee (check writer) to upload a picture of the check in a more secure way. Thus, not only the image will be encrypted, but also the more sensitive routing/account numbers of the check.
[0175] The system provides for reconciling check/card transactions by having two tabs: reconciled and non-reconciled. Since it is very important for a merchant to understand where the transactions came from, the system includes an ability of an advanced check register where each check is moved from “unreconciled” tab to “reconciled” after it is reviewed by the owner/accounting person.
[0176] The system is further configured to generate customer reviews after capturing remote customer signature on mobile application. The system provides a way to generate online reviews for merchants that receive paper checks by sending a link to capture customers signature to finalize a transaction or to capture customers check securely. After clicking “submit” button, a user is forwarded to a review page to help boost online reputation for a merchant; thereby providing a review page for users to leave review of merchant's services.
allowing the document upload process to proceed based on receiving approval from the secondary review process (e.g. the uploading of the check can occur once a secondary review by the user occurs again and another attempt at scanning a clearer photo occurs, which is taught in ¶ [156] above. In addition, if a user corrects an issue with the check, a link can be used to send the corrected items for the check to fill the missing or obstructed information, which is taught in ¶ [171]-[176] above. After the information is checked by the merchant for the correct information, the check information can be uploaded to a server, which is taught in ¶ [113]-[119] above.).
However, Kolchin fails to specifically teach the features of wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model;
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for uploading the document to the user account; and
determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Tidwell. Similar to the primary reference, Tidwell discloses a model receiving check and account information (same field of endeavor or reasonably pertinent to the problem).
Tidwell discloses wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model (e.g. the check image dimensions and payee information is passed to the validation routines that include a risk scoring algorithm. The account number associated with the user account is also passed to the validation routines that uses a risk scoring algorithm that scores the information presented, which is taught in ¶ [79]-[82], [86] and [87].);
[0079] When the validation routines component 135 indicates that the data is acceptable, the check authorization system 100 may activate the risk scoring and decisioning component 175, which in some embodiments, calculates a risk score for the proposed transaction and provides an approval or decline recommendation to the check-cashing entity 110. In some embodiments, the validation routines component 135 transmits data that has been validated as to its format, value range, and the like, and the risk scoring and decisioning component 175 assigns risk scores to the risk factors for use in calculating a transaction risk score. In some embodiments, the validation routines component 135 calculates risk scores associated with individual validated input data items and transmits the risk scores to the risk scoring and decisioning component 17 for use in calculating a risk score for the check-cashing transaction.
[0080] Risk scoring algorithms generally take into account available pieces of data that have been determined to be statistically significant to an assessment of the risk associated with accepting a transaction. The transaction risk score may be a normalized value that indicates the probability that the transaction will be good. In some embodiments, risk assessment for the proposed transaction and for the individual risk factors is accomplished using at least one of: a decision tree, expert system, set of business rules, neural network, Bayesian network, or the like, in addition to or as an alternative to calculating a risk score. Risk scoring and decisioning functions and structures are described in greater detail with reference to FIGS. 3-4 and FIGS. 8-14.
[0081] The check authorization system 100 may be implemented by a business entity offering services associated with the acceptance and processing of second-party checks. For example, in one embodiment, the check authorization system 100 system offers validation services to verify the conformance of data received by the check-cashing entity 110 to acceptable values and/or formats. The check authorization system 100 may be one component of a more comprehensive business entity that offers services related to risk management and/or transaction handling for check-related or other financial transactions. The check authorization system 100 may also be implemented as computer software, a distributed file, database accessed via the Internet, or on a computer operated by the check authorization system 100 or the check-cashing entity 110, or on a server for a networked group of check-cashing entities 110, such as a chain of check-cashing stores, or as a centralized system that provides services to entities who subscribe to their services, or in some other suitably configured manner.
[0082] Based on service agreements reached between the check-cashing entity 110 and the check authorization system 100, a notification based at least in part on the risk assessment performed by the risk scoring and decisioning component 175 may be transmitted from the check authorization system 100 to the check-cashing entity 110. The check-cashing entity 110 may then accept or decline the check for cashing.
[0086] In various embodiments, various types of data may be collected by the check-cashing entity 110. For example, information about the check presenter 101 and information about the check or other financial instrument to be cashed may be collected and transmitted to the check authorization system 100. Some examples of information about the check presenter 101 that may, in various embodiments, be collected comprise: a driver's license number, social security number, other identification or PIN number, name, address, employer information, photograph, other biometric information, other information from a smart card, information from a biomedical implant, and the like. Some examples of information about the check that may be collected comprise: payor information, payee information, check amount, issue date, account number and bank routing number for the account on which the check is drawn, other imprinted information from the face of the check, MICR line information, optical or other scan or image of the check or of any authenticating marks or insignia from the check, information about characteristics of the check such as check dimensions and/or reflectivity of the check material, and the like. In various embodiments, the check-cashing entity 110 may transmit information about the check-cashing entity 110 itself, so that the check authorization system 100 may identify, may categorize, and/or may access stored information about the check-cashing entity 110, such as check entity location, type, and/or contracted service parameters.
[0087] The check-cashing entity 110 communicates with the check authorization system 100 to request an authorization approval or decline recommendation for the proposed check-cashing transaction, transmitting at least some of the information received from the check presenter 101 and from the check.
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account (e.g. the system receives as an output, risk scores that are associated with the determined risk corresponding to the deposit or processing of a check. The transaction data of a deposit is taught in ¶ [54]. The risk scoring is developed and output to determine an approval or decline of the transaction, which is disclosed in ¶ [90]-[94]. A neural network can be used to perform the scoring aspect that assigns scores to certain inputs into the validation routines, which is taught in ¶ [116]-[119].); and
[0054] FIG. 1 is a block diagram of one embodiment of a system 100 to authorize acceptance of second-party checks. As shown in FIG. 1, a check presenter 101 presents a check to a check-cashing entity 110. In the embodiment shown, the check-cashing entity 110 requests approval for the transaction from a check authorization system 100. In one preferred embodiment, if the check authorization system 100 approves the transaction, the check-cashing entity 110 may accept the check and pay the check presenter 101 an equivalent amount of cash, minus any fees associated with the transaction. In other embodiments, if the check authorization system 100 approves the transaction, the check-cashing entity 110 may accept the check in exchange for goods and/or services, for a combination of goods and/or services and cash, or for deposit. As used herein, the term "cashing" is used to signify accepting the check for any combination of cash, goods, services, credit, or the like.
[0090] The process continues at state 220, where the check authorization system 100 determines if the transaction data is valid. In one embodiment, if some or all of the data is determined not to be valid, the check authorization system 100 notifies the check-cashing entity of the invalid data in state 225, and in state 255 advises the check-cashing entity 110 not to accept the check for cashing.
[0091] Returning to state 220, if the check authorization system 100 determines that the transaction data is valid, the process 200 continues in state 230, where the risk scoring and decisioning component 175 of the check authorization system 100 generates risk scores for some or all of the input variables as well as a combined risk score for the proposed check-cashing transaction, as will be described in greater detail with reference to FIG. 3 and FIG. 4.
[0092] Continuing on to state 235, the check authorization system 100 evaluates the calculated risk score to determine whether to recommend that the check-cashing entity 110 accept or decline the proposed transaction. In one embodiment, the determination is based on at least one of: predetermined threshold values, pre-agreed business practices associated with the entity's 110 service agreement, and business rules affected by the entity's 110 type. In other embodiments, the check authorization system 100 evaluates the calculated risk score based on other criteria.
[0093] The process 200 continues to state 240, where, based at least in part on the evaluation of state 235, the check authorization system 100 recommends accepting or declining the proposed check-cashing transaction. If the check authorization system 100 determines that recommending acceptance of the proposed transaction is indicated, the process 200 continues at state 245 where the check authorization system 100 advises the check-cashing entity 110 to accept the transaction. The process 200 continues to state 250, where the check-cashing entity 110 accepts the check from the check presenter 101 for cashing, and the process 200 is complete.
[0094] Returning now to state 240, if the check authorization system 100 determines that recommending that the check-cashing entity 110 decline the proposed transaction is indicated, a decline recommendation is transmitted to the check-cashing entity 110. In one embodiment, if a risk score calculated for the transaction falls within a pre-determined "decline range of value" set by the check-cashing entity 110, the check authorization system 100 declines or recommends declining the proposed transaction. The process 200 continues at state 255 where the check authorization system 100 advises the check-cashing entity 110 to decline the transaction. The process 200 continues to state 260, where the check-cashing entity 110 may decline to cash the check offered by the check presenter 101, and the process 200 is complete.
[0116] As depicted in the sample score calculations of FIG. 4, risk score factors, also known as variables 410, are associated with gradated risk score values 430 that express a level of perceived risk associated with an individual variable value 420. A transaction risk score 440 is calculated to reflect an assessed level of risk for the transaction as a whole, thus being influenced by the individual risk score values 430. In the sample score calculations of FIG. 4, the transaction risk score 440 is calculated as the sum of the variable risk scores 430. As will be familiar to one of ordinary skill in the art, the transaction risk score 440 may be calculated according to other methods. As one example, in one embodiment, variable risk scores 430 are weighted to reflect their relevance to a transaction risk assessment before being summed into the transaction risk score 440.
[0117] As described above, the risk score values 430 express a gradated level of perceived risk associated with the variable values 420. Thus, in various embodiments, the gradated risk scores allow for an expression of perceived risk levels that may be other than either an absolute absence of perceived risk or an absolute absence of perceived security. In various embodiments, risk score values 430 may be assigned to variable values 420 based on a variety of criteria, business priorities, statistical models, historical observations, and the like. For example, a previously observed pattern of higher risk associated with cashing payroll checks from small and mid-sized companies over larger companies may lead to an assignment of risk scores 430 that reflect higher risk associated with a paycheck from a company with two hundred and fifty employees and lower risk associated with a paycheck from a company with one thousand employees. When variable values 420 are expressed as numerical values, risk scores 430 may correspond to the variables based on ranges into which the variable values fall.
[0118] In various embodiments, assignments of risk scores to variable values may be customized to suit the preferences and priorities of a given check-cashing entity 110 for whom the risk scoring is being carried out. Thus, for example, two check-cashing entities may associate a different level of risk with a given variable value, such as a Biometric Confidence value of 90%, and risk score assignments for the two check-cashing entities 110 may be different one from the another.
[0119] In some embodiments, risk scores 430 are assigned to variable values 420 based on an automated learning or decision-making algorithm that identifies risk patterns associated with various variable values 420. For example, the automated learning or decision-making algorithm may comprise a neural network, Bayesian or other probabilistic network, genetic algorithm, statistical analysis, decision tree, expert system, decision tree, ruled-based decision system, linear calculation, other scoring mechanism, or a combination of any of the foregoing.
Therefore, in view of Tidwell, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model; receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account, incorporated in the device of Kolchin, in order to input information into a neural network used to determine scores for the transaction, which can prevent losses based on fraudulent transactions (as stated in Tidwell ¶ [12]).
However, the combination above fails to specifically teach the features of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Joseph. Similar to the primary reference, Joseph discloses calculating a score for check information input into a model (same field of endeavor or reasonably pertinent to the problem).
Joseph discloses determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value (e.g. errors are detected on a check that are associated with the content on the check image. Based on the check information, it is determined whether the check information score is below a threshold. When it is detected that the check score is below a threshold, the areas associated with a low score can be predicted in order to correct the area. Moreover, based on the low score and the correction information, it is determined what area needs to be corrected, which is taught in ¶ [41]-[48].).
[0041] If there is an error, in step 225, a data parser module may receive the extracted information and may perform a differentiation conditional test to determine whether the extracted information is for test or training. If it is for training, in step 225, the data parser module may train a machine learning correction engine with the extracted information. In one embodiment, the data parser module may train a machine learning model with the extracted information (e.g., the information from the machine learning correction engine) to predict the correction.
[0042] If the information is for test, in step 230, the data parser module may pass the extracted information to a corrector module to use a trained machine learning correction engine to predict a correction and a confidence score in the correction based on one or more of the payer name, payee name, account number, routing number, auxonus, EPC, process control, etc. Any of the fields in the transaction data may be incorrect, thus, the fields may be compared to reference/historical information for similar patterns. From these patterns, the trained machine learning correction engine may return a predicted correction and a confidence score in the correction.
[0043] In step 235, the predicted correction and confidence score may be presented to an evaluator module with the predicted correction for the transaction information. The evaluator module may verify that the data matches with the information presented on the transaction.
[0044] In step 240, the confidence score may be evaluated against a threshold, such as 100%. If the confidence score meets this requirement, in step 245, the transaction may be corrected with the predicted correction.
[0045] In step 250, the parser module may train the correction engine with predicted correction, and in step 220, the corrected transaction may be provided to a finalization process.
[0046] If the probable score is not at the threshold, in step 255, the transaction may be recursively looped back to the parser module to train the machine learning correction engine to not apply the correction pattern to any other similar transactions.
[0047] In step 260 the incorrect transaction may be provided to a remediation process for human verification of the check image, and correction of the data.
[0048] In step 265, the human and corrected data is then passed to the parser module, which may then train the machine learning correction engine. The corrected transaction may then be passed to the finalization process in step 220.
Therefore, in view of Joseph, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value, incorporated in the device of Kolchin, as modified by Tidwell ‘351, in order to determine an area within a document does not match with a standard and needs correction, which aids in improving the model to further improve the performance of the model to correct check data (as stated in Joseph [45]-[48]).
However, the combination above fails to specifically teach the features of for uploading the document to the user account.
However, this is well known in the art as evidenced by Heit. Similar to the primary reference, Heit discloses preventing the upload of documents (same field of endeavor or reasonably pertinent to the problem).
Heit discloses for uploading the document to the user account (e.g. the invention discloses having a deposit being an upload of a file to the host system. Applying this to the features of Tidwell and Joseph would yield a risk score associated with a deposit that corresponds to a file being uploaded based on the approval of the deposit. The deposit information is taught in ¶ [148]-[150].).
Approval Module 175
[0148] The DMS 12 provides the approval module 175 that can allow batches/items to be managed within the DMS 12, and to be approved for settlement, thereby providing the distributed decisioning environment 501 (see FIG. 5) for functionality otherwise conducted by the decisioning engine 24 of the host system 14 (see FIG. 1). For example, the Approve Batches/items module 175 can facilitate users to review batches/items (using an approval screen--not shown) that have been balanced, but not yet "injected" into the host system 14 for deposit processing. The user can make approval decisions, and approve Batches/items for deposit. It is recognised that prior to approval, the module 175 can allow for items to be edited or voided. Further, the module 175 can allow the user to review deposits previously made and to provide visual confirmation of successful "Deposit" (i.e. file upload to the host system 14), or indication otherwise. Further, it is recognised that the module 175 may receive Units of Work directly from Image Items, from Key Data, or from Balance Batches modules and can forward Units of Work (e.g. completed batches) to the transfer module 180.
[0149] The batch/item view approval screen can display a list of all batches/items that have been balanced, but not yet included in a deposit. The screen can show the front image of the items selected. For each batch, the view will display the following details (columns), such as but not limited to: Date/Time Batch/item was ready for approval; Batch Control Number; Number of items; Total Dollars; indication as to whether, MICR data was changed, Image Quality suspect was accepted, and/or duplicate detection was overridden; and a selectable checkbox (e.g. approved). The user can expand the batch in the list to display all of the items within it. This can be implemented as a grid control with nested rows. For each item, the view can display the following details (columns), such as but not limited to: Transaction Type; Date/Time Item was scanned; IRN; R/T Number; Account Number; item Number; Dollar Amount; and indication as to whether, MICR was changed, image quality failure was overridden, and/or duplicate detection was overridden.
[0150] In view of the above information, the user of the module 175 can select an item from the list and open the "Edit Item" window, causing a "Edit Item" screen to be displayed for facilitating editing of the image/data 20 associated therewith. All changes made to items via the edit function can be included when the batch/item is approved for Deposit. Further, the BCT can be recalculated to account for any amount change, or in the case of a single item the needed document 18 information (e.g. check amount) can be CARLARed again and/or the needed document 18 information (e.g. check amount) can be rekeyed. Also, the user can select an item from the list and "Void" the item. If the voided item is the only unvoided item in the batch, then the batch can be removed completely.
Therefore, in view of Heit, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of for uploading the document to the user account, incorporated in the device of Kolchin, as modified by Tidwell and Joseph, in order to consider a deposit an upload of a document to the system that is determined to be approved or declined, which can aid in efficient use of the system (as stated in Heit ¶ [04] and [05]).
However, the combination above fails to specifically teach the features of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document.
However, this is well known in the art as evidenced by Ethington. Similar to the primary reference, Ethington discloses using an API to communicate with a server (same field of endeavor or reasonably pertinent to the problem).
Ethington discloses receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document (e.g. the system discloses communicating with the server through the MultiCrop program. A browser can be used to communicate uploads to the server. The browser can use an API to communicate uploads to the server to have an API request include a front or rear image sent to the server. This is taught in col. 47, ll. 3-47 (240) and (241) and col. 86, ll. 19-45 (419). The system further communicates with the server through email using communications using an API transfer of data or the use of other communications between components using communications handled by an API. This is taught in col. 86, ll. 55-58 (421) and col. 91, ll. 10-34 (437). The system further discusses earlier in the reference of first sending an upload of a front of a document, approving the front and proceeding with the request for the back of the document. The user captures the back of the check to go through the same process and sends the image to the server, which is taught in col. 6, ll. 53-col. 7, ll. 58, col. 8, ll. 29-37 (34)-(39) and (42). With the communication of the device installing the MultiCrop software able to use an API browser, email or API communication to the server, the sending of the front and back separately using the API request to the server performs the features of the claims.).
MultiCrop Multiple Check Cropping
(34) FIGS. 2A-2B provide logic flow diagrams illustrating embodiments of the MultiCrop. In one embodiment, MultiCrop may comprise an image uploading and processing component delivered to and installed at a user device. For example, a user may install an MultiCrop application at his personal computer, smart phone, and/or CPAM: 3853804.1 the like, and may instantiate the MultiCrop application for remote deposit. In an alternative implementation, the MultiCrop may comprise a check image processing module associated with a remote server, wherein the server may remotely control a user device to capture and upload check images for deposit, and process the check images in real-time or in a batch.
(35) Within implementations, upon receiving a user request to deposit, MultiCrop may prompt a user to provide user credentials to instantiate a remote deposit, e.g., a user account name, password, and/or the like. Upon user login, the MultiCrop may provide instructions via a user interface for the user to deposit one or more checks. For example, FIG. 3A shows an example screen shot illustrating a user interface of the MultiCrop. As shown in FIG. 3A, the MultiCrop may provide instructions 3A-42 to request the user to endorse the back of the check(s) to be deposited, place the checks on the scanner to scan one side of the check, select the scanner, and click the button for the number of checks placed on the scanner, etc.
(36) In one implementation, as shown in FIG. 3A, the MultiCrop may request the user to select an image capture device 3A-41, e.g., a scanner connected to the personal computer, a camera, etc. For example, the MultiCrop application may be downloaded and installed on the user's personal computer, which may detect and control any image capture device connected to the computer via a TWAIN driver, and/or the like. Alternative implementations of interfacing and controlling the image capture device are discussed in FIGURE nA.
(37) In one implementation, the MultiCrop may receive an indication of a number of checks to be deposited from the user 2A-05. For example, as shown in FIG. 3A, after providing user credentials to log into the MultiCrop application, a user may view icons illustrating deposit a single check, or multiple checks, and may click on the icon (e.g., to deposit three checks) to select 3A-40.
(38) In one implementation, if the user selects a single check to be deposited, the MultiCrop may proceed to process the crop the check image starting at 2A-25. In another implementation, if the user selects to deposit more than one check (e.g., three checks, etc.) 2A-10, the MultiCrop may provide instructions via a user interface for the user to deposit multiple checks at one time. For example, as shown in FIG. 3A, the MultiCrop may instruct the user via an illustrative icon 3A-40 to request the user to evenly align multiple checks on a scanner bed.
(39) In one implementation, the MultiCrop may receive an image comprising multiple images of front sides of a plurality of checks to be deposited 2A-15. The MultiCrop may then process the received image to extract separate check images. In one implementation, the MultiCrop may divide the received image into a number of subimages 2A-20. For example, if the MultiCrop has received an indication that three checks are to be deposited, the MultiCrop may evenly divide the image received at 4015 into three sub-images, wherein each sub-image contains one check image. For another example, the MultiCrop may convert the received image into a grayscale image and obtain an estimate of locations of the check images based on grayscale value analysis of the image of received at 2A-15, as further illustrated in FIG. 2C. For another example, the MultiCrop may convert the receive image into a bitonal virtual image with a light foreground representing the check portion and a dark background, and scan the virtual image from top to bottom to locate the light foreground so as to divide the virtual image, as further illustrated in FIGS. 2F and 2G.
(42) In one implementation, if the front sides of the checks are successfully scanned and processed, the MultiCrop may upload the front images upon user confirmation. For example, the user may click “submit,” and the MultiCrop may then transfer the image data to a remote server, as illustrated at 3C-53 in FIG. 3C. The MultiCrop may proceed to request the user scan the back sides of the checks 2A-60, and process/crop back sides of the checks in a similar manner as applied to front sides of the checks.
(169) As shown in FIGURE BB, at 8B-48, the payee may send the electronic data to a bank that is associated with an account for depositing funds. Any means for transmitting electronic data over a communications network is consistent with an embodiment. For example, if the payee creates a digital image of the check, the image may be sent to the bank by attaching the image to an email. If the electronic data is in the form of MICR information captured by a MICR device, the device may have an output component for transmitting the electronic data to the bank over the communications network. In addition, the electronic data may include information pertaining 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 digital image, for example.
(240) In another embodiment, if the image capture device is not controllable by the browser application component, the MultiCrop may load an instruction user interface page 11.A-15, and instruct the user manually upload the check images. For example, in one implementation, the MultiCrop platform may not have certificates for scanner drivers for a Macintosh computer. In one implementation, the MultiCrop may instruct the user to enter a deposit amount 11.A-20 (as illustrated in a schematic user interface uB-50 shown in FIGURE uC), and to scan front/back side of the check and save the scanned image files uA-25. In one implementation, the MultiCrop may instruct the user to save the scanned image files in a specified format (e.g., tiff, JPEG etc.) uA-30, as illustrated in the schematic user interface uB-56 and uB-58 of FIGURE uB. In one implementation, the MultiCrop may instruct the user to edit the check image file prior to uploading 11.A-30. For example, in one implementation, as shown in FIGURE uC, the MultiCrop may instruct the user to crop the check image via an image editing component, during which the user may submit a selection of check image corner uC-72 via a user interface. In a further implementation, the MultiCrop may instruct the user to convert the obtained check image into a grayscale image prior to uploading the image file. In one implementation, the user may send the obtained check images to MultiCrop platform via email, mobile MMS, MultiCrop browser uploading, and/or the like.
(241) In one embodiment, the MultiCrop may receive check digital files 445 from the remote user device. In one implementation, the user may send the obtained check images to MultiCrop platform via email, mobile MMS, MultiCrop browser uploading, and/or the like. In one embodiment, if the user image capture device is video-enabled, the MultiCrop may receive video clips of the check. In one implementation, video files may be saved in a series of compliant formats (e.g., AVI, MPEG4, RM, DIVX, etc.) and submitted to the MultiCrop platform in similar manners with those of submitting check image files as discussed above. In one implementation, the MultiCrop may instruct or assist the user to compress one or more video files into a package (e.g., WinZip package, etc.) and submit the pack to the MultiCrop.
Web Browser
(419) A Web browser component 2218 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with 128 bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APis (e.g., FireFox, Safari Plug-in, and/or the like APis), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the MultiCrop enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
(421) Access to the MultiCrop mail may be achieved through a number of APis offered by the individual Web server components and/or the operating system.
(437) If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (COREA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components.
Therefore, in view of Ethington, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document, incorporated in the device of Kolchin, as modified by Tidwell, Joseph and Heit, in order to use API requests to send check images to a server after an initial check information is approved, which can improve check image processing (as stated in Ethington col. 42, ll. 3-16).
Re claim 2: Kolchin discloses the computer-implemented method of claim 1, wherein the exception is determined based on a difference between the content of the document and the standard format for the document type of the document (e.g. the date or signature can be detected missing when a standard format would require this information, which is taught in ¶ [171]-[173] above. In addition, delimiters can be missing when the system expects this information. Moreover, if the amount on the check is too low or high, this can cause a system exception to be triggered, which is taught in ¶ [144]-[150] above.).
Re claim 3: Kolchin discloses the computer-implemented method of claim 2, wherein the difference comprises at least one of a missing account number, a missing routing number, and missing user information (e.g. a missing signature or a dollar amount can be used to determine a difference, which is taught in ¶ [171]-[173] above.).
Re claim 4: Kolchin discloses the computer-implemented method of claim 2, wherein the standard format for the document type comprises expected information in the document (e.g. the system can detect if a signature is missing when expected to be in the image, which is taught in ¶ [171]-[173] above.).
Re claim 5: Kolchin discloses the computer-implemented method of claim 1, wherein the exception comprises unreadable text in the content of the document (e.g. an obstruction can occur where information is written over other information that prevents the proper OCR, which is taught in ¶ [143] and [152]. In addition, text can be unreadable based on the background preventing the reading of the text, which is taught in ¶ [147] above.).
[0143] The problems with some of the checks usually happen when a signature (an obstruction) goes over the ACH digits, such that the OCR engine struggles to process a check. For this reason, to reduce OCR errors, the method of the present invention allows for cleaning up the check manually or automatically before the check gets sent for OCR processing. Manually, the backoffice personnel can perform some minor clean ups to have just enough clearance for OCR to recognize the font. Automatically, the system is configured to remove the obstruction by training a Computer Vision Convolutional neural network to recognize a typical check font(s) and clean it up before submitting it to OCR processing by restoring a background image of the check. Additionally, the system of the present invention allows for an override feature to manually type in number by merchants or other personnel.
[0152] The system can also allow for a bad check interception due to an error. In a situation when a check was optically recognized by an OCR engine, but there is a mistake in the MICR line/code, possibly due to signature or other obstructions, a bank would return such a check with an error “unable to locate account” or any other check errors. In accordance with the method of the present invention, to improve the user (merchant) experience, the system is configured to intercept this bad check, re-run it through another OCR or through manual review and automatically resubmit this check again without merchant's involvement.
Re claim 6: Kolchin discloses the computer-implemented method of claim 1, wherein the exception handling further comprises preventing termination of the document upload process prior to triggering the secondary review process (e.g. the system can still allow for uploading the information to a merchant before completing the uploading of the document to a server. This is performed when a user may correct missing information of a check and upload the check to the merchant before sending the corrected check from the merchant to the server, which is explained in ¶ [113]-[119] and [171]-[176] above.).
Re claim 7: Kolchin discloses the computer-implemented method of claim 1, wherein the prompt comprises at least one of a description of an irregularity detected in the content of the document or an image of the irregularity detected in the content of the document (e.g. a description of the irregularity is sent to the user, or check writer, to correct the issue, which is taught in ¶ [171]-[176] above.).
Re claim 8: Kolchin discloses the computer-implemented method of claim 1, wherein triggering the secondary review process further comprises routing the front image of the document and the back image of the document to the secondary review process (e.g. if a user forgets a signature, the user is requested to input this information, which is taught in ¶ [171]-[176] above. This can be on the back of a check, which is taught in ¶ [185] and [186]. The check can then be requested to be uploaded for forwarding to a merchant to check the contents of the check, which is taught in ¶ [113]-[119] above.).
[0185] Since some banks don't like the universal backside of the check or pay close attention to it, the system is configured to capture backside of the check for checks over certain age (e.g., over 3 months old) and/or over certain amount (e.g., over $1,000) and/or for certain banks.
[0186] The system provides for capturing a check image to send a secure link to the check writer to upload a check via Check21 messaging system. Virtual check image is saved by the system and the user can use the link to generate checks fast, just by typing an amount and payee's name. When the merchant sends request to pay to the check writer and the check writer takes the picture of the check and then uploads it to a secure website, the system is configured to offer to the checkwriter to use that image as a template to generate new checks; thereby allowing the check writer to send the link with the mobile check image as a payment to merchants
Re claim 9: Kolchin discloses a system for providing exception handling during a document upload process of a document, comprising:
a memory; and at least one processor coupled to the memory (e.g. a memory is used with a processor to perform the functions of the invention, which is taught in ¶ [36] and [37].) and configured to:
[0036] Referring now to the drawings in detail. An exemplary computing device is illustrated by FIG. 4. The processor 101 may be a special purpose or a general-purpose processor device. As will be appreciated by persons skilled in the relevant art, the processor device 101 may also be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. The processor 101 is connected to a communication infrastructure 102, for example, a bus, message queue, network, or multi-core message-passing scheme.
[0037] The computing device also includes a main memory 103, such as random-access memory (RAM), and may also include a secondary memory 104. Secondary memory 104 may include, for example, a hard disk drive 105, a removable storage drive or interface 106, connected to a removable storage unit 107, or other similar means. As will be appreciated by persons skilled in the relevant art, a removable storage unit 107 includes a computer usable storage medium having stored therein computer software and/or data. Examples of additional means creating secondary memory 104 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 107 and interfaces 106 which allow software and data to be transferred from the removable storage unit 107 to the computer system. In some embodiments, to “maintain” data in the memory of a computing device means to store that data in that memory in a form convenient for retrieval as required by the algorithm at issue, and to retrieve, update, or delete the data as needed.
receive, from an upload application on a user device, a front image of the document to be uploaded to a user account (e.g. the user sends a request for deposit of a check. The user mobile device is used to perform the capturing of the check, which is taught in ¶ [68], [79]. A server can be used in the processing and OCR of the received images, which is taught in ¶ [46] and [47]. The front and the back of the check can be sent to the server for processing, which is taught in ¶ [120], [121] and [185].);
detect, based on performing an instant optical character recognition (OCR) the front image of the document, content of the document (e.g. the content of the checks front and back are recognized in order to determine if the correct information is detected, which is taught in ¶ [120] and [121] above.),
wherein the instant OCR comprises an OCR process that is performed automatically (e.g. a check can be re-submitted for an automatic OCR a second time, which is taught in ¶ [152].); and
initiate the exception handling based on the content of the document including an exception to a standard format for a document type of the document (e.g. the invention performs a process of correcting errors or abnormalities detected from the OCRed document that is not considered as the standard of information on check, see ¶ [147]-[156] above.),
wherein the exception handling comprises:
sending a prompt to the document upload application (e.g. the user’s application can receive a prompt for re-scan or to warn a user about an issue with the scanning or OCR of a check, which is taught in ¶ [147]-[156] above. In addition, a check writer can be sent a prompt to confirm an amount on a check, which is taught in ¶ [144] above.);
receiving, from the document upload application and responsive to sending the prompt, a request to trigger a secondary review process for the document during the document upload process; triggering, based on receiving the request, the secondary review process (e.g. after receiving a prompt to enter missing information, such as a date or signature, the user can enter in the information that was reported as missing in to the application. The response in fixing the error will cause a check to be submitted with the missing information in order to be reviewed by the merchant or server to complete the transaction, which is taught in ¶ [113], [120], [121] and [171]-[176] above.); and
allowing the document upload process to proceed based on receiving approval from the secondary review process (e.g. the uploading of the check can occur once a secondary review by the user occurs again and another attempt at scanning a clearer photo occurs, which is taught in ¶ [156] above. In addition, if a user corrects an issue with the check, a link can be used to send the corrected items for the check to fill the missing or obstructed information, which is taught in ¶ [171]-[176] above. After the information is checked by the merchant for the correct information, the check information can be uploaded to a server, which is taught in ¶ [113]-[119] above.).
However, Kolchin fails to specifically teach the features of wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model;
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for uploading the document to the user account; and
determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Tidwell. Similar to the primary reference, Tidwell discloses a model receiving check and account information (same field of endeavor or reasonably pertinent to the problem).
Tidwell discloses wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model (e.g. the check image dimensions and payee information is passed to the validation routines that include a risk scoring algorithm. The account number associated with the user account is also passed to the validation routines that uses a risk scoring algorithm that scores the information presented, which is taught in ¶ [79]-[82], [86] and [87] above.);
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account (e.g. the system receives as an output, risk scores that are associated with the determined risk corresponding to the deposit or processing of a check. The transaction data of a deposit is taught in ¶ [54] above. The risk scoring is developed and output to determine an approval or decline of the transaction, which is disclosed in ¶ [90]-[94] above. A neural network can be used to perform the scoring aspect that assigns scores to certain inputs into the validation routines, which is taught in ¶ [116]-[119] above.); and
Therefore, in view of Tidwell, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of wherein the exception to the standard format is detected by: passing the content of the document and account information associated with the user account as inputs to a limits model; receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account, incorporated in the device of Kolchin, in order to input information into a neural network used to determine scores for the transaction, which can prevent losses based on fraudulent transactions (as stated in Tidwell ¶ [12]).
However, the combination above fails to specifically teach the features of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Joseph. Similar to the primary reference, Joseph discloses calculating a score for check information input into a model (same field of endeavor or reasonably pertinent to the problem).
Joseph discloses determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value (e.g. errors are detected on a check that are associated with the content on the check image. Based on the check information, it is determined whether the check information score is below a threshold. When it is detected that the check score is below a threshold, the areas associated with a low score can be predicted in order to correct the area. Moreover, based on the low score and the correction information, it is determined what area needs to be corrected, which is taught in ¶ [41]-[48] above.).
Therefore, in view of Joseph, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value, incorporated in the device of Kolchin, as modified by Tidwell ‘351, in order to determine an area within a document does not match with a standard and needs correction, which aids in improving the model to further improve the performance of the model to correct check data (as stated in Joseph [45]-[48]).
However, the combination above fails to specifically teach the features of for uploading the document to the user account.
However, this is well known in the art as evidenced by Heit. Similar to the primary reference, Heit discloses preventing the upload of documents (same field of endeavor or reasonably pertinent to the problem).
Heit discloses for uploading the document to the user account (e.g. the invention discloses having a deposit being an upload of a file to the host system. Applying this to the features of Tidwell and Joseph would yield a risk score associated with a deposit that corresponds to a file being uploaded based on the approval of the deposit. The deposit information is taught in ¶ [148]-[150] above.).
Therefore, in view of Heit, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of for uploading the document to the user account, incorporated in the device of Kolchin, as modified by Tidwell and Joseph, in order to consider a deposit an upload of a document to the system that is determined to be approved or declined, which can aid in efficient use of the system (as stated in Heit ¶ [04] and [05]).
However, the combination above fails to specifically teach the features of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document.
However, this is well known in the art as evidenced by Ethington. Similar to the primary reference, Ethington discloses using an API to communicate with a server (same field of endeavor or reasonably pertinent to the problem).
Ethington discloses receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document (e.g. the system discloses communicating with the server through the MultiCrop program. A browser can be used to communicate uploads to the server. The browser can use an API to communicate uploads to the server to have an API request include a front or rear image sent to the server. This is taught in col. 47, ll. 3-47 (240) and (241) and col. 86, ll. 19-45 (419) above. The system further communicates with the server through email using communications using an API transfer of data or the use of other communications between components using communications handled by an API. This is taught in col. 86, ll. 55-58 (421) and col. 91, ll. 10-34 (437) above. The system further discusses earlier in the reference of first sending an upload of a front of a document, approving the front and proceeding with the request for the back of the document. The user captures the back of the check to go through the same process and sends the image to the server, which is taught in col. 6, ll. 53-col. 7, ll. 58, col. 8, ll. 29-37 (34)-(39) and (42) above. With the communication of the device installing the MultiCrop software able to use an API browser, email or API communication to the server, the sending of the front and back separately using the API request to the server performs the features of the claims.).
Therefore, in view of Ethington, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document, incorporated in the device of Kolchin, as modified by Tidwell, Joseph and Heit, in order to use API requests to send check images to a server after an initial check information is approved, which can improve check image processing (as stated in Ethington col. 42, ll. 3-16).
Re claim 10: Kolchin discloses the system of claim 9, wherein the exception is determined based on a difference between the content of the document and the standard format for the document type of the document (e.g. the date or signature can be detected missing when a standard format would require this information, which is taught in ¶ [171]-[173] above. In addition, delimiters can be missing when the system expects this information. Moreover, if the amount on the check is too low or high, this can cause a system exception to be triggered, which is taught in ¶ [144]-[150] above.).
Re claim 11: Kolchin discloses the system of claim 10, wherein the difference comprises at least one of a missing account number, a missing routing number, and missing user information (e.g. a missing signature or a dollar amount can be used to determine a difference, which is taught in ¶ [171]-[173] above.).
Re claim 12: Kolchin discloses the system of claim 10, wherein the standard format for the document type comprises expected information in the document (e.g. the system can detect if a signature is missing when expected to be in the image, which is taught in ¶ [171]-[173] above.).
Re claim 13: Kolchin discloses the system of claim 9, wherein the exception comprises unreadable text in the content of the document (e.g. an obstruction can occur where information is written over other information that prevents the proper OCR, which is taught in ¶ [143] and [152] above. In addition, text can be unreadable based on the background preventing the reading of the text, which is taught in ¶ [147] above.).
Re claim 14: Kolchin discloses the system of claim 9, wherein the document type comprises a check and the user account comprises a checking account (e.g. the system utilizes a check that is associated with a checking account, which is taught in ¶ [188].).
[0188] A method for conducting secure electronic financial transactions in accordance with an embodiment of the present invention is illustrated in FIG. 17. Method 400 includes receiving a request, from a user, to perform a transaction with a merchant (step 410), generating a virtual check comprising a checking account number, a bank routing number, and a date (step 420), displaying the virtual check on at least one of a display of an electronic device of a user or the merchant (step 430), receiving input from the user corresponding to at least one of a plurality of check fields (step 440), receiving a virtual signature from the user (step 450), encrypting the virtual signature (step 460), storing the encrypted virtual signature in a database (step 470), decrypting and embedding, in the image of the virtual check, the virtual signature received from the user (step 480), populating the virtual check based on the received input (step 490), and depositing the virtual check (step 495). The method 400 can further include the step of encrypting and storing the account number and the routing number of the virtual check in a database.
Re claim 15: Kolchin discloses a non-transitory computer-readable medium storing instructions for providing exception handling during a document upload process of a document, the instructions, when executed by a processor on a mobile device (e.g. a memory is used with a processor to perform the functions of the invention, which is taught in ¶ [36] and [37].), cause the processor to perform operations comprising:
receiving from an upload application on a user device, a front image of the document to be uploaded to a user account (e.g. the user sends a request for deposit of a check. The user mobile device is used to perform the capturing of the check, which is taught in ¶ [68], [79]. A server can be used in the processing and OCR of the received images, which is taught in ¶ [46] and [47]. The front and the back of the check can be sent to the server for processing, which is taught in ¶ [120], [121] and [185] above.);
detecting, based on performing an instant optical character recognition (OCR) the front image of the document, content of the document (e.g. the content of the checks front and back are recognized in order to determine if the correct information is detected, which is taught in ¶ [120] and [121] above.),
wherein the instant OCR comprises an OCR process that is performed automatically (e.g. a check can be re-submitted for an automatic OCR a second time, which is taught in ¶ [152].); and
initiating the exception handling based on the content of the document including an exception to a standard format for a document type of the document (e.g. the invention performs a process of correcting errors or abnormalities detected from the OCRed document that is not considered as the standard of information on check, see ¶ [147]-[156] above.),
wherein the exception handling comprises:
sending a prompt to the document upload application (e.g. the user’s application can receive a prompt for re-scan or to warn a user about an issue with the scanning or OCR of a check, which is taught in ¶ [147]-[156] above. In addition, a check writer can be sent a prompt to confirm an amount on a check, which is taught in ¶ [144] above.);
receiving, from the document upload application and responsive to sending the prompt, a request to trigger a secondary review process for the document during the document upload process; triggering, based on receiving the request, the secondary review process (e.g. after receiving a prompt to enter missing information, such as a date or signature, the user can enter in the information that was reported as missing in to the application. The response in fixing the error will cause a check to be submitted with the missing information in order to be reviewed by the merchant or server to complete the transaction, which is taught in ¶ [113], [120], [121] and [171]-[176] above.); and
allowing the document upload process to proceed based on receiving approval from the secondary review process (e.g. the uploading of the check can occur once a secondary review by the user occurs again and another attempt at scanning a clearer photo occurs, which is taught in ¶ [156] above. In addition, if a user corrects an issue with the check, a link can be used to send the corrected items for the check to fill the missing or obstructed information, which is taught in ¶ [171]-[176] above. After the information is checked by the merchant for the correct information, the check information can be uploaded to a server, which is taught in ¶ [113]-[119] above.).
However, Kolchin fails to specifically teach the features of wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model;
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for uploading the document to the user account; and
determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Tidwell. Similar to the primary reference, Tidwell discloses a model receiving check and account information (same field of endeavor or reasonably pertinent to the problem).
Tidwell discloses wherein the exception to the standard format is detected by:
passing the content of the document and account information associated with the user account as inputs to a limits model (e.g. the check image dimensions and payee information is passed to the validation routines that include a risk scoring algorithm. The account number associated with the user account is also passed to the validation routines that uses a risk scoring algorithm that scores the information presented, which is taught in ¶ [79]-[82], [86] and [87] above.);
receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account (e.g. the system receives as an output, risk scores that are associated with the determined risk corresponding to the deposit or processing of a check. The transaction data of a deposit is taught in ¶ [54] above. The risk scoring is developed and output to determine an approval or decline of the transaction, which is disclosed in ¶ [90]-[94] above. A neural network can be used to perform the scoring aspect that assigns scores to certain inputs into the validation routines, which is taught in ¶ [116]-[119] above.); and
Therefore, in view of Tidwell, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of wherein the exception to the standard format is detected by: passing the content of the document and account information associated with the user account as inputs to a limits model; receiving, as an output from the limits model and based on the inputs, a confidence score representing a determined level of risk for the document to the user account, incorporated in the device of Kolchin, in order to input information into a neural network used to determine scores for the transaction, which can prevent losses based on fraudulent transactions (as stated in Tidwell ¶ [12]).
However, the combination above fails to specifically teach the features of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value.
However, this is well known in the art as evidenced by Joseph. Similar to the primary reference, Joseph discloses calculating a score for check information input into a model (same field of endeavor or reasonably pertinent to the problem).
Joseph discloses determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value (e.g. errors are detected on a check that are associated with the content on the check image. Based on the check information, it is determined whether the check information score is below a threshold. When it is detected that the check score is below a threshold, the areas associated with a low score can be predicted in order to correct the area. Moreover, based on the low score and the correction information, it is determined what area needs to be corrected, which is taught in ¶ [41]-[48] above.).
Therefore, in view of Joseph, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of determining the content of the document includes the exception to the standard format based the confidence score being below a threshold value, incorporated in the device of Kolchin, as modified by Tidwell ‘351, in order to determine an area within a document does not match with a standard and needs correction, which aids in improving the model to further improve the performance of the model to correct check data (as stated in Joseph [45]-[48]).
However, the combination above fails to specifically teach the features of for uploading the document to the user account.
However, this is well known in the art as evidenced by Heit. Similar to the primary reference, Heit discloses preventing the upload of documents (same field of endeavor or reasonably pertinent to the problem).
Heit discloses for uploading the document to the user account (e.g. the invention discloses having a deposit being an upload of a file to the host system. Applying this to the features of Tidwell and Joseph would yield a risk score associated with a deposit that corresponds to a file being uploaded based on the approval of the deposit. The deposit information is taught in ¶ [148]-[150] above.).
Therefore, in view of Heit, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of for uploading the document to the user account, incorporated in the device of Kolchin, as modified by Tidwell and Joseph, in order to consider a deposit an upload of a document to the system that is determined to be approved or declined, which can aid in efficient use of the system (as stated in Heit ¶ [04] and [05]).
However, the combination above fails to specifically teach the features of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document.
However, this is well known in the art as evidenced by Ethington. Similar to the primary reference, Ethington discloses using an API to communicate with a server (same field of endeavor or reasonably pertinent to the problem).
Ethington discloses receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document (e.g. the system discloses communicating with the server through the MultiCrop program. A browser can be used to communicate uploads to the server. The browser can use an API to communicate uploads to the server to have an API request include a front or rear image sent to the server. This is taught in col. 47, ll. 3-47 (240) and (241) and col. 86, ll. 19-45 (419) above. The system further communicates with the server through email using communications using an API transfer of data or the use of other communications between components using communications handled by an API. This is taught in col. 86, ll. 55-58 (421) and col. 91, ll. 10-34 (437) above. The system further discusses earlier in the reference of first sending an upload of a front of a document, approving the front and proceeding with the request for the back of the document. The user captures the back of the check to go through the same process and sends the image to the server, which is taught in col. 6, ll. 53-col. 7, ll. 58, col. 8, ll. 29-37 (34)-(39) and (42) above. With the communication of the device installing the MultiCrop software able to use an API browser, email or API communication to the server, the sending of the front and back separately using the API request to the server performs the features of the claims.).
Therefore, in view of Ethington, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of receiving an application programming interface (API) request, wherein the API request includes a front image of the document, and receiving, responsive to the document upload processing proceeding, a second API request from the upload application, wherein the second API request includes a back image of the document, incorporated in the device of Kolchin, as modified by Tidwell, Joseph and Heit, in order to use API requests to send check images to a server after an initial check information is approved, which can improve check image processing (as stated in Ethington col. 42, ll. 3-16).
Re claim 16: Kolchin discloses the non-transitory computer-readable medium of claim 15, wherein the exception is determined based on a difference between the content of the document and the standard format for the document type of the document (e.g. the date or signature can be detected missing when a standard format would require this information, which is taught in ¶ [171]-[173] above. In addition, delimiters can be missing when the system expects this information. Moreover, if the amount on the check is too low or high, this can cause a system exception to be triggered, which is taught in ¶ [144]-[150] above.).
Re claim 17: Kolchin discloses the non-transitory computer-readable medium of claim 16, wherein the difference comprises at least one of a missing account number, a missing routing number, and missing user information (e.g. a missing signature or a dollar amount can be used to determine a difference, which is taught in ¶ [171]-[173] above.).
Re claim 18: Kolchin discloses the non-transitory computer-readable medium of claim 16, wherein the standard format for the document type comprises expected information in the document (e.g. the system can detect if a signature is missing when expected to be in the image, which is taught in ¶ [171]-[173] above.).
Re claim 19: Kolchin discloses the non-transitory computer-readable medium of claim 15, wherein the exception comprises unreadable text in the content of the document (e.g. an obstruction can occur where information is written over other information that prevents the proper OCR, which is taught in ¶ [143] and [152] above. In addition, text can be unreadable based on the background preventing the reading of the text, which is taught in ¶ [147] above.).
Re claim 20: Kolchin discloses the non-transitory computer-readable medium of claim 15, wherein the document type comprises a check and the user account comprises a checking account (e.g. the system utilizes a check that is associated with a checking account, which is taught in ¶ [188] above.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bhakta discloses detecting defects in financial transactions.
Viera discloses submitting a check front and back to a processing sever.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD S DICKERSON whose telephone number is (571)270-1351. The examiner can normally be reached Monday-Friday 10AM-6PM EST..
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abderrahim Merouan can be reached at 571-270-5254. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD DICKERSON/ Primary Examiner, Art Unit 2682
Prosecution Insights