New! View global litigation for patent families

CA2053455A1 - Mail sorting apparatus and method - Google Patents

Mail sorting apparatus and method

Info

Publication number
CA2053455A1
CA2053455A1 CA 2053455 CA2053455A CA2053455A1 CA 2053455 A1 CA2053455 A1 CA 2053455A1 CA 2053455 CA2053455 CA 2053455 CA 2053455 A CA2053455 A CA 2053455A CA 2053455 A1 CA2053455 A1 CA 2053455A1
Authority
CA
Grant status
Application
Patent type
Prior art keywords
function
file
sack
bin
step
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA 2053455
Other languages
French (fr)
Inventor
Paul F. Kostyniuk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bowe Bell and Howell Co
Original Assignee
Paul F. Kostyniuk
Bell & Howell Phillipsburg Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B07SEPARATING SOLIDS FROM SOLIDS; SORTING
    • B07CPOSTAL SORTING; SORTING INDIVIDUAL ARTICLES, OR BULK MATERIAL FIT TO BE SORTED PIECE-MEAL, e.g. BY PICKING
    • B07C3/00Sorting according to destination

Abstract

MAIL SORTING APPARATUS AND METHOD
ABSTRACT OF THE DISCLOSURE
A mail sorting machine (20) includes an input hopper (30); a mailpiece reading and processing section (22); and, a sorting bin section (24) comprising a plurality of bins (26, -26128). The reading and processing section (22) includes a CPU
(54) which executes a program ANALYZE_MAIL for sorting third class mailpieces. The program ANALYZE_MAIL sorts the mailpieces included in a batch into packages, and then associates the packages into sacks or bags. The program ANALYZE_MAIL constructs the packages and sacks to obtain maximum postage discounts. Upon an initial pass of all mailpieces of a batch through the sorting machine (20), the program ANALYZE_MAIL generates output (TABLE 1) advising how the bins (26) are to be grouped for subsequent passes. The program ANALYZE_MAIL also generates output (TABLES 2A - 2E) advising, for each group, which bins (26) are to have their packages associated together for insertion into the same bag or sack. Advantageously, the mailpieces are sorted so that the bins (26) to be associated together are physically adjacent one another in the sorting machine (20). Bag tags are generated to tell an operator which bins are to be collected together to form a sack or bag, as well as the sack number and group number. The program ANALYZE_MAIL also includes an accounting capability for billing postage to a possible plurality of clients having mailstreams included in the batch, and for allocating postage costs in accordance with whether the client's mailpieces qualify for postage discounts.

Description

20~34~a BACRGROUND OF THE INVENTION

I. FIELD OF THE INVENTION
This invention pertains to apparatus and method for sorting postal envelopes prior to mailing, and particularly to such apparatus and method for presorting envelopes in order to obtain postage discounts offered by the United States Postal Service.

II. PRIOR ART AND OTHER CONBIDERATIONB
The United State~ Postal Service is handling an ever increasing volume of domestic mail. A large component of the domestic mail volume is attributed to postal patrons who introduce large or bulk shipments of mail into the Postal Service. Examples of such postal patrons include financial institutions (such as banks and credit card companies that mail ~20 out periodic statements to their customers); utilities (which mail out monthly or quarterly bills); charitable and non-profit institutions; and, advertising agencies.
The Unit~d States Postal Service affords more favorable postage rates for postal patrons who cooperate with the United a5~ ~ ~States Postal Service by preparing bulk shipments of mail in a~manner more easily handled by the United States Postal Service. The United States Postal Service defines its postage ;class structure,~ and the requirements for obtaining the more favorable postage rates for bulk mail patrons, in a publication ~ called the Domestic Mail Manual (also known as the "DMM'I).

:: ~

:~ ~

.

.
.
, ~ . .
. . .
.

2 2053~5a By way of example for the foregoing, the DMM sets forth a schedule of rates and fees for third class mail, with the postage rate for third class mail depending upon a presort level of the mail. In this respect, for third class mail the DMM prescribes the following presort levels for bulk rate mail:
basic; basic ZIP + 4; 5 digit; 5 digit ZIP + 4; ZIP + 4 barcoded; and, carrier route. of these presort levels, the basic level is the most expensive, the basic ZIP +4 the second most expensive, and so on with the carrier route presort level being the least expensive. Indeed, a patron preparing a bulk shipment of mail can achieve a considerable postage savings depending upon the extent to which the mailpieces included in the shipment qualify for the less expensive presort levels.
Qualifying for a particular presort level involves more than the degree (five or nine digit) and manner (barcoded or not) by which ZIP code information is provided on the mailpieces. For a mailpiece to qualify for most of the presort levels, the DMM further requires that the mailpiece be included as a part of a package (a specified number, such as 10 or more) of mailpieces packaged (i.e., associated by a rubberband) in accordance with specified criteria (such as the same carrier route, same 5 digit ZIP code destination, same 3 digit ZIP code prefix destination, for examples). In addition, to qualify for most of the presort levels, in accordance with specified criteria the postal patron must place the packages in a sack along with other mailpieces, and the sack must contain at least a specified minimum number of pieces (or have at least a specified minimum weight). Examples of such specified criteria for inclusion of mailpieces in the same sack are that the mailpieces either be destined to the same carrier route, the same 5 digit ZIP code destination, or the same 3 digit ZIP code prefix destination.
In addition to complying with the foregoing package and sack requirements, the postal patron must apply a label or tag, having a prescribed format, to each sack. As required by the DMM, the sack tag or label must include select information regarding the contents of the sack.
.

20~3~S

Thus, in order to obtain the maximum possible postage savings for each mailpiece, a postal patron must presort the mailpieces in accordance with ZIP code; must attempt to associate mailpieces in accordance with DMM specifications into packages; must attempt to associate packages in accordance with DMM specifications into sacks; and, must generate a label for each sack in accordance with the format prescribed by the DMM. It should become apparent that factors such as insufficient quantity and thin geographical distribution may disqualify many of the mailpieces included in a bulk shipment from receiving the most favored presort level. A greater postage rate associated with a less favored presort level must be paid for a mailpieces disqualified from the most favored presort level.
Large bulk shipments of mail can be presorted in ZIP
code groupings using automated sorting machines, such as those provided by the Bell & Howell Phillipsburg Company. Examples of such automated sorting machines include the Bell & ~owell Phillipsburg Company model 1000, 800, and 600 Mail Processing Systems. These automated sorting machines read optical characters and/or bar code and sort mail into bins.
While the prior art automated sorting machines cited above perform admirably for their initially intended purposes, the machines still required much human thought in the preparation of packages and associating of packages into sacks for obtaining the more favorable presort levels. In this respect, a human operator must mentally determine how to associate into packages and sacks mailpieces from numerous and often non-adjacent bins of the sorting machine. Such tedious determinations are subject to human error. Erroneous packaging and sacking of mailpieces causes considerable consternation with the United States Postal Service, and may jeopardize or render suspect the entire bulk mail shipment.
In order to qualify as many mailpieces as possible for the most favored presort levels, many companies and organizations send their bulk shipments to a third party company such as a presort agency for combining with the bulk , . .. .

2 0 5 3 ~ ~ ~

shipments of other companies and organizations. By combining the bulk mail shipments of several postal patrons, and by presorting the combined mail for the several patrons on the automated sorting machines described above, the presort agencies are often able to leverage the quantity and geographical distribution factors in order to qualify the maximum number of mailpieces for the most favored presort levels. Unfortunately, since some mailpieces do not achieve the most favored presort levels, it is very difficult for the presort agencies to allocate the postage costs (e.g., qualified discount vs. non-qualified postage rate) incurred among the contributing patrons.
Moreover, some postal patrons meter the mailpieces included in a bulk shipment with postage prior to condusting their own in-house sorting or prior to sending the shipment to a presort agency. In such cases, it may turn out that a mailpiece pre-metered at a rate for a favored presort level may not qualify for that presort level, with the result that additional postage must be applied to that mailpiece. When the mailpieces of more than one patron are combined or commingled, as at a presort agency, it is very difficult from an accounting standpoint to allocate the resultant postage increase triggered by the non-qualifying pre-metered mailpiece to the postal patron from whom the mailpiece came.
As mentioned above, some postal patrons meter the mailpieces included in a bulk shipment prior to the sorting operation (either in-house or at a presort agency). Other postal patrons use the "permit" mail provisions of the United States Postal Service. Traditionally the United States Postal Service has refused to accept bulk shipments that include both pre-metered and permit mail, in view inter alia of the difficulty in verifying the accuracy of the computed postage amounts.
In view of the foregoing, it is an object of the present invention to provide a sorting method and apparatus for associating mailpieces in a manner conducive for collection and 2053~55 associating into packages and sacks for obtaining desired postage presort levels.
An advantage of the present invention is the provision of method and apparatus for sorting mailpieces and for providing reports indicative of the postage presort levels into which mailpieces are classified.
Another advantage of the present invention is the provision of method and apparatus for sorting mailpieces wherein sack labels are automatically generated for sacks of mail.

SUNMARY

A mail sorting machine includes an input hopper; a mailpiece reading and processing section; and, a sorting bin section comprising a plurality of bins. The reading and processing section includes a CPU which executes a program ANALYZE MAIL for sorting third class mailpieces. The program ANALYZE_MAIL sorts the mailpieces included in a batch into packages, and then associates the packages into sacks or bags.
The program ANALYZE_MAIL constructs the packages and sacks to obtain maximum postage discounts.
Upon an initial physical pass of all mailpieces of a batch through the sorting machine, the program ANALYZE MAIL
generates output advising how the bins are to be associated for subsequent passes. As a result of the first physical pass, the program ANALYZE_MAIL classifies the mailpieces of the batch into a plurality of "groups". A "group" is a set of mailpieces which is to be separately sorted, independently from the remainder of the batch, during one or more "passes" of the sorting machine. For example, after the first or initial physical pass, for a first subsequent pass only a first group of mailpieces i5 loaded into the input hopper; for a second subsequent pass only a second group of mailpieces is loaded into the input hopper; and so forth. In general, during the first physical pass, mailpieces belonging to a first group are assigned to a first set of bins; mailpieces belonging to a , ~ , . .

`` 2~34~5 second group are assigned to a second set of the bins; and so forth.
In addition to assigning mailpieces to specified groups (i.e., bins) during the first physical pass, the program ANALYZE MAIL also generates a report which informs the operator from which bins to collect each group. Advantageously, each group is collected from physically ad~acent bins. Moreover, the program ANALYZE_MAIL also generates a report for each group, which report indicates from which bins mailpieces are to be collected into sacks. Advantageously, the sack is composed of mailpieces from physically adjacent bins. Further, the program ANALYZE_MAIL generates "bag tags" (also known as "sack tags") for each sack, with the bag tag bearing info~mation to apprise the operator from which bins to gather the contents of the sack, as well as the sack and group number.
The program ANALYZE_MAIL also includes an accounting capability for billing postage to a possible plurality of clients having mailstreams included in the batch, and for allocating postage costs in accordance with whether the client's mailpieces qualify for postage discounts BRIEF DE8CRIPTION OF T~B DRAWING8 The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
Fig. 1 is a top schematic view of a sorter apparatus according to an embodiment of the invention.
Fig. 2 is a schematic view of electronic circuitry included in the sorter apparatus of the embodiment of Fig. 1.

Fig. 3 is an isometric view of an edge post and hook assembly provided thereon according to the embodiment of Fig.
1.
Fig. 4 is a schematic view showing the interrelationships between Figs. 4A - 4N.
Figs. 4A - 4N are schematic views showing a series of functions and their constituent steps executed in accordance with a program ANALYZE_MAIL by the sorter apparatus of the embodiment of Fig. 1.
DETAILED DESCRIPTION OF THE DR~WINGS

Fig. 1 shows a sorter apparatus 20 according to an embodiment of the invention. The sorter 20 includes a reading and processing section 22 and a sorting bin section 24. The sorting bin section 24 includes a plurality of bins 26 into which mailpieces are ultimately sorted. In one embodiment, 128 such bins 26, numbered as bins 261-26l28, are provided (although not all of the 128 such bins 26 are illustrated in Fig. 1).
It should be understood that in other embodiments a different number of bins are provided.
The processing section 22 includes an input hopper 30:
a feeder 31; and a mailpiece transport assembly 32 which directs mailpieces along a processing path 33. Along the processing path 33 are various processing stations also included in the processing section 22, including an optical character recognition (OCR) station 34; an ink jet printer station 36; a bar code reader station 38.
As shown in Fig. 1, a plurality of hopper floor belts 40 and hopper augers 42 transport incoming mailpieces on edge in the direction of arrow 44 toward the feeder 31. The feeder 31, being of a rotating belt variety, feeds the leading mailpiece in the hopper 31 in the direction of the processing path 33 (i.e., in the direction of arrow 46). The mailpieces travel on edge down the processing path 33 along the OCR
station 34, the ink jet printer station 36, the bar code reader section 38, and into the sorting bin section 24.

\ 20~3~55 The processing section 22 also includes an operator console 50 and a data processing system 52. The data processing system 52 includes a central processing unit (CPU) 54 and an I/O interface 56 ~see Fig. 2). The CPU 54 communicates through the I/O interface 56 to various peripheral devices, including a keyboard 58; a monitor 60; a report printer 62; a bag tag or sack tag printer 64; and, a disk drive 66 (see Fig. 2). In addition, the CPU 54 communicates through the I/O interface 56 to electronics for the aforementioned OCR
station 34; ink jet printer station 36; bar code reader station 38; and, operator console 50.
The operator console 50 includes a start switch 70 and stop switch 72, as well a feed select switch 74 and a series of status indicator lights 76. The feed select switch 74 is used to control the rate at which the feeder 31 feeds mailpieces from the input hopper 30 toward the mail processing path 33.
The sorting bin section 24 includes a central transport assembly 80 which directs mailpieces along a sorting path that i5 collinear with the processing path 33 of the processing section 22. That is, the central transport assembly 80 of the sorting bin section 24 continues to transport a mailpiece in the direction of arrow 46 through the sorting bin section 24 ~mtil the mailpiece is deflected into an appropriate one of the bins 26. The central transport assembly 80 includes a plurality of unillustrated transport belts.
As shown in Fig. 1, bins are provided on both sides of the sorting path in paired relationship. That is, at the same distance from the processing section 22, bin 26l is paired with bin 26128; a little further downstream bin 262 is paired with bin 26127; and so forth until the downstream-most pair of bins 2664 and 2665-The sorting path is defined by a plurality of diverter gates 82 and sorting path walls 84. Each bin 26 has a diverter gate 82 and a sorting path wall 82 associated therewith. When activated, a diverter gate 84 pivots about a pivot point (such as pivot point 86 shown with respect to diverter gate 821 of ,,, -~ 20~3~

bin z6l) for diverting a mailpiece from the sor~ing path into its respective bin. Each sorting path wall 84 has a rear ramp surface 88 inclined with respect to the sorting path. The rear ramp surface 88 and the diverter gate 82 form a planar surface inclined with respect to the sorting path when the diverter gate 82 is pivoted to deflect mailpieces out of the sorting path and into the bin 26. The angle of inclination of this planar surface including the rear ramp surface 88 facilitates direction of the on edge mailpiece into the queue of mailpieces developing in the bin.
In addition to the rear ramp surface 88, a bin 26 is defined by a horizontal bin floor 90 and a leading edge abutment rail 92. The leading edge abutment rail is suspended above the horizontal bin floor 90 between the sorting path wall 84 and a vertical edge post 94. As shown in Figs. 1 and 3, the leading edge abutment rail extends through an aperture provided in a travelling vertical plate 96. The bin floor 90 has an auger 98 provide therein which transports mailpieces diverted into the bin 26 in a direction perpendicular and away from the sorting path. For example, with reference to bin 261, the auger 981 directs deflected mailpieces away from the sorting path in the direction of arrow lO0. The leading or first such mailpiece deflected into a bin 26 contacts the travelling plate 96. As successive mailpieces are diverted into a bin 26 and interposed between the ramp surface 88 and the previous mailpiece, the travelling plate 96 is slidingly pushed along the abutment rail 92 away from the sorting path toward the edge post 94. Near the edge post 94 a pressure sensor switch 102 is provided to detect when a bin 26 is becoming full. In this respect, when a sufficient number of mailpieces are diverted into a single bin 26 such that the travelling plate 96 closes the pressure sensor switch 102 for that bin, the sorting operation is temporarily halted an a diagnostic message is provided to the operator so that mailpieces diverted to the bin can be manually removed for accommodating additional mailpieces in that bin.

~ ,i .. . .

2053~5 As is shown in Fig. 3, each edge post 94 has hook assembly 104 provided thereon for engaging mail sacks, for example. The hook assembly 104 comprises two perpendicular bracket members 106a and 106b. The hook assembly 104 is mounted on the edge post 94 by fasteners 108 which extend through the bracket member 106a. The bracket member 106b has two U-shaped hooks 110 provided thereon. The hooks 110 engage one of the metal rings 112 provided around the mouth of a mail sack 114.
Referring again to the diverter gates 82 provided along the sorting path, each diverter gate 82 is activated by a solenoid 120. The solenoids 120 of each pair of bins are controlled by bin pair controller 122, there being 64 such bin pair controllers 122 shown in the embodiment of Fig. 1. Bin pair controller 1221 controls the solenoids 1201 and 120128 for bins 261 and 26128, respectively; bin pair controller 1222 controls the solenoids 1202 and 120127 for bins 262 and 26127, respectively; and so forth.
The bin pair controllers 122 are connected in series to the I/0 interface 56 of the data processing system 52 in shift register fashion along line 124. The signal carried on line 124 is a digital signal indicative of the bin number to which a mailpiece should be directed in accordance with the sorting operation. The signal from the I/0 interface 56 is first applied to the bin pair controller 1221 as a mailpiece approaches diverter gates 821 and 82128. If the signal indicates that the mailpiece is destined for either bin 261 or bin 26l28, the bin pair controller, upon evaluating the signal, causes activation of the appropriate solenoid 120. If the signal indicates that the mailpiece is destined for another downstream bin 26, the signal for that mailpiece is shifted downstream to the bin pair controller l222 as the mailpiece approaches diverter gates 822 and 821z7 associated with bins 262 and 261z7. The bin pair controller 1222 then either activates an appropriate solenoid 120 or shifts the signal yet further downstream along with the travelling mailpiece.

.

~053~5~
11 ~
The data processing system 52, and particularly the CPU
54 executes a set of instructions that control the operation of the sorter 20. That set of instructions in collectively referred to as program ANALYZE_MAIL. The program ANALYZE_MAIL
consists of numerous subsets of instructions coded in the "C"
programming language, which subsets are referred to herein as "functions". Execution of the program ANALYZE_NAIL and its constituent functions causes the sorting machine 20 to operate in the manner described below. In connection with the ensuing description of the operation of the sorting machine 20, it should be understood that the word "bundle" is often used interchangeably with "package", and that the word "bag" is often used interchangeably with "sack".

