Person-centric account-based digital signature system (20-Dec-2005)

I. CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority in the United States under 35 U.S.C. 119, and under the Paris Convention worldwide, to the benefit of the filing date of Wheeler et al. U.S. provisional patent application Ser. No. 60/223,076, which was filed on Aug. 4, 2000, and which is incorporated herein by reference. This application also incorporates herein by reference each of three international patent applications and three U.S. patent application to Anne and Lynn Wheeler filed concurrently herewith in the U.S. Patent & Trademark Office and bearing Ser. No. 09/923,179 (entitled “Account-Based Digital Signature (ABDS) System”); Ser. No. PCT/US01/41562 (entitled “Entity Authentication in Electronic Communications by Providing Verification Status of Device”) and Ser. No. 09/923,075 (entitled “Modifying Message Data and Generating Random Number Digital Signature Within Computer Chip”) collectively referred to hereinafter as the “VS Applications”; Ser. No. PCT/US01/24572 (entitled “Linking Public Key of Device to Information During Manufacture”) and Ser. No. 09/923,213 (entitled “Manufacturing Unique Devices That Generate Digital Signatures”); and Ser. No. PCT/US01/24563 (entitled “Trusted Authentication Digital Signature (TADS) System”).

II. FIELD OF THE PRESENT INVENTION

The present invention relates to an improved communication system in which electronic communications regarding accounts are digitally signed.

III. BACKGROUND OF THE PRESENT INVENTION

As used herein, an electronic communication (“EC”) is considered to be any communication in electronic form. ECs have become an integral part of transacting business today, especially with the growth of the Internet and e-commerce. An EC can represent, for example, a request for access to information or a physical area, a financial transaction, such as an instruction to a bank to transfer funds, or a legal action, such as the delivery of an executed contract.

Over recent years, digital signatures also have become an important part of e-commerce. The origination of a digital signature generally comprises: (1) the calculation of a message digest—such as a hash value; and (2) the subsequent encryption of the message digest. The message digest is encrypted by an electronic device generally using a private key of a public-private key pair used in asymmetric cryptography. The resulting ciphertext itself usually constitutes the digital signature, which typically is appended to the message to form the EC. The second part of originating the digital signature—encrypting with a private key—is referred to herein as “generating” the digital signature, and the combined two steps (i.e., calculating a message digest and encrypting with a private key) is referred to herein as “originating” the digital signature. Furthermore, while the generation of the digital signature is conventionally understood as the encryption of the message digest, it is contemplated herein that generating the digital signature also may include simply encrypting the message rather than the message digest. Digital signatures are important because any change whatsoever to the message in an EC is detectable from an analysis of the message and the digital signature. In this regard, the digital signature is used to “authenticate” a message contained within the EC (hereinafter referred to as “Message Authentication”).

For example, a message digest may be calculated by applying a hashing algorithm—such as the SHA-1 algorithm—to the message. Such hashing algorithm may be applied either within the device or external to the device with the resulting hash value then being transmitted to the device for generation of the digital signature. In order to perform the Message Authentication in this example, the recipient of the EC must know or be able to obtain both the identity of the hashing algorithm applied to the message as well as the public key (“PuK”) corresponding to the private key (“PrK”) used to encrypt the message digest. With this knowledge, the recipient applies the appropriate hashing algorithm to the message to calculate a hash value, and the recipient decrypts the digital signature using the public key. If the hash value calculated by the recipient equals the hash value of the decrypted digital signature, then the recipient determines that the content of the message contained in the EC was not altered in transmission, which necessarily would have changed the hash value.

In performing Message Authentication, the recipient also authenticates the sender of the EC, in so much as the recipient thereby confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message. This is one type of entity authentication and is based on what the sender “has” (hereinafter referred to as “Factor A Entity Authentication”). Factor A Entity Authentication is useful when the recipient of the EC has trusted information regarding the identity of the owner of the private key.

This trusted information conventionally is provided based on a digital certificate issued by a trusted third party that accompanies the digital signature and binds the identity (or other attributes) of the private key owner with the public key. A digital certificate (also known as a “digital ID”) is a voucher by a third party (commonly referred to as a “Certification Authority”) attesting to the identity (or other attributes) of an owner of a public key. Essentially, digital certificates are the electronic counterparts to driver licenses, passports, membership cards, and other paper-based forms of identification. The digital certificate itself comprises an electronic message including a public key and the identity of the owner of the public key. A digital certificate also typically contains an expiration date for the public key, the name of the Certification Authority, a serial number of the digital certificate, and a digital signature of the Certification Authority. One of the reasons for an expiration date is to limit the liability for the Certification Authority due to the likelihood that attributes other than the identity may change over time. The most widely accepted format for digital certificates is defined by the CCITT X.509 international standard; thus, certificates can be read or written by any application complying with X.509. Based on a digital certificate included in an EC, a recipient is able to authenticate the digital certificate using a public key of the Certification Authority and thereby, presumably, confirm the identity of the owner set forth therein.

The system wherein a digital certificate is included in an EC comprises a “public key infrastructure” (PKI) commonly referred to as the “Certification Authority Digital Signature” (CADS) system. A particular implementation 100 of the CADS system in the context of an electronic transaction between a purchaser 102 and an online merchant 110 is illustrated in FIG. 1. Under this system, a purchaser 102 using, for example, a computer 104 creates a purchase order in the form of an electronic message. The purchaser 102 includes in the message relevant account information of a financial institution 112 from which payment is to be made to the merchant 110. The account information includes, for example, a credit card number and expiration date as well as the name on the card. Software on the purchaser's computer 104 then originates a digital signature for the message using a private key of the purchaser 102 safeguarded in the computer 104. The software also maintains a digital certificate on the computer 104 issued by a Certification Authority 106a. The message, digital signature, and digital certificate then are combined into an EC, and the EC is communicated over the Internet 108 to the merchant 110.

Upon receipt, the merchant 110 authenticates the message using the public key in the digital certificate. If successful, the merchant 110 then authenticates the digital certificate using a public key of the Certification Authority 106a. Successful authentication of the digital certificate may satisfy the merchant 110 that the purchaser—the sender of the EC—is the owner identified in the digital certificate. If the merchant 110 is so satisfied, then the merchant 110 submits the account information to the relevant financial institution 112 for an approval for payment to the merchant 110 from the account. Upon receipt from the financial institution 112 of approval for payment, the merchant 110 fills the purchase order of the purchaser 102. Furthermore, confirmation of approval (or rejection) of the purchase order preferably is sent from the merchant 110 to the purchaser 102.

Unfortunately, while the CADS system enables two parties who otherwise may not have a preexisting relationship with one another to communicate with each other with the confidence of knowing the other's identity, the CADS system does have its drawbacks. For example, a digital certificate typically is issued with an expiration date, and an expired digital certificate generally is not recognized in the industry. Furthermore, if a private key is lost or stolen, then the owner of the private key must notify the Certification Authority to revoke the owner's digital certificate; however, a recipient of an EC with a digital certificate will only know of the revocation of the digital certificate if the recipient cross-references the serial number of the digital certificate against a certificate revocation list (CRL) published by the Certification Authority. Another drawback to the CADS system is that the digital certificate itself is only as good as the particular authority that issues it, and it often is necessary to obtain multiple digital certificates (i.e., from Certificate Authorities 106a, 106b to 106n) in order to create a sufficient “chain” or “network” of trust between the purchaser 104 and merchant 110 for a transaction or communication to be accepted and acted upon. Additionally, the entire CADS system rests upon the secrecy of the private key of the Certification Authority issuing a digital certificate, which, if compromised, collapses the CADS system.

In the context of an EC regarding an account, such as the example of an online purchase set forth above, another drawback of the CADS system is that the account information must be encrypted or otherwise protected if sent over an insecure communications medium, such as the Internet 108. In the example above, a hacker eavesdropping on the communication of the account information could obtain sufficient information to make fraudulent charges to the account of the purchaser, especially as not all merchants require a digital signature and digital certificate to fill a purchase order. Moreover, financial institutions have yet to standardize a requirement that a digital certificate of a purchaser be submitted as a condition precedent to approving a payment request by a merchant; instead, in determining whether a purchaser actually has the authority to effect payment to a merchant, a financial institution relies upon the personal account information provided by the merchant, and whether the account information has been reported lost or stolen. Further, digital certificates raise significant privacy issues in many circumstances.

Accordingly, a need exists for an improved system of communication using digital signatures, especially wherein an EC pertains to an account upon which the person (or device) digitally signing the EC has authority to act.

