Method and system for using electronic communications for an electronic contact

【0001】

(1. Cross-reference to related applications) This patent application was filed on August 4, 2000 under 35 USC 119 and under the Paris International Convention. Wheeler et al. Claim priority to the interests of the filing date of the US provisional patent application serial number 60 / 223,076. This application is incorporated herein by reference. This application is further incorporated herein by reference to each of the three international patent applications and the three US patent applications. These were simultaneously filed with the US Patent and Trademark Office by Anne and Lynn Wheeler for serial number 09 / 923,179 (named "Accout-Based Digital Signature (ABDS) System"); serial number PCT / US01 / 41562 (named "Entity Authentication in"). Electronic Communication by Providing Verification Status of Device) and serial number 09 / 923,075 (named "Modifying Message Data and") Generating Random Number Digital Signature Within Computer Chip ") (collectively referred to as" VS Application "); serial number PCT / US01 / 24572 (name" Linking Public Key of Device to Information During Manufacture ") and serial number 09 / 923,213 (name) It has a "Manufacturing Unique Devices That Generate Digital Signature"); and a serial number PCT / US01 / 24563 (named "Trusted Authentication Digital Signature (TADS) System").

【0002】

(II. Field of Invention) The present invention relates to an improved communication system in which electronic communications relating to accounts are digitally signed.

【0003】

(III. Background of the Invention) As used herein, electronic communication (EC) is considered to be arbitrary communication in electronic form. EC has become an integral part of today's trading business, especially with the growth of the Internet and e-commerce. The EC may present legal activity, such as a request for access to information or physical territory, a financial transaction such as an instruction to a bank to transfer funds, or the delivery of an enforced contract.

【0004】

Digital signatures have become an even more important part of e-commerce in recent years. Creating a digital signature generally involves (1) calculating the message digest-eg, a hash value; (2) encrypting the message digest that follows. Message digests are generally encrypted by electronic devices that use the public-private key pair of private keys used in asymmetric cryptography. The resulting ciphertext itself usually constitutes a digital signature, which is usually added to the message to form an EC. The second part of initiating a digital signature (encryption with a private key) is referred to herein as "generating" a digital signature, and is a combination of two steps (ie, a message). The steps of calculating the digest and encrypting with the private key) are referred to as "originating" the digital signature. Further, while the generation of a digital signature is conveniently understood as the encryption of a message digest, the generation of a digital signature can further include simply encrypting a message rather than a message digest. Considered in the book. Digital signatures are important because any changes in the message in the EC can be detected by analyzing the message and the digital signature. In this regard, digital signatures are used to "authenticate" the messages contained in the EC (hereinafter referred to as "message authentication").

【0005】

For example, the message digest is a hashing algorithm. It can be calculated by applying an algorithm) (eg, the SHA-1 algorithm) to a message. Such a hashing algorithm can be applied either inside or outside the device, depending on the resulting hash value, and as a result, the hash value is propagated to the device to generate a digital signature. To authenticate the message in this example, the EC receiver receives the public key ("PrK") that corresponds to the identity of the hashing algorithm applied to the message and the private key ("PrK") used to encrypt the message digest. You need to know or be able to get both PuK "). Using this knowledge, the receiver applies an appropriate hashing algorithm to the message to calculate the hash value, and the receiver decrypts the digital signature using the public key. If the hash value calculated by the receiver equalizes the hash value of the decrypted digital signature, then the receiver must not change the content of the message contained in the EC in the transmission that changes the hash value as needed. To determine.

【0006】

When performing message authentication, the receiver further authenticates the EC sender, which corresponds to the same amount of public keys that the EC sender successfully uses to authenticate the message as the receiver. Make sure you own the private key. This is a type of entity authentication that is based on what the sender "has" (hereinafter referred to as "factor A entity authentication"). Factor A entity authentication is useful when the EC recipient has trusted information about the identity of the owner of the private key.

【0007】

This trusted information is conveniently provided on the basis of a digital certificate issued by a trusted third party. This digital certificate accompanies the digital signature and combines the identity (or other qualities) of the private key owner with the public key. A digital certificate (also known as a "digital ID") is evidence from a third party (commonly referred to as a "certificate authority") that proves the identity (or other qualities) of the owner of the public key. It is a document (voucher). In essence, digital certificates are electronic counterparts to driver's licenses, passports, membership cards, and other paper-based forms of identification. counterpart). The digital certificate itself comprises an electronic message containing the public key and the identity of the owner of the public key. Digital certificates also typically include an expiration date for the public key, the name of the certification authority, the serial number of the digital certificate, and the digital signature of the certification authority. One of the reasons for the expiration date is to limit the burden on the proof authority due to the likelihood that qualities other than identity may change over time. The most widely accepted format for digital certificates is specified by CCITT X.509 International Standards. Therefore, the certificate can be read or written by any application according to X.509. Based on the digital certificate contained in the EC, the recipient authenticates the digital certificate with the public key of the certification authority, which probably confirms the identity of the owner as described herein. Can be done.

【0008】

Systems in which a digital certificate is included in an EC have a "Public Key Infrastructure" (PKI), commonly referred to as a "Certificate Authority Digital Signature" (CADS) system. A specific implementation 100 of the CADS system in the context of electronic transactions between buyer 102 and online seller 110 is shown in Figure 1. Under this system, for example, the buyer 102 using the computer 104 creates a purchase order in the form of an electronic message. Buyer 102 includes in the message the relevant account information of financial institution 112 for which payment will be made to seller 110. Account information includes, for example, a credit card number and expiration date and name on the card. The software for the buyer's computer 104 creates a digital signature on the message using the buyer's 102's private key protected within the computer 104. The software also maintains a digital certificate issued by the certification authority 106a on the computer 104. The message, digital signature, and digital certificate are then combined with the EC, which is communicated to seller 110 over the Internet 108.

【0009】

Upon receipt, seller 110 authenticates the message with the public key in the digital certificate. If successful, seller 110 then authenticates the digital certificate with the public key of certification authority 106a. Successful authentication of the digital certificate can satisfy the seller 110 that the buyer, the sender of the EC, is the owner identified in the digital certificate. If the seller 110 is so satisfied, the seller 110 presents the account information to the relevant financial institution 112 to allow payment from the account to the seller 110. Upon receipt of a payment permit from the financial institution 112, the seller 110 fills the purchase order of the buyer 102. In addition, confirmation of authorization (or rejection) of the purchase order is preferably sent from seller 110 to buyer 102.

【0010】

Unfortunately, while the CADS system can communicate with each other with the confidence that two parties who cannot otherwise have a pre-existing relationship with each other know the identity of the other, the CADS system suffers from drawbacks. Have. For example, digital certificates are usually issued with an expiration date, and expired digital certificates are generally unrecognized in the industry. In addition, if the private key is lost or stolen, the owner of the private key must notify the certification authority to revoke the owner's digital certificate. However, the EC recipient with the digital certificate knows the digital certificate revocation if the recipient cross-references the digital certificate serial number to a certificate revocation list (CRL) published by the certification authority. Only. Another drawback to CADS systems is that the digital certificate itself is good only for the particular authority that issues it, and often obtains multiple digital certificates from (ie, certification authorities 106a, 106b-106n). It is necessary to form a sufficient "chain" or "network" of trust between the buyer 104 and the seller 110 for accepted or acted out transactions or communications. In addition, the entire CADS system relies on the security of the private key of the certification authority that issues digital certificates, and if leaked, the CADS system would collapse.

【0011】

In the EC context for accounts, such as the online purchasing example described above, another drawback of the CADS system is whether the account information is encrypted when sent over an uncertain communication medium such as the Internet 108. It needs to be protected in another way. Contact to the above example you are, the hackers to eavesdrop on the communication of account information, in particular, because all of the seller is not to request a digital signature and digital certificate in order to satisfy the purchase order, the illegal fee to the buyer's account You can get enough information to form. In addition, financial institutions have not standardized the requirements that the buyer's digital certificate presents as a condition prior to allowing the seller to request payment. Instead, if the buyer decides whether or not they have an authority that actually affects the payment to the seller, the financial institution will provide it by the seller regardless of whether the account information has been reported lost or stolen. Rely on your personal account information. In addition, digital certificates pose important privacy issues.

【0012】

Therefore, there is a need for improved systems of communication using digital signatures, especially if the EC belongs to an account that has the authority for the individual (or device) to digitally sign to operate.

【0013】

(IV. Brief Abstract of the Invention) In short, the method of electronic communication via a communication medium relating to an account belongs to each of the two separate accounts maintained by a separate third party. The steps to keep the information in the account database so that the information can be retrieved based on the unique identifier, and the step to associate the public key of the public-private key pair with the unique identifier, and the public-private key A step of generating a digital signature for an electronic message using a pair of private keys, the electronic message being electronic using the public key associated with the step, including the instruction, and the information identified by the unique identifier. It includes the steps of authenticating the message and executing the instructions for the account represented by the information identified by the unique identifier upon successful authentication of the electronic message.

【0014】

The present invention further includes a method of maintaining a Central Key Authority (CKA) database. The CKA database contains user account information such as the public key of the user device that generates the digital signature, and the user's account information, each of which is maintained by a third party to a third party and associated with the user's public key by the third party. Includes a third-party account identifier that identifies the account.

【0015】

The present invention further includes a method of managing a database for identifying the security features of a device that generates a digital signature, for each of a plurality of devices with a pair of public private keys of the device and the public key of the device. A step of recording information including a security function in a database, which identifies the step associated with the public key in the database and the security function from the database to the recipient of the electronic message. The electronic message is a step in which a digital signature is initiated using the private key of a particular public-private key pair of devices, and the security feature is for a particular device. Includes steps and.

【0016】

(V. Brief Description of Drawings) Further functionality and advantages of these aspects of the invention will become apparent from the detailed description of the preferred method taken with the following drawings. Here, the same reference indicates the same element.

【0017】

(VI. Detailed Description of Preferred Embodiments) As a preliminary matter, the present invention can be widely used and used in view of the following detailed description of the devices, systems, and methods of the present invention. Immediately understood by those skilled in the art. Many embodiments and applications of the invention other than those described herein, and many modifications, modifications, and equivalent configurations, without departing from the essence or scope of the invention, the invention and: It is clear from the detailed description or by the present invention and the following detailed description that it is reasonably presented. Accordingly, the invention is described in detail herein in connection with a preferred embodiment, but this detailed description is merely exemplary and exemplary of the invention and is merely sufficient of the invention. And it should be understood that it is done for the purpose of providing feasible disclosure. The detailed description described herein is not intended to limit the invention or otherwise exclude any other embodiment, adaptation, modification, modification and equivalent configuration of the invention. Also, without interpretation, the invention is limited only by the claims and equivalents attached herein.

【0018】

Those skilled in the art will appreciate that the sequence (s) and / or chronological order of the steps of the various processes described and claimed herein is the best mode intended by the inventor to carry out the invention. Understand and evaluate that it was conceived by the inventor who should be. Further, although the steps of the various processes are shown and described in some cases in a suitable sequence or order over time, the steps of such a process may be one step or more. Steps are not restricted to be performed in any particular sequence or order without specific instructions that they should be performed in a particular sequence or order to achieve a particular intended result. Should be understood. In most cases, the steps of such a process are within the scope of the invention and can be carried out in a variety of different sequences and sequences.

【0019】

Therefore, much of the invention is described in detail herein with respect to computers, networks, integrated circuits, computer chips, and devices, but no particular software or logic circuit is intended and the practice of the invention. It is not required to be used in. In fact, choosing the right computers, networks, integrated circuits, computer chips, and devices to implement the invention in a particular business application is a matter of day-to-day business.

【0020】

The present invention broadly includes the binding of public keys of devices that generate digital signatures using asymmetric cryptography to other information in account database records. Generally, the method according to the first aspect of the present invention is a step of electronically communicating a message via a communication medium relating to an account associated with a public key, the corresponding private key being used to digitally sign the message. , Including steps. The method according to the second aspect of the present invention includes the step of combining a plurality of accounts into the same public key. The method according to the third aspect of the present invention involves maintaining a central database of information on all accounts tied to the same public key. Finally, the method according to the fourth aspect of the invention applies dynamic risk analysis to a particular message to measure the risk of fraudulently creating a digital signature on the message, thereby including it in the message. Includes the step of deciding whether to implement the order.

【0021】

As used herein, an "account holder" is generally any individual who owns a device that can generate a digital signature with a retained private key. The private key corresponds to the public key associated with the account that the individual is authenticated to act on. An "account authority" is generally an individual, entity, system, or device that maintains such an account on behalf of an account holder. In some embodiments, an "account holder" is itself a device that can generate a digital signature using a held private key. The private key corresponds to the public key associated with the account on which the device is authenticated.

【0022】

Briefly describing the methodology of the various aspects of the invention, general and specific implementations of two-, three-, and many-person account-based digital signature (ABDS) systems are described in more detail.

【0023】

(1. Account-Based Digital Signature (ABDS) System) (a. General Two-Party ABDS System) FIG. 2 shows a suitable account-based digital signature (ABDS) system 200 according to the first aspect of the present invention. In particular, FIG. 2 shows a two-party ABDS system that includes account holder 202 and account authority 212. As shown, the account holder 202 comprises the individual who owns the device 250 and secures the unique private key of the public-private key pair. The account authority 212 comprises an entity or system that maintains one or more account databases, collectively illustrated as the account database 214. This account database 214 contains the accounts of account holder 202. Preferably, the account is identified in the account database 214 based on a unique identifier (actID) (eg, account number) 216. In addition, the account authority 212 maintains a bond between the account and the public key 218. This public key 218 corresponds to a private key securely held in device 250 of account holder 202.

【0024】

Communication between the account holder 202 and the account authority 212 for the account of the account holder 202 occurs through any conventional communication medium 208, such as the Internet, an intranet, a wireless network, a dedicated wired network, or the like. Each communication is electronic, and each electronic communication (EC) 206 from account holder 202 to account authority 212 is digitally signed by account holder 202 using a private key held within device 250. Includes electronic message (M). The means by which the device 250 communicates with the account authority 212 is assisted in the morphological factors of the device 250 and in the generation or formation of the message, in the transmission and communication of the EC to the account authority 212, or both. It depends on whether it is used with a separate I / O support element (not shown).

【0025】

The message preferably includes an account unique identifier (acctID) 216 of the account holder 202 and an instruction (i1) for the account authority 212 to perform in connection with the account. The digital signature of the message further preferably includes a unique random number or session key (eg, date and time stamp), so that the two digital signatures created by the device 250 will never be the same (eg, date and time stamp). And, further, as a result, any duplicate digital signature received by the Account Authority 212 can be individually identified and irrelevant.

【0026】

Using the unique identifier (acctID) 216, the account authority 212 can retrieve the combined public key 218. The public key 218 is based on the EC216 message and sender required to authenticate (ie, factor A entity authentication). According to this first aspect of the invention, upon successful authentication of the sender of the message and EC206, the account authority 212 is as if the account holder 202 personally presented such an order (i1). , Authenticate (or attempt to) message instruction (i1).

【0027】

Advantageously, the unique identifier (acctID) 216 is for the account authority 212 to search the account database 214 for the appropriate public key 218 for the purpose of authenticating the EC206 message and sender, and the instruction contained in the message ( Everything that must be included in the message in order to have sufficient authorization from the account holder 202 to carry out i1). Therefore, account holder 202 does not need to include any "identity" information in the message. In addition, the Account Authority 212 is preferably on the account of Account Holder 202 without a valid digital signature created by Device 250 (or, as an alternative, without the actual, physical presence of Account Holder 202). Such electronic communications, including EC206, are cryptographic because they do not carry out any activity and the "identity" information does not need to be included in the electronic communications between the account holder 202 and the account authority 212 for the account. It can be communicated in an unaltered format via an uncertain communication medium 208 (such as the Internet) without the risk of leaking the privacy of the account holder 202. Obviously, if the account holder 202 wants to protect the content of the information contained within the EC206 for privacy, confidentiality, or similar reasons, the EC206 will use the traditional method by the account holder 202, eg, PGP type. It can be encrypted using the account authority 212's public key for encryption, using secure socket layering (SSL), or using other similar encryption techniques. However, encrypting EC content does not necessarily require the functionalization of the present invention.

【0028】

FIG. 2a shows multiple possible relationships between the information contained within the account database 214. Generally, each account in database 214 is identified by, for example, its account identifier (acctID) 216, which is account holder-specific information (hereinafter "customer-specific information") and account-specific information (hereinafter "account"). It is associated with "specific information") and account information 240 such as public key information 218. At a minimum, public key information 218 identifies each particular account and / or each public key (PuK) associated with account identifier 216. As shown, database 214 has multiple specific accounts 281, 282, 283, 284, 285, 288, and multiple accounts between accounts 285 and 288 (not shown, .... Maintained with (indicated by). Accounts 281, 288, each account has a single customer or account holder, and each account has a single public key (PuK) tied for use. Indicates the first account setup type that has account 282, where account 282 has a single customer or an account holder associated with it, but account holders are associated with multiple accounts for use with account 282 ( In this case, it indicates a second account setup type that has two) different public keys (PuK). Such a setup, for example, allows the account holder to access the same account 282. Useful if you use more than one device. A third account setup type is shown in relation to accounts 283, 284. Each of these accounts 283, 284 has the same account holder. The same account holder uses a single public key to access either or both of these accounts 283, 284. Such a setup, for example, allows the account holder to have multiple accounts (in this case, two). This is useful when maintaining a single account authority (eg, primary and secondary bank accounts with the same financial institution). This particular setup is described herein with respect to Figures 64-70. Discussed in more detail in the "People-Centered Devices" section. The fourth account setup type is shown in relation to account 285. Account 285 is combined with a number of different customers or account holders (three in this case), each with a different public key (PuK) to access account 285. Such a setup is, for example, a multiple account with access to the account of two or more authorized users (eg, a couple with access to a joint account, an employer's account). It is beneficial if you have a number of employees). Specific business implementations using this type of account setup are shown and discussed in relation to Figures 46-49.

【0029】

Although not shown in FIG. 2a, it is clear that the above four account setup types can be further combined with each other in various permutations and still settle within the scope and intent of the present invention. As an example of such a combination not shown in Figure 2a, one of the customers accessing account 285 may actually have more than one public key to access joint account 285.

【0030】

Now, turning to FIG. 2b, in a further function of the present invention, the account database 214 may further include device profile information 270. Each device profile contains a device security profile and transaction history. The security profile includes device security features and manufacturing history. Security features include these features of the device that protect the private key and other data in the device from the ability to perform disclosure (security characteristics) and entity authentication (authentication capabilities). The information contained in the security profile is described in detail herein by the name Section VI.4, "Applying Dynamic Risk Analysis to Transactions." Since it is intended that only the unique public key associated with the corresponding public key 218 maintained with the account database 214 exists in a single device of the invention, each public key 218 and its respective device profile information. There is a one-to-one correspondence with 270. In addition, additional security is gained using a device whose private key cannot be leaked.

【0031】

(b. General Three-Party ABDS System) Figure 3 shows a suitable three-party ABDS system 300, including account holder 302 and account authority 312 as well as intermediary 310. The three-party ABDS system 300 differs from the two-party ABDS system 200 (from Figure 2) in that messages and digital signatures from account holder 302 to account authority 312 are first communicated to intermediary 310 by means of EC305. .. The intermediary 310 then forwards the same message and digital signature in another EC315 to the account authority 312.

【0032】

The instruction (i2) is communicated from the account holder 302 to the intermediary 310 as either part of EC305 or a separate EC (not shown). The intermediary 310 does not act on the order, but rather transfers the EC315 to the account authority 312 and waits for the account authority 312 to allow or reject the message. As shown, the message and digital signature in EC315 is the same as the message and digital signature in EC305.

【0033】

Upon receipt of EC315, Account Authority 312 attempts to authenticate the sender of the message and EC305 with the public key of the public-private key pair. This public key is retrieved from the account database 314 based on the unique identifier (acctID) 316 from the message. If the authentication is successful, the account authority 312 executes (or attempts to) the instruction (i1) in the message as if the account holder 302 was presenting the instruction (i1). Based on the results of the attempted authentication of the message and the sender of the EC, and based on the attempted execution of the instruction (i1), the account authority 312 responds to the intermediary 310 with a notice of acceptance or rejection of the message. Provided by means of EC319. If the answer EC319 indicates permission for the message, the intermediary 310 executes the instruction (i2) received from the account holder 302. Preferably, the intermediary 310 notifies the account holder 302 of either permission and execution of instruction (i2) or rejection of instruction (i2) by response EC309.

【0034】

Again, it should be noted that the "identity" information does not have to be included in EC305 by account holder 302 under this system 300. In addition, EC305, 315, 309, 319 all have the same reasons discussed above for System 200 in Figure 2, in an unencrypted format, Internet, intranet, wireless network, dedicated wiring network, etc. Etc. can be transmitted via any conventional communication medium 308a, 308b. In addition, if, as mentioned above, a person wishes to protect the content of the information contained within various EC 305, 309, 315, 319 for privacy, confidentiality, or similar reasons, such EC Secure socket layering (SSL) by a particular EC sender, using traditional methods, such as the intended receiver (s) public key of a particular EC for PGP-type encryption. ), Or can be encrypted with other similar encryption techniques. However, encrypting the contents of various ECs is not always necessary for the functionalization of the present invention. Further, the communication media 308a, 308b can differ from each other (as shown) or in parts of the same medium.

【0035】

(c. Multi-Person ABDS System) Not specifically shown in Figures 2 and 3, but within the scope of the invention, one or more additional persons or entities are along the communication route between account holders, intermediaries, and account authorities. It should be understood that it can be introduced. In particular, such additional persons can be useful for facilitating, screening, and correctly routing electronic communications between various account holders, intermediaries, and account authorities.

【0036】

(d. General account setup in ABDS system) Of course, before either ABDS system 200 or 300 is actually used, account holders 202, 302 first set the ABDS system to the appropriate account authority 212, Must be installed with 213. The steps involved in setting up a new ABDS account are illustrated in Figures 4a and 4b. The steps involved in converting a pre-existing (and traditional) account are illustrated in Figures 5a and 5b.

【0037】

((i) Setting up a new ABDS account) First, referring to Figure 4a, shows one exemplary process of setting up a new account in the ABDS system. In this particular embodiment, the process is initiated by the account authority. For example, the account authority first sets up a "shell" account for future account holders, using publicly available information about future account holders, such as name and address (step 402). ). The account authority then assigns a unique account identifier to the "shell" account and associates it (step 404). The account authority then obtains the public key from the device of the invention (step 406), records the public key in the account database, and associates it with a "shell" account or unique identifier (step 408). In some embodiments of the invention, the unique identifier can actually be the public key from the device or the hashed version of the public key. The account authority was then tied to a "shell" account by the account authority on behalf of future account holders, by offer to "open" the account, and by instructions to do so. Distribute or send the device holding the private key corresponding to the public key to future account holders (step 410). The account authority then waits for a response from future account holders.

【0038】

When a response is received (step 412), the account authority uses traditional authentication techniques to verify that it is a communication with a future account holder. The account authority then retrieves further information to place the account records as required (step 414). The account authority then requires future account holders to use the device to transmit digitally signed test messages (step 416). Such test messages confirm that future account holders own the correct device. Upon confirmation of the test message, the device is "activated" for use with the combined account (step 418).

【0039】

In an alternative embodiment, the setup of a new ABDS account can be initiated by a future account holder who already owns the device of the invention, as shown in Figure 4b. For example, the account authority may receive a request from such a future account holder to set up a new ABDS account (step 450). If the account authority is willing to accept such future account holders who already own such devices, the account authority will receive sufficient information from the future account holders to set up such an account (step). 452). In some business applications, it is not necessary for future account holders to leak any "identity" information in order to establish such an account. The account authority then records any information provided by future account holders in the account database records of the account authority (step 454) and assigns a unique identifier, such as the account number, to the account (step 456).

【0040】

