4
`
`that can be defined within a transaction group 40 are the
`following:
`
`Clock Offset
`
`Coofiguratioo Data
`Ra!XIom SALT
`Input Data
`
`Output Data
`
`3
`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 20 and/or aid in powering the other
`circuitry in the module 10. The energy circuit 34 could 5
`consist of a battery. capacitor. RIC circuit. phot<rvoltaic cell.
`
`or any other equivalent energy producing circuit or means.
`The fumware 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 10
`examples are intended to illustrate a preferred feature set of
`Within each transaction g�:oup 4& the module 10 will
`the module 10 and to explain the services that the module
`initially accept certain commands which have an irreversible
`otiers. These applications by no means limit the capabilities
`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
`IS until the end of the module's useful life or until the trans­
`capabilities.
`L OVERVIEW OF THE PREFERRED MODULE AND ITS
`action group 40. to which it applies. is deleted from the
`FIRMWARE DESIGN
`module 10. In addition. there are certain commands which
`The module 10 preferably contains a general-purpose.
`have an irreversible effect until the end of the module's life
`8051-compauble micro controller lZ or a reasonably similar
`20 contents of the module 1&. These commands will be dis­
`or until a master erase command is issued to erase the entire
`product. a continuously running real-time clock 14. a high­
`(math coprocessor) 18. input and output butlers 28. 30 with
`speed modular exponentiation accelerator for large integers
`a one-wire interface 32 for sending and receiving data. 32
`8 Kbytes of NVRAM (non-volatile RAM) 24 for storage of 25
`Kbytes of ROM memory 22 with preprogrammed firmware.
`critical data. and control circuitry 16 that enables the micro
`controller ll 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. butlers 28. 30. one-wire 30
`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 35
`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 40
`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 first by
`a Service Provider who loads the module 10 with data to
`enable it to perform useful functions. and second by an End 45
`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 offers
`functions to support the Service Provider in setting up the
`
`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. Ex.amples of
`some of the irreversible
`commands are:
`
`RSA M:>du!us
`RSA Exponent
`Transaction Script
`Transaction Collll!er
`Money Register
`Desttuctor
`
`Privatize Object
`Lock Thansaction Gtoup
`
`Lock Object
`Lock Micto-ln-A.Can tw
`
`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 module 10. 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 the transaction script 4t within the
`specified g�:oup. 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 4t 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 module 10
`to "sign" transactions on behalf of the Service Provider.
`thereby guaranteeing their authenticity. By privatizing and/
`or locking one « more objects 4:Z 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.
`ll. USAGE MODELS OF THE MODULE
`This section presents a series of practical applications of
`the module 10. 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
`e-mail securely at any location.
`1. Standard E-Mail
`
`lo 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
`
`module for an intended application. It also offers functions so
`
`to allow the End User to invoke the services otiered by the
`Service Provider.
`Each Service Provider can reserve a block of NVRAM
`memory to support its services by creating a transaction
`is simply a set of objects 4:Z that are defined by the Service
`group 40 (refer to FIGS. 11 and 12). A transaction group 40 ss
`Provider. These objects 42 include both data objects
`(encryption keys. transaction counts. money amounts. date/
`time stamps. etc.) and transaction scripts 44 which specify
`bow to combine the data objects in useful ways. Each 60
`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 10. The number of independent
`Service Providers that can be supported depends on the 65
`number and complexity of the objects 42 defined in each
`transaction group 40. Examples of some of the objects 42
`
`Page 498 of 544
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1008
`
`

`
`5.748.740
`
`6
`
`insecure.
`To counter this problem. the security system known as
`
`5
`provider's computer for new mail. The mail resides on lhe
`provider's computer in plain text form. where it can be read
`by anyone worJtiog there. In addition. while traveling from
`also exposed at these locations. If the user receives his mail 5
`its source. !he mail passes through many computers and was
`the same network can capture and read the rnaiJ. Finally.
`from his provider over a local area network. anyone else on
`with many e-mail systems t.hat do not require lhe user to
`retrieve and read Ills mail. since Ills computer automatically 10
`enter the password. anyone sitting at the user's computer can
`provides the password when it poUs the provider's com­
`It is frequently also possible to copy the password from a
`puter.
`configuration file in the user's computer and use it to read his
`mail from a different computer. As a result of this broad 15
`of password protection. standard e-mail is regarded as very
`distribution of the e-mail in plain text form and the weakness
`P.G.P. (Pretty Good Privacy) was devised. To use P.G.P .. a 20
`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 lhe signature block of all his
`e-mail messages and arranging to have it posted in publicly
`accessible directories of P.G.P. public keys. He stores his 25
`password-protected form. When someone wishes to send
`private key on his own personal computer. perhaps in a
`private e-mail to this user. he generates a random IDEA
`encryption key and encrypts the entire message with lhe
`IDEA encryption algorithm. He then encrypts the IDEA key 30
`itself using the public key provided by the intended recipi-
`ent. He e-mails both the message encrypted with IDEA and
`user. No one that sees this transmission can read it except the
`the IDEA key encrypted with the user's public key to lhe
`intended recipient because the message is enaypted wilh 35
`IDEA and lhe IDEA key is encrypted with the intended
`corresponding private key. and hence can decrypt the IDEA
`recipient's public key. The recipient's computer contains lhe
`Tills provides security from those who might try to read the 40
`
`key and use the deaypted IDEA key to decrypt the message.
`
`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 lhe private key is password
`eavesdrop on him when he enters it. so the user's computer 45
`protected. it is often easy to guess the user's password or
`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
`or that Ills PC would be the weak link that compromises the ss
`wherever he goes without fear that it would be read by olhers
`secwity of Ills 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 lhe 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. S1. generates an RSA key set S2
`and loads it into three objects 42 of the transaction
`exponent objects. E and D). He then privatizes the 6S
`group 40 (one RSA modulus object. N. and two RSA
`decryption ex.ponent S3. D. Finally. he creates a trans­
`action script 44. S4 to take data placed in the input data
`
`object. enaypt it with the modulus N and private
`exponent D and place lhe result in the output data
`object. He locks the group S5 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 Ills
`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
`into the input data object of the transaction group 40.
`secure e-mail AI. he transmits lhe enaypted IDEA key
`A2 and then ca!Js the transaction saipt 44 to deaypt
`data object A4. He then reads the decrypted IDEA key
`this key A3 and place the decrypted result in the output
`mail AS. Note that it is now impossible for anyone.
`from the output data object and uses it to decrypt Ills
`
`including the user. to read any new mail without having
`physical possession of the modu.le 10. There is there­
`fore no way that a user's mail can be read without Ills
`knowledge. because the module 1t must be physically
`
`present on the computer where lhe mail is read. The
`
`user can carry Ills module 10 wherever he goes and use
`it to read Ills forwarded mail anywhere. His horne
`computer is not the weak point in lhe security system.
`Secure e-mail. as described above, i.s lhe 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.
`object oc the modulus object N. lhe user insures that the
`By storing E in an exponent object and not privatizing that
`public key can always be read from the module 10. There are
`no transaction saipts 44 involving E because the module 10
`will never be required to perform an encryption.
`B. Digital Notary Service
`Tills 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
`
`uncouoterfeitable 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
`invention can later be established in court if necessary. In
`disclosures of new inventions so that the priority of the
`is to certify that the disclosure existed in the possession of
`this case. the most important service provided by the notary
`the inventor on a certain date. (The traditional method for
`so establishing priority is the use of a lab notebook in wlllch
`inventors and witnesses sign and date disclosures of signifi­
`cant inventions.)
`2. Electronic Notary Service Using lhe Module
`A company. hereafter referred to as lhe Service Provider.
`decides to go into business to supply a 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 auth<rity to authenticate (date and sign)
`60 documents on Ills behalf. The preferred operation of this
`a. Referring to FIGS. 4. 11 and 12. the Service Provider
`system is as follows:
`creates a transaction group4t for performing electronic
`
`notary functions in a "registered lot" of modules 10.
`B1.
`b. The Service Provider uses a secure computing facility
`to generate an RSA key set and program the set into
`
`Page 499 of 544
`
`

