WO1997022060A1

WO1997022060A1 - Communication of images of electronic funds transfer instruments

Info

Publication number: WO1997022060A1
Application number: PCT/US1996/020358
Authority: WO
Inventors: Gerhard M. Warner, Jr.; Daniel Shutzer; Daniel R. Vermeire; William J. Krajewski; Jo Sander; Gene Rohrer; Phil Stanley
Original assignee: Financial Services Technology Consortium; The First National Bank Of Boston; Unisys Corporation; Huntington National Bank; Citibank N.A.; Lawrence Livermore National Laboratory; International Business Machines Corporation
Priority date: 1995-12-12
Filing date: 1996-12-12
Publication date: 1997-06-19

Abstract

A first electronic representation of a financial instrument (10) complying with a first protocol is created (62). The first electronic representation is converted to a digital delivery format complying with a second protocol (74). The digital delivery format is delivered over an electronic data communication network (52). This enables information concerning the financial instrument to be delivered over the network in a predetermined format. The invention may be generally applied to a financial instrument such as a check (20).

Description

COMMUNICATION OF IMAGES OF ELECTRONIC FUNDS TRANSFER INSTRUMENTS

Background The invention relates to communication of images of electronic funds transfer instruments.

As seen in Fig. 1, payment of a financial instrument 10 is normally effected when a first banking institution 12 presents the instrument to a second banking institution 14. The second banking institution authenticates the instrument and transmits payment 16 to the first banking institution. Presentment of financial instruments among banking institutions may also involve intermediate steps, such as routing the instrument through a clearing house 18.

When the instrument is a written paper check 20, as in Fig. 2, a payer 22 presents the check to a payee 24 during a transaction {such as a sale of goods or services) . The check indicates the name of the payee 26, an amount payable 28, a courtesy amount 29, the date 30 the check was created, the printed name of the payer 32, the name of the payer's bank 34, the number of the payer's account 36 at the payer's bank, the payer's signature 38, check routing information 40, and a MICR line 39 which is a magnetic coding of some of this information. Essentially, the check directs the payer's bank to remove the indicated amount 28 from the payer's account and to pay that amount upon presentment of the check to the payer's bank. The payee places his signature 42 on the back of the check and deposits the check with the payee's bank 44 with an instruction that payment be made to his account 46. The check is then routed to the payer's bank 34 through a clearing house 18, a federal reserve bank or other established clearing arrangement. This procedure for effectuating payment between banks is known as forward check presentment .

The payer's bank verifies the authenticity of the check and (at least for some checks) the signature 38 of the payer. If the check is authentic and the payer has sufficient funds in his account 36 to cover the amount of the check 28, the payer's bank debits the payer's account and transfers funds to the payee's bank m the amount designated on the check as payment 16. A check typically is considered authentic if it contains the signature 38 of the payer, the printed identification of the payer 32 and the printed name of the payer's bank 34, and does not appear to be altered. If the check looks authentic, the payee's bank provisionally credits the payee's account 46 for the amount designated on the face of the check 28 pending clearance, and acceptance and payment by the payer's bank. The payee's bank credits the payee's account when the payee's bank receives payment from the payer's bank. This procedure is known as check posting.

A complete check transaction thus includes verification steps performed by the payer's and payee's banks 34 and 44. Processing a paper check requires time as the physical check is routed from the payer, to the payee, then to a clearing house, federal reserve bank or the payee's bank directly, and finally to the payer's bank. The same is true of other types of financial transactions involving paper instruments, such as credit card slips generated during a credit card sale. In a credit card transaction, a merchant makes an impression of the customer's card, which the customer then signs, to function as a receipt for the transaction.

An important function of check processing relates to "exception" cases, such as a check returned due to insufficient funds m the payer's account. Since exception processing provides for dealing with a problem in the normal flow of a check through the system, the physical check itself may need to be seen in order to resolve the problem. In this case, the paper check is routed back to the payee's bank or the bank of first deposit .

Several mechanisms for using electronic communication to substitute for paper flow m financial transactions are m use or have been proposed. In particular, electronic presentment of checks is a mechanism used to aid m clearing checks collected by banks prior to or without routing the physical checks. Electronic Data Interchange (EDI) is an electronic transactional system m which funds are frequently transferred over existing financial networks.

Check imaging is an electronic transaction procedure involving the scanning of a paper check by a scanner. The scanner digitizes the image of the check pixel by pixel and stores the image electronically m a memory. The image may then be transferred electronically to substitute for or precede the physical delivery of the check, i.e. to truncate the clearing process. The image of the check also may be recreated on a computer monitor or on paper for verification by the appropriate banking institution.

Each bank may have its own system for capturing check images. A critical element of the interchange of check images is the ability to determine where and how an image can be obtained whenever it is needed. Summary

In general, m one aspect, the invention features a computer-based method in which a first electronic representation of a financial instrument complying with a first protocol is created. The first electronic representation is converted to a digital delivery format complying with a second protocol. The digital delivery format is delivered over an electronic data communication network. This enables information concerning the financial instrument to be delivered over the network m a pre-determined format.