Then, and preferably at the same time, the account authority obtains the public key corresponding to the private key securely held on the device (step 458). In some business applications, the public key is obtained directly from the device in response to the appropriate request presented to the device. In other business applications, public keys come from databases maintained by third parties such as central key authorities (as discussed below with reference to Figures 71a-72), device manufacturers, device distributors, and others. To be acquired. The account authority then records the public key in such a way that the public key is properly combined or associated with the account records of future account holders (step 460). Preferably, the public key is specifically associated with a unique identifier for the account. In some embodiments, the public key itself (or the hash value of the public key) is used as a unique identifier assigned to the account.

【0041】

Finally, it is also desirable for the account authority to verify the proper binding of the public key to the account and to ensure that the device holds the private key. This private key corresponds to the public key associated with the account by having the account holder present a "test" EC for authentication (step 462). This authentication may include the corresponding registered public key. Once the account authority is satisfied that the account is properly installed and that the account holder has a device that holds the appropriate private key corresponding to the registered public key, the account is activated (step 464). ), As a result, transactions that are digitally signed using the device are believed to have come from legitimate account holders with Factor A entity authentication.

【0042】

In the above embodiments, the account authority of the device is as confirmed by the security profile of the device obtained from the central key authority or other trusted source, or by physical observation of the device. It may be desirable to ensure that the level of integrity matches or exceeds the business standard or requirements for use with each account.

【0043】

((ii) Converting a Pre-Existing Account to an ABDS Account) Now, with reference to Figure 5a, an example of the steps to convert a pre-existing, traditional account to an ABDS account when initiated by an account authority. The process is explained. First, it is assumed that the account authority already keeps the traditional account setup for account holders in the account database record. In addition, such records include other relevant information for individuals and account holders. It is further assumed that the existing account already has its own unique identifier.

【0044】

First, the account authority obtains the public key from the device of the invention (step 502), records the public key in the account database, and associates it with an existing account or a unique identifier for the account (step 504). The account authority then distributes or sends the device holding the private key corresponding to the public key combined with the existing account to its account holder, with the offer to "convert" the existing traditional account to the "ABDS system". (Step 506). The account authority then waits for a response from its account holder.

【0045】

If a response is received (step 508), the account authority uses traditional authentication techniques to ensure that it is a communication with the expected account holder. The account authority then requires the account holder to carry a digitally signed test message using the device (step 510). Such a test message confirms that the account holder owns the correct device. If you see the test message, the device is "activated" for use with the newly converted ABDS account (step 512).

【0046】

In an alternative embodiment, the conversion from a traditional account to an ABDS account can be initiated by an existing account holder who already owns the device of the invention. For example, the account authority receives a request to convert a traditional account to an ABDS account (step 550). This ABDS account allows account holders to trade on their accounts using digitally signed electronic messages using the account holder's identified device. If the account authority is willing to accept such conversions and allows account holders to use such devices, the account authority first expects using traditional entity authentication techniques. Make sure you are communicating with or otherwise processing the account holder (step 552). Then, and preferably at the same time, the account authority obtains a public key that corresponds to the private key that is kept secure on the device (step 554). In some business applications, the public key is obtained directly from the device in response to the appropriate request presented to the device. In other business applications, public keys are obtained from databases maintained by third parties such as the central key authority (as discussed below with reference to Figures 71a-72), device manufacturers, device distributors and others. Will be done. The account authority then records the public key in such a way that the public key is properly or combined with the existing account record of that account holder (step 556). Preferably, the public key is specifically combined with the unique identifier of the account. In some embodiments, the public key itself (or the hash value of the public key) is used as a unique identifier assigned to the account.

【0047】

Finally, by having the account holder present a "test" EC for authentication (which may include the corresponding registered public key) (step 558), the account authority is appropriate for the public key account. It is also preferable to verify the binding and to ensure that the device holds the private key (which corresponds to the public key bound to the account). .. Once the account authority is satisfied that the account has been properly set up and that the account holder has a device that holds the appropriate private key corresponding to the registered public key, the account is activated (step 560). ), As a result, digitally signed transactions using the device are considered to come from legitimate account holders with Factor A entity authentication.

【0048】

(E. Devices useful for ABDS systems) In accordance with all aspects of the invention, devices are equipped with hardware, software, and / or firmware, in particular computer readable with computer chips, integrated circuits, suitable software. The medium or a combination thereof is provided. The device may further include physical objects such as hardware tokens or embedded tokens, computer chips, integrated circuits, or software, or tokens containing combinations thereof. If the device is a hardware token, it is preferably a ring or other jewelry, dongle, electronic key, IC card, smart card, debit card, credit card, ID badge, safety badge, parking card, or transit. It takes the form of a card such as a card or the like. If the device is an embedded token, it preferably takes the form of a mobile phone, telephone, television, personal digital assistant (PDA), watch, computer, computer hardware or otherwise. The device is preferably some for communicating with a port (including a wireless communication port, a serial port, a USB port, a parallel port, or an infrared port) or an external electronic device (either contacted or non-contacted). Includes device interfaces with other physical interfaces. The device may further include a trusted platform module (TPM). This Platform Module (TPM) is a Trusted Platform Module (TPM) Security Policy Version 0.45, TRUSTED COMPUTING PLATFORM AlLIANCE, October 2000 and TCPA PC Implementation Specification Version 0.95, TRUSTED COMPUTING PLATFORM ALLIANCE, July 4, It has hardware and software components that provide increased trust to the platform as described and described in 2001. Both of these are incorporated herein by reference (collectively, the "TCPA document").

【0049】

Preferably, the device can receive the electronic message and then create a digital signature for the electronic message that utilizes the stored private key. The device preferably further performs a hashing function on the message received by the device prior to encryption using the private key.

【0050】

Further, it is preferable that the device includes a device interface such as an alphanumeric keypad, an electronic contact, a touch screen display, a standard electronic interface with a computer bus, or an antenna, so that the device receives the message. Not only can you get, you can compose a message. The device interface may further include ports such as wireless communication ports, serial ports, USB ports, parallel ports, or infrared ports.

【0051】

Some of the above devices require the use of I / O support elements to allow the device to retrieve messages or other inputs. Some devices require the use of I / O support elements to convey information, including digital signatures and messages to EC recipients. Some of the devices are independent, which means they can generate and transmit messages, digital signatures, and other information without the use of external devices. Some devices are independent, but can interact with external devices such as I / O support elements if desired. The I / O support element can take any number of different device forms, depending on the particular application used and the factors of the interacting form. One example of an I / O support element is a hardware and software component designed according to the technical specification published by CEN / ISSS as a result of the Financial Transactional IC Card Reader Project (known as "FINREAD"). Includes a card reader.

【0052】

Used in each aspect of the invention, preferably during device manufacturing, with respect to device security, unique and random public-private key pairs are preferably used within the device, using known manufacturing techniques. Is generated directly (using a randomizer) on a computer chip, integrated circuit, or other embedded cryptographic module. Due to the size of the private key and because the key is generated using a random number generator, it is very unlikely that a duplicate private key could be in a different device. The private key is then securely stored in a memory location within the device, and is preferably inaccessible for the life of the device (other than for the purpose of generating a digital signature internally within the device). Be done. In addition, the device preferably includes the following additional features: It is tempered (ie, designed to minimize electromagnetic radiation from the device, thus minimizing vulnerabilities to electronic eavesdropping); the device is known. Does not respond to electronic attacks. The device is prevented from being forged with its ability to zero (ie, physical forgery or intrusion of the device destroys the functionality of the device's digital signature component and / or erases the private key). .. The device keeps the private key secure so that it is never leaked outside the device. And the device allows you to export your public key when you need it.

【0053】

In addition, the device is preferably an elliptic curve as described in Federal Information Processing Standard Publication 186-2, Digital Signature Standard, US DOC / NBS, Algorithm 11,1994 (FIPS PUB 186-2). Create a digital signature according to the Elliptic Curve Digital Signature Algorithm (ECDSA). This document is incorporated herein by reference. Therefore, the device creates a digital signature using a random number generator, and the hashing function is performed using a security hash algorithm (SHA-1). This security hash algorithm produces a 20-byte output regardless of the size of the message input to the device. SHA-1 itself is Federal Information Processing Standards Publication 180-1, Secure Hash Standard, US DOC / NBS, April 17, 1995 (hereinafter "FIPS PUB" 180-1 ") is described in the specification. This document is incorporated herein by reference.

【0054】

In aspects of the invention, the device is preferably personally owned by its authorized user (s). Personal ownership of a device involves the installation of a personal identification number (PIN), password, or passphrase (hereinafter "secret"). Conveniently, such a secret must be pre-stored in the device and entered into the device before it can operate to generate a digital signature. Alternatively, however, this is also convenient, the secret is shared with the receiver in advance, and when the EC letter is sent to the receiver, the secret is also sent to the receiver in connection with the message. In the first case, secret verification authenticates the user of the device (hereinafter "user authentication"), and in the second case, secret verification authenticates the sender of the EC (hereinafter "user authentication"). Sender authentication "). When a secret is shared and transmitted between the sender and receiver of an EC, it is usually encrypted or otherwise encrypted to maintain confidentiality from others. Need to be protected. In either case, secret verification represents entity authentication based on what the user or sender "knows" (hereinafter "factor B entity authentication").

【0055】

Other security measures against unauthorized use of the device through physical theft include matching biometric features of the device user or EC sender (eg, fingerprints, retinal scans, DNA, voiceprints, etc.). This type of authentication is based on what the user or sender is "is" (hereafter "Factor C Entity Authentication"). Like the secret, the biometric value is conveniently kept in the device for user authentication or pre-shared with the receiver for sender authentication by the receiver. Is. When biometric values are shared and transmitted between the sender and receiver of the EC, such biometric values are even greater to protect them from interference and discovery by others. Precautionary measures need to be taken.

【0056】

In contrast to both of the above methods of providing Factor B and Factor C entity credentials to the EC receiver, secrets and / or biometrics (s) are provided to the device, such secrets and / or An indicator that represents the result of a comparison of biometrics (s) with data pre-stored on the device communicates or leaks secrets and / or biometrics (s) to the EC receiver. An alternative method of providing an entity authentication state from the account holder to the account authority, provided without the need for, can further be used by the present invention. Such a methodology is described in detail in the VS application.

【0057】

(f. Types and Use of EC in ABDS Systems) As previously mentioned in connection with both Figures 2 and 3, the EC from the account holder to the account authority is the message (M) and the digital signature of the message ( Includes both DS (M)). The message preferably includes a unique account identifier (acctID) and an instruction (i1) for the account authority to perform in connection with the account. However, in many environments it is not necessary for the message to contain a unique account identifier. For example, as long as the account authority can already get a unique account identifier from a previous message from the account holder, and the account identifier is retransmitted, the account authority knows that it is communicating with the same account holder (eg,). Unnecessary for subsequent messages from the same account holder, by session key or identifier, or by a continuous, period of constant electronic connection between the two. Furthermore, it is not always necessary for the message to include an instruction (i1), for example if the instruction (i1) is implied in mere communication between the account holder and the account authority (eg, parking gate). The command (i1) in the EC sent to the controller clearly means the command to "open the parking gate").

【0058】

The EC, and the ability to authenticate the sender of the EC, is useful for at least three different business purposes within the present invention. These three different purposes are commonly referred to herein as "session authentication," "transaction authentication," and "transaction confirmation." Session authentication and transaction authentication are similar to each other. That is because both usually include situations where the account holder must "prove" to the account authority that it is a legitimate account holder (at least to the extent possible based on the strength of entity authentication). In contrast, transaction confirmation usually includes situations where the account holder has already proved to the account authority that it is a legitimate account holder. However, the account authority is specially digitally signed by the account holder before performing the activity for which the account authority was requested (usually on the account itself) in response to the special instruction (i1) contained in the message. Request confirmation of the message.

【0059】

Session authentication and transaction authentication are generally required before the account authority grants the account holder access to the account holder's account or other resources to which the account holder has rights. Such authentication is also generally required before the account authority can perform the requested activity on the account or resource. Resources include, for example, physical space, databases, computer files, data records, checking accounts, computer systems, computer programs, websites and more. The main distinction between session authentication and transaction authentication is what the account authority has done as a result of such authentication. For example, once the account holder is authenticated for session authentication, the account authority provides the account holder with access to the requested account or resource (by session key, entity identifier, etc.) during the "session". To do. The meaning of the session depends on the type of account or resource accessed. And it depends on the business rules of the particular account authority that protects the account or resource. However, a session typically means some period of time during which an account holder is allowed to perform activities on or within an account or resource without providing further authentication to the account authority. In addition, the amount of access to an account or resource authorized by an account holder is also governed by the business rules of a particular account authority, and can vary from account authority to account authority and account to account.

【0060】

In contrast, a trading authority is usually only useful for the particular transaction with which it is associated. A transaction certificate tied to a particular transaction is not "carried over" for use with another transaction. Such a transaction can be a request for an account authority to perform a particular activity on an account or resource (eg, a request for an account authority to "provide a check of account differences", "open a door". ). However, in contrast to transaction confirmation (described in the next paragraph), transaction authentication does not specifically require the account authority to know the "intention" of the account holder before performing the requested activity. It is useful for.

【0061】

On the other hand, transaction confirmation is useful in the following cases. That is, the value or risk associated with a particular transaction is intended for the account holder to send and digitally sign the message, and in response, for the account authority to act in trust. Transaction confirmations that rise to a level where the account authority is inactive without sufficient guarantees are useful. The above intent is that the digital signature from the account holder's device is because the digital signature can be generated by the device, potentially without the device, or even without the owner or user knowledge of the device. Cannot be inferred from the mere reception of. For this reason, some means of confirming the account holder's intent with respect to a particular transaction is needed. Such transaction confirmations are preferably obtained by physical, explicit activity carried out by account holders determinable in the messages received by the account authority. For example, in some cases, supplying the co-existence of factor B or C entity credentials by an account holder with a digitally signed message can mean confirmation or intent. Another way to obtain such transaction confirmation is through deliberate and recognizable alterations by the account holder of the "presented" message generated by the account authority. This account authority is then digitally signed by the account holder.

【0062】

In light of the above, in many environments, for example, to a more restricted portion of a particular account or resource, or to another, even if the account holder has already been provided to the entity credentials for session authentication. Access to more restricted accounts or resources requires the account holder to provide additional and / or stronger entity credentials (still for session authentication) before the account authority provides the account holder. It should be understood that it can be. In addition, even for the duration of a particular session, for transaction authentication purposes (if the transaction requires a stronger level of entity authentication than the requested particular session), or for transaction confirmation purposes (before performing the requested activity). It should also be understood that it may be necessary for the account holder to provide entity credentials to the account authority for any of the purposes (if the account authority desires a specific guarantee of the account holder's intent). It should also be understood that a single EC communicated from the account holder to the account authority can be used simultaneously in many environments for both purposes of transaction authentication and transaction confirmation. ..

【0063】

Here, with reference to FIG. 74, an example of EC7406 used for session authentication is shown. As shown, Account Authority 7412 acts as a type of "gatekeeper" for the three resources 7440, 7450, 7460. One of these is desired by Account Holder 7402 to be accessed as required by EC7406. Only one account authority 7412 is shown in this example for ease of reference, but each resource 7440, 7450, 7460 actually has its own separate account authority (not shown) associated with it. It should be understood that it can have.

【0064】

Continuing with Figure 74, Account Holder 7402 directly or indirectly prevents Account Holder 7402 from advancing through GateGate 7494a, 7494b, or 7494c so that Account Holder 7402 is Account Authority. Restrict access to resources 7440, 7450, 7460 until you provide 7412 with a "sufficient" level of entity authentication (at least to the extent required by certain gates 7494a, 7494b, 7494c). For reasons that should be immediately revealed, the level of entity authentication required by each gate will vary depending on what the particular resource being held is intended for. For example, if the resource is a parking check, a minimum level of entity authentication is required. Stronger entity authentication may be required if the resource is a corporate checking account. If the resource is a control system for firing nuclear warheads, even stronger entity authentication is required.

【0065】

In some environments, providing a sufficient level of entity authentication is all that is needed to gain access to a resource. For example, Gate 7494a provides only the session authentication hurdle to account holder 7402 to resource 7440 (but of course, the amount of access provided to account holder 7402 and account holder 7440 accessing the resource). The process that can be done can be further limited by permissions and access rights, which are not discussed in detail herein). Alternatively, providing a sufficient level of entity authentication to pass through gate 7494b, as indicated by resource 7450, allows account holder 7402 to access resource 7450 in general and (included within resource 7450). T) Allows specific access to subresources 7450a, 7450b. In particular, stronger entity authentication is required for account holder 7402 to be visible by gate 7494d before accessing subresource 7450c. In another alternative configuration, providing a sufficient level of entity authentication to pass through Gate 7494c would allow account holder 7402 to access independent resources 7470, 7480, 7490 as well as resource 7460. enable. These resources 7470, 7480, 7490 are not within the protection of resource 7460, but allow access holder 7402 to access them if sufficient entity authentication is provided to pass through gate 7494c. ..

【0066】

As mentioned earlier, in some environments, certain resources 7440, 7450, 7460 are not only protected by, but maintained by, account authority 7412 (eg, account authority 7412 is in a financial institution). If the resource is a bank account with account holder 7402). In other environments, certain resources 7440, 7450, 7460 are simply protected by account authority 7412. This account authority 7412 communicates with and coordinates with another entity, such as a resource manager, access controller, or authentication controller (not shown) that actually maintains the resource (for example, account authority 7412 is just entity authentication). If the system is a resource-secured network server, and access and permissions to this secure network server are controlled by separate access control servers).

【0067】

The illustration in Figure 74 is equally applicable to ECs used for transaction authentication purposes. For example, if the EC contains a specific request for information from one of resources 7440, 7450, 7460 or the account authority 7412 includes a request to perform a specific activity on or within resources 7440, 7450, 7460. , EC7460 is used for entity authentication only for that particular request. However, advancing or session access to certain resources 7440, 7450, 7460 is not granted as a result.

【0068】

Here, with reference to FIG. 75, three different examples of EC between the account holder 7502 and the account authority 7512 via the communication medium 7508 are shown. In all three examples, the final EC from Account Holder 7502 to Account Authority 7512 is used for transaction confirmation purposes.

【0069】

At the first interchange, the account holder 7502 carries the EC, as specified by EC1A in FIG. 75. This EC includes a message (M1) and a digital signature (DS (M1)) on the message. At this interchange, Account Holder 7502 provides sufficient evidence of intent and Factor B or C entity authentication, so that Account Authority 7512 does not require subsequent EC request confirmation.

【0070】

At the second interchange, the account holder 7502 transmits the EC, as specified by EC2A, 2B and 2C, and still referring to Figure 75. This EC includes a message (M2) and a digital signature on the message (DS (M2)). At this interchange, Account Authority 7512 is not satisfied that sufficient evidence of the account holder's intent has been received as attached to the message (M2). For this reason, Account Authority 7512 sends such EC2Bs to Account Holder 7502. EC2B requires account holder 7502 to send a new EC with the same message (M2) and digital signature (DS (M2), but also with the additional performance of Factor B or C entity authentication. This Factor B Or the C entity authentication indicator is included there as "proof" that the account holder 7502 intended to send the EC2A. As shown, the EC2C message is the original with the addition of the entity authentication indicator (EAI). It is essentially the same as the EC2A message in. Such an entity authentication indicator (EAI) is preferably contained within a digitally signed message (M2).

【0071】

