`'Shficléss
`
`
`iSSUECLASSIFICATI¢N
`
`
`5305702
`I rum .
`
`iii/iii;iiiiiiiiiiii
`\
`
`
`mung—k”.
`
`
`
`
`EXAMINER
`
`i
`'
`,
`'
`'
`WM "ii?
`
`r
`
`
`
`
`‘— BEerQPYi
`
`
`PATENT DATiE
`SERIAL
`
`PATENT
`NUMBER
`7 LE? 0 81993
`NUMBER _
`
`SUBCLASS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` ATTORNEY'S ‘-
`
`[1 yes
`Foraign pnorlfry claimad
`35 USC119cpndhlons met D yo:
`Verlfled and Acknowledged
`Examiner‘s inhials
`.31;
`5
`
`
`DOCKET NO-
`
`'fl] no
`IE up
`
`
`
`
`
`PARTS OF APPLICATION
`.
`«lo?
`\ j
`M61315 Exami’r
`FILED SEPARATELY
`‘ CLAIM ALLOWED
`
`
`'
`
`.
`
`Drwg. Pissing.
`
`
`
`
`
`B f
`
`
`
`
`
`rinAsm'Aficm
`.
`i‘i
`
`SUFERVWRYPMENTEXAMINEF
`
`
`’ I
`
`GROUFZZGO
`ISSUE i
`NUMBER
`
`
`//
`
`
`
`WARNING: The information disclosed herein may pas/striated. Unauthorized disdiosure may be prohibited 1‘
`by the United States Code We Sir’Sectians 122, 181 and 368. Possession outside the US.
`i
`
`
`Pateril 8. Trademark Oflicrfirefiicied to authorized employees and contractors on_|y.
`-
`
`
`Form PTO-436A
`
`(Rev. 8/92)
`
`
`/ .
`(FAf‘Fi
`
`‘
`
`-
`
`'
`
`ROUPON - EXHIBIT 1007
`
`244MAX001169
`
`GROUPON - EXHIBIT 1007
`
`

`

`.
`
`l‘ 5,805,702 7
`
`METHOD, APPARATUS,.AND SYSTEM FOR TRANSFERRING UNITS 0E VALUE '
`
`‘ Transaction History
`
`‘
`
`1
`
`,
`
`‘
`
`
`
`,
`
`
`
`Transaction Description
`2/15/1996 Initial Exam Team hn
`
`3/18/1996 Notice Mailed--Application Incomplete-Filing Date Assigned
`5/2/1996 Application IsNowComplete
`‘ 6/3/1996 App‘licationCaptured on MiCrofiIm
`6/6/1996 Transferlnqmry
`’ 6/10/1996 Case Docketed to Examlner In GAU
`
`11/21/1996 Miscellaneous Incoming Letter
`'
`1- 3/3/1997 Case Docketed to Examiner in GAU
`'
`v
`
`7/18/1997 Restriction/Election Requirement
` 7/21/1997 Mail Restriction Requirement '
`9/8/1997 Response to Election / Restriction Filed
`
`9/8/1997 Request for Extension of Time - Granted
`39/24/1997 Date Forwarded to Examiner
`10/2/1997 Mail‘Notice of Allowance
`
`'
`
`.
`
`_
`
`244MAX001170
`
` 3/10/1999 Post Issue Communication — Certificate of Correction
`
`. 10/2/1997 Notice of Allowance Data Verification Completed
`‘ 12/5/1997 Preexamination‘ Location Change
`
`1/6/1998 Mailroom'Date of Drawing(s)
`1/6/1998 Issue Fee Payment Verified
`4/15/1998 Application Ordered to Match Drawingls)
`
`4/15/1998 Drawing(s) Received at Publications
`5/20/1998 Application Received to Match Drawing(s)
`"' 7/1/1998 Drawing(s)Processing Completed
`7/1/1998 Drawing(s) Matched to Application
`8/3/1998 Issue Notification Mailed
`’ 9/8/1998 Recordation of Patent Grant Mailed
`
`I
`
`‘
`
`

`

`Inn /l';
`
`
`
`
`'C'
`
`"90014
`x '
`W
`
`i'
`L
`
`.
`
`
`
`ff ”‘7‘,"
`
`H...
`
`__
`
`7
`
`_
`
`_
`
`~-..
`
`5%? a.
`
`
`‘
`
`””””““”“m77_l
`PATENTAPPUCAHON
`L,Wm“3:
`V
`.5
`iS
`,WWWWMWWWWWE
`Date?"
`‘
`08595914 W:fwfimmf
`
`RECS‘Wd-
`CONTENTS
`.
`Ma ‘eg
`
`\m
`
`1
`
`2 3
`
`.
`
`4.
`
`5.
`
`6.
`
`. Application
`
`7 8
`
`
`
`
`
`
`
`
`
`(FRONT)
`
`244MAX001171
`
`

`