IV. BRIEF SUMMARY OF THE PRESENT INVENTION

Briefly summarized, a method of communicating electronically over a communications medium regarding accounts includes for each of two separate accounts maintained by separate third parties, the steps of: maintaining information pertaining to the account in an account database such that the information is retrievable based on a unique identifier, associating a public key of a public-private key pair with the unique identifier, generating a digital signature for an electronic message using a private key of the public-private key pair, the electronic message including an instruction and the unique identifier, authenticating the electronic message using the public key associated with the information identified by the unique identifier, and upon the successful authentication of the electronic message, executing the instruction with respect to the account represented by the information that is identified by the unique identifier.

The present invention also includes a method of maintaining a Central Key Authority (CKA) database. The CKA database includes account information of users such as a public key of a user device that generates digital signatures, and third-party account identifiers each of which identifies to a third-party an account of the user that is maintained with the third-party and that has been associated with the user's public key by the third-party.

The present invention also encompasses a method of managing a database for identification of security features of a device that generates digital signatures, and includes the steps of recording in the database for each of a plurality of devices a public key of a pair of public-private keys of the device and information including security features of the device, the security features being associated with the public key in the database; and identifying security features from the database to a recipient of an electronic message for which a digital signature was originated utilizing a private key of the public-private key pair of a particular one of the devices, the security features being for the particular device.

V. BRIEF DESCRIPTION OF THE DRAWINGS

Further features and benefits of these aspects of the present invention will be apparent from a detailed description of preferred methods thereof taken in conjunction with the following drawings, wherein like references refer to like elements, and wherein:

FIG. 1 illustrates a prior art Certification Authority Digital Certificate (CADS) system;

FIG. 2 illustrates a preferred Account-based Digital Signature (ABDS) system in accordance with a first aspect of the present invention;

FIG. 2a illustrates an account database maintained by an account authority for use with an ABDS system;

FIG. 2b illustrates another account database maintained by an account authority for use with an ABDS system;

FIG. 3 illustrates another preferred ABDS system in accordance with the first aspect of the present invention;

FIG. 4a illustrates a flowchart of one embodiment of preferred steps for establishing a new ABDS account in accordance with the first aspect of the present invention;

FIG. 4b illustrates a flowchart of another embodiment of preferred steps for establishing a new ABDS account in accordance with the first aspect of the present invention;

FIG. 5a illustrates a flowchart of one embodiment of preferred steps for converting an existing account into an ABDS account in accordance with the first aspect of the present invention;

FIG. 5b illustrates a flowchart of another embodiment of preferred steps for converting an existing account into an ABDS account in accordance with the first aspect of the present invention;

FIG. 6 illustrates a first business application in accordance with the first aspect of the present invention;

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

FIG. 8 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 6;

FIG. 9 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 6;

FIG. 10 illustrates a second business application in accordance with the first aspect of the present invention;

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

FIG. 12 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 10;

FIG. 13 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 10;

FIG. 14 illustrates a third business application in accordance with the first aspect of the present invention;

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

FIG. 16 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 14;

FIG. 17 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 14;

FIG. 18 illustrates a fourth business application in accordance with the first aspect of the present invention;

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

FIG. 20 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 18;

FIG. 21 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 18;

FIG. 22 illustrates a fifth business application in accordance with the first aspect of the present invention;

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

FIG. 24 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 22;

FIG. 25 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 22;

FIG. 26 illustrates a sixth business application in accordance with the first aspect of the present invention;

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

FIG. 28 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 26;

FIG. 29 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 26;

FIG. 30 illustrates a seventh business application in accordance with the first aspect of the present invention;

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

FIG. 32 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 30;

FIG. 33 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 30;

FIG. 34 illustrates an eighth business application in accordance with the first aspect of the present invention;

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

FIG. 36 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 34;

FIG. 37 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 34;

FIG. 38 illustrates a ninth business application in accordance with the first aspect of the present invention;

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

FIG. 40 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 38;

FIG. 41 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 38;

FIG. 42 illustrates a tenth business application in accordance with the first aspect of the present invention;

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

FIG. 44 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 42;

FIG. 45 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 42;

FIG. 46 illustrates an eleventh business application in accordance with the first aspect of the present invention;

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

FIG. 48 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 46;

FIG. 49 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 46;

FIG. 50 illustrates a first business application in accordance with another preferred embodiment of the first aspect of the present invention;

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

FIG. 52 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 50;

FIG. 53 illustrates a flowchart of steps performed by an intermediate party in the business application of FIG. 50;

FIG. 54 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 50;

FIG. 55 illustrates a second business/consumer application in accordance with another preferred embodiment of the first aspect of the present invention;

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

FIG. 57 illustrates a flowchart of steps performed by an account holder in the business application of FIG. 55;

FIG. 58 illustrates a flowchart of steps performed by an intermediate party in the business application of FIG. 55;

FIG. 59 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 55;

FIG. 60 illustrates a third business/consumer application in accordance with another preferred embodiment of the first aspect of the present invention;

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

FIG. 62 illustrates a flowchart of steps performed by both an account holder and merchant (intermediate party) in the business application of FIG. 60;

FIG. 63 illustrates a flowchart of steps performed by an account authority in the business application of FIG. 60;

FIG. 64 illustrates a preferred ABDS system in accordance with a second aspect of the present invention;

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

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

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

FIG. 65 illustrates a flowchart of steps performed by an account holder in the system of FIG. 64;

FIG. 66 illustrates a flowchart of steps performed by an account authority in the system of FIG. 64;

FIG. 67 illustrates another preferred ABDS system in accordance with a second aspect of the present invention;

FIG. 68 illustrates a flowchart of steps performed by an account holder in the system of FIG. 67;

FIG. 69 illustrates a flowchart of steps performed by an intermediate party in the system of FIG. 67;

FIG. 70 illustrates a flowchart of steps performed by an account authority in the system of FIG. 67;

FIG. 71a illustrates a preferred ABDS system in accordance with a third aspect of the present invention;

FIG. 71b illustrates another preferred ABDS system in accordance with the third aspect of the present invention;

FIG. 71c illustrates yet another preferred ABDS system in accordance with the third aspect of the present invention;

FIG. 71d illustrates a further preferred ABDS system in accordance with the third aspect of the present invention;

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

FIG. 73 illustrates a flowchart of steps performed by an account authority in accordance with the fourth aspect of the present invention;

FIG. 74 illustrates use of an EC for session authentication and transaction authentication purposes in accordance with the first aspect of the present invention;

FIG. 75 illustrates use of an EC for transaction confirmation purposes in accordance with the first aspect of the present invention; and

FIG. 76 illustrates an electronic communication format or layout in accordance with the various aspects of the present invention.

VI. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As a preliminary matter, it readily will be understood by those persons skilled in the art that, in view of the following detailed description of the devices, systems, and methods of the present invention, the present invention is susceptible of broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the following detailed description thereof, without departing from the substance or scope of the present invention. Accordingly, while the present invention is described herein in detail in relation to preferred embodiments, it is to be understood that this detailed description only is illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the present invention. The detailed description set forth herein is not intended nor is to be construed to limit the present invention or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements of the present invention, the present invention being limited solely by the claims appended hereto and the equivalents thereof.

Those skilled in the art will understand and appreciate that the sequence(s) and/or temporal order of the steps of various processes described and claimed herein are those considered by the inventors to be the best mode contemplated by them for carrying out the inventions. It should also be understood that, although steps of various processes are shown and described in some cases as being in a preferred sequence or temporal order, the steps of such processes are not limited to being carried out in any particular sequence or order, absent a specific indication that a step or steps should be carried out in a particular sequence or order to achieve a particular intended result. In most cases, the steps of such processes may be carried out in various different sequences and orders, while still falling within the scope of the present inventions.

Accordingly, while much of the present invention is described in detail herein with respect to computers, networks, integrated circuits, computer chips, and devices, no specific software or logic circuit is intended nor is required to be used in the practicing of the present invention. Indeed, it would be a matter of routine skill to select appropriate computers, networks, integrated circuits, computer chips, and devices in implementing the invention in a particular business application.

