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 B
UNITED STATES PATENT NO.
5,949,880

111111

United States Patent

US005949880A

TRANSFER OF VALUABLE INFORMATION
BETWEEN A SECURE MODULE AND
ANOTHER MODULE

[75]

Appl. No.: 08/978,798

[22]

Filed:

Date of Patent:

[56]

5,003,594
5,539,825
5,546,463
5,577,121
5,621,796
5,642,419
5,671,280

3/1991
7/1996
8/1996
11/1996
4/1997
6/1997
9/1997

Shinagawa ................................
Akiyama et al. .........................
Caputo et al. ............................
Davis et al. ..............................
Davis et al. ..............................
Rosen ........................................
Rosen ........................................

380/24
380/24
380/25
380/24
380/24
380/23
380/24

Primary Examiner-Thomas H. Tarcza
Assistant Examiner-Carmen D. White
Attorney, Agent, or Firm-Jenkens & Gilchrist

Nov. 26, 1997

[57]

Related U.S. Application Data
[62]

Division of application No. 08/594,975, Jan. 31, 1996.

[51]

Int. CI. 6

[52]

U.S. CI. ................................. 380/24; 380/25; 705/39;
705/42

[58]

Field of Search .................................. 380/23,24,25;
705/39, 40, 42

........................................................

114~

References Cited
U.S. PATENT DOCUMENTS

Assignee: Dallas Semiconductor Corporation,
Dallas, Tex.

[21]

5,949,880
Sep. 7, 1999

Patent Number:

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

[73]

[11]

[45]

[19]

Curry et ai.
[54]

1111111111111111111111111111111111111111111111111111111111111

H04L 9/00

110~

.---~~---,

.-~-----,

CREDIT CARD
READER

CASH
ACCEPTOR

ABSTRACT

The present invention relates 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 Claims, 8 Drawing Sheets

/112
AUTO~ATlC

TELLER
MACHINE

/116

PHONE
LINE

~-t--~t----------~
1
SECURE
1
PORTABLE t------III
MICROPROCESSOR
MICROPROCESSOR 1
MODULE
l'~ I :
BASED \ DEVICE
BASED \ DEVICE
1
106
L _ _ _ - \ _ _ _ _ _ _ _ _ . _ _ --.J
_
\
102
104
108

u.s.

Patent

114

112

110

CREDIT CARD
READER

AUTOK4ATIC
TELLER
MACHINE

CASH
ACCEPTOR

1-----1

106
102

I

I

116
PHONE
LINE

----------1

rI
PORTABLE
MODULE

5,949,880

Sheet 1 of 8

Sep.7,1999

I

MICROPROCESSOR
SECURE
BASED DEVICE --~MICROPROCESSOR
BASED DEVICE

I

I
I

_ _ -1

104

FIG. 1

108

u.s.

Patent

i

5,949,880

Sheet 2 of 8

Sep.7,1999

ID NUMBER

210
;212
I

;204

;202
MEMORY

I

IOUTPUT BUFFERI

MEMORY
CONTROL

I

SCRATCH BAD
MEMORY

I INPUT BUFFER I
INPUT/OUTPUT
CONTROL

ICOUNTE~

~ ONE-WIRE

INTERFACE \

Y TIMER J
"'214

206
PORTABLE MODULE

208

FIG. 2

u.s.

Patent

Sep.7,1999

5,949,880

Sheet 3 of 8

UNIQUE ID NUMBER

t

/v--CLOCK

MICRO PROCESSOR

-1 4

I--

/

12 -

~

CONTROL
"MATH COPROCESSOR

18 -

/'

r--

I---'"'

-

ROM
NVRAM

"--- -1 6
f'-- r-- -2 2

"" I- --20

""'- r-- -2 4

OUTPUT BUFFER

28 -

I--'"'

30 -

I--'"'

26 -

I--'"'

32 -

I--'"'

/'

INPUT BUFFER

/
/"

T

V
ENERGY /

./

CIRCUITRY

ONE-WIRE
INTERFACE

MODULE

FIG. 3

8

e--

34

u.s.

Patent

Sep.7,1999

MICROPROCESSOR
BASED DEVICE

PORTABLE MODULE

CONTAINS:

SECURE MODULE

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

_

