Specialized function performed

Postage metering system

6424954

Abstract

A postage metering system that includes a host PC, an SMD, and a printer. The host PC includes a user interface to receive postage information. The SMD operatively couples to the computer via a communications link and includes a processor and a tamper evident enclosure. The processor is configured to receive the postage information from the computer, direct generation of an indicium, and account for the indicium. The tamper evident enclosure houses the processor and other security sensitive elements of the SMD. The printer couples to the SMD and is configured to receive and print the indicium. The SMD can further include a memory element, an interface circuit, and an enclosure. The memory element is configured to store accounting information and information related to the operation of the metering device. The interface circuit is configured to receive a message that includes a code that identifies that message. The processor operatively couples to the memory element and the interface circuit. The processor is configured to receive the message, process the message to generate an indicium, and update the accounting information to account for the generated indicium. The enclosure houses the processor and indicates tampering of elements within the enclosure.


Claims

What is claimed is:

1. A metering device comprising:

a memory element configured to store accounting information and information related to an operation of the metering device;

an interface circuit configured to receive a message, wherein the message includes a code that identifies the message;

a processor operatively coupled to the memory element and the interface circuit, wherein the processor is configured to receive the message, process the message to generate an indicium, and update the accounting information to account for the generated indicium; and

an enclosure that houses the processor and indicates tampering of elements within the enclosure, wherein a predetermined time out period is reset upon completion of an audit transaction.

2. The device of claim 1 further comprising:

a clock circuit operatively coupled to the processor, wherein the clock circuit is configured to provide timing information upon request.

3. The device of claim 1 wherein the memory element retains the accounting information when power is removed from the metering device.

4. The device of claim 1 wherein the accounting information includes an amount of available funds.

5. The device of claim 1 further comprising:

a printer operatively coupled to the interface circuit,

wherein the meter generates a message directing the printer to print the generated indicium, and wherein the printer receives and prints the generated indicium.

6. The device of claim 1 wherein the device couples to a computer and receives messages directing the processor to process transactions.

7. The device of claim 1 wherein operation of the meter is enabled for a predetermined time out period.

8. The device of claim 7 wherein the predetermined time out period is reset upon completion of a funding transaction.

9. The device of claim 1 wherein the available funds are increased by performing a funding transaction.

10. The device of claim 9 further comprising:

a input circuit to receive a command to print indicium,

wherein the device is configured to operate as a stand-alone unit and dispense an indicium having a predetermined value upon receiving the print command.

11. A secure metering device (SMD) comprising:

a memory configured to store information indicative of a current operating state of the SMD, wherein the current operating state is one of a plurality of valid operating states, wherein each of the plurality of valid operating states is associated with a set of permissible operations by the SMD; and

a processor coupled to the memory and configured to operate in the operating state indicated by the information stored in the memory,

wherein the plurality of valid operating states include an initialized state, a funded state, and a withdrawal state,

wherein the withdrawal state is characterized, in part, by a restriction from updating content of a revenue register within the SMD.

12. The SMD of claim 11, wherein the information indicative of the current operating state of the SMD is provided upon receiving a status request.

13. The SMD of claim 11, wherein the plurality of valid operating states further includes an uninitialized state.

14. The SMD of claim 13, wherein the uninitialized state is characterized, in part, by a restriction from updating, except via an initialization transaction, security relevant data items stored within the SMD memory.

15. The SMD of claim 11, wherein the plurality of valid operating states further includes a registered state.

16. The SMD of claim 15, wherein the registered state is characterized, in part, by an association of the SMD with a specific account.

17. The SMD of claim 11, wherein the initialized state is characterized, in part, by an assignment of a set of keys to the SMD.

18. The SMD of claim 17, wherein the set of keys is generated by the SMD based on a set of parameters provided to the SMD.

19. The SMD of claim 18, wherein the set of keys includes a private key retained by the SMD and a public key exported by the SMD.

20. The SMD of claim 11, wherein the plurality of valid operating states further includes a faulted state.

21. The SMD of claim 20, wherein the faulted state is characterized, in part, by a restriction from updating security relevant data items stored within the SMD memory.

22. The SMD of claim 20, wherein the SMD makes a transition to the faulted state upon detection of a security threat.

23. The SMD of claim 11, wherein the memory is further configured to store accounting information, wherein modification of the accounting information is allowed in a first subset of the plurality of valid operating states.

24. The SMD of claim 23, wherein modification of the accounting information is performed via a secure transaction.

25. The SMD of claim 23, wherein a set of permissible operations in the first subset of valid operating state includes updating content of a revenue register with a funding amount via a secure transaction.

26. The SMD of claim 23, wherein access to the accounting information is allowed in a second subset of the plurality of valid operating states.

27. The SMD of claim 11, wherein the plurality of valid operating states further includes a timed-out state.

28. The SMD of claim 27, wherein the SMD transitions from the funded state to the timed-out state upon expiration of a time-out timer.

29. The SMD of claim 15, wherein the timed-out state is characterized, in part, by a restriction from printing an indicium having a non-zero value.

30. The SMD of claim 15, wherein the SMD makes a transition from the timed-out state to the funded state by resetting the time-out timer to a predetermined value during an audit transaction.

31. The SMD of claim 11, wherein the funded state is characterized, in part, by storage in a revenue register of a non-zero value indicative of funds available for dispensing by the SMD.

32. The SMD of claim 31, wherein the set of permissible operations in the funded state includes updating content of the revenue register with a funding amount via a secure transaction.

33. The SMD of claim 31, wherein the funding amount is based on a user request.

34. The SMD of claim 31, wherein the set of permissible operations in the funded state includes printing of an indicium having a value limited to the non-zero value stored in the revenue register.

35. The SMD of claim 34, wherein the indicium value is further limited to a predetermined range of values.

36. The SMD of claim 35, wherein the indicium value is based on a user request.

37. A secure metering device (SMD) comprising:

a memory configured to store information indicative of a current operating state of the SMD, wherein the current operating state is one of a plurality of valid operating states, wherein each of the plurality of valid operating states is associated with a set of permissible operations by the SMD; and

a processor coupled to the memory and configured to operate in the operating state indicated by the information stored in the memory,

wherein the plurality of valid operating states include an initialized state, a funded state, and a withdrawal state,

wherein the withdrawal state is characterized, in part, by a restriction from updating content of a revenue register within the SMD,

wherein the SMD makes a transition from the current operating state to a new operating state upon occurrence of a particular event or by performing a particular transaction,

wherein the SMD transitions from the funded state to the withdrawal state by performing a withdrawal transaction.

38. The SMD of claim 37, wherein the SMD transitions from the initialized state to the funded state by performing a funding transaction.


Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates to the field of postage metering systems, and more particularly to a portable, secure, low cost, and flexible postage metering system.

A postage meter allows a user to print postage or other indicia of value on envelopes or other media. Conventionally, the postage meter can be leased or rented from a commercial group (e.g., Neopost Inc.). The user purchases a fixed amount of value beforehand and the meter is programmed with this amount. Subsequently, the user is allowed to print postage up to the programmed amount.

Historically, postage meters have been dedicated, stand-alone devices, capable only of printing postage indicia on envelopes (or labels, in the case of parcels). These devices normally reside at a single user location and only provide postage metering for that location. Such postage meters often require the user to physically transport the device to a post office for resetting (i.e., increasing the amount of postage contained in the meter). An advance over this system is the ability to allow the user to reset the meter via codes that are provided by either the manufacturer or the postal authority once payment by the user had been made.