`
`
`.
`
`PPLICA ION SERIAL NUMBER
`
`
`
`INTERNATIONAL CLASSIFICATION
`
`
`
`: a
`
`
`ORIGINAL CLASSIFICATION
`*
`4
`,
`- suacuss
`
`3L!
`CROSS REFERENCEIS)
`
`SUBCLASS
`(ONE SUECLASS PER BLOCKI
`
`
`
`
`
`
`
`05 595.014
`
`' APPLICANTS NAME 'LEASE PRINT)
`S'I ngfl II’I .' Cuf 1/ éi-IL (if H ‘
`
`v
`
`F REIISSUE. ORIGINAL PATENT NUMBER
`
`
`
`
`I I
`I
`
`
`E)
`
`‘
`‘
`”’7’
`'
`‘
`If
`GROUP
`ISTANT EXAMINER {P_LE SE STAMP OR PRINT FULL NAM
`-
`
`ART UNIT
`I]...
`r,
`,,
`‘
`1
`,
`
`
`.V- . w If __H
`--
`“I? - EXAMINER PLE-‘ESTAMF on PHINTF
`LNAME
`"'lr‘
`
`
`,yhflj " JY “7.5..
`USWe -
`PATENT‘AND TRADEMARK OFFICE
`3
`‘ mun mm. Mama-
`
`'
`ISSUE CLASSIFICATION SLIP
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`4
`
`E‘.o
`
`.U
`
`9’2.3
`a!
`fin
`
`Oliginal
`wsFlg +++MI
`
`CW
`
` ‘
`
`
`
`
`
`
`mummk
`
`
`
`
`
`
`
`
`I. .5/ I.
`
`‘
`
`
`mmmm
`
`’
`
`o)—2+-Mk
`
`
`
`'
`
`'
`
`.
`rggvfigan
`
`\
`
`
`
`
`
`W
`
`Rejected
`.
`Allowad
`(Through numbaral) Canceled
`.
`Reslviulao
`Nun-Electra
`Inlenevenca
`Appeal
`Ohiecled
`
`
`
`
`
`
`
`II FFT INRII’IFI
`
`244MAX001172
`
`

`

`‘
`
`u--;m..wmw._.i-w_.uw0
`
`_ r..." ___ ”A...“
`
`:l,
`
`
`Clalm
`Date‘
`1
`Date
`j
`_
`.—
`a E
`E
`E Pt
`9)
`
`.
`,
`L“ 5
`5
`SD] _ _
`_51
`
`
`z _
`5:?.3 ~
`
`
`5, ELV
`
`-
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` i
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`abJ>\1Amm
`
`
`6
`7
`
`7
`
`a I!
`1 m
`
`
`
`SYMBOLS
`
`.. Reienled
`Allnwed
`(Through numbeml) Canceled
`.
`Resnlclcd
`-
`
`qn-elaclen
`Intevmence
`Annual
`.Ohiected
`
`a;A
`
`
`
`
`.5:
`
`',as0
`
`(I FFT INQInm
`
`244MAX001173
`
`

`

` SEARCH! NOTES
` NTERFEFIENCE SEARCHED
`
`-—_-'
`
`InlnuT nI ITRIDFJ
`\.
`
`
`244MAX001174
`
`

`

`MMWWMMMMMWMWMWW
`U8005805702A
`
`United States Patent
`Curry et al.
`
`[19;
`
`[11] Patent Number:
`[45] Date of Patent:
`
`5,805,702
`Sep. 8, 1998
`
`J54] METHOD, APPARATUS, AND SYSTEM FOR
`TRANSFERRING UNITS 0F VALUE
`
`[75]
`
`Inventors: Stephen M. Curry, Dallas; Donald W.
`Loomis, Coppell; Christopher W. Fox,
`Dallas, all of Tex.
`
`[73] Assignee: Dallas Semiconductor Corporation,
`Dallas, Tex.
`
`[21] App]. N0.: 595,014
`
`[22]
`
`Filed:
`
`Jan. 31, 1996
`
`Related U.S. Application Data
`
`Provisional application No. 60/004,510, Sep. 29, 1995.
`if [60]
`rm.le ........................................................ H04L 9/00
`’[51]
`[52] U.S.‘Cl.
`.............
`380/24
`
`[58] Field of Search
`.. 380/23, 24, 25,
`380/30; 364/717, 464.02
`
`[56]
`
`References Cited
`U.Sr PATENT DOCUMENTS
`
`364/408
`12/1986 White
`4,630,201
`
`380/24
`12/1991 Herring
`5,077,792
`
`380/24
`11/1996 Davis et a],
`5,577,121
`Primary Examiner—Thomas H, Tarcza
`Assistant Examiner—Carmen D. White
`
`Attorney, Agent, or Firm—Jenkcns & Gilchrist
`[57]
`ABSTRACT
`The present invention relates to an electronic module used
`for secure transactions. More specifically,
`the electronic
`module is capable of passing encrypted information back
`and forth between a service
`rovider’s e ui ment via a
`P
`q P
`secure, encrypted technique so that money and other valu-
`able data can be securely passed electronically. The module
`is capable of being programmed, keeping track of real time,
`recording transactions for later review, and creating encryp-
`tion key pairs.
`
`V
`
`15 Claims, 8 Drawing Sheets
`
`F1
`
`F3
`
`M/SERVICE PROVIDER
`ee
`
`WANTS TO ADD AN
`
`READ MODULE ID
`
`
`AMOUNT OF CASH
`
`NUMBER AND AMOUNT
`
`TO MODULE
`
`
`OF CASH REQUESTED
`
`
`REQUEST MODULE T0
`
`PRODUCE A RANDOM SALT
`CREATE RANDOM
`
`
`SALT NUMBER
`
`0MB|NE SALT.
`ID NUMBE
`
`AND CASH AMOUNT AND
`
`
`
`
`DECRYPT SIGNE SERVICE
`ENCRYPT WITH SERVICE
`PROVIDER CERTIFICATE
`PROVIDER'S PRIVATE KB,
`
`
`THEREBY CREATING A
`WITH SERVICE PROVIDERS
`
`SIGNED SERVICE
`PUBUC KEY AND CHECK
`
`
`' PROVIDER CERTIFICATE
`
`TH ID NUMBER AND
`
`
`RANDOM SALT NUMBER
`
`IF THE ID NUMBER AND
`
`
`RANDOM SALT NUMBER
`IS UNCl-IANGED THEN ADD
`
`
`HE CASH AMOUNT T0 TH
`
`
`
`MONEY REGISTER OF
`THE MODULE
`
`
`F5
`
`F2
`
`F4
`
`244MAX001175
`
`

`