`
`5.748.740
`
`7
`every module 10 as a set of three objects 42. a modulus
`object and two exponent objects B2. The public part of
`the key set is made known as widely as possible. and
`the P£ivate part is forgotten completely by the Service
`Provider. The private exponent object is P£ivatized to
`prevent it from being read back from the modules
`c. The Service Provid.er reads the real-time clock 14 from
`each module 10 and creates a clock offset object that
`contains the difference between the reading of the
`real-time clock 14 and some convenient reference time
`
`(e.g .. 12:00 a.m. Jan. 1. 1970). The true time can then
`
`be obtained from any module 10 by adding the value of
`the clock offset object to the real-time clock B3.
`d. The Service Provider creates a transaction sequence
`counter object initialized to zero B4.
`e. The Service Provider creates a transaction script 44
`which appends the contents of the input data object to
`the true time (sum of real-time clock 14 and the value
`of the clock offset object) followed by the value of the
`transaction counter followed by the unique lasered
`
`registration number. The transaction script 44 then
`
`specifies that all of this data be encrypted with the
`private key and placed in the output data object The
`instructions to perform this operation are stored io the
`transaction group 40 as a transaction script object BS.
`f. The Service Provider privatizes any other objects 4Z
`that it does nol wish to make directly readable or
`writable B6.
`g. The Service Provider locks the transaction group 40.
`preventing any additional transaction scripts 44 from
`being added B7.
`h. Referring to flG. S. now the Service Provider distrib­
`utes the modules to paying customers (End Users) to
`use for notary services. Anytime an End User wishes to
`have a document certified. the End User performs the
`Secure Hash Algorithm (Specified in the Secure Hash
`Standard. FIPS Pub. 180) to reduce the entire dorument
`to a 20 byte message digest. The End User then
`object C1 and calls on the transaction script 44 to bind
`transmits the 20 byte message digest to the input data
`
`the message digest with the true time. transaction
`counter. and unique lasered serial number and to sign
`i. The End User checks the certificate by decrypting it
`the resulting packet with the private key C2.
`with the public key and checking the message digest.
`true time stamp. etc. to make sure they are correct C3.
`The End User then stores this digital certificate along
`with the original copy of the document in digital form
`C4. The Service Provider will attest to the authenticity
`of the certificates P£oduced by its modules.
`j. After a period of time specified by the Service Provider.
`the user retum.s his module 10. pays a fee. and gets a
`new module containing a new private key. The old
`modules can be recycled by erasing the entire transac­
`tion group and reprogramming them. The Service Pro­
`vider maintains an archive of all the public keys it has
`ever used so that it can testify as needed to the
`authenticity of old certificates.
`C. Digital Cash Dispenser
`This exemplary usage model focuses on the module 10 as
`a cash reservoir from which payments can be made for
`goods or services. (To simplify the discussion. the subject of
`refilling the module 10 with cash is postponed until later). In
`this case the Service Provider is a bank or other financial
`institution. the End User is the bank's customer who wishes
`to use the module 10 to make purchases. and the Merchant
`
`8
`is the provider of the purchased goods or services. The roles
`of the Service Provider. the Merchant. and the End User in
`these transactions are explained in detail below.
`The fundamental concept of the digital cash purse as
`5 implemented in the module 10 is that the module 10 initially
`value. and the module It ca.n generate. on demand. certifi­
`contains a locked money object containing a given cash
`10 from the value of the money object These signed documents
`
`cates which are essentially signed documents attesting to the
`fact that the amount of money requested was subtracted
`
`are equivalent to cash. since they attest to the fact that the
`internal money object was decreased in value by an amount
`corresponding to the value of the certificate. The merchant
`can redeem these certificates for cash by returning them to
`
`15 the Service Provider.
`
`When dealing with digital certificates representing cash.
`"replay" or duplication is a fundamental problem. Since
`digital data can be copied and retransmitted easily. it differs
`
`issued certificate. This problem can be solved by having the
`
`payee receives this certificate. he decrypts it with the public
`key. checks the money amount. and then confirms that the
`
`from ordinary coins or paper money which are difficult to
`20 reproduce because of the special technology that is used in
`their manufacture. For this reason. the receiver of the
`certificate he receives is not a replay of some previously
`payment must take special steps to insure that the digital
`25 payee generate a random "SALT'. a challenge number. and
`provide it to the payer.
`is sent and used in a challenge/response mode. The other
`SALT is a method of P£eventing replay. A random number
`party is challenged to return the random number as part of
`30 their response.
`both the money amount and the payee's SALT. When the
`The payer constructs a signed certificate which includes
`35 SALT is the same as the one he provided. By personalizing
`
`the certificate to the payee. the payer proves to the payee that
`the certificate is not a duplicate or replay and is therefore
`authentic. This method can be used regardless of whether the
`module 1t is the payer or the payee.
`
`40 Another problem that must be addressed is .irrepudiability.
`This means that none of the parties to the transaction should
`be able to argue that he did not actually participate in the
`transaction. The transaction record (money certificate)
`45 transaction was a willing participant
`should contain elements to P£ove that each party to the
`1. Background Conventional Cash Transactions
`In a conventional cash transaction. the End User first
`receives Federal Reserve Notes from a bank and the bank
`subtracts the equivalent amount of money from the balance
`50 in his account. The End User can verify the authenticity of
`the Federal Reserve Notes by means of the "public key".
`a. Magnetic ink attracted by a magnet.
`which includes:
`b. Red and blue threads imbedded in the paper.
`c. Microfine printing surrounding the engraved portrait.
`d. Embedded stripe printed with USA and denomination
`of the note.
`The "private key" to this system is the details of how the
`raw materials for printing money are obtained and how the
`
`ss
`
`60 money is actually P£inted. This information is retained bv
`
`the government and not revealed.
`These notes are carried by the End User to the Merchant
`where they are exchanged for goods or services. The Mer­
`chant also uses the "public key" of the notes to verify that
`65 they are legitimate.
`Finally. the Merchant carries the notes to a Bank. where
`the "public key" is again examined by the teller. If the notes
`
`Page 500 of 544
`
`

`
`5)48.740
`
`9
`are legitimate. the Merchant's bank account balance is
`increased by the face value of the notes.
`The end result of this transaction is that the End User's
`bank balance is reduced. the Merchant's bank balance is
`
`increased by the same amount. the goods or services are s
`
`transferred from the Merchant to the End User. and the
`Federal Reserve Notes are ready to be reused for some other
`transaction.
`2. Exemplary Monetary Transactions Using the Module
`cenl.ficares are somewhar more complicated because digital
`Monetary transactions using the module 10 and digital 10
`data. unlike Federal Reserve Notes. can be copied and
`duplicated easily. Nevertheless. the use of "SALTs" and
`of digital certificates. (In the following discussion. it is
`transaction sequence nwnbers can guarantee the authenticity
`assumed that every party to the transaction has its own RSA
`key set with a private key that it is able to keep secret.)
`a. Referring to FIG. 6. the Service Provider (bank) pre­
`pares the module 10 by creating a transaction group 40
`value stored in the module 10. The Service Provider
`containing a money object representing the monetary 20
`also creates a transaction count object. a modulus
`private key in the exponent object D1. He privatizes the
`object. and an exponent object and stores the provider's
`key so that it cannot be read D2. Next. he stores a 2S
`transaction script 44 in the transaction group 40 to
`so that no further objects can be made D3. D4. (The
`perform the monetary transaction and locks the group
`details of what this transaction script does are described
`further below.) Finally. he publishes the corresponding 30
`public key widely so that anyone can obtain it DS.
`b. The End User receives the module 10 from the Service
`Provider. and the End User's bank account is debited by
`handheld computer. the End User can interrogate the 35
`the amount stored in the module 10. Using a PC or
`module 10 to verify that the balance is correct.
`C. Referring to FIG. 7. when the End User wishes to
`purchase some goods or services from a Merchant E1.
`nwnber of the module and places it in a packet along 40
`the Merchant reads the unique lasered registration
`with a random SALT E2. E3. The merchant then signs
`this packet with the merchant's own private key E4 and
`amount of the purchase to the input data object of the
`transmits the resulting encrypted packet along with the
`transaction group 40. ES.
`d. The Merchant then invokes the transaction script 44
`programmed into the module 10 by the Service Pro­
`vider. This transaction script 44 subtracts the amount of
`the purchase from the money object E6. appends the 50
`value of the transaction counter object to the contents
`of the input data object E7. signs the resulting packet
`with the private key. and places the result in the output
`data object E8.
`e. The Merchant then reads the result from the output data 55
`object and decJypts it with the Service Provider's
`public key E9. He then confirms that the amount of the
`purchase is correct and that the remaining data is
`f. Having confirmed that the certificate provided by the 60
`identical to the packet he signed in step c .. E10.
`module It is both authentic and original (not a
`duplicate). the Merchant delivers the goods or services
`Ell. Later the Merchant sends the digital certificate to
`g. The bank decrypts the certificate with the Service 65
`a bank.
`
`IS
`
`4S
`
`Provider's public key EU. extracts the amount of the
`purchase and the transaction count. and decrypts the
`
`10
`remauung data with the Merchant's public key to
`reveal the unique lasered registration number of the
`module E14. The bank then looks up the module 10 by
`
`the unique lasered registration number in a database to
`confirm that the transaction count for this transaction
`has not been submitted before. When this test is passed.
`the bank adds the transaction count value to the
`database. and then increases the Merchant's bank bal­
`ance by the amount of the purchase E15. The fact that
`module 10 and the Merchant confirms that the trans­
`portions of the certificate were signed by both the
`action was freely agreed to by both the Merchant and
`the module 10.
`combinations of the transaction counter value. the unique
`Note that there are many different ways of combining data
`lasered registration number. the random SALT provided by
`payee. and the amount of purchase. encrypted by the mod­
`ule's private key. the Merchant's private key. or both. Many
`of these combinations can also provide satisfactory guaran­
`tees of uniqueness. authenticity. and irrepudiability. and the
`design of the firmware allows the Service Provider flexibil­
`
`ity in writing the transaction script 44 to serve his particular
`needs.
`D. Digital Cash Replenishment
`The discussion of a digital cash purse is section n.c..
`above. did not address the issue of cash replenishment The
`Service Provider can add cash replenishment capability to
`the module 10. as discussed in section n.c .. simply by
`adding another modulus object and exponent object con­
`taining the Service Provider's public key. a random SALT
`object. and a transaction script 44 for adding money to the
`balance. The Service Provider can add money to a module
`10 either in person or remotely over a network. The process
`1. Referring to FIG. 8. the Service Provider reads the
`of adding money is as follows:
`module Fl. F2 and calls on a transaction script 44 to return
`unique lasered registration nwnber (ID number) of the
`the value of a random SALT object. The module 10 calcu­
`lates a new random SALT value from the previous value and
`the random nwnber generator and returns it to the Service
`Provider F3.
`2. The Service Provider places the random SALT returned
`by the module 10 in a packet along with the amount of
`money to be added and the unique lasered registration
`number of the module 10 and then encrypts the resulting
`packet with the Service Provider's private key F4. This
`encrypted packet is then written back into the input data
`3. The Service Provider invokes a transaction script 44
`object of the transaction group 40.
`which decrypts the contents of the input data object with the
`Service Provider's public key and then checks the unique
`SALT against the one that it originally provided. If the SALT
`lasered registration nwnber and the value of the random
`added to the value of the money object in the module FS.
`Note that the inclusion of the unique lasered registration
`nwnber is not strictly necessary. but it is included to insure
`that the Service Provider knows exactly which module is
`receiving the funds.
`E. Exemplary Description of Direct Transfer of Funds
`Section IT.C.2.g. above reveals a problem that occurs
`Between Modules
`when the Merchant returns the digital certificates to his bank
`for crediting to his account. The Merchant's bank must
`either send the certificates back to the Service Provider for
`in a database so that it can determine whether the value of
`redemption. or have access to the Service Provider's records
`
`matches. the money amount is extracted from the packet and
`
`Page 501 of 544
`
`