(DID NUMBER

<V TRANSACTION

5,949,880

Sheet 4 of 8

COUNTER

COUNT

(J) ENCRYPTED DATA PACKET __
AjlD NUMBER
B TRANSACTION COUNT
C MONETARY VALUE

X1

X3---

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

t
DECRYPT ENCRYPTED
DATA USING A
---- - - - - - r -KEY- - - - '
PUBLIC X4 - '

t

XS---

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

t
X6---

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

t

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

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

t

u.s.

Patent

PORTABLE MODULE

Sep.7,1999

5,949,880

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

Xl0

--

RECEIVE ENCRYPTED
DATA-TWO

FIG. 4
(CONTINUED)

Xll

X12

t

--

RECEIVE ENCRYPTED
DATA-TWO AND
STORE IN MEMORY

-

INCREMENT TRANSACTION
COUNTER

t

u.s.

Patent

Sep.7,1999

MICROPROCESSOR
BASED DEVICE

PORTABLE MODULE
CONTAINS:

CD ID

r----

NUMBER

CV TRANSACTION

COUNTER

SECURE MODULE

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

COUNT

5,949,880

Sheet 6 of 8

Q) ENCRYPTED DATA PACKET

---- Y1
A) ID NUMBER
B~ TRANSACTION COUNT
C MONETARY VALUE

~

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

,

Y4

DECRYPT ENCRYPTED DATA
USING A PUBLIC KEY

t

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

t

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

t
Y12--

Y13--

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

t

t
Y11--

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

RECEIVE ENCRYPTED
DATA-TWO AND
STORE IN MEMORY

,

INCREMENT TRANSACTION
COUNTER

FIC. 5

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

,

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

t

u.s.

Patent

Sep.7,1999

5,949,880

Sheet 7 of 8

READ/WRITE OBJECT COMMANDS
MODULE
108

,-

PIN
MATCH

4\

LOCKED
TRANSACTION
GROUP

I'--t-

40

~O~jf~TS (O)~

HSCRIPTS:

I'--t- 42

IPRIVATE (P)~
IOBJECTS

t- 42

~LOCKED ()~ I'--t- 42
OBJECTS L
READ-ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP

l-WIRE

I/O

-

DATA
TRANSPORT
f- LAYER

~

COMMAND
INTERPRETER

-40

r-1 O~jf~TS (0)1

PIN
MATCH
HSCRIPTSI

IPRIVATE (p)1
IOBJECTS

()I

YLOCKED
OBJECTS L

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

-

- 40

r-1 O~f~TS (0)1

PIN
MATCH
HSCRIPTS:

IPRIVATE (p)1
IOBJECTS

~LOCKED
OBJECTS

()\
L

READ ONLY OBJECT COMMAND

FIG. 6

u.s.

Patent

Sep.7,1999

5,949,880

Sheet 8 of 8

I/O DATA BUFFERS
SYSTEM DATA
COMMON PIN, RANDOM
NUMBER REGISTER, ETC ...

oUTP UT DAA
T

TRANSACTION GROUP
OBJECT #1

OUTPUT DATA OBJECT #2
WORKING REGISTER

40
40

---

GROUP NAME,
PASSWORD AND ATTRIBUTES
OBJECT 1
OBJECT 2

-

42

-

42

TRANSACTION GROUP 1

·

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
10

ONCE LOCKED ALL
UNUSED RAM IS
ALLOCATED FOR
THE AUDIT TRAIL

FIG. 7

OBJECT
ID

DATE/TIME
STAMP

5,949,880
1

2

TRANSFER OF VALUABLE INFORMATION
BETWEEN A SECURE MODULE AND
ANOTHER MODULE

based device. The portable module can be carried by a
consumer, filled with electronic money at an add-money
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.

This application is a Divisional of application Ser. No.
08/594,975 filed on Jan. 31, 1996.

CROSS REFERENCE TO OTHER
APPLICATIONS

