Language selection

Search

Patent 2053455 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2053455
(54) English Title: MAIL SORTING APPARATUS AND METHOD
(54) French Title: MACHINE ET METHODE DE TRI DU COURRIER
Status: Dead
Bibliographic Data
(51) International Patent Classification (IPC):
  • B07C 99/00 (2009.01)
  • B07C 3/00 (2006.01)
(72) Inventors :
  • KOSTYNIUK, PAUL F. (United States of America)
  • KOSTYNIUK, PAUL F. (United States of America)
(73) Owners :
  • KOSTYNIUK, PAUL F. (Not Available)
  • KOSTYNIUK, PAUL F. (United States of America)
  • BELL & HOWELL PHILLIPSBURG COMPANY (United States of America)
(71) Applicants :
(74) Agent: KIRBY EADES GALE BAKER
(74) Associate agent:
(45) Issued:
(22) Filed Date: 1991-10-15
(41) Open to Public Inspection: 1992-04-17
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
598,189 United States of America 1990-10-16

Abstracts

English 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.


Claims

Note: Claims are shown in the official language in which they were submitted.



82
The embodiments of the invention in which an exclusive
property or privilege is claimed are defined as follows:

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.


83
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;


84
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.


Description

Note: Descriptions are shown in the official language in which they were submitted.


20~34~a




MAIL SORTING APPARATU8 AND NETHOD

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.

2053455

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
12
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~
14
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
203460000 2 1 3 12 3 7
203500000 1 1 3 1 0 3
203500000 3 1 3 0 0
203500000 2 3 3 1 0 0
203500000 0 7 3 0 2 0
302530000 2 1 4 O 0 5
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
16
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
17
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
18
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~
19
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
21
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~
23
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~
24
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~
26
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
28
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
29
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~
32
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
33
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~
34
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~
37
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

38 2053455
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~
43
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
44
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~
46
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~
47
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
48
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~
51
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~
52
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~
53
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~
54

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
56
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
57
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~
61
~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~
62
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~

63

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~
64
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~
66
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
67
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~
68
together for insertion into the bag. For example, the first
bag tag generated for Group 1 reads:
PROVIDENCE RI 028
3 C LTRS MXD 5--DG PKG
EVANSTON IL 602
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~
69
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:
---- 2053455
FIRST P~SS RESULTS

For futther sottins...
Mark the 3ail as follo~ls:
BINGROIJP # ~IN GROUP
3 1 56 4
4 1 ~i7 46
J 1 . 58 l~7
6 1 ~9 47
7 1 6~ 49
a 2 61 49
62 49


6 9 6
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~
3B 31 91 69
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
1--
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
2053455
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
3C LTRS 3C LTRS 3C LTRS 3C LTRS
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

2053455


~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~

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date Unavailable
(22) Filed 1991-10-15
(41) Open to Public Inspection 1992-04-17
Dead Application 1994-04-17

Abandonment History

There is no abandonment history.

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Application Fee $0.00 1991-10-15
Registration of a document - section 124 $0.00 1993-06-25
Registration of a document - section 124 $100.00 2011-07-08
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
KOSTYNIUK, PAUL F.
KOSTYNIUK, PAUL F.
BELL & HOWELL PHILLIPSBURG COMPANY
Past Owners on Record
None
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Drawings 1992-04-17 21 527
Claims 1992-04-17 3 130
Abstract 1992-04-17 1 47
Cover Page 1992-04-17 1 18
Representative Drawing 1999-04-22 1 27
Description 1992-04-17 82 3,851
Assignment 2011-07-08 7 315