Modem electronic meters are often capable of being reset directly by a registered party, on-site (at the user's location) via a communications link. A system that performs meter resetting in this manner is known as a Computerized Meter Resetting System (or "CMRS"). The party having authority to reset the meter and charge the user (usually the manufacturer or the postal authority) thus gains access to and resets the meter.

Even with these advancements, postage meters are still, for the most part, restricted to use at a single physical location. As such devices are dedicated (and rather sophisticated in their fail-safe attributes and security), their price tends to be prohibitive for small entities. Moreover, the items requiring postage must often be brought to the device because of the device's physical size and the need for supporting connections (i.e., power, communications, and the like).

As can be seen, a postage metering system that is portable, low-cost, secure, and flexible in operation is highly desirable. Moreover, a system that centralizes both postage accounting and security features is also highly desirable. Such a system would allow the printing of postage indicia at locations that are convenient to the end-user by allowing the user to take a portion of the system to the item in need of postage, rather than the reverse.

SUMMARY OF THE INVENTION

The invention provides a postage metering system that is portable, low-cost, secure, and flexible in operation. A secure metering device (SMD) maintains important postal information and provides the required secure processing. A computer (or host PC) provides the user interface and coordinates transactions between the SMD, a user, and a provider. By careful partitioning of the various features of the metering system, the SMD can be manufactured in a (relatively) small-size and low-cost unit. Similarly, the use of a small, dedicated printer enhances portability and low cost.

An embodiment of the invention provides a postage metering system that includes a host PC, an SMD, and a printer. The host PC includes a user interface to receive postage information. The SMD operatively couples to the computer via a communications link and includes a processor and a tamper evident enclosure. The processor is configured to receive the postage information from the computer, direct generation of an indicium, and account for the indicium. The tamper evident enclosure houses the processor and other security sensitive elements of the SMD. The printer couples to the SMD and is configured to receive and print the indicium.

Another embodiment of the invention provides a metering device that includes a memory element, an interface circuit, a processor, and an enclosure. The memory element is configured to store accounting information and information related to the operation of the metering device. The interface circuit is configured to receive a message that includes a code that identifies that message. The processor operatively couples to the memory element and the interface circuit. The processor is configured to receive the message, process the message to generate an indicium, and update the accounting information to account for the generated indicium. The enclosure houses the processor and indicates tampering of elements within the enclosure.

Yet another embodiment of the invention provides a method for printing an indicium. In accordance with this embodiment, an SMD is first registered with a provider. The SMD is then funded via a funding transaction with the provider, wherein the funding is performed via an electronic communications link. After funding, the SMD receives a request to print the indicium. The SMD verifies if sufficient funds exist in the SMD to cover the value of the indicium. If sufficient funds exist, the SMD generates a signed message that includes the indicium. The signed message is verified for authenticity and, if authentic, the indicium is printed.

The foregoing, together with other aspects of this invention, will become more apparent when referring to the following specification, claims, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B show diagrams of two embodiments of a postage metering system of the invention;

FIG. 2A shows a block diagram of an embodiment of a metering device;

FIG. 2B shows a block diagram of an embodiment of a host PC;

FIGS. 3A and 3B show diagrams of embodiments of the interconnection between the two different metering devices and the host PC;

FIG. 4 shows a diagram of an embodiment of a communications protocol between the metering device and the host PC;

FIG. 5A shows a flow diagram of an embodiment of an operational process of the metering device;

FIGS. 5B, 5C and 5C-2, 5D and 5D-2, 5E and 5E-2, 5F and 5F-2, and 5G and 5G-2 show flow diagrams of an embodiment of the Initialization, Registration, Funding, Indicium, Audit, and Withdrawal transactions, respectively;

FIG. 6A shows a state diagram of a specific embodiment of the operating states of the SMD;

FIGS. 6B through 6G show state diagrams of a specific implementation of the Initialization, Registration, Funding, Indicium, Audit, and Withdrawal transactions, respectively;

FIGS. 7A and 7B show state diagrams of a specific embodiment of the Host and the SMD Protocol Initialization processes, respectively;

FIGS. 7C and 7D show state diagrams of a specific embodiment of the Packet Transmission and Reception processes, respectively, for both the host PC and SMD;

FIGS. 8A through 8F show diagrams of an embodiment of a main menu screen, a registration screen, a funding screen, an indicium printing screen, an audit screen, and a device status screen, respectively, displayed by the host application software; and

FIG. 9 shows an illustration of a specific embodiment of an indicium.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

System Description

FIG. 1A shows a diagram of an embodiment of a postage metering system 100a of the invention. System 100a includes a postage metering device 110a that couples to a host personal computer (host PC) 120 via a communications link 122. Host PC couples to a system server 130 (also referred to as a POSTAGE-ON-CALL.TM. system or POC system) via another communications link 132. Communications link 122 can be a serial link such as an RS-232 interface. Communications link 132 can be a telephone link, a wireless link, or other links. Metering device 110a can further couples to an optional scale 140, or other peripheral devices, via a communications link 142 that may also be an RS-232 interface. In this embodiment, metering device 110a includes a secure meter device (SMD) 150 and a printer 152. The operation of each element in system 100a is further described below.

FIG. 1B shows a diagram of an embodiment of another postage metering system 100b of the invention. System 100b is similar to system 100a in FIG. 1A and includes a postage metering device 110b that couples to host PC 120 via communications link 122 and to optional scale 140 via communications link 142. Host PC 120 couples to system server 130 via communications link 132 and to a printer 170 via a communications link 172. Communications link 172 can also be a serial link such as an RS-232 interface. In this embodiment, metering device 110b includes SMD 150 but no printer.

FIG. 2A shows a block diagram of an embodiment of metering device 110a. Metering device 110a includes SMD 150 and printer 152. Within SMD 150, a processor (also referred to as a CPU) 210 couples to a bus 212 that also interconnects a non-volatile memory 216, a volatile memory 218, a clock 220, and a host interface 222. Sensors 224 can be dispersed throughout metering device 110a to detect tampering with the device and to report such event to processor 210. Sensors 224 can couple directly to processor 210 or to bus 212, or a combination of both. Processor 210 performs data processing and coordinates communication with the host PC. Processor 210 also performs the secure processing of the metering device. Non-volatile memory 216 stores data, information, and codes used by the metering device, such as accounting information and information that defines and describes the operation of the metering device. Volatile memory 218 store data and program instructions. Clock 220 provides indication of current time when requested by the processor. Host interface 222 provides the interface with the host PC, and can be a standard interface such as RS-232. Host interface 222 couples to printer 152 via an RS-232 interface or other interfaces.

In accordance with an aspect of the invention, the SMD is responsible for maintaining the contents of certain security relevant data items (SRDIs). The SRDIs include revenue registers, cryptographic keys used for secure data transfer, and others. In an embodiment, the SMD comprises a cryptographic module that performs the secure processing required by the postage metering system. In an embodiment, the cryptographic module includes processor 210, memories 216 and 218, clock 220, and communication interfaces 222 and 228. The cryptographic module is enclosed in a tamper-evident enclosure, and removal of the cryptographic module from the enclosure is possible only upon destruction of the enclosure.

FIG. 2B shows a block diagram of an embodiment of host PC 120. Host PC 120 may be a desktop general-purpose computer system, a portable system, a server, or may be a larger "mainframe" system. Host PC 120 includes a processor 240 that communicates with a number of peripheral devices via a bus 242. These peripheral devices typically include a memory subsystem 244, a user input facility 246, a display subsystem 248, output devices such as a file storage system 252 and printer 170 via a serial port 254. Memory subsystem 244 may include a number of memory units, including a non-volatile memory 256 and a volatile memory 258 in which instructions may be stored. User input facility 246 typically includes a keyboard 262 and may further include a pointing device 264 (e.g., a mouse, trackball, or the like) or other common input devices 266. Display subsystem 248 typically includes a display device 268 (e.g., a cathode ray tube (CRT) or similar devices) coupled to a display controller 270. File storage system 252 may include a hard disk 274, a floppy disk 276, other storage media 278, or a combination of the above. Network connections are usually established through a device such as a network adapter 282 coupled to bus 242, or a modem via serial port 254.

Processors 210 and 240 can be implemented as an application specific integrated circuit (ASIC), a digital signal processor, a microcontroller, a microprocessor, or others electronics units designed to perform the functions described herein. Non-volatile memories 216 and 256 can be a read only memory (ROM), a FLASH memory, a programmable ROM (PROM), an erasable PROM (EPROM), an electronically erasable PROM (EEPROM), a battery augmented memory (BAM), a battery backed-up RAM (BBRAM), or other memory technologies. Volatile memories 218 and 258 can be a random access memory (RAM), a FLASH memory, or other memory technologies. Clock 220 is a real-time clock or a secured timer, which is battery backed, to provide accurate time indication even if the metering device is powered down.

As used herein, the term "bus" generically refers to any mechanism for allowing the various elements of the system to communicate with each other. Buses 212 and 242 are each shown as a single bus but may each include a number of buses. For example, a system typical has a number of buses such as a local bus and one or more expansion buses (e.g., ADB, SCSI, ISA, EISA, MCA, NuBus, or PCI), as well as serial and parallel ports.

Printers 152 and 170 can be specially designed printers or conventional printers. Printers 152 and 170 are capable of printing one-dimensional barcodes, two-dimensional barcodes, FIM (facing identification mark) markings, human readable information, and others. In a specific embodiment, printer 152 is a specially designed printer that is used to print indicia only, although it may be capable of printing other information such as address label, tax stamp, secured ticket, money order, and the like. One such printer is a thermal printer having a resolution of, for example, approximately 200 dots per inch.

In the embodiment shown in FIG. 1A, the printer is enclosed within the metering device. The host interface can be designed to operate on a command set written to reject external print commands, as described below.

With the exception of the input devices and the display, the other elements need not be located at the same physical site. For example, portions of the file storage system could be coupled via various local-area or wide-area network links, including telephone lines. Similarly, the input devices and display need not be located at the same site as the processor, although it is anticipated that the present invention will most often be implemented in the context of general-purpose computers and workstations.

FIG. 3A shows a diagram of an embodiment of the interconnection between metering device 110a and host PC 120. As shown in FIG. 3A, host PC 120, metering device 110a, and scale 140 couple in a daisy-chain communications link. Within metering device 110a, SMD 150 and printer 152 couple in series and form part of the daisy chain. With the daisy chain link, only one communications port on host PC 120 is required to support the metering device of the invention, and the interconnection between these elements is simplified. The daisy chain architecture also allows for additional (optional) elements to be coupled to the system by simply inserting the elements in the daisy chain. An example of such element is a display unit that displays the value of the transaction, the results of the processing, and other information.

FIG. 3B shows a diagram of an embodiment of the interconnection between metering device 110b and host PC 120. As shown in FIG. 3B, host PC 120, printer 170, metering device 110b, and scale 140 couple in a daisy-chain communications link. This configuration is similar to that of FIG. 3A, and the system operates in similar manner even though printer 170 is not enclosed within metering device 110b. In fact, printer 170 can be any standard printer designed to operate with a general-purpose PC.

As shown in the specific implementations in FIGS. 3A and 3B, the printer couples between the host PC and the SMD. This is advantageous since only one communications port (e.g., a serial port) on the host PC is required for the postage metering system. Moreover, the host PC does not need to be reconfigures for used with the metering system since metering device 110a can be directly coupled to a serial port of the host PC and metering device 110b can be coupled to a (normally unconnected) auxiliary port on the printer that couples to the serial port. However, other configurations between the metering device, the printer, and the host PC are possible and are within the scope of the invention. For example, the metering device and printer can be coupled to the host PC in a star configuration (as shown in FIG. 1B). In the star configuration, any communication between the metering device and the printer pass via the host PC.

In a specific embodiment, the daisy chain communications link has the following characteristics:

1) Messages sent by the host PC and intended for the SMD are passed unmodified by the printer. The printer does not analyze or store the data included in these messages, with the exception of few specific messages (e.g., a LABELMODE1 message) as described below.

2) Messages send by the SMD and intended for the host PC are normally passed unmodified by the printer. Again, the printer does not analyze or store the data included in these messages, with the exception of few specific printer-directed messages (e.g., an INDICRUM2 message). The printer intercepts messages specifically directed to it, and processes these printer-directed messages.

In a specific embodiment, when the printer intercepts a printer-directed message, the following actions occur:

1) The printer sends a confirmation message (e.g., an INDICIUM3 message) to the host PC. This confirmation message is received by the host PC and interpreted as an indication that the printer has received the printer-directed message. In an embodiment, the confirmation message includes a status field that indicates whether the printer-directed message contained an error, but does not include information (e.g., the indicium) about the action taken in response to the printer-directed message. If the printer-directed message was received in error (i.e., as indicated by a CRC error), the confirmation message sent to the host PC indicates this error. The confirmation message includes a Packet ID field having a value obtained from the Packet ID field of the printer-directed message.

2) When the host PC receives the confirmation message with an "accepted" status field, the host PC responds with an acknowledgment (ACK) message. Alternatively, when the host PC receives the confirmation message with an "rejected" status field, the host PC responds with a negative acknowledgment (NACK) message. The ACK or NACK message includes a Packet ID field having a value obtained from the Packet ID field of the confirmation message.

3) The printer passes the ACK or NACK message, unmodified, to the SMD.

By including the value in the Packet ID field of a received message in a transmitted message, a mechanism is provided to ensure that the values of the Packet ID stored within the SMD and the host PC remain correct, even with the interception of the printer-directed message by the printer. This feature is further described below.

FIG. 4 shows a diagram of an embodiment of a communications protocol between metering device 110 and host PC 120. As shown in FIG. 4, metering device 110a and host PC 120 communicate with each other using a two-layer (software) protocol supported by communications link 122 (e.g., a serial interface such as RS-232). Data link layer 410a residing on metering device 110a interacts via communications link 122 with data link layer 410b residing on host PC 120. Data link layers 410a and 410b provide reliable transportation of application layer messages between metering device 110a and host PC 120. Data link layers 410a and 410 are further described below and also in the aforementioned U.S. provisional patent Application Serial No. 60/075,934. Application layers 412a and 412b communicate with data link layers 410a and 410b, respectively, and support the various features and functionality of the metering device. Accordingly, various aspects of the invention are described in the context of the Application Level protocol.

As shown in FIG. 2A, two communications channels extend outside the SMD's enclosure. Processor 210 of the SMD communicates with host PC 120 via host interface 222 that couples to a main communications channel 232 (also referred to as the main port). An auxiliary communications channel 234 (also referred to as the auxiliary port) is used in a "pass-through" mode to replace the serial port on the host PC taken up by the SMD. An external device such as a postal scale can couple to the SMD's auxiliary port. The SMD passes data from the external device to the host PC via the main port. In an embodiment, data received from the auxiliary port is not interpreted by the SMD, and there are no services in the SMD that can be activated by data sequences applied to the auxiliary port (i.e., for security reason, as described below). In an embodiment, all secure communication occurs over the main port, and the SRDIs are not received from or written to the auxiliary port by the SMD. In an embodiment, the SMD processes Application Level protocol messages received on the main port and no other ports, including the auxiliary port, again for security reasons.

The host PC can communicate indirectly with the external device coupled to the auxiliary port via Application Level protocol messages presented to the main port. These messages include, for example, CONFIG AUX PORT, ENABLE AUX PORT, GET AUX STATUS, GET AUX DATA, SEND AUX DATA, AUX STATUS and AUX DATA messages that are further described in Exhibit A. Host interface 222 includes mechanism that facilitates bi-directional communication between the host PC and the external device. The communication is routed through the SMD, but the SMD does not interpret data sent to, or received from the auxiliary port.

The host PC can configure various parameters associated with the auxiliary port, such as the baud rate, parity, and so on. This configuration is achieved by sending a CONFIG AUX PORT message to the SMD. The host PC may then enable communication with the external device by sending the SMD an ENABLE AUX PORT message with an Enable Flag parameter of 0.times.FF.