`
`5.748,740
`
`11
`the transaction count object is unique. 'This is inconvenient
`and requires infrastructure. It also prevents any of the
`transactions from being anonymous (as they would have
`been if cash had been used). because the Merchant's bank
`must log used certificate numbers into a database to prevent 5
`them from being reused. These problems can all be elimi­
`nated by making use of fund transfers between modules. In
`addition. the steps required to accomplish a fund transfer
`between modules are considerably simpler than those
`described in section D.C.2.
`In the discussion which follows. it is assumed that the
`Merchant also has a module which he uses to collect the
`funds received from End Users (customers). The module in
`the possession of the End User will be called the Payer. and
`the module in the possession of the Merchant will be called
`the Payee. The steps to accomplish the funds transfer are as
`follows:
`1. Referring to FIGS. 9. 11 and 12. using his computer. the
`Merchant calls on a transaction script 44 in the Payee to
`provide a random SALT. He reads this SALT from the output
`2. The Merchant copies the SALT and the amount of the
`object of the transaction group 4&.
`End User's purchase to the input data object of the Payer Gi.
`
`12
`the Payee. The Payee then encrypts this packet with the
`Service Provider's private key and sends it back to the Payer
`H2.
`3. The Payer deaypts the packet with the Service Pro­
`vider's public key H3. extracts the Payer SALT. and com­
`pares it with the SALT that the Payer provided in step 1. H
`they agree. the Payer subtracts the amount of the purchaser
`from its balance H4 and generates a certificate consisting of
`the amount of the purchase and the Payee's SALT. which it
`10 encrypts with the Service Provider's private key and returns
`to the Payee HS.
`4. The Payee decrypts the packet with the Service Pro­
`vider's public key H6. extracts the Payee SALT. and com­
`pares it with the SALT that the Payee provided in step 2. If
`15 they agree. the Payee adds the amount of the purchase to its
`balance H7.
`The exchange of SALTs allows each module to confirm
`that it is communicating with another module. and that the
`funds transfer requested is therefore legitimate. The SALT
`20 comparison described in step 3 allows the Payer to confirm
`that the Payee is a legitimate module IO before the funds are
`withdrawn. and the comparison described in step 4 allows
`the Payee to confirm that the Payer is a legitimate module I 0
`before the funds are deposited. The transactions described
`
`25 above provide the minimum necessary information in the
`
`then calls on a transaction script 44 in the Payer to subtract
`the amount of the purchase from the balance. combine the
`Payee's SALT in a packet with the amount of the purchase.
`private key. and return it in the output data object G2.
`encrypt the resulting package with the Service Provider's
`3. The Merchant then reads this packet and copies it to the
`input data object of the Payee. then calls on a transaction
`script 44 in the Payee to decrypt the packet with the Service
`one originally generated by the Payee. H they agree. the
`Provider's public key G3 and check the SALT against the
`Payee adds the amount of the purchase to its balance G4.
`This completes the funds transfer. Note that this transac­
`tion effectively transferred the amount of the purchase from
`the Payer to the Payee. and the steps of the transaction were
`much simpler than the three-way transaction described in
`ll.C.2. The Merchant can transfer the balance to his bank
`account by a similar transaction in which the bank provides 40
`a SALT to Merchant's module and the Merchant's module
`prepare