OPERATION
In the operation of the sorting machine 20 of Fig. 1, a batch of third class mail is placed in the input hopper 30.
The batch may comprise a plurality of mailstreams from a plurality of patrons. In the example discussed hereinafter particularly with reference to the TABLES, the batch includes mailstreams from an insurance company patron, a utility company patron, and a publishing company patron. The insurance company actually contributes three separate mailstreams to the batch, in particular an automotive insurance mailstream, a life insurance mailstream, and a health insurance mailstream.
After the mailstreams are all loaded into the input hopper 30, and when the CPU 54 is running the program ANALYZE_MAIL and the start switch 70 is turned on, the operator activates the feed select switch 74. Activation of the feed select switch 74 initiates a first physical pass of the mailpieces through the sorter 20, which includes transport of the mailpieces through the input hopper 30 in the direction of arrow 44; through the processing section 32 (in the direction of arrow 46); and, into the sorting bin section 24. As each mailpiece is transported through the processing section 22, the OCR 34 reads the character address; the ink jet printer 36 2053~5 prints a barcode corresponding to the character-read ZIP code;
and, the bar code reader 38 verifies the printed bar code.
As discussed hereinbefore, the program ANALYZE_MAIL
executed by sorting machine 20 collectively sorts the entire 5batch, comprising the mailstreams of all the patrons, in order to achieve the optimum third class postage discounts in accordance with the DMM. In order to do so, the program ANALYZE MAIL associates the mailpieces of the batch into "packages" (also known as "bundles"), and the packages are 10associated into sacks or bags.
In the above regard, the program ANALYZE_MAIL creates four different package types, notably: five digit (or "5") packages; three digit ("3") packages; state ("S") packages;
and, mixed state (or "M") packages. Generally, packages must 15consist of ten (10) or more mailpieces satisfying the same package ZIP code rule. For example, all the mailpieces in a FIVE DIGIT package must be destined for the same fiYe digit zip code. All the mailpieces included in a THREE DIGIT package must have the same three initial three ZIP code digits (e.g., 2022~.51, 22153, 22155, 22165). All the mailpieces included in a single STATE package must have initial ZIP code digits which destine the mailpieces to the same state (e.g., to Illinois).
As is more fully explained by the DMM, to qualify for certain third class postage discounts, the packages must in 25turn be placed into sacks consisting of a minimum number of mailpieces (or a minimum weight). Typically the minimum number of mailpieces per sack is 125, or alternatively the minimum weight is 15 pounds. Accordingly, the program ANALYZE MAIL
creates four different sack types: FIVE DIGIT sacks;
30THREE_DIGIT sacks; STAT~ sacks; and MIXED STATE sacks.
As a result of the first physical pass, the program ANALYZE MAIL classifies the mailpieces of the batch into a plurality of "groups". A "group" is a set of mailpieces which is to be separately sorted, independently from the remainder 35of the batch, during one or more "passes1' of the sorting machine 20. For example, after the first or initial physical pass, for a first subsequent pass only a first group of .

20~345~

mailpieces is loaded into the input hopper 30: for a second subsequent pass only a second group of mailpieces is loaded into the input hopper 30; and so forth. In general, during the first physical pass, mailpieces belonging to a first group are assigned to a first set of bins 26; mailpieces belonging to a second group are assigned to a second set of the bins 26; and so forth.
In addition to assigning mailpieces to specified groups (i.e., bins) during the first physical pass, the program ANALYZE_MAIL also generates a report in the form of TABLE 1 which informs the operator from which bins 26 to collect each group. Advantageously, each group is collected from physically adjacent bins 26. Moreover, the program ANALYZE_MAIL also generates a report in the form of TABLE 2A for each group, which report indicates from which bins mailpieces are to be collected into sacks. Advantageously, the sack is composed of mailpieces from physically adjacent bins 26. Further, the program ANALYZE MAIL generates "bag tags" (also known as "sack tags") for each sack, with the bag tag bearing information to apprise the operator from which bins 26 to gather the contents of the sack, as well as the sack and group number. A format for a plurality of bag tags is illustrated in TABLE 3.
In addition, during the first physical pass, the program ANALYZE_MAIL generates a number of accounting reports as exemplified by TABLES 4, 5, 6, and 6A discussed infra.

Function FIRST 80RT PASS
As a result of the execution of a function FIRST_SORT_PASS, three files are created during the first physical pass, including file COUNT.DAT, file AGGR.DAT, and CLIENTl.DAT. The creation of these three files is indicated by steps 200, 202, and 204 in Fig. 4A.
The size of the file COUNT.DAT (i.e., the number of records in the file) depends on the number of unique zip codes and mailstreams encountered during the first physical pass.
The format of each record in file COUNT.DAT is as follows:

.... .

, 20~34~

byte offset Zip Code - 4 bytes (long integer) o Stream Index - 1 byte (hex/binary value) 4 Client Index - 1 byte (hex/binary value) 5 Bin - 1 byte (hex/binary value) 6 5 Digit OCR/BCR count - 2 bytes (unsigned integer) 7 Zip + 4 OCR count - 2 bytes (unsigned integer) 9 Zip + 4 Barcoded count - 2 bytes (unsigned integer) 11 After the first physical pass, the records in file COUNT.DAT are sorted in ascending order. In this respect, a primary sortation is done by ZIP code. For ZIP codes repeated due to their usage in different client/mailstreams, a secondary sortation is performed by first sorting the client index number, followed by the stream index number.
The following is an example of how multiple records in the file COUNT.DAT are stored (note that the binary values are convèrted to ascii for display purposes):
ZIP CODE stream client bin 5 Diqit ZIP+4 ZIP+4 Barcoded 406770000 1 1 5 o 1 3 File AGGR.DAT is a binary file of fixed length. Each entry is four bytes long representing a long integer. The first 256 entries is an array of bin counts where each individual bin count is indexed by bin. The 257th entry represents the total number of mailpieces fed, the 258th entry represents the total number of mailpieces read, and the last entry represents the total 5 Digit ZIP count (OCR and Barcoded mailpieces). The following summarizes the file format for file AGGR.DAT:

counts by bin - 256 entries, each entry 4 bytes total fed - 1 entry 4 bytes long total read - 1 entry 4 bytes long total 5 Digit count - 1 entry 4 bytes long - , .
:: .

2053~5~

The file CLIENTl.DAT is a binary file containing ten bytes per record. Each record contains the following data and is presented in order:
byte offset #
Stream Index - 1 byte (hex/binary value) o Client Index - 1 byte (hex/binary value) Total Fed Count - 4 bytes (long integer) 2 Total Reject Count - 4 bytes (long integer) 6 File CLIENTl.DAT contains a variable number of records, depending on the number of unique clients and mailstreams used.
The records in this file are sorted in ascending order. A
sortation is performed by first sorting the client index number followed by the stream index number.
The following discussion describes other steps executed by the CPU 54 in connection with a plurality of functions included in the program ANALYZE MAIL.
Function AB~IGN PACKAGE~
The function ASSIGN_PACK~GES (see Fig. 4A) takes records from file COUNT.DAT and assigns package types to each zip code. The package types are reflected by the numbers "5"
and "3" and the letters "S" and "M". A package type of "5"
refers to a five digit package; a package type of "3" refers to a three digit package; a package type of "M" refers to mixed states package; a package type of "S" refers to a state package.
During the first pass through the records in the file C~UNT.DAT, the function ASSIGN PACKAGES initially examines each record in the file COUNT.DAT in the record order noted above in ordex to determine potential three digit packages (i.e., packages wherein all the mailpieces have identical first three ZIP code digits~ but which do not ~ualify as five digit packages) [reflected by step 250] and potential state packages [reflected by step 252]. In this regard, the function ASSIGN PACKAGES e~amines the field ZIP CODE for the current record to determine whether the record has the same ZIP code ., .

2053~5 as did the next previous record. (Consecutive records might have the same ZIP codes when the same ZIP codes are present in different mailstreams). If the ZIP code for the currently examined record is the same as the previous record, the function ASSIGN PACKAGES determines the total number of mailpieces represented by the record by adding the values in the "5 Digit", "ZIP+4", and "ZIP+4 Barcoded" fields of the record and adds that sum to a running total mailpiece counter (in location CNT) for this ZIP code.
If the ZIP code for the currently examined record differs from tha previous record, the function ASSIGN_PACKAGES
momentarily lays aside the current record to process the mailpiece count for the previous ZIP code (i.e, the ZIP code for the previous record). In this respect, the function ASSIGN PACKAGES determines whether the number of mailpieces for the previous ZIP code was less than the predetermined minimum bundle size. If it was, the function ASSIGN_PACKAGES realizes that the previous ZIP code might qualify for a three digit package. To do this, the function ASSIGN PACKAGES determines to what 3 Digit ZIP code the previous ZIP code belongs (i.e, determines the first three digits of the previous ZIP code).
The function ASSIGN PACKAGES then assigns the total count of the number of mailpieces for the previous ZIP code (stored at location CNT~ to a three digit package counter for the 3 Digit ZIP code to which the previous ZIP code belongs (i.e, to counter THREE DIGIT_PACK_CNT[3_DIGIT_ZIP]).
After processing the mailpiece count for a previous ZIP
code in the manner described above, the function ASSIGN PACKAGES returns to processing the ZIP code for the current record. At this juncture, the function ASSIGN PACKAGES
assigns to the mailpiece counter CNT the sum of the values in the "5 Digit", "ZIP~4", and "ZIP+4 Barcoded" fields of the current record. The function ASSIGN_PACKAGES then examines the next record in the file COUNT.DAT, and continues the process described above for each such record until an end of file is encountered.

20~3~5 After determining the potential three digit packages at step 250, the function ASSIGN_PACKAGES attempts to locate potential state packages (step 252). In this regard, the func:tion ASSIGN_PACKAGES compares the number of mailpieces assigned to each 3 Digit ZIP code with the predetermined minimum number of mailpieces necessary to make up a package (e.g., 10). If the actual number of counted mailpieces for an 3 Digit ZIP code is less than the predetermined minimum, the function ASSIGN_PACKAGES determines with which state the 3 Digit ZIP code is associated, and increments a state package counter for that state (i.e., STATE_PACK CNT(i); where i = a number corresponding to the associated state). Also, if the number of counted mailpieces for an 3 Digit ZIP code is less than the predetermined minimum, the corresponding three digit package counter (THREE DIGIT_PACK_CNT) is set to zero.
Having determined potential three digit packages and potential state packages in the manner described above (steps 250 and 252), the function ASSIGN_PACKAGES then conducts a second pass through the file COUNT.DAT in order to create a temporary file SACKl.TMP (step 254). As will be seen later, the file SACKl.TMP is used by function ASSIGN_SACKS to generate a file SACK2.TMP. The file SACKl.TMP contains multiple records of the following structure:

struct PACKAGE
unsigned long ZIP_ID; /* zip identifier */
unsigned long CNT; /* count */
char PTYPE; /* package type */
unsigned char BIN; /* bin assignment */
}

Thus, the file SACKl.TMP is much reduced in size from the file COUNT.DAT since the multiple zip_id entries due to client/mailstream selections are combined. Also, the three different count categories ("ZIP+4"; "5 Digit": and "ZIP+4 Barcoded") are combined into one count value (CNT) since the sortation of mail only depends on the combined count. The file SACKl.TMP is created in ZIP code order.

2~4~5 As mentioned above, the function ASSIGN_PACKAGES
creates the file SACKl.TMP during the second pass through the file COUNT.D~T (step 254). During the second pass through file COUNT.DAT the function ASSIGN_PACKAGES examines each record of file COUNT.DAT in a manner similar to the first pass. The function ASSIGN_PACKAGES determines whether the ZIP code for each currently examined record in file COUNT.DAT is the same as for the previous record. If the ZIP code is the same, the function ASSIGN_PACKAGES determines the total number of mailpieces represented by the record and adds that number to a cumulative counter (CNT) for the total number of mailpieces for that ZIP code.
When, during the second pass through file COUNT.DAT, the function ASSIGN_PACKAGES encounters a record having a ZIP
code which differs from the previous ZIP code (i.e., the ZIP
code of the previous record)~ the function ASSIGN_PACKAGES
prepares a record for file SACKl.TMP for the previous ZIP code.
In this respect, in creating the record, the previous ZIP code is stored in the ZIP_ID field of the structure PACKAGE and the current value of the counter CNT is stored in the CNT field of the strUCtUre PACKAGE. A value for the bin assignment (BIN) for the mailpieces for thiS package is obtained from the corresponding "bin" field from the record in the COUNT.DAT
file. The value for the package type (PTYPE) is determined as follows.
In determining the package type (PTYPE) for a package of mailpieces, the function ASSIGN_PACKAGES determines whether the total number of mailpieces for the ZIP code (stored in location CNT) exceeds the predetermined minimum package size ~e.g., 10). If the predetermined minimum is equalled or exceeded, the function ASSIGN_PACKAGES assigns a "5" value to the PTYPE field for the record in the structure PACKAGE
associated with this ZIP code. The "5" valua in the PTYPE
field is indicative of the fact that the package is a "5 Digit Package", meaning that all the mailpieces in this package have the identical first five digit ZIP codes.

205345~

If the total number of mailpieces for the ZIP code is iess than the predetermined minimum package size, the function ASSIGN_PACKAGES determines to what 3 Digit ZIP code this ZIP
code belongs. Then the function ASSIGN_PACKAGES determines 5 whether the three digit package counter (THREB_DIGIT_PACK_C~NT~_DIGI~_ZIP] ) for the 3 Digit ZIP code equals or exceeds the predetermined minimum package size. If (THREE_DIGIT_ PACX_CNT~3_DIGIT_ZIP~) for the 3 Digit ZIP code equals or exceeds the predetermined minimum package size, then 10 the function ASSIGN_PACKAGES assigns a "3" value to the PTYPE
field for the record in the structure PACKAGE.
If the total number of mailpieces for the 3 Digit ZIP
code is less than the predetermined minimum package size, the function ASSIGN_PACKAGES determines to what state this 3 Digit 15 ZIP code belongs. Then the function ASSIGN_PACKAGES determines whether the state package counter (STATE_PACK_CNT) for this state equals or exceeds the predetermined minimum package size.
If the state package counter for this state equals or exceeds the predetermined minimum package size, then the function ASSIGN_PACKAGES assigns a "S" value to the PTYPE field for the record in the structure PACKAGE.
If the function ASSIGN_PACKAGES cannot assign a "5", "3", or "S" value to the PTYPE field for this record in the SACKl.TMP file, a "M" value (indicative of "Mixed State Packages) is assigned to the PTYPE field.

Function AS8IGN_SAC~S
Function ASSIGN_SACKS (see Fig. 4A) uses the f ile SACKl. TMP created by function ASSIGN_PACKAGES to generate 30 another file (file SACK2.TMP). In so doing, function ASSIGN_SACKS makes tentative sack assignments.
The file SACK2.TMP is a temporary work file for making sack assignments to ZIP codes. Once created by function ASSIGN SACKS, the file SACK2. TMP contains multiple records of 35 the following structure:

205~55 struct SACK
{

struct PACKAGE package;
int N0; \*bag ID number*~
char STYPE \*sack type*\

where the structure PA~KAGE is as formerly defined.
There are five possible sack assignments: FIVE_DIGIT;
MIXED_FIVE; THRE~_DIGIT; STATE; and MIXED_STATES.
The function ASSIGN_SACKS reads through the file SACKl.TMP in two passes. During the first pass, the function ASSIGN_SACKS obtains certain sack counts. During the second pass, the function ASSIGN_SACKS generates the file SACK2.TMP.
During the first pass through the file SACKloTMP~
function ASSIGN_SACKS determines the 3 Digit ZIP code and the package type (PTYPE) assigned to each record in the file SACKl.TMP. If the package type (PTYPE) of a record is "5", the package count (CNT) for that package is checked to determine whether the package contains enough mailpieces to be its own sack (step 260). This is done by comparing the package count (CNT) value of the package to a predetermined minimum mailpiece number necessary to make up a sack ("MIN MAI~"). If the pack~ge count (CNT) does not qualify the package to be its own sack, then the function ASSIGN_SACKS realizes that this type package may be part of a MIXED_FIVE; THREE_DIGIT; STATE;
or MIXED_STATES sack. Accordingly, for the 3 Digit ZIP code corresponding to the ZIP code for the current package, the function ASSIGN_SACK5 adds the package count (CNT) to a "mixed five sack counter" (MIXED_FIVE_SACK_CNT[3_DIGIT_ZIP]) [step 262].
For packages belonging to the other types (PTYPE = 3, S, or M), the function ASSIGN_SACKS adds the package count (CNT) to the appropriate counter (step 262). For example, for a record in SACKl.TMP having a PTYPE = 3, the function ASSIGN SACKS adds the package count (CNT) of that record to a "three digit sack counter" ~THREE_DIGIT_SACK_CNTt3_DIGIT_ZIP]) for the 3 Digit ZIP code for the ZIP code of the record.

2053~5 Similarly, a unique counter exists for each state (STATE_SACK_CNT) and each mixed state (MS_SACK_CNT).
The function ASSIGN_SACKS then checks the potential mixed five, three digit, and state sack counts (step 264).
First, for each 3 Digit ZIP code, the function ASSIGN_SACXS
checks the value of the counter MIXED_FIVE_SACK_CNT to determine whether each potential mixed f ive sack has the predetermined minimum number of mailpieces to be a sack. If the counter MIXED_FIVE_SACK_CNT falls short of the predetermined minimum number, then it is assumed for the moment that these mailpieces, previously thought to comprise a mixed five sack, should now comprise a three digit sack. To this end, the value of the counter MIXED_FIVE_SACK_CNT [ 3_DIGIT_ZIP]
for this 3 Digit ZIP code is added to the counter THREE_DIGIT_SACK_CNT[3_DIGIT_ZIP] for the 3 Digit ZIP code.
The value of the counter MIXED_FIVE_SACK_CNT for this 3 Digit ZIP code is then re-initialized at zero.
In the Same manner the function ASSIGN_SACKS checks the number of mailpieces in each potential three digit sack to insure that the potential sack has the predetermined minimum number of mailpieces to qualify as a sack. If the value of THREE_DIGIT_SACK_CNT[3_DIGIT_ZIP] does not have the predetermined minimum number of mailpieces, it is assumed that these mailpieces should now be part of a state sack.
Accordingly, a state sack counter (STATE_SACK_CNT) for the state having the concerned 3 Digit ZIP code is incremented by the value of the THREE_DIGIT_SACK_CNT[3_DIGIT_ZIP], and the value of the counter THREE_DIGIT_SACK_CNT[3_DIGIT_ZIP] is reinitialized at zero.
In the same manner the function ASSIGN_SACKS checks the number of mailpieces in each potential state sack to insure that the potential state sack has the predetermined minimum number of mailpieces to qualify as a sack. If the value of STATE_SACK_CNT for the state does not have the predetermined minimum number of mailpieces, it is assumed that these mailpieces should now be part of a mixed state sack.
Accordingly, a mixed statP sack counter (MS_SACK_CNT) is 22 20~3455 incremented by the value of the STATE_SACK_CNT for the affected state, and the value of the counter STATE_SACK_C~T for the affected state is reinitialized at zero.
During the second pass through the file SACKl.TMP the function ASSIGN_SACKS uses the data in the file SACKl.TMP and the various sack counters described above (MIXED_FIVE_SACK_CNT;
THREE_DIGIT_SACK_CNT, STATE_SACK_CNT; and, MS_SACK_CNT) to create the new file SACK2.TMP ~step 266). As the function ASSIGN_SACKS reads through each record in file SACKl.TMP, the function ASSI~N_SACKS again examines the pacXage type (PTYPE) and obtains the 3 Digit 2IP Code corresponding to the ZIP code stored in the record. For records in SACKl.TMP having a record type "5" (i.e., PTYPE = 5) and a package count (C~T) exceediny the predetermined minimum number required to form sack, a record is created in f ile SACK2 . TMP having a five digit sack type value (STYPE = FIVE DIGIT).
If a record has a record type "5" but does not represent tha predetermined minimum number of mailpieces for a FIVE_DIGIT sack, the associated count is compared to see if it exceeds the minimum sack count for the next lowest priority sack type (i.e., sack type MIXED_FIVE) to which it belongs.
If it does, a record is created in file SACK2.TMP having a mixed five sack type value (STYPE = MIXED_FIVE). If the record does not represent the minimum sck count, the same type process is repeated for the remaining lower priority sacks in the order THREE DICIT, followed by STATE. If the record does not meet the minimum number for any of the above sack types, it ls assigned a MIXED STATES sack type.
For records in SACKl . TMP having a package record type of "3", a similar count comparison is performed as above.
However, the check begins with the THREE_DIGIT sack count level so only THR~E_DIGIT~ STATE, and MIXED_STAT~S assignments can be made.
For records in SACKl.TMP having a package record ~ype of "S" a similar count comparison is performed as above.
However, the check begins with the STATE sack count level so that only STATE and MIXED_STATES assignments can be made.

20~34~

Finally, all records having package type "M" are assigned a MIXED_STATES sack type.