Implementations of the invention may also include one or more of the following features. The digital delivery format may be converted to a second electronic representation complying with a third protocol . The third protocol may be the same as the first protocol. The second electronic representation may also be processed. The processing may include displaying an image of the financial instrument or printing an image of the financial instrument. The first electronic representation may be created at a first financial institution and the digital delivery format delivered to a second financial institution. (In this application, whenever we use the words financial institution we mean them to include "merchants" . ) The second protocol may be a protocol recognized m common by the first financial institution and the second financial institution. The first protocol may also include a proprietary protocol of the first financial institution. The second protocol may include a commonly accepted protocol.

The first electronic representation may include an image of the financial instrument or a digital codelme representation of the financial instrument.

The financial instrument may be a check or a credit card slip.

The first electronic representation may be stored for subsequent retrieval upon a request. The first electronic representation may be stored at a first financial institution. The request may be delivered electronically to the first financial institution from a second financial institution and the digital delivery format delivered to the second financial institution. The first electronic representation may be processed at the first financial institution. The processing may include displaying an image of the financial instrument or printing an image of the financial instrument. The request may be generated automatically. The first electronic representation may be assigned an identification index. The request may include the identification index.

The digital delivery format may be encrypted for secure delivery over the electronic data communication network.

In general, in another aspect, the invention features apparatus including a capture device for obtaining a first electronic representation of a financial instrument complying with a first protocol, a translator for converting the first electronic representation into a digital delivery format complying with a second protocol, and means for delivering the digital delivery format over an electronic data communication network.

Implementations of the instrument may include one or more of the following features. The first electronic representation may include an image of the financial instrument or a digital codelme representation of the financial instrument . The financial instrument may be a check or a credit card slip. The second protocol may be a commonly accepted protocol . The capture device may include a scanner. The translator may include an EDI translator.

A memory may be included to store the first electronic representation. A workstation may be included for processing the stored first electronic representation. The processing may include displaying an image of the financial instrument or printing an image of the financial instrument. The workstation may include an interactive display of the first electronic representation. In general, in another aspect, the invention features apparatus including means for electronically receiving a digital delivery format of a financial instrument complying with a first protocol, and a translator for converting the digital delivery format into an electronic representation complying with a second protocol .

Implementations of the invention may include one or more of the following features. The electronic representation may include an image of the financial instrument or a digital codelme representation of the financial instrument. The financial instrument may be a check or a credit card slip. The first protocol may include a commonly accepted protocol . The translator may include an EDI translator. A workstation may be used to process the second electronic representation. The processing may include displaying an image of the financial instrument or printing an image of the financial instrument . The workstation may include an interactive display of the first electronic representation.

In general, in another aspect, the invention features a method for truncating a paper check in a check clearance system by capturing an electronic image of the paper check at a first banking institution, the electronic image complying with a first protocol, converting the electronic image to a digital delivery format complying with a common second protocol, sending the digital delivery format digitally from the first banking institution to a second banking institution, at the second banking converting the digital delivery format to an electronic image complying with a third protocol, and processing the electronic image complying with the third protocol for clearance purposes.

Implementations of the invention may include the following feature. The digital delivery format may include a secure format created by encryption.

In general, another aspect, the invention features a method for use by financial institutions with respect to financial instruments including storing, at different financial institutions, electronic images of paper financial instruments presented to the respective institutions, the storing at different financial institutions being done accordance with different protocols, at each of the financial institutions, accepting electronic requests for copies of specified ones of the electronic images stored at the respective financial institutions, the requests being sent by any of the financial institutions via a common communication network, and at each of the financial institutions, responding to electronic requests by converting the requested electronic images to a common protocol and returning the images digital form to the requesting financial institution.

Implementations of the invention may include the following feature. The electronic requests may be generated automatically.

The invention relates to the communication of binary content images of funds transfer instruments between banks . Each bank wraps the binary content in the bank's own proprietary format. A transmitting bank packages the proprietary format containing the binary content with a standard message format. The receiving bank uses the elements of the standard message format to find and interpret the binary content for use or display. Advantages of the invention may include one or more of the following.

Many business functions could benefit from check image interchange, including signature verification and stop payment orders and/or payer information. The interchange of images m addition to the electronic interchange of check codelme data allows truncation to be possible.

The invention addresses the problem of check image interchange without physically exchanging paper checks. The invention provides an electronic communication alternative for check image transfer.

The invention enhances the electronic presentment of checks with the addition of check images. Critical business flows are rearranged and altered. The invention also provides a new way to implement check processmg to truncate the flow of paper checks. In addition, the invention provides a system for locating check images among the 15,000 banking institutions in the United States. Check images may be transported routinely or on demand.

The invention provides integration of existing banking systems to facilitate check processmg. The existence of these systems will allow for implementation and acceptance by the banking industry.

The invention to a degree electronically mimics heavily-used and well-understood existing paper check processes to enable it to be readily accepted by the banking industry. By retammg the basic characteristics and flexibility of, e.g., the paper check, the invention may be adopted more rapidly. Due to the similarity with exchanging paper checks, the invention can be used withm the structure of existing laws, regulations, and standard banking practices. Since the system can be fully automated, and new processmg can be done outside of existing applications, the cost of electronic check image interchange may be lower, and the costs of implementation minimized. To further minimize implementation costs, check image interchange may be integrated with the existing banking infrastructure, including some of the mechanisms currently used, such electronic presentation of checks.