`US. Patent
`
`Sep. 8,1998
`
`Sheet 1 era
`
`5,805,702
`
`UNIQUE ID NUMBER
`
`IO,
`
`/T/
`
`12
`
`18'
`
`28
`
`30
`
`26
`
`MICRO PROCESSOR
`
`CLOCK
`
`- CONTROL “
`-
`
`32
`
`.14
`
`16
`
`22
`20
`
`24
`
`:54
`
`—-ITIII
`
`‘ OUTPUT BUFFER
`
`INPUT BUFFER
`
`ONE—WIRE
`INTERFACE
`
`ENERGY
`CIRCUITRY
`
`FIG.
`
`1
`
`CREATE TRANSACTION GROUP
`
`CENERATE KEYS ANO LOAD
`INTo A TRANSACTION GROUP
`
`PRNATIZE IDECRYPTION EXPONENT
`
`CREATE TRANSACTION SCRIPT
`
`LOCK TRANSACTION GROUP
`
`FIG. 2
`
`
`
`
`
`
`
`
`$1
`
`$2
`
`$3
`
`'
`
`
`
`$4
`
`55
`
`
`
`244MAX001176
`
`

`

`US. Patent
`
`Sep.8,1998
`
`Sheet 2 01’8
`
`5,805,702
`
`USER RECEIVES SECURE E-MAIL
`AND ENCRYPTED IDEA KEY
`
`MODULE RECEIVES ENCRYPTED
`IDEA KEY IN AN INPUT OBJECT
`OF A TRANSACTION GROUP
`
`TRANSACTION SCRIPT DECRYPTS
`THE IDEA KEY
`
`FIG. 3
`
`V
`
`DECRYPTED IDEA KEY IS PLACED
`IN AN OUTPUT DATA OBJECT
`
`IDEA KEY IS USED TO DECRYPT
`THE SECURE E—MAIL
`
`81
`
`CREATE TRANSACTION GROUP FOR
`PERFORMING ELECTRONIC
`NOTARY FUNCTIONS
`
`FIG. 4
`
`35
`
`82
`
`as
`
`CREATE OBJECT(S) FOR
`‘ RSA ENCRYPTION KEYS
`
`CREATE OBJECT FOR TIMEKEEPING
`
`
`
`
`CREATE TRANSACTION SEQUENCE
`OBJECT (COUNTER)
`
`
`
`
`
`CREATE A TRANSACTION SCRIPT THAT CREATES A
`CERTIFICATE BY COMBINING AN INPUT DATA OBJECT
`WITH THE TRUE TIME. THE VALUE OF THE TRANSACTION
`COUNTER AND A UNIOUE NUMBER ASSOCIATED TO THE
`MODULE, THEN SIGNS THE CERTTFICATE
`
`
`
`
`
`BB
`
`B7
`
`PRIVATIZE OBJECTS
`
`LOCK TRANSACTION GROUP
`
`
`
`
`.
`
`244MAX001177
`
`

`