5

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method and appaThe following applications of common assignee contains 10 ratus of the present invention may be had by reference to the
following Detailed Description when taken in conjunction
related subject matter and is hereby incorporated by referwith the accompanying Drawings wherein:
ence:
FIG. 1 depicts an exemplary system for transferring
Ser. No. UNKNOWN, filed Jan. 31, 1996, entitled
valuable information between a module and a secure device;
METHOD, APPARATUS, SYSTEM AND FIRMWARE 15
FIG. 2 is a block diagram of an embodiment of a portable
FOR SECURE TRANSACTIONS; and
module;
Ser. No. UNKNOWN, filed Jan. 31, 1996, entitled
FIG. 3 is a block diagram of an embodiment of a
METHOD, APPARATUS AND SYSTEM FOR TRANSmicroprocessor based module;
FERRING UNITS OF VALUE.
20
FIG. 4 is an exemplary technique for transferring valuable
BACKGROUND OF THE INVENTION
data securely into a portable module;
FIG. 5 is an exemplary technique for transferring valuable
1. Technical Field of the Invention
data securely out of a portable module;
The present invention relates to a method and system for
FIG. 6 is an exemplary organization of the software and
transferring valuable information securely between a secure
module and another module. More particularly, the present 25 firmware within a secure microprocessor based device; and
FIG. 7 is an exemplary configuration of software and
invention relates to transferring units of value between a
firmware within a secure microprocessor based device.
microprocessor based secure module and another module
used for carrying a monetary equivalent.
DETAILED DESCRIPTION OF A PRESENTLY
2. Description of Related Art
PREFERRED EXEMPLARY EMBODIMENT
In the past the preferred means for paying for an item was 30
FIG. 1 depicts a block diagram of an exemplary system
cash. As our society has become more advanced, credit cards
100 for transferring valuable information to and from a
have become an accepted way to pay for merchandise or
portable module. A portable module 102, which will be
services. The payment is not a payment to the merchant, but
described in more detail later, communicates to a microproinstead is a credit given by a bank to the user that the
cessor based device 104. The portable module 102 may
merchant accepts as payment. The merchant collects money 35 contain information that represents units of exchange or a
from the bank based on the credit. As time goes on, cash is
currency equivalent. The microprocessor based device 104
used less and less, and money transfers between parties are
can be any of an unlimited number of devices. For example,
becoming purely electronic.
the microprocessor based device 104 could be a personal
Present credit cards have magnetic strips to identify the
computer, an add-a-fare machine at a train or bus station
owner of the card and the credit provider. Some credit cards 40 (similar to those in today's District of Columbia metro
have electronic circuitry installed that identifies the credit
stations), a turn style, a toll booth, a bank's terminal, a ride
card owner and the credit or service provider (the bank).
at a carnival, a washing machine at a Laundromat, a locking
The magnetic strips installed in present credit cards do not
device, a mail metering device or any device that controls
enable the card to be used as cash. That is the modern credit 45 access, or meters a monetary equivalent, etc.
card does not allow the consumer to buy something with the
The means for communication 106 between the portable
credit card and the merchant to receive cash at the time of
module 102 and the microprocessor based device 104 is
the transaction. Instead, when the consumer buys something
preferably via a single wire or contact connection. The
on credit, the merchant must later request that the bank pay
single wire connection 106 preferably incorporates a comfor the item that the consumer bought. The bank then bills 50 munication protocol that allows the portable module 102 and
the consumer for the item that was bought.
the microprocessor based device 104 to communicate in a
Thus, there is a need for an electronic system that allows
bidirectional manner. Preferably the communication protoa consumer to fill an electronic module with a cash equivacol is a one-wire protocol developed by Dallas Semiconlent in the same way a consumer fills his wallet with cash.
ductor. It is understood that the means for communicating
When the consumer buys a product or service from a 55 106 is not limited to a single wire connection. The commumerchant, the consumer's module can be debited and the
nication means 106 could be multiple wires, a wireless
merchant's cash drawer can be credited without any further
communication system, infrared light, any electromagnetic
transactions with a bank or service provider.
means, a magnetic technique, or any other similar technique.
The microprocessor based device 104 is electrically conSUMMARY OF THE INVENTION
60 nected to another microprocessor based device, which is
preferably a secure device 108. The term secure device
The present invention is an apparatus, system and method
for communicating a cash equivalent electronically to and
means that the device is designed to contain a secret code
from a portable module. The portable module can be used as
and the secret code is extremely difficult to learn. An
a cash equivalent when buying products and services in the
example of a secure device 108 is explained later in this
market place.
65 document.
The present invention comprises a portable module that
The microprocessor based device 104 can be connected to
can communicate to a secure module via a microprocessor
a variety of other devices. Such devices include, but are not

