`
`PNC-JP MORGAN EXHIBIT 1001
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 1 of8
`
`5,949,880
`
`110
`
`112
`
`116
`
`
`
`
`AUTOMATIC
`
`TELLER
`MACHINE
`
` SECURE
`MICROPROCESSOR
`
`BASED DEVICE
`
`
`
`FIG.
`
`1
`
`Page 2 of 24
`
`Page 2 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 2 of8
`
`5,949,880
`
`ID NUMBER
`
`OUTPUT BUFFER
`
`INPUT BUFFER
`
`INPUT/OUTPUT
`CONTROL
`ONE—WRE
`INTERFACE
`
`MEMORY
`CONTROL
`
`MEMORY
`SCRATCH BAD
`MEMORY
`
`COUNTER
`
`TIMER
`
`205
`
`208
`
`PORTABLE MODULE
`
`FIG. 2
`
`Page 3 of 24
`
`Page 3 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 3 of8
`
`5,949,880
`
`UNMUEID NUMBER
`
`CONTROL
`
`OUTPUT BUFFER
`
`INPUT BUFFER
`
`r-
`MATH COPROCESSOR H
`I
`NVRAM
`I
`Er‘.
`- A
`Ii"i'
`
`ONE—WRE
`
`INTERFACE
`
`FIG. 3
`
`Page 4 of 24
`
`Page 4 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 4 of8
`
`5,949,880
`
`PORTABLE MODULE
`
`M'§E§EPDRoDCEE,%’€R
`
`SECURE MODULE
`
`CONTAINS:
`
`0) ID NUMBER
`
`
`
`® TRANSACTION COUNTER
`COUNT
`
`®ENCRYPTED DATA PACKET
`A ID NUMBER
`B
`TRANSACTION COUNT
`C MONETARY VALUE
`
`READ (SERIAL NUMBER,
`TRANSACTION coUNTER,
`AND ENCRYPTED DATA)
`AS DATA-ONE
`
`THE PORTABLE MODULE
`
`READ DATA-ONE AND
`A FIRST AMOUNT OF
`VALUE TO REMOVE FROM
`
`DECRYPT ENCRYPTED
`DATA USING A
`PUBLIC KEY
`
`COMPARE SERIAL NUMBER
`RECEIVED IN DATA-ONE
`WITH SERIAL NUMBER
`IN DECRYPTED DATA
`
`IF THEY MATCH, THEN
`COMPARE TRANSACTION
`COUNTER RECEIVED IN
`DATA-ONE WITH THE
`TRANSACTION COUNT IN
`DECRYPTED DATA
`
`
`
`IF THEY MATCH SUBTRACT
`THE IST AMOUNT FROM
`THE MONETARY VALUE
`FOUND IN THE DECRYPTED
`DATA AND INCREMENT THE
`TRANSACTION COUNTER
`FOUND IN THE DECRYPTED
`DATA
`
`INCREASE THE VALUE REGISTER
`
`
`BY THE SAME AMOUNT THE
`
`
`MONEY VALUE FOUND IN THE
`DECRYPTED DATA WAS
`
`DECREASED
`
`X4
`
`X5
`
`X6
`
`X7
`
`X8
`
`FIG. 4
`
`Page 5 of 24
`
`Page 5 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 5 of8
`
`5,949,880
`
`PORTABLE MODULE
`
`MICROPROCESSOR
`BASED DEWCE
`
`SECURE MODULE
`
`
`
`
`
`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
`
`
`
`
`
`
`
`X‘ I
`
`X10
`
`X12
`
`RECEIVE ENCRYPTED
`DATA—TWO
`
`RECEIVE ENCRYPTED
`DATA—TWO AND
`STORE IN MEMORY
`
`INCREMENT TRANSACTION
`COUNTER
`
`
`
`
`
`
`FIG. 4
`(CONTINUED)
`
`Page 6 of 24
`
`Page 6 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 6 of 8
`
`5,949,880
`
`PORTABLE MODULE
`
`MICROPROCESSOR
`BASED DEVTCE
`
`SECURE MODULE
`
`CONTAINS:
`
`@m NUMBER
`
`READ (SERIAL NUMBER,
`TRANSACTION COUNTER,
`AND ENCRYPTED DATA)
`As DATA—ONE
`
`
`
`READ DATA—ONE AND A FIRST
`AMOUNT OF VALUE TO ADD
`TO THE PORTABLE MODULE
`
`DECRYPT ENCRYPTED DATA
`USING A PUBLIC KEY
`
`COMPARE SERIAL NUMBER
`RECEIVED IN DATA—ONE WITH
`SERIAL NUMBER IN
`DECRYPTED DATA
`
`IF THE SERIAL NUMBERS
`
`MATCH, THEN COMPARE THE
`
`TRANSACTION COUNTER IN
`DATA—ONE WITH THE
`DECRYPTED TRANSACTION
`
`COUNT
`
`
`
`IF THE TRANSACTION COUNTS
`MATCH, THEN ADD THE IST
`AMOUNT OF VALUE TO THE
`MONETARY VALUE FOUND IN
`
`THE DECRYPTED DATA
`
`INCREMENT THE TRANSACTION
`COUNTER FOUND IN THE
`DECRYPTED DATA
`
`Y3
`
`Y4
`
`Y5
`
`Y6
`
`Y7
`
`DECREASE A VALUE REGISTER
`BY THE SAME AMOUNT THE
`MONEY VALUE WAS INCREASED
`
`Y8
`
` B
`
`@TRANsAcTToN COUNTER
`COUNT
`
`®ENCRYPTED DATA PACKET
`A)
`ID NUMBER
`TRANSACTION COUNT
`MONETARY VALUE
`
`C
`
`Y2
`
`Y1
`
`CREATE DATA—TWO COMPRISING
`
`(THE PORTABLE MODULE'S
`SERIAL NUMBER,
`INCREMENTED
`TRANSACTION COUNTER, AND
`INCREASED MONETARY VALUE).
`ENCRYPT DATA—TWO
`
`USING A PRIVATE KEY.
`
`RECEIVE ENCRYPTED
`DATA—TWO
`
`RECEIVE ENCRYPTED
`DATA—TWO AND
`STORE IN MEMORY
`
`INCREMENT TRANSACTION
`COUNTER
`
`FIG. 5
`
`Y1O
`
`Y11
`
`Y12
`
`Y13
`
`Page 7 of 24
`
`Page 7 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 7 of8
`
`5,949,880
`
`COMMAND
`
`LOCKED
`TRANSACTION
`GROUP
`
`READ-ONLY OBJECT COMMAND
`
`READ/WRITE OBJECT COMMANDS
`
`LOCKED
`TRANSACTION
`GROUP
`
`LOCKED
`OBJECTS (L)
`
`READ-ONLY OBJECT COMMAND
`
`READ/WRITE OBJECT COMMANDS
`
`LOCKED
`TRANSACTION
`GROUP
`
`OBJECTS(O)
`
`PRIVATE
`0BJECTS(P)
`
`LOCKED
`OBJECTS(L)
`
`Page 8 of 24
`
`Page 8 of 24
`
`
`
`U.S. Patent
`
`Sep.7, 1999
`
`Sheet 8 of8
`
`5,949,880
`
`TRANSACTION GROUP
`
`GROUP NAME,
`PASSWORD AND ATTRIBUTES
`
`
`
`OBJECT I
`
`OBJECT 2
`
`OBJECT N
`
`
`
`
`
`TRANSACTION RECORD
`
`GROUP OBJECT
`ID
`ID
`
`DATE/TIME
`STAMP
`
`
`
`I/O DATA BUFFERS
`
`SYSTEM DATA
`
`COMMON PIN, RANDOM
`NUMBER REGISTER, ETC...
`
`OUTPUT DATA OBJECT #1
`
`OUTPUT DATA OBJECT #2
`
`WORKING REGISTER
`
`TRANSACTION GROUP 1
`
`TRANSACTION GROUP 2
`
`TRANSACTION GROUP N
`
`AUDIT TRAIL‘
`
`40
`
`
`
`CIRCULAR BUFFER OF
`TRANSACTION RECORDS
`
`*THE AUDIT TRAIL DOES
`NOT EXIST UNTIL THE
`M|CRO—|N—A—CAN
`HAS BEEN LOCKED
`
`THE AUDIT TRAIL
`
`ONCE LOCKED ALL
`UNUSED RAM IS
`ALLOCATED FOR
`
`Page 9 of 24
`
`Page 9 of 24
`
`
`
`5,949,880
`
`1
`TRANSFER OF VALUABLE INFORMATION
`BETWEEN A SECURE MODULE AND
`ANOTHER MODULE
`
`This application is a Divisional of application Ser. No.
`08/594,975 filed on Jan. 31, 1996.
`
`CROSS REFERENCE TO OTHER
`APPLICATIONS
`
`The following applications of common assignee contains
`related subject matter and is hereby incorporated by refer-
`ence:
`
`filed Jan. 31, 1996, entitled
`Ser. No. UNKNOWN,
`METHOD, APPARATUS, SYSTEM AND FIRMWARE
`FOR SECURE TRANSACTIONS; and
`Ser. No. UNKNOWN,
`filed Jan. 31, 1996, entitled
`METHOD, APPARATUS AND SYSTEM FOR TRANS-
`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 equiva-
`lent 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.
`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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`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.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`A more complete understanding of the method and appa-
`ratus 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.
`DETAILED DESCRIPTION OF A PRESENTLY
`PREFERRED EXEMPLARY EMBODIMENT
`
`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 micropro-
`cessor 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 com-
`munication protocol that allows the portable module 102 and
`the microprocessor based device 104 to communicate in a
`bidirectional manner. Preferably the communication proto-
`col is a one-wire protocol developed by Dallas Semicon-
`ductor. It is understood that the means for communicating
`106 is not limited to a single wire connection. The commu-
`nication 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 con-
`nected 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
`
`Page 10 of 24
`
`Page 10 of 24
`
`
`
`5,949,880
`
`3
`limited to a cash acceptor 110, an automatic teller machine
`(ATM) 112, a credit card reader 114, and a phone line 116.
`The cash acceptor 110 is adapted to receive cash in the
`form of currency, such as dollar bills or coins. The cash
`acceptor 110, preferably, determines the value of the
`accepted currency. The cash acceptor 110 communicates to
`the microprocessor based device 104 and informs the device
`104 of how much currency has been deposited in the cash
`acceptor 110.
`The cash acceptor 110 can also be a device which pro-
`vides currency. That is, the cash accepter 110 in response to
`a communication from the microprocessor based device
`104, may provide a metered amount of currency to a person.
`The credit card reader 114, and ATM 112 can also be
`attached to the microprocessor based device 104. The credit
`card reader 114 could be used to read a user’s credit card and
`
`then, when authorized, either communicate to the micropro-
`cessor based device 104 that units of exchange need to be
`added to the portable module or that units of exchange need
`to be extracted from the portable module to pay for a good,
`service or credit card bill.
`
`The ATM 112 may also be connected to the micropro-
`cessor based device. Via communications from the ATM
`
`112, the microprocessor based device 104 can be informed
`that units of exchange need to be added or subtracted from
`the portable module 102.
`Furthermore, it is also possible that the microprocessor
`based device 104 is connected to a phone line 116. The
`phone line may be used for a variety of things. Most
`importantly,
`the phone line may be used to allow the
`microprocessor based device 104 to communicate with a
`network of devices. Such telephonic communication may be
`for validating transactions or for aiding the accounting of
`transactions that are performed via the microprocessor based
`device’s 104 aid. It is further understood that the phone line
`may be any of a vast variety of communication lines
`including wireless lines. Video, analog, or digital informa-
`tion may be communicated over the phone line 116.
`FIG. 2 depicts a preferred exemplary portable module
`102. The portable module 102 is preferably a rugged read/
`write data carrier that can act as a localized data base and be
`
`easily accessed with minimal hardware. The module can be
`incorporated in a vast variety of portable items which
`includes, but is not limited to a durable micro-can package
`that is highly resistant to environmental hazards such as dirt,
`moisture, and shock. The module can be incorporated into
`any object that can be articulated by a human or thing, such
`as a ring, bracelet, wallet, name tag, necklace, baggage,
`machine, robotic device, etc. Furthermore, the module 102
`could be attached to a stationary item and the microproces-
`sor based device 104 may be articulated to the portable
`module 102. For example, the module 102 may be attached
`to a piece of cargo and a module reader may be touched to
`or brought near the module 102. The module reader may be
`part of the microprocessor based device 104.
`The portable module 102 comprises a memory 202 that is
`preferably, at least in part, nonvolatile memory for storing
`and retrieving vital information pertaining to the system to
`which the module 102 may become attached to. The
`memory 202 may contain a scratchpad memory which may
`act as a buffer when writing into memory. Data is first
`written to the scratchpad where it can be read back. After
`data has been verified,
`the data is transferred into the
`memory.
`The module 102 also comprises a counter 206 for keeping
`track of the number of transactions the module has per-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`
`formed (the number of times certain data in the memory of
`the module has been changed). Atimer 102 may be provided
`in the module to provide the ability to time stamp transac-
`tions performed by the module. A memory controller 204
`controls the reading and writing of data into and out of the
`memory 202.
`The module also may comprise an identification number
`210. The identification number preferably uniquely identi-
`fies the portable module from any other portable module.
`An input/output control circuit 212 controls the data flow
`into and out of the portable module 102. The input/output
`control (“I/O”) 212 preferably has an input buffer and an
`output buffer and interface circuitry 214. As stated above,
`the interface circuitry 214 is preferably a one-wire interface.
`Again, it is understood that a variety of technologies can be
`used to interface the portable module 102 to another elec-
`tronic device. Asingle wire or single connection is preferred
`because the mechanics of making a complete connection is
`simplified. It is envisioned that a proximity/wireless com-
`munication technique is also a technique for communicating
`between the module 102 and another device. Thus,
`the
`interface circuit 214 can be a single wire, multiple wire,
`wireless, electromagnetic, magnetic,
`light, or proximity,
`interface circuit.
`
`FIG. 3 depicts a block diagram of an exemplary secure
`microprocessor based device (“secure device”) 108. The
`secure device circuitry can be a single integrated circuit. It
`is understood that the secure device 108 could also be a
`
`monolithic or multiple circuits combined together. The
`secure device 108 preferably comprises a microprocessor
`12, a real
`time clock 14, control circuitry 16, a math
`coprocessor 18, memory circuitry 20, input/output circuitry
`26, and an energy circuit 34.
`The secure device 108 could be made small enough to be
`incorporated into a variety of objects including, but not
`limited to a token, a card, a ring, a computer, a wallet, a key
`fob, a badge, jewelry, a stamp, or practically any object that
`can be grasped and/or articulated by a user of the object. In
`the present system 100, the secure device 108 is preferably
`adapted to be a trusted certifying authority. That is the secure
`device 108 is a trusted computer. The secure device 108
`comprises a numeric coprocessor 18 optimized for math
`intensive encryption. The BIOS is immune to alteration and
`is specifically designed for secure transactions. This secure
`device 108 is preferably encased in a durable, dirt, moisture
`and shock resistant stainless steel enclosure, but could be
`encased in wide variety of structures so long as specific
`contents of the secure device 108 are extremely difficult to
`decipher. The secure device 108. The secure device 108 may
`have the ability to store or create a private/public key set,
`whereby the private key never leaves the secure device 108
`and is not revealed under almost any circumstance.
`Furthermore, the secure module 108 is preferably designed
`to prevent discovery of the private key by an active self-
`destruction of the key upon wrongful entry.
`The microprocessor 12 is preferably an 8-bit
`microprocessor, but could be 16, 32, 64 or any operable
`number of bits. The clock 14 provides timing for the module
`circuitry. There can also be separate clock circuitry 14 that
`provides a continuously running real time clock.
`The math coprocessor circuitry 18 is designed and used to
`handle very large numbers. In particular, the coprocessor
`will handle the complex mathematics of RSA encryption and
`decryption or other types of math intensive encryption or
`decryption techniques.
`The memory circuitry 20 may contain both read-only-
`memory and non-volatile random-access-memory.
`
`Page 11 of 24
`
`Page 11 of 24
`
`
`
`5,949,880
`
`5
`Furthermore, one of ordinary skill in the art would under-
`stand that volatile memory, EPROM, SRAM and a variety of
`other types of memory circuitry might be used to create an
`equivalent device.
`Control circuitry 16 provides timing, latching and various
`necessary control functions for the entire circuit.
`An input/output circuit 26 enables bidirectional commu-
`nication with the secure module 108. The input/output
`circuitry 26 preferably comprises at least an output buffer
`and an input buffer. For communication via a one-wire bus,
`one-wire interface circuitry can be included with the input/
`output circuitry 26. It is understood that the input/output
`circuitry 26 of the secure device 108 can be designed to
`operate on a single wire, a plurality of wires or any means
`for communicating is information between the secure mod-
`ule 108 and the microprocessor based device 104.
`An energy circuit 34 may be necessary to maintain stored
`information in the memory circuitry 20 and/or aid in pow-
`ering the other circuitry in the module 108. The energy
`circuit 34 could consist of a battery, capacitor, R/C circuit,
`photo-voltaic cell, or any other equivalent energy producing
`circuit or means.
`The firmware architecture of the secure module 108 and
`
`how it operates within the exemplary system for transferring
`valuable information, such as units of exchange or currency,
`between the secure module 108 and a portable module 102
`will now be discussed. The secure module 108 provides
`encryption and decryption services for confidential data
`transfer through the microprocessor based device 104. The
`following examples are intended to illustrate a preferred
`feature set of the secure module 108 and to explain the
`services that the exemplary system 100 can offer. These
`applications and examples by no means limit the capabilities
`of the invention, but instead bring to light a sampling of its
`capabilities.
`I. Overview of the Preferred Secure Module 108 and its
`
`Firmware Design
`Referring to FIG. 3 again, the secure module 108 prefer-
`ably contains a general-purpose, 8051-compatible micro
`controller 12 or a reasonably similar product, a continuously
`running real-time clock 14, a high-speed modular exponen-
`tiation accelerator for large integers (math coprocessor) 18,
`input and output buffers 28, 30 with a one-wire interface 32
`for sending and receiving data, 32 Kbytes of ROM memory
`22 with preprogrammed firmware, 8 Kbytes of NVRAM
`(non-volatile RAM) 24 for storage of critical data, and
`control circuitry 16 that enables the micro controller 12 to be
`powered up to interpret and act on the data placed in an input
`data object. The module 108 draws its operating power from
`a single wire, one-wire communication line. The micro
`controller 12, clock 14, memory 20, buffers 28, 30, one-wire
`front-end 32, modular exponentiation accelerator 18, and
`control circuitry 16 are preferably integrated on a single
`silicon chip and packaged in a stainless steel micro can using
`packaging techniques which make it virtually impossible to
`probe the data in the NVRAM 24 without destroying the
`data. Initially, most of the NVRAM 24 is available for use
`to support applications such as those described below. One
`of ordinary skill will understand that there are many com-
`parable variations of the module design. For example,
`volatile memory might be used, or an interface other than a
`one-wire interface could be used.
`
`The secure module 108 is preferably intended to be used
`first by a Service Provider who loads the secure module 108
`with data to enable it
`to perform useful functions, and
`second by an End User who issues commands to the secure
`module 108 to perform operations on behalf of the Service
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`Provider for the benefit of the End User. For this reason, the
`secure module 108 offers functions to support the Service
`Provider in setting up the module for an intended applica-
`tion. It also offers functions to allow the End User to invoke
`
`the services offered by the Service Provider.
`Each Service Provider can reserve a block of NVRAM
`
`memory to support its services by creating a transaction
`group 40 (refer to FIGS. 6 and 7). A transaction group 40 is
`simply a set of software objects 42 that are defined by the
`Service Provider. These objects 42 include both data objects
`(encryption keys, transaction counts, money amounts, date/
`time stamps, etc.) and transaction scripts 44 which specify
`how to combine the data objects in useful ways. Each
`Service Provider creates his own transaction group 40,
`which is independent of every other transaction group 40.
`Hence, multiple Service Providers can offer different ser-
`vices in the same module 108. The number of independent
`Service Providers that can be supported depends on the
`number and complexity of the objects 42 defined in each
`transaction group 40. Examples of some of the objects 42
`that can be defined within a transaction group 40 are the
`following:
`
`RSA Modulus
`RSA Exponent
`Transaction Script
`Transaction Counter
`Money Register
`Destructor
`
`Clock Offset
`Random SALT
`Configuration Data
`Input Data
`Output Data
`
`Within each transaction group 40 the secure module 108
`will initially accept certain commands which have an irre-
`versible effect. Once any of these irreversible commands are
`executed in a transaction group 40, they remain in effect
`until the end of the module’s useful life or until the trans-
`
`to which it applies, is deleted from the
`action group 40,
`secure module 108. In addition, there are certain commands
`which have an irreversible effect until the end of the mod-
`ule’s life or until a master erase command is issued to erase
`the entire contents of the secure module 108. These com-
`mands will be discussed further below. These commands are
`
`essential to give the Service Provider the necessary control
`over the operations that can be performed by the End User.
`Examples of some of the irreversible commands are:
`
`Privatize Object
`Lock Transaction Group
`
`Lock Object
`Lock Micro-In-A-Can TM
`
`Since much of the module’s utility centers on its ability to
`keep a secret, the Privatize command is a very important
`irreversible command.
`Once the secure module 108, as a whole, is locked, the
`remaining NVRAM memory 24 is allocated for a circular
`buffer for holding an audit trail of previous transactions.
`Each of the transactions are identified by the number of the
`transaction group,
`the number of objects 42 within the
`specified group, and the date/time stamp.
`The fundamental concept implemented by the firmware is
`that the Service Provider can store transaction scripts 44 in
`a transaction group 40 to perform only those operations
`among objects that he wishes the End User to be able to
`perform. The Service Provider can also store and privatize
`RSA key or keys (encryption keys) that allow the secure
`module 108 to “sign” transactions on behalf of the Service
`Provider, thereby guaranteeing their authenticity. By priva-
`tizing and/or locking one or more objects 42 in the trans-
`
`Page 12 of 24
`
`Page 12 of 24
`
`
`
`5,949,880
`
`7
`action group 40, the Service Provider maintains control over
`what the secure module 108 is allowed to do on his behalf.
`The End User cannot add new transaction scripts 44 and is
`therefore limited to the operations on objects 42 that can be
`performed with the transaction scripts 44 programmed by
`the Service Provider.
`II. Usage Models of the Secure Module 108 and Portable
`Module 102
`This section presents practical applications of the system
`100. Each of these applications is described in enough detail
`to make it clear why the secure module 108 and portable
`module 102 are important to the system application.
`A. Transferring Units of Exchange Out of a Portable Module
`102
`This section describes an example of how a portable
`module 102 and a secure module 108 operate in conjunction
`with the microprocessor based device 104 so that units of
`exchange can be securely transferred out of the portable
`module 102 and deposited into the secure module 108 and/or
`potentially communicated to at least one of the cash acceptor
`110, ATM 112, credit card reader 114, or the phone line 116.
`Referring to FIG. 4, initially the portable module 102
`contains its ID number, a count within its transaction counter
`and an encrypted data packet stored in memory. Encrypted
`within the data packet is the portable modules ID number,
`the portable modules transaction count number, and the
`amount of value (the monetary value) of the portable module
`at the present time X1.
`The user of the portable module touches, or somehow puts
`the portable module 102 into communication with the
`microprocessor based device 104. For explanation purposes,
`suppose the portable module 102 is being used as a token
`used to pay for a train fare. Thus, the microprocessor based
`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
`platform is known by the microprocessor based device 104.
`The microprocessor based device 104 reads the portable
`module’s serial number,
`transaction count, and the
`encrypted data packet X2. This data could be referred to as
`a first data.
`
`The microprocessor device 104 then provides the first
`data along with a first value, being the amount of value to be
`debited from the portable token (the train fare), to the secure
`module 108 X3. The secure module 108 decrypts the
`encrypted data found in the first data using a public key X4.
`Next, the secure module 108 makes a few comparisons to
`make sure that
`the data received is good data and not
`counterfeit. The secure module 108 compares the serial
`number received in the first data with the decrypted serial
`number X5. If the two serial numbers match then the secure
`
`module 108 compares the transaction count received in the
`first data with the decrypted transaction count X6. If the two
`transaction counts match then the secure module is com-
`fortable that the data received is not counterfeit data. It is
`
`understood that the comparisons can be done in any order.
`Furthermore, there may have been a time stamp sent from
`the portable module 102. The time stamp may indicate a
`variety of things. One thing could be an indication of
`whether the portable module is still valid or the time stamp
`may further enable the secure module to decide if the data
`is or is not counterfeit.
`
`Assuming all the data passed to the secure module 108 is
`determined to be valid data, the secure module 108 subtracts
`the first value, the train fare, from the monetary value of the
`portable module 102 X7. The decrypted transaction count is
`then incremented.
`
`A register within the secure module 108 is increased by
`the amount of the first value, the train fare, so that the secure
`
`8
`module can keep an accounting of the amount of “money”
`it has collected X8. The secure module 108 creates a data
`
`packet, a second data, which comprises at least the portable
`module’s serial number, the incremented transaction count,
`and the reduced monetary value of the portable module 102.
`The second data packet is then encrypted by the secure
`module 108 using a private key X9.
`The microprocessor based device 104 receives the
`encrypted second data packet, passes the encrypted second
`data packet to the portable module 102 X10, and opens the
`turn style to let the module’s user onto the train platform.
`The portable module 102 receives the encrypted second data
`packet and stores it in memory X11. The portable module
`also increments its transaction count indicating that another
`transaction has occurred X12.
`
`Thus, the above description indicates how valuable infor-
`mation can be transferred between a portable insecure
`module 102 and a secure module 108 wherein there is a
`
`10
`
`15
`
`20
`
`conservation of value. That is, no value is gained or lost.
`Value that was in the portable module 102 was decreased by
`the same amount value was added to the secure module 108.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`In the example provided, the decrease and increase in value
`was equal to a train fare. Such an increment or decrement
`can also be equal to an amount provided by an ATM, credit
`card transaction, cash acceptor, etc.
`It is also understood that the insecure portable is module
`102 could be another secure module similar to the secure
`
`module in the system, but programed to act like a portable
`module 102.
`
`B. Transferring Units of Exchange Into the Portable Module
`102
`
`for simplicity, suppose the portable
`In this example,
`module does not have any monetary value and the user of the
`portable module wishes to “fill it up” with value. Suppose
`the user wishes to take cash out of an ATM machine and
`
`instead of pocketing the cash, the user wishes to put the cash
`value into the portable module 102.
`Referring to FIG. 5, the portable module 102 contains its
`ID number, a transaction count and an encrypted data packet
`containing the portable module’s ID number, transaction
`count and the monetary value of the portable module 102
`Y1. The microprocessor based device 104, which in this
`example could be part of the ATM machine 112, receives the
`information contained in the portable module 102 when a
`communication is initiated between the portable module 102
`and the microprocessor based device 104 Y2.
`The microprocessor based device 104 passes the module’s
`serial number, transaction count, and encrypted data packet
`as a first data packet to the secure module 108. The micro-
`processor based device also passes the amount of amount of
`monetary value to add to the portable module 102, as
`indicated by the ATM 112, to the secure module 108 Y3.
`The secure module 108 decrypts the encrypted data
`passed to it using a public key Y4. The secure module 108
`then makes a few comparisons to make sure that the data it
`has just received is valid and not counterfeit. The secure
`module 108 compares the serial number (ID number)
`received in the first data packet with the serial number (ID
`number) found in the decrypted data Y5. The secure module
`108 also compares the transaction count passed the first data
`packet with the transaction count found in the decrypted data
`Y6. If the serial numbers and transaction counters match,
`then the secure module decides that the data received is valid
`
`and the secure module adds the monetary value, indicated by
`the ATM to the monetary value of the decrypted data Y7.
`The decrypted transaction count is incremented Y8. A reg-
`ister within the secure module may be decremented by the
`
`Page 13 of 24
`
`Page 13 of 24
`
`
`
`5,949,880
`
`9
`sa