At the third interchange, the account holder 7502 conveys the EC, as designated by EC3A, 3B and 3C and still referenced in Figure 75. This EC includes a message (M3) and a digital signature (DS (M3). At this interchange, the account authority 7512 received sufficient evidence of the account holder's intent as attached to the message (M3). For this reason, in this example, the account authority 7512 sends the EC3B to the account holder 7502. The EC3B is to review and digitally sign the presented new message (M4) by the account holder 7502. The message (M4) is composed of the account authority 7512 and preferably contains most (if not all) information contained in the message (M3). The message (M4) is further composed of the message (M4). It may contain additional information not contained in M3). In addition, if Account Holder 7502 approves and accepts the content of Message (M4), Account Holder 7502 will display Message (M4) in (EC3B). , Or modify it in a specific way (based on a known protocol) to create a modified message (mod-M4), and then digitally sign the same (DS (mod-M4)). It is possible to perform factor B or C entity authentication and include an indicator (EAI) within the EC3C, however, as the account authority 7512 does not require it in the EC3B, so it is not required.

【0072】

(g. Data Structures and Formats for EC in ABDS Systems) With reference to FIG. 76, the electronic communications (EC) 7601 according to the various aspects of the invention described herein have different data regions. , Element, or part, generally includes message (M) 7603 and digital signature (DS) 7605. These components generally form data structures that can be stored, communicated, or otherwise manipulated using computing and communication equipment as described herein. EC7601 may be included and / or form a part of a financial transaction according to ISO Standard 8583. This ISO Standard 8583 is incorporated herein by reference or as an X9.59 transaction.

【0073】

Due to known data communication formats and / or data structure agreements, the EC7601 typically includes a header section 7607, a body 7609, and a trailer section 7611. Header 7607 and Trailer 7611 are conventional in nature and are provided for traditional purposes such as EC identification, routing, error correction, packet counting and other purposes as known to those skilled in the art. Will be done.

【0074】

According to the first configuration of this aspect of the invention, the body 7609 comprises a message 7603 and a digital signature 7605 (separated by hashed lines in the figure). Message 7603 preferably includes an account identifier 7616 and message content 7618. The message content may include various types of information such as additional identifiers, commands or instructions (i1) about the account, public keys associated with the account (PuK), time / date stamps, encrypted messages and more. The digital signature 7605 comprises information from message 7603 (eg, message hash, message itself, or compressed material), signed with the sender's private key.

【0075】

According to the second configuration, the main body unit 7609 includes an account identifier 7616 and a message content unit 7618. This message content section 7618 incorporates the digital signature 7605 (ignoring the hashline). The account identifier 7616 can be considered a separate component from the message content 7618. Similar to the first configuration, the digital signature 7605 portion of message content 7618 comprises other information from message content 7618 signed with the sender's private key.

【0076】

Under any of the above configurations, the EC7601 includes an account identifier 7616 and a digital signature 7605 as critical components.

【0077】

A digital signature of any configuration of a data element 7605, depending on the particular use intended by the user of the invention, is an account identifier, additional identifier, an instruction or command relating to the account, the EC sender's public key (PuK), It is understood that information such as and / or other information can be constructed. As previously mentioned, message 7603 does not need to include the account identifier 7616, for example, the account identifier is implied, implied, or retrieved from the message. For example, the EC receiver may have already obtained the account identifier 7616 from a previous message from the EC sender, and retransmission of the account identifier 7616 is not required. Further, for example, it is not necessary for message 7603 or message content 7618 to include an instruction or command if the instruction is implied in the communication between the sender and receiver of the EC.

【0078】

Finally, it should be noted that these electronic communication and data structure formats of the present invention are not limited to file formats, structures, and the content described above. Other formats, structures, and contents with different components and configurations may be used.

【0079】

(h. Specific Implementation of Two-Party ABDS System) The preferred ABDS systems 200, 300 of Figures 2 and 3 can be implemented in a huge number of wide-ranging business applications. Because there are too many specific applications, the following specific examples are described in detail herein to show only the scope and breadth of possible implementations, and the business in which ABDS systems 200, 300 can be implemented. It is not intended that there are restrictions on the type of application. In addition, the particular device used with each particular business application is selected for illustration purposes only, and other devices shown (or not shown) in any other figure may be used. It is not intended to imply or suggest that it is not. Conversely, any device, regardless of form, can be used in most, if not all, business applications utilizing the ABDS systems 200, 300 in Figures 2 and 3, and such devices can be operated. Limited only by possible basic structures.

【0080】

In all of the examples below, it is presumed that the account holder has already set up an ABDS account with the associated account authority. For this reason, the account maintained by the account authority has a public key associated with it that corresponds to the private key. This private key is securely protected by the device, which is owned by the account holder. It is also presumed that in all of the examples below, it is not necessary to encrypt the content of specific communications between various entities, including account holders and account authorities. However, if some of the entities want to protect the content of the information contained in the various ESs between them for privacy confidentiality, or for any similar reason, such ECs are traditional. Methods, such as with a particular EC's intended receiver (s) public key for PGP-type encryption, with secure socket compression (SSL), or with others. It can be encrypted by a particular EC sender with a similar encryption technique. However, various EC encryptions are not required for the functionalization of the present invention.

【0081】

In addition, in many of the specific business applications described below, account holders are encouraged to perform Factor B or Factor C entity authentication as part of the process of configuring an EC and transmitting it to the account authority. Or asked. It should be understood that the mere use of the device is sufficient to provide factor A entity authentication (authentication of the message is essentially successful for the sender of the EC to authenticate the message. You will be sure that you have the private key that corresponds to the commonly used public key). This is sufficient entity authentication for the account authority to act on the message or instruction (i1) contained in the EC from the account holder in many environments. The performance of Factor B and / or Factor C entity authentication enhances the entity authentication provided by the account holder, while being unnecessary for the present invention, and correspondingly, the account authority is in the system and Increase the amount of trust you have in the fact that you are dealing with legitimate account holders.

【0082】

In addition, the methodology by which Factor B and / or Factor C entity authentication is managed between account holders, devices, account authorities, and other entities within the ABDS system described herein is particularly in these implementations. Not explained. It should be assumed that such user or sender authentication is steered by conventional methods (as described above) or as described in VS applications.

【0083】

(i. Financial Institution Account) Figure 6 shows the first business application 600 that implements the two-party ABDS system 200 in Figure 2. In this example, the personalized account holder 602 owns the device in the form of a card 650, such as an IC card, a credit card, or an ATM card or the like that can be used in an ATM machine 660. Card 650 secures the private key of the public-private key pair. The ATM machine 660 includes a display 662, a card reader 664, an alphanumeric keypad 666, and a cash dispenser 668. Card 650 is associated with a debit or credit account maintained by the account authority, including financial institution 612. The account can be a checking deposit, a savings account, a money market account, a credit card account or the like, and a financial institution can be a bank, a savings and loan association, a credit card company or the like. In this example, the ATM machine 660 electronically communicates with the financial institution 612 via a secure, internal banking network 608.

【0084】

Accounts maintained at financial institution 612 are associated with account records maintained within one or more account databases (collectively and exemplified by account database 614 in FIG. 6). Referring to FIG. 7, each account contains a unique account identifier with account number 716. Each account number 716 identifies in account database 614 account information 740, including customer-specific information 742 and account-specific information 744. According to the present invention, the account number 716 further identifies the public key information 718. This public key information 718 includes at least one public key of the account holder for each account. Further, by the function of the present invention, the account number 716 identifies the device profile information 770 about the device holding the private key corresponding to the public key associated with the account.

【0085】

In the example of FIG. 6, the customer-specific information 742 includes, for example, the account holder's name, address, social security number and / or tax identification number. Account-specific information 744 includes, for example, the current account balance, available credits, closing dates and differences on the current statement, and the associated account identifier. The public key information 718 of the account of account holder 602 includes the public key corresponding to the private key held in the card 650. The device profile information 770 includes information specific to the card 650.

【0086】

As mentioned earlier, EC from account holder 602 to financial institution 612 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. In this business application, the most common type of EC is used only for session authentication. This session authentication occurs when account holder 602 initially attempts to log in to or otherwise access the ATM machine 660.

【0087】

Regardless of what type of EC is communicated from account holder 602 to financial institution 612, to configure and digitally sign the message (on the edge of the account holder), and to authenticate the message and entity (account authority). The basic methodology for authenticating (on the edges) is essentially the same. For example, referring here to FIG. 8, the transaction according to the invention is initiated in the implementation shown in FIGS. 6 and 7 when the account holder 602 inserts the card 650 into the card reader 664 of the ATM machine 660. (Step 802). Insertion of the card 650 initiates the ATM machine 660, which uses the display 662 to instruct the account holder 602 to perform entity authentication (step 804). For example, the alphanumeric keypad 666 is used to provide the PIN. Once the PIN is entered, an electronic message is configured to be sent to the financial institution 612 (step 806).

【0088】

The ATM machine 660 displays a menu of available accounts for which account holder 602 can carry out activities. The available accounts are stored in memory on the card 650 and retrieved by the ATM machine 660 for display in the account holder 602. Of course, if only one account is available in memory on the card 650, the account will be selected by default without requiring a specific selection by account holder 602.

【0089】

When selecting an account, the ATM machine 660 displays a menu of operations that can be performed on the selected account. Such operations include, for example, withdrawal of money, balance inquiry, statement request, transfer, monetary deposit, banknote payment and the like. When selecting the desired operation by the account holder 602, and after any additional information about it (withdrawal or transfer amount, etc.) is obtained from the account holder 602, the ATM machine 660 will perform the desired operation of the account holder 602. Consists of an electronic message containing an instruction to the corresponding financial institution 612. The electronic message further includes account number 716 corresponding to the account selected by account holder 602.

【0090】

The message is then transmitted to the card 650 for digital signature by account holder 602 (step 808). In this regard, upon receiving the data representing the message, the card 650 first calculates the hash value of the data and then encrypts the hash value with the private key held in the card 650. Generate a digital signature for (step 810). The card 650 then outputs the digital signature to the ATM machine 660 (step 812). The ATM machine 660 then transmits the message and digital signature in the EC to the financial institution 612 (step 814).

【0091】

Referring to FIG. 9, the EC is received from the ATM machine 660 by the financial institution 612 (step 902). Financial institution 612 then retrieves the public key identified by account number 716 from account database 614 (step 904). Using this public key, financial institution 612 attempts to authenticate the message (step 906). If the message does not authenticate with the public key (step 908), the financial institution 612 responds with a denial of the message (ie, denying access to the account or performing the requested activity) (ie). Step 910). If the message authenticates (step 908), the financial institution 612 concludes that the message actually came from an individual who owns the correct card 650 associated with the identified account number 716 (ie, Factor A entity authentication). Is obtained). The financial institution 612 then determines whether the Factor B entity credentials or the provided state (eg, PIN) is sufficient for further processing of the particular message (step 912). If not sufficient, the financial institution 612 responds to the denial of the message (ie, the denial of granting access to the account or performing the requested activity) (step 910). If the entity authentication provided is sufficient (step 912), the financial institution 612 further processes the message (step 914).

【0092】

In this case, the step of further processing the message (step 914) includes the step of executing the instruction of the message and, if possible, the step of updating the account based on the executed instruction. If it is not possible to execute the order, financial institution 612 responds with a rejection of the message (step 910). For example, if the account holder 602 instructs the financial institution 612 to provide the account balance, the financial institution 612 transmits the account balance to the ATM machine 660 for presentation to the account holder 602. When the account holder 602 instructs the financial institution 612 to withdraw money from the account, the financial institution 612 first checks if the funds are available, and if so, goes to the ATM machine 660. Sends authorization to distribute the requested amount of funds (up to the limit allowed and / or available on a particular account) to Account Holder 602 and updates the account record to reflect the withdrawal. .. If account holder 602 instructs financial institution 612 to transfer funds to another account, financial institution 612 first confirms that the funds are available, and if so, Initiate the transfer of electronic funds to another account, thereby updating the account record. If account holder 602 instructs financial institution 612 to receive payments on banknotes owned by financial institution 612 (credit line payments, credit card payments, mortgagee payments, etc.), financial institution 612 First, make sure the funds are available. If so, start the transfer from your account, which will update your account record.

【0093】

As will be appreciated by those skilled in the art, if the account holder 602 requests an "unusual" transaction such as withdrawal or transfer of a large amount of money or closure of an account, the financial institution 612 will request that the account holder 602 respond to a special request. It may be required to digitally sign the EC for the purpose of transaction confirmation. The financial institution 612 may further require the account holder 602 to provide additional entity credentials or status before the digital signature is generated by the card 650. The ATM machine 660 can be used to help arrange events correctly. As a result, the account holder 602 is prompted to first see the suggested confirmation message displayed on the display 662 of the ATM machine 660 and then enter the secret or biometric. The ATM machine 660 then provides a confirmation message to the card 650 for digital signature. The remaining methods for generating and processing such transaction confirmation ECs are similar to those described above for session authentication.

【0094】

(ii. Fee Account) A second business application 1000 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 10. In this example, the personalized account holder 1002 owns the device in the form of a personal digital assistant (PDA) 1050. The PDA1050 secures the private key of the public-private key pair. The PDA1050 includes a two-way display screen 1052 and a user input key 1056. In addition, the PDA1050 is appropriately equipped with a wireless modem for digital communication via the wireless communication network 1008. PDA1050 is tied to fee commerce, asset management, and credit accounts maintained using the account authority represented by fee company 1012. The commission company 1012 is licensed for trading security on behalf of account holder 1002 and is equipped to receive wireless communications over network 1008.

【0095】

Accounts maintained at Fee Company 1012 are associated with account records maintained at one or more account databases, as aggregated, referenced and shown by account database 1014 in Figure 10. Referring to FIG. 11, each account contains a unique account identifier with account number 1116. Each account number 1116 identifies account information 1140 in the account database 1014, including customer-specific information 1142 and account-specific information 1144. According to the present invention, account number 1116 further identifies public key information 1118. This public key information 1118 includes at least one public key for the account holder for each account. Further, according to the features of the present invention, account number 1116 identifies device profile information 1170 for a device that holds a private key that corresponds to the public key associated with the account.

【0096】

In the example of FIG. 10, the customer-specific information 1142 includes, for example, the account holder's name, address, social security number and / or tax identification number. Account-specific information 1144 includes, for example, account status, account balances, available credits, and in some cases asset holdings, disputed transactions, annual capital gains, combined account identifiers and more. The public key information 1118 of the account of account holder 1002 includes the public key corresponding to the private key held in PDA1050. Device profile information 1170 includes information specific to PDA1050.

【0097】

As mentioned earlier, the EC from account holder 1002 to fee company 1012 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. In this business application, the EC used for session authentication typically occurs when account holder 1002 initially attempts to log in to or otherwise access the online site of fee company 1012. Transaction confirmation occurs in this business application, for example, when account holder 1002 specifically requires commission company 1012 to buy or sell special security. In this case, fee company 1012 digitally signs the request with PDA1050 (and preferably with secret or biometric repopulation) so that account holder 1002 confirms such request. To request.

【0098】

Regardless of what type of EC is communicated from account holder 1002 to fee company 1012, to compose and digitally sign a message (on the edge of the account holder), and to authenticate the message, and (on the edge of the account holder) The basic methodology for authenticating (on the edge of the account authority) is essentially the same. For example, referring to Figure 12 here, the transaction is if the account holder 1002 first establishes a wireless connection to the online site of fee company 1012, or after such a connection has already been established. Initiated when 1002 requests information about the account or when fee company 1012 requests that the activity related to the account be performed (step 1202). The online site then prompts the PDA1050 to provide account holder 1002 with factor B entity credentials such as PINs, if necessary, using the two-way display 1052 (step 1204).

【0099】

Once the PIN is entered, an electronic message is configured to be sent to the fee company 1012 (step 1206). For the first login, the message is simply the associated account number. For other transactions, the message contains an order (i1) from account holder 1002 to fee company 1012. For the first login, the PDA1050 will display a menu of available accounts. Such accounts are displayed in response to communications received from fee companies 1012 or from software pre-stored for this purpose on PDA1050. Preferably, the available accounts are stored in memory on the PDA1050 and presented for selection on display 1052 to account holder 1002. Of course, if only one account is available in memory on the PDA1050, the account holder 1002 will select that account by default without requiring any special selection. For post-login transactions, the PDA1050 displays a menu of operations that can be performed on the selected account. Again, this menu of options can be pre-programmed into the PDA1050 or downloaded from the fee company 1012 if an electronic connection is made between the PDA1050 and the fee company 1012. Such operations include, for example, requests for account status, account balances, available credits, a list of current asset holdings, or a list of disputed transactions or a request to buy or sell security. Upon selection of the desired operation by Account Holder 1002, and after any additional information about it (eg, the amount and selection of certain security purchases or sales) has been obtained from Account Holder 1002, the PDA1050 will be used by Account Holder 1002. Compose an electronic message containing instructions to the fee company 1012 corresponding to the desired operation of 1002. Electronic messages are also accountable

【0100】

The PDA1050 then creates a digital signature for the message by first calculating the hash value for the data and then encrypting the hash value with the private key held within the PDA1050 ( Step 1208). The PDA1050 then outputs the message and digital signature to the PDA1050's wireless modem (step 1210). The PDA1050 transmits EC messages and digital signatures to fee company 1012 (step 1212).

【0101】

Referring to FIG. 13, the EC is received from the PDA1050 by the fee company 1012 (step 1302). The fee company 1012 then retrieves the public key identified by account number 1116 from the account database 1014 (step 1304). Using the public key, the fee company 1012 attempts to authenticate the message (step 1306). If the message is not authenticated using the public key (step 1308), the fee company 1012 responds to the message denial (ie, denying access to the account or performing the requested activity) (that is, denying access to the account or performing the requested activity). Step 1310). If the message is authenticated (step 1308), the fee company 1012 concludes that the message actually came from an individual who owns the correct PDA1050 combined with the identified account number 1116 (ie, Factor A entity authentication). Is obtained). The fee company 1012 then determines if the factor B entity authentication provided (eg, PIN) is sufficient for further processing of a particular message (step 1312). If not sufficient, the fee company 1012 responds to the denial of the message (eg, denial of granting access to the account or performing the requested activity) (step 1310). If entity authentication is sufficient (step 1312), the fee company 1012 further processes the message (step 1314).

【0102】

In the example of the invention, the step of further processing the message after the first session authentication (step 1314) is to access the relevant part (s) of the account record and the PDA personally owned by account holder 1002. Includes steps to display on the welcome website screen above. Further processing of the message after the initial login includes executing the instruction and, if possible, updating the account record based on the executed instruction. If it is not possible to execute the order, the fee company 1012 responds with a rejection of the message (step 1310). For example, account holder 1002 directs fee company 1012 to provide account status, account balance, amount of credit available, list of current asset holdings, list of disputed transactions, or information about specific security. If so, the fee company 1012 obtains the requested information and transmits the requested information to the PDA1050 via the wireless communication network 1008 for display to the account holder 1002 on the display screen 1052 of the PDA1050. If Account Holder 1002 instructs Fee Company 1012 to purchase a specified number of securities shares at a specified price, Fee Company 1102 will first use the funds for the purchase. Make sure it is possible, and if so, place the appropriate "buy" order in the securities market in the traditional way. When and when the purchase of securities is closed, the account record is updated by this (ie, the purchased allocation is added to the list of asset holdings and the purchase price (plus communication) is credited to the account. Or credited). If account holder 1002 directs the fee company 1012 to sell a specified number of securities shares at a specified price, the fee company 1012 will first have the number of specific security allocations. Account holder 100 Make sure that it can be owned and sold by 2, and if so, place the appropriate "sell" order in the securities market in the traditional way. When and when the sale of securities is closed, the account record is updated by this (ie, the sold allocation is removed from the list of asset holdings and the selling price (minus fee) is credited to the account. Will be). For orders to buy and sell securities, it is preferable for the fee company 1012 to obtain a confirmation transaction from the account holder 1002 as described above before executing the requested order.

【0103】

(ii. Pay-as-you-go service account) Figure 14 shows a third business application 1400 that implements the two-party ABDS system 200 in Figure 2. In this example, the account holder 1402, including the individual, owns the device in the form of a mobile phone 1450. The mobile phone 1450 secures the private key of the public-private key pair. The mobile phone 1450 includes a display screen 1452 and a number pad 1456. Further, the mobile phone 1450 appropriately provides wireless voice and data communication via the wireless communication network 1408. The mobile phone 1450 is tied to a pay-as-you-go account, which may include one or more checking accounts, credit card accounts, etc. This pay-as-you-go account is maintained by the account authority represented by the pay-as-you-go service 1412. Pay-as-you-go service 1412 has an automated telephone center authorized to pay pay-as-you-go on behalf of Account Holder 1402 and equipped to receive wireless voice and data communications over network 1408. ..

【0104】

The various payees 1410a, 1410b that account holder 1402 is obliged to pay are also shown in Figure 14. Preferably, the payees 1410a, 1410b are third parties who are obliged by the account holder 1402 to pay regularly and repeatedly. Payees 1410a, 1410b are negative, for example, by mortgage specialists, utilities, credit card companies, retailers, department stores, doctor's offices, and typically account holders 1402 during the last month. It could be another goods and / or service provider that is credited on a January basis for crediting. In this particular business application 1400, account holder 1402 may provide the payment service 1412 with payment information such as the date of description, the maturity date of the payment, and the amount of payment that must be paid to each recipient 1410a, 1410b. It is planned. In an alternative embodiment, payees 1410a, 1410b may be authorized by account holder 1402 to provide the payment information directly to the payment service 1412. Such information may be transmitted by any suitable means, including via dedicated payment network 1411.

【0105】

Accounts maintained in the pay-as-you-go service 1412 are associated with account records maintained in one or more account databases, aggregated, referenced and indicated by the account database 1414 in FIG. Referring to FIG. 15, each account contains a unique account identifier with account number 1516. Each account number 1516 identifies in the account database 1414 account information 1540, including customer-specific information 1542 and account-specific information 1544. According to the present invention, the account number 1516 further identifies the public key information 1518. This public key information 1518 contains at least one public key of the account holder for each account. Further, according to the features of the present invention, account number 1516 identifies device profile information 1570 for a device that holds a private key that corresponds to the public key associated with the account.

【0106】

In the example of FIG. 14, customer-specific information 1542 includes, for example, the name, address, social security number and / or tax identification number of the account holder. Account-specific information 1544 includes, for example, a list of available payment accounts, account balances for each such name payment account, authorized credit card numbers (s), available credits, and if necessary, attached. Along with the payment service 1412, the current balance sheet, current status report, list of payees registered by account holder 1402, customer account number and address for each registered payee, and the current status of each registered payee. Includes information (if available) and others. The public key information 1518 of the account of account holder 1402 includes the public key corresponding to the private key held in the mobile phone 1450. The device profile information 1570 includes information specific to the mobile phone 1450.

【0107】

As mentioned earlier, EC from account holder 1402 to pay-as-you-go service 1412 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. In this business application, the EC used for session authentication usually occurs when the account holder 1402 first attempts to log in to or otherwise access the automated call center of the pay-as-you-go service 1412. Transaction confirmation occurs in this business application, for example, when account holder 1402 specifically requires the pay-as-you-go service 1412 to pay a fixed pay-as-you-go. In this case, the pay-as-you-go service 1412 digitally signs the request using mobile phone 1450 (and possibly by providing additional entity credentials or status) so that account holder 1402 does this. Request to confirm the request.

【0108】

Regardless of what type of EC was communicated from account holder 1402 to pay-as-you-go service 1412, to compose and digitally sign a message (on the edge of the account holder), and to authenticate the message, and then (on the edge of the account holder) The basic methodology for authenticating (on the edge of the account authority) is essentially the same. For example, here, referring to Figure 16, if the account holder 1402 uses mobile phone 1450 to install a wireless phone call to the automated call center of the pay-as-you-go service 1412, or such a connection. Is started when the account holder 1402 requests information about the account or the pay-as-you-go service 1412 requests that the activity related to the account be performed (step 1602). For the first login or for confirmation of a specially requested transaction, the account holder 1402 then uses the number pad 1456 of the mobile phone 1450 to enter Factor B entity credentials such as a PIN (step). 1604).

【0109】

Once the PIN is entered, an electronic message is configured to be sent to the pay-as-you-go service 1412 (step 1606). The first message (including only the account number) consists of an account holder 1402 that presses a key on the number pad 1456 of the mobile phone 1450 that is continued by a specified key (or series of keys) such as the "#" key. Will be done. The specified key indicates that the first message is complete. Preferably, pressing down on the specified key (or set of keys) not only notifies the mobile phone 1450 that the first message is complete, but also informs the mobile phone 1450 about this first message. Have a digital signature created (step 1608). The mobile phone 1450 then attaches the message and digital signature in the EC and transmits it to the Servos 1412 via the wireless communication network 1408 (step 1610).

【0110】

Now, referring to FIG. 17, this first EC is retrieved from the mobile phone 1450 by the pay-as-you-go service 1412 (step 1702). The pay-as-you-go service 1412 retrieves the public key identified by account number 1516 from the account database 1414 (step 1704). Using this public key, the pay-as-you-go service 1412 attempts to authenticate the message (step 1706). If the message does not authenticate (step 1708), the pay-as-you-go service 1412 responds to the EC sender with an EC rejection (step 1710). Such a response may indicate a reason for the refusal, if desired by the pay-as-you-go service 1412. On the other hand, if the message authenticates (step 1708), the pay-as-you-go service 1412 concludes that the message actually came from an individual who owns the correct mobile phone 1450 associated with the identified account number 1516. (Ie, factor A entity authentication is obtained.) The pay-as-you-go service 1412 then determines whether the provided factor B entity authentication (eg PIN) is sufficient for further processing of the particular message (step). 1712). If not sufficient, the pay-as-you-go service 1412 responds with a denial of the message (eg, denial of granting access to the account or performing the requested activity) (step 1710), and again, in this way: Response can give a reason for refusal. If entity authentication (in step 1712) is sufficient, the pay-as-you-go service 1412 further processes the message (step 1714).

【0111】

In the example of the present invention, the step of further processing the message (step 1714) is to account holder 1402 having a menu of options that can be performed on the account 1516 now identified in response to the message containing only account number 1516. Is an automated telephone response.

【0112】