5,949,880

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,949,880

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 is information between the secure mod- 15 which is independent of every other transaction group 40.
ule 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 108 and its
action group 40, to which it applies, is deleted from the
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,949,880
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 the Secure Module lOS and Portable
module lOS using a private key X9.
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 U nits of Exchange Out of a Portable Module
packet and stores it in memory X11. The 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 is module
at the present time Xl.
102 could be another secure module similar to the secure
module in the system, but programed to act like a portable
The user of the portable module touches, or somehow puts
the portable module 102 into communication with the
module 102.
microprocessor based device 104. For explanation purposes, 30 B. Transferring Units of Exchange Into the Portable Module
102
suppose the portable module 102 is being used as a token
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
counterfeit. The secure module lOS compares the serial
The microprocessor based device 104 passes the module's
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
determined to be valid data, the secure module lOS subtracts
Y6. If the serial numbers and transaction counters match,
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,949,880

9

10

same amount that the monetary value of the decrypted data
exponents can be either private or public. When RSA
exponents are created in the secure module, they may be
was increased YS.
The secure module lOS creates a second data packet, that
declared as either. Once created an exponent may be
contains the portable module's ID number, the incremented
changed from a public exponent to a private exponent.
After an exponent has been made private, however, it will
transaction counter and the increased monetary value. The 5
second data packet is then encrypted using a private key
remain private until the transaction group 40 to which it
Y10.
belongs is destroyed.
The microprocessor based device 104 reads the encrypted
Transaction Script A transaction script is a series of instrucsecond data packet and sends it to the portable module 102
tions to be carried out by the secure module. When
Yll. The portable module receives the encrypted second 10
invoked the secure module firmware interprets the
data packet and stores it in memory Y12. The portable
instructions in the script and places the results in the
module also advances its transaction counter Y13. The result
output data object (see below). The actual script is simply
being that the portable module now has the value of the cash
a list of objects. The order in which the objects are listed
withdrawn from the ATM 112. Furthermore, a record of the
specifies the operations to be performed on the objects.
transaction may have been recorded and kept in the secure 15
transaction scripts 44 preferably may be as long as 128
module, as well as by the bank that operates the ATM 112.
bytes.
Exemplary Firmware Definitions for Use With the Secure
Transaction Counter The transaction counter object is prefModule
erably 4 bytes in length and is usually initialized to zero
Object The most primitive data structure accepted by and
when it is created. Every time a transaction script, which
operated on by the secure modules firmware. A list of 20
references this object, is invoked, the transaction counter
increments by 1. Once a transaction counter has been
valid objects and their definitions is provided in the next
section.
locked it is read only and provides an irreversible counter.
Group A self-contained collection of objects. An object's
Money Register The money register object is preferably 4
bytes in length and may be used to represent money or
scope is restricted to the group of which it is a member.
Group ID A number preferably between 0 and 255 repre- 25
some other form of credit. Once this object has been
created, it must be locked to prevent a user from tampersenting a specific group.
ing with its value. Once locked the value of this object can
Object ID A number preferably between 0 and 255 representing a specific object within a specific group.
be altered only by invoking a transaction script. A typical
Object Type Preferably a I-byte type specifier that describes
transaction group 40 which performs monetary transac30
a specific object.
tions might have one script for withdrawals from the
PIN An alphanumeric Personal Identification number that is
money register and one for deposits to the money register.
preferably eight bytes in length.
Clock Offset This object is preferably a 4 byte number which
contains the difference between the reading of the secure
Common PIN The PIN that controls access to shared
resources such as the audit trail. It is also used to control
module's real-time clock and some convenient time (e.g.,
35
12:00 a.m., Jan. 1, 1970). The true time can then be
the host's ability to create and delete groups.
Group PIN The PIN that controls access to operations
obtained from the secure module by adding the value of
the clock offset to the real-time clock.
specific to objects within a group.
SALT A SALT object is preferably 20 bytes in length and
Audit Trail A record of transactions occurring after the
secure module has been locked.
should be initialized with random data when it is created.
Locked Object An object which has been locked by execut- 40
When a host transmits a generate random SALT
ing the lock object command. Once an object is locked it
command, the secure module combines the previous
SALT with the secure module's random number
is not directly readable.
(produced preferably by randomly occurring power-ups)
Private Object An object which has been privatized by
to generate a new random SALT. If the SALT object has
executing the privatize object command. Once an object
45
is private, it is not directly readable or writable.
not been privatized it may subsequently be read by issuing
a read object command.
Locked Group A group which has been locked using the
Configuration Data This is a user defined structure with
locked group command. After a group has been locked it
preferably a maximum length of 128 bytes. This object is
will not allow object creation.
Composite Object A combination of several objects. The
typically used to store configuration information specific
individual objects inherit the attributes of the composite 50
to its transaction group 40. For example, the configuration
object.
data object may be used to specify the format of the
Exemplary Object Definitions
money register object (i.e., the type of currency it
RSAModulusAlarge integer preferably of at most 1024 bits
represents). Since this object has no pre-defined structure,
in length. It is the product of 2 large prime numbers that
it may never be used by a transaction object.
are each about half the number of bits in length of the 55 Input Data An input data object is simply an input buffer
with preferably a maximum length of 128 bytes. A transdesired modulus size. The RSA modulus is used in the
following equations for encrypting and decrypting a mesaction group may have multiple input objects. The host
sage M:
uses input data objects to store data to be processed by
transaction scripts 44.
Encryption: C~Me (mod N)
(1) 60 Output Data The output data object is used by transaction
scripts as an output buffer. This object is automatically
Decryption: M~Cd (mod N)
(2)
created when the transaction group is created. It is prefwhere C is the cyphertext, d and e are the RSA exponents
erably 512 bytes in length and inherits password protec(see below), and N is the RSA modulus.
tion from its group.
RSA Exponent Both e and d (shown in equations 1 and 2 65 Random Fill When the script interpreter encounters this type
of object it automatically pads the current message so that
above) are RSA exponents. They are typically large
numbers but are smaller than the modulus (N). RSA
its length is 1 bit smaller than the length of the preceding