`US. Patent
`
`Sep. 3, 1998
`
`Sheet 3. of 8
`
`5,805,702
`
`CI
`
`C2
`
`03
`
`C4
`
`
`
`THE CERTIFICATE AND ORIGINAL
`DOCUMENT CAN BE
`STORED ELECTRONICALLY
`
` MESSAGE IS PIJ\CED IN AN
`
`
`INPUT DATA OBJECT
`
`TRANSACTION SCRIPT COMBINES
`
`MESSAGE WITH OTHER DATA AND
`
`
`SIGNS THE COMBINATTON WITH A
`PRIVATE KEY CREATING AN
`ENCRYPTED CERTIFICATE
`
`
`
`THE CERTIFICATE CAN BE READ
`AT A LATER TIME BY ENCRYPTING
`IT WITH THE PUBUC KEY
`
`FIG. 5
`
`
`
`
`
`
`PREPARE MODULE
`
`CREATE TRANSACTION GROUP
`
`COMPRISING: MONEY OBJECT
`TRANSACTION COUNT OBJECT
`
`PRIVATE KEY AND
`PUBUC KEY OBJECTS ETC.
`
`
`PRIVATTZE PRIVATE KEY RflATED OBJECT(S)
`
`
`
`
`
`
`
`01
`
`DZ
`
`FIG. 6
`
`D3
`
`D4
`
`D5
`
`CREATE OBJECT FOR TIMEKEEPING
`'RSA ENCRYPTTON KEYS
`
`
`
`
`LOCK TRANSACTION GROUP
`
`
`PUBLISH PUBUC KEY
`'
`
`
`
`
`
`244MAX001178
`
`

`

`US. Patent
`
`Sep.8,1998
`
`. Sheet 4 OfR
`
`5,805,702
`
`USE
`
`MERCHANT
`
`M/SERVICE PROVIDER
`
`USER WANTS TO MAKE
`USINETCIISSSLE
`
`E‘
`
`_
`
`I
`
`READS MODULES
`ID NUMBER
`
`52
`
`-
`
`CREATE DATA PACKET
`THAT INCLUDES A
`'RANDOM SALT' AND
`
`MODULE ID NUMBER
`
`CREATE A SIGNED
`MERCHANT CERTIFICATE
`BY ENCRYPTING DATA
`PACKET WITH
`
`MERCHANT'S PRNATE KEY
`
`E3
`
`E4
`
`SUBTRACT PURCHASE
`AMOUNT FROM
`MONEY REGISTER I
`
`I
`
`‘
`
`ATTACHES PURCHASE
`PRICE T0 MERCHANT'S
`SIGNED CERTIFICATE
`
`INCREMENT
`. TRANSACTION AMOUNT
`
`E7
`
`
`
`
`
`
`
`
`
`INCREMENT
`TRANSACTION AMOUNT
`
`E11
`
`COMBINE TRANSACTION
` E8
`COUNT WITH MERCHANT'S
`
`
`RECEIVE SIGNED MODULE
`SIGNED CERTIFICATE
`
`
`CERTIFICATE AND DECRYPT
`AND PURCHASE AMOUNT;
`
`USING SERVICE
`
`THEN ENCRYPT WITH
`PROVIDERS PUBLIC KEY
`
`SERVICE PROVIDER'S
`PRIVATE KEY THEREBY
`
`CREATING A SICNED
`CONFIRM
`T:
`
`
`1) AMOUNIHSFPURCHASE
`MODULE CERTIFICATE
`
`
`
`IS CORRECT
`
`2) DATA IN MERCHANT'S
`
`CERTIFICATE IS THE
`
`SAME As ORIGINALLY SE
`E10
`
`
`
`
`
`
`.
`
`FIG. 7
`
`E12
`
`RECEIVE MODULE'S
`SIGNED CERTIFICATE
`
`DECRYPT MODULE’S
`CERTIFICATE WITH SERVICE
`PROVIDER‘S PUBLIC KEY
`
`DECRYPT MERCHANT'S
`CERTIFICATE WITH
`MERCHANT'S PUBUC KEY
`
`
`
`IF BOTH CERTIFICATES
`ARE OK THEN ADD
`PURCHASE AMOUNT TO
`
`MERCHANT'S BANK BALANCE
`
`
`
`
`
`
`E13
`
`E”
`
`E15
`
`244MAX001179
`
`