Referring again to FIG. 16, the automated telephone response presentation initiates the process of generating a pay-as-you-go message (step 1612). In this particular example, the automated telephone response presents to account holder 1402: : "Press 1 to pay, press 2 to schedule a new pay due date for a registered payee, press 3 to register a new payee". Account holder 1402 is then guided through a hierarchy of menu options on mobile phone 1450 until a full pay-as-you-go transaction can be formulated by pay-as-you-go service 1412. Preferably, the digital signature does not need to be generated or transmitted during the menu selection / message generation process. Upon completion of the menu selection, the pay-as-you-go service 1412 presents the proposed payment transaction to account holder 1402 for audibility. The number (#) key is used in the following examples for mere exemplary purposes. However, it should be understood that any other key, key arrangement, or telephone operation can be used as an alternative. For example, if Account Holder 1402 is first selected for Option 1 (to pay), the proposed order is "You give us [Payee 1] an amount of $ 51.00 November 1998 4 On the day, I requested to pay for the date of October 22, 1998. For reference, the [Payee 1] customer account number is 012-00009-003 and your payment account is # 01- Use 009000-010. If this is correct, press the number (#) key on the phone. " If Account Holder 1402 first selected Option 2 (to enter a new note for the registered payee), the proposed order would say, "You are planning to pay us to [Payee 1]. 51. For the amount of $ 00, it was scheduled for the day of November 22, 1998 or earlier, and requested to be scheduled for the date of October 22, 1998. For reference, the [Payee 1] customer account number is 012-00009-003. If this is correct, press the number (#) key on the phone. " If Account Holder 1402 first selects Option 3 (to register a new payee), the suggested order is "You have [Payee 1] to your list of registered payees. You requested to add to. Your customer account number with [Payee 1] is 12-00009-003 and the address with [Payment 1] is 123 Main St, AnyTown, AnyState01234. If this is correct, press the number (#) key on the phone. "

【0113】

If account holder 1402 presses any key other than the number (#) key after this voice guidance, the proposed instruction is not accepted (step 1614) and the process of composing a message through the selection of menu items (step 1614). Step 1612) continues. On the other hand, if the account holder 1402 presses the number (#) key on the mobile phone 1450 after one of the above voice guidances, the proposed payment transaction is accepted (step 1614) and the mobile phone 1450 receives the proposed payment. Create a digital signature for the transaction (step 1616). The digitally signed message can be a digital audio file of the accepted proposed payment transaction, which can be temporarily stored in RAM on the mobile phone 1450, or the pay-as-you-go service 1412, The message may be transmitted to mobile phone 1450 as a digital signature in response to the number (#) key pressed in response to the last menu selection. In either case, the mobile phone 1450 then transmits the message and digital signature in the EC to the payment service 1412 over the wireless communication network 1408 (step 1618).

【0114】

As just above, the digitally signed message can be a digital audio file of the proposed instructions when accepted by account holder 1402 by pressing the number (#) key. In an alternative embodiment of this aspect of the invention, rather than pressing the number (#) key to accept the proposed instruction, the account holder 1402 accepts the orally proposed instruction or verbally orders. To configure. It is temporarily stored in RAM on the mobile phone 1450 as a digital file, and a digital signature is then created by the mobile phone 1450 for this instruction.

【0115】

Again, referring to Figure 17, the steps performed by the payment service 1412 in response to the EC of the payment transaction received from the account holder 1402 are essentially those performed in response to the account-only EC. Is the same as. However, the major difference is in step 1714. During this step 1714, the payment service 1412 further processes the payment transaction message by executing or attempting to execute the payment order. The steps to execute an instruction are usually the steps to access the relevant part (s) of the account record, the step to execute the instruction (if possible), and the update of the account record based on the executed instruction. Including the steps to be taken. If it is not possible to execute the instruction, the pay-as-you-go service 1412 responds with a rejection of the message (step 1710). For example, if account holder 1402 instructs Pay-as-you-go service 1412 to pay, Pay-as-you-go service 1412 schedules payments to be made on the scheduled payment date (by email or electronic transfer through payment network 1411). And make sure that the funds are currently available from the payment account 1516 identified by account holder 1402. Either the funds can be set aside at the time of confirmation, or the pay-as-you-go service 1412 can reconfirm the availability of funds from the identified payment account 1516 on the scheduled payment date. If funds are available on the scheduled payment date, the pay-as-you-go service 1412 will forward the funds to the designated payee by email or electronically, thereby updating the account record. If the account holder 1402 simply instructs the pay-as-you-go service 1412 to schedule a new pay-as-you-go service that must be paid to the registered payee, the pay-as-you-go service 1412 simply updates the account record. Similarly, a

【0116】

(iv. Credit Secretariat Account) A fourth business application 1800 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 18. In this example, the account holder 1802, including the individual, owns the device in the form of a dongle 1850 connected to the appropriate port (USB, serial, parallel, etc.) of the personal computer 1860 via cable 1865. The dongle 1850 secures the private key of the public-private key pair. The personal computer 1860 is conventional in that it includes a monitor 1862, a keypad 1864, and a mouse 1866. The dongle 1850, among other accounts, is tied to a personal credit report account maintained by the account authority represented by the credit office 1812. Computer 1860 is properly installed to allow communication over the Internet 1808 to a secure website hosted by Credit Office 1812, by traditional methods such as LAN lines, via a modem. Has web browser software.

【0117】

Accounts maintained by the Credit Secretariat 1812 are collectively referenced in the account database 1814 of FIG. 18 and associated with account records maintained in one or more account databases shown. Referring to FIG. 19, each account contains a unique account identifier with account number 1916. Each account number 1916 identifies in the account database 1814 account information 1940, including customer-specific information 1914 and account-specific information 1944. According to the present invention, the account number 1916 further identifies the public key information 1918. This public key information 1918 contains at least one public key of the account holder for each account. Further, according to the features of the present invention, account number 1916 identifies device profile information 1970 for a device that holds a private key that corresponds to the public key associated with the account.

【0118】

In the example of FIG. 18, customer-specific information 1942 includes, for example, the name, address, social security number and / or tax identification number of the account holder. Account-specific information 1944 includes, for example, a list of accounts, payment history on each account, past maturity on each account, and in some cases total liabilities, credit sources, reports of overall credit status, and more. The public key information 1918 of the account of account holder 1802 contains the public key corresponding to the private key held in the dongle 1850. The device profile information 1970 contains information specific to the dongle 1850.

【0119】

As mentioned earlier, the EC from Account Holder 1802 to Credit Secretariat 1812 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. For example, a common type of session authentication occurs when account holder 1802 first attempts to log in or otherwise access a secure website maintained by Credit Secretariat 1812 in this business application. To do. A further type of session entity authentication occurs when Account Holder 1802 requests access to a particular record or a piece of information that is very sensitive, secure, confidential, or private to Account Holder 1802. In this case, the credit office 1812 may require a stronger level of entity authentication than is required simply to access a secure website. Transaction confirmation is applicable to this business application, for example, if Account Holder 1802 requires Credit Secretariat 1812 to add or change information in the account maintained by Credit Secretariat 1812. In this case, Credit Secretariat 1812 requires account holder 1802 to confirm such a transaction by digitally signing the request with a dongle 1850.

【0120】

Regardless of what type of EC was communicated from Account Holder 1802 to Credit Secretariat 1812, to configure and digitally sign the message (on the Account Holder side), and to authenticate the message and make the entity (Account Authority side). The basic methodology for authenticating (above) is essentially the same. For example, referring here to Figure 20, a transaction occurs when account holder 1802 first accesses the website of Credit Office 1812 via Internet 1808 using computer 1860, or such access has already been established. It is then initiated when account holder 1802 requests access to specific information or when the credit office 1812 requests that activities be performed on the account (step 2002). The website then prompts computer 1860 for account holder 1802 to use keypad 1864 to enter Factor B entity credentials such as a PIN (step 2004).

【0121】

Once the PIN is entered, an electronic message is configured to be sent to the credit office 1812 (step 2006). For the first login, the message is simply the associated account number. For subsequent transactions, the message contains an order (i1) from Account Holder 1802 to Credit Secretariat 1912. For the first login, computer 1860 displays a data entry screen on monitor 1862 that includes an account number data entry area. For subsequent transactions, computer 1860 displays a data entry screen on monitor 1862 that includes additional data entry or a "generate" selection button. Using this "Generate" selection button, Account Holder 1802 can "Provide a Credit Report", "Provide a Credit Score", "Provide Total Debt", "Provide Additional Information", or "Report". You can select the type of transaction you want to start, such as "Error". Once any required data area is filled and the instruction is selected (if applicable), account holder 1802 uses the mouse 1866 to further display a "digital signature" button on the data entry screen. Activate.

【0122】

By selecting this button, the computer 1860 bundles the data entered in the data entry area and pulls the menu down into a single message. This message is then transmitted from computer 1860 to dongle 1850 over cable 1865 for digital signature by account holder 1802 (step 2008). In this regard, upon receipt of data representing a message, dongle 1850 first calculates the hash value for the data, then to encrypt the hash value using the secret key held in the dongle 1850 Therefore, Create a digital signature for the message (step 2010). The dongle 1850 then outputs a digital signature (step 2012). This digital signature is received by computer 1860. Computer 1860 then transmits the EC message and digital signature to the credit office 1812 (step 2014).

【0123】

Referring to FIG. 21, the EC is received from computer 1860 by the credit office 1812 (step 2102). The credit office 1812 then retrieves the public key identified by the account holder 1916 (or other unique identifier, such as a name or social security number) from the account database 1814 (step 2104). Using this public key, the credit office 1812 attempts to authenticate the message (step 2106). If the message does not authenticate with the public key (step 2108), the credit office 1812 responds with a denial of the message (ie, denying access to the account or performing the requested activity). (Step 2110). If the message authenticates (step 2108), the credit office 1812 concludes that the message actually came from the individual who owns the correct dongle 1850 associated with the identified account number 1916. (Ie, factor A entity authentication is obtained.) The credit office 1812 then determines if the provided factor B entity authentication (eg PIN) is sufficient to further process a particular message (step). 2112). If not sufficient, the Credit Secretariat 1812 responds to the denial of the message (eg, denial of granting access to the account or performing the requested activity) (step 2110), and again, in this way: Response may indicate a reason for refusal. If entity authentication is sufficient (in step 2112), the credit office 1812 further processes the message (step 2114).

【0124】

In the example of the invention, the further processing of the message after the first session authentication (step 2114) is to access the relevant part (s) of the account record and the personally owned computer 1860 in account holder 1802. Includes steps to display the welcome website screen above. The steps to further process the message after the first login are to access the relevant part (s) of the account record, to execute the instruction (if possible), and to record the account based on the executed instruction. Includes steps to update. If it is not possible to execute the order, the credit office 1812 responds with a rejection of the message (step 2110). For example, if Account Holder 1802 instructs Credit Secretariat 1812 to provide all credit reports, credit scores, or total debt calculations, Credit Secretariat 1812 will go to the Account Database 1814 to retrieve relevant information. to access. This relevant information is then transmitted to computer 1860 for display on monitor 1862 to account holder 1802. If Account Holder 1802 instructs Credit Secretariat 1812 to provide additional information for inclusion in the Account Database 1814, Credit Secretariat 1812 will provide new data that Account Holder 1802 may provide new information. Provide a subscription page. This new data subscription page is digitally signed using the dongle 1850 and constitutes a new message transmitted to the credit office 1812 in the same way as above. Similarly, if Account Holder 1802 instructs Credit Secretariat 1812 to want to report an error in the credit report or account database, Credit Secretariat 1812 may report the alleged error to Account Holder 1802. Data subscription page, account holder Provided to 1802. This new data subscription page constitutes a new message that was digitally signed using the Dongle 1850 and transmitted to the Credit Office 1812 in the same way as above. Once the credit office 1812 receives new information or alleged error notifications from account holder 1802, it will begin investigating the issue. If the information appears to be accurate, this will update the appropriate record (s) in the account database 1814. For some of the above orders, it is preferable for the Credit Secretariat 1812 to obtain a confirmation transaction from the account holder 1802 as described above before executing the requested order.

【0125】

(v. Patient / Personal Health Record Account) Figure 22 shows the fifth business application 2200 that implements the two-party ABDS system 200 in Figure 2. In this example, the account holder, including patient 2202, owns the device in the form of a card 2250, such as an IC card. The card 2250 secures the private key of the public-private key pair and can be used for the card reader 2252. The card reader 2252 includes an alphanumeric keypad 2256, a display 2254, and a thumbprint reader 2258. The card reader 2252 is connected to the appropriate port (USB, serial, parallel, etc.) of the personal computer 2260 via cable 2265. The personal computer 2260 is conventional in that it includes a monitor 2262, a keypad 2264, and a mouse 2266. As will be appreciated by those skilled in the art, use the card reader 2252 display 2254 to display digitally signed messages and the keypad 2256 and thumb on the card reader to receive entity credentials from patient 2202. Using the fingerprint reader 2258 provides greater security and lower potential for fraud if the same information is displayed and entered on the computer 2260 using the monitor 2262 and the keypad 2264.

【0126】

Card 2250 is associated with a medical record account that is specifically associated with patient 2202 and is maintained by the account authority represented by medical record access number 2112, among other accounts. Computer 2260 is directly connected using Medical Record Access Manager 2212 to access patients enrolled in Medical Record Access Manager 2212 and select selected parts of an individual's medical record maintained by Medical Record Access Manager 2212. Has customer software installed to allow viewing.

【0127】

Accounts maintained by Medical Records Access Manager 2212 are associated with account records maintained in one or more account databases, collectively referenced and shown in account database 2214 in FIG. Referring to FIG. 23, each account contains a unique account identifier as account number 2316. Each account number 2316 identifies in account database 2214 account information 2340, including customer-specific information 2342 and account-specific information 2344. According to the present invention, the account number 2316 further identifies the public key information 2318. This public key information 2318 contains at least one public key of the account holder for each account. Further, by the function of the present invention, the account number 2316 identifies the device profile information 2370 for the device holding the private key corresponding to the public key associated with the account.

【0128】

In the example of FIG. 22, the customer-specific information 2342 shown in FIG. 23 includes, for example, the patient 2202's name, address, social security number and / or tax identification number. Account-specific information 2344 includes, for example, current doctor list, current health information, medical profile and history, known allergies, major medical conditions, tissue donor information and more. The public key information 2318 of the patient 2202's account contains the public key corresponding to the private key held in the card 2250. The device profile information 2370 includes information specific to the card 2250.

【0129】

As previously mentioned, the EC from Patient 2202 to Medical Record Access Manager 2212 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. For example, a common type of session authentication occurs when patient 2202 first attempts to log in or otherwise access medical record access software maintained on computer 2260 in this business application. .. In addition, session authentication occurs when patient 2202 requests access to a particular record or piece of secure, confidential, or private information that is very sensitive to the patient. In this case, the medical record access manager 2212 may require a stronger level of entity authentication (eg, Factor C with the thumbprint reader 2258) than was required to simply access the relevant software. Transaction confirmations in this business application (during any of the sessions above), for example, activities related to patient information contained in a medical record database (eg, update, add, delete, or such information). Patient 2202 requests medical care from record access manager 2212 and medical record access manager 2212 digitally signs the request to patient 2202 using card 2250 (and possibly It is also applicable if you require that such a request be confirmed by an additional factor (by providing additional factor B or C entity credentials or state).

【0130】

Regardless of what type of EC is communicated from patient 2202 to medical record access manager 2212, to configure and digitally sign the message (on the patient side), and to authenticate the message and make the entity (medical record access). The basic methodology for authenticating (on the manager's side) is essentially the same. For example, referring here to FIG. 24, the EC according to the invention is when patient 2202 first attempts to log in to computer 2260 to access medical record software, or such login has already been successful. After successful completion, it is initiated when patient 2202 requests sensitive patient information or medical record access manager 2212 requests to perform activities related to the patient's account (step 2402). In either case, if the card has not yet been provided, the computer 2260 prompts patient 2202 to put the card 2250 into a card reader 2252 (for example, if the reader 2252 is a "contact" type reader, the card. Provided by inserting the 2250 or by bringing the card 2250 in close proximity to the reader 2252 if the reader is a "contactless" type reader (step 2404). Computer 2260 then prompts patient 2202 to provide factor B and / or C entity credentials using the alphanumeric keypad 2256 and / or thumbprint reader 2258 (step 2406). Once such entity credentials are provided, an electronic message is configured to be sent to the medical record access manager 2212 (step 2408). In this case, by the first EC simply requesting access to the system, the message is simply account number 2316 associated with the account maintained by Medical Records Access Manager 2212. Preferably, the reader 2252 has an account available on display 2254 that patient 2202 can select. Display the menu. Preferably, such available accounts are stored in memory on the card 2250 and retrieved by the reader 2252 for selection by patient 2202. Of course, if only one account is available in memory on the card 2250, that account will be selected by default without requiring a specific selection by patient 2202. For subsequent transactions, patient 2202 can choose what information he wants to see (on computer 2260) or what activity he wants the medical record access manager 2212 to perform.

【0131】

In either case, once the computer 2260 composes the message, it is transmitted to the card reader 2252 for display on display 2254 and for digital signature by patient 2202 to card 2250 ( Step 2410). In this regard, upon receiving the data representing the message, the card 2250 first calculates the hash value for the data and then encrypts the hash value with the private key held on the card 2250. Create a digital signature for (step 2412). Card 2252 then transmits the digital signature along with the message as an EC to computer 2260 (step 2416). The computer 2260 transfers the same to the medical record access manager 2212 for authentication.

【0132】

Referring to FIG. 25, the EC is received from the computer 2260 by the medical record access manager 2212 (step 2502). The medical record access manager 2212 then retrieves the public key identified by account number 2316 from the account database 2214 (step 2504). With this public key, medical record access manager 2212 attempts to authenticate the message (step 2506). If the message does not authenticate (in step 2508), the medical record access manager 212 responds with a denial of the message (ie, denial of granting access to the website or performing the requested activity) (step). 2510). Such a response may indicate a reason for refusal. If the message authenticates (step 2508), the medical record access manager 2212 concludes that the message actually came from an individual who owns the correct card 2250 associated with the identified account number 2316. (Ie, factor A entity authentication is obtained.) The medical record access manager 2212 then provides further factor B and / or C entity authentication (eg, PIN and / or thumbprint) for specific messages. Determine if it is sufficient for processing (step 2512). If not sufficient, the medical record access manager 2212 responds with a rejection of the message (step 2510), and again, such a response may indicate a reason for the rejection. If entity authentication is sufficient (in step 2512), the medical record access manager 2212 further processes the message (step 2514).

【0133】

Further processing of the message for the first login gives patient 2202 the right to access the recording access program on computer 2260 and to see private but sensitive information belonging to patient 2202. It simply means to do. This information is maintained in database 2214 and displayed using the customer's software on computer 2260 in response to appropriate inquiries. If the message is a request by patient 2202 to access information belonging to patient 2202 that requires caution, the medical record access manager 2212 may request stronger entity credentials from patient 2202 (such caution). (Due to the increased risk and potential burden of displaying the required information to unauthorized persons) Therefore, in this situation, the computer 2260 prompts patient 2202 (step 2406), PIN and thumb. Have both fingerprints provided. If the decision (step 2512) is positive in this situation, the further processing step (step 2514) includes providing access to the information required for patient 2202 that requires caution. Requests by Patient 2202, where the EC, Medical Records Access Manager 2212, conducts activities with respect to the account or with respect to the information contained in the account, eg, specific medical records, reports, or hospitals, insurance companies, or medical practices. Such ECs may be processed as commonly described in FIGS. 24 and 25, including requests to transfer information to a third party such as a home. However, in contrast to the above two ECs, the purpose of obtaining a digital signature from patient 2202 is not only for entity authentication, but primarily for the "confirmation" of the requested activity. In this scenario, if the entity credentials or state provided is sufficient (as determined in step 2512), the step of further processing the message includes the performance of the requested activity.

【0134】

(vi. (Medical) Medical Care Management Account) A sixth business application 2600 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 26. In this example, an account holder with a medical professional 2602 owns the device in the form of a personal item 2650, such as a watch (as shown), jewelry, keyrings, etc. This personal item 2650 is capable of transmitting and receiving radio frequency (RF) data transmissions to and from the RF receiver / transmitter 2652. The personal item 2650 secures the private key of the public-private key pair. In this example, the RF receiver / transmitter 2652 is connected to the appropriate port (USB, serial, parallel, etc.) of the personal computer 2660 via cable 2665. The personal computer 2660 is conventional in that it includes a monitor 2662, a keypad 2664, and a mouse 2666. In the example of the invention, the computer 2660 further includes a microphone 2668 for receiving voice inputs such as the voice of a healthcare professional 2602 for entity authentication purposes.

【0135】

The personal item 2650 is specifically associated with a medical care management account maintained by the account authority represented by the medical care management server 2612. Computer 2660 must install appropriate database management and access software to interact with the information contained in the account database maintained by server 2612, for example, through the internal or external network 2608 (in this case, the internal network). To enable.

【0136】

Accounts maintained by server 2612 are associated with account records maintained in one or more account databases, aggregated, referenced, and shown by account database 2614 in Figure 26. Referring to FIG. 27, each authorized user in account database 2614 is identified by a unique account identifier that includes account number 2716. Each account number 2716 identifies in account database 2614 account information 2740, including entity-specific information 2742 and accessible database 2744. According to the present invention, the account number 2716 further identifies the public key information 2718. This public key information 2718 includes at least the public key of the user of each account. Further, by the function of the present invention, the account number 2716 identifies the device profile information 2770 for the device holding the private key corresponding to the public key associated with the account.

【0137】

In the example of FIG. 26, the entity-specific information 2742 determines, for example, the name, location, field of practice, and access to the roster of the group to which the account holder belongs (other databases and sub-records (not shown)). For) including. The list of accessible databases 2744 includes, for example, group calendars, personal calendars, group content lists, personal content lists, group patient lists, personal contact lists, accepted insurance policy lists and more. The public key information 2718 for the medical professional 2602 account contains the public key that corresponds to the private key held in the personal item 2650. The device profile information 2770 contains information specific to the personal item 2650.

【0138】

As previously mentioned, the EC from Healthcare Professional 2602 to Server 2612 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. For example, a common type of session authentication occurs when a healthcare professional 2602 first attempts to log in or otherwise access database management and access software maintained on computer 2660 in this business application. To do. Transaction confirmation requires, for example, medical professional 2602 to perform activities on server 2612 regarding the recording of one of the patients contained in the database (eg, updating or adding information) in this business application and server. 2612 confirms such request by digitally signing the request to medical professional 2602 with personal item 2650 (and, if possible, further providing additional entity credentials or status). Is applicable when requesting.

【0139】

Regardless of what type of EC is communicated from healthcare professional 2602 to server 2612, to configure and digitally sign the message (on the healthcare professional side), and to authenticate the message and make the entity (on the server side). The basic methodology for authenticating is essentially the same. For example, referring here to FIG. 28, the transaction is access to various medical records maintained on server 2612 by medical professional 2602 by connecting via internal network 2608 using computer 2660. When accessing the login screen for, or after such a login has already occurred, the healthcare professional 2602 requests information from the database, or the server 2612 performs activities related to the request in the database. It is started when requesting that (step 2802). Server 2612 then prompts computer 2660 for medical professional 2602 to enter Factor C entity credentials such as voiceprints by speaking to microphone 2668 (step 2804).

【0140】

Once the computer 2660 gets the proper voiceprint, an electronic message is configured to send to server 2612 for authentication and access to database records (step 2806). For the first login, Computer 2660 displays a menu of available accounts that Healthcare Professional 2602 can select. Preferably, such available accounts are stored in memory on the personal item 2650 and retrieved by the computer 2660 for selection by the medical professional 2602. Of course, if only one account is available in memory on the personal item 2650, that account will be selected by default without requiring a specific selection by the healthcare professional 2602. Alternatively, the list of available accounts may be maintained in memory on the computer 2660 itself and displayed for selection by the healthcare professional 2602. For post-login communication, the computer 2660 displays, for example, the available patient records that medical professional 2602 is allowed to review and a menu of activities that can be performed on each such patient record. .. Computer 2660 also displays, for example, group and individual calendars, address books, and e-mail boxes that medical professionals have access to.

【0141】

Once the computer 2660 composes the message, it is transmitted over the cable 2665 to the RF receiver / transmitter 2652 (step 2808). The RF receiver / transmitter 2652 then transmits an RF signal (including a message) to the personal item 2650 for digital signature by a medical professional 2602. In this regard, upon receiving an RF signal containing data representing a message, the personal item 2650 first calculates the hash value for the data and then encrypts the hash value with the private key held in the personal item 2650. Create a digital signature for the message by doing so (step 2810). The personal item 2650 then outputs a digital signature (step 2812). This digital signature is received by the RF receiver / transmitter 2652. This RF receiver / transmitter 2652 transfers the same digital signature to computer 2660. Computer 2660 then transmits the message and digital signature over EC to server 2612 (step 2814).

【0142】

Referring to FIG. 29, the EC is received from computer 2660 by server 2612 (step 2902). Server 2612 then retrieves the public key identified by account number 2716 from account database 2614 (step 2904). With this public key, server 2612 attempts to authenticate the message (step 2906). If the message does not authenticate with the public key (step 2908), server 2612 responds with a message denial (ie, denying access to the account or performing the requested activity) (step). 2910). If the message authenticates (in step 2908), server 2612 concludes that the message actually came from the individual who owns the correct personal item 2650 associated with the identified account number 2716. (That is, factor A entity authentication is obtained). Server 2612 then determines if the Factor C entity credentials or state provided (eg, voiceprint) is sufficient to further process the particular message (step 2912). If not sufficient, the server 2612 responds with a rejection of the message (step 2910), and again, such a response may indicate a reason for the rejection. If entity authentication is sufficient (in step 2912), server 2612 further processes the message (step 2914).

【0143】

Further processing the message for the first login simply means providing the healthcare professional 2602 with access to the screen of the primary user displayed by the computer 2660. Further processing for subsequent communications often means displaying information retrieved from database 2614 in response to appropriate investigations made by medical professionals using computer 2660. In some environments, for example, if the message is a request by a healthcare professional 2602 for access to sensitive information relevant to one of the patients, server 2612 medically provides stronger entity credentials. May be requested by expert 2602 (due to the increased risk and potential burden of displaying such sensitive information to unauthorized individuals). Therefore, in this situation, the computer 2660 instructs the healthcare professional 2602 to provide the PIN and voiceprint (using the computer keypad) (in step 2806). If the decision (in step 2912) is positive in this situation, further processing (step 2914) provides medical professional 2602 with access to the required and cautious information. Including. The EC requests by Healthcare Professional 2602 that Server 2612 conducts activities with respect to or about the information contained in the Account (eg, information on patient records for which Healthcare Professional 2602 has the right to modify or add). Such ECs can be processed as generally described in FIGS. 28 and 29, including requests to add or change). However, in contrast to the two ECs mentioned above, the server 2612 may request a digital signature on this EC, primarily to "confirm" the requested activity. In this scenario, if the entity credentials or state provided is sufficient (as determined in step 2912), further process the message.

【0144】

(vii. Administrative Benefit Account) A seventh business application 3000 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 30. In this example, the account holder, including Citizen 3002, is a watch, necklace or collar (dog-tag), other jewelry, key ring (Key). ring) Own the device in the form of personal items 3050 such as others. This personal item 3050 can transmit and receive radio frequency (RF) data transmissions from the RF receiver / transmitter 3052. Necklace 3050 secures the private key of the public-private key pair. In this example, the RF receiver / transmitter 3052 is connected to the appropriate port (USB, serial, parallel, etc.) of the personal computer 3060 via cable 3065. The personal computer 3060 is conventional in that it includes a monitor 3062, a keyboard 3064, and a mouse 3066. Necklace 3050 is associated with, among other things, an administrative record account maintained by the account authority represented by Citizen Record Manager 3012. Computer 3060 is properly installed to allow you to communicate over the Internet 3008 to a secure website hosted by Citizen Record Manager 3012, by traditional methods such as via a modem, LAN line, etc. Has web browser software.