In an embodiment, the SMD includes an auxiliary buffer 228 coupled to the auxiliary port. While the auxiliary port is enabled, the SMD receives data from the port and stores it into the buffer. If an Automatic Report Flag is turned ON, the SMD packages the contents of the buffer into an AUX DATA message whenever the buffer reaches a predetermined limit. This message is then sent to the host PC and the buffer is cleared. The buffer then resumes accumulating data from the auxiliary port. AUX DATA messages are sent whenever the buffer reaches the predetermined limit and as long as the auxiliary port is enabled. If the Automatic Report Flag is turned ON and the buffer is not full but a timeout period is reached, the SMD transmits the contents of the buffer in another AUX DATA message.

While the auxiliary port is enabled, the host PC may at any time send a GET AUX DATA message. Upon receipt of a GET AUX DATA message, the SMD sends an AUX DATA message that includes the current contents of the buffer. The SMD then clears the,buffer, whether or not the buffer has reached its fill limit, and resumes accumulating data.

The host PC may also send data to the external device by sending a SEND AUX DATA message to the SMD. Upon receipt of this message, the SMD receives all data following the Message Type code and sends the unaltered data to the auxiliary port. After completing communication with the auxiliary port, the host PC may disable the port by sending to the SMD an ENABLE AUX PORT message with an Enable Flag parameter of 0.times.00.

The communication protocol described above between the host PC and SMD provides many advantages. First, communication between the host PC and the external device(s) is maintained even in the presence of the SMD interposed within the communications path. For example, if a printer is coupled to the auxiliary port, the host PC can send normal print commands to this printer without alteration by the SMD. The SMD appears transparent to the host PC for messages that are directed to the external device(s). Second, a secured communications link is maintained between the host PC and SMD for security sensitive processes.

SMD Roles