Function FIR8T_PASS_PACgS
The function FIRST PASS PACKS (see Fig. 4B) determines which bins, as a result of the first sort pass, consist of completely sorted packages. In this regard, function FIRST_PASS_PACKS prepares an array FULLSORT_BIN having elements corresponding to each of the 128 bins 26 included in the sorter. As a result of the execution of function FIRST_PASS_PACKS, bins which do not contain a fully sorted package as a result of the first sort pass have a zero value stored in their corresponding element in array FULLSORT_BIN.
For example, if bin 263 does not include a fully sorted package, a "zero" value is stored in FULLSORT_BIN[3]. For any bin consisting of fully sorted packages, a unique non-zero number is stored in the element in array FULLSORT_BIN
corresponding to that bin number.
In the simple case (reflected by step 270), the determination of function FIRST_PASS_PACKS is made by comparing the number of mailpieces in a bin with the sum of the number of mailpieces included in all the packages in the bin. If the number o~ mailpieces in a bin equals the sum of the number of mailpieces included in all the packages in the bin, then the bin consists of fully sorted packages. For any bin consisting of fully sorted packages, a unique non-zero number is stored in the element in array FULLSORT BIN corresponding to that bin number.
For three digit and state packages the comparison is complicated by the fact that completely sorted package contents could end up in several first pass bins. Therefore, for three digit and state packages, the partial package counts from several bins making up one complete package are compared against the same several bins total piece count.
In order to process the three digit and state packages, the function FIRST PASS_PACKS reads through every record in the file SACK2.TMP (which was created by function ~SSIGN_SACKS) and 2~534~

creates two additional work files, i.e., STATE_PACK_FILE and THREE_PACK_FILE (step 272). For every record encountered in file SACK2.TMP that concerns a state package ~PTYPE = S), the function FIRST_PASS_PACKS duplicates that record in the file ST~TE_PACK_FILE. Likewise, for eVery record encountered in file SACK2.TMP that concerns a three digit package (PTYPE = 3), the function FIRST_PASS_PACKS duplicates that record in the file THREE_PACK_FILE.
To determine whether a potentially completely sorted state package is spread through a plurality of bins (step 274), for each state the function FIRST_PASS_PACKS determines what records in the file STATE_PACKS_FILE have ZIP codes belonging to that state. When a record in file STATE_PACKS_FILE pertains to the state, the function FIRST_PASS_PACKS sets a flag in an element of an array sIN_usAGE corresponding to the bin number indicated in the record. For example, if bins 267, 2655, and 2692 all have mailpieces belonging to a completely sorted state package~ flags are set at BIN_USAGE[7], BIN_USAGE~55~, and BIN USAGE[92].
Having noted the bins in which completely sorted state packages may reside, the function FIRST PASS PACKS then compares the total number Of mailpieces in the state package with the total number of mailpieces in all the bins for which a flag was set in array BIN_USAGE for the state of interest.
Recall that the number of mailpieces for each bin 26 is obtainabl~ from the file AGGR.DAT which was created during the first sort pass (i.e., at step 202).
If the total number of mailpieces in the state package is equal to the total number of mailpieces in all the bins for which a flag was set in array BIN_USAGE, then those bins are known to include mailpieces for the fully sorted state package.
For the bins including mailpieces for the fully sorted state package, the same non-zero number is placed in the elements of array FULLSORT_BIN corresponding to those bins. The non-zero number placed in each of the elements of array FULLSORT_BIN for the state is unique number which does not appear in array EULLSORT_BIN for any other state or any other purpose.

2053~

It should be understood that the foregoing processing related to state packages is conducted separately for each state. This requires that certain parameters, including the array sIN_usAGE, be reinitialized for each state. Likewise, whatever number entered into one or more elements of the array FULLSORT_~IN for a particular state will be a number unique to that state.
The function FIRST_PASS_PACXS also determines whether fully sorted three digit packages are spread through more than one bin (step 276). This determination is made in a similar manner as was the determination for state packages. That is, for each 3 Digit ZIP Code value the function FIRST_PASS_PACKS
reaas through the file THREE_PACK_FILE which it created, and ; determines whether mailpieces belonging to that 3 Digit ZIP
Code are in a plurality of bins. If so, the function FIRST_PASS_PACKS sets flags in array BIN_USAGE in the same manner as with the state packages. Then, in like manner as with the state packages, the function FIRST_PASS_PACKS
determines whether the total mailpiece count of the particular three digit package equals the sum of the bin counts for each of the bins in which the three digit package is spread. If an equality is de.termined, then function FIRST_PASS_PACKS realizes that the bins for which flags were set in array BIN_USAGE
contain the completely sorted three digit package. As with the completely sorted state packages, a unique number associate with this three digit package is assigned to each element in array FULLSORT_BIN corresponding to the bins wherein mailpieces belonging to this completely sorted three digit package reside.
Thus, upon completion of the execution of function FIRST_PASS_PACKS, an example of the contents of a portion of array FULLSORT_BIN might be as follows:

20~3~5~

FULLSORT_BIN[OOl] = O
FULLSORT _ BIN [ 002 ] - 1 FULLSORT _ BIN [ 003 ] - 0 EULLSORT _ BIN [ 004 ~ = 2 FULLSORT_BINtO05] = 2 FULLSORT _ BIN [ 006 ] = 3 FU~IJSORT_ BIN [ 007 ] = 3 FULLSORT_BIN[127] = O
FULLSORT_BINtl28] = O

Where a FULLSORT_BIN value of "o" indicates that the bin does not contain a completely sorted package; a value of "l"
indicates that a first fully sorted package is contained in bin 261; a value of "2" indicates that a second fully sorted package (perhaps a state package) is contained in bins 264 and 265; and, a value of "3" indicates that a third fully sorted package tperhaps a three digit package) is contained in bins 266 and 267.