【0145】

Accounts maintained by Citizen Record Manager 3012 are associated with account records maintained in one or more account databases that are aggregated and referenced by the account database in Figure 30. Referring to FIG. 31, each authorized user of account database 3014 is identified by a unique account identifier with account number 3116. Each account number 3116 identifies in the account database 31014 account information 3140, including citizen-specific information 3142 and account-specific information 3144. According to the present invention, the account number 3116 further identifies the public key information 3118. This public key information 3118 includes at least the public key of the citizen associated with each account. Further, by the function of the present invention, the account number 3116 identifies the device profile information 3170 for the device holding the private key corresponding to the public key associated with the account.

【0146】

In the example of FIG. 30, citizen-specific information 3142 includes, for example, citizen's name, address, social security number, tax identification number, business, place of origin, age, and so on. Account-specific information 3144 includes, for example, social security benefits, welfare benefits, geriatric health insurance / national health insurance benefits, universal prescripyion drug benefits, universal health care benefits, and final declarations (previous five years). Electronic format), savings balance information and more. Citizen 3002 account public key information 3118 contains the public key that corresponds to the private key held on the necklace 3050. Device profile information 3170 contains information specific to necklace 3050.

【0147】

In this business application, the EC from Citizen 3002 to Citizen Record Manager 3012 is generally used only for session authentication purposes. For example, first session authentication occurs when Citizen 3002 first attempts to log in or otherwise access a secure website maintained by Citizen Records Manager 3012. Further session authentication occurs when Citizen 3002 requests access to certain records or parts of information that are secure, confidential, or private that are very sensitive to Citizen 3002. In this case, Citizen Records Manager 3012 requires a stronger level of entity authentication than is required simply to access a subscription-level secure website.

【0148】

Regardless of which session authentication EC was communicated from Citizen 3002 to Citizen Record Manager 3012, to compose and digitally sign the message (on the Citizen side) and authenticate the message and make the entity (on the Citizen Record Manager side) The basic methodology for authentication is essentially the same. For example, referring here to FIG. 32, the transaction according to the invention, in the implementation shown in FIGS. 30 and 31, citizen 3002 first connects through the internet 3008 using computer 3060. Citizens 3002, as mentioned above, very much when accessing the login screen to access a secure website maintained by Record Manager 3012, or after such a secure website has been successfully accessed. Initiated when requesting access to sensitive, secure, confidential, or private information (step 3202). The secure website can then attach the PIN to the computer 3060 using the keyboard 3064, or attach a biometric sample to the computer 3060, or electronically communicate with the computer 3060 in other cases. Directing computer 3060 (step 3204) by providing the appropriate biometric reader (not shown) to the citizen 3002 to provide factor B or C entity credentials such as PIN or biometric information. Let me provide it.

【0149】

In this case, once the PIN is entered, an electronic message is configured to be sent to Citizen Record Manager 3012 for authentication and access to Citizen's personal records (step 3206). For login purposes, the message only needs to include the relevant account number. For subsequent requests for transaction authentication communications or access to information, the message includes an order (i1) from Citizen 3002 to Citizen Records Manager 3012. For the first login, computer 3060 displays a menu of available accounts that citizen 3002 can select. Preferably, such available accounts are stored in memory on the necklace 3050 and retrieved by the RF receiver / transmitter 3052 (as directed by computer 3060) for selection by citizen 3002. Of course, if only one account is available in memory on the necklace 3050, that account will be selected by default without requiring a specific selection by citizen 3002. Alternatively, the list of available accounts may be maintained in memory on the computer 3060 itself and displayed for selection by citizen 3002. For post-login communication, computer 3060 displays, for example, a menu of available citizen records and administrative benefit accounts that citizen 3002 is allowed to see.

【0150】

Once the appropriate account number or menu item is selected, Computer 3060 translates the information into a message. This message is transmitted from computer 3060 to RF receiver / transmitter 3052 via cable 3065 (step 3208). The RF receiver / transmitter 3052 then sends an RF signal (including a message) to the necklace 3050 for digital signature by citizen 3002. In this regard, when receiving an RF signal containing data representing a message, the necklace 3050 first calculates the hash value for the data and then encrypts the hash value with the private key held in the necklace 3050. By doing so, create a digital signature for the message (step 3210). Necklace 3050 then outputs a digital signature (step 3212). This digital signature is received by the RF receiver / transmitter 3052. This RF receiver / transmitter 3052 transfers the same thing to computer 3060. Computer 3060 then transmits the message and digital signature to Citizen Record Manager 3012 in the EC (step 3214).

【0151】

Referring to FIG. 33, the EC is received from computer 3060 by citizen record manager 3012 (step 3302). Citizen record manager 3012 then retrieves the public key identified by account number 3116 from the account database 3014 (step 3304). Using this public key, Citizen Record Manager 3012 attempts to authenticate the message (step 3306). If the message does not authenticate with the public key (in step 3308), Citizen Records Manager 3012 responds with a denial of the message (ie, denying access to the account or performing the requested activity). (Step 3310). If the message authenticates (in step 3308), Citizen Records Manager 3012 concludes that the message actually came from the individual who owns the correct necklace 3050 associated with the identified account number 3116. (That is, factor A entity authentication is obtained). Citizen Records Manager 3012 then determines whether the Factor B or C entity credentials or status provided (eg, PIN and / or biometric information) is sufficient to further process a particular message (eg, PIN and / or biometric information). Step 3312). If not sufficient, Citizen Records Manager 3012 responds with a rejection of the message (step 3310), and again, such a response may provide a reason for the rejection. If entity authentication is sufficient (in step 3312), citizen record manager 3012 further processes the message (step 3314).

【0152】

Further processing the message for the first login simply means providing citizen 3002 with access to the primary user screen of the secure website displayed by computer 3060. Further processing for subsequent communications means displaying the citizen records or administrative benefit information requested for citizen 3002. As previously mentioned, due to the added security, Citizen Records Manager 3012 has added digital signatures for some orders and requests made on the website (eg transaction confirmation or further session authentication). Can be requested. If necessary, a message will be generated when Citizen 3002 selects a particular option or menu item on the website. When such an option or item is selected, Citizen Record Manager 3012 transmits a data packet of information to computer 3060 with an instruction requesting a digital signature. Upon response, computer 3060 transmits information to necklace 3050 via RF receiver / transmitter 3052. This information constitutes a new message. To prevent unauthorized or unintended digital signatures from being generated in response to unwanted RF signals transmitted to the Necklace 3050, Citizen Record Manager 3012 will use Factor B or C entity authentication unless factor B or C entity authentication is performed. It is preferable not to trust the EC received from the necklace 3050.

【0153】

(viii. Internet Service Provider) Figure 34 shows the eighth business application 3400 that implements the two-party ABDS system 200 in Figure 2. In this example, the account holder 3402, including the individual, owns the device in the form of a dongle 3450. The dongle 3450 plugs directly into the appropriate port (USB, serial, parallel, etc.) on the back of the personal computer 3460. The dongle 3450 secures the private key of the public-private key pair. The personal computer 3460 is conventional in that it includes a monitor 3462, a keyboard 3464, and a mouse 3466. The dongle 3450 is specifically associated with an Internet Service Provider account maintained by the Account Authority represented by Internet Service Provider 3412. Computer 3460 has suitable web browser software installed to allow Internet service provider 3412 to communicate over network 3408 in traditional ways such as via a modem, LAN line, etc. The computer also has installed software that allows the computer 3460 to communicate with the attached dongle 3450.

【0154】

Accounts maintained at Internet Service Provider 3412 are associated with account records maintained in one or more account databases, aggregated and referenced by account database 3414 and shown in Figure 34. Referring to FIG. 35, each account contains a unique account identifier with account number 3516. Each account number 3516 identifies in account database 3414 account information 3540, including customer-specific information 3542 and account-specific information 3544. According to the present invention, the account number 3516 further identifies the public key information 3518. This public key information 3518 contains at least one public key of the account holder for each account. Further, by the function of the present invention, the account number 3516 identifies the device profile information 3570 for the device holding the private key corresponding to the public key associated with the account.

【0155】

In the example of FIG. 34, the customer-specific information 3542 includes, for example, the name of the account holder, billing address, email address, credit card information, and so on. Account-specific information 3544 includes, for example, ISP connection methods (eg, telephone modems, cable modems, ISDN, T1 connections, etc.), and speed, Internet time used and utilized, email accounts and aliases, the web. Includes page address (s) and others. The public key information 3518 of account holder 3402 contains the public key corresponding to the private key held in the dongle 3450. Device profile information 3570 contains information specific to the dongle 3450.

【0156】

In this business application, the EC from Account Holder 3402 to Internet Service Provider 3412 is generally the Internet Access Portal of Internet Service Provider 3412 for the purpose of session authentication (ie, first, for the purpose of accessing the Internet). Used only (to log in to or otherwise access). For this reason, messages that are typically only needed to communicate from account holder 3402 to Internet service provider 3412 include account number 3516 for the Internet account. The instruction (i1) (ie, "give me access to the Internet") is implicit in the EC's mere communication, including the account number.

【0157】

As shown in Figure 36, session authentication allows account holder 3402 to install automated login software on computer 3460 by "double-clicking" the Internet access icon on the computer desktop in the traditional way. Started when activated (step 3602). The automated login software sends a request for a digital signature message from the computer 3460 to the connected dongle 3450 (step 3604). In response, the dongle 3450 receives the account number from internal memory (step 3606) and provides the account number as a message to the digitally signed component of the dongle 3450 (step 3608). The dongle 3450 then creates a digital signature on the message by first calculating the hash value for the data and then encrypting the hash value with the private key held in the dongle 3450 (step 3610). ). The dongle 3450 then outputs a digital signature (step 3612). This digital signature is received by computer 3460. Computer 3460 then transmits the message and digital signature to Internet service provider 3412 in EC in the traditional way (step 3614).

【0158】

Referring to FIG. 37, the EC is received from computer 3460 by Internet service provider 3412 (step 3702). Internet service provider 3412 then receives from account database 3414 the public key identified by account number 3516 (step 3704). With this public key, Internet service provider 3412 attempts to authenticate the message (step 3706). If the message authenticates (step 3708), the internet service provider 3412 says that the message actually comes from a computer 3460 with a legitimate dongle 3450 connected (this is probably the computer 3460 in account holder 3402). We conclude that we provide computer 3460 with access to Internet 3408 (step 3712). On the other hand, if the message does not authenticate (in step 3708), Internet service provider 3412 responds with a rejection of the message (step 3710). Such a response may include a reason for refusal.

【0159】

Obviously, the above process does not provide very strong entity authentication. That is because any computer with a connected, suitable dongle 3450 can gain access to the Internet (step 3712). If stronger entity authentication is desired, the above process can be modified to be more similar to previous business applications. This requires account holder 3402 to provide factor B and / or C entity credentials. In this case, for example, account holder 3402 may be required to enter Factor B entity credentials such as a PIN. This Factor B entity credential is transmitted by the computer 3460 to the dongle 3450 along with the "Request for Digital Signature" message above. Internet Service Provider 3412 then determines if the entity credentials or state provided by Account Holder 3402 is sufficient for Internet Service Provider 3412 to determine that Account Holder 3402 is an entity that resides on Computer 3460. (In steps not shown). In this case, EC is still used for session authentication.

【0160】

(ix. Employee Database Authentication Account) A ninth business application 3800 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 38. In this example, the account holder, including the computer programmer 3802, owns the device in the form of an electronic key 3850. This electronic key 3850 is designed to interface with the electronic lock 3852. The electronic lock 3852 is connected to the appropriate port (USB, serial, parallel, etc.) of the computer terminal 3860 via cable 3865. The electronic key 3850 secures the private key of the public-private key pair. The personal computer 3860 is conventional in that it includes a monitor 3862, a keyboard 3864, and a mouse 3866. The electronic key 3850 is associated with the employee's database authentication account maintained by the account authority represented by the authentication server 3812 (in this example) run by the employer (not shown) of computer programmer 3802. Employers engage in the business of computer program and code generation, design, and writing. Computer 3860 has direct access to authentication server 3812 via internal computer network 3808, and indirect access to secure server 3892 through server 3812 and through internal firewall 3894. The source code of the computer program is stored on this secure server 3892. Legitimate computer programmers 3802 are authorized to run and need access to this computer program. However, each time the computer programmer 3802 wants to access the secure server 3892, the computer programmer 3802 must first be authenticated and authorized by the authentication server 3812.

【0161】

Accounts maintained by Authentication Server 3812 are associated with account records maintained in one or more account databases, aggregated and referenced by account database 3814 and shown in Figure 38. Referring to FIG. 39, each authorized user in the account database 3814 is identified by a unique account identifier (such as an employee ID) with account number 3916. Each account number 3916 identifies in account database 3814 account information 3940, including employer-specific information 3942 and accessible database 3944. According to the present invention, the account number 3916 further identifies the public key information 3918. This public key information 3918 includes at least the public key of the user of each account. Further, by the function of the present invention, the account number 3916 identifies the device profile information 3970 for the device holding the private key corresponding to the public key associated with the account.

【0162】

In the example in Figure 38, employee-specific information 3942 includes, for example, name, email address, department, administrator name, authorized project (s), building location, room location, computer serial. Includes numbers and more. The list of accessible databases 3944 includes, for example, multiple projects, project 1, project 2, and up to project n identified here. The public key information 3918 of the computer programmer 3802 account contains the public key corresponding to the private key held in the electronic key 3850. The device profile information 3970 includes information specific to the electronic key 3850. In this context, the message from the computer programmer 3802 includes the account number 3916 for the associated account and an instruction to the authentication server 3812 (eg, to provide access to the secure server 3892).

【0163】

In this business application, the EC from the computer programmer 3802 to the authentication server 3812 is generally for the purpose of session authentication (ie, the first protected computer program or source code maintained on the secure server 3892). Used only to gain access). For this reason, in general, only the messages required for communication from the computer programmer 3802 to the authentication server 3812 are the account number 3916 for the associated account and the computer programmer 3802 authorized to operate the project, program, Or it will include the name of the source code file.

【0164】

As shown in Figure 40, session authentication is initiated when computer programmer 3802 requests access to secure server 3892 (step 4002). Such a request is formulated using the appropriate operating system computer command on computer 3864 and presented to authentication server 3812. In response to the request, the authentication server 3812 prompts the computer 3860 (step 4004) to have the computer programmer 3802 insert the electronic key 3850 into the electronic key lock 3852 to provide Factor B entity credentials. For example, for a PIN, the keyboard 3864 is used to enter the PIN into the computer 3860. Once the key 3850 is inserted into lock 3852 and the PIN is entered, an electronic message is configured to send to authentication server 3812 for authentication and authorization to access secure server 3892. (Step 4006). The message is composed of, for example, the following method.

【0165】

Computer 3860 prompts computer programmer 3802 to identify the "project name" for the requested access. Once the project name is entered, computer 3860 combines the project name and account number 3916 with a message to digitally sign. The message is then transmitted from computer 3860 to lock 3852 and then to key 3850 via cable 3865 (step 4008). Once the message is received by key 3850, it is digital to the message by first calculating the hash value for the data and then encrypting the hash value with the private key held in key 3850. Create a signature (step 4010). Key 3850 then outputs the digital signature (step 4012). This digital signature is received by Lock 3852. This lock 3852 transfers the same thing to computer 3860. Computer 3860 then ECs the message and digital signature to the authentication server 3812 (step 4014).

【0166】

Referring to FIG. 41, the EC is received from computer 3860 by server 3812 (step 4102). Authentication server 3812 then retrieves the public key identified by account number 3916 from account database 3814 (step 4104). Using this public key, authentication server 3812 attempts to authenticate the message (step 4106). If the message does not authenticate (in step 4108), server 3812 responds by rejecting the message (ie, denying access to secure server 3892) (step 4110). Such a response may indicate a reason for refusal. If the message authenticates (in step 4108), the authentication server 3812 concludes that the message actually came from an individual who owns the correct electronic key 3850 associated with the identified account number 3916 (ie, factor A). Entity authentication is obtained). Authentication server 3812 then determines whether the factor B entity credentials or state (eg PIN) provided is sufficient to further process a particular message (step 4112). If not sufficient, the authentication server 3812 responds to the rejection of the message (step 4110), and again, such a response may indicate a reason for the rejection. If entity authentication is sufficient (in step 4112), the authentication server 3812 further processes the message (step 4114). In this case, further processing involves the individual determination as to whether the computer programmer 3802 has any rights or permissions associated with the requested program or file. If not, the authentication server 3812 responds with a rejection of the message (step 4110), and again, such a response may indicate a reason for the rejection. Computer Programmer 3802 has any rights or rights regarding the requested program or file

【0167】

(x. Secure Area Authentication Account) A tenth business application 4200 that implements the two-party ABDS system 200 in Figure 2 is shown in Figure 42. In this example, the account holder 4202, which includes the employee, owns the device in the form of an electronic key 4250. The device is designed to interface with the electronic lock 4252. This electronic lock 4252 is connected to the appropriate port on control server 4292 via cable 4265. The electronic lock 4252 is further associated with the alphanumeric keypad 4254 for input, for example, for PIN input, if necessary or desired. The electronic key 4250 secures the private key of the public-private key pair. The control server 4292 electrically controls the locking and unlocking mechanism 4263 associated with the safety door 4262 to the building 4260 via line 4267. Electronic key 4250 is associated with a secure area authentication account maintained by the account authority represented by security account manager 4212 operated by employee (not shown) of employee 4202. Each time Employee 4202 wants to access the building (or any other secure area not shown in this example), Employee 4202 is authenticated by Security Account Manager 4212 for access to the originally requested area. And need to be allowed. This security account manager 4212 communicates with the control server over line 4269.

【0168】

Accounts maintained by Security Account Manager 4212 are associated with account records maintained in one or more account databases, aggregated and referenced by account database 4214 and shown in Figure 42. Referring to FIG. 43, each authorized user identified in the account database 4214 is identified by a unique account identifier with account number 4316. Each account number 4316 identifies in the account database 4214 account information 4340, including employee-specific information 4342, a secure space or area 4344, and access request 4346 associated with each secure space. To do. According to the present invention, the account number 4316 further identifies the public key information 4318. This public key information 4318 includes at least the public key of the user of each account. Further, by the function of the present invention, the account number 4316 identifies the device profile information 4370 for the device holding the private key corresponding to the public key associated with the account.

【0169】

In the example in Figure 42, employee-specific information 4342 includes, for example, name, email address, department, administrator name, project (s) assignment, building location, room location, computer serial. Includes numbers and more. A list of secured spaces or areas 4344 are, for example, parking lots, entrances to major buildings, floors 1-6, floors 7-10, rooms 610, other safe rooms, and other non-specific but safe Includes areas marked with. The list of access requests 4346 identifies what "type" of entity authentication is required to access the corresponding secure space 4344. (For example, none-means that even a digital signature does not authorize access to the corresponding space; device-means that the presentation of the digital signature by the device is sufficient for access; device + PIN-means that the addition of the digital signature from the device and the correct PIN is required for access to the corresponding space; device + BIO-with the digital signature from the device and sufficient biometric specimens. It means that the addition is required for access to the corresponding space; Device + PIN + BIO-means that the addition of a digital signature from the device with the correct PIN and sufficient biometric specimens is required for access to the corresponding space). An additional business rule implemented by Security Account Manager 4212 determines how strong entity authentication really must be to grant access to the requested area in Ring 4260 in the building. The public key information 4318 of the account of employee 4202 includes the public key corresponding to the private key held in the electronic key 4250. The device profile information 4370 includes information specific to the electronic key 4250. In this context, the message from employee 4202 includes providing instructions to account (employee) number 4316 and security account manager 4212 for the relevant account, eg, access to the identified space or area 4344. ..

【0170】

In this business application, the EC from Employee 4202 to Security Account Manager 4212 is generally only for the purpose of transaction authentication (ie, to gain access to the requested secure area or resource). Used. For this reason, in general, only the messages required for employee 4202 to communicate with Security Account Manager 4212 will include the account number 4316 for the associated account. Instruction (i1) (ie, "give me access to the area protected by this lock 4252''") is implied in the mere communication of the EC, including account number 4316.

【0171】

As shown in Figure 44, transaction authentication is initiated when employee 4202 attempts to access a secure space or area, such as the entrance 4262 of the main building of the main building 4260 (step 4402). .. This occurs when field employee 4202 physically inserts the electronic key 4250 into the electronic lock 4252 (this particular lock 4252 is not of the "non-contact" type, but of the "contact" type. Because it is a thing). Control server 4292 uses an audible message output from a speaker (not shown) near safety door 4262 to enter employee 4202 and a PIN into keypad 4254 for factor B entity authentication purposes. Instruct to enter the PIN for (step 4404). With the key 4250 inserted and after the PIN is entered, the electronic message is configured to be sent to server 4212 (via control server 4292) for authentication and authorization for access to the main building 4260. Is done (step 4406). The message is composed, for example, by control server 4292. This control server 4292 retrieves account number 4316 from key 4250 and combines it with the name (or computer identification number) of the secure door 4262 that employee 4202 is typing to enter. Preferably, the control server 4292 also includes a unique session key in the message to prevent the possibility of a "replay attack" (ie, reuse of the previous digital signature created from the key 4250).

【0172】

The message configured by control server 4292 is then back-transmitted to key 4250 over cable 4265 for the creation of a digital signature (step 4408). Once the message is received by key 4250, it first calculates the hash value for the data and then encrypts the hash value with the private key held in key 4250 for the message. Create a digital signature (step 4410). Key 4250 then outputs the digital signature to lock 4252 (step 4412). This lock 4252 transfers the same thing to the control server 4292. Control server 4292 then transmits the message and digital signature over EC to security account manager 4212 (step 4414).

【0173】

Referring to FIG. 45, the EC is received from control server 4292 by security account manager 4212 (step 4502). Security Account Manager 4212 then retrieves the public key identified by account number 4316 from the account database 4214 (step 4504). With this public key, security account manager 4212 attempts to authenticate the message (step 4506). If the message does not authenticate (in step 4508), security account manager 4212 responds with a message denial (ie, denial of granting access to building 4260) (step 4510). Such a response may indicate a reason for refusal. If the message authenticates (in step 4508), security account manager 4212 concludes that the message actually came from an individual who owns the correct electronic key 4250 associated with the identified account number 4316. (That is, factor A entity authentication is obtained). Security Account Manager 4212 then provided Factor B entity authentication (eg PIN) based on the type of entity authentication requested for a particular door 4262, and based on the business rules mentioned above. Determine if it is sufficient to process a particular message further (step 4512). If not sufficient, the security account manager 4212 responds with a rejection of the message (step 4510), and again, such a response may indicate a reason for the rejection. If entity authentication is sufficient (in step 4512), security account manager 4212 further processes the message (step 4514).