The use of electronic check image interchange will be more cost effective than existing paper checks due to volume efficiencies and the automatic processing capabilities of computers. The use of electronic transmission is less costly than physically transporting paper. Banks may significantly reduce the costs of mailing and/or transporting paper checks, such as for envelopes, stamps, and incremental labor.

Other advantages and features of the invention will become apparent from the following description and from the claims. Description

Figure 1 is a block diagram of a financial transaction .

Figure 2 is a flow diagram of the steps of a check transaction. Figure 3 is a block diagram of a network of financial institutions.

Figure 4 is a block diagram of a bank's check image interchange system.

Figure 5 is a flow diagram of a check presentment application.

Figure 6 is a flow diagram of a check query application.

Figure 7 is a block diagram of a check image interchange system. Figure 8 is block diagram of the functional groups of the ANSI X9.46 proposed standard.

Figure 9 is a block diagram of a data structure scheme. As seen in Fig. 9, the invention provides an instrument image interchange facility 500. At one institution 498, a paper instrument 501 is scanned and stored using a conventional data structure 503 to capture the binary image content 504. Typical such structures include JPEG, CCITT Group IV, and IBM's ABIC. The instrument image interchange would require that the binary content of the image be kept m one of these formats or some other preapproved form. It also requires that the binary content be encapsulated (i.e., packaged or enveloped) in a preapproved common data structure 506, for example one complying with ANSI proposed standard X.9. If both of these requirements are met then the packaged data structure may be sent via any communication mode to any other institution which can then reliably recover and use the binary content of the instrument image by means of a readily available, easily defined algorithm. The data structure may also enclose information 510 from proprietary data structures associated with the binary content so long as it also includes the standard forms of data structure information.

In current schemes it is common for an institution to envelope binary content m a proprietary envelope for various purposes, such as the IOCA scheme of IBM. The mvention does not prevent continued use of such arrangements at each institution nor the inclusion of proprietary data structure information in what is sent between institutions, but it provides an alternative approach that permits fluid interchange of image content anywhere in the world via a wide variety of communication media and among a wide variety of institutions for a wide variety of purposes without any two of the institutions having to engage special negotiations to achieve the result. Each institution is able to rely on the common structures as assuring its ability to participate in the system.

As shown in Fig. 3, banking institutions 50 may interchange check images via a network 52, such as a distributed TCP/IP based network. A TCP/IP network could utilize dial-up ISDN, for example. Electronic networks include the dial-up, Internet, wireless, and e-mail networks. Since security is critical for communication of electronic funds transfer instruments, established banking networks, which are secure and well disciplined, may be preferred to public networks.

Each banking institution is a node on the network 52 and has a server 54 (e.g., a UNIX server) , a local image store 56 and a workstation 58 such as a personal computer with a monitor. Through the network, any one of these components in one bank may communicate with any other component in a bank connected to the network, whether or not the components are at the same location or geographically separated.

In Fig. 4, bank 50 has an image capture system 62 connected to its server. The bank which captures a check image is known as the bank of first image. The image capture system includes a scanner 64 for obtaining an electronic digital image of both sides of a check and for deriving codelme data from the check such as the payee, the payer, the payer's bank, the payer's bank account and the amount to be paid. The check may also include an imprint of a unique identifier for the check such as a 2D bar code which would allow tracking of the check by analyzing its image. The image capture system 62 may be a known proprietary system chosen by the bank, such as the High Speed Image Item Processing System available from Unisys. The codeline data may be converted to an format for electronic presentment of checks by a processmg system 66, which may be connected to the bank's server.

The digital check image and the codel e data are stored in a data store 56 known as an archive. The bank may transmit both the codel e data from the check and the check image data over the same network, although the codeline data and the check image need not be transmitted together. The archive 56 stores the data in a proprietary format chosen by the bank, such as the Image Object Content Architecture (IOCA) format of IBM or the Tag Image File format (TIFF) used by Unisys. Check image interchange involves a set of applications which provide user interfaces for banks to request check images from other remote banks, receive images from other remote banks, and provide images to other banks upon request . Two check image interchange applications concern forward check presentment and image queries. The applications manage the resources required to process the queries, responses and acknowledgements associated with check image interchange.

The bank 50 has at least one workstation 58 for formulating and managing image queries to remote banks and for viewing retrieved check images by an operator. The bank may also support other applications 75, including its own use of the stored check images and codeline data such as for processing and viewing. In an alternative embodiment, check images and data may be captured and stored by a third party repository 57. The repository would provide an archive server 59 for access to the stored check images and data by other banking institutions. The applications must support communication of check images and requests a standard format since each bank employs its own chosen proprietary image capture and storage systems. The communications standard chosen for check image interchange is the ANSI X9.46 proposed standard. The mechanisms for routing check images and requests between banks and for searching for images utilize the X9.46 proposed standard for the entire interchange process. Although forward presentment of codelme data alone may be performed either with a commercially available product for electronic presentment of checks or using the X9.46 proposed standard, use of the X9.46 proposed standard will be assumed for present purposes. Details of the X9.46 proposed standard are set forth in the ANSI X9.46 Data Structure Reference, available from the X9B working group withm ANSI and incorporated by reference.