Function M~XE ~ORT RECORDS
The function MAKE SORT R~CORDS (see Fig. 4s) maXes a file (file SORTRECl.TMP) which lists packages for second pass sorting and makes another file (file FU~LSORTl.TMP) which lists packages that will not be sorted in a subsequent pass. The function MAKE_SORT_RECORDS creates the files SORTRECl.TMP and FULLSOR~l.TMP after reading through the file SACK2.TMP (which was created by function ASSIGN_SACKS).
In reading each record from the file SACK2.TMP, the function MAKE_SORT_RECORDS determines to which type of package the record relates. In particular, the function MAKE_SORT RECORDS checks to see if the PTYPE for the record is either "5", "3", or ~S~'.
For a record in file SACK2.TMP having a PTYPE of "5", corresponding to a five digit package, the function MAKE_SORT_RECORDS duplicates the record either in file SORTRECl.TMP or file FULLSRTl.TMP (step 280). To determine to which file to duplicate the record, the function MAKE SORT RECORDS further checks to determine whether this five 27 20~34~5 digit package is in a ~ully sorted bin. This further check is conducted by noting the bin number included in the record, and then indexing into the array FULLSORT_BIN for that bin number.
If the array FULLSORT_BIN contains a non-zero value for that bin, the routine ASSIGN_PACKAGES concludes that the record is fully sorted and duplicates the record from SA~K2.~MP in the file FULLSORTl.TMP. Otherwise the function MAKE_SORT_RECORDS
duplicates the record from SACK2.TMP in the file SOR~RECl.TMP.
If the function MAKE_SORT_RECORDS determines that the PTYPE for a record in file SACK2.TMP is "3", corresponding to a three digit package, the function MAKE_SORT_RECORDS
determines the 3 Digit ZIP Code to which the record pertains.
Then the function MAKE_SORT_REcORDS notes the bin number stored in the record, and stores that bin number in an element of an array THREE_DIG_BIN corresponding to the pertinent 3 Digit ZIP
Code (step 282). Likewise, the function MAKE_SORT_RECORDS
notes from the record the sack type assignment (from STYPE), and stores that sack type in an element of an array THREE_DIGIT SACK TYPE corresponding to the pertinent 3 Digit_ ZIP Code (step 284).
If the function MAKE_SORT_RECORDS determines that the PTYPE for a record in file SACK2.TMP is "S", corresponding to a state package, the function MAKE_SORT_RECORDS determines the state to which the record pertains. Then the function MAKE_SORT_RECORDS notes the bin number stored in the record, and stores that bin number in an element of an array STATE_ BIN
corresponding to the pertinent state (step 286). Likewise, the function MAKE_SORT_RECORDS notes from the record the sack type assignment (from STYPE), and stores that sack type in an element of an array STATE_SACK_TYPE corresponding to the pertinent state (288).
After reading all the records in file SACK2.TMP, after storing information in the arrays ~HREE_DIG_BIN and THREE_DIGIT_SACK_TYPE for three digit package records, and after storing information in arrays STA~E_BIN and STATE SACK_TYPE for state package records, the function MAKE SORT_RECORDS is prepared to complete the writing of the 20~34~5 two output files SoRTRECl.TMP and EULLSORTl.TMP. The function MAKE_ SORT_ RECORDS f irst writes three digit packages to the appropriate one of the two output files (step 290), and then the state packages to ths appropriate one of the two output 5 files (292~, with the result that the two output files are sorted first by package type, and then within each package type by package ZIP.
In writing the three digit packages to the appropriate file (file FULLSORTl.TMP or file SORTRECl.TMP) at step 290, the routine MAKE_SORT_RECORDS checks to determine which elements of array THREE_DIGIT_PACK_CNT (generated by the function ASSIGN_PACKAGES), i.e. which 3 Digit ZIP Codes, have non-zero values, and write a record to the appropriate file only for those 3 Digit ZIP Codes. Similarly, the routine MAKE_SORT_RECORDS writes the state packages to the appropriate file (file FULLSORTl.TMP or file SO~TRECl.TMP) at step 292 only for those states having a number of mailpieces exceeding the predetermined minimum bundles size.
The formats for file FULLSORTl.TMP and SORTRECl.TMP are identical. In particular, the foxmats are both files are prescribed by the structure SACK, which was defined above in connection with the discussion of function ASSIGN_SACKS as including the structure PACKAGE (which, in turn, was defined above in connection with the discussion of the function ASSIGN_PACKAGES). But in creating these two files, the routine ASSIGN_PACKAGES must store the proper information in the structure PACKAGE portion of the structure SACK, particularly the fields for ZIP ID, CNT and BIN. It should be noted that only one record i5 written to a 3 Digit ZIP code, e.g., 60202 is written to ZIP_ID 602. Furthermore, only one record per state is written to FULLSORl.TMP and SORTRECl.TMP.
For each three digit package, the function MAKE_SORT_RECORDS obtains the information for fields CNT and BIN from the corresponding elements in the respective arrays THREE_DIGIT_PACK_CNT and THREE_DIGIT_BIN. Recall that array THREE DIGIT_BIN was generated by the function ~AKE_SORT_RECORDS
and that the array THREE_DIGIT_PACK_CNT was genexated by the 20534~a function ASSIGN_PACKAGES. To determine whether a record should be written to file FULLSORTl.TMP or to file SORTRECl.TMP, the function MAKE_SORT_RECORDS checks the status of array FULLSORT_BIN for the bin whose number is stored in the array THREE_DIGIT_BIN for the pertinent 3 Digit ZIP Code. If the value stored in array FULLSORT_BIN is non-zero, then a record is written to file FULLSORTl.TMP. Otherwise a record is written to file SORTRECl.TMP.
For each state package, the function MAKE_SORT_RECORDS
obtains the information for fields CNT and BIN from the corresponding elements in the respective arrays STATE_PACK_CNT
and STATE_BIN. Recall that array STATE_BIN was generated by the function MAKE_SORT_RECORDS and that the array STATE_PACK_CNT was generated by the function ASSIGN_PACKAGES.
lS To determine whether a record should be written to file FULLSORTl.TMP or to file SORTRECl.TMP, the function MAKE_SORT_RECORDS checks the status of array FULLSORT_BIN for the state. If the value stored in array FULLSORT BIN for the pertinent state is non-zero, then a record is written to file FULLSORTl.TMP. Otherwise a record is written to file SORTRECl.TMP.

Function 8ACR SORT
The function SACK_SORT (see Fig. 4C) creates a file SORTREC2.TMP using file SORTRECl.TMP (step 300). Each record in file SORTREC2.TMP has the format of the structure SACK
described above.
The function SACK SORT sorts the records in file SORTRECl.TMP by sack type (step 302), then within sack type by package type (step 304), and within package type by package ZIP id (step 306). The resultant sort creates the file SORTREC2.TMP. At the end of execution of the function SACK_SORT, mail iS not yet in the final "sack and bag" order, since further sorting is required by major tree as described below.

20~3~

Function SACK_SORT begins by scanning the file SORTRECl.TMP and writing all FIVE_DIBIT sack package entries to the output file SORTREC2.TMP. While scanning the input file, the count for each package type entry is recorded. Since the file SORTRE~l.TMP has been sorted by package type, the package type counts are used to determine the starting position of each different package type's entries.
Next, the file SORTRECl.TMP is scanned from the beginning and all MIXED_FIVE SACX package entries are appended to the output file.
since only one package type could go into FIVE_ DIGIT
and MIXED_FIVE sacks, it was a simple matter of copying sequential records marked with the appropriate sack type to the output file. For the remaining sack types (THREE_ DIGIT, lS STATE, and MIXED_STATES) multiple package types are allowed.
Therefore, much searching is required to ~ind the apprpriate next entry for the output file.
The THREE_DIGIT sack can be composed of both FIVE_DIGIT
and THREE_DIGIT packages. The first step is to determine if any entries exist for all possible package types. Then the function SACK_SORT repeatedly determines which of the existing package entries of sack type THREE_DIGIT (which are located in the input file by the starting position previously saved and count values of records already processed) corresponds to the first THREE_DIGIT sack entry and the appropriate record is appended to the output file with the ZIP_ID corresponding to the three digit ZIP of the sack. In addition, th~ processed record count for the selected package type is incremented.
This is done until all package entries have been processed.
The MIXED_STATES sack can be composed of both FIVE DIGIT, THREE_DIGIT, STATE, and MIXED_STATE packages. The first step is to determine if any entries exist for all possible package types. Since there is only one MIXED_STATES
sack, packages are written in package priority order until all entries are exhausted.
Upon completion of the execution of function SACK SORT, the ZIP_ID f ield in a record in f ile S0RTREC2.TMP is the 31 2()~34~i~
package ZI~ id, which is no longer necessarily the long integer value of the full 5 digit zip code with four zeros trailing in the "+4" position. The ZIP_ID for non-5 digit package mail may be the 3 digit zip (range o - 999) for 3 digit packages and a state index number (range 0 - 99) for state pac~ages. The BAG
field of the records in file SORTREC2.TMP are undefined at this point, since further processing is necessary to determine the appropriate values for this field.

Functio~ MAXE_COMBOS
The function MAKE_COMBOS (Fig. 4D) determines mandatory combinations of first pass bins for making up state packages and three digit packages. Function MAKE_COMBOS sets up the required data in an array BIN_C0MB0S to force mailpieces scattered across numerous bins by ineffective first pass sort schemes back into a single second pass groUp. Bins fully sorted on the first sort pass are pulled out since they are not part of second pass records.
The function MAKE_COMBOS first handles state packages.
For each state at step 310 the function MAKE_COMBOS reads each record in the STATE_PACK_FILE (which was created by function FIRST_PASS_PACKS) and determines (by reference to array FULLSORT_~3IN) whether the particular bin number contained in the record is a fully sorted bin (step 312). If the bin number for that record is fully sorted and the record belongs to the current state, the function MAKE COMBOS goes on to the read the next record in the array STATE_PACK_FILE (i.e., to step 310).
If the bin is not fully sorted, the function MAKE_COMBOS sets a ~`lag in an element of array BIN_USAGE corresponding to that bin, thereby indicating that the bin has mailpieces for the current state (step 314).
After the entire file STATE_PACK FILE has been read for a particular state (determined at step 316), at step 318 the function MAKE_ COMBOS calls another function, function 35 CHECK_ COMBOS, which actually sets up the data in array BIN_ COMBOS giving consideration to possible conflicting bin 20~345~

assignments. A detailed discussion of the function C~ECK COMBOS is provided below.
After the function CH~CK_COMBOS has been called for a particular state, as indicated by the affirmative result at step 320 the function MAKE_COMBOS moves on the next state and repeats the afore-described state package handling for that next state, including a call to function CHECK_COMBOS after reading through the entire STATE_PACK_FILE for that next state.
The function MAKE_COMBOS conducts the afore-described state package handling procedure for each state.
The function MAKE_COMBOS executes much the same procedure for the three digit packages as it did for the state packages. In handling the three digit packages, at step 330 the function MAKE_COMBOS reads the first record in the file THREE_DIGIT_PACK_ FILE (which was created by function FIRST_PASS_PACKS). As reflected by step 332 for example, in handling the state packages, the function MAKE_COMBOS ignores any records in the file THREE_DIGIT_PACK_FILE which pertain to fully sorted bins (determined by reference to array FULLSORT_BINS).
At step 334 the function MAKE_COMBOS obtains the first three digit ZIP code from the first record in the file THREE_DIGIT_ PACK_ FILE and stores that first ZIP code in a location THREE_DIG_ZIP. At step 336 the function MAKE_COMBOS
determines the bin number contained in that record: and, sets a flag in the element of array BIN_USAGE corresponding to that bin number.
Having processed the first record in file THREE_DIGIT_PACK_FILE, the function MAKE_COMBOS then reads through further records in the file THREE_DIGIT_PACX_FILE ( as reflected by step 340), noting the ZIP code stored in the record and storing the first three digits of the ZIP code in a location SCF (step 342). At step 344 the function MAKE COMBOS checks to determine if the value in location SCF
(the ZIP code for the most recently read record) is the same as the value in THREE_DIGIT_ZIP (see the preceding paragraph).
If so, the function MAKE_COMBOS (1) at step 346 sets a flag in 20~3~55 an element of the array BIN_USAGE corresponding to the bin number included in the most recently read record from file THREE_DIGIT_PACK_FILE (thereby indicating that the three digit ZIP code has mailpieces in that bin as well), and ~2) goes on to read the next record in file THREE_ DIGIT_ PACK_FILE (i.e., returns to step 340). If the next record in file THREE_DIGIT_PACK_FILE is read at this point, the function MAKE_COMBOS repeats the steps described in this paragraph with respect to that next recordO
If the function MAKE_COMBOS determines at step 344 that the value in location SCF (the ZIP code for the most recently read record) is not the same as the value in THR~E_ DIGIT ZIP, the function MAKE_COMBOS concludes its processing of the ZIP
code whose value is stored in location THREE_DIGIT_ZIP by: (1) calling function C~ECK_COMBOS (described below) at step 348 to set appropriate values in the array BIN_COMBO; (2) setting the value in location THREE_DIGIT_ZIP equal to the value in location SCF (at step 350); (3) at step 352 setting a flag in an element of the array BIN_USAGE corresponding to the bin number included in the most recently read record from file ~HREE_DIGIT_PACK_FILE: and, (4) repeatin~ the steps of the preceding paragraph for the next record in file ~HREE_DIGIT_PACK_FILE (e.g., by returning to step 340). The processing of three digit packages continues in this manner until all three digit packages have been processed (step 354), after which the function MAKE_SACK_COMBOS is called (skep 356).

Function CHECR COMBOS
The function CHECK_ COMBOS is called by the function MAKE_COMBOS ~described above) in order to resolve any conflicting bin assignments and to store data in the array BIN_COMBOS. ~he roUtine MAKE_COMBOS calls the function CHECK_C0MBOS as the routine MAXE_COMBOS finishes with each state, and as the routine MAKE_COMBOS finishes with each three digit ZIP value.

20~3~

As indicated above, the function CHECK_COMBOS stores values in the array sIN_coMso to indicate which first pass bins are to be mandatorily combined together. As an example of how the array sIN coMsos might appear upon completion o~ the execution of function cHEcK_coMsos, consider the following:

BIN_COMBO E O o 1 ] = o BIN_CoMso[002~ = o BIN_COMBO[003] = 1 BIN_COMBO[004] = 0 sIN_coMso[oos] = 2 BIN_COMBO~006] = 1 BIN_COMB0[007] = 2 BIN_COMBO[008] = 0 BIN_COMBO[127] = 0 BIN coMso[l28] = o where a zero ("0") assignment indicates that there is no forced combination for a bin; where bins assigned a Illli are to be forced into combination (i.e., bins 3 and 6), and, where bins assigned a "2" are to be forced into combination (i.e., bins and 7). Thus, each forced combination has a unique combination number associated therewith, and the bins forced into combination together have the same combination number assigned to their corresponding elements in the array BIN_COMBOS.

When function CHECK_COMBOS is called, function CHECK_COMBOS initially executes two steps: (1) initiali~es a counter COLLISION_CNT; and, (2) counts the number of bins for which a flag has been set in array BIN_USAGE for the current package. If the number of flags set is only one, then function CHECK_COMBOS knows that no combination of bins is required and returns control to the calling function MAKE_COMBOS.
Assuming that the function CHECK_COMBOS does not immediately return control to ~he calling function MAKE_COMBOS, the function CHECK_COMBOS checks to determine whether any of the bins for which a flag was set in array BIN_USAGE has already been forced into a combination. This check is implemented by checking the element in array BIN_COMBO

35 205345~
correspondiny to that bin to determine iE a non-zero combination number has already been assigned to the bin. If a non-zero combination number has already been assigned, the function CHECK COMBOS notes a "collision".
The function CHECK_COMBOS counts the number of collisions detected using a counter COLLISION_ CNT. In addition, the function CH~CX_COMBOS stores the numbers of the bins subject to collision in an array COLLISION_COMBO. For example, if a first collision occurred in bin 67 and a second collision occurred in bin 48, COLLISION_COMBO[l] = 34 and COLLISION_COMBO[2] = 48.
Having searched for collisions, the function CHECK_COMBOS executes different steps in determining the combination number to be stored in BIN_COMBOS, depending upon whether no collisions, one collision, or multiple collisions were detected.
If no colllsions were encountered during the execution of function CHECK_COMBOS, the function CHECK_COMBOS would then select the next avallable number for use as a combination number. For example, in the example, if the highest number thus far stored in the array BIN_COMBOS was "2", the function CHECK_COMBOS would then store a "3" in every element in array BIN_COMBOS for which a flag was set in a corresponding element of array BIN USAGE. The function CHECK COMBOS would then return control to the calling function MAKE_COMBOS.
If only one collision were encountered during the execution of function CHECK_COMBOS, the function CHECK COMBOS
would assign the combination number stored in the first element of COLLISION COMBO to the elements in array BIN_COMBOS
corresponding to the elements in array BIN_USAGE having flags set. For example, if bins 67 and 102 were utilized for the current package as indicated by flags being set in the 67th and 102nd elements of array BIN_USAGE, if the only collision detected by function CHECK_CONBOS for the current package occurred with respect to bin 67, and if the combination number assigned to bin 67 were "5", then the function CHECK_COMBOS
would assign the combination numbar "5" to bins 67 and 102 36 20~34~
(i.e., to BIN COMBO[67] and BIN_COMBO[102]). The function CHECK_COMBOS would then return control to the calling function MAKE COMBOS.
In the more complex case where multiple collisions are encountered, the function CHECK_COMBOS replaces all the elements of array BIN_COMBO affected by ~he collision With the combination number of the first detected collision, i.e., all collision bins are assigned the value COLLISION_COMBO[O] and are properly placed in the BIN_COMBO array. Then the combination number in COLLISION_COMBO[O] is assigned to any new bins that might not have collided. This is done by setting the array elements in BIN_CoMBo to COLLISION_COMBO[0] using the corresponding elements marked in array BIN_USAGE. Since the value in COLLISION_COMBOtO] may not have been the lowest forced combination indicator out of multiple such indicators, a numbering gap could possibly occur.
A numbering gap, if it occurs, is fixed by placing all non-zero elements from the BIN_COMBO array into an~ther array UNIQUE COLLISIONS along With counting the number of elements in array UNIQU~ COLLISIONS. All elements in the array UNIQUE CO~ISIONS are sorted in numerical order~ then each element repeating the value of the previous element is removed from the array, thereby shrinking the array in size. The array UNIQUE_COLLISIONS makes it possible to easily reassign forced bin combination numbers without gaps to the BIN_COMBO array.
This is accomplished by searching hoth the BIN_COMBO array and the UNIQUE_COLLISIONS array for matching contents. When the contents match, a new sequential number is assigned into yet another array COMBO_~RAN~LA~ION correspondlng to the po~ition of the UNIQUE_COLLIsIONS array. Finally, the BIN_COMBO array is updated by assigning the value in the COMBO_~RANSLA~ION
array which is indexed by the contents of the BIN_COMBO array.

Function MAXE_SACK COMBOS
The function MAKE_SACK_COMBOS (see Fig. 4E) determines mandatory combinations of first pass bins for forming sacks.
That is, the function MAKE_SACK_COMBOS sets up the required 2~534~

data to force a sack ' s packages scattered aCross bins by the first pass sort scheme back into a single second pass group.
The function MAKE_SACK_COMBOS (which forces a sack ' s packages together) is somewhat simpler than the function MAKE_COMBOS (which determined combinations of first pass bins for making up state packages and three digit packages). The simplicity results from two factors. First, the function MAKE_COMBOS has already forced zip codes scattered across bins to form packages. Second, an input file (i.e., SORTREC2.TMP) of subsequent pass packages sorted by sack zip ID already exists. The file SORTREC2.TMP was created by the function SACK_SORT. The file SORTREC2.TMP is sorted by sack type, within sack type by package type, and within package type by package zip. Therefore, the file SORTREC2.TMP is effectively sorted by sack zip ID.
At step 370 the function MAKE_SACK COMBOS reads the initial record in the file SORTREC2.TMP. At step 372 the sack ID value obtained from the first record is stored in location hAST_SACK_ZIP_ID, At step 374 the sack type value obtained from the first record iS stored in location LAST_SACK_TYP~.
At step 376 a flag is Set in the element Of array BIN_USAGE
corresponding to the bin value obtained from the first record of file SORTREC2.TMP.
At step 378 the function MAKE_SACK_COMBOS begins a loop of reading and processing records in the file SORTREC2.TMP.
The next record is read at step 378. If the record was not the last record (as determined at step 380), at step 382 the function MAKE_SACK_COMBOS checks whether the sack type value of the record indicates a "MIXED STATES" sack. There is no forced combination with respect to any MIXED STATES sacks, so that an affirmative result at step 382 results in the continuation of the loop with the reading of the next record at step 378. If the record does not indicate a MIXED STATES
sack, the ZIP ID value from the record is stored at location SACK_ZIP_ID (step 384).
At step 386 the function MAKE_SACK_COMBOS determines whether the next record indicates a change of sack types from the previous record. A change of sack types occurs when the current records has two critical parameters that differ from the previous records. That is, when SACK_ZIP_ID is not equal to LAST_SACK ZIP_ID, and when the sack type read from the current record is not equal to LAST_SACX_TYPE, a change of sack type has occurred.
When, at step 386, a change in sack type is determined not to have occurred, the function MAKE_SACK_COMBOS sets a flag in an element of the array BIN_~SAGE corresponding to the bin value obtained from the current record in the SORTREC2.TMP file (step 388). The value in location SACK_ZIP_ID is then stored in location LAST_SACK_ZIP_ID (step 390), and a value indicative of the sack type obtained from the current record is stored in the location LAST_SACK_TYPE (step 392)~ The function MAKE_SACK_COMBOS then loops back to step 378 for the reading of another record from file SORTREC2.TMP.
When, at step 386, a change in sack type is determined to have occurred, at step 394 the function MAKE_SACK_COMBOS
calls the function CHECK_COMBOS (described above) to update the array BIN_COMBOS. The function CHECK_COMBOS resolves conflicting bin assignments for sacks in essentially the same manner as described above in connection with the resolution of conflicting bin assignments for packages. After the call to function CHECK_COMBOS, at step 396 the function MAKE_SACK_COMBOS clears the array BIN_USAGE in anticipatiny of processing the next sack type. The function MAKE_SACK_COMBOS
then sets a flag in an element of the array BIN_USAGE
corresponding to the bin value obtained from the current record in the SORTREC2.TMP file (step 388). The value in location SACK_ZIP_ID is then stored in location LAST_SACK_ZIP_ID (step 390), and a value indicative of the sack type obtained from the current record is stored in the location LAST_SACK TYPE (step 392). The function MAKE_SACK_COMBOS then loops back to step 378 for the reading of another record from file SORTREC2.TMP.
After the last record is read from file SORTREC2.TMP
(as determined at step 380), the function MAKE_SACK_COMBOS
calls the function CHECK_COMBOS at step to update the array 39 20~3~5~
BIN_COMBOS with respect to the last record. Thereafter, as indicated by step 398, processing continues with the function BUILD_TREES, which is described immediately below.

Function BUILD_~REEg The function BUILD_TREES (se~ Figs. 4F and 4G) huilds a major tree array, i.e. array ~AJ_TREE, which associates particular bins with a sort tree. In addition, the function BUILD_TREES develops pointer information in a file SRTREE.DAT.
lo The file SRTREE.DAT contains key pointer and offset information used to process individual subsequent pass groups within a properly ordered input file containing package information for multiple groups.
As an example of how the major trees built by function BUILD_TREES appear, after the execution of function BUILD_TREES, the array MAJ_TREE might have values such as the following:
MAJ_TREE[000] = O tbin O not used) MAJ_TREE~001] = O (no major tree assignment) MAJ_TREE[002] = 1 (first sort tree) MAJ_TREE[003] = 2 (second sort tree) MAJ TREE[004] = 2 (second sort tree) MAJ_TREE~oO5] = O ~no major tree assignment) MAJ_TREE[006] = 3 (third sort tree) MAJ_TREE[128] = o (no major tree assignment The function BUILD_TREES takes the number of different packages coming from a first pass bin or a required combination of bins and forms information for "groups" (including "groups"
requiring even more passes). This is done by comparing the package count with the number of available bins. Several first pass bins may be combined together if the total package count is less than the number of bins available.
At the beginning of the execution of function BUILD_TREES, as reflected by step 400, the function BUILD_TREES
determines the number of packages in each state/3-digit forced bin combination and stores that value in an arrav 20~4~

QUAL_PER_COMBO. This is done by determining which bins have the same value stored in the array BIN_COMB0 (e.g., which bins are forced into combination), and summing the number of packages for all bins combined together. The number of packages in each bin is available from the array PACKS_PER_BIN, which was developed in the previous function MAKE_SORT_RECORDS.
At steps 402 - 408 the function BUILD_TREES initializes various parameters. At step 402 the counter CUTOFF_CNT is initialized at a value equaling the number of available bins.
This initialization value may not be 128, since some bins may be designated as reject bins, or may not be used, or may be used for other purposes. At step 404 the counter TREE_CNT, whiCh coUnts the number of sort trees, is initialized at 1.
At steps 406 and 408, respectively, the counters QUAL CNT and TEMP_CNT are initialized at 2ero.
Commencing at Step 410 the function BUILD TREES
attempts to f ind the f irSt bin belonging to a tree . In so doing, the function BUILD_TREES considers only bins having packages stored therein Which are not fully sorted during the first pass, or bins which have been forced into combination (e.g., bins having a non-zero value in their corresponding element in array BIN_COMBO).
At step 412 the function BUILD_TREES determines whether the considered bin was forced into combination by checking for a non-zero value at the corresponding element in array BIN COMBO. If the considered bin was involved in a forced combination, at step 414 the qualifying package counter QUAL_CNT has the value of the number of packages included in the combined bins added thereto. Where "i" stands for the bin under consideration, the number of packages included in the combined bins is obtained from array QUAL_PER_COMBO[BIN COMBo[i]]. Values were stored in array QUAL PER COMBO at step 400 of function BUILD_TREES. Also for the considered bin involved in the forced combination, for each bin included in the forced combination, at step 416 the function BUILD_TREES sets elements corresponding to each such bin in array MAJ_TREE equal to the value in CoUnter TREE_CNT, 41 20534~
which is presently "1". The function BUILD_TREES then sets BIN_COMBO_USAGE~BIN_COMBo[i]] = 1 at step 417, indicating that all bins in this combination have been accounted for.
Processing then continues at step 420 as indicated by path 422.
The function BUILD_TREES locates a bin not involved in a combination (e.q., a bin for which the corresponding element in array BIN_COMBO is zero) at step 412. Upon locating a non-combined bin, the function BUILD_TREES Stores ~he CUrrent value of counter TREE_CNT (i.e., "1"), in the element of array MAJ_TREE corresponding to the located non-combined bin (step 418). From thence processing continues with step 420 as indicated by path 422.
At step 420 the function BUILD_TREES computes the number of the next-highest numbered bin by incrementing the number of the bin located at step 412. Then, using the incremented bin number (symbolically expressed by "i"), at step 422 the function BUILD_TREES checks to see if the bin was involved in a forced combination by checking the value of BIN_COMBO~i]. If the bin was involved in a forced combination, the number of packages involved in the combination (i.e., QUAL_PER_COMBO~BIN_COMBO~) is stored at the temporary counter TEMP_CNT (step 424). If the bin was not involved in a forced combination, the nu~ber of packages in the bin (i.e., PACKS_PER_BIN~i]) is stored at the temporary c~unter TEMP_CNT
(step 424). After execution of step 424 or step 426, the function BUILD_TREES adds the value of TEMP_CNT to the counter QUAL_CNT ( step 428).
At step 430 the function BUILD_TREES determines whether the value in counter QUAL_ CNT (updated at step 428) exceeds the number of available bins (i.e., exceeds the value of the counter CUTOFF CNT initialized at step 402). If an excess is determined at step 430, at steps 432 and 434, respectively, the function BUILD_TREES increments the value in counter TREE_CNT
and stores the value in TEMP_CNT in counter QUAL_CNT before proceeding to step 436. In so doing, the function BUILD_TREES
begins another sort tree beginning with the current bin and initializes the value in counter QUAL_CNT for the new tree on 42 2~3~
the basis of the c~unt determined at the appropriate one of steps 424 or 426.
At step 436 the function BUILD_TREES again discerns whether the current bin was involved in a forced combination.
If the current bin was involved in a forced combination, at step 438 the function BUILD_TREES sets the corresponding elements in array MAJ_TREE equal to the current value of counter TREE_CNT for each bin included in forced combination with the current bin. Then, at step 440, a flag is set in array BIN_COMBO_USAGE at element BIN_COMBO~i] thereof.
If at step 436 the function BUILD_TREES discerns that the cUrrent bin was not involved in a forced combination, at step 442 the function BUILD_TREES assigns the value of the counter TREE_CNT to the element i in array MAJ_TREE for this bin (i.e., MAJ_TREE[i] = TREE_CNT).
After processing either step 442 or step 440, the function BUILD_TREES checks at step 444 if all bins have been processed. If not, execution l~ops back to step 420 for processing the next bin.
After all bins have been processed by function BUILD_TREES as determined at step 444, at step 446 the function BUILD_TREES prepares the file SRTREE.DAT (described below).
The file SRTREE.DAT contains key pointer and offset information eventually used to process individual "groups" within a properly ordered input file, containing package information for multiple groups.
The file SRTREE.DAT contains records of the following structure:

typedef struct unsigned int QUAL PTR; /* number of package data entries prior to this major tree */
unsigned int QUAL_TRE: /* number packa~es (bins) required per major tree */
unsigned int GRPS_TRE; /* groups per major tree */
unsigned int GROF_TRE: /* number of groups prior to this major tree } TREE_DATA

20~345~

In preparing the file SRTREE.DAT, the function BUILD_TREES finds the bins belonging to each sort tree. Then, for each sort tree, the number of qualifying packages for all the bins included in the tree is summed to obtain a total packaye count for the tree (stored in location QUAL CNT [which is re-initialized at zero before checking each tree]). This value is stored in field QUAL_TR~ for the appropriate record in file SRTREE.DAT for the tree of interest.
To determine the value ~or field GRPS_TRE for a record in filed SRTREE.DAT, the function BUI~D_TREES evaluates the expression:

1 + (QUAL_CNT - 2)/(TOT_BINS - 1) assuming QUAL_CNT is greater than zero, and wherein TOT_BINS
is as described with respect to step 402 supra. If the value of counter Q~AL_CNT is zero, the value for field GRPS_TRE
becomes "1".
The values of ~ields QUA~ PTR and GROF TR~
respectively, for each record in file SRTREE.DAT, are obtained by maintaining running summations of the values QUAL_TR~ and GRPS_TRE for previous trees.

Functlon ~REESORT
The function ~REESORT (see Fig. 4H) takes the input file SORTREC2.TMP and produces an output file SOR~RE~3.~MP.
Whereas the records in input ~ile SORTREC2.TMP are sorted by sack type, then within sack type by package type, and within package type by ZIP ID, the records in output file SORTREC3.TMP
are sorted by major tree, then within major tree by sack type, then within sack type by package type, then within package type by ZIP ID.
At step 450, the function TREESORT determines the number of entries (i.e., the number of records) belonging to each tree. This is done by making a ~irst pass through the input file SORTREC2.TMP. As each record in file SORTREC2.TMP
is read, the bin number for that record is obtained from the - 20~3455 record. Using the bin number extracted from the record as an index, the function TREESORT determines the major tree to which the record belongs hy checking the array MAJ_TREE. The entries for each tree are counted as the input file SORTREC2.TMP is read.
All the records from input file SORTREC2.TMP for as many trees as possible are stored in dynamic memory by the function TREESORT. All the records for all the trees may not fit into dynamic memory simultaneously, so for each execution of a loop (consisting of steps 452, 454, 456, and 458), the records for as many trees as possible are stored in dynamic memory. The lowest numbered trees are handled during the first execution of the loop, with successive loop executions involving progressively higher numbered trees.
Before conducting another pass of the records included in the i~put file SoRTREC2.TMP, at step 452 the function TREESoRT ~ets a memory pointer for each tree which will fit into dynamic memory for the current execution of the loop. The memory pointer lS easl1y determined since the number of entries for each tree is known from step 450, and the size of each record is standardized in accordance ~ith the format discussed supra.
At step 4s4 each record in the input file SORTREC2.TMP
is again read. As a record is read, it is copied into dynamic memory at the location specified by the memory pointer for the tree to which the record belongs. After each record is written to dynamic memory, the memory pointer for its tree is advanced to the next record location for that tree in dynamic memory.
When all the trees being handled by this execution of the loop have been written into dynamic memory, at Step 456 the contents of the dynamic memory is written to the output file SORTREC3.TMP. Thus, the output file SORTR~C3.TMP is ~orted first by tree, then by sack, then by package, and then by ZIP
ID.
At step 458 the function TREESORT checks to determine if all trees have been processed. If further trees remain, the function TREESORT goes back to the beginning of the loop (i.e., 45 . 205~4~5 back to step 452) to handle further trees and to continue writing to the output file SORTREC3.TMP in the manner just described. If all trees have been written, processing continues with function FIRST_PASS_SACKS (as indicated by step 460).

Function FIRST PAS8_SACRS
Function FIRST PASS_SACKS (see FigO 4I) determines f irst pass bins containing completed sorted sacks. In this lo regard, the function FIRST_PASS_SACKS uses the f ile FULLSOR2 . TMP to prepare an array FULL_SACK BIN, which is an array of completely sorted first pass sacks indexed by first pass bin. An example of the appearance of a portion of array FU~ SACK_~IN upon completion of eXecution of function FIRST_ PASS_SACKS is as follows::

FULL_ SACK_ BIN[000] = 0 - bin 0 not used FULL SACK_ BIN[001] = 0 FULL _ SACK _ BIN [ 002 ] = 0 FULL_SACK_ BIN[003] = 1 - bins 3 and 5 form one sack FULL_SACK_BIN[004] = 0 FULL_ SACK_BIN[005] = 1 - bins 3 and 5 form one sack FULL_SACK_BIN[006] = ~ - 2nd sack from only one bin FULL_SACK_ BIN[007] = 0 FULL SACK_BIN[008] = 0 .

FULL SACK BIN [ 127] = 0 FULL SACK BIN[ 12~] = 0 In the simple case, function FIRST PASS_SACKS
determines completely sorted sacks by comparing the sack count with the bin count of the bin where the sack contents was assigned. If the two counts are equal, the bin is completely sorted.
For Mixed five digit, three digit, and state sacks the comparison is complicated because the sack contents could end up in several first pass bins. Therefore the partial sack counts from several bins making up one complete sack are compared against the same several bins total piece count. In addition, only the file containing the first pass package 2~534~

records is scanned, so records that end up in the subseyuent pass package record file are not included. To account for this, the sack count arrays containing both first pass and subsequent pass data are compared against the first pass sack count.
Describing now in detail the steps executed by function FIRST_PASS_SACXS, various arrays and parameters are initialized at step 470. For example, the output array FULL_SACK_BIN has all its elements set equal to zero, and the array BIN_USAGE is set to a logical FALSE value at step 470. In addition, the counters SACK_BIN_CNT and FIRST_PASS_SACKS, and the location SACK_CNT are initialized at zero.
At step 472 the function FIRST_PASS_SACKS reads the first record from file FULLSOR2.TMP. The file FULLSOR2.TMP was created by the function SACK_SORT, and is a file containing one record per completely sorted first pass package. In reading the first record from file FULLSOR2.TMP at step 472, the function FIRST_PASS_SACKS obtains the ZIP ID and the sack type from the initial record, and stores those values at the respective locations LAST_SACK_ZIP_ID and LAST _SACK_TYPE.
At step 474 the function FIRST_PASS_SACKS begins a loop of reading and processing further records in the file FULLSOR2.TMP. In so doing, the function FIRST_PASS_SACKS
obtains the ZIP ID and the sack type from the new record, and stores those values at the respective locations SACK ZIP ID and SACK TYPE.
At step 476 the function FIRST PASS SACKS determines whether the most-recently read record is in the same sac~ as the previous record. This is affirmatively determined when SACK_ZIP_ID = LAST SACK_ZIP_ID and SACK_ZIP ID
LAST_SACK_ZIP ID. If it is determined at step 475 that the most-recently read record is not in the same sack as the previous record, processing continues at step 478. Otherwise processing branches to step 480.
At step 480 the function FIRST PASS SACKS determines whether the most recently read record involves a new bin. A
new bin is involved if the element corresponding to the new bin 20~34~

in array BIN_USAGE is still FALSE. If a new bin is not involved, processing continues with step 482. Otherwise, processing branches to step 484.
When a new bin is involved, at step 484 the function FIRST_PASS_SACKS sets the el~ment in arra~ BIN_USAGE
corresponding to the new bin to a TRUE value. Then, at step 486, the function FIRST_PASS_SACKS adds the count of the number of mailpieces in that new bin to the counter SACK_BIN_CNT. It will be rememhered that the count of the number of mailpieces in the new bin is obtained from the file AGGR.DAT, which was created at step 202.
At step 482, reached either from step 480 or step 486, the function FIRST_PASS_SACKS sums the partial package counts by adding the adding the package count from the most recent record to the counter SACK_cNT. At step 478, reached either ; from step 476 or step 482, the function FIRST_PASS_ SACKS
initializes the logical flag ALL_~ROM_PASSl to a logical zero.
At step 488 the function FIRST_PASS SACKS examines the value of the location LAST_SACK TYPE to determine what type of sack is being processed, with a view to determining whether the flag ALL_FROM PASS1 should be changed from FALSE to TRUE for this sack, thereby indicating that the sack is not split into first and second pass records. FIVE_DIGIT sacks cannot be split into first and second pass records, so if the value of LAST_SACK_TYPE is FIVE_DIGIT, the flag ALL_FROM_PASS1 is set TRUE.
For the other sack types, function FIRST_PASS_SACKS at step 488 determines whether the value of an appropriate counter equals the current value of the counter SACK_CNT (calculated at step 482). In this respect, the equality determination at step 488 is made with respect to the appropriate one o~ the counters MIXED FIVE_SACK_CNT, THREE_DIGIT_SACK_CNT, or STATE_SACK CNT for the last sack ZIP_ID.
At step 490 the function FIRST_PASS_SACKS determines whether the flag ALL_FROM_PASS1 is TRUE and whether the value in counter SACK_CNT equals the value in the counter SACK_BIN_CNT (se~ step 486). When both determinations are 20~3455 affirmative, the function FIRST_PASS_SACKS realizes that it has encountered a completely sorted first pass sack. If either determination is negative, the function FIRST_PASS_SACKS
continues processing at step 492; otherwise the function FIRST_PASS_SACKS branches to steps 433 followed by step 494.
Both determinations at step 490 being affirmative reflect the location of a completely sorted sack, and cause a branch in processing to step 493. At step 493 the counter FIRST_PASS_SACKS is incremented to a value which will be used as a unique identifying value for the just-located completely sorted sack. At step 494 the value of FIRST_PASS_SACKS iS
stored in every element of array FULL_ SACK_BIN which corresponds to a bin which has mailpieces included in the completely sorted sack. The bins which have mailpieces included in this most~recently located completely sorted sack are reflected by the elements in array BIN_USAGE which have been set to a logical TRUE value.
At step 492, reached either from step 490 or step 494, the function FIRST_PASS_SACKS reinitializes the counters SACK_CNT and SACK_BIN_CNT at zero; sets every element in array BIN_USAGE to a FALSE value; and, stores the value from location SACK_ZIP ID in location LAST_SACK_ZIP_ID and the value from location SACK TYPE in the location LAST_SACK_TYPE.
At step 495 the function FIRST_PASS_SACKS determines whether any more records remain for reading in file FULLSOR2.TMP. If records remain, processing loops back to step 474, at which the repetition of the above-described steps occurs for the next record. If no further records remain in file FULLSOR2.TMP, the function FIRST_PASS_SACKS processes the last-read record at step 496. In this regard, the processing of step 496 is essentially the same as steps 488 through 494 inclusive, except there is no step corresponding to reinitialization step 492. At step 497 processing is transfered to function MAXE_BAGS.

2~S34~

4~
Function MARE_BAG8 Function MAKE_BAGS (see Figs. 4J and 4K) assigns unique identification numbers to each bag destination and determines the number of piec~s assigned to a destination. In addition, the bag id2ntification numbers get corresponding assignments to subsequent pass groups and bins.
At step 500 the function MAKE_BAGS initializes the value of location LAST_BAG_ASSIGNE~ at zero. At step 502 the function MAKE_BAGS handles mixed states ~ags, assigning all mixed states records to the bag number "one'l. As part of step 502, the function MAKE_BAGS increments the value a~ location LAST_BAG_ASSIGNED (so that the value is "l"), and then sets BAG_NO = 1. Further, at step 502 the function MAKE_BAGS
creates a record in a file BAGTAG_HANDLE, with the record having the following format and values:

BAG_DATA.ZIP_ID = 0 BAG DATA.BAG ID NO = BAG.NO
BAG_DATA.BEG_GROUP = O
BAG_DATA. BEG_BIN = O
BAG_DATA.END_GROUP = O
BAG_DATA END_BIN = o BAG_DATA S_TYPE = MIXED STATES
BAG_DATA.CNT = MS_SACK_CNT
Having handled the mixed states bags at step 502, the function MAKE_BAGS determines the number of first pass bags containing either some or all completely sorted first pass packages. ~hese sacks must have their bag ID assignment before subsequent pass groups are handled. The completely sorted flrst pass bags are processed by steps 504 through 550 of the function MAKE_BAGS. Thereafter, at steps 554 through 572, the subsequent bags are processed.
In the above regard, at step 504 the function MAKE_BAGS
initializes various values for handling the first pass bags.
The function MARE BAGS sets LAST ID = -1; LAST_.TYPE = -1; anQ, FRST PASS BAGS.CNT = O.
At step 506 the function MAKE BAGS reads, as a first step in a loop, a record from file FULLSOR2.TMP. The file 2053~55 FULLSOR2.TMP was created by the function SACX_SORT. Assuming at step 508 that the record read is not from the same sack as the last record in the file FULLSOR2.TMP, at step 510 the function MAKE_BAGS checks whether the record just read from the file FULLSOR2.TMP pertained to a mixed states sack. If so, the function MAKE_BAGS realizes that it has already handled (at step 502) the mixed states bag, and at step 512 sets SACK_NO
= 1. Also, at step 514, the function MAKE_BAGS writes a corresponding record (i.e., the record read from file FULLSOR2.TMP with the bag number updated) to file FULLSORT.
After execution of step 514, processing loops back to step 506 for the reading of another record from file FULLSOR2.TMP.
Assuming that the function MAKE_BAGS determined at step 510 that the record just-read pertained to a sack type other than a mixed states sack, at step 516 the function MAKE BAGS
obtains the ZIP ID from the record and stores that ZIP ID in location SACK_ZIP_ID. At step 518 the function MAKE_BAGS
checks whether the record just-read from file FULLSOR2.TMP
signals a change of sack. A change of sack is signalled when SACK_ZIP_ID does not equal the value stored in location LAST_ID.
If a change of sack is not encountered at step 518, the function MAKE_BAGS adds the value in the field SACK.PACXAGE.CNT
from the record just-read to the counter FRST_PASS_BAG.CNT
(step 520). Location SACK.No is then set to the value at location BAG.NO (step 522). At step 524, a corresponding record is written to file FULLSORT. After the corresponding record is written at step 524, execution loops back to step 506 for the reading of yet another record from the file FULLSOR2.TMP.
If a change of sack is encountered at step 518, the function MAKE_BAGS determines whether the record just-read from file FULLSOR2.TMP was the very first record in file FULL.SOR2.TMP (step 526). For all but the very first record in file FULLSOR2.TMP, the function MAKE_BAGS writes a corresponding record in the file BAGTAG_H~NDLE (step 528).

~OS~4~

At step 530 the function MAKE_BAGS computes a value for pointer PREV_ASSIGN_PTR. In this regard, at step 530 the function MAKE_BAGS uses the value of SACK ZIP ID ohtained from_ the record just-read as an index ~or an appropriate one of arrays NIXED FIVE BAG NO; STATE_BAG_ NO; T~REE_DIGIT_BAG_ NO;
depending on the value of SACK. STYPE obtained for the record just-read. (These arrays were also initialized at step 500).
The value obtained by indexing into the appropriate array is stored in the pointer PREV_ASSIGN_PTR. If the value of SACK.STYPE obtained from the record just-read is other than MIXED_FIVE; THREE_DIGIT: or STATE; the pointer P~EV_ASSIGN_PTR
is assigned the value NULL at step 530.
At step 532 the function MAKE_BAGS checks to determine if PREV_ASSIGN_PTR is NULL or the contents thereof is zero.
If either value is stored in pointer PREV_ASSIGN_PTR, at step 534 LAST_BAG_ASSIGNED is incremented and at step 536 that incremented value is stored in location BAG_NO. Otherwise, at step 538, BAG_NO has the value from *PREV_ASSIGN_PTR stored therein.
Step 540 is reached either from step 536 or step 538.
At step 540, the function MAKE_BAGS checks whether the pointer PREV ASSIGN_PTR has the value NULL stored therein. If so, at step 542 the value of BAG_NO is stored in location ~PREV ASSIGN PTR.
At step 544, which follows either step 540 or step 542, the function MAKE BAGS creates a record for the array FRST PASS BAGS. The record created at step 544 has the following format and values:

FRST_PASS_BAGS.ZIP_ID = SACK_ZIP_ID
FRST_PASS_BAGS.BAD_ID_NO = BAG_NO
FRST PASS BAGS . BEG GROUP = 0 FRST_PASS BAGS.BEG BIN = 0 FRST PASS BAGS.END GROUP = 0 3 5 FRST PASS sAGs. END BIN = O
FRST PASS_BAGS.S_TYPE = SACK.STYPE
FRST_PASS BAGS.CNT = SACK.PACKAGE.CNT

20~3~

After creating a record for file FRST PASS_BAGS at step 544, the function MARE_BAGS stores the value in location SACK_ZIP_ID in location L~ST_ID (step 546) and s~ores the value in location SACK.STYPE in location LAST_TYPE (step 548). Then function MAKE_BAGS jumps back to execute steps 522 and 524 before reading another record from file FULLS0R2.TMP at step 506. In this respect, as explained before, at step 522 the location SACK.NO is then set to the value at location BAG.N0 and, at step 524, a corresponding record is written to file FULLSORT.
After all records from file FULLSOR2.TMP have been read as determined by step 508, the final FIRST_PASS_BAGS record is written to file BAGTAG_HANDLE at step 549. Then, as indicated by symbol 550 processing continues ai step 554 (see Fig. 4K) for handling package records for subsequent pass sorting (i.e., package records from file SORTREC3.TMP).
At step 554, which is somewhat akin to step 504, various parameters are initialized, i.e., CUS GROUP = 0;
LAST_ID = -l; LAST_TYPE = -1; and, BAG_DATA.CNT = 0. The file SRTREE.DAT iS read to determine if any more tree structures remain. In the Ca~e of remaining tree strUctures~ CUS_GROUP
is incremented by one (step 560). Then a check at step 562 is made to determine if there are any more groups defined by the present tree record. If there are not more groups, the function continues at step 556 where the file SRTREE.DAT is read for another tree structure. In the case where a group remains in the present tree ~deterimed at step 562), at step 564 an array BIN_CNT is set declaring the number of packages to be placed in the present group's bins. In addition, at step 565 a file seek position is set in file SORTREC3.TMP, for the first record in the present group being processed, by using tree record information and the present group within the tree.
At step 567 the array BIN_CNT contents are checked for a value of one. This indicates that no more groups are required to sort the next record found in SO~TREC3.TMP. For al~ bins such that BIN CNT[i] = 1 a record is read from the file SORTREC3.TMP
(step 568). In the case where no more hins remain, processing 20~34~

proceeds to step 560 where a new group is used. Where a record is read from ~ORTREC3 . TMP the record is processed at step 570 in the same way as for a first pass sort record. Step 570 is the same as steps 506 through 549 except in step 506 where a 5 record is read from file FULLSOR2.TMP it is now read from file SORTREC3.TMP. After processing the package record from file SORTREC3.TMP the process continues by going to step 566 where a check is made to determine if any more bins have been assigned to the present group.
In the case where no more trees are left at step 558, the program is ready to go to the function MAXE_CLIENT_CNTS (as indicated by step 572).

Function MARE_CLIENT_COUNTS
The function MAXE_CLIENT_COUNTS (see Fig. 4L) sets up several count categories for each client. These counts are subsequently used in postage reporting and client billing.
The function MAKE_CLIENT_COUNTS uses the input file COUNT. DAT created by function FIRST_SORT_PASS and the input file SORTREC2.TMP created by the function SACK_SORT. It will be recalled that the format of file COUNT.DAT is as follows:
byte offset #
Zip Code - 4 bytes (long integer) 0 Stream Index - 1 byte (hex/binary value) 4 Client Index - 1 byte (hex/binary value) 5 Bin - 1 byte (hex/binary value) 6 5 Digit OCR/BCR count - 2 bytes ~unsigned integer) 7 Zip + 4 OCR count - 2 bytes (unsigned integer~ 9 Zip + 4 Barcoded count - 2 bytes tunsigned integer) 11 The records in file COUNT.DAT are sorted in ascending order.
In this respect, a primary sortation is done by ZIP code. For ZIP codes repeated due to their usage in different client/mailstreams, a secondary sortation is performed by first sorting the client index number, followed by the stream index number.
At step 600 the function MAKE_CLIENT_COUNTS initializes several counter arrays. In this respect, at step 600 the following are initialized at zero:

20~3~

CLIENT[i].QUAL_TOT.COUNT5 CLIENT[i].QUAL_TOT.ZIP4 CLIENT[i].QUAL_TOT.BARCDE
CLIENT t i 3 . NQUAL_TOT . COUNT5 CLIEN~ .NQUAL_TOT.ZIP4 CLIENT[i~.NQUAL_TOT.BARCDE

where i represents the client index (the number associated with a particular client). CLIENT[i].QUAL_TOT.COUNT5 will ultimately contain the total number of mailpieces from client "i" which qualify for the 5 Digit OCR/barcode postage discount;
CLIENT[i].QUAL_TOT.ZIP4 will ultimately contain the total number of mailpieces from client "i" which qualify for the ZIP+4 OCR postage discount; CLIENT[i].QUAL_TOT.BARCDE will ultimately contain the total number of mailpieces from client "i" which qualify for the ZIP+4 barcoded postage discount, CLIENTti].NQUAL_TOT.COUNT5 will ~ltimately contain the total number of 5 Digit OCR/barcoded mailpieces from client llil~ which do not qualify for the 5 Digit OCR/barcoded postage discount;
CLIENT[i].NQUAL TOT . ZIP4 will ultimately contain the total number of ZIP+4 OCR mailpieces from client "i" which do not qualify for the ZIP+4 OCR postage discount; and, CLIENT[i].NQUAL_TOT.BARCDE Will ultimately contain the total number of ZIP+4 Barcoded mailpieces from client "i" which do not qualify for the ZIP+4 Barcoded poStage disCOUnt At step 600 the following are also initialized at zero:
TOTALS[O].COUNT5 TOTALS[O].COUNT9 TOTALS~O].BAR CNT
TOTALS[l].COUNT5 ToTALS[l].CoUNTs TOTALS~l].BAR_CNT
TOTALS[2].COUNT5 TOTALS~2].COUNT9 TOTALS[2].BAR_CNT
At step 602 the function MAKE CLIENT_COUNTS reads a record in the file COUNT.DAT. As noted above, each record in file COUNT.DAT has a ZIP ID field. At step 604 the function MAKE CLIENT COUNTS searches the file SACK2.TMP to find the 20~34~

record in file SACK20TMP having the same ZIP ID as the current record in file COUNT.DAT. At step 606 the function MAXE_CLIENT_COUNTS consults the record found in file SACK2.TMP
to determine the sack type (STYPE) assigned to the sack containing mailpieces for the current ZIP ID.
At step 608 a determination is made whether the record in file SACK2.TMP for the current ZIP ID indicates that mailpieces having the current ZIP ID are contained in FIVE_DIGIT or MIXED_FIVE sacks (thereby qualifying for the applicable postage discounts). If the determination at step 608 is affirmative, the function MAKE_CLIENT_COUNTS adds values from the appropriate fields of the current COUNT.DAT record to "qualifying" counters for the client having the client index borne by the current COUNT.DAT record. In this respect, for client "i" at step 610 the counter CLIENT[i].QUAL_TOT.COUNT5 is incremented by the value contained at byte offset 7 in the COUNT.DAT record; the counter CLIENT[i].QUAL_TOT.ZIP4 is incremented by the value contained at byte offset 9 in the COUNT.DAT record; and, the counter CLIENT[i]~QUAL_ TOT . BARCDE
is incremented by the value contained at byte offset 11 in the COUNT.DAT record.
On the otherhand, if the determination at step 608 is negative, at step 612 other "non-qualifying" counters for client "i" are incremented by the values contained at byte offsets 7, 9, and 11, namely counters CLIENT[i].NQUAL TOT.COUNT5 , CLIENT[i].NQUAL_TOT.ZIP4, and CLIENT[i].NQUAL TOT.BARCDE, respectively.
If other records remain in file COUNT. DAT (as determined at step 614), the function MAKE_CLIENT_COUNTS loops back to step 602 to obtain the next record and to execute the steps of Fig. 4L for that next record. After all records in file CoUNT.DAT have been processed by function MAKE_C~IENT_COUNTS, several ~totals~ are computed at step 616.
At step 616 the function MAKE_CLIENT_COUNTS determines the following totals:

2~3455 TOTALS[O].COUNT5 (The number of mailpieces for all clients qualifying for the 5 Digit OCR/barcode postage discount) TOTALS[O].COUNT4 (The number of mailpieces for all clients qualifying for the ZIP+4 OCR postage discount) TOTALS~0].BAR_CNT (The number of mailpieces for all clients qualifying for the ZIP+4 barcoded postage discount) TOTALS~l].COUNT5 (The number of non-qualifying 5 Digit OCR/harcode mailpieces for all clients) TOTALS[l].COUNT4 (The number of non-qualifying ZIP+4 OCR mailpieces for all clients) TOTALS[l].BAR_CNT (The number of non-qualifying ZIP+4 barcoded mailpieces for all clients) TOTALS~2~.COUNT5 - TOTALS[O].C0UNT5 + TOTALS[1].C0UNT5 TOTALS[2].COUNT4 = TOTALS[O].COUNT4 + TOTAIS[1].C0UNT4 . TOTALS~2].BAR_CNT= T O T A L S ~ O ] . B A R _ C N T +
TOTALS[l].BAR_CNT

Then, at step 616, for j = O, 1, and 2, the function MAKE_CLIENT_COUNTS determines TOTALS[j].TOTAL, which is evaluated for each j by the expression ToTALS[j].ToTAL =
rrOTALS~j].COUNT5 ~ TOTALS[j].COUNT9 + TOTALS[j].BAR_CNT.

Function CORRELA~E_BAGS
The function CORRELATE_BAGS (see Fig. 4M) determines the bag number (i.e., the sack number) for each Zip Code and creates a file SACX3.TMP. The file SACK3.TMF is similar to the file SACK2.TMP which is used to create file SACK3.TMP, but unlike file SACK2.TMP the file SACK3.TMP has a bag number assigned to th~ "no" field in each record.
The input files utilized by function COR~ELATE_BAGS are file SACK2.TMP, file SORTREC.D~T, and file FULLSORT.DAT. These input files are created by the functions ASSIGN SACKS, MAKE_BAGS, and MAKE BAGS, respectively.
Function CORRELATE_BAGS reads successi~e records from the file SACK2.TMP and attempts to first match the current record with a record from the file SORTREC.DAT. If a match is found, the function COR~ELATE_BAGS can assign a bag number for the Zip Code for the current record from the file SACK2.TMP, and writes a record including that bag number to the new file 20~3455 SACK3.TMP. If a match is not found in the file SORTREC.DAT, the function CORRELATE_BAGS then a~tempts to match the current record from the file SACK2.TMP with a record from the file FULLSORT.DAT. If a match is found, the flmction C0RRELATE_BAGS
assigns a bag number for the Zip Code for the current record from the file SACK2.TMP, and Writes a record including that bag number to the new f ile SACK3.TMP.
At step ~40 the function C0RRELATE_BAGS reads a record from the file SACK2.TMP. At step 642 the function CORRELATE_BAGS obtains the value in the PTYPE field for the record just read from the file SACK2.TMP. At step 644 a check is made to determine if the PTYPE value is "M", indicating a mixed states pack~ge. If the PTYPE is "M", the function CORRELATE_BAGS knows that all MIXED STATES packages are to go into the first bin, and accordingly at step 646 assigns SACK.NO
the value "1". Then, at step 648, a record is written to the new file SACK3.TMP, with the "no" field of the record having stored therein the value of SACK.NO (i.e., "1").
If the PTYPE value for the current record from file SACK2.TMP is not an "M", at step 650 the function CORRELATE BAGS obtains the PACKAGE ZIP ID value from the zip identifier field of the struct PACKAGE included in the struct SACK comprising the record for the file SACX2.TMP. Then, preparatory to a loop of reading records from file SORTREC.DAT, at step 652 the function CORRELATE BAGS initializes the flag MATCH FLAG to have a TRUE value and the index CURRENT INDEX to have the value ~0~.
As indicated above, the function CORRELATE_BAGS first attempts to match the current record in the file SACK2.TMP with a record in file SORTREC.DAT. In this regard, at step 654 the function CORRELATE BAGS requires the reading of a record from the file SORTREC.DAT. Then, at step 656, a value for pointer CURRENT PTR is determined, which value reflects the physical position of the current record in the file SORTREC.DAT relative to the beginning of the file SORTREC.DAT. As will be seen below, the value of pointer CURRENT PTR is ultimately used to 58 20~3~
; determine the bag number for the package referred to by the current record in file SACK2 . TMP .
At step 658 the function CORRELATE_BAGS determines whether information from the current record in file SACK2 . TMP
matches the corresponding information for the current record in file SORTREC. DAT. Specifically, the PTYPE and zip identifier fields for the two current records are compared.
In this regard, the zip identifier information for the current record in file SACK2 . TMP is stored in the location PACKAGE_ZIP_ID previously determined at step 650.
If a "match" is located at step 658, the function CORRELATE_BAGS performs three operations depicted by steps 660, 662, and 664. At step 660 the value of CURRENT_PTR is used to find the bag number and set the SACK.NO. At step 662 a record is written to the neW file SACK3.TMP, with the value of SACK.NO
as determined at step 660 being stored in the "no" field of the record. At step 664, the flag MATCH_FLA~ is set to a TRUE
value.
At step 666, reached either from step 664 after a ~match~ or from gtep 658 when a match is not found, the index CURRENT_INDEX is incremented. As explained above, the value of CURRENT_INDEX is used at step 656 to determine the value of CURRENT_PTR, which in turn is used at step 660 to determine the value of SACK.NO.
At step 668 the function CORRELATE_BAGS checks to see if the flag MATCH FLAG has a TRUE value, indicating that a match has just been found. If so, the function CORRELATE BAGS
knows that it is finished with the current record in file SACK2.TMP, and can go on to process the next record in file SACK2.TMP, with the hope of finding a match for that next record as well. In this regard, an affirmative determination at step 668 results in a branching back to step 640 for reading the next record in file SACK2.~MP.
If a match were not found comparing the current record in file SACK2.TMP with the current record in file SORTREC.DAT, at step 670 the function CORRELATE_BAGS checks to determine whether there are yet further records in the file SOR~REC.DA~

59 2~3~
for which a comparison for prospective match can be made. If additional records remain in file SORTREC.DAT, the function CORRELATE_BAGS branches back to step 654 for reading the next record in file SORTREC.DAT. For that next record, the steps 658 through 668 of Fig. 4M are executed, with that next record from file SORTREC.DAT beco~ing the ~current~ record fro~ file SORTREC.DAT.
If, at step 670, it is determined that the file SORTREC.DAT has been exhausted with no match for the current record in file SACK2.TMP, as indicated above the function CORRELATE BAGS goes on to check if a match for the current record in file SACK2.TMP can be found with a record in the file FULLSORT.DAT. Before reading a record from the file FULLSORT.DAT, however, at step 672 a loop parameter "i" is initialized at "O". As seen hereinafter, this loop parameter "i" plays a role in determining the SACK.NO should a match occur.
At step 674 the function CORRELATE_BAGS requires the reading of a record from the file FULLSORT.DAT~t step 678 the function CORRELATE_BAGS determines whether information from the current record in file SACK2.TMP matches the corresponding information for the current record in file FULLSORT.DAT.
Specifically, the PTYPE and zip identifier fields for the two current records are compared. In this regard, the zip identifier information for the current record in file SACK2.TMP
is stored in the location PACKAGE ZIP_ID previously determined at step 650.
If a "match" is located at step 678, the function CORRELATE_BAGS performs three operations depicted by steps 680, 682, and 684. At step 680 the value of the loop parameter "i"
(which points to the first pass record with a match) is used to find the assigned bag number and to set SACX.NO. At step 682 a record is written to the new file SACK3.TMP, with the value of SACK.NO as determined at step 680 being stored in the "no" field of the record. At step 684, the flag MATCH_FLAG is set to a TRUE value.

2~34~

At step 686, reached either from step 684 after a "match" or from step 678 when a match is not found, the loop parameter 7~ is incremented. As explained a~ove, the value of the loop parameter "i" is used to determine the value of SACK.NO.
At step 688 the function CORRELATE_BAGS checks to see if the flag ~ATCH_FLAG has a TRUE value, indicating that a match has just been found. If so, the function CORRELATE_BAGS
knows that it is finished with the current record in file SACK2.TMP, and can go on to process the next record in file SACK2.TMP, with the hope of finding a match for that next record as well. In this regard, an affirmative determination at step 688 results in a branching back to step 640 for reading the next record in file SACK2.TMP.
If a match were not found comparing the current record in file SACK2.TMP with the current record in file SORTREC.DAT, at step 690 the function CORRELATE_BAGS chacks to determine whether there are yet further records in the file FULLSORT.DAT
for which a comparison for prospective match can be made. If additional records remain in file FULLSORT.DAT, the function CORRELATE_BAGS branches back to step 674 for reading the next record in file FULLSORT.DAT. For that next record, the steps 678 through 688 of Fig. 4M are executed, with that next record from file FULLSORT.DAT becoming the "current" record from file FULLSORT.DAT.
If, at step 690, it is determined that the file FULLSORT.DAT has been exhausted with no match for the curxent record in file SACK2.TMP, an error message is created at step 692. When, at step 640, it is determined that the file SACK2.TMP has been exhausted, and a match found for each record therein, processing continues with the function S~VE_ANAL_CNT
described balow.
After the last record is read at step 640, processing continues with the function SAVE_ANAL_CNT.

20~;3~5~

~unction 8AVE ANAL_CNT
The function SAVE_ANAL_CNT (see Fig. 4L) creates a first pass count file ANAL_CNT.DAT which resembles the file COUNT.DAT, except that the file ~NAL_CNT.DAT has the parameters package type (PTYPE), bag type (STYPE), and bag id (SACK.NO) appended to each record.
In the above regard, the function SAVE_ANAL_CNT uses the files COUNT.DAT and SACX3.TMP as input. The file COUNT.DAT
was created by the function FIRST_SORT_PASS (see Fig. 4A); the file SACK3.TMP was created by the file CORRELATE_BAGS (see Fig.
4M).
The file ANAL_CNT.DAT has its records sorted by zip code, then within zip code by client, and within client by mailstream. Each record includes zip code counts by 5 Digit, ZIP+4, and ZIP+4 Barcoded categories, first pass destination bin, package type (PTYPE), bag type (STYPE), and bag ID number (SACK.No).
Multiple records of the following structure are contained in the file ANAL_ CNT . DAT:
typedef struct {
CNT_DATA cnt_dat;
char PTYPE; /*package type*/
char STYPE; /*sack type*/
unsigned int sAG ID; /*bag ID number*/
~ ANAL_CNTS;
where typedef struct long ZIP ID; /*zip code*/
unsigned int STREAM; /*client-mailstream*/
unsigned char BIN; /*bin assignment 1st pass*/
unsigned int CNT5; /*5 Digit count*/
unsigned int ZIP4; /*ZIP+4 count*/
unsigned int BARCDE; /*ZIP+4 Barcoded count*/
} CNT DATA, Thus, the file ANAL_CNT.DAT is sorted by Zip code, then within Zip code by client, then within client by mailstream.
At step 700, the function SAVE_ANAL_CNT (see Fig. 4N~
reads an initial SACK3.TMP record. Then successive COUNT.DAT
records are read and a corresponding ANAL_CNT.DAT record is written for every COUNT.DAT record read. Since there is only 20~3~

one record per package in file SACK3.TMP, and since packages may be made up of multiple records, there will be more COUNT.DAT records than SACK3.TMP records. After a COUNT.DAT
record is read, at steps 702 and 704 the ZIP code is checked to see if it belongs to the package from the SACK3.TMP record.
If the ZIP code belongs to the packages, the package type, bag type, and bag number information from the package is appended to the information in the COUNT.DAT record and written to ANAL_CNT.DAT at step 708. If the ZIP code did not belong to the current SACK3.TMP record, another SACX3.TMP record is read and the new information is written to ANAL_CNT.DAT as in step 708 discussed above. This process repeats until all records in COUNT.DAT have been processed.

Function SET_POST_CNT8 The function SET_POST_CNTS (see Fig. 4N) sets up initial counts files for postage reporting based on the final sorting pass. In this respect, the function SET_POST_CNTS uses input files ANAL_CNT.DAT (generated by the function SAVE_ ANAL_CNT) and AGGR. DAT (generated by the function FIRST_SORT_PASS) to create two new files, file PASSlAGGR.DAT
and file PASS2AGGR.DAT. The file PASSlAGGR.DAT contains counts for all mailpieces that will not be fed during subsequent pass sorting. The file PASS2AGGR.DAT contains counts for subsequent pass sorting. Both files PASSlAGGR.DAT and PASS2AGGR.DAT
include counts for both 5 Digit level rate (qualifying) and Basic level rate (non-qualifying) mailpieces by 5 Digit, ZIP+4, and ZIP+4 Barcoded categories, and also include rejects.
The following data structure is employed for both files PASSlAGGR.DAT and PASS2AGGR.DAT:

typedef struct ~ struct long COUNT5;
long COUNT9;
long BAR_CNT;
} QUAL, NQUAL;
long REJECTS;
} POST_SUM_CNT;

20534~

The function SET_POST_CNTS basically creates the new files PASSlAGGR.DAT and PASS2AGGR.D~T after reading all the records in the file ANAL_CNT.DAT. At the beginning of a loop commencin~ with step 730, the function SET_POST_CNTS reads a record from the file ANAL_CNT.DAT. At step 732 the function SET_POST_CNTS determines whether the bin number included in the bin field from the record just r~ad from file ANAL_CNT.DAT is a bin containing fully sorted packages. This is done by checking whether the element of array FULLSORT corresponding to that bin has a non-zero value. If a zero value exists for the element in array FULLSORT corresponding to that bin, the function SET_POST_CNTS loops back to step 730 for the reading of another record from the file ANAL_CNT.DAT. Otherwise, execution continues with step 734.
At step 734 the function SET_POST_CNTS examines the sack type (STYPE) field of the current record from the file ANAL_CNT.DAT. If the value of STYPE is FIVE_DIGIT or MIX~D_FIVE, the function SET_POST_CNTS knows to go to step 736 to increase certain "qualifying" counters. Otherwise the function SET_POST_~NTS will go to step 738 to increase certain "non-~ualifying" counters.
In the a~ove regard, at step 736 the function SET_POST_CNTS increases the following counters by the values stored in corresponding fields in the current record from file ANAL_CNT.DAT: counter PASSl.QUAL.COUNT5; counter PASSl.QUAL.COUNT9; and, counter PASSl.QUAL.BAR_CNT.
Alternatively, at step 738 the function SET_POST CNTS increases the following counters by the values stored in corresponding fields in the current record from file ANAL_CNT.DAT: counter PASSl.NQUAL.COUNT5; counter PASSl.NQUAL.COUNT9i and, counter PASSl.NQUAL.BAR_CNT.
At step 740 the function SET POST_CNTS determines whether the current record read from file ANAL_CNT.DAT was the last record. If not, processing loops back to step 730 for the reading of a new record from file ANAL_CNT.DAT, after whiCh the steps 732 et seq. of function SET_POST_CNTS are repeated, with - 20~3~

the next record becoming the "current'l record in accordance with the preceding discussion.
Upon the exhaustion of file ANAL C~T.DAT as determined at step 740, the function SET_POST CNTS reads the fila AGGR.DAT
in order to include reject counts (step 742). Then, at step 744, the function SET POST_CNTS writes the entire file PASSlAG&R.DAT, which has the format described above.
Thereafter, at step 7~6, the function SET POST_CNTS initializes all count values to zero in the file PASS2AGGR.D~T in preparation for subsequent use.

Funation INIT GROUP CN~S
Function INIT GROUP CNTS produces a file GRPCNTS.DAT
that maintains counts, by group number, of actually fed and rejected mailpieces. The file GRPCNTS.DAT is initialized with all zeros and is intended to be updated during subsequent pass sorting. The file GRPCNTS.DAT is used for second pass sorting display and insures that mailpieces fed in a wrong mode will not allow the reject count to go negative. Records in the file GRPCNTS.DAT are of the following structure:
struct long FED;
long REJ;
} GRP CNT
~unction PRINT OUT
Function PRINT OUT serves to print information pretaining to the files created in the manner described above.
In particulax, the function PRINT OUT generates hardcopies of the following reports: Group Listing Report (see TABLES 1, 2A -2E); Bag Tags Report (see TABLE 3); Job Summary Report (seeTABLE 4); Postage Summary Report (see TABLES 5 - 6A); and, Bag Audi~ ~eport (see TABLE 7).
TABLE 1 is produced by printing out file ANAL SUM.DAT;
file TOTQUL.DAT; file MAJ TREE.DAT; file FRST PAK.DAT; and, file FRST SAK.DAT. TABLES 1, 2A - 2E show which bins 26 are to be grouped together for subsequent for subsequent passes through the sorter apparatus 20. For example, bins 263 - 267 ' ' . . , , .

20534~5 are to be grouped together as Group l; bin 268 forms Group 2;
bin 269 forms Group 3; bins 261o - 2611 are to be grouped together as Group 5; and so ~orth. Some groups are noticeably absent from TABLE l, such as Group 4, for example. It will be seen below in connection with TABLES 2C and 2D that Group 4 is ultimately generated during a second pass of the Group 3 mailpieces. Likewise, other groups not listed in TAB~E l are generated during successive passes (not the first passes) of other groups.
The output of TABLE l, and of TABLES 2A - 2E explained hereafter, are available upon comple~ion of the program ANALYZE_MAIL after the initial pass of mailpieces through the sorter 20. Using the output of TABLE l AND TABLES 2A - 2E, an operator knows how to group together mailpieces for subsequent passes before those passes are executed. For e~ample, after the initial pass is completed and the program ANALYZE_MAIL has generated TABLE l and TABLES ~A - 2E, the operator would manually retrieve the Group l mailpieces from bins 263 - 267 ànd load those mailpieces into the input hopper 30 of the sorte.r 20.
TABLES 2A - 2E illustrate the output generated upon the printing of the Group Listing Report, which reflects the contents of the bins 26 after passes of the various groups.
Tabl~ 2A reflects the contents of the bins 26 after the Group l mailpieces (gathered from bins 263 - 267 after the initial pass). Each bin 26 has a package stored therein, since it is indicated that these bins are fully sorted.
TAB~ 2A has five headings; "BIN"; "ZIP"; "P"; "B"~
and "ID". The "BIN" h~ading refers to the bins 26 of the sorting machine 20. For example, "bin 3" r~fers to bin 263 according to the nomenclature pre~JioUsly adopted. ~ZIP'' refers to the Zip Code for the package of mailpieces stored in the as~ociated bin. The heading ~'P~' refers to the type of package (PTYPE) stored in the bin. The heading IIB'I refers to the type of sack (STYPE) in which the package in the bin is to be inserted. The heading "ID" refers to the bag identification 20~4~

number, or sack number, of the sack which includes the mailpieces of the bin.
For example, from TABLE 2A it is seen that bin 263 contains a 5 Digit package for zip code 02806, which is to be placed in a MIXED_ FIVE ("M5") sack bearing sack number ("ID"3 "2". As TABLE 2A is further read across the page, it is also seen that bin Z64 contains a 5 Digit package for Zip code 02809, which is to be placed in the same MIXED_FIVE ("M5") sack bearing sack number (~ID~) "21'. In thiS regard, if a number .is not listed under the heading "ID" for a bin, it is understood that the mailpieces from that bin are to be placed in the same saclc with the preceding bin(s). Thus, from TABLE
2A it is apparent that the packages from bins 263 - 2634 will all be placed in the same sack (i.e., the sack bearing sack number ~2~). Similarly, the packages from bins 2635 - 265~ are to be placed in sack number 3: the three digit packages from bins 2652 - 2654 are to be placed in sack number 4; and so forth. Noticeably, bin 26124 houses the MIXED_STATES sack, which bears sack number 1 (see the function MAKE_BAGS, step 502, for an explanation in this regard).
After running Group 1, and loading all the mailpieces from Group 1 into sacks bearing sack numbers 1 - 12 as indicated in TABLE 2A, the machine operator requests that a new sort scheme be loaded into memory with instructions to direct pieces in Group 2 to the proper bins. This is done by referencing file SORTREC.DAT (the creation of which has been described above). The operator also loads the mailpieces of Group 2 (from bin 268 from the initial pass) into the input hopper 30 of the sorter 20. TABLE 2B explains how the Group 2 mailpieces will be distributed across the bins 26. The Group 2 mailpieces from bins 263 - 266 are all to be collected for insertion in a THREE_DIGIT sack which will bear sack number 13;
the Group 2 mailpieces from bins 267 2619 are all to be collected for insertion into a STATE sack which will bear sack number 14.
After collecting the Group 2 mailpieces into sacks 13 and 14 in accordance with TABLE 2B, the operator loads the ~053455 mailpieces for Group 3 into the input hopper 30 of the sorter 20. The sorter 20 directs the Group 3 mailpieces to the bins 26 in accordance with TABLE 2C. In this regard, TABLE 2C
directs how the sacks numbered 15 through 21 lnclusive are to be filled (i.e., from which bins packages are gathered for filllng the respective sacks). TABLE 2C also lndlcates that bin 2 6128 is to be further sorted as Group 4. Recall that Group 4 was not listed in TABLE 1, the reason for which is now understood. Group 4 is derived from Group 3, inasmuch as a o secondary sorting pass arising from Group 3 necessitated the generation of Group 4.
After collecting the packages from the bins 26 after the running of Group 3 as indicated in TABLE 2C ~ the operator collects Group 4 from bin 26l28 and places the Group 4 mailpieces in the input hopper 30 of the sorter 20. TABLE 2D
reflects the contents of the bins 26 after the running of the Group 4 mailpiec8s. From TAB~ 2D it is Seen that packages from bins 263 - 2617 are also to be included in sac~ number 21 generated during the rUnning of Group 4; that packages from bins 2618 - 2630 are to be collected together for insertion into sack number 22 and so forth through sack number 27.
Subsequent groups are run in accordance with TABLE 1 and in the manner of the foregoing discussion. TABLE 2E
reflects the contents of the bins 26 upon the running of the last group, i.e. Group 86. It is thus seen that a total of 722 sacks were filled by the mailpieces run during the illustrative batch.
TABLE 3 shows a partial listing of bag tag data generated by the program ANALYZE_MAIL. The data for generating TABLE 3 is obtained from the file BAGTAG.DAT in conjunction with the table published by the USPS in the DMM. TABLE 3 reflects the contents of bag tags printed for the sacks filled in accordance with the execution of the program ANALYZE_MAIL.
Each bag tag has its first three lines of text generated in accordance with the format prescribed by the Domestic Mail Manual In addition, a forth line of text tells .
the operator what group was run, and which bins to collect 20~34~

together for insertion into the bag. For example, the first bag tag generated for Group 1 reads:

1:3 - 1:34 Sack: 2 indicating that Group 1 bins 263 - 2634 are to be collected together for insertion into a sack bearing sack number ("bag number") " 2 " .
Thus, using the bag tags generatPd by the sorter 20 as a result of the execution of program ANALYZE_MAIL, an operator can visibly determine, for each group, which bins 26 are to have their contents loaded into a given sack, as well as the sack number for that sack. Moreover, advantageously the bins having contents for the same sack are consecutively arranged (i.e., arranged in successive physical relationship), so that the operator need not jump around from bin to bin, as by walking around the large sorting machine 20, for example.
The Job Summary Report in TABLE 4 is produced using information from the file CLIENT.DAT, which file was produced byt he function MAKE CLIENT COUNTS. The Job Summary Report demonstrates the accounting capabilities of the program ANALYZE_MAIL. The report is a ~rief summary of total fed and total reject mailpiece counts maintained by individual mailstreams.
The Postage Summary and Postage Summary by client/mailstream is display in TABLE 5 and TABLES 6 - 6A, respectively. These reports are produced from information obtained from the file CLIENT.DAT. These reports demonstrate the requirements for maintaining detail counts during execution of the program ANALYZE_MAIL.
The Bag Audit Report shown in TABLE 7 demonstrates a unique advantage of the program ANALYZE_MAIL. This report is generated from information in the file ANAL_CNT.DAT. The program ANALYZE_MAIL organizes data in such a way that counts are made available by package, bag, client, mailstream, and ZIP
class categories. This feature is needed to verify the accuracy of the sort process and the accounting.

2~53~5~

While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various alterations in form and detail may be made therein without departing from the spirit and scope of the invention. For example, although not specifically mentioned herein, it should be understood that many of the files can be written to random access memory devices, such as a magnetic disk.

T ~
GROUP ~ ~ING FILL:

FIRST P~SS RESULTS

For futther sottins...
Mark the 3ail as follo~ls:
BINGROIJP # ~IN GROUP

4 1 ~i7 46 J 1 . 58 l~7 6 1 ~9 47 7 1 6~ 49 a 2 61 49 lB 1 j 7~ ~

2C~0 78 61 27 2~ 81 6634 331 i~1 83 6644 3~' ~2 9u85~7 67 C'~ 88 ~7 36 27 ~39 ~7 37 ~9 9~

3q 33 9;~ 71 3 3d 9~, 7 48 4~ 99 79 51 41 l1~13 82 53 44 11~6 &6 e54 4r5 1~7 86 20534~5 .j. ,.. ~ . , ~ .

Cf ~ n ~ r~ rnrnrn r rn rn rn r:n rn ~nr n I : . '': . ... ~
~,3 ,~ ~ .9 ,~ ~ 9 ~ ~3 ~ ~ ~ ~ ~
'Z r~U~g~U~ur~

' r a ~U) ~Ln U~Lr) Ll L~)tnr~ ~ ~rnrn rn rn rn rn rn rn rn rn rn ~r~r~C5 ~ 9 rc -- cu I
~ r~r~rnrnrn rn rn rn n rn rnr~rn r-~ ~ r~ r~ ~ ~ ~q ~ r~

b ~ g r ~ ~ ~ t~ CU ~"" tS~ ~ ~u t,U ~ r~- ~q Z ~ tU r ~ ~ ~ u~ o ~ ~ t9 t9 _ .~
m I
.0 _ r=l I
U~ E2r~r~r~crJrnrnrnrnrnrnrn~nrnr~rn ~` r m~q r~ L~ ~ r~ ~ ~ r~ m r~ ~ ~n ~ r~ rn t ~t,~ ~ Cu t ~ ~ t~J r~ ~ 9 ~ t9 tg ~ rg ~9 ~ tg g ~s r~
_t ~ i~~tr ~ t r'~UtrU~q~t ,,~ ~,iJ~ in~ ~ i--$ CO ~ ~ ~ __t~U

rn ~r'3 ~U
1-- r--i. c~ ra ~iJ ~ ~r~r~r~rnrnrnrntnrn nrntnrnrntn ::~ rn 3 --CUC~_ir~r''~r'') ~ t~tC~r~ ~t~r~t r ~l I