5,949,880
11

12

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.
Working Register 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.
ROM Data 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™.
Preferred Secure Module Firmware Command Set

-continued

Set Common PIN(OlH)
Transmit (to secure module)
OlH, old PIN, new PIN, PIN option byte
Receive data
CSB (command status byte) ~ 0 if successful,
appropriate error code otherwise
Output length ~ 0
Output Data ~ 0

Notes:
The PIN option byte may be the bitwise-or of any of the
following values:
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
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:
ERR BAD COMMON_PIN
ERR BAD PIN_LENGTH

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

Master Erase (02H)

5

Notes:
If the LSB (least significant bit) of the PIN option is clear
(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
15 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
all objects within the groups. The common PIN and common
PIN option byte are both reset to zero.
20
After everything has been erased the secure module
transmits the return packet. The CSB is as described above.
The output data length and output data fields are both set to
O.
10

25
Create Group (03H)
Transmit data
03H, Common PIN, Group name, Group PIN
Receive data
30
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ Group !D if successful, 0
otherwise

35

40

45

Output data length
Output data

55

ERR INSUFFICIENT_RAM

(Incorrect common PIN)
(If group name length> 16
bytes)
(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 !D, old GPIN, new GPIN
Receive data
CSB ~ 0 if command successful, appropriate
60 error code otherwise
Output length ~ 0
Output data ~ 0

Master Erase (02H)
Transmit data
02H, Common PIN

ERR BAD COMMON_PIN
ERR BAD NAME_LENGTH

ERR MIAC_LOCKED

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:
(0 if command successful,
error code otherwise, 1 byte)
(Command output length, 2
bytes)
(Command output, length
specified above).

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

ERR BAD PIN_LENGTH

50

Command status byte

Receive data
CSB = 0 if command was successful,
ERR_BAD COMMON_PIN otherwise
Output length ~ 0
Output data ~ 0

65

Notes:
The Group PIN only restricts access to objects within the
group specified by the group ID transmitted in the command
packet.

5,949,880

13

14

Possible error codes for the set group PIN command:

-continued
Lock Object (06H)

ERR BAD GROUP PIN
ERR BAD PIN_LENGTH

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

Create Object (05H)
Transmit data
05H, Group ID, Group PIN, Object type, Object
attributes, Object data
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ object ID if successful, 0
otherwise

5

error code otherwise
Output length ~ 0
Output data ~ 0

10

Notes:
If the Group ID, Group PIN and Object ID are all correct,
the secure module will lock the specified object. Locking an
object is an irreversible operation.
Possible error return codes for the lock object command:

15

ERR BAD GROUP PIN
ERR GROUP LOCKED
ERR MIAC LOCKED
ERR BAD GROUP ID

20

Notes:
If the Create Object command is successful the secure
module firmware returns the object's ID within the group
specified by the Group ID. If the PIN supplied by the host
was incorrect or the group has been locked by the Lock
Group command (described below) the secure module
returns an error code in the CSB. An object creation will also
fail if the object is invalid for any reason. For example, if the
object being created is an RSA modulus (type 0) and it is
greater than 1024 bits in length. transaction script creation
will succeed if it obeys all transaction scripts rules.
Possible error return codes for the create object command:
(Incorrect group PIN)
(The group has been
locked)
ERR MIAC LOCKED
(The secure module has
been locked)
ERR INVALID_TYPE
(The object type
specified is invalid)
ERR BAD SIZE
(The objects length
was invalid)
ERR INSUFFICIENT_RAM
(Not enough memory for
new object)
Object types:
RSA modulus
0
RSA exponent
Money register
2
Transaction counter
3
Transaction script
4
Clock offset
5
Random SALT
Configuration object
7
Input data object
S
Output data object
9
Object Attributes:
Locked
00000001b
Privatized
00000010b

25
Privatize Object (07H)
Transmit data
07H, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if successful, appropriate error code
30 otherwise

35

ERR BAD GROUP PIN
ERR GROUP LOCKED

40

45

ERR BAD GROUP PIN
ERR GROUP LOCKED

ERR BAD GROUP ID
50

(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)

Make Object Destructable (OSH)

Transmit data
OSH, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if successful, appropriate error code
60 otherwise

Lock Object (06H)
Transmit data
06H, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if command successful, appropriate

Notes:
If the Group ID, Group PIN and Object ID were valid the
object will be privatized. Privatized objects share all the
properties of locked objects but are not readable. Privatized
objects are only modifiable through transaction scripts. Note
that locking a privatized object is legal, but has no meaning
since object privatization is a stronger operation than object
locking. Privatizing an object is an irreversible operation.
Possible error return codes for the privatize object command:

ERR MIAC LOCKED

55

Objects may also be locked and privatized after creation
by using the Lock Object and Privatize Object commands
described below.

(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)

65

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

5,949,880
15

16

bit has no affect. Making an object destructable is an
irreversible operation.
Possible error return codes for the make object destructable command:

-continued
Lock Group (OAH)

5
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)

10

error code otherwise
Output length ~ 0
Output data ~ 0

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:

15
ERR BAD GROUP PIN
ERR GROUP LOCKED

Lock Secure module (09H)
Transmit data
09H, Common PIN
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 2 if successful, 0 otherwise
Output data = audit trail size if successful,
o otherwise

ERR MIAC LOCKED
20
ERR BAD GROUP ID

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

25
Invoke Transaction Script (OBH)

Notes:
If the host supplied Common PIN is correct and the secure
module has not previously been locked, the command will
succeed. When the secure module is locked it will not accept
any new groups or objects. This implies that all groups are
automatically locked. The RAM not used by the system or
by groups will be used for an audit trail. There is no audit
trail until the secure module has successfully been locked!
An audit trail record is six bytes long and has the
following structure:
Group IDIObject IDIDaterrime 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:
(Supplied common PIN
was incorrect)
(Secure module was
already locked)

Transmit data
OBH, Group ID, Group PIN, Object ID
Receive data
30
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ estimated completion time

35

40

ERR BAD GROUP PIN
ERR BAD GROUP ID

45

50

(Incorrect group PIN)
(Specified group does
not exist)
(Script object did not
exist in group)

Read Object (OCH)

Transmit data
OCH, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
55
Output length ~ object length if successful, 0
otherwise
Output data ~ object data if successful, 0
otherwise

60
Lock Group (OAH)
Transmit data
OAH, Group ID, Group PIN
Receive data
CSB ~ 0 if command successful, appropriate

Notes:
The time estimate returned by the secure module is in
sixteenths of a second. If an error code was returned in the
CSB, the time estimate will be O.
Possible error return codes for the execution transaction
script command:

65

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.

5,949,880
17

18

Possible error codes for the read object command:
ERR_BAD GROUP PIN
ERR_BAD GROUP ID

ERR_OBJECT_PRIVATIZED

(Incorrect group PIN)
(Specified group does
not exist)
(Object did not exist
in group)
(Object has been
privatized)

causes the automatic destruction of all objects within the
group. If the secure module has been locked the Delete
Group command will fail.
Possible error codes for the delete group command:
5
ERR BAD CROUP PIN
ERR BAD GROUP_ID
ERR MIAC_LOCKED
10

(Incorrect group PIN)
(Specified group does
not exist)
(Secure module has
been locked)

Write Object (ODH)
Transmit data
ODH, Group ID, Group PIN, Object ID, Object
size, Object Data
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 0
Output data ~ 0

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:

Get Command Status Info (10H)

15
Transmit data
10H
Receive data
CSB ~ 0
Output length ~ 6
20
Output data = secure module status structure
(see below)

25

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)