`

`U.S. Paltent
`
`Sep.8,1998
`
`Sheet 5 0f8
`
`5,805,702
`
`F1
`
`F3
`
`
`
`W/SERVICE PROVIDER
`1%
`WANTS TO ADD AN
`
`
`READ MODULE ID
`
`AMOUNT OF CASH
`NUMBER AND AMOUNT
`
`
`T0 MODULE
`
`OF CASH REQUESTED
`
`REQUEST MODULE T0
`
`
`PRODUCE A RANDOM SALT
`
`
`
`
`
`0MBINE SALT.
`ID NUMBE'
`
`
`AND CASH AMOUNT AND
`
`ENCRYPT WITH SERVICE
`DECRYPT SIGNE SERVICE
`
`
`
`PROVIDERS PRIVATE KEY.
`PROVIDER CERTIFICATE
`THEREBY CREATING A
`WITH SERVICE PROVIDERS
`
`
`SIGNED SERVICE
`PUBUC KEY AND CHECK
`
`
`
`PROVIDER CERTIFICATE
`TH ID NUMBER AND
`
`
`
`RANDOM SALT NUMBER
`
` IF THE ID NUMBER AND
`
`
`RANDOM SALT NUMBER
`IS UNCHANGED THEN ADD
`HE CASH AMOUNT TO TH.
`
`
`MONEY REGISTER OF
`
`THE MODULE
`
`CREATE RANDOM
`SALT NUMBER
`
`F2
`
`F4
`
`FIG. 8
`
`EXAMPLE OF
`TRANSFER FROM USER'S MODULE T0 MERCHANTS MODULE
`
`ESEI/PAYER
`MERCHANT/PAYEE
`
`
`
`RECEIVE SALT AND
`I. CREATE RANDOM SALT
`
`REQUEST FOR MONEY '
`2. DETERMINE AMOUNT OF
`
`
`
`BTRAC
`MONEY TO BE
`I
`
`
`MONEY ALSES‘HE3153
`RECEIVED FROM PAYER
`
`A MONEY REGISTER
`
`CREATE SIGNED PAYMENT
`
`
`ERTIFICATE BY COMBININQ
`
`
`
`SALT WITH PAYMENT
`RECENED SIGNED PAYMENT
`
`
`
`' OUNT THEN ENCRYPTINe
`CERTIFICATE AND DECRYPT
`USING SERVICE PROVIDER'S
`WITH BANK/SERVICE
`
`
`
`PROVIDER'S PRIVATE KEY
`PUBUC KEY
`
`
`
`
`
`
`CHECK DECRYPTED SALT
`AGAINST ORIGINALLY SENT SALT
`
`
`IF THEY ARE THE SAME
`ADD PAYMENT AMOUNT
`T0 MONEY REGISTER
`
`
`PAYEE=MERCHANT
`PAYER=USER
`
`FIG. 9
`
`GI
`
`G3
`
`G4
`
`244MAX00118O
`
`

`

`US. Patent
`
`Sep.8,1998
`
`Sheet 6 0f8
`
`5,805,702
`
`TRANSACTION OVER A NETWORK WITH A MODULE
`
`H1
`
`[IS—ER/PALER
`CREATE RANDOM ‘
`PAYER SALT
`
`MERCHANT/PAYEE
`RECEIVE PAYER SALT AND
`
`
`COMBINE WITH AMOUNT OF
`
`
`MONEY TO BE RECEIVED. AND
`INCLUDE A PAYEE SALT. THEN
`
`ENCRYPT WITH SERVICE
`PROVIDERS PRIVATE KEY TO
`
`CREATE A FIRST DATA PACKET
`
`
`H2
`
`RECEIVE FIRST DATA PACKET
`AND DECRYPT WITH SERVICE
`
`
`PROVIDERS PUBLIC KEY
`
`
`H3
`
`I
`”4
`
`H5
`
`
`
`
`COMPARE EN'CRYPTED
`PAYER SALT WITH ORIGINAL
`
`
`PAYER SALT'
`
`IF THEY ARE THE SAME.
`SUBTRACT AMOUNT OF MONEY
`
`To BE SENT FROM
`
`
`PAYER TO REGISTER
`
`
`
`GENERATE A SECOND DATA
`PACKET CONSISTTNG OF
`
`PAYEE'S SALT AND THE
`
`AMOUNT OF MONEY TO
`
`BE SENT AND ENCRYPT
`USING SERVICE
`RECEIVE SECOND DATA PACKET
`
`
`
`AND DECRYPT USING SERVICE
`V PROVIDER'S PRIVATE KEY
`
`PROVIDERS PUBLIC KEY
`
`
`EXTRACT DECRYPTED PAYEE
`SALT AND COMPARE WITH
`
`PAYEE SALT PROVIDED EARUER
`IF BOTH ARE THE SAME ADD
`
`
`MONEY AMOUNT TO
`PAYEE MONEY REGISTER
`
`FIG;
`
`1 0
`
`'
`
`
`
`
`
`
`
`
`
`
`
`H6
`
`H7
`
`244MAX001181
`
`

`

`US. Patent
`
`Sep. 8, 1998
`
`Sheet 7 of 8
`
`5,805,702
`
`READ/WRITE OBJECT COMMANDS
`
`LOCKED
`
`I
`
`SCRIPTS
`
`OBJECTS (P)
`
`TRANSACTION
`GROUP
`OPEN
`OBJECTS (0)
`I
`IPRIVATE
`ll
`ILOCKED
`OBJECTS (”I
`READ ONLY OBJECT COMMAND
`
`
`
`READ/WRITE OBJECT COMMANDS
`
`LOCKED
`TRANSACTION
`GROUP
`
`LOCKED
`TRANSACTION
`GROUP
`
`LOCKED
`OBJECTS (L)
`
`244MAX001182
`
`

`