- ~` ~ Ir/~nfn 20~34~
. .
, . ~ ~

z r--r.~
r~

r~

r~ r~ n fn =~ r~ ~

~ G~,,~L~
~fg~
Z ~ ~
f~ I

~ r~ ~ rn r:. r.~l _ ~ 1~ ,,.3 Z L~
f~ 1 ..
-o .~ , f~ ~ n fn rn ~ f-. ~ ~,.~ .~

~ f~ r;~ ~
~5 ~ _ r~ _ I
f~ . ~l~
Ql 2 fn _~
r~
C
~.L .~ '5 ¦~, rn fn fn r.~ r`~ f'7 oz o ~:LI_ ~ ._ f l----f.! l~ ~ Z ~f rSI I

CL Ln U~ t'~ 2 0 ~ 3 4 ~ ~
L L L~
r~ ~ ~
Z r_ t.~ l r_ t~ I
~_ I
r~ I
r~ cn rn ~. r~l m r~
t L
~1 ~; ~ r~l ~ CS~ C5 Z L.~ _ ~O

r~
_ l r~ t;n rn r~. IJ~ ~ r~
r~
~_ ~r.~
r~ C9 3 r~ l m I
U~ r~ I
r~ rn rn rn r~ 3 r~

o 1~ ~ Ln m r~
11: r~
r L r~
r1 1 L~ ~ r~ 1~ tn rn rn :~:rn'~ tL l~l~lnt-.~r.
r Z O
#L~ r~ ~ r 1~ ~
o _ r r~