A system known as Image Locator Services (ILS) 72 located in the bank as part of its server processes check image data, codelme data and query requests from the bank's proprietary format into the X9.46 proposed standard format for communication with other banks. A commercially available EDI translator 74 withm the ILS may be used to perform the translation. The ILS determines where data is to be routed in the interbank exchange environment and provides the communications mechanisms needed to transmit information m the standard format. The check image interchange applications include information required to build the content of X9.46 query, image and acknowledgement messages and transmit them to and receive them from the EDI translator 74 via an application interface.

As shown in Fig. 5, in forward check presentment 100, check images and codel e data are captured (step 102) using the bank's existing proprietary capture equipment . The captured data is placed an image archive in the bank's proprietary format (step 104) .

After capture, the codelme data from the checks must be packaged and sent to the payer's bank to initiate payment procedures. A codelme data file is created

(step 106) which includes information for requesting the corresponding check images and the codelme data from which images to be viewed can be identified. For example, the codelme data file contains an image identifier corresponding to the stored check image. The codelme data is then sent to the ILS (step 108) .

The ILS translates the codelme data file to the X9.46 proposed standard format and bundles it into an X9.46 data file (step 110) . The translation process maps the file mto an X9.46 data stream to send to the payer's bank. The codelme data may be sent by itself, or with the correspondmg check image or portions of check image. Or, as described below, the check image data may be transmitted by itself. The ILS also determines the recipient of the translated codelme data (step 112) . Thus, the information sent to the ILS must contain enough information to identify the receiving institution. The ILS then determines the details for transmitting the translated file to the recipient bank, including the phone number to dial, the network address, and/or the e- mail address.

The ILS executes the transmission to the recipient bank (step 114) , and the recipient bank's ILS receives the transmission of the codelme data in the X9.46 proposed standard format (step 116) .

The recipient bank' s ILS determines the nature of the X9.46 data stream it has received (step 118) and identifies which internal system is to receive the codelme data. Knowing this information, the ILS translates the codeline data mto a format usable by the internal system of the recipient bank (step 120) .

The ILS interfaces the translated codeline data file with the appropriate system for processing (steps 122 and 124) . Although each bank may treat the codeline data differently, the codelme data ultimately is passed on to the appropriate internal posting system to complete payment of the check. However, at this time, not all banks post checks with electronic presentment of checks. Thus, the result of the check presentment procedure is the identification of images that the recipient bank must request. Usually this is done to research problem items that cannot be posted directly from the codelme data for various reasons. Also, research may need to be done to handle other exception conditions such as stop payment orders, non-sufflcient funds, closed accounts, etc. The result of the check posting procedure may be a report of check images to be examined or a list of items to be used in an automated query. In Fig. 6, in the check query application 130, two strategies may be employed to accomplish a query. For a single item real time query (step 132) , the operator enters the image identifier of the desired check image. The query for images to be viewed may also be formulated in advance and stored in a pick list to be batch processed (step 134) . For example, the exception processes may generate the pick list, or the operator may enter the image identifiers from a report. Received images may then be stored locally for off-line viewing. If the exception processes automatically generate the query, then the query can be carried out without any action by the operator, and the images would be ready for viewing when the operator is available.

The processes generating the queries send the query request the bank's proprietary format to the ILS of the requesting bank (step 136) . The ILS translates the query request mto an X9.46 data file (step 138) . The ILS also determines what system has sent the query request to determine which map to use for the translation.

The ILS determines the recipient of the query request (step 140) . Thus, the information sent to the ILS must contain enough data to identify the institution to receive the request. The ILS determines the details for transmitting the request file to the bank that created the image, including the phone number to dial, the network address, and/or the e-mail address. The ILS then executes the actual transmission to the bank of first image (step 142) . When the bank of first image's ILS receives the transmitted query request (step 144) , it determines the nature of the X9.46 data stream it has received (step 146) and identifies which internal system (e.g., the archive) is to receive the query request data. The ILS translates the query request mto a format usable by the archive of the bank of first image (step 148) .

The bank of first image's ILS interfaces the translated query request with the archive to service the request (step 150) . The archive attempts to find the requested images and/or data (step 152) . The archive sends the completed response (images, data, or error information) back to the ILS (step 154) .

The ILS of the bank of first image determines which internal system has sent the data to it to determine which map to use for the translation, and then translates the response mto an X9.46 data file (step 156) .

The bank of first image's ILS determines the recipient of the query response (step 158) . Thus, the information sent to the ILS must contain enough data to identify the requesting bank. The ILS then attends to the details for transmitting the file to the requesting bank, including the phone number to dial, the network address, and/or the e-mail address. The ILS executes the transmission of the X9.46 file to the requesting bank's ILS (step 160) .

When the ILS of the requesting bank receives the transmitted query response (step 162) , it determines the nature of the X9.46 data stream it has received (step 164) and identifies which internal system should receive the query response data. The ILS translates the query response into a format usable by the internal system (e.g., the workstation) (step 166) . The workstation at the requesting bank displays the received images (step 168) , or the images and data received are stored for later inspection (step 170) .

