U.S. patent application number 11/868504 was filed with the patent office on 2008-10-09 for systems and methods for check 21 image replacement document enhancements.
Invention is credited to Clark S. Gilder, Michael G. Lalonde.
Application Number | 20080247629 11/868504 |
Document ID | / |
Family ID | 39826943 |
Filed Date | 2008-10-09 |
United States Patent
Application |
20080247629 |
Kind Code |
A1 |
Gilder; Clark S. ; et
al. |
October 9, 2008 |
SYSTEMS AND METHODS FOR CHECK 21 IMAGE REPLACEMENT DOCUMENT
ENHANCEMENTS
Abstract
The present invention provides enhanced processing of Check 21
items using an electronic payment system (EPS) to capture metadata
instructions. The metadata includes instructions regarding an
intended payment to a payee, and can be generated through a
truncation process and optical character recognition, directly from
a digitally originated check, and the like. The metadata is stored
in a database or the like for further processing instead of
printing a paper check. In various exemplary embodiments, the
present invention provides a capability to print Image Replacement
Documents (IRDs) compliant to Check 21 regulations from the
metadata. Further, these IRDs can include enhanced features as
described herein.
Inventors: |
Gilder; Clark S.;
(Alpharetta, GA) ; Lalonde; Michael G.;
(Alpharetta, GA) |
Correspondence
Address: |
CLEMENTS BERNARD MILLER
1901 ROXBOROUGH ROAD, SUITE 300
CHARLOTTE
NC
28211
US
|
Family ID: |
39826943 |
Appl. No.: |
11/868504 |
Filed: |
October 7, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60850536 |
Oct 10, 2006 |
|
|
|
Current U.S.
Class: |
382/137 |
Current CPC
Class: |
G06Q 20/108 20130101;
G06Q 40/00 20130101; G06Q 20/042 20130101; G06Q 20/10 20130101;
G06Q 20/102 20130101; G06Q 20/04 20130101; G06Q 20/0425 20130101;
G06Q 20/40 20130101 |
Class at
Publication: |
382/137 |
International
Class: |
G06K 9/00 20060101
G06K009/00 |
Claims
1. A Check 21 truncation method, comprising: scanning a paper
check; analyzing the scanned paper check to determine data
associated with the scanned paper check, wherein the data comprises
payment instructions, bank account number, and routing number;
storing the data associated with the scanned paper check as
metadata in a digital payment file, wherein the metadata comprises
the data and a globally unique identifier; and providing an image
replacement document image compliant to Check 21 based on the
metadata; wherein an output from the metadata is interoperable with
both paper and electronic clearing methods associated with Check 21
clearing systems.
2. The Check 21 truncation method of claim 1, wherein the storing
step comprises storing the metadata in the digital payment in lieu
of storing an image associated with the scanned paper check.
3. The Check 21 truncation method of claim 1, further comprising
the step of providing the metadata as an Image and Cash Letter file
to a bank.
4. The Check 21 truncation method of claim 1, wherein the image
replacement document is generated with zero degrees of skew, and
wherein the image replacement document comprises substantially
perfect quality as measured by Image Quality tests.
5. The Check 21 truncation method of claim 1, wherein the image
replacement document comprises the globally unique identifier,
wherein the globally unique identifier is utilized for verification
of the image replacement document.
6. The Check 21 truncation method of claim 1, wherein the image
replacement document comprises a bar code comprising the
metadata.
7. The Check 21 truncation method of claim 1, further comprising
the steps of: receiving the image replacement document; and
utilizing the globally unique identifier to electronically receive
the metadata associated with the image replacement document,
wherein the metadata is received as an image cash letter file
without scanning the image replacement document.
8. An enhanced image replacement document method, comprising:
receiving metadata associated with a check, wherein the metadata
comprises payment instructions from the check, wherein the check
comprises one of a paper check and a digitally originated check,
and wherein the paper check is truncated and the metadata is
generated based on scanning the paper check; generating an image
from the metadata, wherein the image comprises an image replacement
document of the check compliant to Check 21, wherein the image
comprises virtually no skew and substantially perfect quality as
measured by Image Quality tests; and printing the image.
9. The enhanced image replacement document method of claim 8,
wherein the printing step is performed at a computer attached to a
printer, wherein the computer comprises a browser configured to
receive the image and print the image, and wherein the browser
comprises security controls.
10. The enhanced image replacement document method of claim 8,
wherein the printing step comprises printing the image on paper
comprising a magnetic strip, and wherein the magnetic strip
comprises the metadata associated with the check.
11. The enhanced image replacement document method of claim 8,
wherein the printed image is compliant to ANSI X9
specifications.
12. The enhanced image replacement document method of claim 8,
wherein the printing step comprises printing a back image of the
check folded behind a front image of the check to provide a paper
check capable of paper processing.
13. The enhanced image replacement document method of claim 8,
wherein the image comprises a space for a notary field.
14. The enhanced image replacement document method of claim 8,
further comprising generating a barcode in the image, wherein the
barcode comprises the metadata.
15. An image replacement document printing method, comprising:
receiving metadata associated with a check under Check 21; and
printing the metadata as an image replacement document compliant to
X9 specifications, wherein the printed image replacement document
is generated with zero degrees of skew, and wherein the image
replacement document comprises substantially perfect quality as
measured by Image Quality tests.
Description
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] The present non-provisional patent application claims
priority to U.S. Provisional Patent Application Ser. No.
60/850,536, filed Oct. 10, 2006, and entitled "FINANCIAL PAYMENT
SYSTEMS AND METHODS," the contents of which are incorporated in
full by reference herein.
FIELD OF THE INVENTION
[0002] The present invention relates generally to Check 21 imaging
systems and methods, and more particularly, provides systems and
methods for enhanced processing of Check 21 Image Replacement
Documents (IRDs), such as storing check data in a digital payment
file instead of an image file which allows enhanced processing and
printing of IRDs.
BACKGROUND OF THE INVENTION
[0003] The Check Clearing for the 21st Century Act (Check 21) was
designed to foster innovation in the payments system and to enhance
efficiency by reducing some of the legal impediments to check
truncation (i.e., eliminating a paper check by converting into a
digital image and destroying the original paper item). The law
facilitates check truncation by creating a new negotiable
instrument called a substitute check (also known as an Image
Replacement Document (IRD)), which permits banks to truncate
original paper checks, to process check information electronically
via exchange of check image files, and to deliver substitute checks
to banks that want to continue receiving paper checks. A substitute
check is created from a check image described by the ANSI X9
standards, such as X9.37 draft, X9.140, and X9.180, all of which
are incorporated in-full by reference herein. This image file is a
digital bitmap in Tagged Image File Format (TIFF) format created by
electronically scanning and imaging the front and back of the
original paper check. The substitute check is created by printing
the front and back images along with some additional information on
an 8.5.times.11 inch sheet of paper. Under the Check 21 law, this
IRD is treated as the legal equivalent of the original check and
includes all the information contained on the original check (when
printed, the images and data must conform to the X9.140 standard).
The law does not require banks to accept checks in electronic form
nor does it require banks to use the new authority granted by the
Act to create substitute checks.
[0004] Referring to FIG. 1, a substitute check (or IRD) 10 is a
paper reproduction of an original check that contains an image of
the front and back of the original check and is suitable for
automated processing in the same manner as the original check. To
clear a check for consideration of payment, the depositing bank
transfers, presents, or returns the substitute check 10 (or another
paper or electronic representation of a substitute check) and
warrants that (1) the substitute check 10 contains an accurate
image of the front and back of the original check and a legend
stating that it is the legal equivalent of the original check, and
(2) no depositary bank, drawee, drawer, or endorser will be asked
to pay a check that it already has paid. The substitute check 10
for which a bank has made these warranties is the legal equivalent
of the original check for all purposes and all persons.
[0005] Conventionally, IRDs are created through a printing process
which utilizes check images produced during the original paper
check scanning process. This paper check scanning and imaging is
accomplished using a check/reader sorter such as the IBM 3890 and
the like. Disadvantageously, these conventional mechanisms require
large data storage of image files and are prone to imaging
problems. For example, under X9 standards a Check 21 image is
required to be a Black and White (B/W) TIFF image at low
resolution, approximately 200 dots per inch (dpi) TIFF image. An
average A4 scan produces 30 kilobytes (KB) of data at 200 dpi and
50 KB of data at 300 dpi. Thus, as more check images are created,
banks and other financial institutions require significantly more
data storage.
[0006] Second, the scanned images are prone to errors, such as
Optical Character Recognition (OCR) problems. For example, these
recognition algorithms are not perfect and they can mistake a
handwritten "7" for a "1" for example. These are called
substitution errors and banks want to keep these error rates as low
as possible to avoid out of balance errors. Having errors forces
banks to keep human operators around to compare by hand the image
and the OCR estimated amounts and correct these errors.
Additionally, scanned images saved in lower resolution TIFF files
provide an output image with lower quality and clarity.
[0007] Third, scanning paper checks or IRDs is slow and cumbersome;
requiring additional human operators to handle paper IRDs. Even
though Check 21 enabled truncation, many banks still receive paper
IRDs and thus they are forced to continue paper handling operations
in their Item Processing back-office departments. The per item
handling costs of IRDs continues to increase as the practice of
check image exchange becomes widely adopted, thus banks are looking
for ways to avoid re-scanning IRDs or to avoid having to create
IRDs when returning items to customers or non-image enabled
banks.
[0008] Thus, there exists a need in the banking and financial
industry to provide efficient mechanisms for handling Check 21
images.
BRIEF SUMMARY OF THE INVENTION
[0009] In various exemplary embodiments, the present invention
provides enhanced processing of Check 21 items using an electronic
payment system (EPS) to capture metadata instructions. The metadata
includes instructions regarding an intended payment to a payee, and
can be generated through a truncation process and optical character
recognition, directly from a digitally originated check, and the
like. The metadata is stored in a database or the like for further
processing instead of printing a paper check. In various exemplary
embodiments, the present invention provides a capability to print
Image Replacement Documents (IRDs) compliant to Check 21
regulations from the metadata. Further, these IRDs can include
enhanced features as described herein.
[0010] In an exemplary embodiment of the present invention, a Check
21 truncation method includes scanning a paper check, analyzing the
scanned paper check to determine data associated with the scanned
paper check, wherein the data includes payment instructions, bank
account number, and routing number, storing the data associated
with the scanned paper check as metadata in a digital payment file,
wherein the metadata includes the data and a globally unique
identifier, and providing an image replacement document image
compliant to Check 21 based on the metadata, wherein an output from
the metadata is interoperable with both paper and electronic
clearing methods associated with Check 21 clearing systems.
[0011] In another exemplary embodiment of the present invention, an
enhanced image replacement document method includes receiving
metadata associated with a check, wherein the metadata includes
payment instructions from the check, wherein the check includes one
of a paper check and a digitally originated check, and wherein the
paper check is truncated and the metadata is generated based on
scanning the paper check, generating an image from the metadata,
wherein the image includes an image replacement document of the
check compliant to Check 21, wherein the image includes virtually
no skew and substantially perfect quality as measured by Image
Quality tests, and printing the image.
[0012] In yet another exemplary embodiment of the present
invention, an image replacement document printing method includes
receiving metadata associated with a check under Check 21, and
printing the metadata as an image replacement document compliant to
X9 specifications, wherein the printed image replacement document
is generated with zero degrees of skew, and wherein the image
replacement document includes substantially perfect quality as
measured by Image Quality tests.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The present invention is illustrated and described herein
with reference to the various drawings, in which like reference
numbers denote like method steps and/or system components,
respectively, and in which:
[0014] FIG. 1 is an illustration of a substitute check (or
IRD);
[0015] FIG. 2 is a diagram of a Check 21 IRD system according to an
exemplary embodiment of the present invention;
[0016] FIG. 3 is an image of an IRD generated from metadata
according to an exemplary embodiment of the present invention;
[0017] FIG. 4 is a flowchart of a DPF operational scenario for
generation and processing of DPFs according to an exemplary
embodiment of the present invention; and
[0018] FIG. 5 is a block diagram of an EPS according to an
exemplary embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0019] In various exemplary embodiments, the present invention
provides systems and methods for efficient data storage of Check 21
items and for superior quality image generation of the associated
Check 21 items. The present invention also provides enhanced
processing of Check 21 items using an electronic payment system
(EPS) to capture metadata instructions. The metadata includes
instructions regarding an intended payment to a payee, and can be
generated through a truncation process and optical character
recognition, directly from a digitally originated check, and the
like. The metadata is stored in a database or the like for further
processing instead of printing a paper check. In various exemplary
embodiments, the present invention provides a capability to print
Image Replacement Documents (IRDs) compliant to Check 21regulations
from the metadata. Further, these IRDs can include enhanced
features as described herein.
[0020] Referring to FIG. 2, a Check 21 IRD system 12 is configured
to create metadata files from scanned checks from a check scanner
14 and from digitally originated checks from a computer 16 or the
like, according to an exemplary embodiment of the present
invention. The present invention provides a digital payment file
(DPF) 20 which includes metadata associated with a Check 21 IRD. Of
note, this metadata does not include the physical image, and
accordingly can be stored efficiently. The present invention
provides systems and methods to generate an IRD image with perfect
quality and other enhancements as described herein.
[0021] The check scanner 14 is a device configured to efficiently
scan front and back images of physical checks. In an exemplary
embodiment of the present invention, output of the check scanner 14
is converted from an image into metadata stored in the DPF 20. This
provides financial institutions the opportunity to store raw data
as opposed to image files when scanning either the IRDs or original
paper checks. Of note, the metadata can be utilized at any time to
create a perfect Check 21 IRD or to provide an Image and Cash
Letter file compliant to Check 21 specifications, such as ANSI
X9.180. Additionally, the computer 16 or 17 can be utilized to
digitally originate a check. A digitally originated check (DOC) is
a check which is created electronically and which is fully
compliant to the Uniform Commercial Code (UCC) and Check 21. The
present invention contemplates the usage of metadata in the DPF 20
for any valid payment format, including Automatic Clearing House
(ACH), credit card, and the like transactions.
[0022] The digital payment file (DPF) 20 includes payment
instructions 22, a transaction identifier 24, audit information 26,
and security information 28, according to an exemplary embodiment
of the present invention. The DPF 20 represents a digital payment
from a payor to a payee, and can include any form of payment along
the various financial payment rails, e.g., check, ACH, credit card,
and the like. The DPF 20 is created and stored electronically based
upon inputs from the check scanner 14, computer 16, and the like.
The DPF 20 is stored in a data store 18 which can include a bank of
redundant file servers, network file storage, and the like. The
data store 18 can be part of a larger electronic payment system
(EPS). For example, the EPS can include a data store, processor,
and network interface all configured to interact with users, check
scanners 14, computers 16, and the like for creation, distribution,
and processing of the DPF 20.
[0023] The payment instructions 22 can include instructions for
"whom to pay" (payee name, phone number, email address, or the
like), some value amount (input as a decimal number of some
currency), the payment issue date, the bank account number from
which the payment is to be drafted (traditional checking account
number and American Bankers Association (ABA) bank routing number),
along with some potential set of conditions, limitations, or
restrictions, along with memo field description details, and
potentially some type of conditional acknowledgements which are
defined to be business rules governing how and when the payment
should be made (i.e., putting a contract on the back of a check,
thus cashing the check is endorsing the contract).
[0024] With regards to the check scanner 14, the payment
instructions 22 can be generated from an Optical Character
Recognition (OCR) mechanism after a physical check is imaged.
Further, the payment instructions 22 can be received from a human
operator, such as when the operator physical inputs a courtesy
amount from the paper check into a system. With regards to the
computer 16, the payment instructions 22 can be electronically
received from the computer 16, such as through the EPS.
[0025] The transaction identifier 24 is a globally unique
identifier (GUID) which is a unique transaction identification used
to identify a specific payment within the DPF 20. The GUID is a
special type of identifier used in software applications in order
to provide a reference number which is unique in the context for
which it is used, for example, in defining the internal reference
for a type of access point in a software application, or for
creating unique keys in a database. In the present invention, the
GUID is sufficiently large to avoid object collisions, i.e.
duplicate numbers, and it utilizes an algorithm to ensure GUIDs
cannot be easily spoofed.
[0026] The GUID or other secure transaction identifier could be
used in order to negotiate or cash an IRD generated from metadata.
These identifiers utilize a generation algorithm with multiple
inputs, and therefore a counterfeiter requires access to these
inputs as well as the algorithm to generate valid identifiers.
Advantageously, this makes it difficult for external counterfeiters
to reproduce them and create fake IRDs. This eliminates the "fake
IRD" problem. Any Adobe Photoshop user can alter a valid IRD image
or generate their own fake IRD image and make it payable to
themselves if they have access to either the original IRD image or
to valid account data. Thus, the existing Check 21 ideas are weak
because any hackers with Photoshop can create a valid image. The
metadata and IRD generation mechanisms of the present invention do
not have this Check 21 weakness via this IRD security method. The
GUID or transaction identifier could be used to verify an IRD
before it is accepted for deposit. For example, this could include
a verification service which is configured to look up the
identifier to show validity.
[0027] The audit information 26 includes the history for an audit
trail of the DPF 20. Since the DPF 20 is an electronic item, it can
be tracked real-time. The audit information 26 can include
timestamps and associated actions, such as creation, notification
of payor, payor actions associated with the DPF 20, and the like.
For example, the EPS can be configured to track, i.e. record and
monitor, all interaction with the DPF 20.
[0028] The security information 28 includes mechanisms designed to
protect the DPF 20 from fraud, counterfeiting, and tampering. The
security information 28 can include Public/Private Key
Infrastructure (PKI) and Certificate Authority (CA) verification,
cryptography, steganography, transmission security such as Secure
Socket Link (SSL) and Virtual Private Networks (VPN), secure
hashes, and the like. Additionally, the security information 28 can
include payee and/or payor notification and authentication
requirements, such as a unique Personal Identification Number (PIN)
for each DPF 20, additional levels of credentials (e.g., unique
account number and login ID into the EPS), private digital security
signature key (e.g., using a public key cryptography system), and
the like.
[0029] The security information 28 can further include digital
security features, such as digital watermarks, stenography, and
cryptographic features that can be applied to the "bitmap" sent out
to DPF 20 image recipients. These features apply when the DPF 20 is
converted to a paper item, such as a substitute check, or an
electronic representation of a paper item (e.g., an email with an
image of the substitute check). These features can be used to
validate that the check was not altered through the system 12. Some
Digital Rights Management (DRM) features could even be "Image
Survivable" meaning that they exist after an IRD printing and
subsequent scanning back into an image (e.g., barcodes).
[0030] In an exemplary embodiment of the present invention, the DPF
20 represents metadata associated with a truncated check, such as
from the check scanner 14, or from a DOC which is compliant to
existing Check 21 paper and electronic clearing methods. These
check clearing methods can include a substitute check or Image
Replacement Document (IRD) compliant to ANSI X9.37 draft as well as
X9.140 IRD final standard, or an Image and Cash Letter Format file
compliant to X9.180 standards. The DOC is referred to as digitally
originated due to the computer generation of the DPF 20 by the
computer 16 to distinguish it from the traditional scanning of a
paper check which could be called manual or "paper origination" of
a check image.
[0031] Referring to FIG. 3, a generated enhanced IRD image 40 is
illustrated according to an exemplary embodiment of the present
invention. In an exemplary embodiment of the present invention, the
DPF 20 of FIG. 2 can be used to generate the X9.140 standard
"substitute check" or IRD which results in a paper version of the
original check. Note, this paper version of the IRD is the legal
equivalent of a physical check under Check 21.
[0032] In the case of a digitally originated check (DOC), the IRD
image 40 can be printed by a payee and taken into their bank for
deposit because it contains a full set of warranties and
indemnities based on the original contract agreed to by the payor
and payee which is required to be signed in order for the DOC to
sent or received. Because DOCs are covered under this contract,
they have a full set warranties and indemnities that are acceptable
to both banks of deposit and downstream clearing banks. This DOC
feature, possessing a "full warranty" state, differs from other
attempts by either businesses or individual consumer users who want
to print their own IRD documents and deposit them at a bank because
those documents will not be accepted by the bank of first deposit
(BOFD) due to the depositing bank's inability to take on
un-transferable risk from an unknown originator of the IRD.
[0033] The IRD image 40 is formatted similar to a standard X9.140
IRD including a standard check front 42 with a "signature" area 44
in one of many forms; either a human digitized signature, or an
e-signature compatible form, or a secure hash produced by a private
key digital signature and a standard check back 46. Additionally,
the image 40 includes a Magnetic Ink Character Recognition (MICR)
line 48 and a legal legend 50 as required by Check 21. Further, the
IRD image 40 can utilize the X9.140 "optional data" area to include
processing and routing information 52 associated with the EPS, a
two-dimensional barcode 54 to facilitate faster processing and
security, a GUID 56, and customer service information 58. The
routing information 52 can be used by itself or in conjunction with
the GUID 56 to allow the EPS to track and perform other functions
with the IRD image 40. Using 2D standards such as PDF417, the
barcode 54 can store up to 2000 bytes of information which can be
used in conjunction with a barcode reader to automatically recover
all of the information associated with the IRD image 40. The GUID
56 provides the unique transaction ID associated with the IRD image
40 and the corresponding DPF 20. Finally, the information 58 can be
used by banks and others to assist with issues or questions related
to the IRD image 40.
[0034] The GUID 56 is a large, algorithmically generated, unique
number. The mechanism uses a given a set of inputs as seed values
and then generates a 16-byte (128-bit) number which is generally
considered to be unique among all users at any time, everywhere on
the planet. Using GUIDs 56 as either hidden or visible check
numbers ensures that the EPS knows which DPF 20 has been issued,
cleared, etc. and facilitates tracking the check anywhere, anytime,
electronically or by IVR (phone) or human lookup. This is unlike
pre-printed check numbers as they are generated on the fly at DOC
creation time. The GUID 56 can also serve as an EPS Transaction ID
(Tx) to find/locate a specific check within all the checks. GUIDs
56 can also be captured and stored inside the PDF417 barcode
embedded on an IRD or check image for automated IRD processing.
[0035] The present invention provides IRD images 40 with superior
quality and characteristics. Using a traditional scan of a paper
check, a high speed reader/sorter machine takes a picture of the
front and back of a check. Several errors are introduced during
this mechanical paper handling process which impact further
electronic processing of the image and subsequent Check 21 item.
Due to inherent mechanical and optical system design defects, any
mechanical paper handling process is subject to jams, miss-feeds
and misalignments of the paper which result in either missing
images or bad quality images (blurry) or miss-aligned images
(alignment measured as degrees off or away from a horizontal
axis--called skew). The impact of these scanning flaws, while rare
on a percentage basis, occur so frequently in the huge volume of
paper checks that the Federal Reserve system has mandated the
adoption of an "Image Quality Assessment" (IQA) test before they
will accept and process a set of Check 21 images from any bank.
Thus the IQA tests are designed to identify and reject images which
do not conform to both the Check 21 standard overall as well as the
specific "readability" or "legibility" OCR tests that the banking
industry has agreed are minimum image requirements. The present
invention can be utilized to minimize these flaws or to limit them
solely to the initial scanning with the check scanner 14.
[0036] The digital generation of the IRD image 40 from metadata
creates none of the traditional paper image quality errors. Also,
there is no resulting image skew from a non-existent horizontal
axis based on the edge of the paper as is seen with a scanned
image. The IRD image 40 is always generated with zero degrees of
skew in the image because it is built from the metadata in the DPF
20, and not a stored image. Next, the IRD image 40 has perfect
image quality as measured by industry standard Image Quality tests
which is independent of dpi resolution due to the fact that a pure
black and white bitmap is generated from metadata and not from a
scanned paper item (which results in noise being introduced by the
surface of the paper item). With the IRD image 40 there are no
stray black noise elements, only the exact letters, numbers, fonts,
and graphics which are present. The metadata instructions generate
individual black bits in the bitmap. Because the IRD image 40 files
have perfect image quality (pure black and white with no random
image noise), and have zero degrees of skew (i.e. they are
perfectly aligned to the horizontal axis of the image file), they
are always readable by both humans and computers using the lowest
dpi image resolution form of Check 21. Thus, this enhanced
readability reduces the chances of OCR errors of the Courtesy
Amount Recognition (CAR) and Legal Amount Recognition (LAR) fields
if the check image is scanned by banks who still handle paper IRDs.
Finally, the well known industry problem of background image
"interference" (this generically is called the "puppy and kitty"
problem due to the wide spread existence of these type of
background images on many consumer checks) is also avoided because
the IRD image 40 does not contain any background data.
[0037] Further, current Item Processing, check sorting, and
encoding methods require the imaging system to validate and compare
the Courtesy Amount box with the Legal Amount field and use OCR to
determine the Amount to Pay. These algorithms are not perfect and
they can mistake a handwritten "7" for a "1" for example. These are
called substitution errors and banks want to keep these errors as
low as possible to ensure that the encoded amount on the MICR line
is correct and that their systems are in balance. Having OCR errors
forces banks to keep human operators around to compare by hand
these amounts and correct these errors. Advantageously, the IRD
images 40 can be generated from digital instructions, i.e. the DOC,
so if they person types a "7" they will get the image of a "7" on
the digital check image.
[0038] Because the IRD image 40 is generated from metadata, it can
be generated in many forms. First, the IRD image 40 can be
generated in many resolution levels (measured as dots per inch or
dpi) which are independent of the chosen bitmap format, such as
JPEG, TIFF, PNG, and the like. Second, when the IRD image 40 is
generated by the EPS, it can be generated to include optional data
such as human signatures for easier processing in paper form. This
optional or conditional data (on the front or back) can include
instructions from the payee or depositing bank about depositing or
clearing features of the specific payment. Examples of this include
merging a "human digitized signature" 44 as the authorized
signature directly into the back (or front) image of the check,
even though it was never printed or signed (using the e-signature
laws). Note that this "digitized signature" feature works if the
payor or payee has uploaded samples of their human signature or
other handwriting samples (ex. Agreed and Accepted), or they could
choose to use a font that displays in "handwriting" format to
simulate their human signature--any of these could satisfy the
e-signature law as their authorized legal signature. Another
example includes a "for deposit only" style stamp 60 for the back
of the check, an account number for the deposit 62, or other
contractual restrictions (such as agreement to a contract if the
check is deposited) that are required by certain business processes
or agreements. Thus, the image 40 form of the DPF 20 can contain
valuable, optional data in both machine and human readable form
without requiring paper processing. This further automates the
processing and handling of checks and speeds up the overall
business process between payor, payee, and the banking system.
[0039] The IRD images 40 are created from "instructions to pay"
metadata which are similar in features to a "vector image file" vs.
a "raster image file". The benefits of using metadata (like the
equations describing a vector) to generate IRD image 40 is that it
provides flexibility in how the image 40 is generated. For example,
under X9 standards for image exchange between banks without
agreements, a Check 21 image is required to be a Black and White
(B/W) TIFF image saved at a low resolution of around 200 dots per
inch. Using the present invention, the EPS can generate IRD images
40 in a variety of formats such as small X9 B/W images which
reduces the file size of the DPF 20 or as a high resolution JPEG
images using a grayscale format for enhanced readability or
clarity. Dynamically creating the "check image" gives you
flexibility and choices which are suitable to the requirements of
the final use or format. Thus for storage, the IRD image 40 can be
made as small as possible given the amount of check data that must
be displayed. This is useful for banks storing large numbers of
check images. Additionally, the IRD image 40 can include low
resolution image versions for creating IRDs and high resolution
used for customer statement presentment or online viewing. An EPS
can also produce IRD images 40 at whatever resolution (or
format--TIFF, JPG, PNG, etc.) is needed by the requesting system
for storage or printing. The DPF 20 record does not contain an
image, only instructions to pay, thus any image type can be
generated on the fly as needed. Also, the DPF 20 is very small
(e.g., a few hundred bytes vs. a few hundred kilobytes for an
image) which can be stored very inexpensively and converted into
larger formats for different purposes. This eliminates the need for
banks to use check image storing services such as ViewPointe.
Instead, when needed in the future, the IRD image 40 can be pulled
back into the bank to be used for customer statement processing,
dispute resolution or legal evidence, etc.
[0040] Similar to "electronic endorsement" features, using metadata
and other digital technologies, any bank department or receiver of
the DPF 20 can automatically sign or endorse the check for
processing and clearing after the check represented by the DPF 20
is deposited. This idea covers the bank stamps, time stamps and
automation tracking features used to update the Check 21 item
throughout its lifecycle. Using these concepts, the EPS can
generate the IRD image 40 showing who signed the check, when it was
deposited, how it was deposited or notify a payee that the item is
a item returned under NSF rules, etc. The EPS updates the audit
trail in the database of the DPF 20. The generation of multiple
image forms utilizes a concept of an "image overlay" to add layers
of digital stamping to the back of a check. This is not
manipulation of the existing image, but instead generating each
stamp in its own image layer one at a time by providing an "image
overlay" layer on top of the existing back of check image 46. Note
that at DPF 20 creation time, the back of image 46 is a blank image
of a check back. Other unique elements of this feature are the idea
of having room for "more than one" signature when multiple
endorsements are needed or used, such as a third party check turned
over to a store. Only the last signature is shown on the back of
check image 46, others are kept on file in metadata, or a statement
can be added saying "signature is on file" and produced as needed.
The same idea can apply to bank processing of DOCs, their "stamps"
can be digitally added and only the last one is shown if desired or
if no room or if illegibility would be created by stamping over top
of each other. For example, the most recent image can be kept in
the display, but all other images are on file. Also useful for NSF
checks to explain why the item was returned. Check 21 provides for
items returned as NSF, but the present invention makes it clear to
all parties what occurred and when no matter how many back and
forth attempts were made to cash the check. Another benefit is the
franking features are always clear and readable, thus there is no
need for a "high resolution" image of the back of the check.
[0041] Existing IRDs take the Check 21 image "as is" and embed it
onto paper. Thus one IRD may be printed, then rescanned and
reprinted over and over for a remote clearing bank that uses a
chain of correspondent banks to clear their checks. This results in
the "copy of a copy of a copy" problem where both image quality and
skew can be introduced at each copy iteration. But, using metadata
instructions to generate a Check 21 compliant image, the present
invention allows each IRD image to be an electronically generated
IRD. This means there is no skewing of the image and the layout on
the IRD form is correct. The present invention cannot compensate
for printer alignment or paper issues which must be corrected by at
the point of printing, but the image of the IRD is perfectly
formatted and oriented with zero degrees of skew relative to the
horizontal line of the IRD boundaries. Further, the present
invention can also "re-hydrate" the IRD back into an electronic
image cash letter file without scanning to eliminate the
introduction of errors when IRDs are printed.
[0042] In another exemplary embodiment of the present invention,
the IRD image 40 could have enhanced features not shown by the X9
standards, such as when formatted or printed as an IRD, the back of
the check will be upside down above the front side of the check
with instructions for folding and cutting to make a standard paper
check. This orientation allows a "fold" dotted line to go between
the two images, plus a "cut here" dotted line above the back of the
check. The resulting cut & folded image is a perfect, one-step
printed item that generates an "item processing" capable check,
i.e. something that can be run through the IBM 3890 check sorting
machine as is and it works just like a paper check. The back/front
may be taped on the sides if needed to reduce any "gap" from having
two pieces of paper back to back. Also, the IRD image 40 can tell
customers how to do this or the Document Preparation Table within
the Item Processing department can easily do this before sending
the printed IRD image 40 into the sorting machine.
[0043] The present invention provides "add-ons" to the IRD image
40, and existing Check 21 IRD specification allows extensions
(i.e., room for optional parts) for new business methods or
systems. For example, the present invention can add new concepts
onto the IRD image, such as instructions to call 1-800-verification
for the customer or bank teller to call for self-service IRD
verification, or use the barcode 54 on the check (e.g., PDF 417, or
United States Postal Service--USPS) to "verify and pull" the check
back into the BOFD, security hashes, or other ID verification data
on the sender or receiver. Note, the 1-800-verification could be
tied to a strong "brand name" to facilitate customer awareness of
who the IRD issuer was so that it can not be easily spoofed with
Joe's ACME IRD branded concept. Banks can subscribe to the
1-800-verification service and using phone touch tones punch in
their account number and code, then the IRD GUID 56 value, which
the verification system uses to validate that the bank is real and
then lookup the check in the DPF using the GUID. Then, the
interactive voice response (IVR) service can tell the user if the
IRD image 40 is real, and optionally who the payee should be (a
secondary validation feature of the 800 # service). The barcode 54
can be used to automate this process--just scan it and the user
avoids the IVR touch tone data entry step. Alternatively, the bank
teller could use a website to enter in the GUID 56 or Tx ID and
verify the IRD.
[0044] Additionally, the IRD image 40 can include an extended the
IRD layout to create space for a Notary Public stamp and a line for
their signature and ID number 59, along with instructions that the
depository signature is witnessed to be a valid endorsement of the
IRD for payment. These optional areas on the IRD layout for the
text/notification can be used such that the IRD is witnessed by a
notary for the payment to be paid. For example, areas outside the
IRD layout can be used for the notary stamp and signature/ID
disclosure line.
[0045] Traditionally, IRDs are printed in the "portrait" mode on a
printed 8.5 by 11 inch piece of paper. Optionally, the present
invention could create the IRD image 40 using the "landscape" width
(i.e., longwise using the 11 inch orientation) instead of the
traditional 8.5 inch orientation. Using the extra "horizontal"
space, the present invention could add additional Magnetic Ink
Character Recognition (MICR) line fields, or barcodes 54, or
transaction codes, or audit or fixed codes, etc and the like. The
Item Processing department could scan the IRD lengthwise and get
standard MICR line data along with the additional data on the
enhanced landscape mode IRD. This adds value to allow the other IRD
enhancements (barcodes 54 or long GUIDs 56) to be easily placed on
the IRD versus the traditional layout.
[0046] Referring to FIG. 4, a DPF operational scenario 70 provides
an exemplary embodiment of generation and processing of DPFs. The
DPF metadata is generated (step 72). As described herein in FIG. 2,
the metadata for the DPF can be generated through a scan of a paper
check as part of a check truncation process, through generation of
a digitally originated check, or through any other process. Of
note, the DPF is not an image file, but rather metadata describing
a payment instruction. The present invention utilizes the metadata
to generate an IRD image file, when needed, or to transmit the
metadata as an Image and Cash Letter File bundle, and the like when
needed.
[0047] The DPF is stored (step 74). As described herein, the DPF
takes up significantly less space than a raw image file since the
DPF is solely data, and not an image. The storage step can be done
by a bank during the check truncation process, by an individual
creating a digitally originated check, or the like. The DPF is
transmitted (step 76). Here, the metadata is transmitted in some
form or fashion. This can include sending the metadata to a payee,
sending it as a bundle to a clearing bank or clearing house, or the
like. Alternatively, the transmitting step can be omitted. The idea
here is that the check, whether a truncated paper check or a
digitally originated check, is now in electronic form as metadata
compliant to Check 21 truncation regulations.
[0048] The present invention includes a full set of warranties and
indemnities applicable to banks of first deposit (BOFD) and
clearing banks. These warranties and indemnities are associated
with the metadata, and are agreed to by a payor and payee
associated with the truncated check. The idea here is to create an
agreement by which payors and payees accept before utilizing
digitally originated checks. With regards to check truncation by
banks and other financial institutions, these warranties and
indemnities are already in place under Check 21 truncation
regulations.
[0049] The IRD image or associated DPF metadata can be transmitted
in any form as is known in the art. For example, it can be sent as
an IRD image via an embedded JPEG or other image type in an email
message. When the payee opens their email, the payee is presented
with an "image" of a check in IRD form. The user prints the email
and takes it into a bank for deposit. Note, the image can include
an optional barcode, and it is in the form of an IRD X9.140 file.
Therefore, the image is a valid IRD and the bank accepts it based
upon the contract between payor, his system, and payee to extend
the rights and responsibilities under Check 21 to all parties.
Additionally, the check image does not need to be in IRD format to
be processed electronically. This can be accomplished using a
custom MIME type to handle the check image viewing within the email
program as way to notify the computer than a "check" has arrived
and not a random graphic picture or image, i.e. using a MIME type
there is an intelligence that is conveyed or created when you
generate an image that you (the originator) know to be an "item of
value" (money). This concept is similar to the difference between
the actual object and a picture of the object. A custom MIME type
handler is used to attach the check to an email as this notifies
the OS or email program that this is a special object that has
value (i.e. a check). This can include a "thumbnail" image to show
recipients that a valid check image is attached, such as in
encrypted form. Additionally, a PIN could be required to secure the
decoding of the image via a symmetric key (sent via SSL).
[0050] Also, the IRD image or associated DPF metadata can be sent
as an encrypted file. The EPS system (thick client or website) can
use a shared PKI infrastructure (built for example by either the
EPS or by a third party Electronic Payments Clearing House or EPCH)
to generate the IRD image or associated DPF metadata, then grab the
payee's public key to digitally sign (or encrypt) the IRD image or
associated DPF metadata into an automatically generated but
encrypted file so that only the recipient/payee can open the file
using their private key. The encrypted payment is transmitted to
the recipient/payee as either an attachment to or directly embedded
within a well known file format such as an Adobe PDF file. Note
that the recipient has to previously register with EPCH to generate
the PKI key pair (storing the public key online, and the private
key offline) and that private key is required to be installed on
any machine where the encrypted PDF image is opened. This is a
simple, low cost "client side" security model that leverages the
free and widely-available Adobe Reader client or other such free
client software viewing program that accepts secure or encrypted
files.
[0051] Next, an image is generated from the DPF (step 78). The
image includes a fully-compliant IRD image as required by X9
standards. The image can be provided in various mechanisms, such as
email, text message, web link (URL), secure PDF file, facsimile,
and the like. At this point, the IRD image can be printed and
utilized as a fully-compliant IRD. The IRD can be printed by a
payee and taken into their bank for deposit because it contains a
full set of warranties and indemnities based. These full set of
warranties and indemnities are based on a contract agreed to by
both the payor and the payee which the EPS requires to be signed in
order for a digitally originated check to sent or received. Because
DOCs are covered under this contract, they have a full set
warranties and indemnities that are acceptable to BOFDs and
downstream clearing banks. This novel digitally originated check
feature, possessing a "full warranty" state, differs from other
attempts by either businesses or individual consumer users who want
to print their own IRD documents and deposit them at a bank because
those documents will not be accepted by the BOFD due to the
depositing bank's inability to take on un-transferable risk from an
unknown originator of the IRD. This scenario is contemplated where
an individual or business does not have an existing two-party
private warranty contract with their bank which is a concept
allowed for under existing UCC law. Also, under the Check 21
regulation as it exists today only banks can truncate checks by
imaging them and later extend their warranties to subsequent
clearing banks in either electronic or IRD form.
[0052] The DPF can be printed to create an IRD or a paper check.
The digital check image and metadata are applied to the IRD layout
and X9.140 specification to create a valid Check 21 item.
Traditionally or by convention, an IRD was only created by scanning
a paper check, this item covers the translation or transformation
of the DOC metadata and image to the IRD format (different than a
scanner doing it). That is, the present invention does not scan a
paper item to create an IRD, but rather scans a paper item to
generate metadata or inputs data from a digitally originated check
to have a meta-data driven IRD.
[0053] In one exemplary embodiment, the IRD is printed from a DPF
on a printer from a browser image. The metadata instructions
include instructions how to generate a perfect check image and a
perfect IRD layout (i.e., no skew, etc.). These get blended into a
single JPG or the like image that is downloaded to a local browser
client, the user sees the JPG, and selects "print" on their local
computer to print the JPG, which is in the format/layout of an IRD.
The paper output is a valid IRD and can clear using normal IRD
process. In this scenario, the browser image can include simple
security controls via JavaScript, a browser plugin or the like.
[0054] In another exemplary embodiment, payees can be locked-out
from printing multiple checks through browser controls. For
example, a system registers a misprinted check as "cancelled," and
the payee agrees in writing (e.g., check a box, etc.) than the
misprint has been destroyed. Replacement checks (i.e. through
metadata) are re-issued with completely new sets of tracking and
identification numbers, codes, etc. This same agreement restates
federal and state check fraud statutes. This feature may require
client side code, ActiveX, or other software features. Optionally,
this could include a secure printer driver injection tool to hook
the print spooler. Also, these mechanisms could also utilize known
security techniques to provide decryption of the DPF for security
and verification.
[0055] For businesses and others with high volume IRD deposit
requirements, such as lockbox services and the like, the present
invention can utilize a magnetic stripe for quick data scanning of
the IRDs. When enhanced IRDs enabled by the present invention are
created by a remote, high volume IRD printing facility such as
offered by Fiserv and the like, they could be printed onto special
IRD stock that includes the magnetic stripe. The stripe could be
used to encode all of the DPF metadata, including GUID, amount,
date, payee, etc. Scanning the stripe eliminates the need to scan
the entire IRD, thus further automating IRD processing for
banks.
[0056] Additionally, printed IRDs can include additional items,
such as barcodes, 1-800-verification numbers, and the like. These
items can be used by the BOFD to provide greater confidence that
the IRD is legitimate. Further, in the case of an electronic
deposit, e.g. forwarded as metadata, bundled as an Image and Cash
Letter file, the BOFD can also have greater confidence that the IRD
is legitimate. The present invention contemplates electronic
verification methods to verify the IRDs, i.e. utilizing the GUID or
transaction identifier to determine validity over a verification
system. This reduces liability by giving the BOFD enhanced
confidence when receiving the IRD as opposed to conventional Check
21 items. Advantageously, the present invention allows a greater
audit trail or liability chain of custody to be
presented/inspected/known at all times, thus increasing check
confidence.
[0057] Current Check 21 processes (i.e., paper scanning and IRD
creation) can allow both the paper check (i.e., as an image) and
the check as an IRD to be processed, causing double drafts for the
same payment. The banks have to watch for this error and constantly
trial balance their systems. Using DPFs, there is no need to track
this, the present invention only authorizes DPFs one time, thus
avoiding a double debit. Even if an IRD is made and the electronic
DPF is deposited, the present invention only honors the first item
through the system. The second will be blocked or marked returned
and not paid, i.e. using a Positive Pay Database PPD enabled by the
present invention helps ensure this. Existing Positive Pay systems
may not capture this because both the IRD and the paper check are
appear to be valid items and therefore a PPD would say "yes" to pay
them. The present invention sees that the first item has processed
and thus does not allow the second item (IRD or electronic) to
clear--only paying one time.
[0058] In another exemplary embodiment of the present invention,
the DPF can be pushed into a bank through remote deposit of a cash
letter file. This is very useful for a non-image enabled bank that
would normally be forced to accept an IRD and forward the paper
item. Whenever a paper IRD is deposited by an account holder to the
bank, the bank can choose to be "item processed" without scanning
if they ask for an X9.180 image file be forwarded on their behalf
from the DPF. The BOFD (depositing bank) can request that a cash
letter file be generated from the IRD (e.g., via the GUID 56) and
be sent to the clearing system on their behalf. For example, the
EPS holds the DPF and can be directed by a depositing bank to
forward to a clearing bank in electronic form via check 21 image
exchange networks. The digital check image and cash letter file is
transmitted to the bank for deposit and the bank can forward it on
to their clearing house of choice. If the bank does not accept
check 21 images, it can forward it on to the Federal Reserve on
their behalf and credit the depositor's account. The remote deposit
service could integrate both conventional remote deposit features
(e.g., ACH or cash letter imaging) along with remote deposit of a
digitally originated check. This feature is the process that takes
both types and prepares a file of mixed items to be remotely
deposited (i.e., paper check images and DOC images).
[0059] Advantageously, IRDs from DPFs can be "re-hydrated" from
paper items back into electronic items without scanning. IRDs do
not have to be used to "clear" a check, the metadata in the DPF
lives in digital form all of the time. Thus the IRD can instruct
the bank teller or customer to "pull" the item into the bank
electronically (e.g., website, 800-checkme, barcode scanning,
etc.). This saves time, money, and can eliminate the need to scan
an IRD altogether. "Re-hydrating" a DPF can be done easily and
makes it instantly digital again, quickly and easily, just tell the
EPS where to send it and the electronic item file is sent. The
forwarding and depositing of DOCs is done in an X9.180 electronic
form into a depositor's bank. A DOC is first created as the first
step in the check creation process. The digital check image and
cash letter file is transmitted to the bank for deposit and the
bank can forward it on to their clearing house of choice. If the
bank does not accept Check 21 images, we can forward it on to the
Fed on their behalf and credit the depositor's account or the
system can convert it to ACH for deposit.
[0060] Additionally, another element of the present invention is
the fact that enhanced IRDs could be utilized as traveler's checks
via a UPC barcode with a fixed value amount. This allows for easy
cashing of IRDs at grocery stores; when a DOC is created, the user
selects "travelers check" format, and a UPC code would be added
with a SKU number containing the EPS GUID+the value amount
(pre-printed/fixed) embedding the SKU onto the IRD. The cashier
would scan the IRD like a coupon using the UPC barcode, and the
"amount" would be deducted from your check out bill. The store
could cash the IRD at their bank just like a travelers check. This
idea makes the enhanced IRDs as Travelers Checks useful and
tradable because people can easily spend them at a grocery store or
other merchant who has POS scanning equipment. The UPC barcode on
the IRD makes them easily processable by the store--easy to accept
like a coupon, easily verified and tracked but they clear like a
check.
[0061] For payees without local printing capabilities, the present
invention contemplates a remote or third party IRD
creation/printing service. This feature allows a payee who receives
the DOC but who does not have a printer to "print" a valid Check 21
IRD item for pickup. When a user of the present invention walks
into a bank (or Western Union or other "check cashing" service,
e.g.) they only need to know basic IRD data to allow the bank or
service to retrieve the IRD. Because it is an enhanced IRD, it is
guaranteed to be a valid IRD so it will be easily accepted (due to
the fact that it has a contract covering the bank's liabilities
this allows a transfer of warranties). The bank or service
processes and validates the IRD as previously described by the
invention allowing the remote IRD to be cashed and cleared through
the system. For example, the remote service can retrieve the DPF
metadata, such as through the GUID, and generate a valid IRD under
X9.140. Further, the user could even walk in to a bank with only a
crude JPG of the IRD--as long as the printed image has the GUID, it
can be converted back into a valid IRD. A remote IRD can also be
created by a remote kiosk or store using a website, a user would
enter in their authentication (account ID) and tell the system the
GUID and it would generates the IRD (or cash letter file) for you
at the kiosk or store.
[0062] Another exemplary embodiment of the present invention
demonstrates the dynamic image generation nature of IRD which can
facilitate a set of enhanced "back of the check" automation
features. This can be easily seen starting first at origination
time, when the back of the check image contains no data (it has a
blank back of check image), but subsequent processing of the DPF
can generate payee metadata used to update the back of the check
image. For example, the EPS can also include User Interface (UI)
screens for subsequent processing by the payee. Thus, after payee
acceptance of the DPF, the EPS can generate Check 21 images that
have been "franked" or stamped on the back with legends such as
"For Deposit Only", "Account number 12345 at Bank XYZ", "Agreed and
Accepted" and even multiple or subsequent payee endorsements--all
of which could appear separately or together in a coordinated
manner on the back of check image. Another example includes the
contractual restrictions (such as agreement to a contract if the
check is deposited) that are required by certain business processes
or agreements. Each stamped image is generated as a separate image
layer from metadata stored in the DPF at the EPS which can be
optionally or conditionally produced to generate the final check
image format used in settlement. This is a significant improvement
over the present systems where human or automated machines "stamp"
over top of each other, making the final cleared image unreadable
at times. The legibility and readability of the back of a check can
become a major focus of attention during any dispute or litigation
surrounding the payment settlement process--including who handled
the check, at what time, with what endorsements or stamps. These
are all areas that are easily handled by the EPS by generating a
series of images representing the back of the check state at
various points in time without images overlapping each other. Thus
payment disputes are easily settled.
[0063] With regards to paper checks which are truncated under Check
21, using existing processes, a paper scanning bank can leverage
all of the benefits of the DPF and the EPS if they use their
equipment to send metadata to the EPS in lieu of check images. The
banks existing IBM 3890 can be modified or extended with software
to extract data from the paper originated check (POC) via OCR and
then create a IRDs after the fact. This allows older banking
systems to be integrated into the EPS model to leverage the full
benefits of Check 21 along with unique metadata-associated features
of the present invention. Creating the DPF from a scanned paper
check requires OCR and validation of the data encoded on the check
including: value amount, identifying payee, and using OCR of MICR
line data to identify payor DDA and bank routing data. The actual
image can ride along in the DPF file, but the main point of this
invention is to create the "digital instructions to pay" metadata
concepts from the scanned paper item and store it within the DPF.
Once in the DPF format, all of the other benefits will accrue to
the bank.
[0064] Advantageously, DPFs can automatically be regenerated back
into digital form without scanning the IRD paper images. Unlike
traditional paper check items which are scanned and then printed in
IRD format, the DPF can be re-converted back into digital form at
any future date by using the unique transaction identifier (GUID).
The IRD check front or back image can be generated in many
resolution levels (measured as dots per inch or dpi) which are
independent of the chosen bitmap format, such as JPEG, TIFF, PNG,
or the like. Second, when an IRD is generated by the EPS, it can be
generated to include optional data such as a 2D barcode which
contains the DOC metadata for easier processing when it is
delivered in paper form. Third, it can include optional or
conditional data (on the front or back) which can be included in
the image file in order to inform and instruct the payee as well as
depositing or clearing bank about optional features of the specific
payment. Examples of this include merging a "human digitized
signature" as the authorized signature directly into the back (or
front) image of the check, even though it was never printed or
signed (using the e-signature laws). Note that this "digitized
signature" feature works if the payor or payee has uploaded samples
of their human signature or other handwriting samples (e.g., "John
Q Public"), or they could choose to use a font that displays in
"handwriting" format to simulate their human signature--any of
these could satisfy the e-signature law as their authorized legal
signature as well as a PKI certified digital signature. Thus, the
image form of a DPF file can contain valuable, optional data in
both machine and human readable form without requiring paper
processing. This further automates the processing and handling of
checks and speeds up the overall business process between payor,
payee and the banking system.
[0065] Another exemplary embodiment of the present invention
demonstrates the enhanced IRD capability that is facilitated by
DOCs and EPS. When IRDs are created by a remote, high volume IRD
printing facility, they could be printed onto special IRD stock
that includes a magnetic stripe. The stripe would be used to encode
all of the DOC metadata, including GUID, amount, date, payee, etc.
This automates IRD processing for banks. This idea is similar to
the airline boarding passes that have stripes for automated
clearing during passenger boarding process.
[0066] Referring to FIG. 5, an EPS system 80 is illustrated
according to an exemplary embodiment of the present invention. As
described herein, an EPS 82 is an electronic system configured to
interact with a plurality of users (i.e. payors and payees), banks,
and other financial institution to enable DPF generation,
distribution, tracking, authentication, security, clearing, and the
like. The EPS 82 is configured to communicate over a network 84 to
a plurality of payors 86, payees 88, BOFDs 90, clearing banks 92,
clearinghouses 94, and the like.
[0067] Generally, the EPS 82 is a computer system which can include
multiple processing elements, distributed memory, network
interfaces, external data storage 96, and the like. The EPS 82 is
configured with processing and data storage redundancy, and is
configured to communicate to the plurality of payors 86, payees 88,
BOFDs 90, clearing banks 92, clearinghouses 94, and the like. The
EPS 82 includes various modules, such as a User Interface (UI) 100,
DPF handling 102, IRD generation 104, transmittal module 106,
tracking module 108, authentication module 110, and processing
module 112. The UI 100 provides a mechanism for users 86, 88, 90,
92, 94 to create and distribute DPF files. Further, the UI 100 can
provide mechanisms for tracking, modification, clearing,
processing, security, authentication, depositing, reissuing, and
the like with regards to DPFs. Also, the EPS 82 can include
mechanisms for automating these processes without the need for
direct UI 100 access, such as with automated processing.
[0068] The DPF handling 102 module is configured to create, modify,
update, etc. of DPF files associated with specific checks. As
described herein, the DPF is a database record storing the metadata
instructions related to a check. The EPS 82 is configured to store
multiple DPFs in the data storage 96 or the like, and to enable the
plurality of payees 84, payors 86, BOFDs 88, clearing banks 90, and
clearinghouses 92 to create, transmit, receive, and process the
DPFs. The DPF handling 102 module is configured to create metadata
responsive to user input, through scanned check OCR, or through
automated processing. Also, the DPF handling 102 module manages
tracking features, audit features, and the like described further
herein.
[0069] The IRD generation 104 module is configured to create IRD
images with perfect quality such that they pass the stringent
Federal Reserve "Image Quality Assessment" (IQA) tests (see e.g.,
www.frbservices.org/Retail/check21TechInfo.html "Black and White
Image Standard and Quality Checks" document incorporated fully by
reference herein). The IQA procedures are a series of tests that
are performed on a Check 21 image file before they will accepted
and processed by the Federal Reserve clearing network. The Fed IQA
tests are also utilized by a variety of banks as their own internal
set of Check 21 images tests, thus ensuring image file
interoperability between any two banks. While the DPF can be
transmitted electronically, it can also be used to generate the
X9.140 standard "substitute check" or IRD which results in a paper
version of the original digital check. The IRD can be printed by
the payee and taken into their bank for deposit because it contains
a full set of warranties and indemnities based. These full set of
warranties and indemnities are based on a contract agreed to by
both the payor and the payee which the EPS 82 required to be signed
in order for the DPF to sent or received. Because DPFs are covered
under this contract, they have a full set warranties and
indemnities that are acceptable to BOFDs 90 and downstream clearing
banks. This novel DPF feature, possessing a "full warranty" state,
differs from other attempts by either businesses or individual
consumer users who want to print their own IRD documents and
deposit them at a bank because those documents will not be accepted
by the BOFD 90 due to the depositing bank's inability to take on
un-transferable risk from an unknown originator of the IRD. This
scenario is contemplated where an individual or business does not
have an existing two-party private warranty contract with their
bank which is a concept allowed for under existing UCC law. Also,
under the Check 21 regulation as it exists today only banks can
truncate checks by imaging them and later extend their warranties
to subsequent clearing banks in either electronic or IRD form.
[0070] The transmittal module 106 is configured to handle
transmission of DPFs between the various payors 86, payees 88,
BOFDs 90, clearing banks 92, and clearinghouses 94. As described
herein, each DPF includes a GUID as a unique transaction ID. With
the present invention, a bank teller could input into the EPS 66
through the UI 100 (e.g., a webpage or phone IVR system) the digits
from the unique transaction identifier (GUID) which can be found on
the IRD. This GUID input system is linked to the EPS 82 that
originally generated the DPF, and which allowed the payee to print
the IRD in the first place. The GUID value can be printed and found
on the front of the IRD in the Check 21 "optional data field"
location where it was placed during the IRD generation process.
[0071] Using the transmittal module 106, the teller at the BOFD 90
can request that the specific Check 21 item be re-generated as an
electronic image file and be sent back into the BOFD 90 for further
processing by the "Item Processing" department. To accomplish this
regeneration, the EPS 82 can use the teller supplied GUID value to
lookup and retrieve the specific metadata information that was
stored in the DPF system. As these re-creation requests arrive at
the DPF, the original metadata values (or the currently stored
values) are retrieved from the EPS 82 and used to re-create the
digital check file in X9.37 format for further image exchange
processing. This electronic X9.37 file can then be sent or routed
directly back to the BOFD 90 via a secure electronic link such as
the existing Federal Reserve System using the standard Cash Letter
File format. The ability to re-generate at will (or at any future
time) a fully compatible Check 21 digital image without scanning or
handling a paper IRD is a further unique element of the present
invention. The benefits of this feature are derived from the fact
that the auto "regeneration" process avoids the errors of paper
scanning and is a great benefit to banks in reducing the amount of
labor involved in handling of paper items. Thus, there is no need
to scan an IRD submitted for deposit in order to generate the front
and back check image in standard Check 21 format. The regenerated
image and data values can be generated directly from the EPS 82 and
sent back to the BOFD 90 in a standard Cash Letter File for further
image exchange processing.
[0072] The tracking module 108 is configured to provide real-time
and historical tracking of each DPF created and processed through
the EPS 82. The present invention allows the DPF to be generated
through the EPS 82 anytime with a full history and audit trail.
This is because the DPF is electronic and all interaction with the
EPS 82 can be recorded, monitored, and tracked through the tracking
module 108. Additionally, the DPF can still be processed locally on
paper as an IRD, or it can be recreated and sent into a bank
electronically at will. All of these concepts are based on the idea
that the DOC is built around the metadata "instructions to pay"
stored in the DPF, and the tracking module 108 can track the
various steps by recording data in the DPF. The tracking module 108
provides similar information as a shipment tracking feature, such
as with UPS. The DOC issuer can view real-time status related to
the DOC to determine when it is received (which can also tie to an
auto-notification feature), when it was cashed, if and when it is
endorsed to a third party, and the like. Additionally, significant
events related to the DOC can be pre-subscribed to auto notify when
they occur. For example, the payor can be auto-notified when the
DOC is cashed.
[0073] The authentication module 110 is configured to provide
security relative to creation and processing of the DPFs. For
example, the EPS 82 uses the GUID to lookup the DPF transaction and
determines how to authenticate the payee based on the
authentication level chosen by the payor when creating the DPF (or
setup by the payee as a condition for retrieving payments from the
EPS 82 under a specific name or ID). Authentication levels can
include nothing (i.e., just knowing the transaction ID or GUID is
enough security for the payor), having a unique PIN number for each
DOC, having additional levels of credentials (e.g., unique account
number and login ID into the EPS 66), private digital security
signature key (e.g., using a public key cryptography system), or
other levels of security agreed to by one or both parties and
supported by the EPS 82.
[0074] The processing module 112 is configured to allow payees 86,
payors 88, BOFDs 90, clearing banks 92, and clearinghouses 94 to
process and clear DOCs through the EPS 82. As described herein,
DPFs are identified through the GUID or the like. Once identified,
the processing module 112 enables forwarding or clearing of the
DPF. For example, the processing module can generate the electronic
image file and send it to the bank of first deposit for further
processing by the "Item Processing" department. As these
re-creation requests arrive at the processing module 112, the
original metadata values (or the currently stored values) are
retrieved from the system and used to re-create the digital check
file in X9.37 format for further image exchange processing. This
electronic X9.37 file can then be sent or routed directly back to
the bank of first deposit via a secure electronic link such as the
existing Federal Reserve System using the standard Cash Letter File
format. The regenerated image and data values can be generated
directly from the EPS 82 and sent back to the bank of first deposit
in a standard Cash Letter File for further image exchange
processing. Thus, this further demonstrates that any items produced
by the invention are built using a fully Check 21 compliant process
from electronic metadata (instructions to pay) stored in a database
(DPF) instead of scanning paper or existing check image data.
[0075] Although the present invention has been illustrated and
described herein with reference to preferred embodiments and
specific examples thereof, it will be readily apparent to those of
ordinary skill in the art that other embodiments and examples may
perform similar functions and/or achieve like results. All such
equivalent embodiments and examples are within the spirit and scope
of the present invention and are intended to be covered by the
following claims.
* * * * *
References