30
ERR BAD GROUP PIN
ERR BAD GROUP ID
ERR BAD OBJECT 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)

Get Secure module Configuration Info (l1H)
35

Transmit data
11H
Receive data
CSB ~ 0
Output length ~ 4
Output data = secure module configuration
40 structure

Notes:
This operation requires no PIN and never fails. The
configuration structure is defined as follows:

Read Group Name (OEH)
Transmit data
OEH, Group ID
Receive data
CSB ~ 0
Output Length ~ length of group name
Output data ~ group name

45
Number of groups
Flag byte (see below)
Audit trail size/Free RAM

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

50

The flag byte
values:

Notes:
The group name length is a maximum of 16 bytes. All
byte values are legal in a group name.
55

IS

the bitwise-or of any of the following

00000001b (Secure module is locked)
00000010b (Common PIN required for access)

Delete Group (OFH)
Transmit data
OFH, Group ID, Group PIN
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 0
Output data ~ 0

Notes:
If the group PIN and group ID are correct the secure
module will delete the specified group. Deleting a group

60

Read Audit Trail Info (12H)

Transmit data
12H, Common PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
65
Output length ~ audit trail structure size (5)
if successful, 0 otherwise

5,949,880

19

20

-continued
ERR BAD GROUP_ID

Read Audit Trail Info (12H)
Output data ~ audit trail info structure if
successful, 0 otherwise