The present invention broadly comprises the association of a public key of a device that originates digital signatures using asymmetric cryptography to other information in an account database record. In general, a method in accordance with the first aspect of the present invention includes electronically communicating a message over a communications medium regarding an account that is associated with a public key, the corresponding private key of which is used to digitally sign the message. A method in accordance with the second aspect of the present invention includes associating multiple accounts with the same public key. A method in accordance with the third aspect of the present invention includes maintaining a central database of information on all accounts associated with the same public key. Finally, a method in accordance with the fourth aspect of the present invention includes applying dynamic risk analysis to a specific message to gauge the risk that the digital signature for the message was fraudulently originated and, thus, to determine whether or not to perform an instruction contained within the message.

As used herein, an “account holder” is generally any person possessing a device that is capable of generating a digital signature using a private key retained therein; the private key corresponding with a public key associated with an account upon which the person is authorized to act. An “account authority” is generally a person, entity, system, or apparatus that maintains such an account on behalf of the account holder. In some embodiments, the “account holder” is, itself, a device that is capable of generating a digital signature using a private key retained therein; the private key corresponding with a public key associated with an account upon which the device is authorized to act.

Having briefly described the methodologies of the various aspects of the present invention, general and specific implementations of two-party, three-party, and multiple-party Account-based Digital Signature (ABDS) systems now will be described in greater detail.

1. Account-based Digital Signature (ABDS) Systems

a. General 2-Party ABDS Systems

FIG. 2 illustrates a preferred Account-based Digital Signature (ABDS) system 200 in accordance with a first aspect of the present invention. Specifically, FIG. 2 illustrates a two-party ABDS system that includes an account holder 202 and an account authority 212. As shown, the account holder 202 comprises a person who possesses a device 250, which securely protects a unique private key of a public-private key pair therein. The account authority 212 comprises an entity or system that maintains one or more account databases, collectively referred to and illustrated by account database 214, which includes an account of the account holder 202. Preferably, the account is identifiable within the account database 214 based on a unique identifier (acctID) 216, such as an account number. Further, the account authority 212 maintains an association between the account and the public key 218, which corresponds with the private key that is securely retained within the device 250 of the account holder 202.

Communications between the account holder 202 and account authority 212 regarding the account of the account holder 202 occur through any conventional communications medium 208, such as the Internet, an intranet, a wireless network, a dedicated hardwired network, or the like. Each communication is electronic, and each electronic communication (“EC”) 206 from the account holder 202 to the account authority 212 includes an electronic message (M) that is digitally signed by the account holder 202 using the private key retained within the device 250. The means by which the device 250 communicates with the account authority 212 varies by the form factor of the device 250 and whether or not the device 250 is used in conjunction with a separate I/O support element (not shown) to assist in the generation or creation of the message, in the transmission or communication of the EC to the account authority 212, or both.

The message preferably includes the unique identifier (acctID) 216 of the account of the account holder 202 and an instruction (i1) for the account authority 212 to perform in relation to the account. The digital signature of the message also preferably includes a unique random number or session key, such as, for example, a date and time stamp, so that no two digital signatures originated by the device 250 would ever be identical (and also so that any duplicate digital signature received by the account authority 212 could be identified as such and disregarded).

Using the unique identifier (acctID) 216, the account authority 212 is able to retrieve the associated public key 218, which is necessary for authenticating the message and the sender of the EC 206 (i.e., based on Factor A Entity Authentication). In accordance with this first aspect of the present invention, upon the successful authentication of the message and of the sender of the EC 206, the account authority 212 performs (or attempts to perform) the instruction (i1) of the message as if the account holder 202 had presented such instruction (i1) in person.

Advantageously, since the unique identifier (acctID) 216 is all that must be included in the message in order for the account authority 212 to retrieve the appropriate public key 218 from the account database 214 for the purpose of authenticating the message and sender of the EC 206 and for having sufficient authorization from the account holder 202 for performing the instruction (i1) contained in the message, the account holder 202 need not include any “identity” information in the message. In addition, since the account authority 212 preferably will not perform any action on the account of the account holder 202 without a valid digital signature originated by the device 250 (or, alternatively, without the actual, physical presence of the account holder 202) and since no “identity” information needs to be included in electronic communications between the account holder 202 and the account authority 212 regarding the account, such electronic communications, including EC 206, may be transmitted in unencrypted fashion over an insecure communications medium 208 (such as the Internet) without risk of compromising the privacy of the account holder 202. Obviously, if the account holder 202 desires to protect the contents of the information contained within the EC 206 for privacy, confidentiality, or similar reasons, the EC 206 may be encrypted by the account holder 202 in conventional manner, for example, using the public key of the account authority 212 for PGP-type encryption, using secure socket layering (SSL), or other similar encryption techniques; however, encrypting the contents of the EC is not necessary for the functioning of the present invention.