Applications for check image interchange have been developed by IBM and Unisys. The check image interchange components are provided on hardware and software platforms such as RISC/6000 for the IBM AIX system and U6000 for the Unisys UNIX system, as well as platforms for the EDI translator. Connection to the network may be accomplished through network boxes such as an Adtran 128 DSU modem for ISDN connectivity and Cisco 2502 access routers for LAN connectivity to ISDN equipment. These have been used in pilot experiments. Any scheme that can establish a TCP/IP network may be used.

The image capture system captures both the electronic digital images and the codeline data for checks. The scanners that may be used range from high speed reader/sorters such as those available from Unisys, AT&T and IBM, to low speed desktop scanners such as those available from Hewlett-Packard. In some systems, the codelme information is entered by the operator rather than through the scanning operation. The image capture system exports the captured information to the archive and generates index information used for identification. The index information ideally includes the item sequence number, the cycle indicator (day of the week) , the processing data, and the initial storage device number. For convenience, export of information also should be controllable by other useful selection criteria such as sorter ηob. If the image capture system does not perform these functions, it must allow the archive system to access the information so that the data can be stored and indexed. Alternatively, the capture system may be integrated into the archive system for ease of storage and indexing. The number of views presented to the requesting bank for each request corresponds to the number of views captured by the bank of first image's image capture system. Check image interchange may support varied image views, such as front black-white, front gray scale, back black-white and back gray scale.

Storage and communication of check images is carried out in the compressed image format of the bank of first image. The image data compression algorithm used is determined by the binary image format of the bank of first image. Image data may be formatted using accepted compression algorithms, which include Adaptive Bilevel Image Compression (ABIC) by IBM, and CCITT Group 4 and the Joint Photographic Experts Group (JPEG) used by Unisys and AT&T. No image data conversion takes place prior to or durmg communications, and the receiving system converts the image as needed or desired.

The use of electronic presentment of checks allows check data to be interchanged real time and at volumes that current technology, price and performance can accommodate. By sending the data m codel e data format (which may also contain an identification label of the associated image) , the receiving bank can process the data, post the check, and be assured of resolving discrepancies with the data and handling exception conditions in a timely manner by accessing the check image from the bank of first image. In some cases, the actual check images will be forward presented, such as for items not qualified for processmg of electronic presentment of checks or where the condition of the check would dictate a need by the recipient for the image. The receiving bank can resolve the problem causing the exception by viewing the image and making the necessary repairs to the data.

The components of the ILS are constructed on a server, such as a UNIX-based server. The software components required to implement image capture and transfer through the ILS include the applications and the EDI translator. These software components enclose and optionally encrypt, perform hashing on, and provide a digital signature (if one does not already exist) for the compressed image in a ANSI X9.46 proposed standard envelope that identifies the image format and contains various pieces of data pertinent to the image, such as the index information. A digital signature may already exist prior to the processing; if so, the digital signature is simply passed through. The EDI translator maintains communication session control between the banks exchanging data in X9.46 proposed standard format.

The EDI translator in the ILS constructs X9.46 messages based on information received from the processing system, the archive and the workstation, and passes information received in X9.46 proposed standard format to these systems. Data is passed between the EDI translator and the other systems using an application interface, which may include sockets, named pipes, Files, FTP, e-mail or other means.

Image data, for example, is provided to the EDI translator in TIFF, IOCA or another image encapsulation data structure via the application interface. The EDI translator opens the image content and constructs the X9.46 interchange object based on the control data and the image binary data contained in the image object. Conversely, the EDI translator assembles image data received an X9.46 data stream into TIFF or IOCA image objects as specified by the receiving bank's application. The archive provides a repository of check images and codeline data. The archive includes all the processing data elements necessary to locate images and codeline data from queries made to the system, including the item sequence number, processing date, cycle number, and device identification. Other financial data storage requirements may include the MICR line of the check, the bank of first deposit and document image number, the date the check was paid, and the disposition of the check. The images of the front and back of the check may be stored in their original capture format or in an export format that includes the data compression and an image wrapper. The archive interfaces with the ILS to perform the query function. The archive normally will be used both for check image interchange and for check processing such as normal proof of deposit operations. Alternatively, there may be a separate archive used solely for interchange or other functions.

The archive system must be capable of receiving or importing images and data from the capture system. This exchange may be via seamless integration or a data export type of interface. The process of storing may occur real time during capture, or in some cases it may be a separate export process that takes place subsequent to capture. Further, some aspects of data integrity and security may be implemented within the archive system. The workstation provides a user interface for querying and displaying images. The workstation may support the entry of an image identifier for queries as well as imbedding the query functions into the various business applications that utilize check images, such as exception processing and signature verification. Upon entry of user data needed to formulate a query, the formatting routines of the workstation's software establish a query transaction to be transmitted to the ILS. Examples of workstation platforms are Windows and OS/2 Warp. The images returned to the workstation from the ILS after a query request are in the data format used by the bank of first image. No transcoding is done by the bank of first image. Thus, the display system of the workstation must be able to understand all of the accepted standard image formats. The workstation has software to decompress and decode received image formats, such as Image Viewer.