ERR PAD GROUP PIN

5

Notes:
If the transmitted Common PIN is valid and the secure
module has been locked, it returns audit trail configuration
information as follows:
(2 bytes)
(2 bytes)
(1 byte)

Number of used transaction records
Number of free transaction records
A boolean specifying whether or
not the audit trail rolled
since previous read command

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

10
Read Real Time Clock (15H)
Transmit data
15H, Common PIN
Receive data
CSB ~ 0 if the common PIN matches and
15
ERR_BAD COMMON_PIN otherwise
Output length ~ 4
Output data ~ 4 most significant bytes of the
real time clock

Possible error codes for the read audit trail info command:
20
ERR BAD COMMON_PIN
ERR MIAC NOT_LOCKED

(Common PIN was
incorrect)
(Secure module is not
locked)

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.

25
Read Real Time Clock Adjusted (16H)

Read Audit Trail (13H)
Transmit data
13H, Common PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ # of new records * 6 if
successful, 0 otherwise
Output data ~ new audit trail records

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:
ERR BAD COMMON_PIN
ERR MIAC NOT_LOCKED

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

Transmit data
16H, Group 10, Group PIN, 10 of offset object
Receive data
CSB ~ 0 if successful, appropriate error code
30
otherwise
Output length ~ 4 if successful, 0 otherwise
Output data ~ Real time clock + clock offset 10

35

40

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:

45
ERR BAD GROUP PIN
ERR BAD GROUP ID
ERR BAD OBJECT_TYPE

Read Group Audit Trail (14H)
Transmit data
14H, Group ID, Group PIN
Receive data
CSB ~ 0 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:

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

50

Get Random Data (17H)
Transmit data
17H, Length (L)
Receive data
CSB ~ 0 if successful, appropriate error code
otherwise
Output length ~ L if successful, 0 otherwise
Output data ~ L bytes of random data if
60
successful

55

65

Notes:
This command provides a good source of cryptographically useful random numbers.
Possible error codes for the get random data command
are:

5,949,880

21

22
ERR_BAD_COMMON_PIN (81H)

(Requested number of bytes
> 128)

5

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.

Get Firmware Version ID (18H)
Transmit data
18H
Receive data
CSB ~ 0
Output length ~ Length of firmware version 10
string
Output data = Firmware version ID string

10

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.

15

Notes:
This command returns the firmware version ID as a Pascal
type string (length+data).
20
Get Free RAM (19H)
Transmit data
19H
Receive data
CSB ~ 0
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.

25

30

35
Change Group Name (lAH)
Transmit data
lAH, Group 10, Group PIN, New Group name
Receive data
CSB = 0 if successful or an appropriate error
code otherwise
Output length ~ 0
Output data ~ 0

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
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 BAD GROUP PIN
ERR_BAD_GRQUP_ID
ERR BAD NAME_LENGTH

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

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