【0174】

In this case, further processing involves an individual decision as to whether employee 4202 has any right or permission to gain access to the requested, secure area through the secure door 4262. .. If not (even if employee 4202 is provided with sufficient entity authentication), security account manager 4212 responds with a message denial (ie, denial of granting access to the requested area). Then (step 4510), and again, such a response may indicate a reason for rejection. If Employee 4202 has the right or permission to enter the requested area, Security Account Manager 4212 will provide Employee 4202 with access to the requested area. More specifically, security account manager 4212 sends the appropriate signal to control server 4292. The control server 4292 then sends a signal over line 4267 to unlock and / or open the front door 4262.

【0175】

(xi. Electronic data interchange by multiple buyer agents) Figure 46 shows the eleventh business application 4600 that implements the two-party ABDS system in Figure 2. In this example, the two account holders, including the buyer agents 4602a and 4602b, own devices in the form of cards 4650a and 4650b, such as IC cards, respectively. The cards 4650a and 4650b can be used for card readers 4652a and 4652b. Each card 4650a, 4650b secures the private key of the public-private key pair. In this example, the card readers 4652a, 4652b are connected to the appropriate ports (USB, serial, parallel, etc.) of the personal computers 4660a, 4660b via cables 4665a, 4665b. Both personal computers 4660a and 4660b are conventional in that they include monitors 4662a, 4662b, keyboards 4664a, 4664b and mice 4666a, 4666b, respectively. Both cards 4650a, 4650b are tied to a joint purchase account maintained by the account authority represented by supplier 4612. Both computers 4660a, 4660b are suitable to allow them to communicate over the Internet 4608 to the website hosted by the supplier 4612, in the traditional way, such as via a modem, LAN line, etc. Install on your web browser software.

【0176】

Accounts maintained at supplier 4612 are tied to account records maintained in one or more account databases, aggregated and referenced by account database 4614 and shown in Figure 46. Referring to FIG. 47, each account contains a unique account identifier, including account number 4716. Each account number 4716 identifies in the account database 4614 account information 4740, including account-specific information 4742 and buyer agent-specific information 4744. According to the present invention, the account number 4716 further identifies the public key information 4718. This public key information 4718 includes at least one public key for each buyer's agent for each account. Further, by the function of the present invention, the account number 4716 identifies the device profile information 4770 for each device holding the private key corresponding to the public key associated with the account.

【0177】

In the example in Figure 46, account-specific information 4742 includes, for example, company name, major company contact, email address, billing address, billing information, and a list of authorized buyer agents for the account. .. Information specific to the buyer's agent 4744 includes, for example, the agent's name, the buyer's agent identification number, contact information about the buyer's agent, and in some cases purchase restrictions imposed by the company on the purchase agent, and more. The public key information 4718 of the company account includes each public key corresponding to the private key held on the cards 4650a, 4650b of each buyer's agent. The device profile information 4770 includes information specific to each card 4650a and 4650b. FIG. 46 shows only two buyer agents, while FIG. 47 shows the fact that more buyer agents (n) can be further tied to this particular company account.

【0178】

As previously mentioned, the EC from the buyer agents 4602a, 4602b to the supplier 4612 can be used for three different purposes. It is session authentication, transaction authentication, and transaction confirmation. For example, a common type of session authentication, in this business application, buyer agents 4602a, 4602b first attempt to log in or otherwise access a secure website operated by supplier 4612. Occurs when. Transaction confirmation is performed in this business application, for example, when buyer agents 4602a, 4602b request the purchase of a higher ticket item and / or when buyer agents 4602a, 4602b "confirm" and purchase an item. Applicable when you are ready to pay for the list. In such cases, the supplier 4612 digitally signs the request to the buyer agents 4602a, 4602b using the cards 4650a, 4650b (and, if possible, further provides additional entity credentials or status). ) To confirm such a request.

【0179】

Regardless of what type of EC is communicated from Buyer Agents 4602a, 4602b to Supplier 4612, to configure and digitally sign the message (on the purchasing agent side), and to authenticate the message and make the entity The basic methodology for certification (on the supplier side) is essentially the same. For example, referring here to FIG. 48, a transaction (in this case, session authentication) is accessed by one of the buyer agents 4602a, 4602b via the Internet 4608 using computers 4660a, 4660b, respectively, to the website of supplier 4612. Will be started if you want to (step 4802). For the rest of this example, it is assumed that this transaction is initiated and executed by the First Buyer Agent 4602a. First, the supplier web directs computer 4660a (step 4804) to have the buyer agent 4602a enter Factor B entity credentials such as a PIN on the login screen. Once the PIN is entered on the login screen, an electronic message is configured to be sent to supplier 4612 (step 4806).

【0180】

The message in this example is simply the account number 4716 tied to a joint account maintained by the supplier 4612 on behalf of the employees of both buyer agents 4602a, 4602b. Computer 4660a displays a menu of available accounts that Buyer Agent 4602a can select. Preferably, such available accounts are stored in memory on the card 4650a and retrieved by the computer 4660a for selection by the buyer agent 4602a. Of course, if only one account is available in memory on the card 4650a, that account will be selected by default without requiring a specific selection by the buyer's agent 4602a. Alternatively, the list of available accounts may be maintained in memory on the computer 4660a itself and displayed for selection by the buyer agent 4602a.

【0181】

Once the appropriate account number is selected, it is transmitted as a message from computer 4660a to card 4650a via cable 4665a for digital signature by buyer agent 4602a (step 4808). In this regard, upon receipt of the data representing the message, the card 4650a first calculates the hash value for the data and then encrypts the hash value with the private key held on the card 4650a. Create a digital signature for (step 4810). Card 4650a then outputs a digital signature (step 4812). This digital signature is received by computer 4660a. Computer 4660a then transmits the message and digital signature in EC to supplier 4812 (step 4814).

【0182】

Referring to FIG. 49, the EC is received from computer 4660a by supplier 4612 (step 4902). The supplier 4612 then retrieves all of the public keys identified by account number 4716 from the account database 4614 (step 4904). Using each of these public keys, supplier 4612 attempts to authenticate the message over time (step 4906). Alternatively, the message could actually explain the public key 4718 (or the appropriate buyer's agent ID that acts as a sub-account identifier) for the associated buyer's agent 4602a, so that the supplier 4612 is from database 4614. You don't have to "guess" which public key 4718 to use. However, supplier 4612 still needs to ensure that such public key 4718 corresponds to a particular account number 4716. If the message is not authenticated by any of the public keys associated with the identified account 4716 (in step 4908), the supplier 4612 may reject the message (ie, authorize access to the website for purchase). Respond to (Reject) (step 4910). Such a response may indicate a reason for refusal. Once the message is authenticated (step 4908), the supplier 4612 concludes that the message actually came from an individual who owns the correct card 4650a associated with the identified account number 4716 (ie, Factor A entity). Certification is obtained). The supplier 4612 then determines whether the Factor B entity credentials or status (eg, PIN) provided is sufficient to further process the particular message (step 4912). If not sufficient, supplier 4612 responds with a rejection of the message (step 4910), and again, such a response may indicate a reason for the rejection. If entity authentication is sufficient (in step 4912)

【0183】

In this case, further processing involves providing the Buyer Agent 4602a with access to a website for purchasing supplies on behalf of the employees of the Buyer Agent 4602a. Further processing of the Buyer Agent 4602a is based on the purchase restrictions imposed on the particular Buyer Agent 4602a as described in Purchase Limits from Buyer Agent Specific Information 4744 in the Account Database 4614. It also includes limiting the display (or selection for purchase) of items that are not within the purchase authority.

【0184】

Once on the website, if the Buyer Agent 4602a is allowed to freely maneuver the website (except as described above) and purchase on behalf of the employee, the supplier 4612 will provide the website. Additional entity authentication by Buyer Agent 4602a may be required using the above "high ticket" or card 4650a for a particular item. In such cases, the website preferably reverse-transmits the confirmation message to the computer 4660a for transmission to the card 4650a for the creation of a confirmation digital signature by the card 4650a. The process of creating such a digital signature is mirror-like with the procedure described above, providing the same state as before rejoining the Factor B entity credentials or creating a digital signature. Can include.

【0185】

(Specific implementation of i.3-party ABDS system) Similar to the 2-party ABDS system 200 in Figure 2, the 3-party ABDS system 300 in Figure 3 can be implemented in a huge number of business applications. The particular examples described herein therefore represent only sampling of such a wide range of possibilities.

【0186】

E-business transactions using financial institution accounts) The first business application 5000 that implements the three-party ABDS system 300 in Figure 3 is shown in Figure 50. In this example, the account holder, including buyer 5002, owns a device in the form of a card 5050, such as an IC card. This device can be used for a card reader 5052. Card 5050 secures the private key of the public-private key pair. In this example, the card reader 5052 is connected to the appropriate port (USB, serial, parallel, etc.) of the personal computer 5060 via cable 5065. The personal computer 5060 is conventional in that it includes a monitor 5062, a keyboard 5064, and a mouse 5066. The card 5050 is associated with a debit or credit account maintained by the account authority, including the financial institution 5012, among other accounts. The account can be a checking deposit, a savings account, a money market account, a credit card account or the like, and the financial institution 5012 can be a bank, a savings loan, a credit card company or the like. Computer 5060 is a financial institution that installs appropriate web browser software to allow intermediaries, including online seller 5010, to communicate over the Internet 5008 in traditional ways, such as via modems, LAN lines, etc. Accounts maintained at 5012 are associated with account records maintained in one or more account databases, aggregated and referenced by account database 5014 and shown in Figure 50. Referring to FIG. 51, each account contains a unique account identifier, including account number 5116. Each account number 5116 identifies in the account database 5014 account information 5140, including customer-specific information 5142 and account-specific information 5144. According to the present invention, the account number 5116 also knows the public key information 5118. Separate. This public key information 5118 includes at least one public key of the account holder of each account. Further, by the function of the present invention, the account number 5116 identifies the device profile information 5170 for the device holding the private key corresponding to the public key associated with the account.

【0187】

In the example of FIG. 50, the customer-specific information 5142 includes, for example, the name, address, social security number and / or tax identification number of the account holder. Account-specific information 5144 includes, for example, the current account balance, available credits, the difference between closing data and the current statement, and the associated account identifier. The public key information 5118 of the buyer 5002's account contains the public key corresponding to the private key held in the card 5050. Device profile information 5170 contains information specific to card 5050.

【0188】

With particular reference to Figure 52, Buyer 5002 initiates a transaction with Online Seller 5010 by accessing the Website of Online Seller 5010 using web browsing software installed on Computer 5060 in the traditional manner ( Step 5202). While viewing the website on computer 5060, buyer 5002 orders from online seller 5010 by selecting books to purchase goods such as books in the traditional way on the website (step 5206). .. Preferably, the buyer 5002 enters the factor B or C entity credentials into the computer 5060 (in step 5204) when the card 5050 is inserted into the card reader 5052, as before. If the card 5050 was not inserted into the card reader 5052 as before, the computer 5060 instructs the buyer 5002 to do so and enter the relevant participation credentials (step 5204).

【0189】

The step of generating the message (step 5208) is digitally signed and occurs as follows. As part of the ordering process, the website displays a payment selection screen to buyer 5002 on monitor 5062. The payment selection screen preferably identifies the goods to be ordered and includes the price and shipping and handling of the goods. Buyer 5002 traditionally uses the requested data participation area and mark selection from the on-screen pull-down menu on monitor 5062 to identify the payment method (ie, account number 5116 and account type). Such areas / menus can be completed automatically by computer 5060 using the information stored in "cookies" in a known manner). In general, the financial industry has identified itself from the use of account number 5116 (eg, Issuer Identification Number (IIN) as defined as ISO Standard 7812 (which is incorporated herein by reference)). It is not necessary to identify the name of financial institution 5012, as it follows the conventions that can be drawn. Other payment information does not need to be entered in the payment selection screen. Rather, it is necessary to present the information to the online seller 5010 in an encrypted format, for example, Security Sockets Section (SSL). This security socket policy (SSL) is conventional, and the buyer 5002 simply requests the option to "digitally sign" the order in the "ABDS method" (on the payment method screen). In response to this selection, computer 5060 uses the information displayed and / or entered on the payment selection screen (s) by the buyer 5002 to generate a message.

【0190】

This message is then transmitted from computer 5060 to card 5050 via cable 5065 for digital signature by buyer 5002 (step 5210). In this regard, upon receiving the data representing the message, the card 5050 first calculates the hash value for the data and then encrypts the hash value with the private key held on the card 5050 for the message. Create a digital signature (step 5212). Card 5050 then outputs a digital signature (step 5214). This digital signature is received by computer 5060. Computer 5060 then transmits the message and digital signature over EC to the online seller 5010 (step 5216).

【0191】

In this particular example, the instruction (i2) from the buyer 5002 to the online seller 5010 includes the buyer's order for the goods using the account 5116 specified in the payment method and message. Delivery to the address is optionally provided by Buyer 5002. Therefore, part of the instruction (i2) may be included in the electronic communication prior to the EC containing the message and digital signature, and an additional part of the instruction (i2) may be included in the EC containing the message and digital signature. .. On the other hand, the message from buyer 5002 is ultimately intended for financial institution 5012, with account number 5116 and finance for a particular account in order to make payments from account 5116 in the identified account to online seller 5010. Includes order (i1) to agency 5012.

【0192】

Unlike the two-party ABDS system 200, ECs containing messages and digital signatures (in this case used for transaction authentication purposes) are not sent directly to financial institution 5012, but to online seller 5010. As shown in Figure 53, the online seller 5010 receives the EC from the buyer 5002 (step 5302) and any additional instructions from the buyer 5002 to the online seller 5010 contained in the EC, including messages and digital signatures (step 5302). Extract i2) (step 5304). The online seller 5010 then forwards the EC, including the message and digital signature, to the financial institution 5012 for payment verification and authorization (step 5306). While waiting for a response from financial institution 5012, online seller 5010 then issues these orders (i2) (ie, purchase requests) to the "on hold" hold approval of payments from financial institution 5012. Position (step 5308).

【0193】

With reference to Figure 54, the EC is received from the online seller 5010 by the financial institution 5012 (step 5402). The financial institution 5012 then retrieves the public key identified by account number 5116 from the account database 5014 (step 5404). Using this public key, financial institution 5012 attempts to authenticate the message (step 5406). If the message does not authenticate (in step 5408), the financial institution 5012 responds to the online seller 5010 with a rejection of the message (step 5410). Such a response may indicate a reason for refusal. If the message authenticates (in step 5408), the financial institution 5012 concludes that the message actually came from the individual who owns the correct card 5050 associated with the identified account number 5116 (ie, the Factor A entity). Certification is obtained). The financial institution 5012 then determines whether the factor B or C entity credentials or state provided is sufficient to further process the particular message (step 5412). If not sufficient, financial institution 5012 responds with a rejection of the message (step 5410), and again, such a response may provide a reason for the rejection. If entity authentication is sufficient (in step 5412), financial institution 5012 proceeds with further processing of the message (described below).

【0194】

In the example of the present invention, further processing of the message includes determining whether the instruction (i1) can be performed (step 5414). For example, even if the message is authenticated, the buyer may not have enough money or credits tied to an account that the financial institution 5012 allows to trade. Therefore, making such a decision usually involves accessing the relevant part (s) of the account record and ensuring that the funds are available. If the decision (in step 5414) is negative, the financial institution 5012 responds to the online seller 5010 with a rejection of the message (step 5410). Again, such a response may provide a reason for refusal. If the decision in step 5414 is authoritative, financial institution 5012 implements order (i1) (step 5416). In this example, the order (i1) from the buyer 5002 is to pay the online seller 5010 a certain amount of money from the account for the purchase of the goods. Therefore, implementing the order (step 5416) usually involves accessing the relevant part (s) of the account record, initiating the transmission of a certain amount of funds from the Buyer 5002 account to the Online Seller 5010. , And automatically debit / update account records. (It should be noted that the steps of transmitting funds and crediting the account may not occur at the same time as the other steps.) The financial institution 5012 also grants a message to the online seller 5010 and Notify the start of payment (step 5418).

【0195】

Again, referring to Figure 53, once the online seller 5010 receives a response from the financial institution 5012, the decision in step 5310 is positive. The online seller 5010 then determines whether the response is a permit or rejection of the transaction (step 5312). If the transaction is not permitted by financial institution 5012, the online seller 5010 will reject the message to buyer 5002 (ie, payment is not permitted) and the order (i2) will not be executed (ie, the goods due to payment refusal). Will not be shipped) (step 5314). On the other hand, if the decision in step 5312 is positive, the online buyer 5010 executes the previously awaited instruction (i2) (step 5316). In this case, the online seller 5010 begins shipping the goods purchased by the buyer 5002. The online seller 5010 then allows the buyer 5002 to trade (ie, pay) and the order (i2) has been or has already been executed (ie, the goods have been shipped to the requested address). Notify (step 5318).

【0196】

Digital gift check using financial institution account) A second business application 5500 that implements the three-party ABDS system 300 in Figure 3 is shown in Figure 55. In this example, the account holder includes the gift giver 5502. This gift giver 5502 owns a device in the form of a personal digital assistant (PDA) 5550. The PDA5550 secures the private key of the public-private key pair. The PDA5550 includes a two-way display screen 5552 and a user input key 5556. In addition, the PDA5550 is adequately equipped with a wireless modem for digital communication over the wireless communication network 5508. The PDA5550 is associated with a debit or credit account maintained by an account authority that includes a gift clearinghouse or gift processor 5512. The account can be a checking deposit, a savings account, a money market account, a credit card account, etc., and the gift processor 5512 can be a bank, savings loan, credit card company or other financial institution, or a digital check or financial gift. It can be a company or business unit specially set up for the purpose of allowing it to be transmitted electronically within the ABDS system. The PDA5550 installs the appropriate software to allow the traditional method to generate an email and transmit it over the network 5508 to the gift recipient 5510. The gift receiving side 5510 has a computer 5590. The computer 5590 is capable of receiving and forwarding emails received, for example, over the network 5508 and / or the Internet 5511. Alternatively, the PDA5550 is specially provided by the Gift Processor 5512 for the purposes of configuring, generating, and transmitting such emails (or other electronic communications readable or standard web software by email). Install the software

【0197】

Accounts maintained on the Gift Processor 5512 are associated with account records maintained in one or more account databases, aggregated and referenced by account database 5514 and shown in Figure 55. Referring to FIG. 56, each account contains a unique account identifier, including account number 5616. Each account number 5616 identifies in the account database 5514 account information 5640, including customer-specific information 5642 and account-specific information 5644. According to the present invention, the account number 5616 further identifies the public key information 5618. This public key information 5618 contains at least one public key of the account holder for each account. Further, by the function of the present invention, the account number 5616 identifies the device profile information 5670 for the device holding the private key corresponding to the public key associated with the account.

【0198】

In the example of FIG. 55, the customer-specific information 5642 includes, for example, the account holder's name, address, social security number and / or tax identification number. Account-specific information 5644 includes, for example, current account balances, available credits, current account holder statements, and payment account alternatives. The public key information 5618 for the gift giver 5502 account contains the public key that corresponds to the private key held by the PDA5550. Device profile information 5670 contains information specific to PDA5550.

【0199】

Especially with respect to FIG. 57, buyer 5002 sends a digital check or monetary gift to the gift recipient 5510 by launching the appropriate email or gift software (provided by the gift processor 5512) on the PDA5550 (step 5702). Start giving. If factor B or C entity credentials, such as PIN or biometric information, have not yet been entered into the PDA5550 by the gift giver 5502, the PDA5550 now instructs the gift giver 5502 to do so (step 5704). ).

【0200】

Once such Factor B or C entity credentials are entered, the gift giver 5502 generates a message (step 5706). This is done either by configuring email or by configuring an appropriate "digital check" with pre-installed software. Nevertheless, the message should include the following information: The name and email address of the gift recipient 5510, the amount of gift, and the account number 5616 of the account from which the gift will be withdrawn. If the gift giver 5502 uses a standard email program, the configured message must include the appropriate email address or web address for the gift processor 5512. As a result, the gift recipient 5510 knows where to go to get an electronic gift or digital check. If the gift giver 5502 uses pre-installed software from the gift processor 5512, such software will provide such appropriate contact information to the gift processor 5512 after the gift giver 5502 configures it. Automatically add to the message. Once such a message is completed, the gift giver 5502 digitally signs the message using the PFA5550. The PDA5550 first calculates the hash value for the data and then the private key held in the PDA5550. Create a digital signature on the message by encrypting the hash value with. (Step 5708). The PDA5550 then puts digital signatures and messages out of the email program. Output to "box)" (step 5710). The PDA5550 establishes a wireless connection with an email service provider over network 5508 and uses the email address for the gift recipient 5510 provided by the gift giver 5502 when generating the message, and the message in the EC and The digital signature is transmitted in the form of an email to the gift recipient 5510 (step 5712).

【0201】

As shown in FIG. 58, the gift receiver 5510 uses the standard email software that the gift receiver 5510 has on the computer 5590 to message and digitally sign (again, in this case, for transaction authentication purposes). Receive an EC containing) (step 5802). Upon receipt of the EC, the Gift Recipient 5510 uses the identified email or the web address contained in the EC to forward the EC, including a message to the Gift Processor 5512 and a digital signature, for authentication and payment. Only that is needed (step 5804). Perhaps such email from the gift recipient 5510 to the gift processor 5512 is transmitted over the Internet 5511 or other traditional communication network. The Gift Recipient 5510 then only waits for instructions from the Gift Processor 5512 about how to get the gift or for notification that the gift has been saved to the Gift Recipient 5510's account. The placement between the gift receiver 5510 and the gift processor 5512 may already be an alternative to such savings.

【0202】

Referring to FIG. 59, the EC is received by the gift processor 5512 from the gift receiving side 5510 (step 5902). The gift processor 5512 then retrieves the public key identified by account number 5616 from the account database 5514 (step 5904). Using this public key, the gift processor 5512 attempts to authenticate the message (step 5906). If the message does not authenticate (in step 5908), the gift processor 5512 responds to the gift recipient 5510 with a rejection of the message (step 5910). Such a response may indicate a reason for refusal. If the message authenticates (in step 5908), the gift processor 5512 concludes that the message actually came from the individual who owns the correct PDA5550 associated with the identified account number 5616. (Ie, factor A entity authentication is obtained.) The gift processor 5512 then determines whether the factor B or C entity credentials or the provided state is sufficient to further process a particular message. (Step 5912). If not sufficient, the gift processor 5512 responds to the rejection of the message (step 5910), and again, if desired, such a response may indicate a reason for the rejection. If the Factor B or C entity credentials or state are sufficient (in step 5912), the gift processor 5512 proceeds with further processing of the message (discussed below).

【0203】

In the example of the present invention, further processing the message involves determining whether the instruction (i1) can be performed (step 5914). For example, even if the message is authenticated, the gift giver 5502 may not have enough money or credits tied to the account for the gift processor 5512 to authorize the transaction. For this reason, making such a decision typically involves accessing the relevant part (s) of the account record and ensuring that the funds are available. If the decision (in step 5914) is negative, the gift processor 5512 responds to the gift recipient 5510 with a rejection of the message (step 5910). Again, such a response may provide a reason for refusal. If the decision in step 5914 is positive, the gift processor 5512 executes instruction (i1) (step 5916). In this example, the order (i1) from the gift giver 5502 is to pay the gift recipient 5510 a certain amount of money from the account as a gift or, in some cases, a donation. For this reason, enforcing the order (step 5916) usually involves accessing the relevant part (s) of the account record and conditionally crediting a certain amount of funds from the gift giver 5502 account. And thereby updating the account record. The gift processor 5512 then notifies the gift recipient 5510 of the permission of the message (step 5918) and, if necessary, provides the gift receiver 5510 with an instruction to obtain the amount of money for the gift.

