« PreviousContinue »
(12) United States Patent
(io) Patent No.: (45) Date of Patent:
US 7,123,376 B2 Oct. 17, 2006
(54) METHOD FOR USING PRINTSTREAM BAR CODE INFORMATION FOR ELECTRONIC DOCUMENT PRESENTMENT
(75) Inventor: Michael Shea, Litchfield, CT (US)
(73) Assignee: Pitney Bowes, Inc., Stamford, CT (US)
( * ) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by 1164 days.
(21) Appl. No.: 10/124,792
(22) Filed: Apr. 16, 2002
(65) Prior Publication Data
US 2003/0196175 Al Oct. 16, 2003
(51) Int. CI.
(52) U.S. CI 358/1.15; 358/1.18; 358/1.9;
(58) Field of Classification Search 358/1.15,
358/1.9, 1.18; 705/406, 408 See application file for complete search history.
(56) References Cited
U.S. PATENT DOCUMENTS
5,115,326 A * 5/1992 Burgess et al 358/440
A method for using bar code data parsed from a legacy printstream to facilitate electronic processing and electronic document presentment, whereby match code data, page number data, page count data are extracted from bar code data of legacy printstreams to determine what corresponding mail piece data set extracted data belongs to, and alternatively consulting a separate mail run data file as identified in the bar code data in order to find mail piece information to be used in identifying what page data belongs to what mail piece. Integrity and classification of collected data are thereby enhanced by consulting mail piece assembly data and page information included in legacy printstream bar code information.
4 Claims, 2 Drawing Sheets
METHOD FOR USING PRINTSTREAM BAR
CODE INFORMATION FOR ELECTRONIC
TECHNICAL FIELD 5
The present invention relates to parsing and extracting data from an electronic printstream in order to present documents in an electronic format. More particularly, the present invention utilizes bar code data within the electronic 10 printstream to assist in identifying and formatting printstream data for electronic presentment.
Recently, many organizations are becoming more involved in conducting business electronically (so called e-business), over the Internet, or on other computer networks. E-business calls for specialized applications software such as Electronic Bill Presentment and Payment (EBPP) 20 and Electronic Statement Presentment (ESP) applications. To implement such applications, traditional paper documents have to be converted to electronic form to be processed electronically and exchanged over the Internet, or otherwise, with customers, suppliers, or others. The paper 25 documents will typically be reformatted to be presented electronically using Hypertext Markup Language (HTML) Web pages, e-mail messages, XML messages, or other electronic formats suitable for electronic exchange, processing, display and/or printing. 30
For example, a credit card or utility company may decide to implement an EBPP service to allow its customers to view and pay bills on-line over the Internet. Any such EBPP implementation must be integrated into the organization's existing billing system. A straightforward seeming approach 35 to integrating the billing systems would be to get the data from the existing billing system's database and use that data in the new e-business system. This approach, however, is not as simple as it may seem. Many legacy systems do not have a standard interface for data extraction and, moreover, the 40 information required to present a document to a customer in electronic format does not exist in any one easily accessible database format. A telephone company, for example, might maintain three different databases feeding into its legacy billing application. The different database could be (1) a 45 customer information database containing account numbers, calling plans, addresses and other customer profile information—this database including data that would be updated infrequently; (2) a rate and tariff database containing the rate structure used to calculate the cost of calls, which is typi- 50 cally based on geographic zones, time of day and the like—this database including data that would be updated periodically; and (3) a transaction database containing the transaction history of calls made by customers including number called, duration, and the like—this database includ- 55 ing data that would be updated very frequently.
The various databases may be located on three separate and distinct computer systems (e.g. IBM mainframe, Tandem fault tolerant system, UNIX minicomputer, and so on) and in three different database formats (e.g. Oracle RDBMS, 60 flat files, IMS database, and so on). Moreover, there is typically a great deal of application logic embedded in the billing system's legacy software code, which could be in the form of a COBOL program written in the 1960s, for calculating taxes, discounts, special calling charges, and so on. 65 Because of these complexities, it is generally very difficult to recreate a bill for use in e-business from original data
sources. Reference to the original data sources would generally require recreation of all of the functionality that exists in the individual organizations' existing billing systems. The cost and time needed to accomplish such recreation would generally be prohibitive.
Thus for use in legacy system integration and transition to e-commerce it can be more efficient to extract the desired information from print data generated by the legacy system as part of its conventional customer billing process. For this purpose, specialized software tools known as parsers have been developed to extract information out of the printstream data that is generated by the legacy document printing files. A run of printstream data may typically represent thousands of documents that are used to form thousands of bills to be sent to customers. As used in the legacy computer system, the printstream data is provided to a printer that prints out the thousands of documents (bills, statements, etc.) that are assembled and mailed to customers. The parser tools are programmed to recognize and extract data fields and information from the printstream so that such information may be used in an EBPP system.
A fair amount of printstream data will not be useful to the EBPP system, and will be accordingly ignored by the parser tools. For example, a bill printed by the legacy system may include graphics that are will not be used in the EBPP system. The corresponding graphics information in the printstream will thus be ignored.
Another example of printstream data that has typically been ignored is bar code data that is used for bar codes on documents produced by the legacy systems. The bar code data in the printstream will usually be in the form of an ASCII string that is converted to the familiar bar code form by a font on the printer. The bar codes are conventionally used for providing instructions to the machinery that assembles the printed documents into mail pieces, stuffs mail pieces into envelopes, and prepares the envelopes for mailing. The machines for preparing mass quantities of finished mail pieces from the printed documents are generally known as "inserters."
The bar codes printed on documents may include information about how a mail piece should be assembled, as well as information about the intended recipient of the mail piece. Such information can include addressing, geographic, demographic and insert criteria, which information is used by a document inserting system to build a mail piece around the recipient's personalized document. The bar code may also include a "matchcode" that identifies the document as belonging to a particular mail piece. Consecutive documents having a same matchcode will be collated into the same mail piece. The bar codes may also include information on how many pages are in the mail piece, and a page number for a particular document in the sequence of documents in the mail piece.
The bar code may also include a reference pointer identifying a computer data file that further includes information about individual mail pieces to be assembled by the inserter. Such a computer data file is called a Mail Run Data File (MRDF) and typically an MRDF will include information about a large run of documents that are to be printed and processed by the inserter machine. The MRDF typically includes information and instructions more extensive that which is included in the bar code itself. An inserter machine will often receive instructions for assembling an individual mail piece based on information stored in the MRDF.
When processing documents to form mail pieces, an inserter system will scan the barcodes printed on the documents using known techniques. Using the information from