Additional details of the check imaging system are shown in Fig. 7. As shown in Fig. 8, the ANSI X9.46 proposed standard 200 defines several functional groups for exchanging image information and coded data.

The query request functional group 202 is used by the requesting bank to request one or more images from the bank of first image. Each query contains a unique query ID 204 for maintaining continuity between the original query, acknowledgment and the transmission of images to the requesting bank.

The query request functional group 202 permits an image to be specified individually, based on its image identifier, or to be specified based upon generalized search criteria such as account number and serial number range. The requesting bank also may request check image formats that conform to its viewing software. Additional query request elements may include snippets of the check image, scaling and color.

The items views functional group 206 is used to return image items requested by the requesting bank. This functional group supports transmission of one or more images. Item data loop structures 208 contain the information for imaged items. Multiple item data loops, each representing a single image, may exist with the functional group. Withm each item data loop, one or more item view loops may exist to represent different views of the image. Therefore, a smgle transmission of an item views functional group may contain multiple images, each of which may further contain multiple views. The views available to be sent to the requesting bank depend upon which views were captured by the bank of first image.

The financial data functional group 210 is used to convey check codeline and other associated financial data.

The application acknowledgment functional group 212 provides a positive or negative application acknowledgment 214 that the content of the information received in an exchange is functionally correct and acceptable to the recipient. An application acknowledgment 214 may be requested response to the transmission of a query request functional group 202, an item views functional group 206 or a financial data functional group 210.

The functional acknowledgment functional group 216 provides a positive or negative functional acknowledgment 218 that the information received in an interchange is syntactically correct for a functional group, transaction set, or data segment. A functional acknowledgment 218 may be requested in response to the transmission of a query request functional group 202, an item views functional group 206 or a financial data functional group 210. Unlike the other functional groups, the information in the functional acknowledgment functional group is supplied entirely by the EDI translator in response to the information received in the context of the functional group which invoked it; no input from the receiving application is required. The EDI translator constructs the functional acknowledgment functional group and transmits the response back to the requestor without the intervention of the application. The X9.46 proposed standard also supports other image capture and transfer functions. The query request functional group 202 and the item views functional group 206 provide a security header which allows authentication, encryption services, and digital signatures to be applied to transmission of these groups. The X9.46 proposed standard also permits one or more transaction sets to be specified for each functional group. Additional functional groups and data elements may be added at a later date to support an expanded implementation of the X9.46 proposed standard.

The EDI translator accepts source images in either the IOCA or TIFF object format, for example, and builds X9.46 interchange messages which are independent of the proprietary systems employed by the bank and which contain the appropriate control and data content, but do not rely upon the syntax of the original image data. The receiving bank may request that the translator reconstruct the image into its original object format, if it is known, or reconstruct the image object into a representation chosen by the bank. For example, the sending bank may have provided the image as a TIFF object but the receiving bank may wish to reconstruct the image as an IOCA object.

Under normal circumstances it is assumed that the receiving bank will select a smgle representation for all images it receives, and that the representation will be defmed in the translator via a configuration table. It is also conceivable that the receiving bank may wish to dynamically define the format of the images it receives based on the source of the images. The format chosen by the bank will be incorporated into the EDI translator.

The transaction is the basic unit of communication with the EDI translator. Each transaction contains the information necessary to represent the content of an X9.46 functional group. The EDI translator uses the content of the transaction to construct an X9.46 functional group for outbound transmissions. For inbound transmissions, the EDI translator constructs a transaction from the received X9.46 functional group. The interface with the EDI translator includes pre¬ defined interface files.

Each X9.46 functional group has a pair of dedicated interface files for outbound transactions to the EDI translator and inbound transactions from the EDI translator. For example, each interface file has a record length of 80 bytes followed by a line feed character. Each record withm a file represents a logical grouping of X9.46 data elements, referred to as segments. A segment consists of a segment identifier and the data elements, which may not exceed 80 bytes The segment and data element structure of the outbound and inbound interface files is the same.

A unique set of segments is defmed for each EDI transaction type. These segments represent the mandatory data elements required for each functional group in addition to any optional or conditional elements necessary for implementation of the applications. New segment definitions may be added to incorporate additional data elements. All interface file segments records must be built by the application m the sequence specified for a particular transaction type.

Data elements within a segment have fixed lengths, with no delimiters between data elements. Binary data elements are contained m a separate file whose name is contained a segment data element. The order m which data elements appear in the segment may not necessarily correspond to the order m which they appear m the X9.46 functional group. All segment data element positions are present m both outbound and inbound transactions.

Except where noted, all data elements contain data both outbound and inbound transactions. In those cases where the length of a data element may be less than the fixed length of the data element field, the data is left- aligned and the unused bytes must be padded with ASCII blanks .

An X9.46 loop structure may be represented by a single segment or a sequence of segments. Loop iterations are specified by repeating the segment or segments for the required number of iterations. The nesting sequence of outer and inner loops is as described m the ANSI X9.46 proposed standard specification. Loop structures must be constructed the order described for the transaction type. Subordinate loop sequences must be completed before the next higher level loop can be repeated.