【0204】

Seeing Figure 58 again, the gift receiver 5510 then responds from the gift processor 5512, which still has an account setup where the gift receiver 5510 has the gift processor 5512 to receive such a gift amount. Receive an instruction to get a gift if not (step 5806).

【0205】

(iii. Points of sales transactions using financial institution accounts) The third business application 6000 that implements the three-party ABDS system 300 in Fig. 3 is shown in Fig. 60. In this example, the account holder, including the buyer 6002, owns a device in the form of a card 6050, such as an IC card. This device can be used at points of sale. Points for the sale card reader 6052 include an alphanumeric keypad 6056, a display 6054, and in this case a thumbprint reader 6058. The point of the sales card reader 6052 communicates with the seller cash register / terminal 6060 via the data connector 6064. The seller cash register / terminal 6060 has its own display 6062. The point of the sales card reader 6052 also communicates with the standard financial network 6008. This standard financial network 6008 has the ability to communicate and properly route communications between the seller and the various financial institutions represented by, in this example, financial institutions 6012, 6022, 6032. The financial institutions 6012, 6022, 6032 are, for example, banks, savings and loan associations, credit card companies and others. Accounts maintained at financial institutions 6012, 6022, 6032 are associated with account records maintained in one or more account databases, collectively referenced by account databases 6014, 6024, 6034, respectively, as shown in Figure 60. In this example, financial institution 6012 maintains a banking or credit card account on behalf of an authorized user of card 6050. In this example, it is further assumed that card 6050 is tied to the account of an authorized user of card 6050 in the account database 6014.

【0206】

Referring to FIG. 61, each account in database 6014 contains a unique account identifier that includes account number 6116. Each account number 6116 identifies in the account database 6014 account information 6140, including customer-specific information 6142 and account-specific information 6144. According to the present invention, the account number 6116 further identifies the public key information 6118. This public key information 6118 includes at least one public key of the account holder for each account. Further, by the function of the present invention, the account number 6116 identifies the device profile information 6170 for the device holding the private key corresponding to the public key associated with the account.

【0207】

In the example of FIG. 60, the customer-specific information 6142 includes, for example, the name, address, social security number and / or tax identification number of each account holder. Account-specific information 6144 includes, for example, the current account balance, available credits, the difference between closing data and the current statement, and the associated account identifier. The public key information 6118 of the buyer 6002's account contains the public key corresponding to the private key held on the card 6050. Device profile information 6170 includes information specific to card 6060.

【0208】

In particular with reference to FIG. 62, the buyer 6002 initiates a transaction with the seller if the buyer 6002 requires the seller's cash register / terminal 6060 to pay the item (step 6202). The seller "rings up" the item on the seller's cash register / terminal 6060 (step 6204). The total shortfall is then shown on the display 6062 to the buyer 6002. To pay, buyer 6002 inserts card 6050 into points on the sale card reader 6052 (or both card reader 6052 and card 6052 are ISO / IFC standard 14443, which is incorporated herein by reference. ), Bring the card 6050 close to the card reader 6052) (step 6206). Upon insertion (or approach), the points of the sales card reader 6052 are started (step 6208), which provides, at a minimum, the power from the points of the sales card reader 6052 to the card 6050.

【0209】

The seller's loan register / terminal 6060 then transmits the balance through the data connector 6064 by having a sales card reader 6052 points (step 6210). The point of the sales card reader 6052 is to display the deduction charge amount on the display 6054 (step 6212). Preferably, point 6052 on the sales card reader 6052 retrieves a list of all available (or at least two or five major) payment accounts maintained in memory on the card 6050 (step 6214). Then display them for selection by buyer 6002 (step 6216). If there is one or more accounts to select, then the buyer 6002 will have more than one of the listed accounts (or if the purchase volume is separated between one or more accounts). Account) (step 6218). Display 6054 facilitates buyer 6002 (step 6220) to provide factor B and C entity credentials such as PIN and right thumb fingerprint using the alphanumeric keypad 6056 and scanner 6058 for thumb fingerprints. -But only if you accept the proposed transaction (including the purchase and usage of the selected account (s) for payment). Once the PIN and thumbprint are entered, the point of the sales card reader 6052 transmits the digital version of the PIN and thumbprint to the card 6050 (step 6222). The card reader 6052 then transmits data representing the message to the card 6050 for digital signature (step 6224).

【0210】

In this regard, upon receiving the data representing the message, the card 6050 first calculates the hash value for the data and then encrypts the hash value with the private key held in the card 6050 for the message. Generate a digital signature (step 6226). Card 6050 then outputs a digital signature (step 6228). The digital signature is received by points on the sales card reader 6052. The point of the sales card reader 6052 is to transmit the message and digital signature in the EC to the financial institution 6012 (via the financial network 6008) (step 6230) and wait for a response from the financial institution 6012 (step 6232). In this case, EC is used for transaction authentication.

【0211】

With reference to Figure 63, after the financial network 6008 has correctly routed the EC, the EC is received by the financial institution 6012 from the point of the sales card reader 6052 (step 6302). The financial institution 6012 then retrieves the public key identified by account number 6116 from the account database 6014 (step 6304). Using the public key, financial institution 6012 attempts to authenticate the message (step 6306). If the message does not authenticate (in step 6308), the financial institution 6012 rejects the message and responds to the seller (via points on the financial network 6008 and the sales card reader 6052) (step 6310). Such a response includes a reason for refusal. If the message authenticates (in step 6308), the financial institution 6012 concludes that the message actually comes from the person who owns the correct card 6050 associated with the identified account number 6116-(ie, Factor A entity). Certification is obtained). The financial institution 6012 then determines whether the provided Factor B and C entity credentials (eg, PIN and thumb fingerprint) are sufficient to further possess a particular message. If not sufficient, financial institution 6012 responds to the seller (via financial network 6008 and points on the sales card) with a message of refusal (step 6310). Such a response may include a reason for refusal, if desired. If entity authentication is sufficient (in step 6312), financial institution 6012 proceeds with further processing of the message (described below).

【0212】

In this example, a further step in processing the message involves determining whether instruction (i1) can be executed. If it is not possible to execute order (i1), financial institution 6012 responds to the rejection of the message (step 6310). For example, even if the message is authenticated, the buyer 6050 may not have sufficient money or loans associated with the account for the financial institution 6012 to approve the transaction. Thus, the steps of making such a determination typically include accessing the relevant portion (s) of the account record and ensuring that the funds are available. If the verdict is negative (in step 6314), the financial institution 6012 rejects the message (via points on the financial network 6008 and the sales card reader 6052) and responds to the seller (step 6310). Again, such a response may indicate a reason for refusal. If the verdict is positive in step 6314, financial institution 6012 implements order (i1) (step 6316). In this example, the order (i1) from the buyer 6002 is to pay the seller a certain amount of money from a particular account to purchase the goods. Therefore, the step of executing the order (step 6316) typically involves accessing the relevant part (s) of the account record and identifying (in a known manner) the funds from the buyer's account to the seller. Includes steps to initialize the volume transfer and debit / update account records accordingly. (As previously mentioned in the application of business, the step of processing the above order does not necessarily occur at the same time as the other steps mentioned herein.) Financial Institution 6012 also (Financial Network 6008). And notify the seller of the approval of the transaction (via the point of sale or card reader 6052) (step 6318).

【0213】

Returning to FIG. 62, once the seller receives the response from financial institution 6012, the decision in step 6232 is positive. The seller then determines if the response is an approval or rejection of the transaction (step 6234). The seller then notifies the buyer 6002 that the transaction has not been approved (step 6236). On the other hand, if the determination in step 6234 is positive, the seller completes the sale by giving the buyer the goods and receipt.

【0214】

As can be seen from the above example, the EC from the buyer 6002 has many "hands" (via the financial network 6008), even before actually reaching the financial institution 6012 for processing and certification. Acts as transaction authorization for the requested purchase and payment methods that pass through.

【0215】

2. "Person-Centric Device" The second aspect of the invention incorporates the ABDS system of the first aspect of the invention, plus having multiple accounts instead of one. Includes account holder device public key (PuK) associations. In addition, some accounts within multiple accounts can be maintained by the same account authority (shown by the third potential setup described with Figure 2a). Some accounts may be maintained by another account authority. It is referred to herein as a "person-centric device" because the same device is associated with multiple accounts and is not representative of any one account, but rather of an account holder such as a device.

【0216】

People-centric devices allow account holders to register a single device for use with multiple accounts, eliminating the need to have multiple credit cards such as IC cards and ID cards. It will be clear soon. For example, people-centric devices include one or more bank accounts, credit card accounts, frequent flight passenger accounts, frequent dining out accounts, gas card accounts, phone card accounts, building ID accounts. , Can be related to parking accounts, etc.

【0217】

When used, a human-centric device creates a digital signature for a device-like message described with respect to the first aspect of the invention. Specifically, a human-centric device generates a digital signature by encrypting the hash value of a message with a private key held by the human-centric device. Also, in some embodiments of the device, the human-centric device calculates the hash value of the message by applying an appropriate hashing algorithm. Moreover, in some embodiments, the human-centered device also constitutes a message.

【0218】

The message itself is the same as described for the first aspect of the invention. That is, the message contains an account-equivalent instruction and a unique identifier. However, in ABDS systems that utilize people-centric devices, the unique message of a particular message must correspond to the account maintained by the account authority that receives the message. To secure the delivery of electronic communications over intermediate communications to the appropriate account authority, electronic communications are sent via a closed communication medium dedicated to a particular account authority. If the communication medium is an open network such as the Internet, the electronic communication must contain sufficient information to identify the account authority that needs to receive the electronic communication to authenticate and approve the message. is there. Identification of the proper account authority can be achieved in many different ways. For example, the account number itself can provide any intermediate or routing entity with sufficient information, recognizing which account authority should receive electronic communications. In another example, such information may be entered directly into the message by the account holder during message composition, by a device or I / O support element during message composition, or as a location for the transmission of electronic communications. ..

【0219】

(a. Two-way ABDS system with human-centered devices) Here, with reference to FIG. 64, a first preferred implementation of the ABDS 6400 utilizing the "general" human-centered device 6450 is shown. The human-centered device 6450 is similar and identical to any device previously described with respect to the first aspect of the invention. Therefore, the human-centric device 6450 secures the private key of the public / private key pair inside. In addition, the human-centric device 6450 can communicate via the communication medium 6408. The communication medium 6408 includes the Internet and any previously described device communicates in the same manner.

【0220】

The ABDS system 6400 also includes device users who become account holders 6402 once at least one account has been established with one of the account authorities 6412, 6422, 6432. Each account authority 6412, 6422, 6432 maintains one or more account databases, collectively relating to FIG. 64, the first of the invention shown in FIG. 64 by account databases 6414, 6424, 6434. With respect to aspects, each of these account databases 6414, 6424, 6434 maintains account holder records, which are indexed by unique identifiers, preferably represented by unique account numbers.

【0221】

In this figure, account holder 6402 establishes an account with account authority 6412. This account has a unique identifier specified by "acctID (a)". Account Holder 6402 also establishes an account with Account Authority 6422. This account has a unique identifier specified by "acctID (b)". In addition, account holder 6402 establishes two accounts with account authority 6432. One account has a unique identifier specified by "acctID (c1)" and the other account has a unique identifier specified by "acctID (c2)". Even if the account holder 6402 has four different accounts with three different account authorities, each of the account database records has the same public key (PuK) in them as shown in Figures 64a, b, c. Including. The process (which causes account holder 6402 to register the person-centric device 6450), and, on the other hand, the public key of the person-centric device 6450 with account authorities 6412, 6422, 6432, respectively. It is comparable to the registration process described for the aspect.

【0222】

The process (which causes the account holder 6402 to communicate directly with any one of the account authorities 6412, 6422, 6432) is also any one of the processes described for the two-party ABDS system 200 in Figure 2. One and any of the ABDS business applications are the same as or similar to the two specific parties described in Figures 6-49. For example, as shown in Figure 65, the account holder 6402 with any particular one of the account authorities 6412, 6422, 6432 by establishing an electronic connection with the desired account holder (step 6502). Initialize the communication of. The account holder 6402 then enters the entity credentials (eg, the PIN, password, passphrase, or biometric information associated with the device 6451 into the device 6450) (step 6540). Account holder 6402 then generates a message (step 6506). If the device 6450 no longer generates, the message is imported / transmitted into the human-centric device 6450 (step 6508). This human-centric device 6450 first generates a digital signature on the message by computing the hash value for the data and then encrypting the hash value with the private key held within the device 6450 (step). 6510). In another and less preferred embodiment, the hash value of the message is calculated outside the device and then provided to the device solely for the purpose of encrypting such hash value for digital signatures. The device 6450 then outputs a digital signature from the device's digital signature component (step 6512). Therefore, the message and digital signature are transmitted to the appropriate account authority (step 6514).

【0223】

The exact process of generating a message, and the process of generating a digital signature for a message, is a particular form of human-centric device 6450 and a special environment (used in this environment (eg, with an I / O aid element)). ), Please note that it changes. For example, if the person-centric device 6450 is a mobile phone or PDA, the message and the hash value of the message are preferably generated and calculated directly on the person-centric device 6450, respectively, and then digitally signed. .. When the human-centric device 6450 is a dongle, an electronic key used in combination with an electronic lock, or a card used in combination with a card reader, all of which are preferably used in conjunction with the account holder's computer. Then, the message is generated or received on this computer. The hash value is either generated by the computer and transmitted to the human-centric device 6450, or after the human-centric device 6450 receives the message and generates the hash value itself, then The human-centric device 6450 generates a digital signature for a message. A human-centered device is a subcutaneous implant, a personal item, or a card that can be used in public interface settings (eg, ATM machines, card readers, RF receivers / transmitters, or sales reader locations). If the message and the hash value of the message are preferably generated out of the human-centric device 6450, the hash value is transmitted to the human-centric device 6450, and then the human-centric device 6450 digitally signs the message. To generate.

【0224】

Preferably, each account number (or associated unique account identifier) is stored in memory within the person-centric device 6450, regardless of the particular type of person-centric device 6450 used.

【0225】

Ultimately, the human-centric device 6450 sends electronic communication messages and digital signatures through the communication medium 6408 with or without assistance from I / O aid elements or other external devices to a particular account authority. To transmit to. With this account authority, the human-centric device 6450 has already established an electronic connection. Regardless of how the above message is generated, the message contains a unique account identifier and an instruction (i1) to be executed by the account authority. In addition, as long as the person-centric device 6450 is communicating with the account authority (which is the only account registered for the account associated with the private key), the unique account identifier will actually be public. The key itself. Thus, the public key can be used as a unique account identifier for two parties' direct communication between the account holder 6402 and the account authorities 6412 and 6422, but is unique for communication with the account authority 6432. Not available as an account identifier for. This account authority 6432 maintains two separate accounts for account holder 6402, both accounts associated with the same public key.

【0226】

The steps performed by Account Authority 6412, 6422, 6432 in response to electronic communications received from Account Holder 6402 are maintained by Order (i1) and the type of business in which the Account Authority is involved, or by Account Authority. It is essentially the same as the steps performed by any particular account authority of any of the two specific two ABDS business applications in Figures 6-49 that have only variations that result from the type of business content being done. The general steps performed are shown in FIG. These steps use the step of receiving the electronic communication (step 6602), the step of receiving the public key from the associated record in the account database (step 6604), and the public key thus obtained. Includes steps to attempt to authenticate a message. If the message authenticates (in step 6608), the account authority determines if entity authentication is adequately provided (step 6612). If enough entities are authenticated, the account authority processes the message further (step 6614). This step 6614 includes (or at least attempts to) execute the instruction (i1). If the message does not authenticate (step 6608), there is not enough entity authentication (step 6612), and the instruction (i1) cannot be executed (in step 6614), the account authority rejects the message, and Potentially, it responds to the sender communicating with the grounds or reasons for refusal (step 6610). (b. Third-party ABDS system with human-centered device) Here, with reference to FIG. 67, a second preferred implementation of the ABDS system 6700 utilizing the human-centered device 6750 is shown. The only significant difference between this second preferred implementation of Figure 67 and the first preferred implementation of Figure 64 is the middleman 6710, and the account holders 6702 to account authorities 6712, 6722, 6732. The fact is that electronic communication to one of them is communicated to the intermediary 6710. Therefore, this intermediary forwards the electronic communication to the appropriate account authority 6712, 6722 or 6732 specified by account holder 6702. The method of third-party ABDS trading with the person-centric device 6750 is quite similar to the method of third-party ABDS trading described earlier, with reference to Figures 50-63.

【0227】

With particular reference to FIG. 68, the account holder 6702 first initializes the transaction with the intermediary 6710 by establishing an electronic connection with the intermediary 6710 through the communication medium 6708 using the person-centric device 6750. (Step 6802). Again, the exact form of the human-centered device 6750 can vary, but is similar or identical to any device described with respect to the first aspect of the invention. Preferably, the account holder 6702 then enters the entity credentials (eg, the PIN, password, passphrase, or biometric information associated with the device 6750 into the device 6750) (step 6804). By means of electronic connection, the account holder 6702 formulates the instruction (i2) that the account holder 6702 wants the intermediary 6710 to execute (step 6806). In order for the intermediary 6710 to carry out the order (i2), the intermediary 6710 requires authentication and approval from one of the account holder's account verifications 6712, 6722, 6732. For this reason, account holder 6702 generates a message for the purpose of obtaining such authentication and authorization from the appropriate account authority (step 6808). In order for the intermediary 6710 to know which account authority of the account holder receives the message, the account number itself identifies the appropriate account authority, or the electronic communication is which account authority (AA #) authenticates the transaction and It either indicates whether it is necessary to receive electronic communications for approval.

【0228】

Once the message is configured, the message should be transmitted / delivered to / delivered to device 6750 (if the message is not actually configured by or within device 6750) (step 6810). Thus, the device 6750 first generates a digital signature on the message by first calculating the hash value for the data and then encrypting the hash value with the private key held within the device 6750 (step). 6812). In another, and less preferred embodiment, the hash value of the message is calculated outside the device 6750 and then to the device 6750 solely for the purpose of encrypting such a hash value of a digital signature. Provided. The device 6750 then outputs the digital signature from the digital signature component of the device 6750 (step 6814). The message, digital signature, and instruction (i2) are therefore transmitted to the intermediary 6710 via the communication medium 6708 (step 6816). As described throughout this specification, the human-centric device 6750 is an I / O support element or other external device (not shown) to complete the step of transmitting electronic communications to the intermediary 6710. ) May be required. As shown in Figure 69, the intermediary receives electronic communication from account holder 6702 (step 6902). The intermediary 6710 extracts any instruction (i2) from the account holder 6702 to the intermediary 6710 that contains information (AA #) about the identity of the account authority that needs to receive the forwarded electronic communication ( Step 6904). As shown in FIG. 67, instruction (i2) informs the intermediary 6710 that the account authority 6712 is the appropriate account authority to receive the transferred electronic communications. Man-in-the-middle 6710 orders electronic communications, including messages and digital signatures (i1) to approve and authenticate accounts. Transfer to authority 6712 (step 6906). The intermediary 6710 then issues these instructions (i2) (eg, a purchase request) to the message payment "on hold" from the account authority 6712 while waiting for a response from the account authority 6712 (step 6910). hold) positioned as hold approval. Here, with reference to FIG. 70, the steps performed by the account authority 6712 in response to electronic communications received from the account holder 6702 via the intermediary 6710 are described in more detail below. First, the account authority 6712 receives electronic communication from the intermediary 6710 (step 7002). Using the account number (acctID (#)) provided for electronic communication, the account authority 6712 retrieves the public key from the associated record in the account database 6714 (step 7004). With this public key, Account Authority 6712 attempts to authenticate the message (step 7006). If the message does not authenticate (in step 7008), account authority 6712 rejects the message and responds (step 7010). Such a response includes a reason for refusal. If the message does not authenticate (in step 7008), the account authority 6712 concludes that the message came from the person who owns the correct device 6750 associated with the actually identified account number-(ie, Factor A entity authentication). Is obtained). Account Authority 6712 then determines if the entity authentication provided is sufficient for further ownership of a particular message (step 7012). If not sufficient, Account Authority 6712 responds to message rejection (step 7010). Such a response may indicate the reason for the refusal. If entity authentication is sufficient (in step 7012), account authority 6712 continues further processing of the message (described below).

【0229】

Further processing of the message includes determining whether the instruction (i1) can be executed (step 7014). For example, even if the message authenticates, the account in account holder 6702 cannot be authenticated, or the account authority 6712 cannot handle the instruction (i1) or the instruction (i1) in this way to approve the message. .. If the verdict is negative (in step 7014), the account authority 6712 rejects the message and responds to the intermediary 6710 (step 7010). Again, such a response may indicate a reason for refusal. If the determination is positive in step 7014, the account authority 6712 executes instruction (i1) (step 7016). The account authority 6712 also notifies intermediary 6710 of approval to execute the message and instruction (i1) (step 7018). Returning to and referring to FIG. 69, once the intermediary 6710 receives the response from the account authority 6712, the decision in step 6910 is positive. The intermediary 6710 then determines whether the response is either an approval or a rejection of the transaction (step 6912). If the account authority 6712 does not approve the transaction, the intermediary 6710 notifies account holder 6702 that the message has been rejected and that the order (i2) has not been executed (step 6914). On the other hand, if the decision in step 6912 is positive, the intermediary 6710 executes the previously on-hold instruction (i2) (step 6916). Intermediary 6710 then notifies account holder 6702 that the transaction has been approved and that the order (i2) has been or has been executed. 3. Central Key Authority A third aspect of the invention incorporates the ABDS system of the first and second aspects of the invention, in addition to which account information linked to a particular PuK of the user of the device (in the specification). Including the maintenance of the database of "registration information"). In other words, the database identifies multiple accounts with which the public key is associated. The entity that maintains the database is referred to herein as the "central key authority".

【0230】

Registration information includes one or more of the following types of information about a particular device that generates a public key (PuK) and digital signature. Third Party Identity (with this identity, the user of the device has a PuK-linked account for the device and identifies each of the user's PuK-linked accounts to each third party. ); Information linked to the public key of the device according to other aspects of the invention; user-specific information such as the user's email address, credit card information, age, etc .; if applicable, to the user maintained by the central key authority. Authentication technology applied when verifying specific information. In addition, the central key authority preferably indexes the user's registration information for the user's public key so that the registration information can be retrieved based on the public key. In other words, the user of the device is the "account holder" of the central key authority.

【0231】

According to this aspect of the invention, the Central Key Authority will determine some or all of the registration information to a third party, as appropriate or requested. The user has an ABDS account with a third party, or the user wants to establish a new ABDS account with a third party-a message containing instructions representing transactions in the account (such as digitally signed using the device). The registration information will be disseminated when you wish to send an EC with a message. For example, the dissemination of registration information occurs when the registration information maintained by a third party expires as a specific account.

【0232】

The registration information maintained by the Central Key Authority can be obtained in a variety of ways. For example, the public key and the information linked to the public key are preferably obtained from the device manufacturer or other trusted entity that owns the device's public key and security profile. Third Party Identity (User has a PuK-linked account for the device with this identity and an account identifier that identifies the user's PuK-linked account for each such third party. ) Is preferably obtained from the user and when the user registers with the central key authority (at the user's command, when the central key authority establishes an account for the user at a third party, or at the user's command). , When a third party requests registration information from the central key authority).

【0233】

The central key authority according to this third aspect of the invention provides the convenience of updating a user's PuK-linked account on the user's new device on behalf of the user's old (and potentially expired) device. Can be provided. Such updates are preferably for associating the public key of the old device with the well-identified public key of the new device to a well-identified third-party account that is digitally signed with the old device. Achieved by simply sending an EC to the central key authority containing the message containing the instruction. Upon receiving such an EC, the central key authority authenticates the EC's message with the identified public key of the old device. Upon successful authentication, the central key authority retrieves registration information for the public key that corresponds to the old device. The central key authority then updates the registration information with the public key of the new device and transmits the EC to each of the third parties clearly identified to the user. The EC requires each third party to associate each user's account record with the new device's public key instead of the user's previous public key.