z Ir-~ r ~3~5~
I
, I
U~ ~U7 ~ ~ U~ ~U7 U~ 7U~U7U~ u~7 ~lrJ U~UX
r u7 U~ U~ ~nLr~ U~ ~n U~ U7 U~ U? U~ U7U~ ln U7 UJ U 71--~ u~ 7 t ~ C,J L~ C~ S ~ C'l t ~ ~ t~ ~ .D r ~ c~

Z r~r--ry~C~, Jr-- ~r~rr_rDror~u~r~ r C Jr~J
ra C
r~
~U7 ~ U U U ~U ~ U~
O_ IJ~ Ll~ Ll-) In 11~ 1~ Ll~ Il~ IJ~ IJ~ U7 Il~ U7 1~ U'J l~ Il~ IJ~ Ll~ L~ U7 Ll~
r t~7t~r~ U r ~

J ~ f~ u~D r--r--a~ a~ a~ a~ ~ ~ ~ ~ r~J l:U
t ~ I
r~ 1~

cl ~ u u ~ u~ u~ U~

tl ~_ a~ C~ ~ r ~ ~ a~ r~ c~ r ~ r~ r ~ ~J~J ~ a Z Ll~ 1~U~ rS'r~co~CUl~U~1~IJrU~, ~ l~.1 u~ rs~ ~ U~ IJ IJ U~ U~ ~ IJ X~ ~ ~ L~ U ~ ~ X ~ ~ ~ ~ ~ ~ ~ ~