`US. Patent
`
`801). 8,1998
`
`Sheet 8 0f8
`
`5,805,702
`
`l/O DATA BUFFERS
`
`TRANSACTION GROUP
`
`GROUP NAME.
`PASSWORD AND ATTRIBUTES
`
`
`
`
`
`
`
`OBJECT 1
`
`OBJECT 2
`
`OBJECT N
`
`42
`
`42
`
`SYSTEM DATA
`COMMON PIN. RANDOM
`NUMBER REGISTER. ETC...
`
`
`
`
`
`
`
`OUTPUT DATA OBJECT #1
`
`OUTPUT DATA'OBJECT #2
`WORKING REGISTER
`
`
`
`TRANSACTION GROUP 1
`
`TRANSACTION GROUP 2
`
`
`
`
`
`
`THE AUDIT TRAIL
`
`TRANSACTION GROUP N
`
`AUDIT TRAIL‘l
`
`CIRCULAR BUFFER OF
`TRANSACTION RECORDS
`
`‘THE AUDIT TRAIL DOES
`NOT EXIST UNTIL THE
`MlCRO-lN—A—CAN
`HAS BEEN LOCKED
`
`ONCE LOCKED ALL
`UNUSED RAM IS
`ALLOCATED FOR
`
`TRANSACTION RECORD
`
`GROUP OBJECT
`ID
`ID
`
`DATE/TIME
`STAMP
`
`FIG. 12
`
`244MAX001183
`
`

`

`5,805,702
`
`1
`METHOD, APPARATUS, AND SYSTEM FOR
`'
`TRANSFERRING UNITS OF VALUE
`BACKGROUND OF THE INVENTION
`1. Technical Field of the Invention
`The present invention relates to a method, apparatus and
`system for transferring money or its equivalent electroni-
`cally. In particular, in an electronic module based system, the
`module can be configured to provide at least secure data
`transfers or to authorize monetary transactions.
`’
`2. Description of Related Art
`Presently, credit cards that have a magnetic strip associ-
`ated with them, are a preferred monetary transaction
`medium in the market place. Acard user can take the card
`to an automatic cash machine, a local store or a bank and
`make monetary transactions. In many instances the cardis
`; used via a telephone interface to make'monetary exchanges.
`The magnetic strip card is used to help identify the card and
`user of the card. The card provides a relatively low level of
`security for the transfer. Regardless, the card enables a card
`holder to buy products, pay debts and make monetary
`exchanges between separate bank accounts.
`Improvements have been made to the magnetic strip card.
`There have been cards created with microcircuits instead of
`magnetic strips. In general the mierocircuit, like a magnetic
`strip, is used to enable a card-reader to perform a transaction.
`SUMMARY OF THE INVENTION
`
`The present invention is an apparatus, system and method
`for communicating encrypted information between a pref-
`erably portable module and a service provider’s equipment.
`The invention comprises a module,
`that has a unique
`identification, that is capable of creating a random number,
`for example, a SALT, and passing the random number, along
`with, for example, a request to exchange money, to a service
`provider’s equipment. The service provider's equipment
`may in return encrypt the random number with a private or
`public key (depending on the type of transaction), along with
`other information and pass the encrypted information back
`to the module as a signed certificate. The module, upon
`receiving the signed certificate, will decrypt the certificate
`with a public or private key (depending on the type of
`transaction) and compare the decrypted number with the
`original random number. Furthermore, if the numbers are the
`same then the transaction that was requested may be deemed
`secure and thereby proceeds. The module is capable of time
`stamping and storing in memory information about
`the
`transaction for later review.
`
`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 is a block diagram of an embodiment of a module;
`FIG. 2 is an exemplary process for creating a transaction
`group;
`FIG, 3 is an exemplary technique for receiving an E-mail
`message;
`FIG. 4 is an exemplary technique for preparing a module
`for notary functions;
`FIG. 5 is an exemplary technique for using the module as
`a notary;
`FIG. 6 is an exemplary technique for preparing a module
`to perform a money transaction;
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`FIG. 7 is an exemplary technique for performing :1 money
`transaction using a module;
`FIG. 8 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 9 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 10 is an exemplary technique for passing data over
`a network;
`FIG. 11 is an exemplary organization of the software and
`firmware within a module; and
`_ FIG. 12 is an exemplary configuration of software and
`firmware within a module.
`
`DETAILED DESCRIPTION OF A PRESENTLY
`PREFERRED EXEMPLARY EMBODIMENT
`
`FIG. 1 depicts a block diagram of an exemplary module
`10 that
`incorporates an exemplary embodiment of the
`present invention. The module circuitry can be a single
`integrated circuit. It is understood that the module 10 could
`also be on multiple integrated or descrete element circuits
`combined combined together. The module 10 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.
`The module 10 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, in key
`fob, badge, jewelry, stamp, or practically any object that can
`be grasped and/or articulated by a user of the object.
`The microprocessor 12 is preferably an 8-bit
`microprocessor, but could be 16, 32, 64 or any operable
`number ofbits. 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 RSAcncryption and
`decryption.
`'
`The memory circuitry 20 may contain both read-only-
`memory and non-volatile random-access-memory,
`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 could be used to create an
`equivalent device.
`Control circuitry 16 provides liming, latching and various
`necessary control functions for the entire circuit.
`An input/output circuit 26 enables bidirectional commu-
`nication with the module 10. The input/output circuitry 26
`preferably comprises at least an output buffer 28 and an
`input buffer. For communication via a one-wire bus, one-
`wire interface circuitry 32 can be included with the input/
`output circuitry 26.
`An energy circuit 34 may be necessary to maintain the
`memory circuitry 2|] and/or aid in powering the other
`circuitry in the module 10. The energy circuit 34 could
`consist of a battery, capacitor, R/C circuit, photovoltaic cell,
`or any other equivalent energy producing circuit or means.
`The firmware architecture of a preferred embodiment of a
`secure transaction module and a series of sample applica-
`tions using the module 10 will now be discussed. These
`examples are intended to illustrate a preferred feature set of
`the module 10 and to explain the services that the module
`otfers, These applications by no means limit the capabilities
`of the invention, but instead bring to light a sampling of its
`capabilities.
`
`244MAX001184
`
`