The SMD supports a number of different roles during various transactions and services in which it participates. In a specific implementation, the SMD supports the roles of a Crypto-Officer, a provider, a controlling authority (CA), and a user. The SMD performs predetermined functions and provides predetermined services to each of the roles. The provider is an entity (i.e., a vendor such as Neopost Inc.) that operates a finding system (such the Neopost funding computer, which is also called the POC system). The controlling authority is an entity (such as the U.S. Postal Service (USPS) that "approves" devices (e.g., the SMD) for postal operation. Greater, fewer, or different roles can be supported by the SMD, and this is within the scope of the invention. Greater, fewer, or different services than those described below can be provided by the SMD, and this is also within the scope of the invention. The following describes a specific implementation of the actions performed to each of the roles.

A Crypto-Officer initializes the SMD at the factory (i.e., after the metering device has been manufactured). The Crypto-Officer role is available at the factory, before the SMD is sealed in its tamper-evident enclosure. The SMD validates the Crypto-Officer when the Crypto-Officer installs a FIT (field initialization transaction) flag that is located on the SMD. The SMD performs the Initialization service after the flag has been installed. The Initialization service causes the SMD to generate a pair of public and private keys, export the public key, and load a Provider X.509 certificate that includes the provider's public key. The Crypto-Officer obtains and provides the Provider X.509 certificate to the SMD and archives the SMD's public key. After initializing the SMD, the Crypto-Officer removes the flag and closes the tamper-evident cover.

The SMD supports the provider role by providing the following services: Registration, Funding, Audit, and Withdrawal. These services are described in detail below. Whenever one of these services is requested, the SMD validates that the requester is an authorized provider. This is achieved by using the provider's public key to validate the signature on the service request that has been signed using the provider's private key. The provider's public key is retrieved from the Provider X.509 certificate that is loaded by the Crypto-Officer during initialization.

The SMD supports the user role by providing the following services: Indicium, Status, Self-Tests, Read & Adjust RTC, Read X.509 Certificates, and Configure Aux. Serial Port. These services are described in detail below. The SMD does not verify the requester in the user role. If one of these services is requested after the SMD has been initialized, the SMD performs the service without requesting a role validation.

The SMD supports the controlling authority role by providing an Inspection service. A request to perform an Inspection is signed using the CA's private key. The SMD validates the signature using the CA's public key stored in the CA X.509 certificate loaded by the Authorize service, as described below.

SMD Operating States

In a specific implementation, SMD operates in one of a predetermined number of operating states. The current operating state depends on the contents of a set of registers or locations in the SMD's non-volatile memories. These contents define and describe the operation of the SMD. The SMD generally transitions between the operating states as a result of a transaction with the host PC and the system server (for some transactions). However, some of the operating states can be reached in response to other conditions (e.g., detection of tampering with the SMD), as described below.

In a specific embodiment, the SMD includes two types of operating state: persistent states and intermediate states. A persistent state is one in which the SMD may remain for an indefinite period of time, even if power is removed and reapplied. An intermediate state is one that the SMD occupies for a short period of time, and is not occupied by the SMD upon power-up. Intermediate states are reached during transactions that include the transmission of more than one request/response message pair. In an embodiment, if the SMD is in an intermediate state and an unexpected event occurs (e.g., power is removed or an unexpected message is received), the SMD reverts, when operation resumes, back to the previous persistent state it occupied prior to the beginning of the transaction.

FIG. 6A shows a state diagram of a specific embodiment of the operating states of the SMD. In the embodiment shown in FIG. 6A, the SMD includes an Uninitialized state 612, an Initialized state 614, an Registered state 616, a Faulted state 618, a Time-Out state 620, a Public Rekey state 622, and a Private Rekey state 624. Greater, fewer, or different operating states may be used and are within the scope of the invention. The following describes a specific implementation of the operating states.

Uninitialized State: The SMD enters the Uninitialized state when it is determined on power-up that the SMD has not been initialized. Newly manufactured SMDs and SMDs that have been reset enter this state upon their first power-up. When in the Uninitialized state, the SMD does not allow SRDIs to be altered except via a valid Initialization transaction. Such a transaction is typically performed at the factory since it involves the generation and cataloging of the SMD's private and public keys.

Initialized State: The SMD transitions from the Uninitialized state to the Initialized state after completing a successful Initialization transaction. An initialized SMD is unable to dispense revenue, but can transmit the contents of revenue and identification registers to the host PC. In an embodiment, an initialized SMD is not assigned to any particular user.

Registered State: The SMD transitions from the Initialized state to the Registered state after completing a Registration transaction. The Registration transaction may be performed outside the factory, and is usually performed at the user's premises using the user's PC as the host PC. A Registered SMD is registered to a particular user, but is still unable to dispense revenue because no revenue has been loaded into the SMD. A Registered SMD is able to issue zero valued indicia to allow the user to test the operation of the system.

A Registered SMD may be funded by performing a Funding transaction with the system server via the host PC. The Funding transaction adds revenue to the revenue registers within the SMD. A funded SMD is capable of issuing non-zero valued indicia, up to an authorized maximum value. Once the SMD has dispensed enough revenue such that the amount remaining in the revenue registers is less than an authorized minimum value, the SMD can no longer issue non-zero valued indicia until another Funding transaction is completed.

A Registered SMD may also process a request to print indicium by performing an Indicium transaction.

Faulted State: The SMD transitions to the Faulted state if the SMD has been registered and a security threat is detected. While in the Faulted state, the SMD does not perform transactions that can alter the revenue registers. The SMD can transition out of the Faulted state with a signed message from the USPS or other controlling agencies. The agency typically inspects a faulted SMD before sending this signed message to the SMD.

Time-Out State: The SMD maintains a timer that is initialized with a time-out value transferred to the SMD during the Registration transaction. The timer counts down in real time until it reaches zero, at which point the timer "times out." If the timer times out while the SMD is in the Registered state, the SMD transitions to the Timed-Out state and sends the host PC a message (e.g., a STATECHG message) indicating that it has transitions to the Time-Out state. The SMD does not transition out of the Timed-Out state unless it successfully completes an Audit transaction, in which case it transitions back to the Registered state. If a security threat is detected while in the Time-Out state, the SMD transitions to the Faulted state.

In an embodiment, a timed-out SMD does not dispense indicia, even if there is sufficient revenue within the revenue registers. This specific implementation forces the user to perform periodic Audit transactions to allow the provider to audit and track the SMD from time to time to ensure that it is not being used in a fraudulent manner.

Intermediate States: If a transaction comprises more than one request/response message pair, the SMD waits in an intermediate state, upon sending the response for a particular message pair, for the next request message in the transaction sequence. Intermediate states are designed such that the SMD expects a particular request message. The action taken by the SMD depends on the next request message received by the SMD and the time the message is received.

While in the intermediate state, the SMD terminates the transaction if any of the following conditions occurs: (1) a message other than the next expected request is received, (2) the SMD receives from the host PC a signed message that includes an invalid signature, (3) the SMD does not receive the expected message to continue the transaction within a predetermined period (e.g., two minutes). Termination of the transaction includes sending the host PC an error message that includes an appropriate error code and returning to the operating state the SMD occupied prior to the start of the transaction. If power is removed from the SMD while it is in an intermediate state the SMD, upon subsequent power-up, reverts to the state it occupied previous to the start of the transaction. Upon receipt of the last request message in the transaction and after sending the final response message, the SMD transitions to the operating state appropriate for that particular transaction.

Upon power up, the SMD performs checks to determine which one of the allowable operating states to enter. The power-up checks include checks necessary to insure proper operation of the metering device and checks of the SRDIs within the SMD. The checks may further include the verification of the CRC or the signature of the contents of the SRDIs. If it is determined upon power-up that the SMD has not been initialized, the SMD transitions to the Uninitialized state. The SMD transitions to the Faulted state if the power-up checks determine that the SMD has been initialized but some SRDIs contain invalid data.

Transactions

The SMD provides services by exchanging messages between itself and the host PC via the SMD's main port. A service is a set of operations performed by the SMD on behalf of an entity operating in a particular role. Communications software is installed on the host PC to access SMD services. The software is readily available from the provider, and no special security is associated with obtaining or installing the software.

The messages are structured into groups called transactions. A transaction is a series of one or more request/response message pairs comprising the performance of a particular service. A request message is a message sent from the host PC to the SMD. A response message is a message sent from the SMD to the host PC following the SMD's processing of the request message.

The SMD interacts with the host PC to carry out various transactions and functions. As an example, the SMD cooperates with the host PC to generate revenue certificates referred to as indicia. An indicium may be generically viewed as a printed certificate that can be used as evidence that a certain amount of money has been paid, similar to a postage stamp. Indicia can in fact be used for postage stamps.

In an embodiment, the SMD provides the following functions: (1) secure data storage for the SRDIs, (2) secure storage and processing for indicia information, (3) security processing (e.g., verification of a signed message using digital signature algorithm (DSA)), (4) I/O communications with the host PC, (5) processing as required by the postage metering system, and others. Some of these functions are performed by the SMD without input or intervention from external devices, while some other functions are performed in cooperation with the host PC and (for some transactions) the system server. The various services and functions performed by SMD are further described below.

The host PC performs various functions in support of the SMD. For example, the host PC acts as a user interface to receive user inputs and to display messages and results. The host PC also provides some processing of the received data, such as calculation of the proper postage amount for an indicium based on user input data. The host PC sends requests to the SMD, receives responses from the SMD, and processes the responses. For example, the host PC can store the responses from the SMD and displays the responses such that the user can be informed of success or failure of a request. The various functions performed by the host PC are further described below.

The SMD also interacts with the system server (via the host PC as shown in FIGS. 1A and 1B) to engage in specific transactions, as required or allowed by the postage metering system. Some of the requirements may be imposed by the USPS. In an embodiment, the SMD can be directly coupled to the system server via communications channels such as a (dedicated) wide area network (WAN), the Internet, and others. Transactions between the SMD and system server can include the following: (1) system registration (including lockout and update), (2) postage value download, (3) device audit, (4) device withdrawal, (5) error state correction of the metering device, and others. The various transactions between SMD and system server are further described below.

FIG. 5A shows a flow diagram of an embodiment of an operational process of the metering device. At a step 510, a user receives the metering device with the associated software from the provider (Neopost Inc.). The user then installs the software on a host PC and executes the software, at a step 512. Via the software, the user initiates an online registration of the SMD, at a step 514. Alternatively, the registration can be performed through other techniques such as calling a customer representative of the provider. The host PC, SMD, and system server then interact and cooperate to register the SMD, at a step 516. After a successful registration, the user is allowed to operate the metering device, at a step 518, for various transactions such as printing indicia.

In a specific implementation, the SMD supports the following services: Initialization, Registration, Indicium, Funding, Audit, Withdrawal, Status, Self Tests, Adjust RTC, Get X.509 Certificate, and Enable, Disable, and Configure Auxiliary Serial Port. Greater, fewer, or different services than those listed above can be provided by the SMD, and this is within the scope of the invention. Each of these services is performed to a particular role, as tabulated in Table 1. 

                             TABLE 1
                   Roles versus Services Matrix
                                        Roles
                        Crypto-              Controlling
    Services            Officer   Provider    Authority   User
    Initialization         X
    Registration                      X
    Indicium                                                X
    Funding                           X
    Audit                             X
    Inspection                                    X
    Withdrawal                        X
    Status                                                  X
    Self Tests                                              X
    Adjust RTC                                              X
    Read X.509                                              X
    Certificates                                            X
    Auxiliary Port Ops                                      X


The SMD processes transaction requests that are appropriate for the current operating state of the SMD. Exhibit C tabulates the messages that are appropriate for the various operating states. If the SMD receives a request message that is not appropriate for the current operating state, the SMD sends an error response message to the host PC and returns to the operating state it occupied before receiving the request.

Initialization transaction: An Initialization transaction prepares the SMD for operation. The following is a specific implementation of the Initialization transaction, and other implementations are available.

FIG. 5B shows a flow diagram of an embodiment of the Initialization transaction. At a step 520, the SMD is prepared for the Initialization transaction. This preparation can comprise installing a FIT flag located on the SMD. The Crypto-Officer then, via a host PC, sends the SMD an initialization request message that includes the Provider X.509 certificate and the device ID number, at a step 522. This request message is signed using the provider's private key. The SMD receives and validates the request message, at a step 524.

The SMD accepts a request to perform an Initialization transaction if it is in an Uninitialized or Initialized state. This determination is performed at a step 526. If the SMD receives a request to perform an Initialization transaction and the FIT flag is not installed or if the SMD is not in the Uninitialized or Initialized state, the SMD ignores the request and the transaction terminates. The validation of the request message includes verification of the signature in the request message using the provider's public key from the Provider X.509 certificate, at a step 528. If the signature is invalid, the SMD sends an error message, at a step 530, and the transaction terminates.

If the signature is valid, the SMD saves the Provider X.509 certificate provided in the request message, at a step 532. The DSA (digital signature algorithm) parameters p, q, and r are then loaded into the SMD, at a step 534. The SMD uses these parameters to generate a pair of public and provide keys, at a step 536. The SMD retains the private key in secrecy and exports the public key. The SMD sends the host PC a signed message that includes the SMD's public key, at a step 538. This message is signed using the SMD's private key and can be verified by the host PC using the SMD's public key that is included in the message. The SMD then transitions to the Initialized state, at a step 540. Before an initialized SMD leaves the factory, the Crypto-Officer removes the FIT flag and seals the tamper-evident enclosure, at a step 542.

The SMD does not accept a request to perform any transaction other than an Initialization transaction if it is in the Uninitialized state. After a successful Initialization transaction, the SMD transitions to the Initialized state. The SMD tests for the presence of the FIT flag when a request is received to perform any transaction that alters the SRDIs. If the FIT flag is present and the requested transaction is not the Initialization transaction, the SMD enters the Faulted state.

In summary, the following operations are performed by the Initialization transaction:

Load the DSA parameters p, q, and g into the SMD.

Load the Provider X.509 certificate that includes the provider's public key into the SMD.

Instruct the SMD to generate a public/private key pair.

Instruct the SMD to export the public key.

Place the SMD the Initialized operating state.

Registration transaction: A Registration transaction prepares the SMD for operation at a user site and notifies the system server to activate the user's account. In an embodiment, registration of the SMD is performed before the SMD is allowed to process other transactions. The Registration transaction is achieved between the host PC, SMD, and system server via the SMD's main port. The following is a specific implementation of the Registration transaction, and other implementations are available.

FIGS. 5C and 5C-2 show a flow diagram of an embodiment of the Registration transaction. At a step 550, the user requests, via the host PC, registration of the SMD. The user typically initiates an online registration when the user first installs the application software on the host PC. In response, the host PC sends the SMD a registration request message that includes the SMD X.509 certificate, at a step 552. This request message is signed using the provider's private key. The SMD receives and validates the request message, at a step 554.

The SMD X.509 certificate includes the SMD's public key, and is sent along with messages signed by the SMD. The SMD X.509 certificate allows entities receiving the SMD signed messages to validate the signatures included in the signed messages. The SMD X.509 certificate is generated by the USPS based on the SMD's public key that was sent to the Crypto-Officer during the Initialization transaction.

The registration can be performed by an entity operating in the provider role, and this role is validated by requiring that the registration request message from the host PC be signed using the provider's private key. Thus, the validation of the request message includes a verification of the signature in the request message, at a step 556. The SMD verifies the signature using the provider's public key from the Provider X.509 certificate loaded into the SMD during the Initialization transaction. If the signature is invalid, the SMD sends an error message, at a step 558, and the transaction terminates. If the signature is valid, the transaction continues.

The SMD accepts a request to perform a Registration transaction if it is in an Initialized or Registered state. This determination is performed at a step 560. If the SMD receives a request to perform an Initialization transaction and is not in the Initialized or Registered state, the SMD sends an error message, at a step 562, and the transaction terminates.

Otherwise, if the SMD is in the proper operating state, it stores the SMD X.509 certificate includes in the request message, at a step 564, The SMD then sends the host PC a signed message that includes the device ID, at a step 566, and transitions to an intermediate state, at a step 568. The host PC receives and forwards the signed message to the system server, at a step 570. The system server registers the SMD and sends the host PC a message, at a step 572. The host PC receives the message from the system server and sends the SMD a signed message that includes the USPS X.509 certificate and other information, at a step 574. The SMD receives and validates the message, at a step 576.

During the Registration transaction, the SRDIs are included in a request message signed using the provider's private key and loaded into the SMD. The SMD does not accept any data included in such message unless it verifies the signature using the provider's public key. The validation of the message includes verification of the signature and the message type, at a step 576. If it is determined, at a step 578, that the signature is invalid or the message is of an unexpected type, the SMD sends an error message, at a step 580. The SMD then returns to the Initialized state, at a step 582, and the transaction terminates.

Otherwise, if the signature is valid and the message is of an expected type, the SMD stores the USPS X.509 certificate and the information included in the message, at a step 584. The SMD then transitions to the Registered state, at a step 586, and sends the host PC a message indicating a change in operating state, at a step 588.

In summary, the Registration transaction performs the following operations:

Load the SMD X.509 certificate into the SMD.

Load the user's account number and licensing information into the SMD.

Load a maximum and a minimum indicium revenue value, and a Watchdog Timer increment value into the SMD.

Load the CA X.509 certificate into the SMD. A controlling authority (such as the USPS) provides a certificate to the SMD that includes the authority's public key so the SMD can verify signature on messages signed by the authority.

Funding transaction: A Funding transaction allows an entity operating in the provider role to authorize the SMD to add more revenue to its revenue registers so it can generate more indicia. The user requests the host PC to begin a Funding transaction. The entity operating in the user role cannot authorize the Funding service, but can request initiation of the service. The entity operating in the provider role participates in, and authorizes the Funding service. Funding of the SMD is allowed after the SMD has been registered with the system server, which is achieved by the process described above in FIGS. 5C and 5C-2.

In an embodiment, funding is authorized by the system server based on, for example, funds that have been previously deposited and credited to the user's account. Alternatively, the funds can be provided by the user during the funding transaction through the use of, for example, a debit card, a charge card, a charge account, or other credit mechanisms. At the completion of the funding process, the SMD revenue registers are incremented by an amount specified by the system server, and the system server debits the user's account accordingly. The following is a specific implementation of the Funding transaction, and other implementations are available.

FIGS. 5D and 5D-2 show a flow diagram of an embodiment of the Funding transaction. At a step 5100, the user requests, via the host PC, funding of the SMD. Alternatively, the host PC can also query the user for a Funding transaction if the available funds drop below a predetermined value or if the available funds are insufficient to cover the requested transaction. The host PC can provide the user with information such as the current available funds in the SMD, the upper and lower fund amounts that can be requested, and so on. The user can enter the requested funding amount, the payment option, and other information.

The host PC sends the SMD a funding request message that includes the requested funding amount, at a step 5102. This request message is signed using the provider's private key. The SMD receives and validates the request message, at a step 5104.

The funding can be performed by an entity operating in the provider role, and this role is validated by requiring that the funding request message from the host PC be signed using the provider's private key. Thus, the validation of the request message includes a verification of the signature in the request message using the provider's public key, at a step 5106. If the signature is invalid, the SMD sends an error message, at a step 5108, and the transaction terminates. If the signature is valid, the transaction continues.

The SMD accepts a request to perform a Funding transaction if it is in a Registered state. This determination is performed at a step 5110. If the SMD receives a request to perform a Funding transaction and is not in the Registered state, the SMD sends an error message, at a step 5112, and the transaction terminates.

Otherwise, if the SMD is in the Registered state, it transitions to an intermediate state, at a step 5114. The SMD then sends the host PC a signed message that includes the required information, at a step 5116. The required information may include, for example, the requested funding amount, the current contents of the revenue registers, the customer licensing information (e.g., the identity of the SMD and the user's account), the current date and time, a transaction serial number generated by the SMD, and other information (e.g., the credit or debit card number and its expiration date). The host PC receives and forwards the signed message to the system server, at a step 5118.

The system server receives and validates the message, and either authorizes or rejects the funding request, at a step 5120. As part of the processing, the system server authenticates the signed message using the SMD's public key. If sufficient funds are available in the user's account (or if the credit card is approved for the requested amount), the system server authorizes the charging of the funds. The system server may also track the SMD and log the requested transaction (i.e., regardless of whether the funding is approved or not). The system server then sends the host PC a signed message that includes the authorization or rejection, at a step 5122.

The host PC receives and forwards this signed message to the SMD, at a step 5124. The host PC may also display the results of the funding process (i.e., informing the user that the requested funding has been approved or rejected by the system server). The SMD receives and validates the message, at a step 5126. The validation of the signed message includes a verification of the signature and a determination of whether the message is of the expected type, at a step 5128. If the signature is invalid or the message is not of the expected type, the SMD sends an error message, at a step 5130, and transitions to the Registered state, at a step 5132. The transaction then terminates.

Otherwise, if the signature is valid and the message is of an expected type, the SMD determines if the relevant data content of the message is correct, at a step 5134. This may include, for example, verification that the transaction serial number in the received message is the same as the number forwarded by the SMD earlier. If the data is not valid, the SMD proceeds to step 5130 and sends an error message. Otherwise, if the data is valid, the SMD updates the revenue registers as authorized (i.e., by zero if funding is rejected, or by the authorized funding amount), at a step 5136. The SMD then transitions to the Registered state, at a step 5138. The SMD sends the host PC, at a step 5140, a signed status message that includes, for example, the updated revenue registers and the transaction serial number. This message is forwarded to the system server, at a step 5142. The host PC may update the display to inform the user that the requested funds are available for use. The transaction then terminates.

In a specific embodiment, the available funds within the SMD are limited to a predetermined amount (e.g., $500, or some other values). The finding request is then limited based on the currently available funds, the predetermined fund limit, and the amount of approved credit. For example, if the limit is $500 and the SMD has $20 of funds remaining when the user requests a funding transaction, the amount of request is limited to $480. This implementation reduces the risks of fraud, loss, and theft since the total funds amount cannot be increased to a large amount.

Indicium transaction: An Indicium transaction allows the user to obtain revenue in the form of indicia from the SMD. Printing of the indicium is allowed after the SMD has been registered with the system server, which is achieved by the process described above in FIGS. 5C and 5C-2. The Indicium transaction is initiated when, at the user's request, the host PC sends the SMD a message requesting the SMD to deduct a revenue amount from its revenue registers. If sufficient funds exist, the SMD generates a signed bit pattern representing the revenue (i.e., an indicium) that is sent to the host PC. The host PC then renders the indicium into a predetermined (e.g., 2-D barcode) format and prints it on a document. The printed indicium is verifiable visual evidence that revenue was paid.

In the following description, the SMD is coupled to the host PC and the user interacts with the SMD via the host PC. The SMD is also capable of operating in a stand-alone mode, and this is described below. The following is a specific implementation of the Indicium transaction, and other implementations are available.

FIGS. 5E and 5E-2 show a flow diagram of an embodiment of the Indicium transaction with the SMD. At a step 5150, the user requests, via the host PC, printing of an indicium. The host PC can provide the user with information such as the funds available in the SMD, the rate tables, the address (e.g., zip code) information, and others. The user can enter mail parameters such as the class of mail, the zip-code information, and so on. Based on the information entered by the user and additional information (e.g., the mail weight information from a scale coupled to the serial port), the host PC determines the amount of postage for the indicium. Alternatively, the user can directly enter the postage amount.

The host PC sends the SMD an indicium request message that includes the requested indicium value, at a step 5152. In a specific implementation, this request message is not signed using the provider's private key, and anyone with access to the host PC can request printing of an indicium. However, safeguards can be included in the host PC software (i.e., through the use of a password) to prevent unauthorized printing of indicia.

The SMD receives and validates the request message, at a step 5154. The SMD accepts a request to perform an Indicium transaction if it is in an Initialized or Registered state. This determination is performed at a step 5156. If the SMD receives a request to perform an Indicium transaction and is not in the Initialized or Registered state, the SMD sends an error message, at a step 5158, and the transaction terminates.

Otherwise, the SMD determines whether the requested indicium value is within predetermined minimum and maximum limits, at a step 5160. If the requested indicium value is outside these limits, the SMD sends an error message, at a step 5162, and the transaction terminates. Otherwise, the SMD examines its revenue registers to determine whether sufficient funds exist to cover the requested indicium value, at a step 5164. If the funds are insufficient, the SMD sends an error message, at a step 5166, and the transaction terminates.

If sufficient funds exists, the SMD updates its revenue registers to account for the requested indicium value, at a step 5180, and generates the indicium, at a step 5182. The SMD then generates a message that includes the indicium, signs the message using the SMD's private key, and sends the signed message to the host PC, at a step 5184.

The host PC verifies the signed message and directs printing of the indicium, at a step 5186. The host PC may also update the display to reflect the current available funds. Also, if an error message is received during the Indicium transaction, the host PC displays the error message to inform the user (i.e., that insufficient funds exist).

Audit transaction: The SMD includes a timer (also referred to as a "Watchdog Timer") that allows it to perform services for a predetermined period of time. An Audit transaction is performed periodically to reset the timer, giving the SMD more time to operate before the timer times out. If the timer times out before an Audit transaction is performed, the SMD transitions to the Timed-Out operating state and no further operation (except for an Audit transaction) is permitted. The provider may also obtain the status of the SMD by initiating the Audit transaction. The following is a specific implementation of the Audit transaction, and other implementations are available.

FIGS. 5F and 5F-2 show a flow diagram of an embodiment of the Audit transaction. At a step 5200, the user requests, via the host PC, an audit of the SMD. This may be motivated by the SMD transitioning into the Timed-Out state. In response, the host PC sends the SMD an audit request message, at a step 5202. In a specific implementation, this request message is not signed using the provider's private key, and anyone with access to the host PC can request an audit. However, safeguards can be included in the host PC software (i.e., through the use of a password) to prevent unauthorized audit requests.

The SMD accepts a request to perform an Audit transaction if it is in a Registered or Timed-Out state. This determination is performed at a step 5204. If the SMD receives a request to perform an Audit transaction and is not in the Registered or Timed-Out state, the SMD sends an error message, at a step 5206, and the transaction terminates.

Otherwise, the SMD saves its current operating state, at a step 5210, and transitions to an intermediate state, at a step 5212. The SMD then sends the host PC a signed message that includes the required information, at a step 5214. The required information may include, for example, the current contents of the secure revenue registers, the device ID number, the current date and time, a transaction serial number generated by the SMD, and other information. The host PC receives and forwards the signed message to the system server, at a step 5216.

The system server receives and validates the message, at a step 5218. As part of the processing, the system server authenticates the signed message using the SMD's public key and analyzes the data included in the message. The system server then sends the host PC a signed message that includes the response data, at a step 5220. This response data includes, for example, the same device ID and transaction number from the message received earlier.

The host PC receives and forwards this signed message to the SMD, at a step 5222. The SMD receives and validates the message, at a step 5224. The validation of the signed message includes verification of the signature and determination of whether the message is of the expected type, at a step 5226. If the signature is invalid or the message is not of the expected type, the SMD sends an error message, at a step 5230, and transitions back to the previously saved state, at a step 5232. The transaction then terminates.

Otherwise, if the signature is valid and the message is of an expected type, the SMD determines if the data contents of the message is correct, at a step 5234. This may include, for example, verification that transaction serial number in the received message is the same as the number forwarded by the SMD earlier. If the data is not valid, the SMD proceeds to step 5230 and sends an error message. Otherwise, if the data is valid, the SMD resets the Watchdog Timer, at a step 5236, and transitions to the Registered state, at a step 5238. The SMD then sends the host PC, at a step 5240, a confirmation message that indicates a successful Audit transaction. The host PC may update the display to inform the user of the amount of time remaining before the next audit transaction is required, or to inform the user that the SMD is now available for use (if it was in a Timed-Out state). The transaction then terminates.

Withdrawal transaction: Once the SMD has been authorized to a particular user's account, it functions on behalf of that account only. This means that when the SMD is funded, that customer's account at the provider is debited the amount of the funding (plus any associated service charges). If that SMD is to be reused on a different account, it is withdrawn from its present account and re-authorized for the new account. The following is a specific implementation of the Withdrawal transaction, and other implementations are available.

FIGS. 5G and 5G-2 show a flow diagram of an embodiment of the Withdrawal transaction. At a step 5231, the user requests, via the host PC, a withdrawal of the SMD. In response, the host PC sends the SMD a withdrawal request message, at a step 5233. In a specific implementation, this request message is not signed using the provider's private key, and anyone with access to the host PC can request a withdrawal. However, safeguards can be included in the host PC software (i.e., through the use of a password) to prevent unauthorized withdrawal of the SMD.

The SMD accepts a request to perform a Withdrawal transaction if it is in a Registered state. This determination is performed at a step 5235. If the SMD receives a request to perform a Withdrawal transaction and is not in the Registered state (i.e., if the inquiry at step 5235 is No), the SMD sends an error message, at a step 5237, and the transaction terminates.

Otherwise, the SMD transitions to an intermediate state, at a step 5239. The SMD then sends the host PC a signed message that includes the required information, at a step 5241. The required information may include, for example, the current contents of the secure revenue registers, the device ID number, a transaction serial number generated by the SMD, and other information. The host PC receives and forwards the signed message to the system server, at a step 5243.

The system server receives and validates the message, at a step 5245. As part of the processing, the system server authenticates the signed message using the SMD's public key and analyzes the data included in the message. The system server then sends the host PC a signed message that includes the response data, at a step 5247. This response data include, for example, the same device ID and transaction number from the message received earlier. This message authorizes the SMD to withdraw from service.

The host PC receives and forwards this signed message to the SMD, at a step 5249. The SMD receives and validates the message, at a step 5250. The validation of the signed message includes verification of the signature and determination of whether the message is of the expected type, at a step 5252. If the signature is invalid or the message is not of the expected type, the SMD sends an error message, at a step 5254, and transitions back to the previously saved state, at a step 5256. The transaction then terminates.

Otherwise, if the signature is valid and the message is of an expected type, the SMD determines if the data content of the message is correct, at a step 5258. This may include, for example, verification that transaction serial number in the received message is the same as the number forwarded by the SMD earlier. If the data is not valid, the SMD proceeds to step 5254 and sends an error message. Otherwise, if the data is valid, the SMD sends the host PC, at a step 5260, a message that indicates a change in operating state. The SMD then transitions to the Initialized state, at a step 5262. The host PC may update the display to inform the user that the SMD is no longer available for service.

For simplicity, for the transactions described in the above figures, the interactions between the SMD, host PC, and system server are conducted through the passing of a single message for each step. However, in actual implementations, multiple messages may be exchanged between these elements for a particular step.

Other transactions: Additional services can be obtained from the SMD in the user role. These services do not effect SRDIs and do not require role validation. They are obtained when an entity operating in the user role requests the service from the host PC. The host PC and SMD engage in a transaction that provides the requested service.

The Self Test transaction is initiated by the host PC, upon request by the user, by sending a SELF TEST message to the SMD. The SMD responds by performing its self tests and sending the results to the host PC in a SELF TEST RESPONSE message. The details of the self tests are described below. The Self Test transaction can be performed while the SMD is in any operating state. The Self Test transaction does not alter the contents of any of the SRDIs. In a specific implementation, the SELF TEST message allows one or more of the following tests to be selected:

CPU Self Test;

Volatile Memory Self Test;

Cryptographic Algorithm Test;

Firmware Test;

RTC Test;

Random Number Generator Tests; and

SRDI Signatures Test.

The Adjust RTC transaction allows the user to adjust the time of a real-time clock (RTC) to account for errors in the clock rate. The errors may accumulate over time, as well as due to changes to and from Daylight Savings Time, and so on. An Adjust RTC transaction may occur at any time. In a specific implementation, no more than a predetermined number of adjustments may be made during a predetermined time period (e.g., up to two adjustments in any single 30-day period).

The Get X.509 Certificate transaction allows the user to read the contents of any of the three (e.g., CA, provider, and SMD) X.509 certificates stored in the SMD's non-volatile memories.

The Enable, Disable, and Configure Auxiliary Serial Port transactions allow the user to connect the host PC to an external device via the SMD's auxiliary serial port.

SMD Security

The SMD operates in accordance with a predetermined set of security rules designed to discourage, prevent, and detect fraud. The rules are also designed to protect the contents of the SRDIs from fraud and component failure. In a specific implementation, the following rules apply to the SMD.

The SMD retains each of the SRDIs in a location in a non-volatile memory. Generally, the SRDIs defines the current operating state of the SMD, which is also referred to as the "State." Certain transactions as noted herein change the operating state of the SMD.

If the SMD detects an unauthorized change to any of the SRDIs, the SMD enters the Faulted state.

The SMD does not exit the Faulted state until an Inspection transaction is performed. The SMD does not perform any transaction, other than an Inspection transaction, which can alter any of the SRDIs while in the Faulted state.

The SMD initializes a Fraud counter to zero during an Audit transaction.

The SMD increments the Fraud counter each time a signature verification fails during a transaction. If the value in the Fraud counter exceeds a predetermined value (e.g., 50), the SMD enters the Faulted state.

In a specific implementation, the SMD accepts request messages from the host PC and provides response messages to the host PC via the main port only. This implementation provides additional security. The auxiliary port is used to transfer data between the host PC and external device(s) coupled to the auxiliary port. The SMD does not interpret the data streams received from, or sent to the auxiliary port. The SMD also does not output or receive the contents of any of the SRDIs via the auxiliary port.

CPU and Volatile Memory Self Tests: Each time the SMD is powered up, it performs a series of operations designed to test security and determine the current operating state. In a specific implementation, the following tests are performed each time the SMD is powered up: CPU and Volatile Memory Self Tests, Cryptographic Module Self Tests, and Basic Security Check. Greater, fewer, or different tests than those listed above can be performed by the SMD, and this is within the scope of the invention. The following describes a specific implementation for each of the tests, but it can be noted that other implementations can be achieved and are within the scope of the invention.

CPU and Volatile Memory Self Tests: The SMD performs the CPU and Volatile Memory Self Tests to determine if the basic facilities of the CPU and volatile memories are functional. A firmware performs the CPU and memory self tests each time the SMD is powered up. The CPU self test is performed before the memory self test is performed. The CPU and memory self tests are performed before other power-up self tests are performed.

Since the CPU is used to test itself, it may not be practical to determine if the CPU is in fact functional. However, it is possible to determine if the CPU is not functional in certain aspects. In one implementation, the firmware verifies that the CPU properly determines that two internally stored identical strings of length 128 bytes or greater are in fact identical. The firmware also verifies that the CPU properly determines that two internally stored non-identical strings of length 128 bytes or greater are in fact not identical. If either of these tests fails, the SMD enters the Faulted state.

The firmware performs a test of the volatile (e.g., RAM) memory devices accessible by the CPU. The test alternately writes and reads bit patterns to verify the integrity of each memory location. The patterns are designed ensure that all bits are capable of changing state, and that each memory location is capable of storing one and zero. If any of these tests fail, the SMD enters the Faulted state.

Cryptographic Module Self Tests: The SMD performs the Cryptographic Module Self Tests to verify the proper operation of the cryptographic module. In a specific implementation, the following self tests are performed each time the SMD powers up: Cryptographic Algorithm Test, Firmware Test, Critical Functions Test, and Statistical Random Number Generator Tests.

For the Cryptographic Algorithm Test, the SMD performs a "known-answer" test in which the cryptographic module generates a signature on an internally stored data field and compares the generated signature with a reference signature stored in memory. If the two signatures match, the test passes. If the signatures do not match, the test fails and the SMD enters the Faulted state.

For the Firmware Test, the SMD verifies the signature of the contents of the program memory. (EPROM, ROM, etc.). If the signature is invalid, the SMD enters the Faulted state.

For the Critical Functions Test, the SMD verifies the proper operation of the Real Time Clock (RTC) by comparing its rate against a predetermined independent standard. Such a test employs a firmware loop having an execution time that is known a priori and is based on, for example, the CPU's crystal frequency. The loop may be executed a predetermined number of times, and the RTC may be checked before and after executing the loop to determine if the RTC has advanced the expected amount. If the RTC is not accurate within a predetermined range (e.g., .+-.0.05%, or approximately 4.5 hours/year), the SMD enters the Faulted state.

The Statistical Random Number Generator Tests may be made available as part of the support firmware provided with the cryptographic module. In this case, SMD executes these tests upon power up, and if any such tests fail, the SMD enters the Faulted state.

Basic Security Check: Upon power up and after performing the CPU, memory, and cryptographic self tests, the SMD perform the Basic Security Check to determine if the contents of the non-volatile memories are valid. The Basic Security Check includes a series of tests. First, the SMD checks the signature on the SRDIs stored in non-volatile memory that is external to the cryptographic module. If any signatures do not verify, the SMD enters the Faulted state. The SMD also checks the CRC or checksum on the SRDIs stored in non-volatile memory that is located inside the cryptographic module. If the CRC or checksum does not verify, the SMD enters the Faulted state.

Digital Signature: In a specific implementation, the SMD employs the digital signature algorithm (DSA) to sign all messages that include SRDIs to be reported to external devices. Such messages are signed using the SMD's private key. The SMD also employs DSA to verify signature on all messages that include SRDIs to be written to the SMD's non-volatile memories.

The SMD's private key is generated during factory initialization, stored inside the cryptographic module, and is not accessible by any means without leaving evidence of tampering. During factory initialization, when the SMD generates a public/private key pair, the SMD tests the key pair using a pair-wise consistency test. This test is defined in section 4.11.2 of a document entitled "Security Requirements for Cryptographic Modules, Federal Information Processing Standards Publication 140-1" (also referred to as FIPS 140-1). If the keys fail the test, a new set of keys is generated and tested. If after a predetermined number of (e.g., three) successive sets of keys are generated and failed the test, the SMD aborts the key generation function and informs the FIT of the error. The SMD's private key is not made available via any communications port or by any other means.

In a specific implementation, the SMD does not sign (using the SMD's private key) externally generated data received via either the main or auxiliary port, unless that data was received in a valid transaction under signature from the provider's and only after the SMD has verified the signature using its internally stored version of the provider public key. This implementation of inhibiting the SMD from signing externally generated data prevents an entity from sending a "phony" indicium to the SMD, getting the SMD to sign and return it, and printing that indicium, thereby defrauding the provider in a manner that may be difficult to detect or prove.

In an embodiment, each time the cryptographic module uses the random number generator to generate a digital signature, the cryptographic module performs the continuous random number generator test as specified in the above-referenced FIPS 140-1, section 4.11.2.

Security Relevant Data Items: In accordance with an aspect of the invention, security relevant data items (SRDIs) are maintained within the SMD's tamper-evident enclosure. The SRDIs include revenue registers and other registers. The revenue registers refer to data items (stored in the SMD's memories) that are required to determine the amount of revenue remaining in the SMD. These items include, for example, the Ascending and Descending registers, the Fault Code, the Fraud counter, and the SMD operating state.

In a specific implementation, at least two copies of the revenue registers are stored inside the SMD's tamper-evident enclosure. The storage redundancy allows for recovery of at least one set of revenue registers should the other set be damaged by component failure, power failure, fraud, or tampering.

In an embodiment, each copy of the revenue registers is stored in a different physical memory device from the other copy, and uses a different power source if power is used to maintain such memory. One such copy may be stored inside the cryptographic module, if such module includes sufficient non-volatile memories. The values saved in this module can be retrieved by requesting a Status transaction. The Status transaction data is signed using the SMD's private key, and the signature is included with the data delivered in the transaction. The Status transaction is available in all operating states, including the Faulted state.

In a specific implementation, the cryptographic module comprises a single chip CPU/Cryptographic Processor that includes an on-chip battery backed-up RAM memory (BBRAM) that stores one copy of the revenue registers. The device that stores the second copy of the revenue registers can be a Flash memory device located inside or outside the cryptographic module. This memory can be coupled to the cryptographic module via a microcomputer bus. In such a configuration, the factory is able to read the revenue registers and signature by using a specially designed test device that clips onto the leads of the Flash component and reads it directly.

If a copy of the revenue registers is stored inside the cryptographic module, several effective means are available for the SMD to verify the integrity of the registers before they are used. One such means is the use of a digital signature. An alternative means is the use of a (e.g., 16-bit) CRC or checksum, which is a faster mechanism and may be adequate since the copy of the revenue data is stored in the cryptographic module itself and risks of tampering are reduced. The SMD periodically checks the checksum or CRC of the revenue registers stored inside the cryptographic module. This check is performed on power-up, before accepting a request to perform an Indicium or Funding transaction, and periodically within a predetermined time period (e.g., at least once per hour) while power is applied and no transactions have been requested. If the checksum or CRC is found to be invalid, the SMD enters the Faulted state, unless the FIT flag is installed in which case the SMD enters the Uninitialized state.

The copies of the revenue registers can also be stored in devices located outside the cryptographic module. In a specific implementation, each copy of the revenue registers stored in a device outside the cryptographic module is stored "in the clear" and signed using the SMD's private key. The signature is also stored in the same device that stores the revenue registers. Each memory device outside the cryptographic module that stores revenue registers is readable by an external means at the factory, after removing the tamper-evident enclosure. The SMD periodically checks the signature on the revenue registers stored external to the cryptographic module. This check is performed on power-up, after each Indicium or Funding transaction, and periodically within a predetermined time period (e.g., at least once per hour) while power is applied and no transactions have been requested. If the signature is found to be invalid, the SMD enters the Faulted state.

The SMD maintains an SRDI called a real time clock (RTC), from which it obtains the current date and time for inclusion in messages and for other functions. The RTC is initialized while the SMD is in the Initialized state with the FIT flag installed. Under these circumstances, any value may be written to the RTC. The RTC may be changed by a command from the user to correct for accumulated clock error, daylight savings time, and so on. The RTC may be changed up to a predetermined amount (e.g., no more than .+-.5 hours) and up to a predetermined number of time (e.g., no more than three times) per audit period.

The SMD maintains a date, stored in non-volatile memory, called the Watchdog Timer. The use of the Watchdog Timer forces the user to request periodic audits of the SMD. The audits allow the provider to monitor the status of the SMD's revenue registers and determine if any attempt to defraud the SMD has occurred. The time between audits is set during the Registration transaction, and is stored in the SMD's non-volatile memory.

The Watchdog Timer is an SRDI that is initialized during the Registration transaction. The SMD checks the RTC each time it powers up, and one or more times per day during normal operation, to determine if the RTC has counted past the Watchdog Timer. If the RTC contains a date that is greater than that of the Watchdog Timer, the SMD transitions to a Timed-Out state and does not perform any transaction (except for an Audit transaction) that can change any of the SRDIs. The SMD also includes, in non-volatile memory, an SRDI called a Watchdog Increment that contains the number of days to be added to the Watchdog Timer after a successful Audit transaction.

The SMD remains in the Timed-Out state until receipt of a Device Audit field as specified in the document entitled "Information Based Indicia Program, Postal Security Device Specification," USPS Engineering Center. The SMD verifies the signature on the Device Audit field using the provider's public key included in the Provider X.509 certificate that is loaded during factory initialization. Upon verification of the signature, the SMD adds a constant to the Watchdog Timer and transitions out of the Timed-Out state. The SMD is then able to perform transactions that affect the revenue registers. The value that is added to the timer is obtained from the Watchdog Increment stored in the SMD memory during the Registration transaction.

Exhibit E lists the various SRDIs and their description, definition, and structure. This reflects a specific implementation of the SRDIs for the SMD. Exhibit E also tabulates the transactions used to access the various SRDIs.

Messages and Transactions

As used herein, a message is a basic unit of Application Level data exchanged between the SMD, host PC, and system server. Messages are communicated using a reliable transport mechanism that transmits and receives messages on (e.g., asynchronous serial) communications channels. One such transport mechanism is an asynchronous data-link protocol disclosed in the aforementioned U.S. Patent provisional Application Serial No. 60/075,934. In an embodiment, a message includes a field for identifying a Message Type code followed by a field of zero or more bytes of Message Data (i.e., 0 to N bytes of 8-bit data). In a specific implementation, when the Message Data field includes a data item having more than one byte, the data item is sent with the most significant byte first, followed by successively less significant bytes.

In an embodiment, messages are typically exchanged in a group that makes up a transaction. A transaction may cause the SMD to print indicia, increase the amount of the stored revenue, report status, withdraw from service, and so on. The host PC typically initiates a transaction, and does so by sending a request message to the SMD. The SMD replies with a response message.

While the host typically initiates transactions, the SMD may send unsolicited status and error messages to the host PC. For example, the SMD may send a STATECHG or ERROR message, or both, based on conditions detected by the SMD. This may occur, for example, when a security threat is detected by the SMD and the SMD transitions to the Faulted state, or when the SMD's internal Watchdog Timer times out and the SMD transitions to the Timed-Out state.

As can be seen from FIG. 6A, various transactions are performed to transition between, and within the operating states. Some of these transactions are described below using state diagrams. Each state diagram shows a particular transaction between the operating states shown in FIG. 6A, and may be substituted into FIG. 6A in place of a corresponding transaction arrow.

In the following state diagrams, a transition between operating states occurs upon receipt of a message from the host PC. The solid lines represent these transitions. For many such transitions, a response message is sent by the SMD to the host PC. The response message is shown by a dotted line leaving a circle attached to the solid transition line, with an arrow terminating the dotted line in space.

The following state diagrams describe which transition to take when a message is processed "properly" or processed "erroneously." In an embodiment, a message is processed properly if the message was received in an appropriate state, and all signatures, transaction ID numbers, or other checks were performed without error and as expected. A message is deemed to have been processed erroneously if the message was received in an inappropriate state, or the signatures, transaction ID numbers, or other checks were in error or not as expected. Where ambiguities arise, the description for the message (see Exhibit A) specifies which result constitutes proper processing and which result constitutes erroneous processing.

In a specific implementation, transactions are performed in accordance with following set of rules:

1) The SMD only process messages that are appropriate for its current operating state. Exhibit C lists messages that are appropriate for each operating state.

2) If the host PC sends the SMD a message that is inappropriate for the SMD's current operating state, the SMD ignores (not process) the message and responds by sending to the host PC an ERROR message that includes an error code of BAD_STATE. For example, the SMD does not process a message to print an indicium when it is in the Uninitialized state.