A transaction set reference ID 220 is used to associate two functional groups. For example, the transaction set reference ID is used to associate the item views transaction to the query request transaction which requested the images. The transaction set reference ID of the query request will be inserted in the transaction set reference ID of the resulting item views transaction to allow the receiving application to associate the inbound item views transaction with the query request transaction that requested the images. Since the EDI translator generates the transaction set reference ID for all outbound transactions, the transaction set reference ID must be returned to the application m a status file after the EDI translator builds the outbound transaction.

In a transaction, the application sends an outbound query to the EDI translator. After building the query request transaction, the EDI translator returns the transaction set reference ID 220 to the application in a status file. The receiving EDI translator passes the transaction set reference ID of the query request transaction to the receiving application along with the query contents. When the receiving application builds the item views transaction, it passes the transaction set reference ID of the query request transaction to the EDI translator, which inserts it mto the transaction set cross reference ID of the item views transaction. This associates the item views transaction with the query request transaction. When it receives the item views transaction, the application which sent the query extracts the transaction set cross reference ID to associate the inbound item views transaction with the original query request transaction. The EDI translator maintains two status files which will be available to the application after every outbound call to the EDI translator, one for results of outbound query requests and the other for results of outbound item view requests. The status files contain the call status and the transaction set reference ID of the transactions created by the EDI translator.

The EDI translator builds a status file with the appropriate file name after processmg an outbound request from the application. The status file is available to the application after a return code is posted for the call. Once the status file is read, the application must delete the file. The EDI translator may not build another status file for a given transaction until the last status file has been erased by the application. If the application calls the translator to process a transaction without having first erased the previous status file for that transaction type, a non¬ zero return code will be posted and the translator will not accept the call. The content of the status file is associated with only one call. The EDI translator may not append status information from separate calls mto one status file.

The application initiates outbound communication by making a call to the EDI translator. The EDI translator responds with a return code of zero to indicate a successful operation or a non-zero return code to indicate an error. The call structure and the return codes are defined for the EDI translator. Only one interface file may be passed to the EDI translator for each call, and only one transaction may be presented in each outbound interface file.

To send an outbound transaction from the application to the EDI translator, the application creates a lock and an interface file using the appropriate file name. The application then places the segment information m the interface file and turns off the lock. The application passes the file name to the EDI translator via a call. The EDI translator locks the file specified the call and receives the outbound transaction. If the call is successful the EDI translator erases the interface file, turns off the lock, and posts a return code of zero to the application. If the call is unsuccessful the EDI translator turns off the lock, but will not erase the interface file and a non¬ zero return code is be posted to the application. Finally, the application erases the interface file.

To receive inbound communications from the EDI translator, the application polls the system for the existence of unlocked inbound interface files. The inbound interface file may contain one or more transactions. The receiving application processes some or all of the transactions received the inbound file Transactions not processed by the application must be returned to the EDI translator as described below. Inbound transactions are sent from the EDI translator to the application. If the appropriate inbound interface file does not exist, the EDI translator will create a lock and a file with the appropriate file name. If the file already exists, the EDI translator will place a lock on the file. The EDI translator will place the inbound transaction at the beginning of the interface file if the file is new or append the transaction to the existing content if the file already exists. The EDI translator then unlocks the interface file. When the application detects the file by polling, it places a lock on it.

An application may process one or more transactions in the file. If the application processes the entire content of the inbound interface file it must erase the file and remove the lock. If the application does not process all of the transactions m the inbound transaction it must delete all segment associated with the transactions it processed. The lock will then be removed from the interface file to release it back to the EDI translator.

Other embodiments are within the scope of the following claims. What is claimed is:

Claims

1. A computer-based method comprising creating a first electronic representation of binary content of an image of a financial instrument in accordance with a predefined data structure, processing the first electronic representation to generate a digital delivery format complying with a common delivery protocol, and delivering the digital delivery format over an electronic data communication network.

2. The method of claim 1 further comprising converting the digital delivery format to a second electronic representation complying with a second predefined data structure protocol .

3. The method of claim 2 which the predefined data structures are the same.

4. The method of claim 2 further comprising processmg the second electronic representation.

5. The method of claim 4 m which the processing comprises displaying an image of the financial instrument.

6. The method of claim 4 in which the processing comprises printing an image of the financial instrument .

7. The method of claim 1 m which the first electronic representation is created at a first financial institution and the digital delivery format is delivered to a second financial institution or merchant.

8. The method of claim 7 in which the common protocol comprises a protocol recognized common by the first financial institution and the second financial institution.

9. The method of claim 7 in which the first predefined data structure comprises a proprietary data structure of the first financial institution.

10. The method of claim 1 which the first electronic representation comprises an image of the financial instrument.

11. The method of claim 1 which the first electronic representation comprises a digital codel e representation of the financial instrument.

12. The method of claim 1 in which the financial instrument comprises a check.

13. The method of claim 1 m which the financial instrument comprises a credit card slip.

14. The method of claim 1 in which the common protocol comprises a commonly accepted protocol.