`

`3
`1. OVERVIEW OF THE PREFERRED MODULE
`AND ITS FIRMWARE DESIGN
`
`The module 10 preferably 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 exponentiation 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 circuitry 26. The module 10 draws its
`operating power from the one-wire line. The micro control-
`ler 12, clock 14, memory 20, butfers 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 microcan 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 can be used, or an interface other than a
`one-wire could be used. The silicon chip can be packaged in
`credit cards, rings etc.
`The module 10 is preferably intended to be used iirst by
`a Service Provider who loads the module 10 with data to
`enable it to perform useful functions, and second by an End
`User who issues commands to the module 10 to perform
`operations on behalf of the Service Provider for the benefit
`of the End User. For this reason, the module 10 otfers
`functions to support the Service Provider in setting up the
`module for an intended application. It also 011ch 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. 11 and 12). A transaction group 40
`is simply a set of 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 oifer diiferent ser-
`vices in the same module 10. 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 Clock Oifset
`RSA Exponent Random SALT
`-Transaction Script Configuration Data
`Transaction Counter Input Data
`Money Register Output Data
`Destructor
`Within each transaction group 40 the module 10 will
`initially accept certain commands which have an irreversible
`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-
`
`‘
`
`10
`
`15
`
`20
`
`30
`
`35
`
`4o
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,805,702
`
`4
`action group 40, to which it applies, is deleted from the
`module 10. In addition, there are certain commands which
`have an irreversible effect until the end of the module’s life
`or until a master erase command is issued to erase the. entire
`contents of the module 10. These commands will be dis-
`cussed further below. These commands are essential to give
`the Service Provider the necessary control over the opera-
`tions that can be performed by the End User, Examples of
`some of the irreversible commands are:
`Privatize Object Lock Object
`Lock Transaction Group Lock Micro-In-A-CanTM
`Since much of the module ’5 utility centers on its ability to
`keep a secret,
`the Privatize command is a very important
`irreversible command.
`Once the module 10, as a whole, is locked, the remaining
`NVRAM memory 24 is allocated for a circular butler [or
`holding an audit trail of previous transactions. Each of the
`transactions are identified by the number of the transaction
`group, the number of the transaction script 40 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
`RSAkcy or keys (encryption keys) that allow the module 10
`to “Sign" transactions on behalf of the Service Provider,
`thereby guaranteeing their authenticity. By privatizing and/
`or locking one or more objects 42 in the transaction group
`40, the Service Provider maintains control over what the
`module 10 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 MODULE
`
`This section presents a series of practical applications of
`the module It], ranging from the simplest
`to the most
`complex. Each of these applications is described in enough
`detail to make it clear Why the module 10 is the central
`enabling technology for that application,
`A. BACKGROUND OF SECURE E-MAIL
`
`In this section we provide an example of how a module 10
`could be used to allow anyone to receive his or her own
`email securely at any location.
`1. Standard E-Mail
`In a standard e-mail system, a user’s computer is con-
`nected to a provider of Internet services, and the user’s
`computer provides an e-mail password when polling the
`provider’s computer for new mail. The mail resides on the
`provider’s computer in plain text form, where it can be read
`by anyone working there. In addition, while traveling from
`its source, the mail passes through many computers and was
`also exposed at these locations. If the user receives his mail
`from his provider over a local area network, anyone else on
`the same network can capture and read the mail. Finally,
`with many e-mail systems that do not require the user to
`enter the password, anyone sitting at the user’s computer can
`retrieve and read his mail, since his computer automatically
`provides the password when it polls the provider’s com—
`puter.
`It is frequently also possible to copy the password from a
`configuration file in the user’s computer and use it to read his
`
`244MAX001185
`
`