3) If the SMD is in the Faulted state, it does not process any messages that would alter any of the SRDIs, or would cause a state change to a state that may process messages that could alter any of the SRDIs.

4) If power is removed from the SMD after a transaction begins but before it is complete, the transaction is canceled. When power is reapplied, the SMD returns to the operating state it previously occupied before the transaction began.

The following FIGS. 6B-6G describes specific implementations of the Initialization transaction, the Registration transaction, the Funding transaction, the Indicium transaction, the Audit transaction, and the Withdrawal transaction, respectively. In these figures, only the communication between the SMD and the host PC is described, for clarity. The interactions between the SMD, host PC, and system server for these transactions are described above in reference to FIGS. 5B, 5C, 5C-2, 5D, 5D-2, 5E, 5E-2, 5F, 5F-2, 5G, and 5G-2. Moreover, the descriptions of the messages passed between the SMD and host PC (given in Exhibits A and B) also provide additional details of these transactions.

FIG. 6B shows a state diagram of a specific implementation of the Initialization transaction. An SMD in the Uninitialized state performs the Initialization transaction to initialize the SMD. In an embodiment, the Initialization transaction causes the SMD to generate a pair of public and private keys. The SMD retains the private key in secrecy, and exports the public key to the host PC.

The Initialization transaction begins when the host PC sends an INIT1 message to the SMD. The SMD only accepts the INIT1 message while in the Uninitialized state. Otherwise, the SMD remains in the Uninitialized state and replies to the INIT1 message with an ERROR message that includes an error code or BAD_STATE. The SMD processes the INIT1 message according to the directions included in the message's description. This processing includes verification of the signature of the INIT1 message. Upon successful completion of that processing, the SMD generates an INIT2 message that includes the public key and sends the message to the host PC. The SMD then transitions to the Initialized state.