40

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

50

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.

55

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)
60

ERROR CODE DEFINITIONS

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

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.

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.

65

When the host sends a create object command to the
secure module, one of the parameters it supplies is an object

5,949,880

23

24

type (see command section). If the object type is not
recognized by the firmware it will return an ERR_BAD_
OBJECT_TYPE error code.

articulatable items include credit cards, rings, watches,
wallets, purses, necklaces, jewelry, ID badges, pens,
clipboards, etc.
5

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.

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

10

coprocessor optimized for math intensive encryption. The
BIOS is preferably immune to alteration and specifically
designed for very secure transactions.

Each secure module can have a random "seed" generator
with the ability to create a private/public key set. The private
An ERR_BAD_SIZE error code is normally generated
15
key never leaves the secure module and is only known by the
when creating or writing an object. It will only occur when
secure module. Furthermore, discovery of the private key is
the object data supplied by the host has an invalid length.
prevented by active self-destruction upon wrongful entry
into the secure module. The secure module can be bound to
All commands that operate at the transaction group level 20 the user by a personal identification number (PIN).
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.
25

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
30
group (also specified in the command packet) the secure
module will generate an ERR_BAD OBJECT_ID error
code.
ERR_INSUFFICIENT_FUNDS (8FH)

35

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.

40

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.

45

50

55

ERR_OBJECT_DESTRUCTED (92H)
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
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
can. It is understood that an exemplary secure module can be
placed in virtually any articulatable item. Examples of

60

65

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:
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 stamping of the transaction.
3) where the transaction took place via a registered secure
module interface site identification.
4) security information via uniquely serialized transactions 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
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.
What is claimed is:
1. A method for electronically transferring units of
exchange between a first module and a second module,
comprising the steps of:
a. initiating communication between said first module and
an electronic device;
b. passing a first value datum from said first module to
said electronic device;
c. passing said first value datum from said electronic
device to said second module;
d. performing a mathematical calculation on said first
value datum thereby creating a second value datum;
e. passing said second value datum from said second
module to said electronic device;
f. passing said second value datum from said electronic
device to said first module;
g. storing said second value datum in said first module;
and
h. discontinuing communication between said first module and said electronic device.

5,949,880

25
2. The method of claim 1, wherein said first value datum
represents a monetary equivalent.
3. The method of claim 1, wherein said first value datum
is encrypted.
4. The method of claim 1, wherein said second value 5
datum is encrypted.
5. The method of claim 3, wherein the step of performing
a mathematical calculation comprises the steps of:
is
m. decrypting said first value datum with a public key
thereby creating a decrypted value;

26
n. performing at least one of an addition function and a
subtraction function on said decrypted value thereby
creating a value result; and
o. encrypting said value result with a private key thereby
creating said second value datum.
6. The method of claim 1, wherein the step (b) of passing
performed over at least a single conductive contact.

* * * * *

UNITED STATES PATENT AND TRADEMARK OFFICE

CERTIF'ICATE OF CORRECTION
PATENT NO.

5,949,880

DATED

Sep. 7, 1999
Curry et al.

INVENTOR(S);

Page 1 of 2

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

Column 2, line 57

Replace "electroma,gnetic"
With --electro-magnetic--

Column 5, line 15

Before "information"
Remove --is--

Column 8, line 26

Before "module"
Remove --is--

Column 12, line 47

Replace "ERR BAD PIN LENGTH"
With --ERR_BAD_PIN LENGTH--

Column 17, line 34

Replace "ERR BAD OBJECT I~'
With --ERR BAn OBJECT ID--

UNITED STATES PATENT AND TRADEMARK OFFICE

CERTIFICATE OF CORRECTION
PATENT NO.5, 949,880

Page 2 of 2

Sept 7, 1999
INVENTOR(S): Curry et al

DATED

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

Column 20, line 6

Replace 'ERR MIAC NOT LOCKE~'
With --ERR MIAC NOT LOCKED~-

Column 20, line 48

Replace "ERR BAD OBJECT TY..PE"
With --ERR BAD OBJECT TYPE--

Column 21, line 58

Replace "ERR BAD NAME LENGTH"
With --ERR BAD NAME LENGTH--

Signed and Sealed this

Twenty-fifth Day of April, 2000
Attest:

~~
Q. TODD DICKINSON

Attesting Officer

Director of Patents and Trademarks