Patent Application
20080162158
The technical field of the invention relates generally to authentication services and more specifically to the area of compensation systems for authentication services.
In its most general sense, authentication may be defined as a determination that a person (or thing) is a particular person (or thing). In the context of computer systems, authentication is a determination that someone (or thing, in the case of an object or a device such as a computer) is, has, or is capable of reproducing an authentication factor and a corresponding authentication factor value; the authentication factor and/or authentication factor value generally being associated with a particular person (or thing).
Authentication factors may generally be classified according to the following categories: i) Something the user is (e.g., a fingerprint or retinal pattern, a voice pattern, or another biometric identifier or physical attribute); ii) Something the user has (e.g., an identification card or chip, a security token, a phone or email address, etc.); or iii) Something the user knows (e.g., a password, phrase, or PIN).
Authentication factor values are generally produced by and/or associated with an authentication factor. Certain authentication factors may have only one authentication factor value, while other authentication factors may have or produce a range of authentication factor values. In the case of something the user is, authentication factor examples often include physical attributes such as fingerprints, retinal or voice patterns, or other biometric or other physical attributes; in such examples, the authentication factor value is a particular fingerprint, retinal or voice pattern, or the like. In the case of something the user has, an example of an authentication factor is a specialty purpose digital signal processor (“DSP”) which produces a unique number and/or character string or another unique output; the authentication factor value in such an example is a particular instance of the unique number and/or character string output by the DSP. Another example of an authentication factor which falls into the category of something the use has is an access card (the authentication factor) magnetically encoded with a unique identifier (the authentication factor value of the card). In the case of something the user knows, the authentication factor may be a password, phrase, or personal identification number or “PIN,” while the authentication factor value is the specific password, phrase, or PIN known to the user.
The distinctions drawn between these authentication factor categories (is/has/knows) generally assume a human user, though the user (the party or object to be authenticated) may include a physical object, including a computer. A thing, device, or computer can have an electronic, magnetic, structural, or other physical attribute (as well as a particular instance of the physical attribute). A thing, device, or computer can also have a particular thing, such as an ID card or chip, which acts as an authentication factor. A thing, device, or computer can also be said to “know” something such as a password, phrase, or PIN, to the extent the object is programmed or otherwise provided with an embodiment of the “known” information. In the context of things, devices, or computers, however, the placement of authentication factors in the categories, above, depends upon how the concepts of “being,” “having,” and “knowing,” are applied to inanimate objects (does the object “have” a security chip, or is the security chip part of the object the way a fingerprint is part of a person, or does the security chip allow the object to “know” something?). These categories are nonetheless useful in understanding the background art.
It is frequently the case that a given authentication system may require that the user (whether human or otherwise) have more than one authentication factor and more than one authentication factor value from the different categories enumerated above, one or more of which must be successfully communicated (often in a prescribed sequence). For example, a user may have an access card (an authentication factor), which must be properly encoded (an authentication factor value), and which is used in association with a PIN (which, generally, is an authentication factor, while a particular PIN number is an authentication factor value). In another example, a user may have a token (without limitation, such as described in patent application Ser. No. 11/317,568 and the successor continuation-in-part filed on Dec. 15, 2006, with the United States Receiving Office as an International application) as an authentication factor, which token is capable of producing unique numbers and/or character strings or other unique output as authentication factor values.
A term related to authentication is “authorization,” which may be defined as a determination that a known person (or thing, such as a computer) has the authority to perform a particular act, to be in a particular area, to possess an item, or the like. Authorization and authentication are linked, with authentication generally preceding authorization. A person or computer may be authenticated, that is, it may be confirmed that the person or computer is a particular party, but nonetheless not authorized to download a website or access an account of a different party.
Users of various computer and communications systems have become familiar with authentication and authorization systems such which employ authentication factors such as swipe cards and passwords, tokens, login identifiers and passwords, and even signatures (one of the original biometric authentication factors). Most electronic authentication systems have developed as independent systems dedicated to authorizing a person with respect to a particular activity and/or organization, in which case authorization is an implicit part of the authentication process. Such systems authenticate a user for the purpose of accessing an account, car, telephone, files, records, etc.
Multiple independent authentication processes are convenient for merchants and service providers, each of whom may maintain authentication and authorization systems independently from one another without the cost of coordinating the authentication and authorization systems. The existence of multiple authentication processes, however, places a burden on users, who must retain, remember, or otherwise deal with different authentication factors in order to be authorized in different contexts. A person's account login identifier and password for a bank will not generally be the same as a login identifier and password for an email system. It is necessary to remember multiple login identifiers, multiple passwords, to carry a token for one system, a card and a PIN for another. Besides being inconvenient, the result is an overall reduction in security. Users resort to writing down authentication information, passwords are not changed frequently enough, passwords and login identifiers are re-used at multiple merchants and service providers (without systems to prevent misuse), passwords are selected to be easy to remember rather than to be difficult to guess, and systems must be provided to allow account information to be recovered or changed (often through email and/or telephone), all of which reduce overall security.
Third parties have begun to develop authentication services not necessarily tied to a specific authorization process or technology, hereinafter “third party authentication.” See, for example, patent application Ser. No. 11/317,568 and the successor continuation-in-part filed on Dec. 15, 2006, with the United States Receiving Office as an International application, which is incorporated herein in its entirety by this reference, both of which describe third party authentication technologies. If third party authentication services become widespread, burdens on users can be reduced and overall security can be improved.
In an example of third-party authentication, a user in need of authentication obtains a token which is registered with a third party authentication service provider. The token is designed to produce a unique token value which changes over time or according to another parameter. To obtain goods and/or services from a party referred to herein as a “merchant,” (referred to as a “provider” in patent application Ser. No. 11/317,568 and the successor continuation-in-part filed on Dec. 15, 2006) the user obtains a unique token value from the token and communicates it to one or more merchants. Communication of the token value may be transparent to the user, such as through a proximity based system, or it may involve the active participation of the user, such as through typing the token value into a prompt in a user interface. The merchant provides at least the token value and generally another identifier, such as an identifier associated with the user and/or the token, to the third party authentication service provider with whom the user's token is registered. The merchant may also provide other information, such as the time when the token value was supplied. The third party authentication service provider generally confirms (or not) that the token was capable of producing the token value around the time that the token value was provided.
Authentication systems come with real costs which must be paid for. Hardware and network services must be obtained, software and user- and machine-interfaces must be designed, written, and maintained; cards and the like must be manufactured, programmed, and distributed; customer service must support users who loose and/or forget authentication factors; and fraudulent transactions must be investigated and dealt with, often involving expensive legal processes, to list but a few of the costs associated with authentication systems.
Without a third party authentication service, merchants typically absorb the cost of their own authentication-authorization systems as a price of doing business. With a third party authentication service, a common business model is that the third party provider of authentication services charges a fee to the merchant, such as a fee based on a number of users or based on a number of authentication attempts in a particular period of time. If the merchant has a small user base, the third party authentication service provider may also charge the merchant a flat-rate to ensure recovery of sunk costs. Such fees, however, may render the third party authentication service cost-prohibitive.
The present invention describes a method and a corresponding computer system to obtain compensation for authentication services by potentially obtaining compensation from someone other than a merchant who is requesting authentication services. In addition to or instead of obtaining compensation from the merchant who is requesting authentication services, the compensating party may be a user or another merchant.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description is for the purpose of illustrating embodiments of the invention only, and other embodiments are possible without deviating from the spirit and scope of the invention, which is limited only by the appended claims.
Referring now to
The user 101 possesses or controls at least one authentication factor 102 which is associated with at least one authentication factor value 103.
The authentication service provider 130 or 230 is depicted as including an authentication manager 131 or 231 and a compensation manager 134 or 234. While graphically depicted as separate objects, these components represent different functional activities which may be physically and/or logically collocated within the same computer or set of networked computers and which may be provided by a shared set of common software applications.
The authentication manager 131 or 231 is shown to include an authentication factor value generator 132 or 232, authentication factor records 133 or 233, a sample authentication factor record 134 or 234, and an authentication factor value evaluator 135 or 235. As is understood in the art, these components may be used in conjunction to evaluate authentication factor values 103 provided by users 101 and/or merchants 110-A. For example and without limitation, a user 101 may have a token which acts as an authentication factor 102. The token provides an authentication factor value 103 to the user 101 and/or to a merchant 110-A, through the transaction UI 111-A and the authorization UI 112-A. The merchant 110-A may pass the authentication factor value 103 to the authentication service provider 137 or 237 via the merchant's communications system 114-A, the communication media 120, and the authentication service provider's communication system 137 or 237, such as through an http interaction over an encrypted secure sockets layer (“SSL”), also called an “https” connection. The authentication service provider 130 or 230 decrypts and parses the communication containing the authentication factor value 103, which in this example would likely also contain a token or user ID, an identifier for the merchant 110-A, and other information, such as the time at which the authentication factor value 103 was provided. An authentication factor value evaluator 135 or 235 may then access the authentication factor records 133 or 233 to obtain the shared secret, such as an encryption key, which corresponds to the user and/or token ID and which should have been utilized by the user's token to produce the authentication factor value 103. The shared secret and the other information, such as the time information, may be utilized by an authentication factor generator 132 to attempt to reproduce the previously provided authentication factor value 103. If a match is obtained, the authentication service provider 130 or 230 returns a corresponding message to the merchant 110-A.
As noted above, the authentication service provider 130 or 230 is also depicted as including a compensation manager 134 or 234. The compensation manager 134 or 234 is depicted as including components for an account evaluator 137 or 237, an account manager 135 or 235 and account records 136 or 236. While graphically depicted as separate objects, these components represent different functional activities that may be physically and/or logically collocated within the same computer or set of networked computers and which may be provided by a shared set of common software applications. The account evaluator may, at any point during a request to authenticate an authentication factor value, access account records 136 or 236 to determine if the party requesting the authentication services has an account (or equivalent) with the authentication service provider 130 or 230, whether or not the account is current, and, in the case of the present invention, whether a user account provides that the user may be the party who compensates the authentication service provider 230. The account manager 135 or 235 may access the account records 136 or 236 to debit or credit accounts and to record other transactions and account activities.
In the case of the background art, accounts reflected in the account records 136 may be created as a result of contracts entered into between the authentication service provider 130 and the merchants 110-A and 110-B. In the case of the disclosed invention, and as is noted in
The sample account record 138 or 238 is depicted as including fields such as an account identifier or ID, a code (or similar) to indicate the payment terms between the account holder and the authentication service provider 130 or 230 (which may include payment terms requiring pre-payment, pay-as-you go, and/or some form of credit), a current balance (which may also reflect the availability of credit), and fields for account transactions, such as specific credits or debits or other transactions. Those skilled in the art would readily appreciate that this is a example of an record pertinent to this disclosure, that such records may likely include much more information which is not necessarily relevant to this disclosure, and that, as such, this recitation and the figures should not be understood to limit the disclosed invention.
As is illustrated by the foregoing examples, resolution of decision point 304 would generally turn on evaluation of the entries in the specific record, such as the example account record 238, which corresponds to the account identifier. As with step 303, this step may be performed in a different order than that depicted in
Provided that the outcome of step 304 is affirmative (that is, that a payer has been identified, that the terms of the relationship between the payer and the authentication service provider are such that the authentication service provider may proceed, and that the payer has a sufficient account balance (including credit) to provide the authentication service provider with reasonable assurance of being compensated)
Following this step,
If any of the decision points in
The receipt and processing of the authentication service request 301 is depicted in
As noted above, an embodiment of the invention in a computer system may be implemented in commodity personal computers, utilizing software (including an operating system and application software, such as a webserver and a database application) and supported by hardware and communication systems as are well known in the art. An exemplary diagram of the components of such a computer system and potential network architectures to allow communication between such components is depicted in
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
The disclosed invention has applicability to the authentication services industry.