FIG. 6C shows a state diagram of a specific embodiment of the Registration transaction. In an embodiment, an Initialized SMD is not licensed to any user and cannot generate indicia. Registration is the process of licensing the SMD to a particular user and installing the SMD at the user's site. In an embodiment, only an Initialized SMD may be registered.

The Registration transaction begins when the host PC sends a REGISTER1 message to the SMD. The SMD only accepts the REGISTER1 message while in the Initialized or Registered state. Otherwise, the SMD does not change state and replies to the REGISTER1 message with an ERROR message that includes an error code of BAD_STATE; and the Registration transaction terminates.

If the SMD receives the REGISTER1 message while in the Initialized or Registered state, it processes the REGISTER1 message according to the directions included in the message's description. This processing includes verification of the signature of the REGISTER1 message. If the REGISTER1 message is processed without error, the SMD generates a REGISTER2 message, sends it to the host PC, and transitions to an Register-Intermediate state 632. Otherwise, if an error occurs during the processing of the REGISTER1 message, the SMD does not change state and sends the host PC an error reply according to the directions included in the message's description. The error reply includes an error number that the host PC converts to an error message to be displayed.

If the SMD is in the Registered-Intermediate state and a REGISTER3 message is received, the SMD processes the message according to the directions included in the message's description. If the message is processed without error, the SMD generates a STATECHG message, sends this message to the host PC, and transitions to the Registered state. Otherwise, if an error occurred during processing of the REGISTER3 message, the SMD transitions to the state it occupied before the start of the Registration transaction and sends the host PC an error reply according to the directions included in the message's description. If the SMD is in the Registered-Intermediate state and any message other than a REGISTER3 message is received, the SMD transitions to the state it occupied before the start of the Registration transaction and sends the host PC an ERROR message that includes an error code of MSG_INVALID.