【0234】

The generally described system described above is shown in more detail in FIGS. 71a-72 below. A system 7100a according to a third aspect of the invention, including a central key authority 7190 and a database of account records 7194, is shown in Figure 71a. Again, account holder 7102 owns device 7150. The device 7150 secures the unique private key of the public / private key pair. Preferably, the device also holds the public key (PuK1) 7118 internally. This public key 7118 can be exported from device 7150. As can be seen in Figure 71a, the public key (PuK1) of device 7150 is associated with an account that was previously registered with account authority 7112 and has a unique account identifier "acctID (a)", and the account number (acctID). It is stored in the account record of the account database 7114 (based on the public key (PuK1)) that can be retrieved from the database 7114 in response to the input in (a).

【0235】

Account holder 7102 also owns another device 7151. Device 7151 in this figure is a human-centered device described with respect to the second aspect of the invention. The human-centric device 7151 secures a different private key of the public-private key inside. Preferably, device 7151 holds a public key (PuK2) 7128 internally. This public key 7128 may be exported from device 7151. As can be seen from the figure in Figure 71a, the public key (PuK2) of the human-centric device 7151 is registered with two account authorities; in the account authority 7122, PuK2 has a unique account identifier "acctID (b). ) And is stored in the account record in the account database 7124; in account authority 7132, PuK2 has at least two unique account identifiers acctID (c1) and acctID (c2) . Related to another account. Both accounts acctID (c1) and acctID (c2) are stored in their respective account records in the account database 7134.

【0236】

In establishing a database account with Central Key Authority 7190, referring to Figures 71a and 72, Account Holder 7102 preferably provides Central Key Authority 7190 with the following information for each account to be tracked: S: Public keys 7118, 7128 out of each device 7150, 7151 associated with the account (recorded in column Figure 72); unique identifiers (eg acctID (a); acctID (b); acctID (c1) ); AcctID (c2)), as well as other account-specific information, such as the account authority identifier and account type, for each particular account (recorded in column 7244 of Figure 72). The account holder 7102 also preferably has customer-specific (ie, personal) information and a device profile for each device 7150, 7151 associated with such an account (recorded in column 7240 of Figure 72). Provide information to Central Key Authority 7190. Other account attributes can also be recorded in the account database 7194 and can be obtained from the account holder 7102, or directly from either of the respective account authorities 7112, 7122, 7132. Preferably, the central key authority 7190 assigns the account holder 7102 with a unique account identifier such as the registered account number "RacctID (a)" (recorded in column 7230 of FIG. 72).

【0237】

Further referring to FIG. 71a, the account holder 7102 can electronically communicate with the central key authority 7190 through the communication medium 7108 in the form of a two-way ABDS (discussed with respect to the first aspect of the invention). In other words, the account holder 7102 holds the device 7150, or the message (M) containing the account holder's central key authority account number (RacctID (a)) and instruction (i3), as well as the digital signature (DS) of the message. A new account associated with the human-centric device 7151 can be registered by sending the including electronic communication to the central key authority 7190. The actual steps taken by Account Holder 7102, as well as the Central Key Authority 7190 to create, sign, send, and authenticate such messages are not described in detail. This is because such steps closely follow the method of two-way ABDS communication that has already been described for quite some time. Interestingly, the process of authenticating a message is potentially one to the central key authority because the account 7230 of account holder 7102 maintained by the central key authority 7190 is in fact associated with multiple public keys 7218. Requests an attempt to authenticate a message with one or more public keys. A typical instruction (i3) sent by account holder 7102 to central key authority 7190 would, for example, first set up an account for central key authority; add a new device 7150 or 7151 (and equivalent public key) to the registration information. Add, update, or delete personal information in your registration information; add, update, or delete the account identifier associated with a particular account; the public key for which the new account authority (and account) exists Add to; Includes requests to add or modify information about existing account authorities. Referencing Figure 72 again shows an example of the account database 7194 maintained by the central key authority 7190. Here, database 7194 is governed by registered account ID number 7230 and is related to registered account ID number 7230: information specific to the corresponding customer 7242, such as name, address, social security number and / or tax ID number, Credit card information; Public key information including each public key of a particular customer 7218; Device profile information for each device that holds a private key equivalent to each public key 7270 (such device profile information is of security Features, device authentication capabilities, manufacturing history, and transaction history); Account specific information 7244 (eg, account authority name, account-related unique account identifier (acctID), account authority address, account A complete list of accounts (s) related to the public key, including the type of account maintained by the authority).

【0238】

Providing a convenient way for the Central Key Authority 7190 to track multiple public keys associated with a particular account holder 7102, and to track each of the accounts associated with each of the public keys, is Immediately understood. Easy and immediate access to such information is important. For example, the appropriate account authorities 7122, 7132 need to be notified, especially when the person-centric device 7151 of account holder 7102 is lost or stolen, or when its private key (PuK2) is compromised. ..

【0239】

In such a situation, as shown in Figure 71b, the account holder 7102 attaches to such a central key authority 7190 (obviously in a more convenient way, perhaps the device or private key (PrK2) is no longer a message. Not available for generating digital signatures). The Central Key Authority 7190 contacts each Authority 7122, 7132 in turn. Each account authority 7122, 7132 then ceases to be used until account holder 7102 associates the new public key (PuK2-new) with the associated account [acctID (b); acctID (c1); acctID (c2)]. (Or at least stop using the account with a particular device 7151 and public key 7128).

【0240】

In addition, as shown in Figure 71c, once the account holder 7102 gets a new device and the corresponding new public key (PuK2-new) 7102, the account holder 7102 gets a new public key (PuK2-new) 7138. You only need to update the central key authority 7190 with. The central key authority 7190 is then preferably associated with the associated accounts [acctID (b); acctID (c1); acctID (c2)] and the respective accounts [acctID (b); acctID (c1); Communicate the new public key (PuK2-new) 7138 with the appropriate account authorities 7122, 7132 to reactivate acctID (c2)].

【0241】

As shown in Figure 71d, the central key authority 7190 is also useful in establishing a new account with the new account authority 7142. In this regard, if the central key authority 7190 keeps a record for account holder 7102 who wants to establish an account with the new account authority 7142, the new account (acctID (d)) is preferably of account holder 7102. Established by Central Key Authority 7190 on request. In particular, the account holder 7102 instructs the central key authority 7190 to transmit the information corresponding to the new account authority 7142 from the account database 7194 to the account holder 7102. The public key (Puk-new) 7138 of account holder 7102 that should be associated with the new account (acctID (d)) is included in the relevant information. The desired account authority 7142 then uses the information received from the central key authority 7190 to establish an initial record in the account database 7144 of the desired account authority 7142. Any further information that may be requested by the account authority 7142 may then be obtained from the new records in the new account holder 7102 and the updated account database 7144.

【0242】

Assuming that the central key authority 7190 and the account authorities 7112, 7122, 7132, 7142 register their own public keys with each other, the above communication between them occurs in electronic communication and in the form of two-party ABDS. obtain.

【0243】

4. Applying Dynamic Risk Analysis to Transactions As recognized, the credit of the ABDS system described above depends on the legitimate possession and use of the private key. Unauthorized use of a private key to digitally sign a message contained in an EC cannot be detected simply through message authentication. Thus, the device's private key is stolen either by physically stealing the device or by discovering and replicating the private key to make the original digital signature available on another device. If so, the above ABDS system is potentially suspected of being misused.

【0244】

Factor B entity authentication and / or factor C entity authentication techniques and credentials previously described are used to prevent unauthorized use of the device through theft of the device itself. In order to discover the private key and prevent it from being subsequently duplicated and used by another device, the device may shield, zero, tamper evidence and tamper response, or the private key contained internally. Manufactured with other security features that protect (and other protected data). Such security features are well known in the field of manufacturing secure computer chips and other cryptographic modules, including hardware and software.

【0245】

Qualifications for such safety features are Federal Information Processing Standards Publication 140-1, Security Requirements for Cryptographic Modules, US DOC / NBS, January 11, 1994 (in this specification, "FIPS PUB 140-1". ) And incorporated herein by reference. Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules, US DOC / NBS, May 25, 2001 (referred to herein as "FIPS PUB 140-2"). Incorporated as a reference. FIPS PUB 140-1 and 140-2 also specify the level of security that can be met by the device based on the security features of the device. Each of these defines security levels that represent different levels of difficulty-in terms of time and cost. You will encounter these when trying to identify the device's private key. The four security levels are defined so that security level 4 is the highest level of security available.

【0246】

The specification for such security features also includes Trusted Platform Module (TPM) Security Policy Version 0.45, TRUSTED COMPUTING PLATFORM ALLIANCE, October 2000, and TCPA PC Implementations Specification Version 0.95, TRUSTED COMPUTING PLATFORM ALLIANCE, 7 2001. May 4 (both specifications are incorporated herein by reference (collectively, the "TCPA document")), as well as the Common Criteria for Information Technology Security Evaluation, Smart Card Protection Profile, Draft Version 2.1d. , SMART CARD SECURITY USER GROUP, March 21, 2001, as incorporated herein by reference (the "Smart Card Protection Profile").

【0247】

Device features that protect against the discovery of private keys and other protected data are cited herein as "security features" of the device. A device feature that protects against the authenticated use of a device by authenticating the user is cited herein as the "authentication capability" of the device. The "security features" of a device (including an encryption module or TPM) include features such as security features and authentication capabilities. The qualifications for these functions are clearly stated in the references cited above.

【0248】

Unfortunately, the previously mentioned defenses generally reduce the risk of fraud within the entire digital signature system, but the recipient of any one particular EC, including messages and equivalent digital signatures, is digital. You may be unfamiliar with the device used to generate the signature, and therefore cannot read the risk of whether the digital signature could have been fraudulently generated, either through device theft or discovery of the private key. In addition, the receiver can generally read the risk of a digital signature being fraudulently generated when it is not confidential or biometric values are shared between the sender and the receiver. Can not. In such situations, the receiver acknowledges that the device currently used to generate the digital signature has not been stolen, and the device used to generate the digital signature has been discovered and You must rely on blindly believing that you have sufficient protection to protect your private key from use.

【0249】

Therefore, the fourth aspect of the present invention will be described below. A fourth aspect of the invention incorporates the ABDS system of the first aspect of the invention, plus the risk or possibility that the authenticating message was fraudulently, inadvertently, or unknowingly signed. Includes identification and evaluation of a number of factors by the account authority for the purpose of reading sex and for the purpose of determining whether the instruction (i1) contained in the message should be executed. Factors evaluated and considered are the authentication capabilities of the device used to generate the digital signature for the message, the type and sufficiency of entity authentication obtained by the device or provided to the EC, if any. Others, including device security features, environmental factors related to message composition and transmission, transaction history related to the device or message related account, and whether the order (i1) can be performed on the identified account. Is your account or business well funded for certain factors (eg, the account for the requested refund or transfer? Will the account holder be authenticated to view the requested information? Will the account holder be authenticated to enter the requested space? Will the account holder be authenticated to carry out the requested transaction? The account holder will be authenticated within the identified contact. Will it be authenticated to enter?) Included. The authentication capability of a device includes these components that perform factor B and / or C entity authentication for authenticating the user of the device. By knowing the authentication capabilities of the device (or lack of them), the receiver can read the possibility that someone other than the authenticated user could use the device to generate a digital signature. As technology develops over time, reducing the effectiveness of such security features and, as a result, reducing the actual security level of the device.

【0250】

In addition, it is also important to know the "manufacturing history" of the device used to generate the digital signature contained within the EC. The "manufacturing history" of a device is (device manufacturer; all details applicable to the device; device manufacturing data; manufacturing location; device cohesive identifier; device serial number and part number; manufacturer security; layout. And physical implementation of the device with respect to process geometry; software certificate and launch data; device operating parameters including voltage and frequency regions; identification of all enabled hardware and software security features of the device, etc.) Includes device manufacturing attribute records. By knowing the manufacturing history of the device, the security features and authentication capabilities of the device are corrected as errors, omissions, defects, security breaches, or possible improper things that occur during the manufacturing of the device. Can be done. Therefore, by knowing the manufacturing history, the stability level of the device can be determined.

【0251】

The "environmental factors" associated with EC creation and transmission are where in the world the EC was generated, how the EC was communicated, and what type of I / O support element (s) or type. What type was involved in the generation and transmission of the EC, whether each of these I / O support elements generated its own digital signature on the EC, the security features associated with the I / O support element, The entire digital signature environment (in this environment, for example, whether entity credentials can be eavesdropped, duplicated by an I / O aid element or other external device, and then replayed later without the knowledge of the device user, etc. Includes knowing (where the action is taken). The device's "transaction history", or EC-related account, identifies and tracks irregular or unusual activity, or account-related instructions (eg, typical of the device). Knowing geographic usage, typical transaction volume or type, frequency of use, typical entity authentication provided, historical data about wrong attempts to provide entity authentication, etc.), device lost Involved in knowing whether or not it has been reported that it has been stolen or stolen. Includes other account factors and business considerations, and all additional criteria evaluated by the EC receiver to determine if the instruction (i1) in the message should be enforced.

【0252】

As previously described for each of the various ABDS systems, it is preferred that the device profile information of the device should be recorded by the account authority in the account database record associated with the device's public key. The device profile information includes the device security profile and transaction history. The security profile includes device security features and manufacturing history. Security features include device security features and authentication capabilities. The security profile is preferably (but not necessarily required) obtained directly from the device manufacturer (preferably a reliable and credible entity). If the security profile is not obtained directly from the manufacturer, the security profile is obtained indirectly from a trusted third party who obtained the security profile from the manufacturer, or by an account authority (or an entity trusted by the account authority). Either obtained from a physical inspection of the device (according to). Security profiles may also be provided by account holders within the scope of the present invention. Given the third aspect of the invention, the security profile is also obtained from the central key authority (as when information is received from the central key authority when establishing a new account for an account holder). obtain.

【0253】

With this information in the device profile information, the account authority authenticates the message contained within the EC and then processes the message further. This includes the step of calculating and determining whether to execute the instruction (i1) contained in the authenticated message. Alternatively, the step of further processing the message is a decision to execute a limited part of the instruction based on an analysis of the current risk associated with the instruction (i1), or a risk associated with the current instruction (i1). Includes a decision to request more information from the EC sender to reduce.

【0254】

As shown in Figure 73, for example, when the account authority first receives the EC from the claimed account holder (step 7302), the account authority will get the PuK associated with the account number provided to the EC in the account database. Extract from (step 7304) and attempt to authenticate the message using PuK (step 7306). If the message does not authenticate (in step 7308), the account authority responds with a rejection to the instruction and / or the instruction (i1) contained in the message (step 7310)-all of which is the first aspect of the invention. Matches with. If the message authenticates (in step 7308), the account authority further processes the message and the instruction (i1) contained within the message (step 7312).

【0255】

An example of further processing a message by the account authority after authenticating the message according to the first aspect of the invention is previously associated with FIGS. 6-63 for each particular implementation of the two- and three-way ABDS systems. Explained. However, as shown in FIG. 73, a further process according to this fourth aspect of the invention (step 7312) is to finally determine whether to execute the instruction (i1) contained in the message. Includes assessment and consideration (step 7314) of a number of factors used by the account authority. The evaluation and consideration (step 7314) includes the evaluation of the device's ability to authenticate (step 7316), and the analysis of entity authentication provided by the device's EC or user's sender, if any, and device-related security features. Assessment (step 7318), assessment of environmental factors surrounding EC (step 7320), device transaction history, and / or consideration of EC-related accounts (step 7322), or to other accounts and / or business Includes consideration of specific factors (step 7324). Whether the account authority considers some or all of the above factors, how much the account authority considers any particular factor, if any, in the order (in this order the account authority evaluates or considers the above factors) The weight or importance of each account changes from one account authority to the next, depending on the particular business interests, needs, targets, objectives, and risks of each account authority itself. Therefore, each account authority determines whether the instruction (i1) from the message should be executed (step 7326) based on any or all of the factors considered (in step 7314). Use the business rules and judgments of the account authority itself. If this check is negative (in step 7326), then the account -The solitaire rejects the message and / or the instruction (i1) contained in the message (step 7310). If this verdict is positive (in step 7326), the account authority executes the command (i1) from the message (step 7328) and thus updates the account record (step 7330).

【0256】

Although not shown in FIG. 73, if the decision in step 7326 is negative, the account authority should, if possible, execute only the restricted portion of the instruction (i1) instead, based on an analysis of the above factors. Can be selected. In another alternative embodiment (also not shown in Figure 73), the account authority of the EC before executing the instruction (i1) to reduce the risk associated with the current instruction (i1). Further information may be requested from the sender.

【0257】

From all of the above, the devices described above with respect to the present invention include, for example, the seller and the devices of other commercial entities that generate digital signatures, and the devices of individual consumers that generate digital signatures. It is clear that you are not limited to. For example, a device according to the invention is, for example, an IC card reader used to read an individual consumer's IC card in establishing a secure financial transaction (such an IC card reader itself produces a digital signature). Includes I / O support elements, including if). In this regard, such devices may include a trusted platform module.

【0258】

Therefore, given the above detailed description, devices, and methods of preferred embodiments of the invention, it will be readily appreciated by those skilled in the art that the invention is widely useful and widely applicable. Will be done. At the same time as many modifications, modifications, and equivalent arrangements, various methods, embodiments, and adaptations of the invention other than those described herein deviate from the gist or scope of the invention. It is not apparent from the present invention and the following detailed description of the present invention, or is reasonably proposed by the present invention. Further, various processing steps are shown and described in some examples as if they were performed in a preferred or primary order, but these processing steps are in such a particular order. One of ordinary skill in the art understands and recognizes that it is not necessarily limited to what is done in sequence. Rather, in many examples, the steps of processing described herein can be performed in a variety of different orders and orders, as long as they are within the scope of the present invention. Thus, although the invention is described in detail herein in the context of preferred methods and devices, only this detailed description is an illustration and an example of the invention, providing all and providing the present invention. It should be understood that it is done only for the purpose of enabling the disclosure of. The detailed description presented herein is constructed to limit the invention, otherwise any such other embodiment of the invention, adaptations, modifications, modifications, and. It is not intended to exclude the invention and its equivalents, which are merely limited by the equivalent arrangement, the appended claims.

[Simple explanation of drawings]

FIG. 1 shows a prior art certification authority digital certificate (CADS) system.

FIG. 2 shows a suitable account-based digital signature (ABDS) system according to a first aspect of the invention.

FIG. 2a shows an account database maintained by an account authority for use with the ABDS system.

FIG. 2b shows another account database maintained by the account authority for use with the ABDS system.

FIG. 3 shows another suitable ABDS system according to the first aspect of the invention.

FIG. 4a shows a flow chart of an embodiment of a preferred step for establishing a new ABDS account according to a first aspect of the invention.

FIG. 4b shows a flowchart of another embodiment of a preferred step for establishing a new ABDS account according to a first aspect of the invention.

FIG. 5a shows a flow chart of an embodiment of a preferred step for converting an existing account into an ABDS account according to a first aspect of the invention.

FIG. 5b shows a flowchart of another embodiment of a preferred step for converting an existing account into an ABDS account according to a first aspect of the invention.

FIG. 6 shows a first business application according to a first aspect of the present invention.

FIG. 7 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 8 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 9 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 10 shows a second business application according to a first aspect of the present invention.

FIG. 11 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 12 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 13 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 14 shows a third business application according to a first aspect of the present invention.

FIG. 15 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 16 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 17 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 18 shows a fourth business application according to a first aspect of the present invention.

FIG. 19 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 20 shows a flow chart of steps performed by account holders in the business application of FIG.

FIG. 21 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 22 shows a fifth business application according to a first aspect of the present invention.

FIG. 23 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 24 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 25 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 26 shows a sixth business application according to a first aspect of the present invention.

FIG. 27 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 28 shows a flow chart of steps performed by account holders in the business application of FIG.

FIG. 29 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 30 shows a seventh business application according to a first aspect of the invention.

FIG. 31 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 32 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 33 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 34 shows an eighth business application according to a first aspect of the invention.

FIG. 35 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 36 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 37 shows a flow chart of the steps performed by the account authority in the business application of FIG.

FIG. 38 shows a ninth business application according to a first aspect of the invention.

FIG. 39 shows an account database maintained by the account authority for use with the business application of FIG. 38.

FIG. 40 shows a flow chart of steps performed by account holders in the business application of FIG. 38.

FIG. 41 shows a flow chart of steps performed by the account authority in the business application of FIG. 38.

FIG. 42 shows a tenth business application according to a first aspect of the present invention.

FIG. 43 shows an account database maintained by the account authority for use with the business application of FIG. 42.

FIG. 44 shows a flow chart of steps performed by an account holder in the business application of FIG. 42.

FIG. 45 shows a flow chart of steps performed by the account authority in the business application of FIG. 42.

FIG. 46 shows an eleventh business application according to a first aspect of the present invention.

FIG. 47 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 48 shows a flow chart of steps performed by account holders in the business application of FIG.

FIG. 49 shows a flow chart of steps performed by the account authority in the business application of FIG.

FIG. 50 shows a first business application according to another preferred embodiment of the first aspect of the invention.

FIG. 51 shows an account database maintained by the account authority for use with the business application of FIG.

FIG. 52 shows a flow chart of steps performed by an account holder in the business application of FIG.

FIG. 53 shows a flow chart of steps performed by an intermediary in the business application of FIG.

FIG. 54 shows a flow chart of the steps performed by the account authority in the business application of FIG.

FIG. 55 shows a second business / consumer application according to another preferred embodiment of the first aspect of the invention.

FIG. 56 shows an account database maintained by the account authority for use with the business application of FIG. 55.

FIG. 57 shows a flow chart of steps performed by account holders in the business application of FIG. 55.

FIG. 58 shows a flow chart of steps performed by an intermediary in the business application of FIG. 55.

FIG. 59 shows a flow chart of steps performed by the account authority in the business application of FIG. 55.

FIG. 60 shows a third business / consumer application according to another preferred embodiment of the first aspect of the invention.

FIG. 61 shows an account database maintained by the account authority for use with the business application of FIG. 60.

FIG. 62 shows a flow chart of steps performed by both the account holder and the seller (intermediate) in the business application of FIG. 60.

FIG. 63 shows a flow chart of steps performed by the account authority in the business application of FIG. 60.

FIG. 64 shows a suitable ABDS system according to a second aspect of the invention.

FIG. 64a shows an account database maintained by the account authority for use with the system of FIG. 64.

FIG. 64b shows another account database maintained by the account authority for use with the system of FIG. 64.

FIG. 64c shows a third account database maintained by the account authority for use with the system of FIG. 64.

FIG. 65 shows a flow chart of steps performed by account holders in the system of FIG. 64.

FIG. 66 shows a flow chart of steps performed by the account authority in the system of FIG.

FIG. 67 shows another suitable ABDS system according to a second aspect of the invention.

FIG. 68 shows a flow chart of steps performed by account holders in the system of FIG. 67.

FIG. 69 shows a flow chart of steps performed by an intermediary in the system of FIG. 67.

FIG. 70 shows a flow chart of steps performed by the account authority in the system of FIG. 67.

FIG. 71a shows a suitable ABDS system according to a third aspect of the invention.

FIG. 71b shows another suitable ABDS system according to a third aspect of the invention.

FIG. 71c shows yet another suitable ABDS system according to a third aspect of the invention.

FIG. 71d shows a more preferred ABDS system according to a third aspect of the invention.

FIG. 72 shows an account database maintained by the account authority for use with the FIG. 71a system.

FIG. 73 shows a flow chart of steps performed by the account authority according to the fourth aspect of the invention.

FIG. 74 illustrates the use of EC for session authentication and transaction authentication purposes according to the first aspect of the invention.

FIG. 75 shows the use of EC for transaction confirmation purposes according to the first aspect of the invention.

FIG. 76 shows an electronic communication format or layout according to various aspects of the invention.