`

`5,805,702
`
`5
`mail from a dilferent computer. As a result of this broad
`distribution of the e-mail in plain text form and the weakness
`of password protection, standard e-mail is regarded as very
`insecure.
`To counter this problem, the security system known as
`P.G.P. (Pretty Good Privacy) was devised. To use P.G.P., a
`user generates a complete RSA key set containing both a
`public and private component. He makes his public key
`widely available by putting it in the signature block of all his
`email messages and arranging to have it posted in publicly
`accessible directories of P.G.P. public keys. He stores his
`private key on his own personal computer, perhaps in a
`password-protected form. When someone wishes to send
`private e-mail to this user, he generates a random [DEA
`encryption key and encrypts the entire message with the
`IDEA encryption algorithm. He then encrypts the IDEA key
`itself using the public key provided by the intended recipi-
`ent. He e-mails both the message encrypted with IDEA and
`the IDEA key encrypted with the user’s public key to the
`user. No one that sees this transmission can read it except the
`intended recipient because the message is encrypted with
`, IDEA and the IDEA key is encrypted with the intended
`recipient's public key. The recipient’s computer contains the
`corresponding private key, and hence can decrypt the IDEA
`key and use the decrypted lDEAkey to decrypt the message.
`This provides security from those who might try to read the
`user’s mail remotely, but it is less effective when the user’s
`computer is accessible to others because the computer, itself,
`contains the private key. Even if the private key is password
`protected, it is often easy to guess the user’s password or
`eavesdrop on him when he enters it, so the user’s computer
`provides little security. In addition, the user can receive
`secure e-mail only at his own computer because his private
`key is stored in that computer and is not available elsewhere.
`Therefore, the weakness of P.G.P. is that it is tied strongly to
`the user’s computer where the private key resides.
`2. Module Protected E-Mail
`With the exemplary module 10 being used to protect
`e-mail, a user could have his e-mail forwarded to him
`wherever he goes without fear that it would be read by others
`or that his PC would be the weak link- that compromises the
`security of his mail. The module protected e-mail system is
`‘ similar to the P.G.P. system, except that the private key used
`for decrypting the IDEA key is stored in a privatized object
`in a transaction group of the module 10 instead of in a PC.
`The module protected e-mail system operates as follows:
`a. Referring to FIGS. 2, 11 and 12,
`the user creates a
`transaction group 40, 31, generates an RSA key set 52 .
`and loads it into three objects 42 of the transaction
`group 40 (one RSA modulus object, N, and two RSA
`exponent objects, E and D). He then privatizcs the
`decryption exponent 53, D. Finally, he creates a trans-
`action script 44, S4 to take data placed in the input data
`object, encrypt
`it with the modulus N and private
`exponent D and place the result
`in the output data
`object. He locks the group 55 to prevent any additional
`transaction scripts 44 from being added. He “forgets”
`the value of D and publishes the values of E and N in
`public directories and in the signature blocks of his
`e-mail messages. Since he has forgotten D and since the
`D exponent object has been privatized, there is no way
`that anyone will ever find out the value of D.
`b. Referring to FIG. 3, to send secure e-mail to the user,
`the P.G.P. system is used. When the user receives the
`secure e-mail A1, he transmits the encrypted IDEA key
`into the input data object of the transaction group 40,
`
`6
`A2 and then calls the transaction script 44 to decrypt
`this key A3 and place the decrypted result in the output
`data object A4. He then reads the decrypted IDEA key
`from the output data object and uses it to decrypt his
`mail A5. Note that it
`is now impossible for anyone,-
`including the user, to read any new mail without having
`physical possession of the module 10. There is there-
`fore no way that a user’s mail can be read without his
`knowledge, because the module 10 must be physically
`present on the computer where the mail is read. The
`user can carry his module 10 wherever he goes and use
`it
`to read his forwarded mail anywhere. His home
`computer is not the weak point in the security system.
`Secure e-mail, as described above, is the simplest possible
`module application, requiring only one RSA key and one
`transaction script 44.
`It is unnecessary even to store the
`. public key E in the module 10, but it is a good idea to do so
`because the public key is supposed to be publicly accessible.
`By storing E in an exponent object and not privatizing that
`object or the modulus object, N, the user insures that the
`publickey can always be read from the module 10. There are
`no transaction scripts 44 involvingE because the module 10
`will never be required to perform an encryption.
`B. DIGITAL NOTARY SERVICE
`
`This section describes a preferred notary service using the
`module 10.
`1. Background of a Standard Notary Service
`A conventional Notary Service Provider receives and
`examines a document from an End User and then supplies an
`uncounterfeitable mark on the document signifying that the
`document was presented to the notary on a certain date, etc.
`One application of such a notary service could be to record
`disclosures of new inventions so that the priority of the
`invention can later be established in court if necessary. In
`this case, the most important service provided by the notary
`is to certify that the disclosure existed in the possession of
`the inventor on a certain date. (The traditional method for
`establishing priority is the use of a lab notebook in which
`inventors and witnesses sign and date disclosures of signifi;
`cant inventions.)
`2, Electronic Notary Service Using The Module
`A company, hereafter referred to as the Service Provider,
`decides to go into business to supply at notary service
`(strictly, a priority verification service) for its customers,
`hereafter referred to as the End Users. The Service Provider
`chooses to do this by using the module 10 as its “agents” and
`gives them the authority to authenticate (date and sign)
`docume