fig1 is an overall symbolic diagram of an arrangement according to the invention . the arrangement has three primary components : a user system 102 , a financial clearinghouse system 104 and a system referred to herein as an inquirer system 106 . the financial clearinghouse system 104 can be any certification server trusted by the inquirer 106 , such as a bank , a credit card company , or a third party certifying authority . the inquirer system 106 can be any entity that wishes to verify with the financial clearinghouse 104 the identity of a user . in the embodiment described herein , the inquirer 106 might be , for example , an on - line merchant server system . in conformity with this paradigm , the user 102 might be a person interested in purchasing goods or services from the merchant 106 . in addition to the above , the financial clearinghouse 104 maintains a signature database 108 , containing digital signatures of the various accounts held by users of the financial clearinghouse 104 . in general operation , a user opens up an account with the financial clearinghouse 104 , and provides a digital signature to the clearinghouse 104 for storage on the signature database 108 . as described in more detail hereinafter , the digital signature depends upon both the user and the user &# 39 ; s system 102 . at a subsequent time , when the user wishes to purchase merchandise from the merchant 106 , the user system 102 regenerates the signature in real time , including both the portions which depend upon the user and the portions which depend upon the user &# 39 ; s system . the newly generated signature is provided to the financial clearinghouse , which processes it in relation to the digital signature originally stored on the signature database 108 to determine whether the real timegenerated signature is valid . in fig1 the user system 102 , the certification server 104 and the inquirer system 106 are each illustrated as a respective individual block . depending on the embodiment , each block might contain no more than a single computer , or in different embodiments , different blocks can contain more than one computer . in one embodiment , one or more of the blocks 102 , 104 and 106 , for example the certification server 104 , contains a number of computers spread out over a great geographical area and interconnected by a network . the illustration of the user system 102 , the certification server 104 , and the inquirer system 106 as single blocks is not intended to indicate that each must constitute only a single computer system or that each must be located at a respective single location . nor is there any requirement that computers used to form the user system 102 , the certification server 104 , and the inquirer system 106 have any particular structure . fig2 is a symbolic block diagram illustrating the structure of a typical computer system which may be used as a user system , an inquirer system or a certification server it comprises a cpu 202 and cache memory 204 , both connected to a cpu bus 206 . interface circuitry 208 is also connected to the cpu bus 206 . the interface circuitry 208 is further connected to a main memory 210 , as well as to two i / o buses : pci - bus 212 and isa - bus 214 . connected to the pci - bus 212 are sound and game controllers 216 , a network adapter 232 and a display adapter 218 , the last of which is further connected to a monitor 220 . connected to the isa - bus 214 is a hard disk drive controller 222 , a cd - rom drive controller 224 , a floppy disk drive controller 226 , various i / o ports 228 , and a boot prom 230 . most of the peripheral components illustrated in fig2 include on - board configuration data which can be read by the cpu 202 . in addition , the boot prom 230 includes a portion which is writeable by the cpu 202 to store configuration data . in general , the software to operate the user system 102 , the certification server 104 or the inquirer system 106 is stored on the disk drive controlled by the disk drive controller 222 , and brought into main memory 210 as needed for execution . the computer system of fig2 communicates with the other systems of fig1 via the network adapter 232 . fig3 a and 3b in combination are a flow chart illustrating the overall system flow for the embodiment of fig1 . the flow chart of fig3 a continues in fig3 b , as indicated by the circled symbol &# 34 ; b &# 34 ; in both figures . referring to fig3 a , in a step 310 , prior to any purchasing transaction , the user presents his or her identification to the financial clearinghouse or other financial institution which stands behind the certification server 104 . depending on the level of confidence that the financial institution requires in the physical identity of the user , the required identification might be as strict as a biometric measurement , such as fingerprints or a retinal scan , or it may be somewhat less stringent , such as by requiring notarization , a photo i . d ., or other mechanism involving some physical presence . in a situation where the financial institution does not need to know the physical identity at all , for example where the financial institution is merely going to be maintaining a debit account and is taking no risk of its own , step 310 can be omitted . for a debit account , the financial institution is concerned only that the user identity be consistent in future transactions , not that the user identity actually be known ; it is not necessary to bind the user identity with a physical identity . in a step 312 , the financial institution establishes an account for the user . this may involve depositing some money into a debit account , or it may involve merely creating a record of the user in a database . in step 314 , the user , at the user system 102 , creates an original signature for a first user identity in a manner described in more detail hereinafter . the digital signature created in step 314 depends upon both the user system 102 as well as the user &# 39 ; s first identity ( the user can have more than one virtual identity , if desired ). in a step 316 , the user system 102 transmits the original digital signature to the certification server 104 which , in step 318 , stores the original digital signature in the signature database 108 in conjunction with the user account . some time later , in a step 320 , the user browses an on - line catalog , for example , maintained by the merchant system 106 , and selects items for purchase . in step 322 , the user system 102 transmits the user &# 39 ; s payment information to the merchant system 106 . such payment information might include credit card information , or a reference to a debit account previously established at the financial clearinghouse 104 . before authorizing the transaction , the merchant system 106 will first desire certification that the user is in fact the owner of the credit card or debit account . accordingly , in a step 324 , the merchant system 106 generates a challenge code and transmits it to the user system 102 . the challenge code serves as an inquiry to the user system 102 to provide information so that the merchant can verify the identity of the user . the challenge code preferably is generated randomly , but complete randomness is not actually required . the challenge code is also preferably generated just prior to transmission to the user system 102 , but in other embodiments , it may have been generated earlier . it will be seen from the further description below that the issuance of a challenge code helps to ensure that the real time digital signature that will next be generated by the user system 102 , truly was generated in real time , and is not merely a surreptitious copy of a digital signature previously stored on the user system 102 . different embodiments of the arrangement of fig1 might require different levels of confidence in the currency of the real timegenerated digital signature , and therefore might permit different freedoms in the randomness of the merchant &# 39 ; s challenge code or in the currency of generation of the merchant &# 39 ; s challenge code . in a step 326 , after the user system 102 receives the challenge code from the merchant system 106 , the user system requests a user identity code ( e . g ., a pin ) from the user . in step 328 , the user enters the pin for his or her first user identity . in step 330 ( fig3 b ), the user system 102 generates a real time digital signature , in dependence upon the challenge code , the pin entered with the first user identity , and certain data regarding certain listed components as presently existing in the user system 102 . the generation of the real time digital signature in step 330 is described in more detail below . in step 332 , the user system 102 transmits the real time digital signature to the merchant system , which in step 334 further transmits it on to the certification server 104 together with the challenge code and the user &# 39 ; s payment information previously supplied . in step 336 , the certification server 104 combines the challenge code with the original signature for the first user identity , as stored in the signature database 108 , and determines , in step 338 , whether the result matches the real time digital signature provided by the user system 102 via the merchant system 106 . if the two results match , then the certification result is positive ( step 340 ). if they differ , then the certification result is negative ( step 342 ). in step 344 , the certification server 104 transmits the certification result back to the merchant system 106 which , in step 346 , either allows or declines the purchases desired by the user . note that any or all of the communications called for in fig1 can be encrypted , digitally signed and / or certified if desired in a given embodiment , although to some extent these precautions might mitigate the advantages obtained by the invention over prior certification mechanisms . by avoiding these precautions , certain requirements of current u . s . export laws can be avoided as well . as mentioned above , the original digital signature generated by the user system 102 depends upon both the user system 102 itself , as well as a user identity . the user identity may be indicated by , for example , a code or pin entered by the user via the keyboard . alternatively , it might be more secure , for example , by a fingerprint or a retinal scan taken by the user system 102 of the user . the portion of the original digital signature which identifies the user system 102 itself , referred to herein as a user system signature ( uss ), can be generated in a number of different ways in different embodiments . one embodiment takes advantage of serial numbers or other identifying data which may be present in the user system , and which carry external assurances of substantial uniqueness . that is , many computers when manufactured are assigned a serial number or other indicator which the manufacturer of the computer , or some other authority , guarantees to be unique . for example , apple macintosh computers , when manufactured , are assigned an ethernet address which is unique to that specific computer . alternatively , the identifier can be assigned in software , such as in the operating system of the computer . it is not essential that whatever authority assigns the serial number guarantee uniqueness ; depending on the level of confidence required by the merchant or the financial clearinghouse , it may be sufficient only that it be extremely unlikely that two computer systems which can act as user systems 102 carry the same identifier . this is the case where , for example , the number carries external assurances of substantial uniqueness , such as in the case of ethernet addresses . in another embodiment , the user system signature does not rely on a component having an identifier that carries external assurances of substantial uniqueness . instead , a plurality of components ( hardware or software ) are examined to determine individual component signatures . the individual component signatures are then combined to form the overall user system signature , or all of the individual component data is digested together in a single pass . in one embodiment , the individual component signatures are all concatenated together in a predetermined sequence to form the overall user system signature . the individual component signatures may be digested prior to concatenation in order to limit their size to the predefined field size . in another embodiment , optionally after digesting , the individual component signatures are averaged or summed together to form the overall user system signature . the individual component signatures can be weighted prior to combination , in order to reduce the impact on the user system signature that would result from changes in components that are more frequently subject to upgrade or replacement . in one embodiment , the user system 102 generates the user system signature in dependence upon component signatures from the following components , to the extent present in the system . except as indicated below , most of the component signatures set forth in this list are readable either from the cmos or from a configuration manager driver . for pci or eisa systems , the data can be read from the pci or eisa board bios . the following is only an illustrative list ; other embodiments can refer to other components not on this list . in addition , different embodiments may or may not include components which are readily removable by the user . the kinds of identifying data that might be used to generate the individual component signatures can include the manufacturer name , revision number , versionnumber , date , release number , and so on . in yet another embodiment , a combination of individual component signatures also includes one or more component signatures that carry external assurances of substantial uniqueness , to the extent such a component exists in the machine . fig4 is a flow chart detail of step 314 in fig3 a , within which the user system creates the original digital signature for the first user identity . in a step 410 , the user enters his or her pin for the first user identity . as mentioned , other forms of identification might be used in different embodiments . in step 412 , the user system 102 determines whether it has a component which bears an i . d . that carries external assurances of substantial uniqueness . if so , then in step 414 , the uss is set equal to that component i . d . in step 416 , if the user system 102 does not have a component bearing an i . d . that carries external assurances of substantial uniqueness , or if the embodiment does not utilize such component i . d . s , the user system 102 obtains data regarding each of the listed components as they then exist in the user system 102 . in a step 418 , the user system 102 digests the different data items and , in step 420 , combines the digested data items to form the uss . any suitable digesting algorithm can be used for the purpose of the digesting step 418 including , for example , an error - correcting code ( ecc ) generator or the well - known sha - 1 algorithm . the sha - 1 digesting algorithm is described national institute of standards and technology ( nist ) fips publication 180 : secure hash standard ( shs ) ( may 1993 ), as amended by national institute of standards and technology ( nist ) announcement of weakness in the secure hash standard ( may 1994 ), both incorporated herein by reference . note that in a different embodiment , the data from the individual components can be combined ( e . g ., summed , averaged , concatenated together , etc .) without digesting , and only the combined version is digested . in step 422 , the user system 102 combines the uss either from step 420 or from step 414 , with the first user identity pin as entered in step 410 , and digests the results again . again , &# 34 ; combining &# 34 ; can include adding or concatenating the pin with the uss , or even xor - ing the pin with the uss . note that in a different embodiment , the pin can be combined with the individual data items earlier in the process of fig4 resulting in only a single digesting step . fig5 is a flow chart detail of step 330 ( fig3 b ) in which the user system generates the real time signature in dependence upon the challenge code , the pin for the first user identity , and data regarding listed components as presently existing in the user system 102 . the term &# 34 ; real time &# 34 ;, as used herein , does not require absolute currency . the term should be interpreted loosely enough to include digital signatures generated recently , but certainly more recently than the time that the original digital signature was generated . for example , instead of the uss / pin combination being calculated only in response to an inquiry from an inquiring system , an embodiment might request the user &# 39 ; s pin and generate the &# 34 ; real time &# 34 ; uss / pin combination on system boot . another embodiment might request the user &# 39 ; s pin and generate the &# 34 ; real time &# 34 ; uss / pin combination at the beginning of the user &# 39 ; s online session , for example when the user &# 39 ; s browser software begins executing . another embodiment might request the user &# 39 ; s pin and generate the &# 34 ; real time &# 34 ; uss / pin combination only in response to an inquiry , but might then cache it for some period of time thereafter . referring to fig5 in step 510 , the user system 102 determines whether it has a component bearing an i . d . that carries external assurances of substantial uniqueness . if so , then a real time uss is set equal to such component i . d . ( step 512 ) if not , or if the embodiment does not utilize components bearing an i . d . that carries external assurances of substantial uniqueness , then in step 514 , the user system 102 obtains , in real time , data regarding the listed components as presently existing in the user system 102 . in step 516 , as in step 418 in the flow chart of fig4 the data items are digested and , in step 518 , a real time uss is generated by combining the digested data items . the real time uss is then further digested in step 520 with the pin entered in step 328 ( fig3 a ) for the first user identity . as with the flow chart of fig4 the combining and digesting steps can be performed with various algorithms in different embodiments . however , the algorithms chosen should be such that the signature , as it exists prior to step 522 , should be the same as the original digital signature generated in the procedure of fig4 given identical pins and identical user system components . in step 522 , the result of step 520 is further combined with the challenge code and digested to produce the real time digital signature that will subsequently be provided to the merchant system 106 in step 332 ( fig3 b ). it can be seen that the real time digital signature must , in fact , be generated in real time ( as that term is used herein ) if it is to incorporate the challenge code provided by the merchant system 106 . the reliability of the real time signature in assuring that the user system 102 on which it is generated is in fact the same as the user system 102 on which the original digital signature was generated , can be compromised if the user system 102 stores the uss locally in a form that can be pilfered . this risk is minimized , as previously mentioned , by further requiring the user to enter his or her pin and digesting it together with the uss . the user can still compromise the reliability of the real time digital signature by storing his or her pin locally on the user system 102 , or by storing the original digital signature itself locally on the user system 102 , but this is not an advisable procedure . the risk to the merchant 106 or the financial clearinghouse 104 of such a procedure can be minimized , for example by contractually requiring the user to maintain better security procedures , or by contractually assigning liability to the user for any increased risk resulting from inadequate pin security . fig6 is a detail of step 336 ( fig3 b ), in which the certification server 104 combines the challenge code with the original signature for the first user identity , as stored in the signature database 108 . in step 610 , in response to receipt of the information from the merchant system 106 , the certification server retrieves the original signature for the first user identity from the signature database 108 . in step 612 , the certification server combines the original signature with the challenge code provided by the merchant system 106 and digests them together in the same manner as performed in step 522 ( fig5 ). as previously discussed , in step 338 ( fig3 b ), if the original digital signature as combined ( by the certification server 104 ) with the challenge code provided by the merchant system 106 , does not match the real time signature provided by the user system 102 , then the certification server has determined either that the user system 102 on which the real time signature was generated is not identical to the user system 102 on which the original digital signature was generated , or that the user identity code entered by the user for the current transaction does not match the user identity code entered by the user at the time of original account establishment . either conclusion increases the likelihood that the current user is an impostor . according to an aspect of the invention , however , some flexibility can be applied to the determination of whether the user system 102 is the same system on which the original digital signature was generated , allowing for a certain amount component upgrade drift fig7 is a detail of the decision step 338 in fig3 b , which accommodates such flexibility in one such embodiment , the algorithms used to generate the original and real time signatures involve combining undigested individual system component data prior to digesting . at the time of account establishment , in addition to providing the original signature to the certification server 104 , the user system 102 also digests individually the component data that was used to generate the original signature , and provides these individual component digests , together with the user &# 39 ; s pin , to the certification server 104 for storage on the signature database 108 in conjunction with the original digital signature . the individual component signatures actually can be digested prior to combining in the generation of the original signature , but in order to minimize the risk from unauthorized access to the signature database 108 , the digesting algorithm used to provide the individual component digests to be stored on the signature database 108 should be such that they cannot be used to recreate the original uss . referring to fig7 in step 710 , the certification server 104 determines whether the original signature and challenge code combination is exactly equal to the real time signature provided through the merchant server 106 . if so , then the certification result is positive ( step 712 ). if not , then in step 714 , the certification server determines whether the uss was based on a component having external assurances of substantial uniqueness . if so , then no drift is permitted in such a component and the certification result is negative ( step 716 ). in step 718 , if the original signature and challenge code combination is not exactly equal to the real time signature , and individual user system component signatures were used to generate a uss , then in step 718 , the certification server 104 requests the individual user system component signatures as they presently exist , from the user system 102 via the merchant 106 . in step 720 , the user system 102 provides such information via the merchant 106 in the same individually digested form with which they were originally provided and stored on the signature database 108 . in step 722 , the certification server 104 compares the individually digested real time user system component signatures , newly received , to the individually digested user system component signatures previously stored in the signature database . in step 724 , the certification server 104 determines whether the difference exceeds some predetermined threshold specified , for example , as a number of component signatures which are permitted to have changed if the differences do not exceed the designated threshold , then automatic reauthorization is performed ( step 1000 ). if the differences does exceed the predetermined thresholds then the certification result is negative ( step 728 ). fig8 is a detail of step 724 ( fig7 ) in which the certification server 104 determines whether the difference between the two sets of individual component signatures exceeds the predetermined threshold . the flow chart set forth in fig8 represents one embodiment in which the threshold is specified as a percentage . in a step 810 , the certification server 104 calculates the weighted sum of the real time user system component signatures . in step 812 , the certification server calculates the weighted sum of user system component signatures as previously stored in signature database 108 . in step 814 , the certification server 104 determines whether the difference between the two calculated values exceeds the predetermined percentage threshold . if not , then automatic reauthorization is permitted ( step 1000 ) if so , then the certification result is negative ( step 818 ). fig9 is a detail of step 724 ( fig7 ) as performed in a second embodiment , in which the maximum upgrade drift flexibility is specified as a maximum number of components whose individual component signatures are permitted to have changed . in a step 910 , the certification server counts the number of real time provided component signatures which differ from the corresponding component signatures as previously stored . in step 912 , the certification server determines whether the count exceeds the predetermined threshold . if not , then automatic reauthorization is permitted ( step 1000 ). if so , then the certification result is negative ( step 916 ). fig1 is a flow chart detail of step 1000 ( fig7 and 9 ). in step 1010 , the certification server 104 checks its log to determine whether the user &# 39 ; s user identity has received more than a predetermined number of automatic reauthorizations . if so , then the certification result is negative ( step 1012 ) and reauthorization must take place manually . if not , then in step 1014 , the certification server digests the newly received predigested component signatures with the user &# 39 ; s pin already on file in the signature database 108 . in response to a request by the certification server 104 , the user system also digests its newly digested component signatures with the user &# 39 ; s pin , and transmits the result back to the certification server 104 ( step 1016 ). in step 1018 , the certification server 104 determines whether the two values are equal . if not , then in step 1020 , the certification result is negative and automatic reauthorization is aborted . if the two numbers are equal , then automatic reauthorization was successful . in order to update the signature database 108 , the channel between the user system 102 and a certification server 104 optionally now begins using a secure socket layer ( ssl ) ( step 1022 ). in step 1024 , the user system 102 creates a new original digital signature , using the undigested individual component signatures and the user &# 39 ; s pin , and transmits the result to the certification server 104 . in step 1026 , the certification server 104 stores the new individually digested component signatures , as well as the new original signature received from step 1024 , in conjunction with the user account . in step 1028 , the certification server 104 increments the reauthorization count in its log , and in step 1030 , the communication channel between user system 102 and certification server 104 exits the ssl protocol . now that reauthorization has taken place , in step 1032 , the certification server notifies the merchant system 106 to retry the transaction . control then returns to step 324 ( fig3 a ) for the issuance of a new challenge code to the user system 102 . as used herein , steps which take place &# 34 ; in response to &# 34 ; a predecessor event , do so if the predecessor event influenced the performance of such steps . if there is an intervening time period , the performance of the steps can still be considered &# 34 ; respons &# 34 ; to the predecessor event . if the performance of the steps depends on more than one predecessor event , then the steps are considered performed in response to each of the predecessor events . the foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description . it is not intended to be exhaustive or to limit the invention to the precise forms disclosed . obviously , many modifications and variations will be apparent to practitioners skilled in this art . for example , whereas the flowcharts described herein illustrate steps being performed in a particular sequence , it will be appreciated that in many instances the sequence of the steps can be reversed , or the steps can be performed in a pipelined , overlapping manner , or both , without departing from the scope of the invention the embodiments herein were chosen and described in order to best explain the principles of the invention and its practical application , thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated it is intended that the scope of the invention be defined by the following claims and their equivalents