The Registration transaction terminates when the SMD transitions to the Registered state (upon sending the STATECHG message). The Registration transaction also terminates when the SMD sends the host PC an error reply in response to an error during processing of the REGISTER1 or REGISTER3 message.

FIG. 6D shows a state diagram of a specific embodiment of the Funding transaction. A Registered SMD is not able to dispense indicia unless the revenue registers contain adequate revenue. The Funding transaction is performed to fund the SMD, and may be initiated when the user decides to add additional funds. The host PC may also query the user to initiate the Funding transaction, for example, when it is determined that the SMD revenue has fallen below a predetermined threshold.

The Funding transaction begins when the host PC sends a FUND1 message to the SMD. In an embodiment, the SMD only accepts a FUND1 message while in the Registered state. Otherwise, the SMD does not change state and replies to the FUND1 message with an ERROR message that includes the BAD_STATE error code; and the Funding transaction terminates.

If the SMD receives a FUND1 message while in the Registered state, it processes the FUND1 message according to the directions included in the message's description. This processing includes verification of the signature of the FUND1 message. If the FUND 1 message is processed without error, the SMD generates a FUND2 message, sends it to the host PC, and transitions to a Funding-Intermediate state 636. Otherwise, if an error occurs during processing of the FUND1 message, the SMD does not change state and sends the host PC an error reply according to the directions included in the message's description.

If the SMD is in the Funding-Intermediate state and a FUND3 message is received, the SMD processes the message according to the directions included in the message's description. This processing includes verification of the signature of the FUND3 message. If the message is processed without error, the SMD generates a FUND4 message, sends this message to the host PC, and transitions to the Registered state. Otherwise, if an error occurred during processing of the FUND3 message, the SMD transitions to the state it occupied before the start of the Funding transaction and sends the host PC an error reply according to the directions included in the message's description.

If the SMD is in the Funding-Intermediate state and a FUND5 message is received, the SMD processes the message according to the directions included in the message's description. If the message is processed without error, the SMD generates a STATECHG message, sends this message to the host PC, and transitions to the Registered state. Otherwise, if an error occurred during processing of the FUND5 message, the SMD transitions to the Registered state and sends the host PC an error reply according to the directions included in the message's description.

If the SMD is in the Funding-Intermediate state, one of several possible events can occur. If any message other than a FUND3 or FUND5 message is received, the SMD transitions to the Registered state and sends the host PC n ERROR message that includes an error code of MSG_INVALID. Also, if a FUND3 or FUND5 message is received with an invalid signature, the SMD transitions to the Registered state and sends the host an ERROR message that includes an error code of SIG_INVALID. If a FUND5 message is received and the Fraud counter in the SMD exceeds a predetermined limit, the SMD transitions to the Faulted state.

The Funding transaction terminates when the SMD sends the FUND4 or STATECHG message in response to a successful Funding transaction. The Funding transaction also terminates when the SMD sends the host PC an ERROR message in response to (1) an error occurred during processing of the FUND1, FUND3, or FUND5 message, or (2) receiving messages other than the FUND3 or FUND5 message while in the Funding-Intermediate state.

FIG. 6E shows a state diagram of a specific embodiment of the Indicium transaction. The SMD dispenses an indicium to the host PC for the Indicium transaction. The Indicium transaction begins when the host PC sends an INDICIUM1 message to the SMD. The SMD only accepts the INDICIUM1 message while in the Initialized or Registered state. Otherwise, the SMD does not change state and replies to the INDICIUM1 message with an ERROR message that includes an error code of BAD_STATE; and the Indicium transaction terminates.

If the SMD receives the INDICIUM1 message while in the Registered or Initialized state, it processes the INDICIUM1 message according to the directions included in the message's description. If the INDICIUM1 message is processed without error, the SMD generates an INDICIUM2 message and sends it to the host PC. Otherwise, if an error occurs during processing of the INDICIUM1 message, the SMD sends the host PC an error message according to the directions included in the message's description. In either case, the SMD does not change state and the Indicium transaction terminates.

In an embodiment, the Audit transaction is performed periodically, either manually by the user or automatically with each Funding transaction, or both. If the user does not initiate a Funding transaction or an Audit transaction is not performed within the time-out period, the SMD times out and initiates a lock sequence that prevents further indicium printing. In a specific implementation, the time-out period is 90 days, although other time periods can be used and are within the scope of the invention.

FIG. 6F shows a state diagram of a specific embodiment of the Audit transaction. The Audit transaction is used to inform the system server the current operating state of the SMD. The Audit transaction begins when the host PC sends an AUDIT1 message to the SMD. The SMD only accepts the AUDIT1 message while in the Registered or Timed-Out state. Otherwise, the SMD does not change state and replies to the AUDIT1 message with an ERROR message that includes an error code of BAD_STATE; and the Audit transaction terminates.

If the SMD receives the AUDIT1 message while in the Registered or Timed-Out state, it processes the AUDIT1 message according to the directions included in the message's description. If the AUDIT1 message is processed without error, the SMD generates an AUDIT2 message and sends it to the host PC. The SMD then transitions to an Audit-Intermediate1 state 640 if the AUDIT1 message was received while in the Registered state, or to an Audit-Intermediate2 state 642 if the AUDIT1 message was received while in the Time-Out state. Otherwise, if an error occurs during processing of the AUDIT1 message, the SMD does not change state and sends the host PC an error message according to the directions included in the message's description.

If the SMD is in either Audit-Intermediate state and any message other than an AUDIT3 message is received, the SMD transitions to the state it occupied before the start of the Audit transaction and sends the host PC an ERROR message that includes n error code of MSG_INVALID. If the SMD receives an AUDIT3 message while in either Audit-Intermediate state, the SMD processes the message according to the directions included in the message's description. If the message is processed without error, the SMD generates a STATECHG message, sends this message to the host PC, and transitions to the Registered state. Otherwise, if an error occurred during processing of the AUDIT3 message, the SMD transitions to the state it occupied before the start of the Audit transaction and sends the host PC an error reply according to the directions included in the message's description.

The Audit transaction terminates when the SMD sends the STATECHG message in response to a successful Audit transaction. The Audit transaction also terminates when the SMD sends the host PC an ERROR message in response to an error during processing of the AUDIT1 or AUDIT3 message.

FIG. 6G shows a state diagram of a specific embodiment of the Withdrawal transaction. The Withdrawal transaction is used to remove a Registered SMD from service. The Withdrawal transaction begins when the host PC sends a WITHDRAW1 message to the SMD. Upon receipt of this message, the SMD checks its internal state counter to verify that it is in the Registered state. If it is not in the Registered state, the SMD does not change state and sends the host PC an ERROR message that includes an error code of BAD_STATE; and the Withdrawal transaction terminates.