FIG. 2a illustrates a plurality of possible relationships among the information contained within account database 214. Generally, each account within the database 214, for example, is identified by its account identifier (acctID) 216 and has associated therewith account information 240, such as information specific to the account holder (hereinafter “customer-specific information”) and information specific to the account (hereinafter “account-specific information”), and public key information 218. At a minimum, the public key information 218 identifies each public key (PuK) associated with each particular account and/or account identifier 216. As shown, database 214 maintains a plurality of specific accounts 281,282,283,284,285,288, with a plurality of accounts (not shown but indicated by the “. . .”) existing between accounts 285 and 288. Accounts 281,288 illustrate a first account setup type in which each account has a single customer or account holder and in which each account has a single public key (PuK) associated for use therewith. Account 282 illustrates a second account setup type in which the account 282 has a single customer or account holder associated therewith, but the account holder has a plurality (two, in this case) of different public keys (PuK) associated for use with the account 282. Such a setup is beneficial, for example, when an account holder uses more than one device of the present invention for access to the same account 282. A third account setup type is illustrated in association with accounts 283,284. Each of these accounts 283,284 has the same account holder, who uses a single public key to access either or both of these accounts 283,284. Such a setup is beneficial, for example, when an account holder maintains a plurality of accounts (in this case, two) with a single account authority (e.g., primary and secondary bank accounts with the same financial institution). This particular setup is discussed in greater detail in the “person-centric device” section set forth herein with regard to FIGS. 64–70. A fourth account setup type is illustrated in association with account 285. Account 285 has associated therewith a plurality of different customers or account holders (three, in this case), each of whom has a different public key (PuK) for accessing the account 285. Such a setup is beneficial, for example, when an account has two or more authorized users (e.g., husband and wife with access to a joint account; plurality of employees with access to their employer's account). A specific business implementation using this type of account setup is illustrated and discussed in association with FIGS. 46–49.

Although not shown in FIG. 2a, it should be apparent that the above four account setup types may be further combined with each other in a variety of permutations and still fall within the scope and intent of the present invention. As one example of such a combination not shown in FIG. 2a, one of the customers accessing account 285 could, in fact, have more than one public key for accessing the joint account 285.

Turning now to FIG. 2b, in a further feature of the present invention, account database 214 may also include Device Profile Information 270. Each Device Profile includes the Security Profile and transactional history of the device. The Security Profile includes the security features and manufacturing history of the device. The security features include those features of the device that protect the private key and other data within the device from discovery (“Security Characteristics”) and features that perform entity authentication (“Authentication Capabilities”). Information contained in the Security Profile is described in greater detail herein in Section VI.4, entitled “Applying Dynamic Risk Analysis to a Transaction.” Since it is contemplated that a unique private key associated with the corresponding public key 218 maintained with the account database 214 only exists in a single device of the present invention, there is a one-to-one correspondence between each public key 218 and its respective device profile information 270. Further, additional security is obtained with a device that is incapable of divulging its private key.

b. General 3-Party ABDS Systems

FIG. 3 illustrates a preferred three-party ABDS system 300 and includes an account holder 302 and account authority 312 as well as an intermediate party 310. The three-party ABDS system 300 differs from the two-party ABDS system 200 (from FIG. 2) in that the message and digital signature from the account holder 302 to the account authority 312 is communicated first to the intermediate party 310 by means of an EC 305. The intermediate party 310 then forwards the same message and digital signature in another EC 315 to the account authority 312.

An instruction (i2) is communicated from the account holder 302 to the intermediate party 310, either as part of the EC 305 or as a separate EC (not shown). The intermediate party 310 does not act upon the instruction (i2) but rather, forwards the EC 315 to the account authority 312 and waits for the account authority 312 to approve or reject the message. As shown, the message and digital signature in EC 315 are the same as the message and digital signature in EC 305.

Upon receipt of the EC 315, the account authority 312 attempts to authenticate the message and the sender of EC 305 using the public key of the public-private key pair, which 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 performs (or attempts to perform) the instruction (i1) of the message as if the account holder 302 were presenting the instruction (i1) in person. Based on the results of the attempted authentication of the message and the sender of the EC and based on the attempted execution of instruction (i1), the account authority 312 provides the intermediate party 310 with notification of approval or rejection of the message by means of a reply EC 319. If reply EC 319 indicates an approval of the message, the intermediate party 310 then executes the instruction (i2) received from the account holder 302. Preferably, the intermediate party 310 then notifies the account holder 302 either of the approval and execution of instruction (i2) or of the rejection of the instruction (i2) by means of reply EC 309.

Again, it should be noted that no “identity” information needs to be included in the EC 305 by the account holder 302 under this system 300. In addition, all of the ECs 305,315,309,319 may be transmitted in unencrypted fashion over any conventional communications mediums 308a,308b, such as the Internet, an intranet, a wireless network, a dedicated hardwire network, and the like, for the same reasons discussed above with regard to system 200 in FIG. 2. Also, as discussed above, if the parties desire to protect the contents of the information contained within the various ECs 305,309,315,319 for privacy, confidentiality, or similar reasons, such ECs may be encrypted by the sender of the particular EC in conventional manner, for example, using the public key of the intended recipient(s) of the particular EC for PGP-type encryption, using secure socket layering (SSL), or other similar encryption techniques; however, encrypting the contents of the various ECs is not necessary for the functioning of the present invention. Further, the communication mediums 308a,308b may be different from each other (as illustrated) or part of the same medium.

c. Multiple-Party ABDS Systems

Although not shown specifically in FIGS. 2 and 3, it should be understood that one or more additional parties or entities may be introduced along the communication route between the account holder, intermediate party, and account authority within the scope of the present invention. Among other things, such additional parties may be useful for expediting, screening, and correctly routing electronic communications between the various account holders, intermediate parties, and account authorities.

d. General Account Set-up in ABDS Systems

Of course, before either ABDS system 200,300 is utilized in practice, the account holder 202,302 first must establish an ABDS account with the appropriate account authority 212,312. The steps involved in establishing a new ABDS account are set forth in FIGS. 4a and 4b. The steps involved in converting a pre-existing (and conventional) account into an ABDS account are set forth in FIGS. 5a and 5b.

i. Establishing a New ABDS Account

Referring first to FIG. 4a, one exemplary process of establishing a new account within the ABDS system is illustrated. In this particular embodiment, the process is initiated by an account authority. For example, the account authority first establishes (Step 402) a “shell” account for a prospective account holder using publicly available information about the prospective account holder, such as name and address. The account authority next assigns (Step 404) a unique account identifier to the “shell” account and associates it therewith. The account authority then obtains (Step 406) the public key from a device of the present invention and records (Step 408) the public key in the account database and associates it with the “shell” account or with the unique identifier. In some embodiments of the present invention, the unique identifier may actually be the public key from the device or a hashed version of the public key. The account authority then distributes or sends (Step 410) the device that retains the private key corresponding with the public key associated with the “shell” account to the prospective account holder with an offer to “open” an account on behalf of the prospective account holder with the account authority and with instructions for doing so. The account authority then waits for a response from the prospective account holder.

If a response is received (Step 412), the account authority uses conventional authentication techniques to confirm that it is communicating with the prospective account holder. The account authority then obtains (Step 414) additional information, as needed, to populate the account record. The account authority then requires (Step 416) the prospective account holder to transmit a test message that is digitally signed using the device. Such test message confirms that the prospective account holder possesses the correct device. If the test message confirms, then the device is “activated” (Step 418) for use with the associated account.

In an alternative embodiment, setup of a new ABDS account may be initiated by a prospective account holder who already possesses a device of the present invention, as illustrated in FIG. 4b. For example, an account authority may receive (Step 450) a request to establish a new ABDS account from such a prospective account holder. If the account authority is willing to accept such a prospective account holder who already possesses such a device, the account authority receives (Step 452) sufficient information from the prospective account holder to establish such an account. In some business applications, it is not necessary for the prospective account holder to divulge any “identity” information in order to establish such an account. The account authority then records (Step 454) whatever information is provided by the prospective account holder in a record of the account database of the account authority and assigns (Step 456) a unique identifier, such as an account number, to the account.

Next and preferably contemporaneously, the account authority obtains (Step 458) the public key that corresponds with the private key that is securely retained on the device. In some business applications, the public key is obtained directly from the device in response to a suitable request submitted to the device. In other business applications, the public key is obtained from a database maintained by a third party, such as a Central Key Authority (as discussed below with reference to FIGS. 71a–72), device manufacturer, device distributor, or the like. The account authority then records (Step 460) the public key in such a manner that the public key is suitably bound to or associated with the account record of the prospective account holder. Preferably, the public key is associated particularly with the unique identifier of the account. In some embodiments, the public key itself (or a hashed value of the public key) is used as the unique identifier assigned to the account.

Finally, it also is preferable for the account authority to confirm proper binding of the public key to the account and to confirm that the device retains the private key, which corresponds with the public key bound to the account, by having the account holder submit (Step 462) a “test” EC for authentication, which may contain the corresponding public key being registered. Once the account authority is satisfied that the account has been established properly and that the account holder possesses the device retaining the appropriate private key corresponding with the public key being registered, the account is activated (Step 464) so that transactions that are digitally signed using the device will be deemed to have come from the legitimate account holder according to Factor A Entity Authentication.

In the above embodiment, the account authority may desire to confirm that the integrity level of the device, as confirmed by the Security Profile of the device obtained from the Central Key Authority or other reliable source or as confirmed by a physical inspection of the device, meets or exceeds its business standards or requirements for use with the respective account.

ii. Converting a Pre-existing Account Into an ABDS Account

Referring now to FIG. 5a, an exemplary process of converting a pre-existing, conventional account into an ABDS account, when initiated by an account authority, is set forth. First, it is assumed that the account authority already maintains a conventional account setup for the account holder in a record of an account database. Further, such record contains personal and other pertinent account information of the account holder. It is also assumed that the existing account already has its own unique identifier.

First, the account authority obtains (Step 502) the public key from a device of the present invention and records (Step 504) the public key in the account database and associates it with the existing account or with the unique identifier of the account. The account authority then distributes or sends (Step 506) the device that retains the private key corresponding with the public key associated with the existing account to its account holder with an offer to “convert” the existing conventional account to an ABDS account. The account authority then waits for a response from its account holder.

If a response is received (Step 508), the account authority uses conventional authentication techniques to confirm that it is communicating with its expected account holder. The account authority then requires (Step 510) the account holder to transmit a test message that is digitally signed using the device. Such test message confirms that the account holder possesses the correct device. If the test message confirms, then the device is “activated” (Step 512) for use with the newly converted ABDS account.

In an alternative embodiment, conversion of a conventional account to an ABDS account may be initiated by an existing account holder who already possesses a device of the present invention. For example, the account authority receives (Step 550) a request to convert a conventional account into an ABDS account, which enables the account holder to transact business on the account using electronic messages digitally signed using the account holder's specified device. If the account authority is willing to accept such a conversion and is willing to allow the account holder to use such a device, the account authority first confirms (Step 552), using conventional entity authentication techniques, that it is communicating or otherwise dealing with the expected account holder. Next and preferably contemporaneously, the account authority obtains (Step 554) the public key that corresponds with the private key that is securely retained on the device. In some business applications, the public key is obtained directly from the device in response to a suitable request submitted to the device. In other business applications, the public key is obtained from a database maintained by a third party, such as a Central Key Authority (as discussed below with reference to FIGS. 71a–72, device manufacturer, device distributor, or the like. The account authority then records (Step 556) the public key in such a manner that the public key is suitably bound to or associated with the existing account record of its account holder. Preferably, the public key is associated particularly with the unique identifier of the account. In some embodiments, the public key itself (or a hashed value of the public key) is used as the unique identifier assigned to the account.

Finally, it also is preferable for the account authority to confirm proper binding of the public key to the account and to confirm that the device retains the private key, which corresponds with the public key bound to the account, by having the account holder submit (Step 558) a “test” EC for authentication, which may contain the corresponding public key being registered. Once the account authority is satisfied that the account has been established properly and that the account holder possesses the device retaining the appropriate private key corresponding with the public key being registered, the account is activated (Step 560) so that transactions that are digitally signed using the device will be deemed to have come from the legitimate account holder according to Factor A Entity Authentication.

e. Devices Useful With ABDS Systems

In accordance with all of the aspects of the present invention, the device comprises hardware, software, and/or firmware, and specifically comprises a computer chip, an integrated circuit, a computer-readable medium having suitable software therein, or a combination thereof. The device further may comprise a physical object such as a hardware token or an embedded token, the token containing such a computer chip, integrated circuitry, or software, or combination thereof. If the device is a hardware token, it preferably takes the form of a ring or other jewelry; a dongle; an electronic key; a card, such as an IC card, smart card, debit card, credit card, ID badge, security badge, parking card, or transit card; or the like. If the device is an embedded token, it preferably takes the form of a cell phone; a telephone; a television; a personal digital assistant (PDA); a watch; a computer; computer hardware; or the like. The device preferably includes a device interface comprising a port—including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port—or some other physical interface for communicating with an external electronic apparatus, whether contact or contactless. The device also may include a trusted platform module (TPM) comprising hardware and software components providing increased trust in a platform, as set forth and described in 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, Jul. 4, 2001, both which are incorporated herein by reference (collectively “TCPA Documents”).

Preferably, the device is capable of receiving an electronic message and then originating a digital signature for the electronic message utilizing the private key stored therein. The device preferably also performs a hash function on the message received by the device prior to encryption with the private key.

Additionally, it is preferred that the device include a device interface, such as, for example, an alphanumeric keypad, an electrical contact, a touch screen display, a standard electronic interface with a computer bus, or an antenna, so that the device not only may receive a message, but also compose a message. The device interface may also comprise a port, such as a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port.

Some of the above devices require use of an I/O support element to enable the device to receive messages or other input. Some of the devices require use of an I/O support element to transmit information, including digital signatures and messages to recipients of the ECs. Some of the devices are self-contained, which means that they can generate and transmit messages, digital signatures, and other information without the use of external apparatuses; some devices, although self-contained, are capable of interacting with such external apparatuses, such as an I/O support element, if desired. An I/O support element may take the form of any number of different apparatuses, depending upon the particular application in which it is used and depending upon the form factor of device with which it interacts. One example of an I/O support element includes a card reader comprising hardware and software components designed in accordance with the technical specifications published by CEN/ISSS as a result of their Financial Transactional IC Card Reader Project (known commonly as “FINREAD”).

With regard to the security of the device used in each aspect of the present invention, preferably during the manufacture of the device, a unique and random public-private key pair is generated directly within the device (using a random number generator), preferably on a computer chip, integrated circuit, or other cryptographic module embedded therein, using known manufacturing techniques. Because of the size of the private key and because the key is generated using a random number generator, the likelihood that a duplicate private key might exist in a different device is very low. The private key then is securely stored within a memory location in the device and, preferably, made inaccessible throughout the life of the device (other than for the purpose of generating a digital signature internally within the device). Furthermore, the device preferably includes the following additional characteristics: it is tempested (i.e., designed in such a way to minimize electromagnetic emanations from the device and, thus, minimize its vulnerability to electronic eavesdropping); the device is immune to known electronic attacks; the device is tamper-resistant with zeroization capability (i.e., physical tampering or intrusion of the device should destroy the functionality of the digital signature component of the device and/or erase the private key); the device maintains the private key securely such that the private key is never divulged outside of the device; and the device allows export of the public key when necessary.

Furthermore, the device preferably originates digital signatures in accordance with an elliptical curve digital signature algorithm (ECDSA) as specified in Federal Information Processing Standards Publication 186-2, Digital Signature Standard, US DOC/NBS, Jan. 11, 1994 (hereinafter “FIPS PUB 186-2”), which is incorporated herein by reference. Accordingly, the device originates digital signatures using a random number generator, and the hash function is performed using the secure hash algorithm (“SHA-1”), which generates a 20-byte output regardless of the size of the message that is input into the device. The SHA-1 itself is specified in Federal Information Processing Standards Publication 180-1, Secure Hash Standard, US DOC/NBS, Apr. 17, 1995 (hereinafter “FIPS PUB 180-1”), which is hereby incorporated by reference.

In the aspects of the invention, the device preferably is personalized to its authorized user(s). Personalization of the device includes the establishment of a personal identification number (PIN), password, or passphrase (hereinafter “Secret”). Conventionally, such a Secret is prestored within the device and must be input into the device before it will operate to generate digital signatures. Alternatively, but also conventionally, the Secret is shared with the recipient beforehand and, when the EC later is sent to the recipient, the Secret also is sent to the recipient in association with the message. In the first case, verification of the Secret authenticates the user of the device (hereinafter “User Authentication”), and in the second case, verification of the Secret authenticates the sender of the EC (hereinafter “Sender Authentication”). If the Secret is shared and transmitted between the sender of an EC and the recipient, it typically must be encrypted or otherwise protected to maintain its secrecy from others. In either case, confirmation of the Secret represents entity authentication based on what the user or sender “knows” (hereinafter “Factor B Entity Authentication”).

Other security measures against fraudulent use of the device through physical theft include the verification of a biometric characteristic—like a fingerprint, retina scan, DNA, voice print, and the like—of the user of the device or sender of the EC. This type of authentication is based on what the user or sender “is” (hereinafter “Factor C Entity Authentication”). As with the Secret, a biometric value is conventionally either maintained within the device for User Authentication, or is shared with the recipient beforehand for Sender Authentication by the recipient. If the biometric value is shared and transmitted between the sender of an EC and the recipient, even greater precautions must be taken to protect such biometric value from interception and discovery by others.

In contrast with both of the above methods of providing Factor B and Factor C Entity Authentication information to the recipient of the EC, an alternative method of providing Entity Authentication status from the account holder to the account authority in which the Secret and/or biometric value(s) is provided to the device and an indicator representing the results of the comparison of such Secret and/or biometric value(s) with data prestored in the device is provided to the recipient of the EC without communicating or compromising the Secret and/or biometric value(s) may also be used with the present invention. Such a methodology is described in greater detail in the VS Applications.

f. Types of and Uses for ECs in an ABDS System

As stated previously with regard to both FIGS. 2 and 3, an EC from an account holder to an account authority preferably includes both a message (M) and a digital signature of the message (DS(M)). The message preferably includes the unique account identifier (acctID) and an instruction (i1) for the account authority to perform in relation to the account. In many circumstances, however, it is not necessary for the message to contain the unique account identifier. For example, the account authority may have already obtained the unique account identifier from a previous message from the account holder and retransmission of the account identifier is unnecessary for a follow-up message from the same account holder—as long as the account authority knows that it is communicating with the same account holder (e.g., by means of a session key or identifier or during a continuous, uninterrupted electronic connection between the two). Further, it is not always necessary for the message to contain an instruction (i1), such as, for example, when the instruction (i1) is implicit in the mere communication between the account holder and the account authority (e.g., an instruction (i1) in an EC sent to a parking gate controller obviously implies an instruction to “open the parking gate”).

ECs, and the ability to authenticate the sender of an EC, are useful for at least three different business purposes within the present invention. These three different purposes are described generally hereinafter as “session authentication,” “transaction authentication,” and “transaction confirmation.” Session authentication and transaction authentication are similar to each other since both typically involve situations in which the account holder must “prove” (at least to the extent possible based on the strength of the entity authentication) to the account authority that he is the legitimate account holder. In contrast, transaction confirmation typically involves situations in which the account holder has already proven to the account authority that he is the legitimate account holder; however, the account authority requires confirmation of a specific digitally-signed message from the account holder before the account authority will perform a requested action (typically, upon the account itself) in response to a specific instruction (i1) contained within the message.

Session authentication and transaction authentication are generally necessary before the account authority will grant the account holder with access to the account of the account holder or to another resource to which the account holder has rights. Such authentication is also generally necessary before the account authority will perform a requested action on the account or resource. A resource is, for example, a physical space, database, computer file, data record, checking account, computer system, computer program, web site, or the like. A main distinction between session authentication and transaction authentication is what the account authority does as a result of such authentication. For example, once the account holder is authenticated for session authentication purposes, the account authority provides the account holder with access (by means of a session key, entity identifier, and the like) to the requested account or resource for the duration of the “session.” The meaning of a session varies depending upon the type of account or resource being accessed and depending upon the business rules of the particular account authority protecting the account or resource; however, a session typically means some period of time during which the account holder is allowed to perform actions on or within the account or resource without providing additional authentication to the account authority. In addition, the amount of access to the account or resource an account holder is granted is also governed by the business rules of the particular account authority and may vary from account authority to account authority and from account to account.

In contrast, transaction authentication is typically only useful for the particular transaction with which it is associated. Transaction authentication associated with a particular transaction is not “carried over” for use with another transaction. Such a transaction may be a request for the account authority to perform a specific action on the account or resource (e.g., a request for the account authority to “provide checking account balance” or “open the door”). In contrast with transaction confirmation (described in the next paragraph), however, transaction authentication is useful when the account authority does not specifically need to know the “intent” of the account holder before performing the requested action.

Transaction confirmation, on the other hand, is useful when the value or risk associated with a particular transaction rises to the level that the account authority will not act unless it receives sufficient assurance that the account holder intended to send and digitally sign the message and, corresponding, intended for the account authority to act in reliance thereupon. Since a digital signature is capable of being generated by a device, potentially without the desire or even knowledge of the owner or user of the device, intent cannot be presumed from the mere receipt of a digital signature from a device of the account holder. For this reason, some means of confirming the account holder's intent with respect to a specific transaction is needed. Such transaction confirmation is preferably obtained by a physical, overt act performed by the account holder that is determinable within the message received by the account authority. For example, in some instances, the contemporaneous provision of Factor B or C entity authentication information by the account holder in conjunction with the message that is digitally signed can imply confirmation or intention. Another method of obtaining such transaction confirmation is through the deliberate and recognizable modification by the account holder of a “proposed” message generated by the account authority, which is then digitally signed by the account holder.

In light of the above, it should be understood that in many circumstances, even if the account holder has already provided entity authentication information for the purpose of session authentication, it may be necessary for the account holder to provide additional and/or stronger entity authentication information (still for session authentication purposes) before the account authority will provide the account holder, for example, with access to a more restricted portion of the particular account or resource or to another more restricted account or resource. Further, it should also be understood that even during a particular session, it may be necessary for the account holder to provide entity authentication information to the account authority either for transaction authentication purposes (when the transaction requires a stronger level of entity authentication than the particular session required) or for transaction confirmation purposes (when the account authority desires specific assurance of the account holder's intent before performing the requested action). In addition, it should also be understood that a single EC communicated from an account holder to an account authority may be used simultaneously for both transaction authentication and for transaction confirmation purposes in many circumstances.

Turning now to FIG. 74, an example of an EC 7406 used for session authentication purposes is illustrated. As shown, an account authority 7412 acts as a type of “gate-keeper” for three resources 7440,7450,7460, one of which the account holder 7402 desires to access as requested in the EC 7406. Although only one account authority 7412 is illustrated in this example for ease of reference, it should be understood that each resource 7440,7450,7460 could, in fact, have its own separate account authority (not shown) associated therewith.

Continuing with FIG. 74, the account authority 7412 restricts access to the resources 7440,7450,7460, directly or indirectly, by preventing the account holder 7402 from proceeding through gates 7494a, 7494b, or 7494c until the account holder 7402 has provided the account authority 7412 with a “sufficient” level of entity authentication—at least to the extent required by the particular gate 7494a,7494b,7494c. For reasons that should be readily apparent, the level of entity authentication required by each gate varies depending upon what the specific resource is that is being protected. For example, if the resource is a parking deck, only a minimal level of entity authentication is necessary; if the resource is a corporate checking account, stronger entity authentication is likely required; if the resource is the control system for launching nuclear warheads, even stronger entity authentication is required.

In some circumstances, providing a sufficient level of entity authentication is all that is needed to obtain access to the resource. For example, gate 7494a provides the only session authentication hurdle to account holder 7402 for accessing resource 7440 (although, of course, the amount of access provided to the account holder 7402 and the process by which the account holder 7440 is able to access the resource may be further restricted by permissions and access rights, which are not discussed in detail herein). Alternatively, as illustrated by resource 7450, providing a sufficient level of entity authentication to pass through gate 7494b enables the account holder 7402 to access resource 7450 generally and to access sub-resources 7450a,7450b (nested within the confines of resource 7450) specifically. Notably, stronger entity authentication is necessary before account holder 7402 is given access to sub-resource 7450c, as indicated by gate 7494d. In another alternative arrangement, providing a sufficient level of entity authentication to pass through gate 7494c enables the account holder 7402 to access not only resource 7460 but also independent resources 7470,7480,7490, which are not within the protective confines of resource 7460 but which allow the account holder 7402 with access therein when the account holder 7402 has provided sufficient entity authentication to pass through gate 7494c.

As stated previously, in some circumstances, the particular resource 7440,7450,7460 is not only protected but also maintained by the account authority 7412 (for example, if the account authority 7412 is a financial institution and the resource is a bank account of the account holder 7402). In other circumstances, the particular resource 7440,7450,7460 is merely protected by the account authority 7412, which is in communication and coordination with another entity, such as a resource manager, access controller, or authorization controller (not shown), that actually maintains the resource (for example, if the account authority 7412 is merely an entity authentication system and the resource is a secure network server, to which access and permissions are controlled by a separate access control server).

The illustration of FIG. 74 is equally applicable to an EC used for transaction authentication purposes. For example, if EC 7406 contains a specific request for information from one of the resources 7440,7450,7460 or a request for the account authority 7412 to perform a specific action on or in one of the resources 7440,7450,7460, then the EC 7406 is used for entity authentication solely for that particular request; however, no on-going or session access to the particular resource 7440,7450,7460 is granted as a result.

Turning now to FIG. 75, three different examples of ECs between an account holder 7502 and an account authority 7512 over communications medium 7508 are illustrated. In all three examples, the last EC from the account holder 7502 to the account authority 7512 is used for a transaction confirmation purpose.

In the first interchange, designated by EC 1A in FIG. 75, the account holder 7502 transmits an EC, which contains a message (M1) and a digital signature for the message (DS(M1)). In this interchange, the account holder 7502 provides sufficient proof of intent and Factor B or C Entity Authentication such that the account authority 7512 requires no follow-up EC requesting confirmation.

In the second interchange, designated by ECs 2A, 2B, and 2C and still with reference to FIG. 75, the account holder 7502 transmits an EC, which contains a message (M2) and a digital signature for the message (DS(M2)). In this interchange, the account authority 7512 is not satisfied that it has received sufficient proof of the account holder's intent as applied to the message (M2). For this reason, the account authority 7512 sends EC 2B to the account holder 7502; EC 2B requests that the account holder 7502 send a new EC with the same message (M2) and digital signature therefor (DS(M2)) but with the additional performance of Factor B or C Entity Authentication, an indicator (EAI) of which is included therewith as “proof” that the account holder 7502 did intend to send EC 2A. As shown, the message of EC 2C is essentially the same as the message of original EC 2A with the addition of the Entity Authentication indicator (EAI). Such Entity Authentication indicator (EAI), preferably, is included within the message (M2) that is digitally signed.

In the third interchange, designated by ECs 3A, 3B, and 3C and still with reference to FIG. 75, the account holder 7502 transmits an EC, which contains a message (M3) and a digital signature therefor (DS(M3)). In this interchange, the account authority 7512 is not satisfied that it has received sufficient proof of the account holder's intent as applied to the message (M3). For this reason, in this example, the account authority 7512 sends EC 3B to the account holder 7502; EC 3B contains a proposed new message (M4) for review and digital signing by the account holder 7502. Message (M4) is composed by the account authority 7512 and preferably contains most, if not all, of the information that was contained in message (M3). Message (M4) may also contain additional information not contained in message (M3). Further, EC 3B requests that, if the account holder 7502 agrees with and accepts the contents of message (M4), that the account holder 7502 modify the message (M4) in a specified manner (indicated in EC 3B or 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) thereof within EC 3C; however, it is not required since account authority 7512 did not request it in EC 3B.

g. Data Structure and Formats for ECs in an ABDS System

Referring now to FIG. 76, an electronic communication (EC) 7601 in accordance with various aspects of the inventions described herein includes various data fields, elements, or portions, generally speaking, a message (M) 7603 and a digital signature (DS) 7605. These components generally form a data structure that may be stored, communicated, or otherwise manipulated with computing and communications apparatuses, according to the methods described herein. The EC 7601 may be included with, and/or form a part of, a financial transaction in accordance with ISO Standard 8583, which is incorporated herein by reference, or an X9.59 transaction.

In accordance with known data communication formats and/or data structure conventions, the EC 7601 typically includes a header portion 7607, a body 7609, and a trailer portion 7611. The header portion 7607 and trailer portion 7611 are conventional in nature and are provided for conventional purposes, such as identification of the EC, routing, error correction, packet counting and sequencing, and other purposes, as will be known to those skilled in the art.

According to a first arrangement of this aspect of the invention, the body portion 7609 comprises a message 7603 and the digital signature 7605 therefor (separated by a hashed line in the illustration). The message 7603 preferably includes an account identifier 7616 and message content 7618. The message content can include various types of information such as a further identifier, a command or instruction (i1) relating to the account, the public key (PuK) associated with the account, time/date stamp, encrypted message, and the like. The digital signature 7605 comprises information from the message 7603 (for example, a hash of the message, the message itself, or a compressed), signed with the sender's private key.

According to a second arrangement, the body portion 7609 comprises the account identifier 7616 and a message content portion 7618, which incorporates the digital signature 7605 (ignoring the hashed line). The account identifier 7616 may be considered a separate component from the message content 7618. Similar to the first arrangement, the digital signature 7605 portion of the message content 7618 comprises other information from the message content 7618, signed with the sender's private key.

Under either of the above arrangements, the EC 7601 includes the account identifier 7616 and the digital signature 7605 as significant components thereof.

It will be appreciated that the digital signature 7605 of any arrangement of data elements may constitute information such as the account identifier, a further identifier, an instruction or command relating to the account, the public key (PuK) of the sender of the EC, and/or other information, depending upon the particular application contemplated by the user of the invention. AS stated previously, the message 7603 need not contain the account identifier 7616, e.g. the account identifier is implied or inferred, or obtained from, the message. For example, the recipient of the EC may have already obtained the account identifier 7616 from a previous message from the sender of the EC and retransmission of the account identifier 7616 is not needed. Further, it is not necessary for the message 7603 or message content 7618 to contain an instruction or command, for example, when the instruction is implicit in the communication between the sender of the EC and the recipient thereof.

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

h. Specific Implementations of 2-Party ABDS Systems

The preferred ABDS systems 200,300 of FIGS. 2 and 3 may be implemented in a vast number of wide-ranging business applications. Because the specific applications are so numerous, the following specific examples are described in detail herein only to illustrate the scope and breadth of possible implementations and are not intended to be limitations on the type of business applications in which the ABDS systems 200,300 may be implemented. In addition, the specific device used with each particular business application is chosen merely for illustrative purposes and is not intended to imply or suggest that other devices shown (or not shown) in any other figure cannot be used therewith. To the contrary, any device, regardless of form, can be used in most, if not all, business applications utilizing the ABDS systems 200,300 of FIGS. 2 and 3, limited only by the available infrastructure within which such device is capable of operating.

In all of the following examples, it is presumed that the account holder has already established an ABDS account with the relevant account authority; thus, the account maintained by the account authority has associated therewith the public key that corresponds with the private key, which is securely protected in the device, which is in the possession of the account holder. In all of the following examples, it is also presumed that there is no need to encrypt the contents of the particular comunications between the various entities, including the account holders and the account authorities; however, if any of the entities desires to protect the contents of the information contained within the various ECs between them for privacy, confidentiality, or any similar reasons, such ECs may be encrypted by the sender of the particular EC in conventional manner, for example, using the public key of the intended recipient(s) of the particular EC for PGP-type encryption, using secure socket layering (SSL), or other similar encryption techniques; however, encrypting the contents of the various ECs is not necessary for the functioning of the present invention.

In addition, in many of the specific business applications described hereinafter, the account holder is prompted or asked to perform Factor B or Factor C Entity Authentication as part of the process of composing and transmitting an EC to the account authority. It should be understood that mere use of the device is sufficient for providing Factor A Entity Authentication (since authenticating the message inherently confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message), which, in many circumstances, is sufficient entity authentication for the account authority to act upon the message or instruction (i1) contained in the EC from the account holder. Performance of Factor B and/or Factor C Entity Authentication, while not necessary for the present invention, does strengthen the entity authentication provided by the account holder and, correspondingly, increases the amount of trust the account authority has in the system and in the fact that it is dealing with the legitimate account holder.

Further, the methodology by which Factor B and/or Factor C entity authentication is managed between the account holder, the device, the account authority, and other entities within the ABDS systems described herein is not specifically set forth in these implementations. It should be assumed that such User or Sender Authentication is handled in conventional manner (as described above) or as described in the VS Applications.

i. Financial Institution Account

A first business application 600 implementing the two-party ABDS system 200 of FIG. 2 is illustrated in FIG. 6. In this example, an account holder 602 comprising a person possesses a device in the form of a card 650, such as an IC card, credit card, or ATM card, which is capable of being used at an ATM machine 660 or the like. The card 650 securely protects therein a private key of a 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. The card 650 is associated with a debit or credit account maintained with an account authority comprising a financial institution 612. The account may be a checking account, savings account, money market account, credit card account, or the like, and the financial institution may be a bank, savings and loan, credit card company, or the like. In this example, the ATM machine 660 communicates electronically with the financial institution 612 over a secure, internal banking network 608.

Accounts maintained with the financial institution 612 are associated with account records maintained in one or more account databases, collectively referred to and illustrated in FIG. 6 by account database 614. With reference to FIG. 7, each account includes a unique account identifier comprising an account number 716. Each account number 716 identifies within the account database 614 account information 740, including customer-specific information 742 and account-specific information 744. In accordance with the present invention, the account number 716 also identifies public key information 718, which includes at least a public key of an account holder of the respective account. Also in accordance with a feature of the present invention, the account number 716 identifies device profile information 770 for the device that retains the private key corresponding with the public key associated with the account.

In the example of FIG. 6, the customer-specific information 742 includes, for example, the name, address, social security number and/or tax-ID number of the account holder. The account-specific information 744 includes, for example, the current account balance, available credit, closing date and balance of current statement, and associated account identifiers. The public key information 718 of the account of the account holder 602 includes the public key corresponding to the private key retained within the card 650. The device profile information 770 includes information specific to the card 650.

As stated previously, an EC from the account holder 602 to the financial institution 612 may be used for three different purposes: session authentication, transaction authentication, and transaction confirmation. In this business application, the most common type of EC is used merely for session authentication, which occurs when the account holder 602 initially attempts to login to or otherwise access the ATM machine 660.

Regardless of which type of EC is communicated from the account holder 602 to the financial institution 612, the basic methodology for composing and digitally signing the message (on the account holder end) and for authenticating the message and authenticating the entity (on the account authority end) is essentially the same. For example, turning now to FIG. 8, a transaction in accordance with the present invention is initiated (Step 802) in the implementation illustrated in FIGS. 6 and 7 when the account holder 602 inserts the card 650 into the card reader 664 of the ATM machine 660. The insertion of the card 650 initializes the ATM machine 660, which, using display 662, prompts (Step 804) the account holder 602 to perform entity authentication, such as providing a PIN, using the alphanumeric keypad 666. Once the PIN is input, an electronic message is composed (Step 806) for sending to the financial institution 612.

The ATM machine 660 displays a menu of available accounts upon which the account holder 602 may perform an action. The available accounts are stored within memory on the card 650 and retrieved by the ATM machine 660 for display to the account holder 602. Of course, if only one account is available in memory on the card 650, then that account is selected by default without requiring specific selection by the account holder 602.

Upon selection of an account, the ATM machine 660 displays a menu of operations that can be performed on the selected account. Such operations include, for example, money withdrawal, balance inquiry, statement request, money transfer, money deposit, bill payment, and the like. Upon selection of the desired operation by the account holder 602, and after any additional information relating thereto is obtained from the account holder 602, such as a withdrawal or transfer amount and the like, the ATM machine 660 composes an electronic message that includes an instruction to the financial institution 612 corresponding to the desired operation of the account holder 602. The electronic message also includes the account number 716 corresponding to the account selected by the account holder 602.

The message then is transmitted (Step 808) to the card 650 for digital signing by the account holder 602. In this regard, upon receipt of data representing the message, the card 650 originates (Step 810) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 650. The card 650 then outputs (Step 812) the digital signature to the ATM machine 660, which then transmits (Step 814) the message and the digital signature therefor in an EC to the financial institution 612.

With reference to FIG. 9, the EC is received (Step 902) by the financial institution 612 from the ATM machine 660. The financial institution 612 then retrieves (Step 904) from the account database 614 the public key that is identified by the account number 716. Using this public key, the financial institution 612 attempts to authenticate (Step 906) the message. If the message does not authenticate (in Step 908) using the public key, then the financial institution 612 responds (Step

1. A method of communicating electronically over a communications medium regarding accounts, comprising the steps of: (a) for a first account, (i) maintaining information pertaining to the first account in an account database such that the information is retrievable based on a first unique identifier, (ii) associating a public key of a public-private key pair with the first unique identifier, (iii) generating a digital signature for an electronic message using a private key of the public-private key pair, the electronic message including an instruction and the first unique identifier, (iv) authenticating the electronic message using the public key associated with the information identified by the first unique identifier, and (v) upon the successful authentication of the electronic message, executing the instruction with respect to the first account represented by the information that is identified by the first unique identifier; and (b) for a second account, (i) maintaining information pertaining to the second account in an account database such that the information is retrievable based on a second unique identifier, (ii) associating the same public key that is associated with the first account with the second unique identifier, (iii) generating a digital signature for an electronic message using the private key of the public-private key pair, the electronic message including an instruction and the second unique identifier, (iv) authenticating the electronic message using the public key associated with the information identified by the second unique identifier, and (v) upon the successful authentication of the electronic message, executing the instruction with respect to the second account represented by the information that is identified by the second unique identifier.

2. The method of claim 1, wherein each account database is maintained by an account authority.

3. The method of claim 2, wherein each account database is maintained by a different account authority.

4. The method of claim 2, wherein both account databases are maintained by the same account authority.

5. The method of claim 2, wherein each said step of generating a digital signature for an electronic message is performed by a device of an account holder, the device including the private key of the public-private key pair.

6. The method of claim 5, wherein the account holder communicates with the account authority by sending the respective electronic message and digital signature in an electronic communication (“EC”) to the account authority.

7. The method of claim 6, wherein the account holder sends a respective EC directly to the account authority.

8. The method of claim 7, wherein the device includes each unique identifier with which the public key of the device is associated.

9. The method of claim 6, wherein the device communicates with the communications medium through a device interface.

10. The method of claim 9, wherein the device interface includes each unique identifier and the identity of each account authority with which the public key of the device is associated.

11. The method of claim 10, wherein the device further includes the identity of each account authority with which one of the accounts is maintained.

12. The method of claim 6, wherein the account holder sends a respective EC directly to an intermediate party, and the intermediate party communicates the electronic message and digital signature to the account authority.

13. The method of claim 12, wherein each said step of executing the instruction with respect to an account is preformed by the account authority.

14. The method of claim 13, wherein an additional instruction is communicated to the intermediate party by the account holder.

15. The method of claim 14, wherein the intermediate party executes the additional instruction upon successful execution by the account authority of the instruction with respect to the respective account.

16. The method of claim 14, wherein the additional instruction is sent in a separate EC from the account holder to the intermediate party.

17. The method of claim 14, wherein the additional instruction is included in the respective EC sent from the account holder to the intermediate party.

18. The method of claim 17, wherein the additional instruction is removed by the intermediate parry from the respective EC before being forwarded to the account authority.

19. The method of claim 1, further comprising the step of composing the electronic messages external to a device possessing the private key used to generate the digital signature.

20. The method of claim 19, further comprising the step of calculating a respective hash value for the electronic messages external to the device.

21. The method of claim 19, further comprising the step of inputting the electronic messages into the device for generation of the digital signature.

22. The method of claim 1, further comprising the step of composing the electronic messages within a device possessing the private key used to generate a digital signature.

23. The method of claim 22, further comprising the step of calculating a respective hash value for the electronic messages within the device.

24. The method of claim 1, wherein a device possessing the private key used to generate a digital signature of an electronic message plugs into a device interface.

25. The method of claim 24, wherein the device is swiped through the device interface.

26. The method of claim 1, wherein a device possessing the private key used to generate a digital signature of an electronic message transmits the digital signature to a device interface without physical contact therewith.

27. The method of claim 26, wherein the device transmits the digital signature trough wireless communication.

28. The method of claim 26, wherein the device transmits the digital signature through an RF transmission.

29. The method of claim 1, wherein a said step of executing an instruction is performed based solely on the successful authentication of the respective electronic message.

30. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises communicating a balance of the account.

31. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises debiting the account by a specified amount.

32. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises crediting the account by a specified amount.

33. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises transferring funds to another account.

34. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises granting access to a database.

35. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises granting access to a physical location such as a room, building, parking deck, and web site.

36. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises granting access to a data transmission such as pay per view, music download, and web broadcast.

37. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises providing a product.

38. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises providing a service.

39. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises making a monetary payment from the respective account.

40. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises transferring something of monetary value from the account.

41. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises transferring a security from the account.

42. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises authorizing a charge to the account.

43. The method of claim 1, wherein execution of an instruction with respect to at least one of the accounts comprises transferring information from the account.

44. The method of claim 1, further comprising retrieving from one of the respective account databases the public key associated with the unique identifier of the electronic message.

45. The method of claim 1, further comprising, for one of the accounts, communicating notice of a rejection of the respective electronic messages.

46. The method of claim 1, wherein the public key associated with the respective unique identifier in a message is included in the respective message.

47. The method of claim 1, wherein at least one of the respective unique identifiers comprises an associated public key.

48. The method of claim 1, wherein at least one of the respective unique identifiers comprises an account number of the respective account.

49. The method of claim 1, wherein the information includes an account number.

50. The method of claim 1, wherein the information includes a current balance for the respective account.

51. The method of claim 1, wherein the information includes an available credit for the respective account.

52. The method of claim 1, wherein the information includes a list of associated accounts.

53. The method of claim 1, wherein the information includes the name of an account holder.

54. The method of claim 1, wherein the information includes the address of an account holder.

55. The method of claim 1, wherein the information includes the social security number of an account holder.

56. The method of claim 1, wherein the information includes the tax identification number of an account holder.

57. The method of claim 1, wherein the information regards a device possessing the private key used to generate at least one of the digital signatures.

58. The method of claim 1, wherein the information includes security characteristics of a device possessing the private key used to generate at least one of the digital signatures.

59. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a personal computer.

60. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a cell phone.

61. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a PDA.

62. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises an electronic key.

63. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a dongle.

64. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a subcutaneous implant.

65. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a secure chip.

66. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises jewelry.

67. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises an IC card.

68. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a credit card.

69. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a debit card.

70. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises a security card.

71. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures comprises an ID badge.

72. The method of claim 1, wherein a device possessing the private key used to generate at least one of the digital signatures transmits the digital signature through physical contact with a device interface.

73. The method of claim 1, wherein the communications medium is open and insecure.

74. The method of claim 1, wherein the communications medium comprises the Internet.

75. The method of claim 1, wherein at least one of the electronic messages is not encrypted.

76. The method of claim 1, wherein at least one of the electronic messages is encrypted.

77. The method of claim 1, wherein at least one of the electronic messages includes no personally-identifying information regarding an owner of the account.

78. The method of claim 1, wherein at least one of the electronic messages includes no account identifying information other than the respective unique identifier of an account.

79. The method of claim 1, wherein a said step of associating a public key with a unique identifier comprises recording the public key with the information retrievable based on the respective unique identifier.

80. The method of claim 1, wherein a said step of associating a public key with a unique identifier comprises indexing the information retrievable based on the respective unique identifier with the public key.

81. A device used in communicating electronically over a communications medium regarding an account, the device including, (a) a private key of a public-private key pair; (b) a plurality of unique account identifiers, each identifying an account maintained by an account authority with which the public key of the public-private key pair is associated.

82. The device of claim 81, further including the identity of the respective account authority maintaining each of the identified accounts, whereby an electronic message which is digitally signed by the device may be directed to the respective account authority maintaining the account which the communication regards.

83. The device of claim 81, wherein the identity of the respective account authority maintaining each of the identified accounts is determinable from the respective unique account identifiers, whereby an electronic message which is digitally signed by the device may be directed to the respective account authority maintaining the account which the communication regards.

84. The method of claim 81, wherein a unique identifier comprises an associated public key.

85. The method of claim 81, wherein a unique identifier comprises an account number of an account.

86. The method of claim 81, wherein the communications medium is open and insecure.

87. The method of claim 81, wherein the communications medium comprises the Internet.

88. The method claim or 81, wherein an electronic message which is digitally-signed by the device is not encrypted.

89. The method of claim 81, wherein an electronic message which is digitally-signed by the device is encrypted.

90. The method of claim 81, wherein an electronic message which is digitally-signed by the device includes no personally-identifying information regarding an owner of the account.

91. The method of claim 81, wherein an electronic message which is digitally-signed by the device includes no account identifying information other than a unique identifier of an account.