.~ r~ ~rqrq~r ~
&I Z ~ r~ ~ a ~ a~ a ~" ~ rr ¢~C~ r` ~ ~ ~--~ ~ 3 rn ~ ._ tn ~ u~ ~

~r r~ 1~mu~u~ u~ 1- u~1~ o ~
. r~ --.' ~ LI~U~ ~r71J~ U7-1~u~ 7~ u~ C ~ r-7 mrq~r~r ~r rqr ~ 0 ~ r r~Z .C ~, ~ JC~ a7r~7-0~ uq7r~ r--~-7~ q7a7r-7~qrC5~C~7r'7a7 r~ I

20~4~
r~ !,1~ U~ Ll~ Ln LI~U7 U~ Ln U~ Ln U1 U ) U~ U~ U~ Ln Ln r., U~ Lr7 u~ Lr7 u~ U7 1-~ L ~ Ln u~ Ll, U~ u7 Lr7 Ll'7 u~ Ll~ U~ t~7 r~

r tJ' 0 0 ~ CJ~ Lr7 _ ~7 _ ~J ~ Ll~ ~ 1~ r~7 U7 Ll-J ~ 0 1 a~ rl~ Ll~ r- 0 ~
10 ~O .~0 ~O ~ 0 ~O ~D ~.t:l ._0 ~O ~Cl ~D ~17 ~O ~O ~O ~O ~
Z~r~u~ 9 r~ I
I
LI~Ll7u7Lr7Ll7U7Ll7Lr7Ll~u7L~u7 ~U7LI~U7L~U7 rnrn CL Ll~ U~ Ll~ U7 Ll~ Ll .7 Ll~ U7 Ll~ Ll~ Ll~ U7 Ll~ Ln U7 U7 Ll~ U7 r ~7 r~7 LL ~ 9 _ C57. ~J UO" ~ a~ L ~ ~ 7 ~ Ll~ ~ r 7 r_ ~ ~ Lr7U ~ ~ ~ r- a7 070 a~ r --1--I _,, r~ ~L71_ r I ~J ~J

r~ p~ U7 L~ Ll~ L~ L~ Ll~ Ll~ L~ u7 L~ U7 Ll~ u7LI~ Ll~ L~ un ~ ~ rJ7 r~
r_L Ll~ U7 Ll~ Ll~ Ll~ Ll~ Ll~ Ll~ Ll~ Ll~ Ll~ Ll~ U~ Ll~ Ll~ U~ U~ t~
r L Ll r _I~J~ r ~r~0--r~ ~ ~ u~ L~ r--r--r--~ r--0 ca0 0 c~
L s;t ~ ~ s,t ~ ~ ,s," ~' ~ r~t ~ i,t Z Ll~ Gt Lt :9 Ll~ C9 Ll~ C9 Lt~ CS:I L1~ 19 Lt~ CSt Ln ~; t Lt~ CSt Ll~ 1:9 rr, ¦ lJ r~lJr~ r~ `~ LI-~ ~ t ~I;t r--~ C~ t ~ r~ ~ tSt r.~ I ~ t~
PS_ E,rt rr~ Lt u u u u u ,t u ,t un u ,t u t u ,t u ,t u t unu ,t ~ Lr-t L~.~U~ ~n .~~ c Lt~L~Lt~Lt tLt~Lr,tLt~Ll~Ll~U~Lt~Lt,tLt~LnL~U~L~unLl~r~t + I
-~ CL r~ Lnr~r~5~ln~r~ ---~r~r~r~r~
CL ~ ~ LI,tutLl~Ltr '~rL--'r--r~G~00'~'00'~
O ~t ~ D ~t ~D ~Çt ~ ~Ct ~D ~t ~ ~t ~ ~ t~l~
r t ~C~ t5 ~9 rgCi;~ CS .9 19 CS:I t~ !9 r9 cs tS;t C~t ~ Istst CD
rL r~ ~J~ "~ $ ~ u~" UJ' ~, rr~ r--~t'~ rrJ'~' .... .
~, 3 , I t tl C' I
~rrt r t ~L _Ll tL~~L~--tLOL~LI-tLOLOU~L-tLI-lLOL~--tu tLOU~L
~J C
--t- -t r L IJ~U~Ll~Lr~Ll~LnLl~U~Ll~Ll~U~Ll~Ll~LnL~Ll~Ll~Ll~U~r~
OZ o :U:L~ rS~ L~ rU~rr~r9L~t'J~tr. ~r~0C~--Lt~
o ,--t r--rJ~ IU ,s~--r5t Ln r--~ r~--t r~3 Ln r--rr rD
~ t ~ ~ ~ ~ u~LI~ ~ ~t 1--r--r--r--r- 00 0 0t~.trJ~r~ ~ r~
r~ CL r~t r5"9 5t t~9 tS;t r~t rSt rS,t ~t ~t r~ r~t rs~ r~t rs~ r9 r~t rs~ rs~ r , r~, r--Z
t ~ 1. lJ r~i r~ ~ ~ Lt~ Ln ~Ct ~ r--r--J;t 0 0~ rJ~ r9 r~ I r-- j- J 2 0 ~i 3 4 5 5 r l-~U~L~LnL~nLnL~LnlrJL~L~ lJ~ Ll~Ll-Jr`)u7(~
r~D--r----r~ LrJ~r-~r~---r--~-~r~
rr r cr~ C~ tr-cr L7' cr cr ~ ~ ~rr rT ~ rJa rr ~r ~r r~ o cr cr cr c~ ~ rr rr cr t r tr ~rtr r~ rr~J
Z Ir--~ r--~Jr ~ ~C~Jr--;:~Jr--.. Jr--j~~_)r---~Jlo~l' JI--t9 t~
C~J r--~ 1' r- r-~
L~:l Lr--J,~L~ L~f,_;~ ; L~ r~t ~ Ll~ l.~ Ln L~ Lr~l~ Lr~ Ll~ L,~ ~ ~ Lr~ ~ L~L~ r-~
L-~ r~ u~ C9 r-r r-~rcr U ~ nJ -r ts; Ll~ c~ ~n ~n ~r~ C
r_ rs c~ _ t J L ~ ts r~ j~ rD r J It~ J--;;I- t3 ~ LI~ ~ U-l t-~
tJ~cr~rrLT~C~trcrtrcr~cJ~r~r tOcOcr~rcr~l.0~3ro~cr -r tr a tr crtr tr tr cr tr cr cr a~ tra tr tr a~a~
L~--D--~r~ _ ~rJ _ .~J ~ .CI _1 ~.Jr~ .C~ rJ--.Ir~l~ L~ L,~r--r--c~:lcn,l~cr~:"
rc~ I , ~D cr t~
; - ~ r P~ IJ~LI L~ L7~ LI L~ t~t~
u~InL17L~U~JU~ mLl~U'~ Ll-~L~l,l-)Ll'~ r-~t-~
c~ r~ ~ ~ c-r ~ l--~ ~ r~ . , cn-- ~ J----r-i ~,iUiLl iu~. irLn~ r~ c5~ cO~
cr~ r~ c-r cr cr. c r c-r rr ~1~ c-r c o rD t~ a~ c~c~ c~ 0 t~a rr cr~ r~ ~ C~ ~ r~ r~ r,~ r r~ ~ r r~ rJ~ c~ c r~ rT~
~ j~ t9 L17 tS7 Ln ~ L~l~ ~ L ~ U~ LLn rg IJ~, r~ IU 3 r~ r~ c3 rcl r l l ~O C~
NIJ t.-, I~
~3 o C~ Ll~ Ll7 Ll ~ u7 Ll~ ~L;E Ll7 L ~ ~u,~7 t~ tq tq r~ n crJ l nc n ru r L~UnLl~Lr~Ll~L~ Ll~Ll~L~lJ~rql~t~l~r~Jl~lJ~r`~
I
, L ~_ ~ o r~Dm t,~ t.~J t-~._O ~T~ _ C.Jtq rl ~ E; ~t~Jr~C;: ,~ 1.1l 1:~16:
u: r~ trcrCr~Cr r L~rt~Dr~rrr~crr3 ~r,~rSJ~, ~C~ D
~cJ~t~tr~t3~c~tr t7~c~tr~t~o~tJ tJ~trcrcrtr~cr cu z I ~~ Jta~r~ ~C~I~ur~ " Dr~ir'-t~ rr~cr~

r~ l -tn ~_ tI l-- ~ r5. t~
L-l t5~ ~ t=l 1~ 1~ . r-I_ c - ~ ~ L LnL~L~L~ ~u~t~tqt~tqt~ o~r-ntr ~ -- ~ Ln Ln u~ un u~ un Ln un u~ Ln Ln Ln lJ~ -.Ln t~
O ~ rn 3 o%
rl ~g r~ --t' J r-l~ c3 $ c J~ rJ jJJ ~Dt--~
0_l-- 4- r_ r-u~nunU~u~ ~r--r~ c~c~ t~c~--r~ ~ou~
:::1 ~C~ cr rJ~C7~ a tr~cJ'trC' tr~r't~rC~ cc`rcrr~tro~t~rr ~-- ~ ~~t~ tq~."r~C3~r~LC~o~r~cOr ~cot ~ror r~

