Patent Application
`Docket #20661/457
`
`amount of purchase, encrypted by the module's
`
`private key, the Merchant's private key, or both .
`
`Many of these
`
`combinations
`
`can also
`
`provide
`
`satisfactory guarantees of uniqueness, authenticity,
`
`and irrepudiability, and the design of the firmware
`allows the Service Provider flexibility in writing
`the transaction script 44 to serve his particular
`
`needs.
`
`5
`
`D.
`
`DIGITAL CASH REPLENISHMENT
`
`10
`
`The discussion of a digital cash purse is
`
`....
`
`15 .
`
`section II.C., above, did not address the issue of
`
`The Service Provider can add
`cash replenishment.
`cash replenishment capability to the module 10, as
`
`discussed in section II.C., simply by adding another
`
`modulus object and exponent object containing 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
`
`20
`
`network. The process of adding money is as follows:
`
`IPDI\L:, 1991.1 /2o661·45,
`
`38
`
`Page 76 of 544
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1008
`
`
`Docket #20661/457
`
`amount of purchase, encrypted by the module's
`
`private key, the Merchant's private key, or both .
`
`Many of these
`
`combinations
`
`can also
`
`provide
`
`satisfactory guarantees of uniqueness, authenticity,
`
`and irrepudiability, and the design of the firmware
`allows the Service Provider flexibility in writing
`the transaction script 44 to serve his particular
`
`needs.
`
`5
`
`D.
`
`DIGITAL CASH REPLENISHMENT
`
`10
`
`The discussion of a digital cash purse is
`
`....
`
`15 .
`
`section II.C., above, did not address the issue of
`
`The Service Provider can add
`cash replenishment.
`cash replenishment capability to the module 10, as
`
`discussed in section II.C., simply by adding another
`
`modulus object and exponent object containing 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
`
`20
`
`network. The process of adding money is as follows:
`
`IPDI\L:, 1991.1 /2o661·45,
`
`38
`
`Page 76 of 544
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1008
`
`
`
`Patent Application
`Docket #20661/457
`
`1.
`
`Referring to FIGURE 8,
`
`the Service
`
`Provider reads the unique lasered registration
`
`number (ID number) of the module Fl, F2 and calls on
`
`a transaction script 44 to return the value of a
`
`5
`
`random SALT object. The module 10 calculates a new
`
`random SALT value from the previous value and the
`
`random number generator and returns it to the
`
`Service Provider F3.
`
`2.
`
`The Service Provider places the random
`
`10
`
`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
`
`15
`
`then written back into the input data object of the
`
`transaction group 40.
`
`/
`
`3.
`
`The Service Provider invokes a transaction
`
`script 44 which decrypts the contents of the input
`
`data object with the Service Provider's public key
`
`20
`
`and then checks the unique lasered registration
`
`I PDAL: 71997.1 I 20661-451
`
`39
`
`·-
`
`Page 77 of 544
`
`
`
`' .
`
`Patent Application
`Docket #20661/457
`
`number and the value of the random SALT against the
`
`one that it originally provided.
`
`If the SALT
`
`matches, the money amount is extracted from the
`
`packet and added to the value of the money obj ect in
`
`5
`
`the module FS.
`
`Note that the inclusion of the unique lasered
`
`registration number is not strictly necessary, but
`
`it is included to insure that the Service Provider
`
`knows exactly which module is receiving the funds.
`
`--
`
`10
`
`15
`
`20
`
`E.
`
`EXEMPLARY DESCRIPTION OF DIRECT TRANSFER OF
`FUNDS BETWEEN MODULES
`
`Section II.C.2.g. above reveals a problem that
`
`occurs when the Merchant returns
`
`the digital
`
`certificates to his bank for crediting to hie
`
`account. The Merchant's bank must either send the
`
`certificates back to the Service Provider for
`
`f
`
`redemption, or have access to the Service Provider's
`
`records in a database so that it can determine
`
`whether the value of the transaction count obj ect is
`
`unique.
`
`This
`
`is
`
`inconvenient
`
`and requires
`
`40
`
`Page 78 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`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 them from being reused.
`These problems can all be eliminated by making use
`
`of fund transfers between modules.
`
`In addition, the
`
`steps required to accomplish a fund transfer between
`
`modules
`are
`considerably
`described in section II.C.2.
`
`simpler
`
`than
`
`those
`
`In the discussion which follows, it is assumed
`
`that the Merchant also has a module which he uses to
`collect
`
`received
`
`from
`
`End
`
`Users
`
`the
`
`funds
`
`5
`
`10
`
`15
`
`The module in the possession of the
`( customers) .
`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 FIGURES 9, 11 and 12, using
`
`20
`
`his computer, the Merchant calls on a transaction
`
`IPDI>J.:11997.1/2o66l-457
`
`41
`
`Page 79 of 544
`
`
`
`Patent Application
`Docket #20661/457
`script 44 in the Payee to provide a random SALT. He
`reads this SALT from the output object of the
`
`transaction group 40.
`
`2 .
`
`The Merchant copies the SALT and the
`
`5
`
`amount of the End User's purchase to the input data
`object of the Payer Gl, 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, encrypt
`
`10
`
`the resulting package with the Service Provider's
`
`private key, and return it in the output data object
`
`G2.
`
`3 .
`
`The Merchant then reads this packet and
`
`copies it to the input data object of the Payee,
`
`15
`
`then calls on a transaction s�ript 44 in the Payee
`
`/
`
`to decrypt the packet with the Service Provider's
`
`public key G3 and check the SALT against the one
`
`originally generated by the Payee.
`
`If they agree,
`
`the Payee adds the amount of the purchase to its
`
`20
`
`balance G4 .
`
`I�OI\l..: 71997 .l/20661-457
`
`42
`
`Page 80 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`This completes the funds transfer.
`
`Note that this
`
`transaction 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 II.C.2.
`
`The Merchant can
`
`5
`
`transfer the balance to his bank account by a similar
`
`transaction in which the bank provides a SALT to
`Merchant's module and the Merchant's module prepares a
`
`certificate for the balance which it delivers to the
`
`10
`
`bank. Use of a module by the Merchant to collect funds
`
`simplifies the transaction, eliminates the need for a
`
`database to confirm uniqueness,
`
`and preserves the
`
`anonymity of the End User that would normally result from
`
`a cash transaction.
`
`15
`
`F. EXEMPLARY TRANSACTIONS WITH A MODULE OVER A
`NETWORK
`
`I
`
`20
`
`The transactions described in section II.C.2.,
`
`II.D. and II.E. above could also be performed over
`
`a network, allowing a physical separation between
`
`the Merchant, End User, and modules. However, this
`
`could produce a potential problem because one of the
`
`IPDAL: 71997. 1 I 20661-451
`
`43
`
`Page 81 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`communications to the �odule 10 is unencrypted and
`
`therefore subject to falsification. To avoid this
`
`problem, both parties must produce a SALT so that
`
`the other can demonstrate its ability to encrypt the
`
`5
`
`SALT with the Service Provider's private key and
`
`therefore prove authenticity. The operation of this
`
`protocol is described as follows as it relates to
`
`the transfer of funds between modules (section II.E.
`
`above) . This method can be employed to allow any of
`
`10
`
`the transactions described above to take place over
`
`a network. This clearly enables secure electronic
`
`-�
`
`commerce over the Internet.
`
`15
`
`/
`
`1.
`
`Referring to FIGURE 10, 11 and 12, the
`Payer generates a random SALT and transmits it over
`the network to the Payee Hl.
`
`2.
`
`The Payee appends the amount of the
`
`purchase to the Payer's SALT, followed by a SALT
`
`randomly generated by the Payee.
`
`The Payee then
`
`encrypts this packet with the Service Provider's
`
`20
`
`private key and sends it back to the Payer H2.
`
`IPOI\L: 71997.1/20661-4 57
`
`44
`
`i
`\.
`
`Page 82 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`3.
`
`The Payer decrypts the packet with the
`
`Service Provide r ' s public key H3, extracts the Payer
`
`SALT , and compares it with the SALT that the Payer
`provided in step 1 .
`
`If they agree, the Payer
`
`5
`
`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 encrypts with the Service Provider ' s
`
`private key and returns to the Payee HS.
`
`10
`
`4 .
`
`The Payee decrypts the packet with the
`
`Service Provider ' s public key H6, extracts the Payee
`
`SALT, and compares it with the SALT that the Payee
`
`provided in step 2.
`If they agree, the Payee adds
`the amount of the purchase to its balance H7.
`
`15
`
`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 comparison described in step 3 allows the Payer
`
`to confirm that the Payee is a legitimate module 1 0
`
`20
`
`before the funds are withdrawn , and the comparison
`
`45
`
`Page 83 of 544
`
`
`
`.
`
`l
`
`Patent Application
`Docket #20661/457
`
`described in step 4 allows the Payee to confirm that the
`
`Payer is a legitimate module 10 before the funds are
`
`deposited. The transactions described above provide the
`
`minimum necessary information in the encrypted packets to
`
`5
`
`confirm that the funds are being transferred from one
`
`module 10 to another. Other information, such as the
`
`unique lasered registration number, could be included (at
`
`the cost of anonymity) to provide additional information
`
`and greater control over the transaction.
`
`10
`
`G . AN
`EXEMPLARY TECHNIQUE FOR
`AUTHORIZATION AND USAGE METERING
`
`SOFTWARE
`
`The module 10 is well-suited for the tasks of
`
`enabling specific software features in
`
`a
`
`comprehensive software system and for metering usage
`
`15
`
`of those features . {This usage model parallels the
`
`previously described model for withdrawing money
`
`from a module 10 . )
`
`/
`
`46
`
`'-,
`
`Page 84 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`1 .
`
`Preparation
`
`Referring to FIGURES 11 and 12, the Service
`
`Provider creates a transaction group 4 0 and stores
`
`5
`
`a configuration object in the group detailing which
`software within the module 10 the End User is
`
`allowed to use. The Service Provider also creates
`
`a money object containing the allowed usage credit
`
`(which could be in units of time rather than the
`
`actual dollar amount ) , and stores and privatizes a
`
`10
`
`private RSA key pair to use for authenticatio n . A
`
`transaction script 44 is stored to receive a SALT
`and the amount to · withdraw from the End User,
`
`decrement the balance by the amount withdrawn, and
`
`output an RSA signed certificate containing the
`
`15
`
`amount withdrawn , the sale, and the value of the
`
`configuration object.
`
`2.
`
`Usage
`
`/
`
`At periodic intervals during the use of the
`
`software within the module 10, the PC program
`
`2 0
`
`generates a random SALT and an amount to charge for
`
`the use of the module
`
`10 and transmits this
`
`...... .....
`�
`c;
`?-� 'I"'
`::-...c.
`';d. " �
`... -
`�-""' ,' ' :;;.
` �
`·"" id;J
`�j
`
`-=
`
`I POAL: '1199'1.1 I 20661-�5'1
`
`4 7
`
`r
`· .... ,·
`
`\
`
`Page 85 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`information to the module 1 0 .
`
`The module 10
`
`decrements the balance and returns the certificate .
`
`The PC decrypts the certificate and confirms that
`
`the SALT is the same, the amount withdrawn is
`
`correct, and the use of the software within the
`module 10 is authorized by the information stored in
`
`the configuration object.
`
`If all of these tests are
`
`successful, the module 10 executes for a specified
`
`· period of time or for a given number of operations
`
`5
`
`10
`
`before asking the module 10 for another certificate .
`
`There are many possible variations on this
`
`usage model. For example, the transaction script 44
`
`could also bind up the true time in the certificate
`
`so that the application program running on the PC
`
`15
`
`could guarantee
`
`that
`
`the execution
`
`time is
`
`accurately measured.
`
`(This would require the
`
`Service Provider to create a clock offset object
`
`during initialization to provide a reference for
`
`/
`
`measuring time . )
`
`48
`
`'
`
`> I
`l. ·i I I
`
`Page 86 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`H.
`
`SIMULATION OF TRANSACTION TOUCH MEMORY�
`
`This usage model describes how the module 10
`
`can be used to simulate the behavior of the simpler
`
`Transaction Touch Memory™
`
`(OS 1962)
`
`(hereinafter
`
`5
`
`"TTM") or any similar device or substitute that can
`
`operate in a nearly equivalent or similar fashion.
`
`The principal feature of the TTM is that there is a
`
`counter associated with a block of memory in such a
`
`way that the counter is incremented automatically
`
`10
`
`whenever the contents of the memory block are
`
`changed.
`
`1 .
`
`Preparation
`
`' ,;,.•
`
`This simple feature can be programmed into the
`module 10 by creating a configuration object, a
`
`15
`
`transaction counter object, and a transaction script
`
`object which combines the contents of the input
`
`I
`
`object with the value of the transaction counter
`
`object and places them in the configuration object,
`
`incrementing the counter automatically in the
`
`20
`
`process. All three objects 42 are locked, but none
`
`are privatized.
`
`IPDI\L: 11991.1/20661-4 57
`
`4 9
`
`.. \ \
`
`Page 87 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`2.
`
`Usage
`
`To add or remove money, the End User reads the
`
`values of
`
`the
`
`configuration object
`
`and
`
`the
`
`transaction counter object directly, then decrypts
`
`5
`
`the configuration object and checks the transaction
`
`count from the decrypted package against the value
`
`of the counter object. The End User also checks the
`
`unique
`
`lasered registration
`
`number
`
`from
`
`the
`
`encrypted packet against the registration number of
`the module 10 .
`If these both agree, the balance i s
`considered valid . An amount is added to or
`
`subtracted from the balance, the transaction count
`
`is incremented, and the packet is re-encrypted and
`
`stored in the input data obj ect. The transaction
`
`script 44 is then invoked to move the data and the
`
`transaction counter value to the configuration
`
`'
`,... _,
`
`10
`
`15
`
`object, automatically incrementing the counter value
`
`/
`
`in the proces s .
`
`(The transaction script 4 4
`
`guarantees that the counter object ' s value will be
`
`20
`
`incremented anytime data in the configuration object
`
`is changed . )
`
`IPOAL: 11991.1 /20661-457
`
`50
`
`\
`
`Page 88 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`This
`
`simple
`
`operation
`
`can be performed
`
`relatively quickly since the module 10 does not have
`
`to perform any encryption itself. However, as with
`
`the TTM, the End User must now use a secure
`
`5
`
`computing facility to perform the encryption and
`
`decryption operations. This usage is therefore less
`
`protected than those which depend on the module ' s
`
`encryption capabilities.
`
`:::)
`
`I.
`
`EXEMPLARY TECHNIQUE FOR POSTAL METERING SERVICE
`
`10
`
`This usage model des cribes an application in which
`
`the module 10 is used to dispense postage certificates.
`
`The digital information which constitutes the certificate
`
`is printed on the envelope in the form of a two-
`
`""· ='
`
`15
`
`dimensional barcode which can be read and authenticated
`
`( U . S . P . S. ) . A computer program
`by the Service Provider
`running on an ordinary PC attached to a laser printer in
`
`combination with the module 1 0 can be used to print the
`/.
`'postage certificates .
`
`I POAL: 71997. 1 I 20661-457
`
`51
`
`Page 89 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`1 .
`
`Preparation
`
`The Service Provider creates a group containing
`
`a money register, a private RSA key (exponent object
`
`and modulus object) common to every module, and a
`
`transaction script 4 4 . The script 4 4 combines the
`
`SALT and the amount to be withdrawn
`
`(provided by the
`
`End User's computer) with the unique
`
`lasered
`
`registration number of the module 1 0 , encrypts this
`
`packet with the private key, subtracts the amount
`
`withdrawn from the balance, and places the encrypted
`
`certificate in the output object where it can be
`
`read by the PC.
`
`5
`
`1 0
`
`4�
`. . -
`
`The Service Provider initializes the balance
`
`with a specific amount of money, locks the balance
`
`15
`
`and script 4 4 , privatizes the RSA key objects, and
`
`locks the group so that no more scripts can be
`
`added. The modules prepared in this way can then be
`
`/
`
`sold over the counter for use with PC-based postage
`
`metering programs .
`
`52
`
`Page 90 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`2.
`
`Usage
`
`When the first envelope i s to be printed, the
`
`PC program prepares the first SALT by cal culating a
`
`one-way hash ( e . g . , the Secure Hash Standard , FI�
`
`PUB
`
`1 8 0 ) of the date and the unique lasered
`
`registration number of the part.
`
`This information
`
`is passed to the module 10 along with the amount of
`
`postage to be withdrawn. The resulting certificate
`
`is printed in the two-dimensional barcode along with
`
`1 0
`
`the
`
`the hash generation number
`(one for the first hash) ,
`registration number,
`
`the unique
`
`lasered
`
`plaintext denomination of the stamp, the date, and
`
`other information as desired to identify the End
`
`User . Subsequent SALTs are generated by performing
`
`15
`
`the one-way hash again on the previous SALT and
`
`incrementing the hash generation number.
`
`I
`
`20
`
`When
`
`the
`
`Service
`
`Provider
`
`receives
`
`the
`
`envelopes, most of them are taken at face value and
`
`the digital barcode is not read .
`
`However, a
`
`statistical sampling of the barcodes are read and
`
`the information provided is decrypted with the
`
`IPDAL: 71997.1/20661-4 57
`
`53
`
`�\
`
`. /
`
`Page 91 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`public key and verified.
`
`Discrepancies are
`
`investigated, and fraud is prosecuted under existing
`
`law. Verification is possible because the Service
`
`Provider can recreate the SALT from the unique
`
`5
`
`lase red registration number,
`
`date,
`
`and hash
`
`generation number, and thereby verify that the
`
`transaction is not only current but also linked to
`
`a specific module 10.
`
`Note that there are many possible variations on
`
`10
`
`the method described above, leading to similar
`
`results .
`
`The most
`
`likely
`
`fraud would be
`
`duplication, in which a user captures the digital
`information sent to the printer to produce the
`
`postage certificate and makes many duplicate copies
`
`of the same certificate .
`
`This could be detected
`
`easily by the Service Provider simply by reading the
`
`15
`
`hash generation number and unique registration
`
`/
`
`number and looking them up in a database to make
`
`sure that the user is not duplicating the same
`
`20
`
`certificate.
`
`(This check could be performed more
`
`1PDAL:11997. I I 20661-4 57
`
`54
`
`Page 92 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`often than full certificate verification, which
`
`would require RSA decrypt ion . )
`
`J.
`
`SUBSCRIPTION INFORMATION SERVICE
`
`This usage model describes an appl ication in which
`
`S
`
`a Service Provider makes available
`
`information in
`
`encrypted form over the internet to users who have agreed
`
`to pay for �·such information.
`
`This application works
`
`exactly the same way as the Secure E-mail usage model
`
`described in section A above, except that the Service
`
`10
`
`Provider bills the user for the encrypted information
`
`·�
`
`that the Service Provider e-mails to him.
`
`The billing
`
`information is obtained from a registry of pubic RSA keys
`
`which allows the Service Provider to identify and bill a
`
`user, based on his public key or on the unique lasered
`
`15.
`
`serial number of his module 1 0 .
`
`K .
`
`REGISTRY WITH GUARANTEED PRIVATE KEY SECURITY
`
`/
`
`In order to provide Merchants with an independent
`
`confirmation of the identity of an End User, a Service
`
`Provider may wish to maintain a registry containing the
`
`20
`
`pubic key of a particular module 10 along with the name,
`
`IPDA!.: 71997.1/20661-4 57
`
`55
`
`Page 93 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`address, and other identifying information of the person
`
`to whom the module 10 is issued. For this purpose , it is
`
`essential for the Service Provider to make sure that the
`public key in the registry corresponds to a private key
`
`5
`
`which is known only to the module 10.
`
`In order to
`
`guarantee thi s , the module 10 must be in the possession
`
`of the Service Provider at the time the public key is
`extracted from the module 10 and placed in the registry .
`
`After recording this information in the registry, the
`Service Provider can ship the module 10 to the End User
`
`10
`
`named in the registry.
`
`It is also important for the End User to be able to
`
`confirm, when he receives the module 10, that the private
`
`key is not known to the Service Provider or any of the
`
`15
`
`Service Provider ' s employees. This is important because
`
`an ideal registry system should not require that any
`
`The system works to
`party trust any other party.
`/everyone ' s satisfaction only· when each party can be
`
`convinced that none of the other parties could possibly
`know the private key.
`
`2 0
`
`I PDAL: 71997. 1(20661-457
`
`56
`
`Page 94 of 544
`
`
`
`Patent Application
`Docket #20661/457
`One way to accomplish this, the service Provider
`sends a command to the module 10 to cause it to generate
`a complete RSA key set using random numbers, and then to
`automatically make one of the exponents private, so that
`there is no way any person can discover the value of the
`private key. This key set has a special type , different
`from that of a key set programmed into the can by a
`Service Provider, so that anyone doing business directly
`\.,rith the module 10 can determine for themselves that the
`private key is known only to the module 1 0 .
`Preparation
`l .
`The Service Provider creates a password-
`protected transaction group 40 for the application,
`and then creates an RSA key set in the group that is
`(After generating the
`generated by the module 10 .
`key set, the modulus and one exponent will be locked
`automatically, while the second exponent will be
`privatized automatically by the firmware of the
`The Service Provider then creates a
`transaction script 44 which will encrypt data from
`the input object with the private key and place the
`in the output object.
`encrypted result
`
`/
`
`module 10.
`
`The
`
`57
`
`S
`
`10
`
`15
`
`20
`
`Page 95 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`transaction script 44 might optionally append
`( e . g . •
`
`additional information
`
`the
`
`transaction
`
`counter) to the data from the input object, in order
`
`to satisfy any additional objectives of the
`Other objects 42 and transaction
`
`application.
`
`scripts 44 may also be added at the discretion of
`
`the Service Provider. The transaction group 40 is
`
`locked .by the Service Provider when it is complete .
`
`Next, the Service Provider reads the RSA
`
`modulus and public exponent from the transaction
`
`group 40 and records them in the registry along with
`
`the information identifying the End User. Finally,
`
`the Service Provider ships the module 10 to the End
`
`User, and later conveys to the End User the password
`that can be used to access the transaction group 40.
`
`5
`
`10
`
`15
`
`2 .
`
`Usage
`
`I
`
`When a Merchant wishes to obtain positive
`
`identification of an End User over the Internet or
`
`other network, the Merchant generates a unique
`
`20
`
`packet of data and transmits it to the End User, and
`
`58
`
`Page 96 of 544
`
`
`
`s
`
`10
`
`Patent Application
`Docket #20661/457
`
`the End User passes the data into the input object
`
`and invokes the transaction script 44 which causes
`
`it to be encrypted with the private key generated by
`
`the module 1 0 . The resulting encrypted packet is
`
`transmitted back to the Merchant . The Merchant then
`
`accesses the data base provided by the Service
`
`Provider to obtain the public key belonging to the
`
`End User, and attempts to decrypt the encrypted
`
`packet using the End User's public key.
`
`If the
`
`decryption succeeds, the Merchant has proven the
`physical presence of the End User's module 10 at the
`
`remotely networked location.
`
`By guaranteeing the
`
`presence of the End User ' s module 10 at the remote
`
`site, this identification validates and legitimizes
`
`15
`
`the contents of the data packet and therefore also
`
`any financial transactions, represented by the
`
`contents of the packet, that may be requested by the
`
`End User.
`
`I
`
`20
`
`The model described here is one in which the
`
`authority to perform financial transactions derives from
`
`the registry maintained by the Service Provider.
`
`It is
`
`1 PDAL: 11991. 1 I 20661-451
`
`59
`
`{
`
`Page 97 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`therefore essential that this information be accurate and
`
`that the private key in the module 10 can be secure from
`
`all parties. Because each module 1 0 has its own unique
`
`RSA key set, there is no provision in this model for the
`
`5
`
`module 10 to represent money independently of the
`
`registry maintained by the Service Provider.
`
`Instead,
`
`the registry and the ability of the module 10 to sign
`
`with its private. key together serve as a definitive means
`
`of identifying the End User remotely to any other party.
`
`:l F ""'
`-· ,.,. ·.jo.
`:=
`,;.
`.,:j
`:;.)
`�t -·
`i,..
`�
`t:
`·.C
`!C
`
`1 0
`
`L.
`
`TAXATION OF TRANSACTION VOLUME
`
`This usage applies to a business model in which the
`
`Service Provider intends to collect a service charge from
`
`the End User that is a percentage of the total amount of
`
`money transferred by the module 1 0 .
`
`This model is
`
`15
`
`similar to those described in sections C D , E, and F
`
`above, but with the addition of a destructor object that
`
`can cause any particular transaction script 44 to expire
`
`at <} predetermined date and time.
`
`This model also
`
`requires the use of an additional money object which is
`
`2 0
`
`programmed
`
`(with a suitable transaction script 44) to
`
`IPOAL:7l997 .1/ 20661-4S7
`
`6 0
`
`(i
`\ -..
`.,
`
`Page 98 of 544
`
`
`
`Patent Application
`Docket #20661/457
`accumulate the total value of all the money passed out of
`
`the module 1 0 .
`
`Preparat ion
`1 .
`The Service Provider creates a transaction
`group 40 containing money objects, etc. as described
`
`in sections D and E above .
`The Service Provider
`also creates an additional money object to serve as
`
`the volume accumulator. The Service Provider also
`
`creates transaction scripts 44 for withdrawing or
`depositing money as in D and E, except that the
`transaction script for adding money to the module 10
`includes a destructor object set to expire at a
`predetermined
`i n
`the
`future,
`and
`the
`time
`transaction script 44 for withdrawing money incl udes
`
`5
`
`·�
`
`10
`
`15 .
`
`an instruction to add the amount of the withdrawal
`
`to
`the money object
`ac cumulator.
`
`The service provider then locks the
`
`serving
`
`as
`
`the volume
`
`group and ships the module 10 to the End User .
`
`I
`
`I PDAL: 71997 .I I 20661-4S7
`
`6 1
`
`\.._i.
`
`Page 99 of 544
`
`
`
`.�
`
`'
`-
`
`Patent Application
`Docket #20661/457
`
`2.
`
`Usage.
`
`The End user uses the module 10 for deposits
`
`and withdrawals as described in sections D and E
`
`above. During the time that the module 10 is used,
`
`5
`
`the cumulative total of all the money spent from the
`
`module 10 is accumulated in the money object serving
`
`as the volume accumulator.
`
`When the time limit
`
`expires, the End User can no longer add money to his
`
`module 10, although he can continue to withdraw
`
`10
`
`money if desired until there is none left. The End
`
`User then returns the module 10 to the Service
`
`Provider to be restored. The Service Provider reads
`
`the remaining amount of money and also the amount of
`
`money recorded in the volume accumulator.
`
`The
`
`15
`
`Service Provider bills the End User a service charge
`
`that is a percentage of the amount in the volume
`
`accumulator.
`
`If the End User is willing to pay this
`
`amount to continue his service, the transaction
`
`I
`
`group 40 is destroyed and rebuilt, then the amount
`
`20
`
`of money remaining in the module 10 when the End
`
`User returned it is programmed back into the money
`
`object of the transaction group 40.
`
`The Service
`
`I PDAL: 11991.1 /20E61-<57
`
`62
`
`Page 100 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`Provider then returns the restored module to the End
`
`User, provided that the End User pays the service
`
`charge.
`
`The system described above allows a Service Provider
`
`5
`
`to collect periodic fees for service without having to
`
`monitor and be involved in every financial transaction
`
`performed by the End user.
`
`The fee is based on actual
`
`usage, as determined by the contents of the volume
`
`register.
`
`10
`
`15
`
`Exemplary Firmware Definitions for Use With the Module
`
`Object
`
`The most primitive data structure
`
`accepted by and operated on by the
`
`modules firmware.
`
`A list of valid
`
`objects and their definitions is
`
`provided in the next section.
`
`I
`
`IP�: 71997.1/ 20661-4�7
`
`63
`
`.
`
`'
`\.
`
`Page 101 of 544
`
`
`
`Group
`
`A
`
`self-contained
`
`collection of
`
`Patent Application
`Docket #20661/457
`
`objects. An object's scope is
`
`restricted to the group of which it
`
`is a member.
`
`5
`
`Group ID
`
`A num ber preferably between 0 and
`
`255 representing a specific group.
`
`Object ID
`
`A number preferably between 0 and
`
`255 representing a specific object
`
`within a specific group.
`
`10
`
`Object Type
`
`Preferably a 1-byte type specifier
`
`that describes a specific object.
`
`PIN
`
`An
`
`alphanumeric
`
`Personal
`
`Identification
`
`number
`
`that
`
`is
`
`preferably eight bytes in length.
`
`I PDI\L: 71997. 1 I 20661·4S7
`
`64
`
`Page 102 of 544
`
`
`
`Co:mmon PIN
`
`The PIN that controls access to
`
`Patent Application
`Docket #20661/457
`
`shared resources such as the audit
`
`trail.
`
`It is also used to control
`
`the host's ability to create and
`
`delete groups.
`
`Group PIN
`
`The PIN that controls access to
`
`operations
`
`specific
`
`to
`
`objects
`
`within a group .
`
`Audit Trail
`
`A record of transactions occurring
`
`after the module has been locked.
`
`Locked Object
`
`An object which has been locked by
`
`executing the lock object command.
`
`Once an object is locked it is not
`
`directly readable .
`
`5
`
`10
`
`. r: ""'
`
`""•
`=
`
`;.
`-:=
`�
`�
`
`-.
`..,;
`:::J
`,:,..
`.=
`
`!;
`.,., ��
`
`15
`
`/Private Object
`
`An object which has been privatized
`
`by executing the privatize object
`
`command. Once an object is private,
`
`65
`
`f'
`
`I
`'->.-
`
`Page 103 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`it
`
`is not
`
`directly
`
`readable
`
`or
`
`writable.
`
`Locked Group
`
`A group which has been locked using
`
`the locked group command.
`
`After a
`
`5
`
`group has been locked it will not
`
`allow object creation.
`
`Composite Object
`
`A combination of several objects.
`
`The individual objects inherit the
`
`attributes of the composite object .
`
`...
`,..) .I
`:-!:
`
`/
`/
`
`IPMLt71997.1/ Z0661-C57
`
`66
`
`(
`
`I
`' I
`
`
`
`I
`
`Page 104 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`Exemplary Object Definitiooa
`
`RSA Modulus
`
`A large integer preferably of at
`
`5
`
`10
`
`.�
`
`.-.
`""
`
`( 1)
`
`(2)
`
`15
`
`/
`
`It is the
`most 1024 bits in length.
`product of 2 large prime numbers
`
`that are each about half the number
`
`of bits in length of the desired
`
`modulus size.
`
`The RSA modulus is
`
`used in the following equations for
`
`encrypting and decrypting a message
`
`M:
`
`Encryption:
`
`C • � (mod N)
`
`Decryption:
`
`M = Cd (mod N)
`
`where C is the cyphertext, d and e
`
`are the RSA exponents
`
`(see below),
`
`and N is the RSA modulus.
`
`IPOA�:7l997 .1/ 20661-4S7
`
`67
`
`(·
`.
`l..
`
`\
`
`Page 105 of 544
`
`
`
`RSA Exponent
`
`Both e and d
`
`(shown in equations 1
`
`Patent Application
`Docket #20661/457
`
`and 2 above) are RSA exponents.
`
`They are typically large numbers but
`
`are smaller than the modulus
`
`(N) •
`
`RSA exponents can be either private
`
`or public.
`
`When RSA exponents are
`
`created in the module, they may be
`
`declared as either. Once created an
`
`exponent may be changed
`
`from a
`
`public
`
`exponent
`
`to
`
`a
`
`private
`
`exponent.
`
`After an exponent has
`
`been made private, however, it will
`
`remain private until the transaction
`
`group 40 to which it belongs is
`
`destroyed.
`
`Transaction Script A transaction script is a series of
`
`/
`
`instructions to be carried out by
`
`the module. When invoked the module
`
`firmware interprets the instructions
`
`in the script and places the results
`
`in the output
`
`data object
`
`(see
`
`68
`
`5
`
`10
`
`15
`
`20
`
`Page 106 of 544
`
`
`
`Patent Application
`Docket #20661/457
`
`below) . The actual script is simply
`
`a list of objects.
`
`The order in
`
`which
`
`the
`
`objects
`
`are
`
`listed
`
`specifies
`
`the
`
`operations to
`
`be
`
`5
`
`performed
`
`on
`
`the
`
`objects.
`
`transaction scripts
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