If the SMD receives the WITHDRAW1 message while in the Registered, it processes the WITHDRAW1 message according to the directions included in the message's description. If the WITHDRAW1 message is processed without error, the SMD generates a WITHDRAW2 message and sends it to the host PC. The SMD then transitions to a Withdrawal-Intermediate state 646. Otherwise, if an error occurs during processing of the WITHDRAW1 message, the SMD does not change state and sends the host PC an error message according to the directions included in the message's description.

If the SMD receives a WITHDRAW3 message while in the Withdrawal-Intermediate state, the SMD processes the message according to the directions included in the message's description. If the message is processed without error, the SMD generates a STATECHG message, sends this message to the host PC, and transitions to the Initialized state. Otherwise, if an error occurred during processing of the WITHDRAW3 message, the SMD transitions to the Registered state and sends the host PC an ERROR message.

The Withdrawal transaction terminates when the SMD sends the STATECHG message in response to a successful Withdrawal transaction. The Withdrawal transaction also terminates when the SMD sends the host PC an ERROR message in response to an error during processing of the WITHDRAW1 or WITHDRAW3 message.

Message Definition and Structure

In an embodiment, each application level message includes an 8-bit Message Type code followed by a message body. The Message Type code identifies each message to the recipient. The message body includes data as required by the SMD or host PC to process the message. The length of the message body depends on the particular message. The overall message length stated in the message descriptions includes the length of the message type code and the message body. It is the total length of the "variable length Application Level packet" that is sent by the transmission level protocol.

The following describes a specific implementation. All byte addresses within a message are relative to the beginning address of the message. For example, the first byte of the message is address 0.times.0000, the next byte is 0.times.0001 and so on. Unless otherwise indicated, all message fields are transmitted with the more significant digits in the lower relative byte addresses. Successively lower significant digits are transmitted in increasing relative byte addresses. BCD (binary coded decimal) encoded data contains the high order digit in the high order nibble of a byte, and the next lower order digit in the low order nibble of the byte. Leading zeros are used to pad a BCD field to the size indicated. For example, the BCD encoded number 12345 is transmitted in 3 bytes as follows: 0.times.01, 0.times.23, 0.times.45. Also, unless otherwise specified, fields containing alphanumeric data are transmitted with the left most character in the string appearing in the lowest relative byte address, and with successive characters to the right in successively increasing relative addresses.

The ability of the SMD to process a particular message depends on the current state of the SMD. The allowable states for each message are given in Exhibit C. If a message is received while the SMD is in an operating state that is inappropriate for processing the message, the SMD responds by sending the host PC an ERROR message that includes an error code of BAD_STATE.

Exhibit A lists the messages and their description, definition, and structure. Exhibit C summarizes the definition and structure of the messages. Exhibit C lists the messages that can be processed by the SMD for each of the operating states. And Exhibit D lists and defines the parameters for the messages.

Data Link Protocol

In an embodiment, a Data Link protocol provides reliable transfer of Application Level messages between the SMD and host PC. The protocol functions to convey messages in an error-free manner with no duplication of messages and with each message received in the order as transmitted. The protocol does not interpret the meaning of the transmitted message.

In an embodiment, data and messages are transferred between the SMD and host PC in the form of "packets" by the Data Link protocol. A packet is a unit of communication reliably transmitted or received by the Data Link protocol. Packets may include messages that are interpreted by the SMD Application Level protocol. The Data Link protocol does not interpret the meaning of the of the message included within the packets. The interpretation of the message is handled by the software described in aforementioned U.S. provisional patent application Serial Nos. 60/075,934 and 60/074,947. In an embodiment, proper reception of packets is ensured by checking the CRC appended to each packet, and packets that are improperly received are retransmitted.

In an embodiment, a packet has the general structure shown in Table 2. 

                             TABLE 2
                          Packet Format
          Packet Field                       Length
          SOH                                1 Byte
          Packet ID                          1 Byte
          Reserved                           1 Byte
          Message Length MSB                 1 Byte
          Message Length LSB                 1 Byte
          Variable Length               0 to 65535 Bytes
          Application Level Message
          CRC MSB                            1 Byte
          CRC LSB                            1 Byte


The SOH field forms the first byte of a packet and comprises the ASCII SOH character having a value of 0.times.0.

The Packet ID field is used by the host PC and SMD to keep track of packets that are sent and received. In an embodiment, this field is partitioned into two 4-bit nibbles, a most significant nibble (MSN) and a least significant nibble (LSN). The LSN includes the serial number of the packet being sent, and the MSN includes the serial number of the packet being received. Before sending a packet, the sender loads the serial number of the packet to be sent into the LSN of the Packet ID field, and loads the serial number of the last packet received from the packet's recipient into the MSN of the Packet ID field. The Packet ID field is further described below.

The Reserved field is a reserved byte for future use. The SMD and host PC transmit a value of 0.times.00 in this field unless otherwise specified in future versions of the protocol.

The Message Length fields are used to identify the length of the Application Level messages. These fields include a count of all bytes from the start of the message, up to and including the last byte of the message. The count does not include the lengths of the SOH, Packet ID, Message Length, or CRC fields (as these fields are of fixed lengths and are part of each message). The message may be of zero length. The Message Length MSB includes the high order 8 bits of the message length and the Message Length LSB includes the low order 8 bits of the message length.

The Variable Length Application Level Message field is a variable length string of bytes. This field may be absent, depending on the type of packet. The format and definition of the message are interpreted by the Application Level protocol described in the aforementioned U.S. provisional patent application Serial Nos. 60/075,934 and 60/074,947. Messages can vary in length from 0 to 65535 bytes. In actual implementation, the maximum length is typically less. The maximum length that is supported by the SMD is also specified in the aforementioned U.S. provisional patent application Serial Nos. 60/075,934 and 60/074,947.

The CRC fields includes two bytes that provide an integrity check of the packet. In a specific embodiment, the CRC fields include a 16-bit cyclic redundancy check (CRC) using, for example, the CCITT standard polynomial: X.sup.16 +X.sup.12 +X.sup.5 +1. The CRC can be calculated by various standard methods that are known in the art. This CRC identifies all single and double bit errors, all errors with an odd number of bits, all burst errors of length 16 or less, 99.997 percent of 17-bit error bursts, and 99.998% of 18-bit and longer error bursts. In an embodiment, the CRC applies on all fields of the packet, including the Packet ID, Message Length, and (all bytes of the) Message fields, but excluding the SOH and CRC fields.

The Packet ID field is used by the Data Link protocol to determine whether or not a packet has been properly transmitted or received. It includes two nibbles, each of which includes a serial number referring to a packet. The sender or recipient can examine the byte to determine if the other side had received the last transmission properly, or to determine if a newly received packet includes a new Application Level message or is a retransmission of an old message.

In an embodiment, each device (e.g., SMD and host PC) maintains local storage of a 4-bit nibble called the Transmitted Serial Number (TXSN). Each device also maintains local storage of a 4-bit nibble called the Received Serial Number (RXSN). A device increments its TXSN before sending a packet that includes a new Application Level message. After incrementing the TXSN, the transmitting device loads this TXSN value into the LSN of the Packet ID field of the outgoing packet. TXSN is not incremented before retransmitting a packet that includes a previously transmitted Application Level message. If a device is about to transmit a packet that includes a zero length message, the LSN of the Packet ID field is loaded with the TXSN of the most recently transmitted message, and the TXSN is not incremented. When a device transmits a packet, it loads the most recent contents of the RXSN into the MSN of the Packet ID field of the outgoing packet. The TXSN is a wrap-around counter, and wraps around from 15 to zero. That is, if the TXSN was 15 before the increment, it becomes zero after the increment.

Each time a device receives a packet, it compares the LSN of the Packet ID field (e.g., the transmitted TXSN) of the received packet to its local copy of the RXSN. If the LSN is equal to the RXSN, the receiving device concludes that the newly received packet does not include a new Application Level message. Further, if the packet does not have a zero length message, then the receiving device concludes that the received message is a retransmission of a previously received message that has not been acknowledged. The receiving device receives the message and acknowledges the retransmission.

If the LSN of the received packet is equal to the RXSN+1, the received packet includes a new message. The receiving device copies the number included in the LSN into the RXSN, and transfers the new message to the Application Level software. The receiving device then acknowledges receipt of the new message. Otherwise, if the LSN of the ID byte is not equal to the RXSN or the RXSN+1, the received packet is in error and ignored. The reviewing device discards the packet and sends a negative acknowledgment (NACK) to the remote device.

Moreover, each time a device receives a packet, it compares the MSN of the Packet ID field to its local copy of the TXSN. If the MSN is equal to the TXSN, the receiving device concludes that the most recently transmitted Application Level message was properly received by the remote device. This is considered an ACK to the last transmission. Otherwise, if the MSN is not equal to the TXSN, the receiving device concludes that the most recently transmitted message was not properly received by the remote device. This is considered to be a NAK to the last transmission. The device then retransmits another packet that includes the previously sent message. If more than two such retransmissions are required to communicate the message to the remote device, the sending device registers a communications error and reinitializes its portion of the Data Link protocol. After transmitting a packet that includes a new message, the sending device does not transmit another new message until the remote device acknowledges receipt of the new message.

The Data Link protocol does not define unique ACK and NAK packets. However, ACKs and NAKs occur (naturally) within the protocol using the Packet ID field as described above. If a device properly receives a packet that includes a new Application Level message or if it receives an erroneous packet, it ACK or NAK that receipt. It does so by sending the remote device a packet in which the MSN of the Packet ID field is equal to the RXID of the last properly received packet. This procedure is used for sending ACKs or NAKs. The return packet may or may not include a new message.

Before the SMD and host PC can begin exchanging packets, they identify themselves to each other. This process is referred to as Protocol Initialization. In a specific implementation, the host PC initialization is different from the SMD initialization, which prevents a host PC from connecting to another host PC, or an SMD from connecting to another SMD.

FIG. 7A shows a state diagram of a specific embodiment of a Host Protocol Initialization process. The host PC detects the presence of the SMD in the following manner. Upon power up (A), the host PC enters an operating state 710 and sends two ASCII "DLE" characters (0.times.10) to the remote device (e.g., the SMD). In an embodiment, the second DLE is sent within a first predetermined time-out period (e.g., less than two seconds) of the transmission of the first DLE, or else the remote device times out. After sending the two DLEs (C), the host PC enters an operating state 712. In state 712, the host PC's receiver listens for an ASCII "CR" character (0.times.0D) from the remote device. If the CR does not arrive from the remote device within a second predetermined time-out period (e.g., five seconds) (F), the host returns to state 710 and retransmits the two DLEs. If any character other than CR arrives (G), the host PC also returns to state 710 and retransmits the DLEs.

If the CR character arrives within the second predetermined time-out period (E), the host enters an operating state 714 and listens for a second CR. If the second CR does not arrive within a third predetermined time-out period (e.g., two seconds) of the transmission of the first CR, the host PC times out (D) and returns to state 710 and retransmits the DLEs. Likewise, if a character other than CR is received (I) before the third predetermined time-out period, the host returns to state 710 and retransmits the DLEs. If the second CR is received before the third predetermined time-out period (H), the host PC's portion of the Data Link protocol is initialized. The host PC then enters an operating state 730 in the transmit state diagram in FIG. 7C and an operating state 750 in the receive state diagram in FIG. 7D, which are described below.

In an embodiment, the host PC attempts three transmissions (B) of a packet to the SMD. If all three attempts fail, the host PC re-executes the Host Protocol Initialization starting from state 710. In the specific implementation, if the SMD is not coupled to the host PC, the host PC loops between states 710 and 712 by continually transmitting the DLEs (C) and timing out when the CR is not received (F). This loop continues indefinitely until power is removed from the host PC or an SMD is detected.

FIG. 7B shows a state diagram of a specific embodiment of a SMD Protocol Initialization process. Initialization