15. The method of claim 1 further comprising storing the first electronic representation for subsequent retrieval upon a request.

16. The method of claim 15 in which the first electronic representation is stored at a first financial institution.

17. The method of claim 16 in which the request is delivered electronically to the first financial institution from a second financial institution and the digital delivery format is delivered to the second financial institution.

18. The method of claim 16 further comprising processing the first electronic representation at the first financial institution.

19. The method of claim 18 m which the processing comprises displaying an image of the financial instrument .

20. The method of claim 18 which the processing comprises printing an image of the financial instrument .

21. The method of claim 15 m which the request is generated automatically.

22. The method of claim 15 further comprising assigning the first electronic representation an identification index.

23. The method of claim 22 which the request comprises the identification index.

24. The method of claim 1 further comprising encrypting the digital delivery format for secure delivery over the electronic data communication network.

25. Apparatus comprising a capture device for obtaining a first electronic representation of a financial instrument complying with a first protocol, a translator for converting the first electronic representation mto a digital delivery format complying with a second protocol, and means for delivering the digital delivery format over an electronic data communication network.

26. The apparatus of claim 25 m which the first electronic representation comprises an image of the financial instrument.

27. The apparatus of claim 25 in which the first electronic representation comprises a digital codel e representation of the financial instrument

28. The apparatus of claim 25 in which the financial instrument comprises a check.

29. The apparatus of claim 25 m which the financial instrument comprises a credit card slip.

30. The apparatus of claim 25 m which the second protocol is a commonly accepted protocol .

31. The apparatus of claim 25 m which the capture device comprises a scanner.

32. The apparatus of claim 25 further comprising a memory for storing the first electronic representation.

33. The apparatus of claim 32 further comprising a workstation for processmg the stored first electronic representation.

34. The apparatus of claim 33 in which the processing comprises displaying an image of the financial instrument .

35. The apparatus of claim 33 in which the processing comprises printing an image of the financial instrument .

36. The apparatus of claim 32 which the workstation comprises an interactive display of the first electronic representation.

37. The apparatus of claim 25 m which the translator comprises an EDI translator.

38. Apparatus comprising means for electronically receiving a digital delivery format of a financial instrument complying with a first protocol, and a translator for converting the digital delivery format into an electronic representation complying with a second protocol .

39. The apparatus of claim 38 m which the electronic representation comprises an image of the financial instrument.

40. The apparatus of claim 38 in which the electronic representation comprises a digital codeline representation of the financial instrument.

41. The apparatus of claim 38 in which the financial instrument comprises a check.

42. The apparatus of claim 38 in which the financial instrument comprises a credit card slip.

43. The apparatus of claim 38 in which the first protocol comprises a commonly accepted protocol .

44. The apparatus of claim 38 in which the translator comprises an EDI translator.

45. The apparatus of claim 34 further comprising a workstation for processing the second electronic representation.

46. The apparatus of claim 45 in which the processing comprises displaying an image of the financial instrument .

47. The apparatus of claim 45 in which the processing comprises printing an image of the financial instrument.

48. The apparatus of claim 45 in which the workstation comprises an interactive display of the first electronic representation.

49. A method for truncating a paper check in a check clearance system comprising capturing an electronic image of the paper check at a first banking institution, the electronic image complying with a first protocol, converting the electronic image to a digital delivery format complying with a common second protocol, sending the digital delivery format digitally from the first banking institution to a second banking institution, at the second banking converting the digital delivery format to an electronic image complying with a third protocol, and processing the electronic image complying with the third protocol for clearance purposes.

50. The method of claim 49 m which the digital delivery format comprises a secure format created by encryption.

51. A method for use by financial institutions with respect to financial instruments comprising storing, at different financial institutions, electronic images of paper financial instruments presented to the respective institutions, the storing at different financial institutions being done in accordance with different protocols, at each of the financial institutions, accepting electronic requests for copies of specified ones of the electronic images stored at the respective financial institutions, the requests being sent by any of the financial institutions via a common communication network, and at each of the financial institutions, responding to electronic requests by converting the requested electronic images to a common protocol and returning the images in digital form to the requesting financial institution.

52. The method of claim 51 m which the electronic requests are generated automatically.

53. The method of claim 1 further comprising automatically processing the binary content of the image to verify the authenticity of the item.

54. The method of claim 1 further comprising automatically processmg the binary content to identify characters on the financial instrument .

55. The method of claim 53 which the processing includes using cryptography for determining authenticity.

56. The method of claim 1 further comprising automatically processmg the binary content to identify handwritten information.

57. The method of claim 53 further comprising marking the financial instrument with an authenticity flag and automatically processing the binary content to identify the authenticity flag.

58. The method of claim 1 further comprising automatically processing the binary content to determine if the financial instrument had been altered without authorization.

59. A method comprising storing binary content of images of financial instruments m accordance with a predefined data structure and information uniquely identifying each of the images, encapsulating the binary content of each of the images in a delivery package that complies with a common protocol, and m response to a request for images havmg specified identifying information, sending packages containing the binary contents of the images digital form.

60. The method of claim 1 in which the processing of the first electronic representation includes selectmg only snippets of the binary content for inclusion in the digital delivery format.