I'~.B~ 3 R~!` . **~*~ **~* MXD CHICRGO IL 6~6 *~*~*~ ~i PROVIDENCE Rl ~28 ~ GROUP SFP~R~TOR ~ 3r LTRS MXD ST~TES *~ GROUP SEP~R~TOR ** 3C LTRS MXD 5-DG PKG
:~ Sroup ~ EY~NSTON IL 6el2 ** Group 1 ** EY~NSTON IL 6~2 I-i*l*]~ }~ :3 S~IC~ 3 ~ 1:311 SaCk: 2 PROYIDENCE Rl ~7a PROYIDENCE Rl ~29 PROVIDENCE Rl a29 BOSTON MÇ~ ~21 3C LTRS MXD 5-DG PK6 3C LTRS MXD 5-DG PKG 3C LTRS MXD .~-DG PllG 3C LTRS
EYPNSTON 3L 6~2 EY~NSTON IL 6~a2 EY~NSTON IL 6~)2 EY~NSTON IL 6~2 1:3 ~ 1:34 SaCk: 2 1:3~ :J1 SaCk: 3 1:3J ~ 1:~1 SaCk: 3 1:52 - 1:54 Sack: ~ -M~NCHESTER NH 9i~ PORTSMOUTH NH ~3~ PORTL~IND ME ~4~1 BRNGOR ME 044 EYRNSTON IL 6~2 EYP,NSTON IL 6e' EY~NSTDN IL 6a2 EY~NSTON IL 6a2 1:55 - 1:5a Sack: 5 1:59 - 1:J9 Sack: 6 1:6~ 61 Sach: 7 1:62- 1:f!7 SlCk: 3 DIS SPRINGFIELD MFl el~ DIS SPRINGFIELD M~ J SCF PROYIDENCE Rl e~8 DIS MRNCHESTER NH QiC
3C LTRS M~ 3C LTRS M~ 3C LTRS Rl 3C LTRS NH
EYPNSTON IL 6~2 EYPNSTON iL 6~2 EYPNSTON IL 6~a2 EYRNSTON IL 6~2 1 68 ~ 1:97 SaCk: 9 1:6B ~ 1:B7 SaCk: 9 1:8B- 1:B9 SaCk~ 9~- 1:Ie!4 SaCh: 11 DIS PORTL~ D ME ~ DIS PORTL~ND ME ~4~ X*~ * WHITE RIVER JCT ~IT ~57 3C ~TRS ME 3C LTRS ME ~* GROUP SEP~R~TOR ** S~C LTRS
EY~NSTQN IL 6~ EY~NSTON IL 6~ ** Grouo 2 ** EYRNSTON IL 6&E~
1:1~5 - 1:123 Sack: 12 1:1~5 - 1:1~3 Sa~k: 12 *~*~*~ 2:3 ~ 2:~ S3Ck: 13 ~IS WHITE RIIIER JCT ~5~ *~ **~** STORRS II~NSFIELD CT e6268 ST~MFORD CT ~69e2 3C LTRS YT ** GROUP SEP~RPTOR ** 7C LTRS 3C LTRS
EY~NSTON IL ~2 ** Grollp 3 *~ EVRNSTON IL 6a2 EYRNSTON IL 6~2 2:7 - 2:19 Sack: 14 ~ 3:3 - 3:3 Sack: 15 3:4 ~ 3:4 Sack: 16 H~RTFORD CT ~6~ HRRTFoRD CT ~6~ IIRRTFORD ST a61 HRRTFORD CT ~62 3C LTRS MXD 5-DG PKG 3C LTRS MXD 5-DG PKG 3C LTRS MXD 5-DG pKG 3C LTRS ~IXD 5-D6 PKG
EYRNSTON IL 6Q2 EVRNSTON IL 6~2 EV~NSTON IL 6a2 EY~NSTON JL 6~2 3;5 - 3:47 Sack: 17 3:5 - 3:47 S~ck: 17 3:48 - 3:61 Sack: 16 3:~2 - 3:78 S~ck: 19 NT~ HRYEN CT ~63 NEW HRYEN CT ~63 NEW HRYEN CT ~64 NE~ HRYEN CT ~64 3C LTRS MXD 5-D6 PKG 3C LTRS MXD 5-DG PK6 3C LTRS MXD 5-DG PKG 3C LTRS MXD 5-DG PK~
EYRNSTON IL 6~2 EY~NSTON IL 6~2 EYRNSTON IL 6a2 EVRNSTON IL 6~2 3:79 - 3:1~C Sach: 2~ 3:79 - 3:1e~ Sack: 2~ 3:1~1 ~ 4:17 S~ck: 21 3:1~1.- 4:17 Sack: 21 20534~5 ~BLE 4 Clien~ ailst~ealn Col.lnt Sl.lmmary based on ~ st p~ss ~es~ ,s Cl i ent (la~a~ Insllr~ance . -------------------------------------------- ~E~ REJ
Rl.~to ~ 7 3 (~1) Li1~e 147~
.. (la~3) Health 1~5* 114 Cl i ent S~.~b--~rotal . 17~399 ~943 Cl i ent (~3): Ut i l ity Co.
--------------------------------------------- FED REJECTS
) Service bill~ 663B~i 954 Cl i ent Sl.~b-Total~C~3~35 g~i4 ;, Client t~6)~ F~llblisher~
~--~~~~~~~--~~~~~-~~~-----FEDP~EJF.CTS
t ~ ) M~ 9 ~ 2 i ll e ~ 3 ~.2~34 . ~225 Cl ien~ Sl.~b-To~al3~a34 2~ 5 ~BLl~ 5 STER F~OST~GE SUI~lM~RY ~lETERED ~ND PER~l I T COlrl~ I NED
B~sed upon First Pass Counter~
:i-5 DIGIl- LE~EL F~IECE ColJNT F~ER F~IECE R~TE C05T
_____________ ___________ ______________ ___________ ZIF'~-4 ~arcoded 5 ZIP+4 J DIGIT 179~3~ .13;~ 6~.48a :. ------ ________ ______________ ___________ 5 D i g i t To t a l 179~39 ~'3633 . 1 4a ~SIC R~TE LEIJEL F~IECE COUNT PE~ PIECE R~TE COST
________________ __ ______ _ ____________ _ _ _________ .: ZIF'+4 ~arcoded ~ ~.167 : ZIP-~4 ~ ~.167 ~ 0 S DIGIT 13557 ~. 167 13954. ~19 P~sS 1 N~n-S~an 7~ . 167 117~. 674 _____________ ____________________________________ Basic Total 9~579 151~6.69-5 Digit and B~si~ 9~18 3a7~

.......
1ifyino F~e~enl;age tReje~ts Ex~ ded): ~9 Percent~g e Z I F~-~ 4 ~a~od ed ( Re j ect 5 Exc1 l.ld ed ):
PercentaDe ZIF'-i-4 ~Reject~, Ex~luded~

.:
. .

... .
' .
"

F~OSTFIGE ~U~ QR`~ FOR CLIENT ~ ) Insllrance ~ase~ 'oon Fit~st ~'~ass Comntet~s ~34~
F~ER F~IECE ~lEl'ERED R~TE by ~ailstt~eam _________________ ._______________.__ ~ )Q~.lto l~.lc7 (~l)Life la.!a0 ~00~)Health 0.00 5 DIGIT LEVEL Mailstteam F~IECE COUNT F~ER F'IECE RQTE COST
_____________ _____________. __ ___ ___________ ______________ ___________ Ll~l+4 ~~rcoded (~)QI~to ~ ~.13~ ~.66~
~0i)Life 0 ~l.13'c 0.000 (Qll~l~) Hedlth 0 ~ c~ ~1. 00~1 total ~ 0.66 ZiF'+4 (000)Ql.;to ~ 0.132 '~lal)Life ~ 0. 1.,~ 0.000 ( 01a_ ) H e a l t h ~I Ql . 1 3'c e~
tutal 0 ~-000 5 DIGIT ~0~la)Q~.Ito 12e'-1'c 0.1~c 1~o9'~.984 (~,01)Life 1~74 ~ 14'~.76a (003)Hedlth 10988 0.13'. 14~.416 t~t~l i4~27'~ 18~'~6.i6C
_____________ ____________________ ___________ ______________ ___________ 5 DiSit lot~-.l ;40~7 18r~i6.8.5 ~QSIC RQTE LEIJEL Mailstredm F'IECE COUNT F'ER F'IECE RQTE COST
________________ ____________________ ___________ ______________ ___________ ZIF'*4 ~drcoded ~ )Q~Ito ~ 0.1O7 0.000 ~01)Life 0 ~. lo~
~0~)Heal~ 7 t ot~ a~2, ~Ir-'~ to ~ ~.167 ~ 0 ~00i)Life 0 ~.i67 ~ 00 ~00~)Health ' 0 ~ 7 ~ 0 total 5 DIGIT ~la)~llto 24442 0. 1~74~81. 814 ~0~1)Life c83 0. 16747.~'-'61 ~00~)Hedlth 155~ 0.107'~59.184 total ~c77 4~~ J9 F~ass ! Non-Scan (0~)QIlto ~o08 2J. 1~7 00C. 5_o (~l)Life l'cl 0.1672~. ~c07 (003) Health 114 0.10719. ~J8 total .,84~ 641. 781 _____________ ____________________ ___________ ______________ ___________ ~BI,13 6A 2 0 5 3 4 5 ~

. . ..
. .

...
.
Postaae Due (Permit) . 1413~ 19~7.87L
(F~et~it PostaQe ~d~justed to ex~1ude rejects) Postage Due ~Permit Re.jects Exc1uded) 13997 18q8.6'~9 Pos'~ge Due (Meter) ~16~8.994 Metered Postæ~e Paid 1~6~67 19345.91~
Qdditional Metet~ed Postage Due 1763.~84 (Metet~ed Postaoe Qdjusted to exclllde t~e,jects) Postage Due ~Meter) ~ 6.458 l~;etered Postaoe Paid 15~659 !93a7.~94 Qdditional Metered Postage Due 1618.7~4 Quaii5~ir,G Pet~entace' ~Re,iec's Exc1l.~ded): 84 PercentaGe ZIP~4 ~.arcoded (Rejects Exc1uded)~
PercentaGe ZIP'4 (Rejects Exc!uded):

20~34~5 G

I' r~, ~ G l. IJ ~ --~ ~; ~ r~ ~ ~ r~ r;J _ ~ _ t~ ~ r~, G .~ f~ lJ ~ u 3 ~ _ '' ' ~ ~ ~ a~r-~
L~ ,l _ a H

I L ~1 1~' ~1 1~,1 01rJ ~ IJ~r~ l.r r~ ~t~ ~r~ ~r~t~ ~r~ -J~ r,,~ ~r~r~r~
Ulr~. .. .. .. ...... ,.. ~,~, u~
~L
Ul Ul ~n u u u~ u~ ul ~ ul u U U~ U Ul ul u ~ r~ ~ r~l ~ r~ ~ ~ r~J t~ r~ q ~ ~ -J
E r~# ~-1# ~t# rl ~l.~l# rl#.~l# rl#.~l r-l# ~i##.rl rl -rl#:#:#-~l#-~l## ~
n ~ n ~ n ~ nnn n n n ~n n nn n n n ~J
~ ~ S tuc+~ tut_~ tur_~ tua~r_tuC~r_o~C~utut_~Ut-t-tua~t-ccctuccc~c~cc~
ty ~ t -~l O ~ ,1 0 t~ O ~ tJ-,~ J tJ-,~ 00 r~ U~ ,~ r~ ,1 rl~ ,1 r~+~ rJ, rl ,- r~l ,l rl ,l ,l r~l-,l r~ r~ ,- ,l rJ rl r~ rl ,, r~ r~ N ~l r~-~l rl N~l--al 5_ r~l S- S ~ t_ a~ lr rl t alalal~ls. al~lr rlS r l75 r~la-, r-Jrn~ ~rn~ ~rn~ ~rnrnrsJ~:rn~:rn:~rn~:rnrn~rn~rnrn~ n~ rn~rn:~
t~
~: ~ r~, 0~ tU r~
cu ~Y rGo ~o ~o Yooc~ o o o oo o oo o o o r~
rY rJ ~t~ S Yt~ ~ Yr~ t ~Ir~ur~ ~ r~ S r~ ~r~ ~ r~r~ t, rJ ~, ~, r~t~ t~ t~ ~ t o r~ r~ ~ tJ a~ tJ tut~ C.l aJ t~J aJ tu a, ~ t~ tu tu aJ tu tu tu aJ tu tu L~rn r5 ~ ~ .~ rs ~ r ~ ~ ~s u U,~t U U~ U~+)~ U y U~ Ul+~ U~+~ I't U~'t U Ul.4~ U'l Ul Ul Ul~ U~ Ul Ul~ Ul~ Ul ISI
rt' I't r ~ cn ,~ n ,I ,,n ,, ,ln ~ ,,n ,~n ,,n r,~ n ,~nn ,, ,!nnnsJ ,~nnn, n ,~nn ~.~1 .-- rr.~ ~~ o ~ _' 0~ _. ,, ~ I't ~ _.~ _.~ --~ I't 5~'t _.~ _. ~:;~ I't _t _t _t --;+~ 5 5 _t~ 5+~ 5 5 r lt ~ t~ ~rl~LL ~rl~lL ~rl ~U t~ ~u lu~u~ulL l~ulLulL~uL~ u~uu tU rlir~lr~ tU~r~ CU~ tur-~r~ r~r~r~r~r~rl~ ~t~r~COr~
~,C H ~ r~ lr~l r,r~r~ r~r~r~r~r~r~r~r~ r~r~r~r~r~r~r~r~r~r~r~lr~ r~r~lr~r~lr~r~r~

Claims (12)

1. A sorter apparatus comprising:
hopper means into which a plurality of mailpieces-to-be-sorted are introduced;
reader means for reading postage address destination information provided on said mailpieces-to-be-sorted;
a plurality of bins into which said mailpieces are sorted;
conveying means for conveying said mailpieces from said hopper means, past said reader means, and toward said plurality of bins;
gating means for directing a mailpiece into a selected one of said plurality of bins;
control means for controlling said gating means, said control means being connected to said reader means for obtaining therefrom signals indicative of said destination information for said mailpieces, said control means including logic means for determining how said mailpieces should be classified according to predetermined criteria into packages of mailpieces and how said packages of mailpieces should be classified according to predetermined criteria into sacks, with said control means connected to control the activation of said gating means whereby mailpieces classifiableable in a sack but stored by reason of said criteria in a plurality of bins are gated into a plurality of physically adjacent bins without destroying the package classification of said mailpieces.
2. The apparatus of claim 1, further comprising:
means responsive to said control means for generating labels for attachment to said sacks, said labels bearing information including the bins from which mailpieces should he extracted for inclusion in a sack.
3. The apparatus of claim 2, wherein said labels also bear a sack number.
4. The apparatus of claim 1, wherein upon an initial reading pass of each of said mailpieces-to-be-sorted through the sorter, said control means associates said mailpieces into groups by gating the mailpieces of each group into a set of bins corresponding to their group, said sets of bins having a plurality of bins being comprised of physically adjacent bins of the sorter, and wherein said control means provides an indication of which bins contain each group of mailpieces.
5. The apparatus of claim 4, wherein said control means associates said mailpieces into groups for the purpose of subsequently feeding each group separately into said hopper means for a subsequent pass through said sorter.
6. The apparatus of claim 5, wherein said control means associates said mailpieces into groups and by gating the mailpieces of each group into an associated set of bins, each of said groups being assigned a group number and each bin having a bin number, and whereby, as the group numbers monotonically increase during said assignment, the bin numbers included in the associate set also monotonically increase.
7. A method of sorting mailpieces comprising:
introducing a plurality of mailpieces-to-be-sorted into a hopper means;
conveying said mailpieces from said hopper means, past said reader means, and toward a plurality of bins;
reading postage address destination information provided on said mailpieces-to-be-sorted using said reader means;
classifying said mailpieces, according to predetermined criteria, into packages of mailpieces and in turn classifying packages of mailpieces, according to predetermined criteria, into sacks;
using gate means to direct mailpieces into selected ones of said plurality of bins;

whereby said classification whereby mailpieces classifiable in a sack but directed by reason of said criteria in a plurality of bins are gated into a plurality of physically adjacent bins without destroying the package classification of said mailpieces.
8. The method of claim 7, further comprising:
generating labels for attachment to said sacks, said labels bearing information including the bins from which mailpieces should be extracted for inclusion in a sack.
9. The method of claim 8, wherein said labels also bear a sack number.
10. The method of claim 7, wherein upon conveying said mailpieces on an initial reading pass through the sorter, said said mailpieces are associated into a plurality of groups by gating the mailpieces of each group into a set of bins corresponding to their group, said sets of bins having a plurality of bins being comprised of physically adjacent bins of the sorter, and wherein an indication is provided regarding the bins which contain each group of mailpieces.
11. The method of claim 10, wherein said mailpieces are associated into groups for the purpose of subsequently feeding each group separately into said hopper means for a subsequent pass through said sorter.
12. The method of claim 11, wherein said mailpieces are associated into groups by gating each of the mailpieces of each group into an associated set of bins, each of said groups being assigned a group number and each bin having a bin number, and whereby, as the group numbers monotonically increase during said assignment, the bin numbers included in the associated set also monotonically increase.
CA 2053455 1990-10-06 1991-10-15 Mail sorting apparatus and method Abandoned CA2053455A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US59818990 true 1990-10-16 1990-10-16
US598,189 1990-10-16

Publications (1)

Publication Number Publication Date
CA2053455A1 true true CA2053455A1 (en) 1992-04-17

Family

ID=24394594

Family Applications (1)

Application Number Title Priority Date Filing Date
CA 2053455 Abandoned CA2053455A1 (en) 1990-10-06 1991-10-15 Mail sorting apparatus and method

Country Status (3)

Country Link
EP (1) EP0481569A3 (en)
JP (1) JPH04265183A (en)
CA (1) CA2053455A1 (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5292008A (en) * 1992-10-28 1994-03-08 Pitney Bowes Inc. Postal tray label apparatus and method
US5429249A (en) * 1993-11-15 1995-07-04 Pitney Bowes Inc. On-line sorting for an inserter system
US5419440A (en) * 1993-11-15 1995-05-30 Pitney Bowes Inc. Intelligent traying for inserter systems
JP3269234B2 (en) * 1993-12-28 2002-03-25 株式会社日立製作所 Delivery route sequencing apparatus of the paper sheet
EP0820357A1 (en) * 1995-04-13 1998-01-28 3M Australia Pty. Ltd. Sorting device and method
GB2370823B (en) * 2001-01-09 2004-09-22 Post Office An improved sorting system
US8977385B2 (en) 2004-11-22 2015-03-10 Bell And Howell, Llc System and method for tracking a mail item through a document processing system
US8129646B2 (en) 2004-11-22 2012-03-06 Bell And Howell, Llc System and method for validating mailings received
US7741575B2 (en) 2004-11-22 2010-06-22 Bowe Bell + Howell Company Mail piece consolidation and accountability using advanced tracking methods

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2302150B1 (en) * 1975-02-28 1982-05-21 Bertin & Cie
US4167476A (en) * 1977-05-06 1979-09-11 Harris Corporation Bulk article sorting system
FR2590505A1 (en) * 1985-11-28 1987-05-29 Sadas Sarl Method of sorting and grouping objects according to their destination and plant allowing the implementation of said METHOD

Also Published As

Publication number Publication date Type
EP0481569A2 (en) 1992-04-22 application
EP0481569A3 (en) 1993-04-21 application
JPH04265183A (en) 1992-09-21 application

Similar Documents

Publication Publication Date Title
US5917930A (en) Method for semi-continuous currency processing using separator cards
US5249687A (en) Barcode translation for deferred optical character recognition mail processing
US6303889B1 (en) Method and apparatus for sorting documents into a pre-defined sequence
US6829369B2 (en) Coding depth file and method of postal address processing using a coding depth file
US6598748B2 (en) Line of travel sequence transformation in mail processing applications
US6026385A (en) Encrypted postage indicia printing for mailer inserting systems
US20080027986A1 (en) Method and system for sorting mail
US6610955B2 (en) Method and apparatus for multi-task processing and sorting of mixed and non-machinable mailpieces and related methods
US5838574A (en) System for controlling feeders of a package assembly apparatus
US6801833B2 (en) Method for maintaining the integrity of a mailing using radio frequency identification tags
US5043908A (en) Mail delivery system with arrival monitoring
US20040215480A1 (en) Computer system for routing package deliveries
US20010034608A1 (en) Shipping method and system
US6009416A (en) System and method for detection of errors in accounting for postal charges in controlled acceptance environment
USRE38663E1 (en) Method for semi-continuous currency processing using separator cards
US6508365B1 (en) Method of removing mail from a mailstream using an incoming mail sorting apparatus
US20050119786A1 (en) System, method and computer program product for containerized shipping of mail pieces
US5898153A (en) Method for processing mail in a sweepstakes contest
US20040249771A1 (en) Method of providing a unique identifier for a mailpiece
US4949272A (en) Flexible billing rate for mail communication systems
US5005124A (en) Method and apparatus for categorizing and certifying mail
US6671577B2 (en) System and method for directly connecting an advanced facer canceler system to a delivery bar code sorter
US6219994B1 (en) Method and system for mail processing
US5475603A (en) Apparatus and method for mail qualification and traying
US4500083A (en) Collating and binding system and method with postage indication

Legal Events

Date Code Title Description
FZDE Dead