Maxim Integrated Products, Inc. v. Starbucks Corporation

Filing 1

COMPLAINT for Patent Infringement against Starbucks Corporation ( Filing fee $ 350 receipt number 0540-3389392.), filed by Maxim Integrated Products, Inc.. (Attachments: # 1 Exhibit A - U.S. Patent No. 5,940,510, # 2 Exhibit B - U.S. Patent No. 5,949,880, # 3 Exhibit C - U.S. Patent No. 6,105,013, # 4 Exhibit D - U.S. Patent No. 6,237,095, # 5 Civil Cover Sheet)(Spangler, Andrew)

EXHIBIT A
UNITED STATES PATENT NO.
5,940,510

111111

United States Patent

1111111111111111111111111111111111111111111111111111111111111
US005940510A

[11]

Curry et ai.
[54]

TRANSFER OF VALUABLE INFORMATION
BETWEEN A SECURE MODULE AND
ANOTHER MODULE

[75]

Notice:

Filed:

[51]
[52]
[58]

[57]

Jan. 31, 1996

Int. CI. ........................................................ H04L 9/00
U.S. CI. ................................................. 380/25; 380/49
Field of Search .................................. 380/49, 24, 23,
380/25

ABSTRACT

6 Claims, 8 Drawing Sheets

ID NUMBERJ

~

~

t

I CONTROLJ
~ f---l 6

MATH COPROCESSOR
/'

f-

18 -I--"

I

f---l 4

I CLOCK!l

MICRO PROCESSOR

12 -I------'

H

ROM

~

J

NVRAM

J

I

~r-2

2

'--I--- 20
~r-2 4

•

OUTPUT BUFFER

28

-I----

INPUT BUFFER

30 -

26 32 -

ONE-WIRE
INTERFACE

Shinagawa ................................ 380/24
Chan ........................................... 380/4
Blandsord .... ...... .......... ...... ....... 380/23
Bellovin et al. ...... ...... ...... ........ 380/21
Akiyama et al. ......................... 380/24
Davis ........................................ 380/50
Caputo et al. ............................ 380/25
Davis et al. ...... .......... ...... ........ 380/24
Davis et al. .............................. 380/24
Tuttle ........ ...... ...... .......... .......... 380/23

The present invention rotates to system, apparatus and
method for communicating valuable data from a portable
module to another module via an electronic device. More
specifically, the disclosed system, apparatus and method are
useful for enabling a user to fill a portable module with a
cash equivalent and to spend the cash equivalent at a variety
of locations. The disclosed system incorporates an
encryption/decryption method.

6

IUNIQUE

3/1991
9/1992
2/1993
8/1993
7/1996
7/1996
8/1996
11/1996
4/1997
7/1998

Primary Examiner-Salvatore Cangialosi
Attorney, Agent, or Firm-Jenkens & Gilchrist

Appl. No.: 08/594,975

[22]

References Cited

5,003,594
5,150,407
5,189,700
5,241,599
5,539,825
5,539,828
5,546,463
5,577,121
5,621,796
5,787,174

This patent issued on a continued prosecution application filed under 37 CFR
1.53(d), and is subject to the twenty year
patent term provisions of 35 U.S.c.
154(a)(2).

[21]

*Aug.17,1999

U.S. PATENT DOCUMENTS

Assignee: Dallas Semiconductor Corporation,
Dallas, Tex.

[ *]

[56]

Inventors: Stephen M. Curry, Dallas; Donald W.
Loomis, Coppell; Michael L. Bolan,
Dallas, all of Tex.

[73]

Date of Patent:

5,940,510

Patent Number:

[45]

[19]

T

ICIRCUITRY -=
ENERGY,h
MODULE

1--,34

u.s.

Patent

Aug. 17, 1999

114

112

110

CREDIT CARD
READER

CASH
ACCEPTOR

.-PORTABLE
MODULE

I
I

AUTOMATIC
TELLER
MACHINE

116
PHONE
LINE

----------,

I

SECURE
MICROPROCESSOR~~MICROPROCESSOR
BASED DEVICE
BASED DEVICE

L

__ _

I-----i

106
102

5,940,510

Sheet 1 of 8

I
I
I
I

_ _ -1

104

FIG. 1

108

u.s.

Patent

Aug. 17, 1999

5,940,510

Sheet 2 of 8

ID NUMBER \

210
(212
I

(204
I

IOUTPUT BUFFERI

I INPUT BUFFER I
INPUT/OUTPUT
CONTROL
ONE-WIRE
INTERFACE \

MEMORY
CONTROL

MEMORY

-

L

202

I

~

SCRATCH BAD
MEMORY

ICOUNTER

YTIMER
"'214

206
PORTABLE MODULE

208

FIG. 2

u.s. Patent

5,940,510

Sheet 3 of 8

Aug. 17, 1999

UNIQUE ID NUMBER

/V-MICRO PROCESSOR

CLOCK

r-1 4

r--

/

12 -

V

CONTROL

"'",,-- r-l 6

MATH COPROCESSOR
./

18 - v

ROM
NVRAM

OUTPUT BUFFER

28 - v

V

30 -

V

26 - 32 - -

./'

INPUT BUFFER

t--

20

t- t-2 4

TV - 34

MODULE

FIG. 3

1"- I'--

+V
ENERGY /
CIRCUITRY

ONE-WIRE
INTERFACE

'"
'"

r- t-2 2

n-

u.s.

Patent

Aug. 17, 1999

MICROPROCESSOR
BASED DEVICE

PORTABLE MODULE

CONTAINS:

CD ID

5,940,510

Sheet 4 of 8

SECURE MODULE

READ (SERIAL NUMBER,
TRANSACTION COUNTER,I--_ _ _ _-----,
AND ENCRYPTED DATA)
AS DATA-ONE

_

NUMBER

Q) TRANSACTION COUNTER
COUNT

READ DATA-ONE AND
A FIRST AMOUNT OF
VALUE TO REMOVE FROM
THE PORTABLE MODULE

(j) ENCRYPTED DATA PACKET ____ 1
AjlD NUMBER
B TRANSACTION COUNT
C MONETARY VALUE

X

T
DECRYPT ENCRYPTED
DATA USING A
X4~~__~P~U~B_L1C~K_EY____~

•

X5~

COMPARE SERIAL NUMBER
RECEIVED IN DATA-ONE
WITH SERIAL NUMBER
IN DECRYPTED DATA

f
IF THEY MATCH, THEN
COMPARE TRANSACTION
COUNTER RECEIVED IN
DATA-ONE WITH THE
TRANSACTION COUNT IN
DECRYPTED DATA

t

FIG. 4
X7 -------

IF THEY MATCH SUBTRACT
THE 1ST AMOUNT FROM
THE MONETARY VALUE
FOUND IN THE DECRYPTED
DATA AND INCREMENT THE
TRANSACTION COUNTER
FOUND IN THE DECRYPTED
DATA

f
INCREASE THE VALUE REGISTER
BY THE SAME AMOUNT THE
MONEY VALUE FOUND IN THE
DECRYPTED DATA WAS
X8 ------DECREASED

u.s.

Patent

PORTABLE MODULE

Aug. 17, 1999

5,940,510

Sheet 5 of 8

MICROPROCESSOR
BASED DEVICE

SECURE MODULE

X9

--

CREATE DATA-TWO COMPRISING
(THE PORTABLE MODULE'S
SERIAL NUMBER, INCREMENTED
TRANSACTION COUNTER, AND
REDUCED MONETARY VALUE)
AND ENCRYPT DATA-TWO
USING A PRIVATE KEY

t
X10

X11

--

X12

--

FIC. 4
(CONTINUED)

--

RECEIVE ENCRYPTED
DATA-TWO
RECEIVE ENCRYPTED
DATA-TWO AND
STORE IN MEMORY

1
INCREMENT TRANSACTION
COUNTER

u.s.

Patent

Aug. 17, 1999

MICROPROCESSOR
BASED DEVICE

PORTABLE MODULE

(DID NUMBER

CV TRANSACTION

COUNTER

Y2/

COUNT

Q) ENCRYPTED DATA PACKET

AllD

SECURE MODULE

READ (SERIAL NUMBER,
TRANSACTION COUNTER,
f---AND ENCRYPTED DATA)
AS DATA-ONE

CONTAINS:

NUMBER
B TRANSACTION COUNT
C MONETARY VALUE

5,940,510

Sheet 6 of 8

!

READ DATA-ONE AND A FIRST
AMOUNT OF VALUE TO ADD
Y3 - - TO THE PORTABLE MODULE

r--- Yl

1
Y4

DECRYPT ENCRYPTED DATA
USING A PUBLIC KEY

f

COMPARE SERIAL NUMBER
RECEIVED IN DATA-ONE WITH
SERIAL NUMBER IN
YS-DECRYPTED DATA

1
Y6-----

CREATE DATA-TWO COMPRISING
(THE PORTABLE MODULE'S
YlO - - SERIAL NUMBER, INCREMENTED
TRANSACTION COUNTER, AND
INCREASED MONETARY VALUE).
ENCRYPT DATA-TWO
USING A PRIVATE KEY.

1
Yll-----

Y12-

Y13-

RECEIVE ENCRYPTED
DATA- TWO

1

IF THE SERIAL NUMBERS
MATCH, THEN COMPARE THE
TRANSACTION COUNTER IN
DATA-ONE WITH THE
DECRYPTED TRANSACTION
COUNT

T
IF THE TRANSACTION COUNTS
MATCH, THEN ADD THE 1ST
Y7 ----- AMOUNT OF VALUE TO THE
MONETARY VALUE FOUND IN
THE DECRYPTED DATA

,

INCREMENT THE TRANSACTION
COUNTER FOUND IN THE
Y8----DECRYPTED DATA

t

RECEIVE ENCRYPTED
DATA-TWO AND
STORE IN MEMORY

,

INCREMENT TRANSACTION
COUNTER

FIG. 5

DECREASE A VALUE REGISTER
BY THE SAME AMOUNT THE
Y8- MONEY VALUE WAS INCREASED

t

u.s.

Patent

5,940,510

Sheet 7 of 8

Aug. 17, 1999

READ/WRITE OBJECT COMMANDS
MODULE
108

,-

PIN
MATCH

4\

LOCKED
TRANSACTION
GROUP

I- 40

r1 O~jf~TS

HSCRIPTSj

(ot

JPRIVATE

(Pt

IOBJECTS

(t

YLOCKED
OBJECTS L

I-

42

I-

42

I-

42

J

READ-ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP

l-WIRE
I/O

- r-

DATA
TRANSPORT
LAYER

Ie::;

r-1 O~jE~TS (O~

PIN
MATCH

COMMAND
INTERPRETER

r-- 40

HSCRIPTSJ

IPRIVATE (P~
IOBJECTS

()I

YLOCKED
OBJECTS L

READ-ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP

-

~ O~jf~TS (0)1

PIN

MATCH
--jSCRIPTSJ

JOBJECTS (P~
PRIVATE
I

Y

LOCKED (L)J
OBJECTS

READ ONLY OBJECT COMMAND

FIG. 6

- 40

u.s.

Patent

Aug. 17, 1999

5,940,510

Sheet 8 of 8

I/O DATA BUFFERS
SYSTEM DATA
COMMON PIN, RANDOM
NUMBER REGISTER, ETC ...
TRANSACTION GROUP
OUTPUT DATA OBJECT #1
OUTPUT DATA OBJECT #2

GROUP NAME,
PASSWORD AND ATTRIBUTES

WORKING REGISTER

OBJECT 1

r--- 42

OBJECT 2

40 -------

TRANSACTION GROUP 1

40 -------

TRANSACTION GROUP 2

OBJECT N
TRANSACTION GROUP N

AUDIT TRAIL'
CIRCULAR BUFFER OF
TRANSACTION RECORDS
TRANSACTION RECORD

'THE AUDIT TRAIL DOES
NOT EXIST UNTIL THE
MICRO-IN-A-CAN
HAS BEEN LOCKED

GROUP
ID

ONCE LOCKED ALL
UNUSED RAM IS
ALLOCATED FOR
THE AUDIT TRAIL

FIG. 7

OBJECT
ID

DATE/TIME
STAMP

r--- 42

5,940,510
1

2

TRANSFER OF VALUABLE INFORMATION
BETWEEN A SECURE MODULE AND
ANOTHER MODULE

station, and be debited by a merchant when a product or
service is purchased by the consumer. As a result of a
purchase, the merchant's cash drawer will indicate an
increase in cash value.

CROSS REFERENCE TO OTHER
APPLICATIONS

5

BRIEF DESCRIPTION OF THE DRAWINGS

The following applications of common assignee contains
related subject matter and is hereby incorporated by refer10
ence:
Ser. No. 08/594,983, filed Jan. 31, 1996, entitled
METHOD, APPARATUS, SYSTEM AND FIRMWARE
FOR SECURE TRANSACTIONS; and
Ser. No. 08/595,014, filed Jan. 31, 1996, entitled
METHOD, APPARATUS AND SYSTEM FOR TRANS- 15
FERRING UNITS OF VALUE.
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates to a method and system for
transferring valuable information securely between a secure
module and another module. More particularly, the present
invention relates to transferring units of value between a
microprocessor based secure module and another module
used for carrying a monetary equivalent.
2. Description of Related Art
In the past the preferred means for paying for an item was
cash. As our society has become more advanced, credit cards
have become an accepted way to pay for merchandise or
services. The payment is not a payment to the merchant, but
instead is a credit given by a bank to the user that the
merchant accepts as payment. The merchant collects money
from the bank based on the credit. As time goes on, cash is
used less and less, and money transfers between parties are
becoming purely electronic.
Present credit cards have magnetic strips to identify the
owner of the card and the credit provider. Some credit cards
have electronic circuitry installed that identifies the credit
card owner and the credit or service provider (the bank).
The magnetic strips installed in present credit cards do not
enable the card to be used as cash. That is the modern credit
card does not allow the consumer to buy something with the
credit card and the merchant to receive cash at the time of
the transaction. Instead, when the consumer buys something
on credit, the merchant must later request that the bank pay
for the item that the consumer bought. The bank then bills
the consumer for the item that was bought.
Thus, there is a need for an electronic system that allows
a consumer to fill an electronic module with a cash equivalent in the same way a consumer fills his wallet with cash.
When the consumer buys a product or service from a
merchant, the consumer's module can be debited and the
merchant's cash drawer can be credited without any further
transactions with a bank or service provider.

20

25

DETAILED DESCRIPTION OF A PRESENTLY
PREFERRED EXEMPLARY EMBODIMENT
30

35

40

45

50

55

SUMMARY OF THE INVENTION
The present invention is an apparatus, system and method
for communicating a cash equivalent electronically to and
from a portable module. The portable module can be used as
a cash equivalent when buying products and services in the
market place.
The present invention comprises a portable module that
can communicate to a secure module via a microprocessor
based device. The portable module can be carried by a
consumer, filled with electronic money at an add-money

A more complete understanding of the method and apparatus of the present invention may be had by reference to the
following Detailed Description when taken in conjunction
with the accompanying Drawings wherein:
FIG. 1 depicts an exemplary system for transferring
valuable information between a module and a secure device;
FIG. 2 is a block diagram of an embodiment of a portable
module;
FIG. 3 is a block diagram of an embodiment of a
microprocessor based module;
FIG. 4 is an exemplary technique for transferring valuable
data securely into a portable module;
FIG. 5 is an exemplary technique for transferring valuable
data securely out of a portable module;
FIG. 6 is an exemplary organization of the software and
firmware within a secure microprocessor based device; and
FIG. 7 is an exemplary configuration of software and
firmware within a secure microprocessor based device.

60

65

FIG. 1 depicts a block diagram of an exemplary system
100 for transferring valuable information to and from a
portable module. A portable module 102, which will be
described in more detail later, communicates to a microprocessor based device 104. The portable module 102 may
contain information that represents units of exchange or a
currency equivalent. The microprocessor based device 104
can be any of an unlimited number of devices. For example,
the microprocessor based device 104 could be a personal
computer, an add-a-fare machine at a train or bus station
(similar to those in today's District of Columbia metro
stations), a turn style, a toll booth, a bank's terminal, a ride
at a carnival, a washing machine at a Laundromat, a locking
device, a mail metering device or any device that controls
access, or meters a monetary equivalent, etc.
The means for communication 106 between the portable
module 102 and the microprocessor based device 104 is
preferably via a single wire or contact connection. The
single wire connection 106 preferably incorporates a communication protocol that allows the portable module 102 and
the microprocessor based device 104 to communicate in a
bidirectional manner. Preferably the communication protocol is a one-wire protocol developed by Dallas Semiconductor. It is understood that the means for communicating
106 is not limited to a single wire connection. The communication means 106 could be multiple wires, a wireless
communication system, infrared light, any electromagnetic
means, a magnetic technique, or any other similar technique.
The microprocessor based device 104 is electrically connected to another microprocessor based device, which is
preferably a secure device 108. The term secure device
means that the device is designed to contain a secret code
and the secret code is extremely difficult to learn. An
example of a secure device 108 is explained later in this
document.
The microprocessor based device 104 can be connected to
a variety of other devices. Such devices include, but are not

5,940,510

3

4

limited to a cash acceptor 110, an automatic teller machine
formed (the number of times certain data in the memory of
the module has been changed). A timer 102 may be provided
(AIM) 112, a credit card reader 114, and a phone line 116.
in the module to provide the ability to time stamp transacThe cash acceptor 110 is adapted to receive cash in the
tions performed by the module. A memory controller 204
form of currency, such as dollar bills or coins. The cash
110, preferably, determines the value of the 5 controls the reading and writing of data into and out of the
acceptor
memory 202.
accepted currency. The cash acceptor 110 communicates to
The module also may comprise an identification number
the microprocessor based device 104 and informs the device
210. The identification number preferably uniquely identi104 of how much currency has been deposited in the cash
fies the portable module from any other portable module.
acceptor 110.
An input/output control circuit 212 controls the data flow
The cash acceptor 110 can also be a device which pro- 10
into and out of the portable module 102. The input/output
vides currency. That is, the cash accepter 110 in response to
control ("I/O") 212 preferably has an input buffer and an
a communication from the microprocessor based device
output buffer and interface circuitry 214. As stated above,
104, may provide a metered amount of currency to a person.
the interface circuitry 214 is preferably a one-wire interface.
The credit card reader 114, and ATM 112 can also be 15 Again, it is understood that a variety of technologies can be
attached to the microprocessor based device 104. The credit
used to interface the portable module 102 to another eleccard reader 114 could be used to read a user's credit card and
tronic device. A single wire or single connection is preferred
then, when authorized, either communicate to the microprobecause the mechanics of making a complete connection is
cessor based device 104 that units of exchange need to be
simplified. It is envisioned that a proximity/wireless comadded to the portable module or that units of exchange need 20 munication technique is also a technique for communicating
to be extracted from the portable module to pay for a good,
between the module 102 and another device. Thus, the
service or credit card bill.
interface circuit 214 can be a single wire, multiple wire,
wireless, electromagnetic, magnetic, light, or proximity,
The ATM 112 may also be connected to the microprointerface circuit.
cessor based device. Via communications from the ATM
FIG. 3 depicts a block diagram of an exemplary secure
112, the microprocessor based device 104 can be informed 25
that units of exchange need to be added or subtracted from
microprocessor based device ("secure device") 108. The
the portable module 102.
secure device circuitry can be a single integrated circuit. It
is understood that the secure device 108 could also be a
Furthermore, it is also possible that the microprocessor
monolithic or multiple circuits combined together. The
based device 104 is connected to a phone line 116. The
phone line may be used for a variety of things. Most 30 secure device 108 preferably comprises a microprocessor
12, a real time clock 14, control circuitry 16, a math
importantly, the phone line may be used to allow the
coprocessor 18, memory circuitry 20, input/output circuitry
microprocessor based device 104 to communicate with a
26, and an energy circuit 34.
network of devices. Such telephonic communication may be
The secure device 108 could be made small enough to be
for validating transactions or for aiding the accounting of
transactions that are performed via the microprocessor based 35 incorporated into a variety of objects including, but not
device's 104 aid. It is further understood that the phone line
limited to a token, a card, a ring, a computer, a wallet, a key
may be any of a vast variety of communication lines
fob, a badge, jewelry, a stamp, or practically any object that
can be grasped and/or articulated by a user of the object. In
including wireless lines. Video, analog, or digital information may be communicated over the phone line 116.
the present system 100, the secure device 108 is preferably
FIG. 2 depicts a preferred exemplary portable module 40 adapted to be a trusted certifying authority. That is the secure
device 108 is a trusted computer. The secure device 108
102. The portable module 102 is preferably a rugged read/
comprises a numeric coprocessor 18 optimized for math
write data carrier that can act as a localized data base and be
intensive encryption. The BIOS is immune to alteration and
easily accessed with minimal hardware. The module can be
is specifically designed for secure transactions. This secure
incorporated in a vast variety of portable items which
includes, but is not limited to a durable micro-can package 45 device 108 is preferably encased in a durable, dirt, moisture
and shock resistant stainless steel enclosure, but could be
that is highly resistant to environmental hazards such as dirt,
encased in wide variety of structures so long as specific
moisture, and shock. The module can be incorporated into
contents of the secure device 108 are extremely difficult to
any object that can be articulated by a human or thing, such
decipher. The secure device 108. The secure device 108 may
as a ring, bracelet, wallet, name tag, necklace, baggage,
machine, robotic device, etc. Furthermore, the module 102 50 have the ability to store or create a private/public key set,
whereby the private key never leaves the secure device 108
could be attached to a stationary item and the microprocesand is not revealed under almost any circumstance.
sor based device 104 may be articulated to the portable
Furthermore, the secure module 108 is preferably designed
module 102. For example, the module 102 may be attached
to prevent discovery of the private key by an active selfto a piece of cargo and a module reader may be touched to
or brought near the module 102. The module reader may be 55 destruction of the key upon wrongful entry.
part of the microprocessor based device 104.
The microprocessor 12 is preferably an 8-bit
microprocessor, but could be 16, 32, 64 or any operable
The portable module 102 comprises a memory 202 that is
number of bits. The clock 14 provides timing for the module
preferably, at least in part, nonvolatile memory for storing
circuitry. There can also be separate clock circuitry 14 that
and retrieving vital information pertaining to the system to
which the module 102 may become attached to. The 60 provides a continuously running real time clock.
memory 202 may contain a scratchpad memory which may
The math coprocessor circuitry 18 is designed and used to
handle very large numbers. In particular, the coprocessor
act as a buffer when writing into memory. Data is first
will handle the complex mathematics of RSA encryption and
written to the scratchpad where it can be read back. After
data has been verified, the data is transferred into the
decryption or other types of math intensive encryption or
memory.
65 decryption techniques.
The module 102 also comprises a counter 206 for keeping
The memory circuitry 20 may contain both read-onlymemory and non-volatile random-access-memory.
track of the number of transactions the module has per-

5,940,510

5

6

Furthermore, one of ordinary skill in the art would underProvider for the benefit of the End User. For this reason, the
stand that volatile memory, EPROM, SRAM and a variety of
secure module 108 offers functions to support the Service
other types of memory circuitry might be used to create an
Provider in setting up the module for an intended applicaequivalent device.
tion. It also offers functions to allow the End User to invoke
Control circuitry 16 provides timing, latching and various 5 the services offered by the Service Provider.
necessary control functions for the entire circuit.
Each Service Provider can reserve a block of NVRAM
An input/output circuit 26 enables bidirectional commumemory to support its services by creating a transaction
nication with the secure module 108. The input/output
group 40 (refer to FIGS. 6 and 7). A transaction group 40 is
circuitry 26 preferably comprises at least an output buffer
simply a set of software objects 42 that are defined by the
and an input buffer. For communication via a one-wire bus, 10 Service Provider. These objects 42 include both data objects
one-wire interface circuitry can be included with the input/
(encryption keys, transaction counts, money amounts, date/
output circuitry 26. It is understood that the input/output
time stamps, etc.) and transaction scripts 44 which specify
circuitry 26 of the secure device 108 can be designed to
how to combine the data objects in useful ways. Each
operate on a single wire, a plurality of wires or any means
Service Provider creates his own transaction group 40,
for communicating information between the secure module 15 which is independent of every other transaction group 40.
108 and the microprocessor based device 104.
Hence, multiple Service Providers can offer different serAn energy circuit 34 may be necessary to maintain stored
vices in the same module 108. The number of independent
information in the memory circuitry 20 and/or aid in powService Providers that can be supported depends on the
ering the other circuitry in the module 108. The energy
number and complexity of the objects 42 defined in each
circuit 34 could consist of a battery, capacitor, R/C circuit, 20 transaction group 40. Examples of some of the objects 42
photo-voltaic cell, or any other equivalent energy producing
that can be defined within a transaction group 40 are the
circuit or means.
following:
The firmware architecture of the secure module 108 and
how it operates within the exemplary system for transferring
RSAModulus
Clock Offset
valuable information, such as units of exchange or currency, 25
RSA Exponent
Random SALT
between the secure module 108 and a portable module 102
Configuration Data
Transaction Script
will now be discussed. The secure module 108 provides
Input Data
Transaction Counter
Money Register
Output Data
encryption and decryption services for confidential data
Destructor
transfer through the microprocessor based device 104. The
following examples are intended to illustrate a preferred 30
feature set of the secure module 108 and to explain the
Within each transaction group 40 the secure module 108
services that the exemplary system 100 can offer. These
will initially accept certain commands which have an irreapplications and examples by no means limit the capabilities
versible effect. Once any of these irreversible commands are
of the invention, but instead bring to light a sampling of its
executed in a transaction group 40, they remain in effect
capabilities.
35 until the end of the module's useful life or until the transI. OVERVIEW OF THE PREFERRED SECURE MODULE
action group 40, to which it applies, is deleted from the
108 AND ITS FIRMWARE DESIGN
secure module 108. In addition, there are certain commands
Referring to FIG. 3 again, the secure module 108 preferwhich have an irreversible effect until the end of the modably contains a general-purpose, 80SI-compatible micro
ule's life or until a master erase command is issued to erase
controller 12 or a reasonably similar product, a continuously 40 the entire contents of the secure module 108. These comrunning real-time clock 14, a high-speed modular exponenmands will be discussed further below. These commands are
tiation accelerator for large integers (math coprocessor) 18,
essential to give the Service Provider the necessary control
input and output buffers 28, 30 with a one-wire interface 32
over the operations that can be performed by the End User.
for sending and receiving data, 32 Kbytes of ROM memory
Examples of some of the irreversible commands are:
22 with preprogrammed firmware, 8 Kbytes of NVRAM 45
(non-volatile RAM) 24 for storage of critical data, and
Privatize Object
Lock Object
control circuitry 16 that enables the micro controller 12 to be
Lock Micro-In-A-Can ™
Lock Transaction Group
powered up to interpret and act on the data placed in an input
data object. The module 108 draws its operating power from
Since much of the module's utility centers on its ability to
a single wire, one-wire communication line. The micro 50
controller 12, clock 14, memory 20, buffers 28, 30, one-wire
keep a secret, the Privatize command is a very important
front-end 32, modular exponentiation accelerator 18, and
irreversible command.
Once the secure module 108, as a whole, is locked, the
control circuitry 16 are preferably integrated on a single
remaining NVRAM memory 24 is allocated for a circular
silicon chip and packaged in a stainless steel micro can using
packaging techniques which make it virtually impossible to 55 buffer for holding an audit trail of previous transactions.
Each of the transactions are identified by the number of the
probe the data in the NVRAM 24 without destroying the
data. Initially, most of the NVRAM 24 is available for use
transaction group, the number of objects 42 within the
specified group, and the date/time stamp.
to support applications such as those described below. One
The fundamental concept implemented by the firmware is
of ordinary skill will understand that there are many comparable variations of the module design. For example, 60 that the Service Provider can store transaction scripts 44 in
volatile memory might be used, or an interface other than a
a transaction group 40 to perform only those operations
one-wire interface could be used.
among objects that he wishes the End User to be able to
perform. The Service Provider can also store and privatize
The secure module 108 is preferably intended to be used
RSA key or keys (encryption keys) that allow the secure
first by a Service Provider who loads the secure module 108
with data to enable it to perform useful functions, and 65 module 108 to "sign" transactions on behalf of the Service
second by an End User who issues commands to the secure
Provider, thereby guaranteeing their authenticity. By privamodule 108 to perform operations on behalf of the Service
tizing and/or locking one or more objects 42 in the trans-

5,940,510
7

8

module can keep an accounting of the amount of "money"
action group 40, the Service Provider maintains control over
what the secure module lOS is allowed to do on his behalf.
it has collected XS. The secure module lOS creates a data
The End User cannot add new transaction scripts 44 and is
packet, a second data, which comprises at least the portable
therefore limited to the operations on objects 42 that can be
module's serial number, the incremented transaction count,
performed with the transaction scripts 44 programmed by 5 and the reduced monetary value of the portable module 102.
the Service Provider.
The second data packet is then encrypted by the secure
II. USAGE MODELS OF IRE SECURE MODULE lOS
module lOS using a private key X9.
AND PORTABLE MODULE 102
The microprocessor based device 104 receives the
This section presents practical applications of the system
encrypted second data packet, passes the encrypted second
100. Each of these applications is described in enough detail
10 data packet to the portable module 102 X10, and opens the
to make it clear why the secure module lOS and portable
turn style to let the module's user onto the train platform.
module 102 are important to the system application.
The portable module 102 receives the encrypted second data
A. TRANSFERRING UNITS OF EXCHANGE OUT OF A
packet and stores it in memory X11. The portable module
PORTABLE MODULE 102
also increments its transaction count indicating that another
This section describes an example of how a portable
module 102 and a secure module lOS operate in conjunction 15 transaction has occurred X12.
Thus, the above description indicates how valuable inforwith the microprocessor based device 104 so that units of
mation can be transferred between a portable insecure
exchange can be securely transferred out of the portable
module 102 and a secure module lOS wherein there is a
module 102 and deposited into the secure module lOS and/or
conservation of value. That is, no value is gained or lost.
potentially communicated to at least one of the cash acceptor
110, AIM 112, credit card reader 114, or the phone line 116. 20 Value that was in the portable module 102 was decreased by
the same amount value was added to the secure module lOS.
Referring to FIG. 4, initially the portable module 102
In the example provided, the decrease and increase in value
contains its ID number, a count within its transaction counter
and an encrypted data packet stored in memory. Encrypted
was equal to a train fare. Such an increment or decrement
within the data packet is the portable modules ID number,
can also be equal to an amount provided by an ATM, credit
the portable modules transaction count number, and the 25 card transaction, cash acceptor, etc.
amount of value (the monetary value) of the portable module
It is also understood that the insecure portable module 102
at the present time Xl.
could be another secure module similar to the secure module
in the system, but programed to act like a portable module
The user of the portable module touches, or somehow puts
102.
the portable module 102 into communication with the
microprocessor based device 104. For explanation purposes, 30 B. TRANSFERRING UNITS OF EXCHANGE INTO THE
suppose the portable module 102 is being used as a token
PORTABLE MODULE 102
In this example, for simplicity, suppose the portable
used to pay for a train fare. Thus, the microprocessor based
module does not have any monetary value and the user of the
device 104 could be, in this case, a turn style that allows the
user to enter a train platform. The cost of entering the train
portable module wishes to "fill it up" with value. Suppose
platform is known by the microprocessor based device 104. 35 the user wishes to take cash out of an AIM machine and
The microprocessor based device 104 reads the portable
instead of pocketing the cash, the user wishes to put the cash
module's serial number, transaction count, and the
value into the portable module 102.
encrypted data packet X2. This data could be referred to as
Referring to FIG. 5, the portable module 102 contains its
a first data.
ID number, a transaction count and an encrypted data packet
The microprocessor device 104 then provides the first 40 containing the portable module's ID number, transaction
data along with a first value, being the amount of value to be
count and the monetary value of the portable module 102
debited from the portable token (the train fare), to the secure
Yl. The microprocessor based device 104, which in this
module lOS X3. The secure module lOS decrypts the
example could be part of the ATM machine 112, receives the
encrypted data found in the first data using a public key X4.
information contained in the portable module 102 when a
Next, the secure module lOS makes a few comparisons to 45 communication is initiated between the portable module 102
and the microprocessor based device 104 Y2.
make sure that the data received is good data and not
The microprocessor based device 104 passes the module's
counterfeit. The secure module lOS compares the serial
number received in the first data with the decrypted serial
serial number, transaction count, and encrypted data packet
number X5. If the two serial numbers match then the secure
as a first data packet to the secure module lOS. The micromodule lOS compares the transaction count received in the 50 processor based device also passes the amount of amount of
first data with the decrypted transaction count X6. If the two
monetary value to add to the portable module 102, as
transaction counts match then the secure module is comindicated by the AIM 112, to the secure module lOS Y3.
The secure module lOS decrypts the encrypted data
fortable that the data received is not counterfeit data. It is
understood that the comparisons can be done in any order.
passed to it using a public key Y4. The secure module lOS
Furthermore, there may have been a time stamp sent from 55 then makes a few comparisons to make sure that the data it
the portable module 102. The time stamp may indicate a
has just received is valid and not counterfeit. The secure
module lOS compares the serial number (ID number)
variety of things. One thing could be an indication of
received in the first data packet with the serial number (ID
whether the portable module is still valid or the time stamp
number) found in the decrypted data Y5. The secure module
may further enable the secure module to decide if the data
is or is not counterfeit.
60 lOS also compares the transaction count passed the first data
Assuming all the data passed to the secure module lOS is
packet with the transaction count found in the decrypted data
Y6. If the serial numbers and transaction counters match,
determined to be valid data, the secure module lOS subtracts
the first value, the train fare, from the monetary value of the
then the secure module decides that the data received is valid
and the secure module adds the monetary value, indicated by
portable module 102 X7. The decrypted transaction count is
then incremented.
65 the ATM to the monetary value of the decrypted data Y7.
A register within the secure module lOS is increased by
The decrypted transaction count is incremented YS. A regthe amount of the first value, the train fare, so that the secure
ister within the secure module may be decremented by the

5,940,510

9

10

same amount that the monetary value of the decrypted data
was increased YS.
The secure module lOS creates a second data packet, that
contains the portable module's ID number, the incremented
transaction counter and the increased monetary value. The 5
second data packet is then encrypted using a private key
Y10.
The microprocessor based device 104 reads the encrypted
second data packet and sends it to the portable module 102
Yll. The portable module receives the encrypted second 10
data packet and stores it in memory Y12. The portable
module also advances its transaction counter Y13. The result
being that the portable module now has the value of the cash
withdrawn from the ATM 112. Furthermore, a record of the
transaction may have been recorded and kept in the secure 15
module, as well as by the bank that operates the ATM 112.

-continued
Exemplary Object Definitions

RSA Exponent

Exemplary Firmware Definitions for Use With the Secure Module
Object

Group

Group ID
Object ID

Object Type
PIN

Common PIN

Group PIN

Audit Trail

Locked Object

Private Object

Locked Group

Composite Object

The most primitive data structure
accepted by and operated on by the
secure modules firmware. A list of
valid objects and their definitions
is provided in the next section.
A self-contained collection of
objects. An object's scope is
restricted to the group of which it
is a member.
A number preferably between 0 and
255 representing a specific group.
A number preferably between 0 and
255 representing a specific object
within a specific group.
Preferably a 1-byte type specifier
that describes a specific object.
An alphanumeric Personal
Identification number that is
preferably eight bytes in length.
The PIN that controls access to
shared resources such as the audit
trail. It is also used to control
the host's ability to create and
delete groups.
The PIN that controls access to
operations specific to objects
within a group.
A record of transactions occurring
after the secure module has been
locked.
An object which has been locked by
executing the lock object command.
Once an object is locked it is not
directly readable.
An object which has been privatized
by executing the privatize object
command. Once an object is private,
it is not directly readable or
writable.
A group which has been locked using
the locked group command. After a
group has been locked it will not
allow object creation.
A combination of several objects.
The individual objects inherit the
attributes of the composite object.

Exemplary Object Definitions
RSAModulus

A large integer preferably of at
most 1024 bits in length. It is the
product of 2 large prime numbers
that are each about half the number
of bits in length of the desired
modulus size. The RSA modulus is

20

Transaction Script

25

30

Transaction Counter
35

40
Money Register

45

50

Clock Offset

55

60

65

SALT

used in the following equations for
encrypting and decrypting a message
M:
Encryption: C ~ M' (mod N) (1)
Decryption: M ~ Cd (mod N) (2)
where C is the cyphertext, d and e
are the RSA exponents (see below)
and N is the RSA modulus.
Both e and d (shown in equations 1
and 2 above) are RSA exponents.
They are typically large numbers but
are smaller than the modulus (N).
RSA exponents can be either private
or public. When RSA exponents are
created in the secure module, they
may be declared as either. Once
created an exponent may be changed
from a public exponent to a private
exponent. After an exponent has
been made private, however, it will
remain private until the transaction
group 40 to which it belongs is
destroyed.
A transaction script is a series of
instructions to be carried out by
the secure module. When invoked the
secure module firmware interprets
the instructions in the script and
places the results in the output
data object (see below). The actual
script is simply a list of objects.
The order in which the objects are
listed specifies the operations to
be performed on the objects.
transaction scripts 44 preferably
may be as long as 128 bytes.
The transaction counter object is
preferably 4 bytes in length and is
usually initialized to zero when it
is created. Every time a
transaction script, which references
this object, is invoked, the
transaction counter increments by 1.
Once a transaction counter has been
locked it is read only and provides
an irreversible counter.
The money register object is
preferably 4 bytes in length and may
be used to represent money or some
other form of credit. Once this
object has been created, it must be
locked to prevent a user from
tampering with its value. Once
locked the value of this object can
be altered only by invoking a
transaction script. A typical
transaction group 40 which performs
monetary transactions might have one
script for withdrawals from the
money register and one for deposits
to the money register.
This object is preferably a 4 byte
number which contains the difference
between the reading of the secure
module's real-time clock and some
convenient time (e.g., 12:00 a.m.,
January 1, 1970). The true time can
then be obtained from the secure
module by adding the value of the
clock offset to the real-time clock.
A SALT object is preferably 20 bytes
in length and should be initialized
with random data when it is created.
When a host transmits a generate
random SALT command, the secure
module combines the previous SALT
with the secure module's random
number (produced preferably by

5,940,510
11

12

-continued

PIN_TO_ERASE bit is set in the option byte, the PIN can
only be changed through the set common PIN command.
Possible error codes for the set common PIN command:

Exemplary Object Definitions

Configuration Data

Input Data

Output Data

Random Fill

Working Register

ROM Data

randomly occurring power-ups) to
generate a new random SALT. If the
SALT object has not been privatized
it may subsequently be read by
issuing a read object command.
This is a user defined structure
with preferably a maximum length of
128 bytes. This object is typically
used to store configuration
information specific to its
transaction group 40. For example,
the configuration data object may be
used to specify the format of the
money register object (i.e., the
type of currency it represents)
Since this object has no pre-defined
structure, it may never be used by a
transaction object.
An input data object is simply an
input buffer with preferably a
maximum length of 128 bytes. A
transaction group may have multiple
input objects. The host uses input
data objects to store data to be
processed by transaction scripts 44.
The output data object is used by
transaction scripts as an output
buffer. This object is
automatically created when the
transaction group is created. It is
preferably 512 bytes in length and
inherits password protection from
its group.
When the script interpreter
encounters this type of object it
automatically pads the current
message so that its length is 1 bit
smaller than the length of the
preceding modulus. A handle to this
object is automatically created when
the transaction group is created.
It is a private object and may not
be read using the read object
command.
This object is used by the script
interpreter as working space and may
be used in a transaction script. A
handle to this object is
automatically created when the
transaction group is created. It is
a private object and may not be read
using the read object command.
This object is automatically created
when the transaction group is
created. It is a locked object and
may not be altered using the write
object command. This object is 8
bytes and length and its contents
are identical to the 8 by ROM data
of the Micro-In-A-Can TM.

00000001b (require PIN for
Master Erase)
00000010b (require PIN for
group creation)

Initially the secure module has a PIN (Personal Identification Number) of 0 (Null) and an option byte of o. Once a
PIN has been established it can only be changed by providing the old PIN or by a Master Erase. However, if the

5
ERR BAD COMMON PIN
ERR BAD PIN_LENGTH
ERR BAD OPTION_BYTE
10

15

(Common PIN match
failed)
(New PIN lenqth
> 8 bytes)
(Unrecognizable option
byte)

For all commands described in this section, data received
by the host will be in the form of a return packet. A return
packet has the following structure:
Command status byte (0 if command successful, error
code otherwise, 1 byte)
Output data length

20

Output data

(Command output length, 2
bytes)
(Command output, length
specified above).

Master Erase (02H)
Transmit data
02H, Common PIN
Receive data
CSB=O if command was successful, ERR BAD
COMMON_PIN otherwise
30
Output length=O
Output data=O
Notes:
If the LSB (least significant bit) of the PIN option is clear
35 (i.e. PIN not required for Master Erase) then a 0 is transmitted for the Common PIN value. In general this text will
always assume a PIN is required. If no PIN has been
established a 0 should be transmitted as the PIN. This is true
of the common PIN and group PINS (see below). If the PIN
was correct the firmware deletes all groups (see below) and
40
all objects within the groups. The common PIN and common
PIN option byte are both reset to zero.
After everything has been erased the secure module
transmits the return packet. The CSB is as described above.
45 The output data length and output data fields are both set to
25

o.
Create Group (03H)
Transmit data
03H, Common PIN, Group name, Group PIN
50
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=1 if successful, 0 otherwise
55
Output data=Group ID if successful, 0 otherwise
Notes:
The maximum group name length is 16 bytes and the
maximum PIN length is eight bytes. If the PIN_TO_
CREATE bit is set in the common PIN option byte and the
60 PIN transmitted does not match the common PIN the secure
module will set the OSC to ERR_BAD COMMON_PIN.
Possible error return codes for the create group command:

65

ERR BAD COMMON_PIN
ERR BAD NAME_LENGTH

(Incorrect common PIN)
(If group name length> 16
bytes)

5,940,510

13

14

-continued
ERR BAD PIN_LENGTH
ERR MIAC LOCKED
ERR INSUFFICIENT_RAM

(If group PIN length
> 8 bytes)
(The secure module has
been locked)
(Not enough memory for
new group)

Set Group PIN (04H)
Transmit data
04H, Group ID, old GPIN, new GPIN
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=O
Output data=O
Notes:
The Group PIN only restricts access to objects within the
group specified by the group ID transmitted in the command
packet.
Possible error codes for the set group PIN command:
ERR BAD GROUP PIN
ERR BAD PIN_LENGTH

(Group PIN match
failed)
(New group PIN length
> 8 bytes)

-continued

5

10

Transaction script
Clock offset
Random SALT
Configuration object
Input data object
Output data object
Object Attributes:
Locked
Privatized

4

5
7
8
9

00000001b
00000010b

Objects may also be locked and privatized after creation
by using the Lock Object and Privatize Object commands
described below.
15 Lock Object (06H)
Transmit data
06H, Group ID, Group PIN, Object ID
Receive data
CSB=O if command successful, appropriate error code
20
otherwise
Output length=O
Output data=O
Notes:
If the Group ID, Group PIN and Object ID are all correct,
25
the secure module will lock the specified object. Locking an
object is an irreversible operation.
Possible error return codes for the lock object command:

Create Object (OSH)
30
ERR BAD GROUP PIN
(Incorrect group PIN)
Transmit data
ERR GROUP LOCKED
(The group has already
OSH, Group ID, Group PIN, Object type, Object
been locked)
attributes, Object data
ERR MIAC LOCKED
(The secure module has
been locked)
Receive data
ERR BAD GROUP ID
(Specified group does
CSB=O if command successful, appropriate error code 35
not exist)
otherwise
(Specified object does
not exist)
Output length=l if successful, 0 otherwise
Output data=object ID if successful, 0 otherwise
Privatize Object (07H)
Notes:
Transmit data
If the Create Object command is successful the secure 40
07H, Group ID, Group PIN, Object ID
module firmware returns the object's ID within the group
Receive data
specified by the Group ID. If the PIN supplied by the host
was incorrect or the group has been locked by the Lock
CSB=O if successful, appropriate error code otherwise
Group command (described below) the secure module
Notes:
returns an error code in the CSB. An object creation will also 45
If the Group ID, Group PIN and Object ID were valid the
fail if the object is invalid for any reason. For example, if the
object will be privatized. Privatized objects share all the
object being created is an RSA modulus (type 0) and it is
properties of locked objects but are not readable. Privatized
greater than 1024 bits in length. transaction script creation
objects are only modifiable through transaction scripts. Note
will succeed if it obeys all transaction scripts rules.
that locking a privatized object is legal, but has no meaning
50
since object privatization is a stronger operation than object
Possible error return codes for the create object command:
locking. Privatizing an object is an irreversible operation.
Possible error return codes for the privatize object comERR BAD GROUP _PIN
(Incorrect group PIN)
mand:
ERR GROUP LOCKED
ERR MIAC_LOCKED
ERR INVALID_TYPE
ERR BAD SIZE
ERR INSUFFICIENT_RAM

(The group has been
locked)
(The secure module has
been locked)
(The object type
specified is invalid)
(The objects length
was invalid)
(Not enough memory for
new object)

55
ERR BAD GROUP PIN
ERR GROUP LOCKED
ERR MIAC LOCKED
60

ERR BAD OBJECT ID

Object types:
RSAmodulus
RSA exponent
Money register
Transaction counter

ERR BAD GROUP ID

(Incorrect group PIN)
(The group has already
been locked)
(The secure module has
been locked)
(Specified group does
not exist)
(Specified object does
not exist)

o
2
3

65

Make Object Destructable (OSH)
Transmit data
OSH, Group ID, Group PIN, Object ID

5,940,510
15

16

Receive data
CSB=O if successful, appropriate error code otherwise
Notes:
If the Group ID, Group PIN and Object ID were valid the
object will be made destructable. If an object is destructable
it becomes unusable by a transaction script after the groups
destructor becomes active. If no destructor object exists
within the transaction group the destructible object attribute
bit has no affect. Making an object destructable is an
irreversible operation.
Possible error return codes for the make object destructable command:

Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=O
Output data=O
Notes:
If the group PIN provided is correct the secure module
BIOS will not allow further object creation within the
specified group. Since groups are completely self-contained
entities they may be deleted by executing the Delete Group
command (described below).
Possible error return codes for the lock group command:

5

10

15
ERR_BAD GROUP PIN
ERR_GROUP LOCKED

ERR_BAD GROUP ID

(Incorrect group PIN)
(The group has already
been locked)
(The secure module has
been locked)
(Specified group does
not exist)
(Specified object does
not exist)

ERR BAD GROUP _PIN
ERR GROUP LOCKED
ERR MIAC_LOCKED
ERR BAD GROUP_ID

20

(Incorrect group PIN)
(The group has already
been locked)
(The secure module has
been locked)
(Specified group does
not exist)

Invoke Transaction Script (OBH)
Transmit data
OBH, Group ID, Group PIN, Object ID
25
Lock Secure module (09H)
Receive data
Transmit data
CSB=O if command successful, appropriate error code
09H, Common PIN
otherwise
Receive data
Output length=l if successful, 0 otherwise
30
CSB=O if successful, appropriate error code otherwise
Output data=estimated completion time
Notes:
Output length=2 if successful, 0 otherwise
The time estimate returned by the secure module is in
Output data=audit trail size if successful, 0 otherwise
sixteenths of a second. If an error code was returned in the
Notes:
CSB, the time estimate will be O.
If the host supplied Common PIN is correct and the secure 35
Possible error return codes for the execution transaction
module has not previously been locked, the command will
script command:
succeed. When the secure module is locked it will not accept
any new groups or objects. This implies that all groups are
ERR BAD GROUP _PIN
(Incorrect group PIN)
automatically locked. The RAM not used by the system or
ERR BAD GROUP_ID
(Specified group does
by groups will be used for an audit trail. There is no audit 40
not exist)
trail until the secure module has successfully been locked!
ERR BAD OBJECT_ID
(Script object did not
exist in group)
An audit trail record is six bytes long and has the
following structure:
Group IDIObject IDIDate/Time stamp.
Once an audit trail has been established, a record of the
form shown above will be stored in the first available size
byte location every time a transaction script is executed.
Note that since the secure module must be locked before the
audit trail begins, neither the group ID nor any object ID is
subject to change. This will always allow an application
processing the audit trail to uniquely identify the transaction
script that was executed. Once the audit trail has consumed
all of its available memory, it will store new transaction
records over the oldest transaction records.
Possible error codes for the lock secure module command:
ERR BAD COMMON_PIN
ERR MIAC LOCKED

Lock Group (OAR)
Transmit data
OAR, Group ID, Group PIN

(Supplied common PIN
was incorrect)
(Secure module was
already locked)

45

50

55

60

65

Read Object (OCH)
Transmit data
OCH, Group ID, Group PIN, Object ID
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=object length if successful, 0 otherwise
Output data=object data if successful, 0 otherwise
Notes:
If the Group ID, Group PIN and Object ID were correct,
the secure module checks the attribute byte of the specified
object. If the object has not been privatized the secure
module will transmit the object data to the host. If the Group
PIN was invalid or the object has been privatized the secure
module will return a 0 in the output length, and data fields
of the return packet.
Possible error codes for the read object command:
ERR BAD GROUP _PIN
ERR BAD GROUP_ID

(Incorrect group PIN)
(Specified group does
not exist)

5,940,510
17

18

-continued

ERR OBJECT_PRIVATIZED

(Object did not exist
in group)
(Object has been
privatized)

Write Object (ODH)
Transmit data
ODH, Group ID, Group PIN, Object ID, Object size,
Object Data
Receive data
CSB=O if successful, appropriate error code otherwise
Output length=O
Output data=O
Notes:
If the Group ID, Group PIN and Object ID were correct,
the secure module checks the attribute byte of the specified
object. If the object has not been locked or privatized the
secure module will clear the objects previous size and data
and replace it with the new object data. Note that the object
type and attribute byte are not affected.
Possible error codes for the write object command:

-continued
ERR MIAC_LOCKED

5

10

15

20

25
ERR BAD GROUP PIN
ERR BAD GROUP ID

ERR BAD OBJECT_SIZE
ERR OBJECT_LOCKED
ERR OBJECT_PRIVATIZED

(Incorrect group PIN)
(Specified group does
not exist)
(Object did not exist
in group)
(Illegal object size
specified)
(Object has been
locked)
(Object has been
privatized)

(Secure module has
been locked)

30

35

Get Command Status Info (lOH)
Transmit data
lOH
Receive data
CSB=O
Output length=6
Output data=secure module status structure (see below)
Notes:
This operation requires no PIN and never fails. The status
structure is defined as follows:
Last command executed
Last command status
Time command received

(1 byte)
(1 byte)
(4 bytes)

Get Secure module Configuration Info (llH)
Transmit data
11H
Receive data
CSB=O
Output length=4
Output data=secure module configuration structure
Notes:
This operation requires no PIN and never fails. The
configuration structure is defined as follows:
Number of groups
Flag byte (see below)
Audit trail size/Free RAM

(1 byte)
(1 byte)
(2 bytes)

Read Group Name (OEH)
Transmit data
The flag byte is the bitwise-or of any of the following
OEH, Group ID
values:
Receive data
40
OOOOOOOlb (Secure module is locked)
CSB=O
OOOOOOlOb (Common PIN required for access)
Output Length=length of group name
Read Audit Trail Info (12H)
Output data=group name
Transmit data
Notes:
12H, Common PIN
45
The group name length is a maximum of 16 bytes. All
Receive data
byte values are legal in a group name.
CSB=O if command successful, appropriate error code
Delete Group (OFH)
otherwise
Transmit data
Output length=audit trail structure size (5) if successful, 0
OFH, Group ID, Group PIN
50
otherwise
Receive data
Output data=audit trail info structure if successful, 0
CSB=O if successful, appropriate error code otherwise
otherwise
Output length=O
Notes:
If the transmitted Common PIN is valid and the secure
Output data=O
55 module has been locked, it returns audit trail configuration
Notes:
information as follows:
If the group PIN and group ID are correct the secure
Number of used transaction records (2 bytes)
module will delete the specified group. Deleting a group
causes the automatic destruction of all objects within the
Number of free transaction records (2 bytes)
group. If the secure module has been locked the Delete 60
A boolean specifying whether or (1 byte)
Group command will fail.
not the audit trail rolled
Possible error codes for the delete group command:
since previous read command
Possible error codes for the read audit trail info command:
ERR_BAD_COMMON_PIN (Common PIN was
ERR BAD GROUP PIN
(Incorrect group PIN)
incorrect)
65
ERR BAD GROUP ID
(Specified group does
not exist)
ERR_MIAC_NOT_LOCKED (Secure module is not
locked)

5,940,510

19

20

Read Audit Trail (13H)
Transmit data
13H, Common PIN
Receive data
CSB=O if command successful, appropriate error code 5
otherwise
Output length=# of new records * 6 if successful, 0
otherwise
Output data=new audit trail records
10
Notes:
If the transmitted common PIN is valid and the secure
module has been locked, it will transfer all new transaction
records to the host.
Possible error codes for the read audit trail command:
15
ERR BAD COMMON_PIN
ERR MIAC NOT_LOCKED

(Common PIN was
incorrect)
secure module is not locked
20

Read Group Audit Trail (14H)
Transmit data
14H, Group ID, Group PIN
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=# or records for group * 6 if successful, 0
otherwise
Output data=audit trail records for group
Notes:
This command is identical to the read audit trail
command, except that only records involving the group ID
specified in the transmit data are returned to the host. This
allows transaction groups to record track their own activities
without seeing other groups records.
Possible error codes for the read group audit trail command:

25

30

35

40
ERR BAD GROUP ID
ERR BAD GROUP PIN
ERR MIAC NOT_LOCKED

(Group ID does not
exist)
(Common PIN was
incorrect)
(The secure module is
not locked)

Read Real Time Clock (1SH)
Transmit data
1SH, Common PIN
Receive data
CSB=O if the common PIN matches and ERR_BAD
COMMON_PIN otherwise
Output length=4
Output data=4 most significant bytes of the real time
clock
Notes:
This value is not adjusted with a clock offset. This
command is normally used by a service provider to compute
a clock offset during transaction group creation.
Read Real Time Clock Adjusted (16H)
Transmit data
16H, Group ID, Group PIN, ID of offset object
Receive data
CSB=O if successful, appropriate error code otherwise
Output length=4 if successful, 0 otherwise
Output data=Real time clock+clock offset ID

45

50

55

60

Notes:
This command succeeds if the group ID and group PIN
are valid, and the object ID is the ID of a clock offset. The
secure module adds the clock offset to the current value of
the 4 most significant bytes of the RTC and returns that value
in the output data field. Note that a transaction script may be
written to perform the same task and put the result in the
output data object.
Possible error codes for the real time clock adjusted
command:
ERR BAD GROUP _PIN
ERR BAD GROUP_ID
ERR BAD OBJECT_TYPE

(Incorrect group PIN)
(Specified group does
not exist)
(Object ID is not a
clock offset)

Get Random Data (17H)
Transmit data
17H, Length (L)
Receive data
CSB=O if successful, appropriate error code otherwise
Output length=L if successful, 0 otherwise
Output data=L bytes of random data if successful
Notes:
This command provides a good source of cryptographically useful random numbers.
Possible error codes for the get random data command
are:
ERR_BAD_SIZE (Requested number of bytes>128)
Get Firmware Version ID (18H)
Transmit data
18H
Receive data
CSB=O
Output length=Length of firmware version ID string
Output data=Firmware version ID string
Notes:
This command returns the firmware version ID as a Pascal
type string (length+data).
Get Free RAM (19H)
Transmit data
19H
Receive data
CSB=O
Output length=2
Output data=2 byte value containing the amount of free
RAM
Notes:
If the secure module has been locked the output data bytes
will both be 0 indicating that all memory not used by
transaction groups has been reserved for the audit trail.
Change Group Name (1AH)
Transmit data
1AH, Group ID, Group PIN, New Group name
Receive data
CSB=O if successful or an appropriate error code otherWIse

65

Output length=O
Output data=O
Notes:
If the group ID specified exists in the secure module and
the PIN supplied is correct, the transaction group name is
replaced by the new group name supplied by the host. If a

5,940,510

21

22

group ID of 0 is supplied the PIN transmitted must be the
common PIN. If it is correct, the secure module name is
replaced by the new name supplied by the host.
Possible error codes for the change group name command:

ERR_MIAC_NOT_LOCKED (88H)

5

If the secure module has not been locked there is no audit
trail. If one of the audit trail commands is executed this error
code will be returned.

ERR_GROUP_LOCKED (89H)
ERR BAD GROUP PIN
ERR BAD GROUP ID
ERR BAD NAME LENGTH

(Incorrect group PIN)
(Specified group does
not exist)
(New group name> 16 bytes)

10

Once a transaction group has been locked object creation
within that group is not possible. Also the objects attributes
and types are frozen. Any attempt to create objects or modify
their attribute or type bytes will generate an ERR
GROUP_LOCKED error code.

ERROR CODE DEFINITIONS
ERR_BAD_COMMAND (80H)

15

This error code occurs when the secure module firmware
does not recognize the command just transmitted by the
host.

When the host sends a create object command to the
secure module, one of the parameters it supplies is an object
type (see command section). If the object type is not
recognized by the firmware it will return an ERR_BAD_
OBJECT_TYPE error code.

20

This error code will be returned when a command
requires a common PIN and the PIN supplied does not match
the secure module's common PIN. Initially the common PIN
is set to O.

Transaction groups may have their own PIN, FIG. 6. If
this PIN has been set (by a set group PIN command) it must
be supplied to access any of the objects within the group. If
the Group PIN supplied does not match the actual group
PIN, the secure module will return the ERR_BAD
GROUP_PIN error code.
ERR_BAD_PIN_LENGTH (83H)
There are 2 commands which can change PIN values. The
set group PIN and the set common PIN commands. Both of
these require the new PIN as well as the old PIN. The
ERR_BAD_PIN_LENGTH error code will be returned if
the old PIN supplied was correct, but the new PIN was
greater than 8 characters in length.

25

ERR_BAD_SIZE (8CH)
30

All commands that operate at the transaction group level
require the group ID to be supplied in the command packet.
If the group ID specified does not exist in the secure module
it will generate an ERR_BAD_GROUP_ID error code.
40

45

The create transaction group and create object commands
return this error code when there is not enough heap available in the secure module.

If a script object that executes financial transactions is
invoked and the value of the money register is less than the
withdrawal amount requested an ERR_INSUFFICIENT_
FUNDS error code will be returned.

55

60

ERR_MIAC_LOCKED (87H)
When the secure module has been locked, no groups or
objects can be created or destroyed. Any attempts to create
or delete objects will generate an ERR_MIAC_LOCKED
error code.

All commands that operate at the object level require the
object ID to be supplied in the command packet. If the object
ID specified does not exist within the specific transaction
group (also specified in the command packet) the secure
module will generate an ERR_BAD_OBJECT_ID error
code.
ERR_INSUFFICIENT_FUNDS (8FH)

50

When the create transaction group command is executed,
one of the data structures supplied by the host is the group's
name. The group name may not exceed 16 characters in
length. If the name supplied is longer than 16 characters, the
ERR_BAD_NAME_LENGTH error code is returned.

An ERR_BAD_SIZE error code is normally generated
when creating or writing an object. It will only occur when
the object data supplied by the host has an invalid length.

35

ERR_BAD_OPTION_BYTE (84H)
The option byte only applies to the common PIN. When
the set common PIN command is executed the last byte the
host supplies is the option byte (described in command
section). If this byte is unrecognizable to the secure module,
it will return the ERR_BAD OPTION_BYTE error code.

When the host sends a create object command to the
secure module, one of the parameters it supplies is an object
attribute byte (see command section). If the object attribute
byte is not recognized by the firmware it will return an
ERR_BAD OBJECT_ATTR error code.

65

Locked objects are read only. If a write object command
is attempted and it specifies the object ID of a locked object
the secure module will return an ERR OBJECT
LOCKED error code.

Private objects are not directly readable or writable. If a
read object command or a write object command is
attempted, and it specifies the object ID of a private object,
the secure module will return an ERR OBJECT
PRIVATE error code.

5,940,510

23

24

ERR_OBJECT_DESTRUCTED (92H)

What is claimed is:
1. A system for communicating data securely, comprising:
a first portable module comprising:
a nonvolatile memory for storing a first data;
a first real time clock circuit for time stamping data
transactions;
a counter for counting a transaction count;
an input/output circuit;
a substantially unique electronically readable identification number readable by said input/output circuit;
and
a memory control circuit in electrical communication
with said nonvolatile memory, said real time clock,
said counter, and said input/output circuit;
a portable module reader that can be placed in communication with said first portable module, said portable
module reader can be connected to a plurality of other
devices;
a secure microcontroller based module in electronic communication with said portable module reader, said
secure micro controller comprising:
a micro controller core;
a math coprocessor, in communication with said microcontroller core, for processing encryption calculations;
an energy circuit for storing energy;
a memory circuit connected to said microcontroller
core;
a memory circuit in communication with said microcontroller core; and
a second real time clock circuit in communication with
said microcontroller,
said combination of said portable module reader and said
secure microcontroller performing secure data transfers
with said first portable module.
2. The system for communicating data securely of claim
1, wherein said plurality of other devices includes at least
one of a credit card reader, a cash machine, an automatic
teller machine, and a phone line.
3. The system for communicating data securely of claim
1, wherein said first data is a packet of encrypted data.
4. The system for communicating data securely of claim
1, wherein said first portable module communicates with
said portable module reader via a single wire bus comprising
a single bidirectional communication wire and a ground
connection.
5. The system for communicating data securely of claim
1, wherein said first module can create random publici
private key sets for encryption purposes.
6. The system for communicating data securely of claim
1, wherein said secure microcontroller can create random
public/private key sets for encryption purposes.

If an object is destructible and the transaction group's
destructor is active the object may not be used by a script.
If a script is invoked which uses an object which has been 5
destructed, an ERR_OBJECT_DESTRUCTED error code
will be returned by the secure module.
The exemplary embodiment of the present invention is
preferably placed within a durable stainless steel, token-like 10
can. It is understood that an exemplary secure module can be
placed in virtually any articulatable item. Examples of
articulatable items include credit cards, rings, watches,
wallets, purses, necklaces, jewelry, ID badges, pens,
clipboards, etc.
15
The secure module 108 preferably is a single chip "trusted
computer". By the word "trusted" it is meant that the
computer is extremely secure from tampering by unwarranted means. The secure module incorporates a numeric
coprocessor optimized for math intensive encryption. The
BIOS is preferably immune to alteration and specifically
designed for very secure transactions.

20

Each secure module can have a random "seed" generator
with the ability to create a private/public key set. The private 25
key never leaves the secure module and is only known by the
secure module. Furthermore, discovery of the private key is
prevented by active self-destruction upon wrongful entry
into the secure module. The secure module can be bound to 30
the user by a personal identification number (PIN).
When transactions are performed by the secure module
108 certificates of authentication are created by either or
both the secure module and a system the secure module
communicates with. The certificate can contain a variety of
information. In particular, the certificate may contain:

35

1) who is the secure module user via a unique registration
number and a certified public key.
2) when the transaction took place via a true-time stamp- 40
ing of the transaction.
3) where the transaction took place via a registered secure
module interface site identification.
4) security information via uniquely serialized transac- 45
tions and digital sign on message digests.
5) secure module status indicated as valid, lost, or expired.
Although a preferred embodiment of the method and
apparatus of the present invention has been illustrated in the
accompanying Drawings and described in the foregoing 50
Detailed Description, it will be understood that the invention
is not limited to the embodiment disclosed, but is capable of
numerous rearrangements, modifications and substitutions
without departing from the spirit of the invention as set forth
and defined by the following claims.

* * * * *

UNITED STATES PATENT AND TRADEMARK OFFICE

CERTIFICATE OF CORRECTION
PATENT NO.

5,940,510

DATED

Aug. 17, 1999

INVENTOR(S) :

Curry et al.

It is certified that error appears in the above-identified patent and that said Letters Patent is hereby
corrected as shown below:

On the title page, item:

Item [57], line 1

Replace 'rotates"
With --relates--

Signed and Sealed this
Twenty-second Day of February, 2000

Attest:

Q. TODD DICKINSON

'Westing Officer

Commissioner (If Pate"ts

WId

Trademarks