Note: Descriptions are shown in the official language in which they were submitted.
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
Descri tion
TECHNIQUE FOR SECURING A SYSTEM
CONFIGURATION OF A POSTAGE FRANKING SYSTEM
Technical Field
The invention relates to a secure system
configuration technique, and more particularly to a
technique for protecting the integrity of components in a
postage franking system.
Background of the Invention
It is commonplace to use postage meters or
franking systems for generating postage indicia on
mailpieces. The format of the postage indicia is
specified by a postal authority to facilitate its
inspection. In the United States, much attention has
been focused on an Information-Based Tndicia Program
(IBIP) by the United States Postal Service CUSPS),
proposing, among other things, new requirements for the
format of a postage indicium. Such new requirements were
promulgated, e.g., in the "Information Based Indicia
Program (IBIP) Open System Indicium Specification," dated
August 19, 1998. For instance, the IBIP requires
inclusion of a 2-dimensional (2-D) barcode in the postage
indicium. Such a barcode represents postal information
including postage, and a digital signature for
authenticating the postal information, in accordance with
a public key algorithm. One such public key algorithm
may be the Digital Signature Algorithm (DSA) described,
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-2-
e.g., in "Digital Signature Standard (DSS)," FIPS PUB
May 19, 1994.
In addition, under the IBIP, the requirements
of a postal security device (PSD) supporting the creation
of the postage indicium are specified, e.g., in the
"Information Based Indicia Program (IBIP) Open System
Postal Security Device (PSD) Specification," dated August
19, 1998. In accordance with the IBIP requirements, the
PSD provides the aforementioned digital signature in the
postage indicium, and dispenses and accounts for a postal
fund stored therein in a secure manner.
With the advent of sophisticated and widely
available general purpose computers, e.g., personal
computers (PCs), it has become possible to use one such
computer, by installing an appropriate postage generation
program therein, to print postage indicia on a printer.
Thus, a franking system may comprise a PC, and a PSD and
printer serving as peripherals thereto, in accordance
with an "open system" configuration. An advantage of
adopting the open system configuration is that other
mailing application software may also be installed by the
user in the same PC to effectively generate mailpieces
along with the postage indicia. For example, such
mailing application software may include a billing
program for charging postage back to different accounts,
an envelope program for printing an address and a postage
indicium on an envelope, an address cleansing program for
correcting mailing addresses, etc.
However, the user of a franking system based on
the open system configuration has full access to the
hardware and software components in the system. As a
result, these components including the aforementioned
postage generation program are subject to tampering, and
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-3-
fraudulent manipulation to generate unauthorized postage
indicia.
In accordance with the invention, an
authorization code is used to secure the configuration of
a franking system. The authorization code is derived in
part from system configuration information concerning,
e.g., the enabled and disabled feature options, current
version number of software, and the identity of a
computer in the franking system (e. g., the serial number
of the computer). Any unauthorized change in the system
configuration results in an invalidation of the
authorization code in the franking system, and denial of
the franking operation. Thus, any system
reconfiguration, e.g., a change in the feature options or
software upgrade, must be effected using a new valid
authorization code. Preferably, the authorization code
verification is performed each time before the franking
operation starts to forestall any fraudulent generation
of postage indicia.
In accordance with an aspect of the invention,
software code, e.g., the object code of a postage
generation program, in the franking system is subject to
error checking thereof. Thus, the above authorization
code is also derived from error checking information,
e.g., cyclic redundancy check (CRC) bits or checksum of
the software code. Any tampering of the software also
results in an invalidation of the authorization code.
In addition, to minimize the risk of fraudulent
generation of postage indicia, franking-related software
and hardware components by, e.g., third party vendors,
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-4-
need to go through a pre-approval process before they are
installed in the franking system to participate in the
. franking operation. For instance, in the pre-approval
process, the components need to pass standardized tests
to meet certain minimum requirements in, e.g., tamper
resistance. In accordance with yet another aspect of the
invention, a pre-approved software component is afforded
a registration identifier which is necessary for the
software component to participate in the franking
operation. For example, the registration identifier
needs to be produced for verification each time when the
software component interacts with the aforementioned
postage generation program. Similarly, a pre-approved
hardware component is afforded a registration identifier
which is necessary for its utility software to
participate in the franking operation.
It is an object of the invention to control the
configurations of the franking systems in the field. To
that end, a data center keeps records of the latest
configurations of the franking systems served by the data
center, including the identities of the franking-related
components in the respective systems. Such records can
be used to control the configuration of each franking
system. For example, with such records, the data center
can generate the aforementioned authorization code for
verification in each franking system to enforce its
configuration.
It is another object of the invention to
effectively conduct online transactions using postage
funds. To that end, the aforementioned data center also
keeps a customer account for replenishing a postage fund
in each franking system. For example, software or a
feature option for the franking system may be purchased
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-5-
through a~communication connection with the data center.
Such an online transaction involves the data center's
downloading the software to, or enabling the feature
option of, the franking system through the communication
connection, with the price of the software or feature
option debited from its customer account in the data
center.
Brief Description of the Drawincr
Further objects, features and advantages of the
invention will become apparent from the following
detailed description taken in conjunction with the
accompanying figures showing illustrative embodiments of
the invention, in which:
Fig. 1 illustrates a franking system which is
capable of communicating with a remote data center in
accordance with the invention;
Fig. 2 illustrates the format of each record in
a database in the remote data center;
Fig. 3 is a block diagram of a postal security
device used in the franking system;
Fig. 4 is a flow chart depicting the steps of a
postage generation program used in the franking system;
Fig. 5 illustrates a postage indicium generated
by the postage generation program;
Fig. 6 illustrates an authorization code which
needs to be verified in reconfiguring the franking
system;
Fig. 7 is a flow chart depicting the steps
taken by the franking system to verify the authorization
code;
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-6-
Figs. 8A and 8B jointly illustrate a process
whereby the franking system can be remotely reconfigured
through a communications connection;
Fig. 9 shows a variation of the design of the
authorization code;
Fig. 10 illustrates a memory map of storage of
feature option values;
Fig. 11 illustrates a process for generating
the authorization code of Fig. 9 in changing a feature
option in the franking system;
Fig. 12 illustrates a process for changing the
feature option in the franking system using the
authorization code of Fig. 9;
Fig. 13 illustrates a second process for
changing the feature option in the franking system using
the authorization code of Fig. 9;
Fig. 14 illustrates a memory map of storage of
software version numbers;
Fig. 15 illustrates a process for updating a
software version number in the franking system; and
Figs. 16A, 16B and 16C jointly illustrate a
process for printing addresses and a postage indicium on
an envelope using pre-approved components in the franking
system.
~7Ptailed Des~~~ tion
Fig. 1 illustrates franking system 100
embodying the principles of the invention for realizing
mailing applications and generating postage indicia on
mailpieces. In this particular illustrative embodiment,
system 100 is configured as an open system, where
computer 105 may be a conventional personal computer (PC)
CA 02334922 2000-12-13
WO 99/bb422 PCT/US99/13488
serving as a host device, and where PSD 110, printer 115
and modem 120 are peripherals to computer 105.
Alternatively, computer 105 may be a workstation or any
other general purpose computing machine. Computer 105
may cause modem 120 to establish a communication
connection through a communications network to, say,
remote data center 125. Although modem 120 in this
instance is shown as an external modem, it will be
appreciated that any internal modem within computer 105
may be used, instead.
Data center 125 includes processor 130 which,
among other things, maintains database 140 and
registration identifiers 145 stored in memory 135 to
serve different franking systems, e.g., franking system
100, communicates therewith to replenish their postage
funds, and provides authorization codes to control their
configurations in accordance with the invention.
Database 140 contains records concerning the
respective franking systems served by data center 125.
Fig. 2 illustrates the format of each record in database
140. In this instance, each franking system is
identified by a PSD serial number in field 161 pre-
assigned to its PSD. Field 163 contains account
information such as a prefunded or credit escrow account
balance for the franking system for conducting a
telemeter setting (TMS) transaction described below.
Field 165 includes configuration information (described
below) concerning the configuration of the franking
system to protect its integrity in accordance with the
invention.
Fig. 3 illustrates PSD 110 which in this
instance is realized as an integrated circuit (IC) module
peripheral to computer 105. PSD 110 comprises secure
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/134$8
_g_
memory 200, processing unit 210 including one or more
processors, and communications interface 220 (realizable
as PCMCIA, serial or parallel interface) fox interfacing
with and insertion into a corresponding mating port (not
shown) in computer 105.
Secure memory 200 is a nonvolatile memory which
includes, among others, ascending register 230 and
descending register 235. Ascending register 230 is used
to keep track of an amount of postage dispensed. On the
other hand, descending register 235 is used to keep track
of the postage fund amount available for postage
dispensation. When the value of descending register 235
decreases over time below a predetermined limit, computer
105 can no longer dispense postage until descending
register 235 is reset. Such a reset may be achieved by
way of electronic funds transfer, in accordance with a
well-known TMS technique, via a communication connection
(e.g., a dial-up connection or an Internet connection) to
data center 125 through modem 120.
Using the TMS technique in this instance, the
user need not carry PSD 110 to a postal authority for
authorized resetting of descending register 235. To
initiate a TMS process on computer 105, the user needs to
meet certain access requirements. For example, the user
may be required to enter a password, key, or biometric
input (e.g., fingerprint) on computer 105 using an
appropriate input device attached to computer 105.
Verification of such an access entry ensures that the
user is authorized to conduct such a process. After the
access entry is verified, computer 105 initiates a call
through modem 120 (alternatively via the Internet) to
data center 125, requesting additional postage funds.
Upon receipt of the call, processor 130 verifies in a
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
_g_
well known manner the current ascending and descending
register values and other PSD data in secure memory 200
of PSD 110, and ascertains the availability of funds in
the prefunded or credit escrow account of system 100.
After the PSD data is validated and the account balance
is found to be sufficient, processor 130 debits the
account and remotely resets descending register 235 in
PSD 110 accordingly.
System 100 in this instance may be used to
generate postage indicia in accordance with the United
States Postal Service CUSPS) Information Based Indicia
Program (IBIP) specification, namely, the "Information
Based Indicia Program (IBIP) Open System Indicium
Specification," dated August 19, 1998. To that end,
secure memory 200 also includes a well-known digital
signature algorithm (DSA) described, e.g., a.n "Digital
Signature Standard (DSS)," FIPS PUB 186, May 19, 1994;
and a private key and the corresponding public key in
accordance with the DSA. The public key may be made
available to the public in a PSD certificate in the
postage indicia. For instance, using the DSA, unit 210
may sign specified postal data with an associated private
key to generate a different digital signature to be
included in each postage indicium. The postal authority
then scans the postage indicium and verifies the digital
signature to authenticate the postage indicium, in
accordance with the DSA. It should be noted that instead
of the DSA of the DSS, another well-known data
authentication algorithm such as the RSA or Elliptic
Curve algorithm may be used.
For postage franking operation, computer 105 is
loaded with software components including postage
generation program 300 for generating postage indicia.
CA 02334922 2000-12-13
WO 99/b6422 PCT/US99/13488
-10-
Fig. 4 illustrates program 300 stored in a memory (not
shown) in computer 105. Instructed by program 300,
computer 105 prompts the user to enter mailing
information concerning the destination zip code, weight,
mail class (or rate category), any special services,
etc., of a mailpiece to be mailed, as indicated at step
305. Assuming in this instance that a rate module is
pre-installed in computer 105 which provides postage rate
information, computer 105 at step 310 calculates the
required postage based on the user entries and postage
rate information. Otherwise, the user would be prompted
to enter the required postage value for mailing the
mailpiece. At step 313, computer 105 sends the data
concerning the mail class and postage value to PSD 110.
Instructed by a subroutine of program 300, unit 210 in
PSD 110 deducts the required postage value from the
available postal fund in descending register 235, and
accordingly adds same to the dispensed fund in ascending
register 230 to account for the transaction, as indicated
at step 315. At step 317, unit 210 in accordance with
the DSA of the DSS signs postal data concerning the mail
class, postage value, ascending and descending register
values, and date of mailing, together with other data
pre-stored in memory 200 such as the software ID
identifying program 300, device ID identifying PSD 110,
and licensing zip code, resulting in a digital signature
for authenticating the postage indicium to be generated.
At step 320, computer 105 receives from PSD 110 the
digital signature, ascending and descending register
values, etc. At step 325, computer 105 prepares a print
image of a postage indicium representing the required
postal data and digital signature. Alternatively, unit
210 itself may create the print image of the postage
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-11-
indicium 'and pass it onto computer 105. Upon receiving a
print command, computer 105 transmits the print image to
printer 115, which then prints the postage indicium on a
label or an envelope fed to printer 115.
Fig. 5 illustrates one such postage indicium
500 which serves as proof of postage payment. Indicium
500 includes human readable portion 555 and machine
readable portion 560. Portion 555 may include, e.g., the
date of mailing, postage, device ID, originating town and
zip code, mail class, etc. Machine readable portion 560,
which is readable using an optical scanner, may include a
2-dimensional barcode representing data concerning the
device ID, ascending and descending register values,
postage value, digital signature, date of mailing,
licensing zip code, software ID, PSD certificate, mail
class, etc. Alternatively, machine readable portion 560
may comprise one or more data matrix symbols representing
similar data, as described in PCT International
Publication No. WO 99/16023, published on April 1, 1999.
Because of the open system configuration of
franking system 100, the user has full access to hardware
and software components in system 100. As a result,
these components, e.g., postage generation program 300
described above, are subject to tampering and
unauthorized use. In accordance with the invention,
verification of an authorization code is required from
time to time to prevent tampering and unauthorized use of
the components of system 100.
Fig. 6 illustrates one such authorization code
600 used to prevent any tampering and unauthorized use of
postage generation program 300 described above, and
feature options available in system 100 which may
include, e.g., a label printing option and other printer
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-12-
options, ~ barcode scanner option, etc. System 100 is
pre-loaded with software components necessary for
providing these options. A valid authorization code,
which is unique to system 100, needs to be entered onto
system 100 in order to install or upgrade the code of
program 300, and/or enable new feature options selected
by the user. In response to a user request for a system
reconfiguration involving the program code and/or feature
options, authorization code 600 is generated by processor
130 in data center 125 and then provided either to the
user via facsimile, email, telephone, etc., for the user
to enter onto system 100 using, e.g., a keyboard attached
to computer 105, or to system 100 directly via the
aforementioned communication connection between data
center 125 and system 100. As shown in Fig. 6,
authorization code 600 consists of m-bit electronic
signature 605 and n-bit encrypted option segment 610,
where m and n are predetermined integers. To generate
electronic signature 605, for example, a combination of
(a) the identity of computer 105, which in this instance
is the serial number of computer 105, (b) the hardware
configuration identifier of computer 105, e.g.,
indicative of the type of processor and RAM capacity in
computer 105, (c) the serial number of PSD 110, (d) the
software version number of program 300, (e) error
checking information, e.g., in this instance cyclic
redundancy check (CRC) bits, resulting from performing a
CRC on the code of program 300, and (f) an option number
whose bit pattern corresponds to a particular combination
of the enabled and disabled feature options for the
postage franking operation. Item (c) is provided in
field 161, and items (a), (b), and (d) through (f) are
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-13-
provided 'in field 165 of the record pertaining to system
100 in database 140.
It should be noted at this point that item (e)
in this instance is obtained by running a well known CRC
algorithm, e.g., Reed Solomon CRC algorithm, on the
object code of program 300 which is authorized in system
100. Alternatively, a checksum derived in a conventional
manner from the object code may be used.
The derivation by processor 130 of electronic
signature 605 involves encrypting the combination of
items (a) through (f) in accordance with a first well
known encryption algorithm. Signature 605 is then
derived from the encrypted version of the combination of
the items, e.g., by extracting therefrom a predetermined
sequence of m bits. Alternatively, signature 605 may be
generated using a well known symmetric or asymmetric key
cryptographic methodology.
On the other hand, encrypted option segment 610
is generated by encrypting only the option number (f) in
accordance with a second well known encryption algorithm.
Alternatively, segment 610 may be unencrypted, i.e.,
containing the plain text of option number (f).
It suffices to know for now that after system
100 enters a reconfiguration mode where authorization
code 600 is entered, code 600 is stored in authorization
code buffer 241. Encrypted option segment 610 of code
600 is subsequently decrypted to recover the underlying
option number. Using the recovered option number (f) and
additional items in system 100 which are identical to
aforementioned items (a) through (e), and the same first
encryption algorithm in the above-described manner,
system 100 is capable of independently generating an
electronic signature identical to electronic signature
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-14-
605 of code 600. In any event, the generated signature
is compared with electronic signature 605 in buffer 241.
If the two signatures match, the authorization code is
declared valid. Otherwise, if they do not match, the
franking operation by system 100 is suspended.
It should be noted at this point that the
authorization code verification requirement is desirable
in that it helps deter unauthorized copying of software
in system 100, e.g., program 300, onto other similar
systems. This stems from the fact that even though the
software can be copied onto the similar systems, the
latter would not be able to perform the franking
operation without proper authorization codes, which need
to be derived in part from their respective unique
computer and PSD serial numbers. In addition, because
authorization code 600 is partly derived from
aforementioned item (e), tampering of the software is
prevented as any such tampering results in a deviation
from the valid CRC bit values, causing invalidation of
the authorization code. Moreover, since system 100 would
only be able to perform franking operation with a proper
authorization code, which specifies a valid combination
of software and hardware components, and feature options
in system 100, the authorization code verification
requirement thus enables data center 125 to control the
configuration of each franking system served thereby.
As mentioned before, each bit of the option
number (f) corresponds to a feature option of franking
system 100. Each option, which is initially disabled,
may be selectively enabled by setting the appropriate
bits of the option number (f) to the opposite value.
Thus, for example, if a user wants to enable a previously
disabled label printing option, a proper authorization
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-15-
code need's to be entered on system 100 while in a
reconfiguration mode, causing the bit in the option
number (f) corresponding to the label printing option to
change to the opposite value to enable the option.
System 100 effects the feature options according to the
bit pattern of the option number stored in option number
buffer 243 in memory 200. In this particular
illustrative embodiment, the recovered option number from
decrypting segment 610 of authorization code 600
overwrites the current option number in buffer 243
irrespective of the outcome of the validation of
authorization number 600. That is, system 100
immediately effects the feature options according to the
recovered option number as soon as it is placed in buffer
243, irrespective of the outcome of the validation.
After the feature options are effected in the
prescribed manner in the reconfiguration mode, system 100
returns to a normal operation mode. When postage
generation program 300 is invoked to perform the franking
operation in the normal operation mode, unit 210 reads
from memory 200 (i) the serial number of computer 105,
(ii) the hardware configuration identifier of computer
105, (iii) the serial number of PSD 110, and (iv) the
software version number of program 300, which are
collected by unit 210 and stored in memory 200. Unit 210
also obtains (v) CRC bits based on running the
aforementioned CRC algorithm on the latest code of
program 300 in system 100, and (vi) the option number
from buffer 243. Unit 210 independently generates an
electronic signature using items (i) through (vi) and the
aforementioned first encryption algorithm in a similar
manner to processor 130 generating electronic signature
60S in data center 125. The electronic signature, thus
CA 02334922 2000-12-13
WO 99/66422 PCT/US99113488
-16-
generated', is compared with the electronic signature
stored in buffer 241, i.e., the first m bits of
authorization code 600 therein. If there is no mismatch,
generation of postage indicia using program 300 is
allowed. Otherwise if there is any mismatch, a message
such as "Invalid Authorization Code" is displayed on
computer 105, and generation of postage indicia is
halted.
Where authorization code 600 is entered by user
onto system 100, in view of the possibility that the user
makes an erroneous authorization code entry, the user is
afforded a limited number of times to re-enter the
correct authorization code after the message is
displayed. After the limited number of times is
exhausted, proper resetting of system 100 by authorized
personnel is needed to re-enable the system to perform
the franking operation.
For installing or upgrading a software
component, e.g., the code of postage generation program
300, the user may be provided with a compact disk (CD),
or another conventional storage medium, e.g., a floppy
disk, IC module, digital video disk (DVD), etc.,
containing the necessary software, and authorization code
600 on the storage medium package which is generated in
data center 125 for verification after the software
installation or upgrade. The new software version number
of program 300 may be embedded in the header of the
program. When the software installation or upgrade is
performed, the new software version number is read by
computer 105 and transferred to memory 200 where the new
software version number replaces the current software
version number (iv).
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-17-
'After the software installation or upgrade in
the reconfiguration mode, system 100 returns to the
normal operation mode. When postage generation program
300 is invoked to perform the franking operation in the
normal operation mode, the user is prompted for
authorization code 600 on the storage medium package.
Authorization code 600 is then verified according to the
steps similar to those in the above-described
verification after effecting new feature options.
Specifically, unit 210 stores in buffer 241 authorization
code 600 entered by the user, as indicated at step 701 in
Fig. 7. At step 702, unit 210 causes the decryption of
encrypted option segment 610 of authorization code 600 in
buffer 241, thereby recovering the underlying option
number (vi). Such decryption is accomplished using a
decryption algorithm inverse to the second encryption
algorithm. At step 703, processor 201 stores the
recovered option number in buffer 243, although in this
instance the recovered option number is identical to
current option number in buffer 243. At step 704, unit
210 runs the CRC algorithm on the latest code of postage
generation program 300, thereby obtaining item (v). At
step 705, unit 210 reads the above items (i) through (iv)
from memory 200, where item (iv) has the latest software
version number of program 300. At step 706, unit 210
independently generates an electronic signature using
items (i) through (vi), and the first encryption
algorithm in a similar manner to processor 130 generating
electronic signature 605 in data center 125. Unit 210 at
step 707 compares the generated electronic signature with
electronic signature 605 of authorization code 600 in
buffer 241. The authorization code is validated if unit
210 finds that the two electronic signatures match.
CA 02334922 2000-12-13
WO 99/66422 PCT/US99113488
-18-
Otherwise,' a message such as "Invalid Authorization Code"
is displayed on computer 105, and generation of postage
indicia is halted.
It should be noted that the above authorization
code verification is performed not only after system 100
is reconfigured, but preferably each time, or from time
to time, when postage generation program 300 is invoked
in the normal operation mode. Thus, preferably each
time, or from time to time, before the franking operation
is initiated, processor 201 performs above steps 702
through 707 for fear that the components of franking
system 100 are tampered in the meantime.
It should also be noted that the above
authorization code verification may also be performed via
direct communications between data center 125 and
franking system 100, thereby obviating the need of having
the user enter the authorization code. Figs. SA and 8B
jointly illustrate remote reconfiguration process 800
whereby a user can purchase a new feature option or
software online, and whereby authorization code 600 is
verified via direct communications between data center
125 and system 100. Process 800 may be invoked by the
user's entering a specified command on computer 105.
Similar to the above-described TMS process for requesting
additional postage, process 800 starts with prompting the
user for an access entry (e.g., a password, key or
biometric input) on computer 105, as indicated at step
806 in Fig. 8A. Verification of such an access entry
ensures that the user is authorized to conduct the remote
reconfiguration process. After the access entry is
verified at step 809, computer 105 at step 812
establishes a communication connection with data center
125 via modem 120. Through the established connection,
CA 02334922 2000-12-13
WO 99!66422 PCTNS99/13488
-19-
processor'130 in data center 125 performs initial
handshaking with franking system 100 according to a pre-
agreed upon communication protocol, thereby identifying
at step 815 franking system 100, e.g., by its PSD serial
number. Based on the PSD serial number, processor 130 at
step 818 locates in database 140 the record pertaining to
franking system 100.
At step 821, processor 130 reviews fields 163
and 165 of the located record for the current escrow
account balance and configuration information of system
100, respectively. Based on the current configuration of
system 100, processor 130 at step 824 causes computer 105
to display a menu thereon containing selections of any
new software available for downloading, and currently
disabled options for activation. The menu also indicates
the current escrow account or credit balance, the prices
for downloading any new software having a new version
number, and for activating one or more of the disabled
options. Assuming that in this example the user wants to
activate a previously disabled option, say, option A in
the menu, the user may use a mouse device (not shown)
attached to computer 105 to select option A.
At step 827, computer 105 communicates the
user's selection of option A to processor 130. Upon
receiving the option selection, processor 130 at step 83o
debits the price of option A from the current escrow
account balance, resulting in a new balance in field 163.
Accordingly, processor 130 at step 833 changes the value
of the bit in the option number (f) in field 165
corresponding to option A, reflecting an activation of
option A. At step 836, processor 130 generates
authorization code 600 consisting of electronic signature
605 and encrypted option segment 610. As mentioned
CA 02334922 2000-12-13
W O 99/66422 PCT/C1S99/13488
-20-
before, electronic signature 605 is derived from an
encrypted version of items (a) through (f) in field 165
of the record pertaining to system 100. Encrypted option
segment 610 is obtained by encrypting the option number
(f) alone. Authorization code 600 is then transmitted
from data center 125 to system 100 through the
established communication connection, as indicated at
step 839. The communication connection is thereafter
terminated.
The remaining steps in process 800 are similar
to those in routine 700 described before. Specifically,
similar to step 701, step 841 in Fig. 8B involves storing
received authorization code in buffer 241. Similar to
step 702, step 843 involves decryption of encrypted
option segment 610 of authorization code 600 to recover
the underlying option number (vi), which in this instance
indicates the activation status of option A. Similar to
step 703, step 845 involves storing the recovered option
number in buffer 243, thereby activating option A.
Similar to step 704, step 847 involves running the CRC
algorithm on the latest code of postage generation
program 300, thereby obtaining item (v). Similar to step
705, step 849 involves reading items (i) through (iv)
from memory 200. Similar to step 706, step 851 involves
independently generating an electronic signature using
items (i) through (vi), and the first encryption
algorithm. Similar to step 707, step 853 involves
comparing the generated electronic signature with
electronic signature 605 of authorization code 600 in
buffer 241. Again, the authorization code is validated
if unit 210 finds that the two electronic signatures
match. Otherwise,.an "Invalid Authorization Code"
message would be displayed on computer 105, and
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-21-
generation of postage indicia would be halted as
described before.
Based on the disclosure heretofore, it is
apparent to a person skilled in the art that where the
user chooses to purchase new software online, instead,
the steps in process 800 similarly follow, except that in
that case, at step 839 the new software, including the
new software version number therein, would be downloaded
from data center 125 to system 100, along with the
transmission of authorization code 600 thereto.
Variations of the design of the authorization
code which call for different verification techniques
will now be described. In accordance with a first design
variation, the authorization code is generated by
encrypting items (a) through (f) using a standard
encryption algorithm in data center 125. After such an
authorization code is provided to system 100, the latter
decrypts the received authorization code using a
decryption algorithm inverse to the standard encryption
algorithm, thereby recovering the underlying items (a)
through (f). Items (i) through (v) are then obtain in
system 100 in the manner described before, and compares
them with the corresponding, recovered items (a) through
(e). The authorization code is validated if the two sets
of items match.
If the authorization code of the first design
variation is not validated because of certain mismatched
items, it may be desirable to show on computer 125 such
mismatched items for diagnostic purposes. For example,
if it is shown that item (d) does not match item (iv), a
wrong software version of program 300 may have been
installed in system 100. It may be a manufacturing
CA 02334922 2000-12-13
WO 99/66422 PCT/U599/13488
-22-
defect if~the authorization code invalidation occurs
during the very first time of the franking operation.
Fig. 9 illustrates a second variation of the
authorization code design. In accordance with this
variation, authorization code 900 includes m-bit
electronic signature 905 which is generated in the same
manner as electronic signature 605. Authorization code
900 also includes encrypted reconfiguration segment 910
having a variable length. The formation of segment 910
is fully described below. It suffices to know for now
that the length of segment 910 depends on the actual
reconfiguration which needs to be realized.
In a first example where authorization code 900
may be used, a user requests an activation of a currently
disabled feature option, say, option C. In accordance
with an aspect of the invention, for each feature option,
a pair of memory locations are allocated in memory 200 of
PSD 110 to pre-store "1" and "0" bit values representing,
e.g., an "enabled" status and a "disabled" status of the
option, respectively. The resulting memory map is
illustrated in Fig. 10. As shown in Fig. 10, a first
pair of memory addresses lA2B (hexadecimal) and lA2C in
memory 200 correspond to feature option A, where "0" is
pre-stored at memory address lA2B and "1" is pre-stored
at memory address lA2C; a second pair of memory addresses
lA2D and 1A2E in memory 200 correspond to feature option
B, where "0" is pre-stored at memory address 1A2D and "1"
is pre-stored at memory address lA2E; a third pair of
memory addresses lA2F and 1A30 in memory 200 correspond
to feature option C, where "0" is pre-stored at memory
address 1A2F and "1" is pre-stored at memory address
1A30; and so on and so forth. This memory map is made
known to data center 125 beforehand and registered in
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-23-
field 165~of the record pertaining to system 100 in
database 140.
Continuing the above example, assuming that the
request for activating feature option C is granted,
processor 130 in data center 125 changes the value of the
bit in option number (f) corresponding to option C from
the previous value "0" to the new value "1" to activate
the option, as indicated at step 1103 in Fig. 11.
Processor 130 at step 1106 generates electronic signature
905 based on items (a) through (f) in the manner
described before, where option number (f) incorporates
the new bit value "1" corresponding to option C.
Processor 130 then generates encrypted
reconfiguration segment 910. Specifically, at step 1109
processor 130 looks up from the aforementioned registered
memory map the memory address corresponding to option C
at which the new bit value "1" is pre-stored in memory
200. In this instance, the memory address in question is
1A30. At step 1112, processor 130 encrypts the memory
address using the aforementioned second encryption
algorithm, resulting in segment 910. Authorization code
900 consisting of electronic signature 905 and encrypted
reconfiguration segment 910 is fed to system 100 in a
reconfiguration mode either by direct communications or a
user entry.
After receiving authorization code 900, unit
210 at step 1203 in Fig. 12 decrypts segment 910 of
authorization code 900 using the decryption algorithm
inverse to the second encryption algorithm, thereby
recovering the memory address 1A30. It should be noted
that segment 910 starts from the (m+1)th bit of received
authorization code 900. Unit 210 at step 1206 retrieves
from memory 200 the bit value "1" corresponding to option
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-24-
C at memory address 1A30. Unit 210 at step 1209
overwrites the current bit value "0" corresponding to
option C in option number buffer 243 with the retrieved
bit value "1," thereby activating option C. Unit 210 at
step 1212 gathers items (i) through (v) in the manner
described before, and reads from option number buffer 243
the modified option number (vi). Unit 210 at step 1215
independently generates an electronic signature based on
items (i) through (vi) in the manner described before.
Unit 210 compares the resulting electronic signature with
received electronic signature 905 of received
authorization code 900, as indicated at step 1217. If
they match, the authorization code is validated.
Otherwise, an "Invalid Authorization Code" message would
be displayed on computer 105, and generation of postage
indicia would be halted as described before.
Although the above processes involve only one
feature option, i.e., option C, the processes similarly
follow where two or more options need to changed at the
same time. In that case, the memory addresses associated
with the multiple options are concatenated and then
encrypted using the second encryption algorithm, thereby
generating encrypted reconfiguration segment 910.
Accordingly, the length of segment 910 increases with the
number of feature options to be changed.
To keep segment 910 relatively short especially
when multiple options need to be changed, in an
alternative embodiment, segment 910 comprises an
encrypted version of offset memory addresses, rather than
full memory addresses, associated with the options.
Referring briefly to Fig. 10, since the full memory
address associated with each feature option
illustratively starts with "lA," unit 210 can be
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-25-
programmed to assume that the first two nibbles of the
option memory addresses are always "1A". Thus, when
option A needs to be changed, only the offset address
"2B" or "2C" needs to be communicated using segment 910
for enabling or disabling the option; when option B needs
to be changed, only the offset address "2D" or "2E" needs
to be communicated using segment 910 for enabling or
disabling the option; when option C needs to be changed,
only the offset address "2F" or "30" needs to be
communicated using segment 910 for enabling or disabling
the option; and so on and so forth.
In a second example where authorization code
900 may be used, to save memory space in memory 200, the
storage of "1" and "0" values for each option as set
forth in the memory map of Fig. 10 may be totally
avoided. Since a change in each option involves changing
the corresponding bit value in option number buffer 243
to the opposite value, the encrypted reconfiguration
segment 910 only needs to communicate the identities of
the feature options which need to be changed. After
learning the identities of such options based on segment
910, unit 210 locate the bits in buffer 243 corresponding
to the identified options and change their current bit
values to the opposite values, respectively.
Thus, in this second example, segment 910 is
formed by encrypting codes identifying the respective
options to be changed. Various designs of the codes are
possible as long as each code uniquely identifies a
respective option. Fox example, for the sake of
convenience, the code identifying an option may represent
the bit position corresponding to the option in buffer
243. Thus, the code for option A may be "O1"
representing the first bit position of buffer 243
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-26-
corresponding to option A; the code for option B may be
"02" representing the second bit position of buffer 243
corresponding to option B; the code for option C may be
"03" representing the third bit position of buffer 243
corresponding to option C; and so on and so forth.
Continuing the second example, let's say that
feature options A and C need to be changed in this
instance. Thus, system 100 is fed with authorization
code 900 wherein electronic signature 905 is generated by
processor 130 in data center 125 in the manner described
before, and encrypted reconfiguration segment 910
contains an encrypted version of the option codes "0103"
in concatenation, where the option code "O1" identifies
option A and option code "03" identifies option C.
As indicated at step 1303 in Fig. 13, unit 210
first decrypts encrypted reconfiguration segment 910 of
received authorization code 900, thereby recovering the
option codes "0103". Based on a first option code "Ol"
representing the first bit position in buffer 243
corresponding to option A, which needs to be changed,
unit 210 at step 1306 changes the current value of the
first bit in buffer 243 to the opposite value. In
addition, based on a second option code "03" which
immediately follows "O1" and which represents the third
bit position in buffer 243 corresponding to option C,
which needs to be changed, unit 210 at step 1309 changes
the current value of the third bit in buffer 243 to the
opposite value. Unit 210 at step 1312, similar to above-
described step 1212, gathers items (i) through (v), and
reads from option number buffer 243 the modified option
number (vi). Unit 210 at step 1315, similar to above-
described step 1215, independently generates an
electronic signature based on items (i) through (vi).
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-27-
Unit 210 Compares the resulting electronic signature with
electronic signature 905 of received authorization code
900, as indicated at step 1317 similar to above-described
step 1217. If they match, the authorization code is
validated. Otherwise, an "Invalid Authorization Code"
message would be displayed on computer 105, and
generation of postage indicia would be halted as
described before.
We have recognized that for loading new
software on system 100 for a program upgrade or
installation without changing feature options,
authorization code 900 may consist of electronic
signature 905 only, i.e., encrypted reconfiguration
segment having a zero length. In this illustrative
embodiment, an array of memory addresses in memory 200
are allocated to pre-store a quantity of possible version
numbers of software, e.g., postage franking program 300.
As shown in Fig. 14, for example, version number "1" is
pre-stored at memory address 1B12; version number "2" is
pre-stored at memory address 1B13; version number "3 is
pre-stored at memory address 1814; and so on and so
forth. A version number pointer (not shown) in memory
200 is used to indicate the memory location of the
current software version number. Assuming that the
current software version number is "2", the pointer has a
value of "1813".
The new software to be loaded onto system 100
contains a header which in this instance includes the
memory address at which the new software version number
is pre-stored. Let's say the new version number is "3"
and the header thus contains the memory address "1B14".
In granting the loading of new software onto
system 100, processor 130 in data center 125 generates
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-28-
authorization code 900 consisting of only electronic
signature 905 based on items (a) through (f) in the
manner described before, where item (d) has the new
software version number. Electronic signature 905 is
provided to system 100 for later verification.
While the new software is being loaded onto
system 100 via an online connection or a storage medium,
unit 210 in PSD 110 at step 1503 in Fig. 15 changes the
aforementioned version number pointer value to the memory
address provided in the header of the new software, i.e.,
"1814". As a result, the pointer indicates a new memory
location containing the software version number "3".
Unit 210 at step 1506 gathers items (i) through (iii),
(v) and (vi), and reads from memory address 1814
indicated by the pointer the new software version number
"3" as item (iv). Unit 210 at step 1509, similar to
above-described step 1215, independently generates an
electronic signature based on items (i) through (vi).
Unit 210 compares the resulting electronic signature with
received electronic signature 905, as indicated at step
1511 similar to above-described step 1217. If they
match, the authorization code is validated. Otherwise,
an "Invalid Authorization Code" message would be
displayed on computer 105, and generation of postage
indicia would be halted as described before.
It should be noted at this point that the
memory address communicated in the header of the new
software may be an offset address, as well, e.g., "12",
"13", "14" . . ., rather than its full address, e.g.,
"1812", "1813", "1814" . . . as it is understood that the
two most significant nibbles of the full address are
always "1B".
CA 02334922 2000-12-13
WO 99/66422 PGT/US99/13488
-29-
In addition, to save memory space in memory
200, the storage of possible software version numbers as
_ set forth in the memory map of Fig. 14 may be totally
avoided, especially where the software version number
always increments by one when new software is loaded onta
system 100. In that case, a counter (not shown) in PSD
110 may be used to keep track of the current software
version number. Unit 210 may be programmed to be
responsive to loading of new software onto system 100 to
cause the counter to increment by one, thereby updating
the software version number (iv). After loading of the
new software, unit 210 independently generates an
electronic signature based on items (i) through (vi).
The generated electronic signature is compared with
electronic signature 905 generated by data center 125 in
part based on the new software version number in (d). If
they match, the loading of new software onto system 100
is authorized.
Because system 100 is configured as an open
system, a user may freely load additional software onto
computer 105, and add to system 100 hardware components,
e.g., peripherals to computer 105. An advantage of
adopting the open system configuration is that
application software, other than postage generation
program 300 described above, may be installed by the user
on his/her own in computer 105 to interact with, say,
program 300, to realize a more comprehensive mailing
process. Such other application software may include,
e.g., a billing program for charging postage back to
different accounts, an envelope program for printing an
address and a postage indicium on an envelope, an address
cleansing program for correcting mailing addresses, etc.
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-30-
'On the other hand, because system 100 is
configured as an open system, the integrity of the
franking operation thereby may be jeopardized. For
example, the user may load illegitimate software on
computer 105 to interact with postage generation program
300 to fraudulently print postage indicia. The user may
also employ a printer of interior quality to print
substandard postage indicia, which are unreadable by an
optical scanner.
Thus, in accordance with an aspect of the
invention, the franking-related hardware and software
components in system 100 need to be pre-approved. To
that end, the components by different vendors need to
pass standardized tests to meet certain minimum
requirements in, e.g., compatibility with a postage
generation program in the franking system, print quality,
tamper resistance, efficiency, durability, etc., to
' become approved. The pre-approved components may then be
marketed to users for installation in their franking
systems, e.g., system 100. The manner in which the pre-
approval requirement of the software and hardware
components is enforced when they interact with the
postage generation program is fully described below. Tt
suffices to know for now that each pre-approved software
component includes a valid registration identifier which
is necessary for the software component to interact with
the postage generation program. Similarly, for each pre-
approved hardware component (e.g., a printer), its
utility software (e. g., printer driver software)
interfacing the hardware component with the postage
generation program also includes a valid registration
identifier, which is necessary for it to interact with
the postage generation program.
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-31-
'In accordance with another aspect of the
invention, a registration identifier is used to (1)
identify a franking-related hardware or software
component in a franking system configuration, (2) enforce
the pre-approval requirement of such a hardware or
software component. To achieve object (1), each pre-
approved software component, and hardware component
including its utility software is assigned a different
registration identifier. A duplicate copy of the
registration identifier is registered in memory 135 of
data center 125. Thus, data center 125 includes in
memory 135 a collection of registration identifiers 145
which identify and are associated with different pre-
approved components. The registration identifier
collection is updated from time to time as additional
software and hardware component pass the standardized
tests and become approved.
When each pre-approved component interacts with
the postage generation program, the registration
identifier in the component is compared with the
registered registration identifier. If the two
identifiers match or correspond, the component is
verified to be pre-approved, thereby achieving object
(2) .
A pre-approved envelope program having a
registration identifier for verification of its pre-
approval status will now be described. This envelope
program may be purchased from a third-party vendor and
installed by the user in computer 105. Because of its
pre-approval status, the envelope program includes
therein a registration identifier which identifies the
program. Figs. 16A, 16B and 16C jointly illustrate the
envelope program and interactions with postage generation
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-32-
program 300 to print addresses and a postage indicium on
an envelope. Instructed by such an envelope program,
computer 105 elicits from the user the size of the
envelope to be used for a mailpiece, as indicated at step
1603 in Fig. 16A. Computer 105 at step 1606 displays an
image of the envelope having the specified size on its
screen. Computer 105 at step 1609 prompts the user to
type originating mailing address and destination mailing
address at desired locations an the displayed envelope.
Computer 105 at step 1612 prompts the user to indicate
the desired location on the displayed envelope where a
postage indicium is to be printed. Accordingly, the user
utilizes a mouse device to indicate the desired location
which, in this instance, is the upper right corner of the
envelope according to the postal authority regulations.
Computer 105 thereafter provides at step 1615 a
draft option which enables the user to preview the
envelope including a specimen indicium appearing at the
user defined location before the envelope is printed.
Thus, this option allows the user to check the format of
the envelope and the relative placement of the address
blocks, and postage indicium on the envelope before the
user is committed thereto.
After the user decides to proceed with the
printing of the envelope at step 1617, computer 105 at
step 1618 generates a first ensemble of control
characters indicating the position of the originating
mailing address, a second ensemble of control characters
indicating the position of the destination mailing
address, and a third ensemble of control characters
indicating the position of the postage indicium on the
envelope. At step 1621, computer 105 inserts the first,
second and third ensembles of control characters into the
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-33-
data stream representative of the texts of the
originating and destination mailing addresses, where the
originating mailing address data is preceded by the first
ensemble of control characters, and the destination
mailing address data is preceded by the second ensemble
of control characters. The resulting data stream is
formatted pursuant to the protocol required by printer
115. For example, if printer 115 is a printer
manufactured by Hewlett-Packard Co., the data stream
would be in accordance with the Hewlett-Packard printer
control language (HP-PCL).
The envelope program proceeds from step 1621 to
step 1623 in Fig. 16B where postage generation program
300 described before is invoked. Upon such an
invocation, unit 210 in PSD 110 is interrupted, and
requests computer 105 to pass thereto a copy of the
registration identifier in the envelope program for
examination, as indicated at step 1624. If computer 105
fails to produce a copy of the registration identifier,
unit 210 causes computer 105 to display thereon an
"Unauthorized Component" message, and prevents generation
of any postage indicium, as indicated at step 1625.
Otherwise, if computer 105 produces a copy of
the registration identifier of the envelope program, unit
210 at step 1626 compares the registration identifier
from computer 105 with each of registration identifiers
245 in PSD 110, which are associated with the pre-
approved components which have been verified at least
once. At step 1627, unit 210 determines whether a
corresponding registration identifier is found amongst
registration identifiers 245. Assuming that this is not
the first time that the envelope program invokes program
300, and the registration identifier of the envelope
CA 02334922 2000-12-13
WO 99/bb422 PCT/US99/13488
-34-
program has been verified at least once, unit 210 in this
instance finds the corresponding registration identifier
amongst registration identifiers 245, and proceeds to
step 1642 in Fig. 16C described below.
Otherwise, if the registration identifier of
the envelope program has never been verified, unit 210
fails to find a corresponding registration identifier
amongst registration identifiers 245. Unit 210 then
causes modem 120 to establish at step 1628 a
communication connection with data center 125. Unit 210
transmits at step 1629 the serial number of PSD 110 and
copy of the registration identifier of the envelope
program to data center 125 where processor 130 at step
1630 compares the received registration identifier with
each of registration identifiers 145 in data center 125,
which as mentioned before consist of the registration
identifiers of all pre-approved components ever.
Processor 130 at step 1631 determines whether a
corresponding registration identifier is found amongst
registration identifiers 145.
Since in this instance, the envelope program is
pre-approved, processor 130 locates a corresponding
registration identifier amongst registration identifiers
145. Processor 130 recognizes that the envelope program
identified by the corresponding registration identifier
is being run on system 100, which is identified by the
received serial number of PSD 110. Accordingly,
processor 130 at step 1633 updates the record of system
100 in database 140 to also include in field 165 thereof
an indication that the envelope program is now part of
the configuration of system 100. Processor 130 then at
step 1636 returns the copy of the registration identifier
of the envelope program to unit 210, with an
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-35-
acknowledgment that such a registration identifier is
valid, and then terminates the communication connection.
In response, unit 210 at step 1639 in Fig. 16C adds the
returned registration identifier to registration
identifiers 245 in PSD 110 for subsequent verification,
obviating the need to have processor 130 involved in the
subsequent verification of such a registration
identifier. Unit 210 then goes on to help generate a
postage indicium, as indicated at step 1642.
Otherwise, if processor 130 at step 1631 fails
to locate a corresponding registration identifier amongst
registration identifiers 145, processor 130 at step 1645
in Fig. 16B returns only a negative acknowledgement that
the received registration identifier is invalid, and
terminates the communication connection. In response to
the negative acknowledgement, unit 210 returns to step
1625.
After step 1642 in Fig. 16C and execution of
program 300, a print image of an appropriate postage
indicium is prepared. At step 1648 a printer driver
program associated with printer 115 is invoked to print
the originating and destination addresses, and postage
indicium on an envelope fed to printer 115. As the
printer driver program interacts with program 300 to
receive the print image of the postage indicium resulting
from program 300, printer 115 including the printer
driver program needs to be pre-approved. As such, upon
the invocation of the printer driver program, unit 210 in
PSD 110 is interrupted, and requests computer 105 to pass
thereto a copy of the registration identifier in the
printer driver program for examination, as indicated at
step 1651. If computer 105 fails to produce a copy of
such a registration identifier, unit 210 denies the
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/13488
-36-
printer driver program of the print image of the postage
indicium, as indicated at step 1654.
Otherwise, if computer 105 produces a copy of
the registration identifier, unit 210 at step 1657
compares the registration identifier from computer 105
with each of registration identifiers 245 in PSD 110
which, as mentioned before, are associated with the pre-
approved components which have been verified at least
once. Assuming that this is not the first time that the
printer driver program is invoked to print a postage
indicium, and the registration identifier of the printer
driver program has been verified at least once, unit 210
in this instance locates at step 1660 the corresponding
registration identifier amongst registration identifiers
245. The printer driver program is provided with the
print image of the postage indicium, as indicated at step
1663. At step 1667, printer 115 prints on the provided
envelope the originating and destination addresses and
the postage indicium at the user defined positions, based
on the aforementioned data stream from computer 105 and
the print image of the postage indicium.
Otherwise, if at step 1660 unit 210 fails to
locate the corresponding registration identifier,
processor 130 would be involved in verifying the
registration identifier with the steps similar to steps
1628 through 1631, and 1633, 1636, 1639 and 1645
described before, which are not repeated here.
It is apparent from the disclosure heretofore
that database 140 in data center 125 has records of
configurations of all of the franking systems served by
center 125. In particular, field 165 of each record
pertaining to a respective franking system includes
configuration information concerning, among others, the
CA 02334922 2000-12-13
WO 99/66422 PCT/US99/1348$
-37-
hardware cbnfiguration of the computer (i.e., item (b)),
the enabled or disabled options (i.e., item (f)), the
version of the postage generation program (i.e., item
(d)), and other hardware and software components
interacting with the postage generation program in the
franking system. Such information in database 140 can be
used by a postal authority to effectively monitor and
control the configurations of individual franking systems
in the field.
The foregoing merely illustrates the principles
of the invention. It will thus be appreciated that those
skilled in the art will be able to devise numerous other
arrangements which embody the principles of the invention
and are thus within its spirit and scope.
For example, to further deter unauthorized
reconfiguration of system 100, the encryption algorithms
for generating authorization codes may be changed from
time to time. The new algorithms may easily be
downloaded from data center 125 during a software upgrade
in computer 105, or during a TMS transaction with data
center 125. The memory locations in the memory maps of
Figs. 10 and 14 may be changed from time to time, as
well.
In addition, in the illustrative embodiment,
the memory of computer 105 is distinguished from memory
200 in PSD 110. However, the memory spaces in the two
memories may be interchangeable in that some or all of
the memory contents in memory 200 may be stored in the
memory of computer 105, and vice versa. Similarly, some
or all of the tasks performed by processing unit 210 in
PSD 110 in the illustrative embodiment may be performed
by computer 105, and vice versa.
CA 02334922 2000-12-13
WO 99/66422 PCT/US991134$8
-38-
Finally, the illustrative embodiment of the
invention is disclosed herein in a form in which various
franking and communications functions are performed by
discrete functional blocks. These functional blocks may
be implemented in various ways and combinations using
logic circuitry and/or appropriately programmed
processors, as will be known to those skilled in the art.
