Method and system for transaction authorization

[0001] 1. Field of the Invention

[0002] The present invention generally relates to a system and method for transaction authorization which allows a merchant to check for account authorization for a prospective customer. This can be for any type of customer, even, for example, a medical record linked to a patient. Specifically, the system and method of the present invention matches a generated alphanumeric string which is checked for every account and which is associated with an individual customer for pre-defined specified time spans. More specifically, the present invention allows the option to check an account's alphanumeric string for the time interval associated with an authorization request regardless if that request is beyond the specified time interval. The method of the present invention further allows for multiple relationships between customers, alphanumeric strings, and accounts. This results in more than one alphanumeric string which can be valid for the same account at the same time. Additional protection thresholds may be added as a part of this authorization process. By using this disclosed method and system, authorization of customer's transactions by merchants will be accomplished with heretofore unrealized transaction security.

[0003] 2. Background of the Related Art

[0004] With a huge number of financial and information transactions carried out every day on the Internet, over the phone, and in person, a great need arises for the proper approval of each transaction. Currently most transactions (for example, credit card transactions) only require the signature of the cardholder and the account identification number for authorization. Processing a transaction in this way, is unreliable even when used with the best of intentions. However, when a transaction is entered by phone or by the internet (the number of which is expected to grow dramatically in the near future), even that limited security is not available. In fact, the same can be said about any application or information request carried over the Internet. With annual fraud in billions of dollars, there is a great need to protect such transactions with approval methods, for example, “authorization signatures” (for example, unpredictable alphanumeric strings valid for a specified time interval). This is necessary to provide increased security which would make the “authorization signature” difficult to forge or steal, even when it is exposed to another party carrying out a legitimate transaction. Such a system must be able to function even when not all of the accounts are participating in a newly introduced authorization procedure. This may be because not everyone may choose to participate in the new procedure or may be because a gradual phase-in may be desired.

[0005] The use of variable identification numbers, or random, or pseudorandom alphanumeric strings used as unpredictable codes which are changed at regular time intervals for authorization in a various security mechanisms, is not new. There are currently systems provided by Security Dynamics, which use a variable identification number (a “VIN”) with a password for computer system access authorization. This is generally disclosed in U.S. Pat. No. 5,988,497 to Michelle H. Wallace. This patent discloses a feature for credit card transaction authorization which operates by having users use a token-like device. This is typically a small hand-held device which generates a pseudorandom string of numbers which allows for computer system access for a specified time span by a user having the generated number string. At the end of the specified time interval, the number string is no longer operative and a new unpredictable string of numbers is generated for access to the computer system. Such disclosed authorization systems will deny authorization to a user who is not enrolled in the system.

[0006] Accordingly, there is now provided with this invention a system and method which will allow authorization to a user (in this case, a merchant or subscriber) for a customer who is not enrolled in the system. Multiple relationships between an alphanumeric string and accounts are also disclosed which results in more than one an alphanumeric string valid for the same account at the same time.

[0007] The present invention describes a system and method for a secure authorized transaction between a merchant and a customer. Of course, the merchant does not necessarily have to be a seller of goods. For example, “transaction” as contemplated herein, can be broad enough to include the release of medical records, credit records, or records of any kind. The method includes storing customer identification information, storing account identification information, and storing merchant identification information. A portion of said customer identification information is linked with a portion of said account identification information. The method further includes generating an unpredictable alphanumeric string, for every customer for pre-defined time intervals, communicating an authorization request between a merchant and the service, comparing information contained in said request with said merchant information, comparing information contained in said request with said account information, and comparing information contained in said request with said alphanumeric string.

[0008] The present invention is also directed to a system for authorizing transactions. The system includes a central authorizing computer for storing customer identification information, merchant identification information, and account identification information, wherein a portion of the customer information is linked with a portion of said account information, and for generating an unpredictable alphanumeric string. The system also includes a merchant computer for sending an authorization request to said central authorizing computer. The request includes merchant identification information, account identification information, and an alphanumeric string. The authorizing computer compares the information contained in the request with stored information and sends a message indicating whether the request is authorized.

[0009] The present invention is further directed to a method of transaction authorization. The method includes storing information uniquely identifying a customer account, generating an unpredictable alphanumeric string valid for a pre-determined time span for each customer, storing the unpredictable alphanumeric string on a central authorization computer for a pre-determined time period (one which can be longer than the time span and which may include several valid time spans), discarding the unpredictable alphanumeric string after said pre-determined time period has expired, generating an unpredictable alphanumeric string on a account owner's device, wherein the string on the device is synchronized with the string currently valid on the central computer, storing on the central computer information uniquely identifying every registered authorization service subscriber, communicating an authorization request between one of the service subscribers and the central computer, wherein the request identifies service subscriber, an account, the string on said device, and the time when the request was communicated. The method further includes comparing the party communicating said request with a stored list of eligible service subscribers, determining whether the party communicating the request matches with an eligible service provider on the stored list of eligible service subscribers and returning a negative message to the requesting party if a match is not made. The method also includes determining whether the account identified in the request matches a valid account stored in said central computer, and returning a positive message to the requesting party if a match for the account information is not found. The method also includes determining whether the alphanumeric string included in the request matches at least one of a plurality of valid alphanumeric strings for identified accounts for a transaction authorization time span stored in the central computer and returning a negative message to the requesting party if a match is not made or returning a positive message to the requesting party if a match is made, and compiling authorization process statistics for the account and the service subscriber.

[0010] Additional objects of the present invention will become apparent from the following descriptions. The method and apparatus of the present invention will be better understood by reference to the following detailed discussion of specific embodiments and the attached figures, which illustrate and exemplify such embodiments.

[0014] The following preferred embodiment as exemplified by the drawings is illustrative of the invention and is not intended to limit the invention as encompassed by the claims of this invention. The method of transaction authorization disclosed herein, can be used either an additional authorization tier which can be combined with any already existing authorization procedures or as an independent feature in an authorization procedure. This new method provides heightened security for transactions involving an account owner, fund, or information holding entity, (hereinafter referred to as “the customer”) and any third party merchant who needs funds or information on behalf of the customer (hereinafter referred to as “the subscriber”). In this usage, the customer is the entity which established the account with the system and who uses the system to authorize the transaction against his account. The subscriber is the merchant who wishes to charge the account with the transaction.

[0015] The system stores unique customer identification information and unique identifiers of accounts linked to each other. Every account registered with the Transaction Authorization System in accordance with this invention has unique account identification information associated therewith. This account identification information is stored on a central authorization server (a “CAS”). Such registered accounts could include, for example, a credit account, or a bank account, or personal identification information, or a combination thereof. Links are specified linking specific customers to specific accounts. A plurality of customers may be linked to the same account. Also, a plurality of accounts may be linked to the same customer.

[0016] The customer has access to a generator of unpredictable alphanumeric strings. Typically, this may be a small hand-held device (“HHD”) which generates a pseudorandom alphanumeric string which allows for transaction authorization for a specified time span by a user having the generated string. Alternatively, the software which generates the string of unpredictable alphanumerics may be loaded onto a customer's computer or work station. At the end of the pre-determined specified time interval, the alphanumeric string becomes inoperative and a new unpredictable string of numbers is generated for access to the transaction system.

[0017] The additional security provided for by this invention is achieved by comparing the generated alphanumeric string, valid for the specified time interval, with a synchronized CAS. Such an alphanumeric string is changed at regular pre-specified time intervals (for example, every 2 minutes). All alphanumeric strings are produced on the CAS in advance (before the time span, for which they will be valid) and are stored for a further specified pre-determined time interval. All alphanumeric strings for a specified time interval are created in advance and made available for the authorization process “just in time”. “Just in time” in this context means shortly before the time interval for which they are valid will begin, for example, for 10 seconds. Alphanumeric strings are held so that they remain available for the authorization process up to a pre-selected system-defined time limit, for example, for 6 hours. The storage of the strings that are no longer valid is to allow authorization for a transaction authorized in the past. After the pre-selected system-defined time limit for “holding” the alphanumeric strings expires, all alphanumeric strings are discarded. Any attempt to authenticate transactions having an authorization time outside the pre-selected time period, that is, the “holding period” will return a negative result. In this way, a reasonable time limit is established for posting third party transactions. Also, in this way, it is difficult to “steal” or improperly get access to authorized strings, even when they were exposed.

[0018] Each alphanumeric string is associated with a customer rather than with an account, though all accounts held by the same customer are linked to the same alphanumeric string for the specified time period. If several people share the same account (for example family members who use the same credit card) then more then one alphanumeric string is valid for that account at the same time.

[0019] Following FIG. 1, the transaction authorization process begins by having a merchant (subscriber) first requesting authorization of a transaction (step 1). A third party who wishes to participate in the security process outlined above may typically subscribe for the service by registering with the Transaction Authorization System of the present invention. A method of communication between the service subscriber and a CAS is established for each individual case based upon particular subscriber needs and capabilities. All information relative to the individual subscriber is stored on the CAS. If the requester is not a subscriber (step 2) to this transaction authorization process (which may be imbedded in an overarching transaction approval process), then the system of the present invention sends a message back to the requester: Service Denied. If, however, the requestor merchant is a subscriber, then his subscriber identification is sent to the system along with the customer's unique alphanumeric string, valid at this time, and the customer's account identification number. Also included as additional preferable information, may be the exact time when the authorization was requested (step 3). If this exact time is omitted, then the time when the CAS received the authorization request should preferably be used as the time when the transaction was authorized.

[0020] This information can be sent in clear text, coded, encrypted, scrambled or in any other form according to the information exchange protocol set up for communication between the CAS and a particular subscriber. The CAS then decodes the information (if it has been transmitted in other than clear text).

[0021] The system then checks to determine if both the customer's alphanumeric string is valid at this time and if the entered account is registered with the system. All transactions involving accounts unknown to the system, and so not protected by it, are considered to be legitimate. That is, if an account cannot be located, the default message is the same as if that account had been found and linked with the customer's valid alphanumeric string, and the system sends the message to the merchant: Authorization Approved.

[0022] The method and system of the present invention, then determines if the account is enabled. That is, the system checks to see if the account identified in the request is not taken out of service either explicitly by a customer request or implicitly by the system when certain thresholds are reached, and it is in proper order for charges to be made against it (step 6).

[0023] The system then matches the alphanumeric string included in the authorization request with all alphanumeric strings which are valid for the account identified in the request for the time when the transaction was authorized. If the match is not made, then the system sends the message back to the merchant: Authorization Failed (step 7).

[0024] An additional feature of this system that may be included is that this determining process can be repeated for time intervals not necessarily at the moment of the transaction authorization request (step 8). This feature which could also compensate for small internal clock discrepancy between customer's HHD and CAS will be described in greater detail with respect to FIG. 2 below.

[0025] After the system has determined that the customer's alphanumeric string is valid for the entered account for the time period when the transaction was authorized, the system then determines if a successful authorization threshold has been reached. Such authorization thresholds are selected by the customer and can be set up for a number of successful requests using the same alphanumeric string, for a number of successful requests within certain period of time, and etc (step 9). If those thresholds are not reached, then a “Authorization Approved” message is sent to the subscriber. If a determination is not made, or any account specific thresholds are reached then a “Authorization Denied” message is sent to the subscriber. At this point “Failed authorization thresholds” for the entire customer's activity, are checked for both the subscriber's and customer's accounts. Such thresholds can preferably be set up for a various number of failed authorization attempts within the specified time period. If a customer threshold is reached, the system response may also include an immediate customer notification via the means set for it, disabling one or all customer accounts on temporary or permanent bases, and etc. A response to reaching subscriber threshold could result in either a temporary or a permanent denial of service.

[0026] This feature is set to identify and find subscribers who routinely use stolen property (credit cards, etc.) or subscribe to the system in order to break authorization security. Thresholds can be set, for example, as a ratio between successful and failed authorization attempts for a rolling time period. As an example, such a ratio could be 10 to 1 for every 10 hours of subscriber operations excluding periods of no activity. If such a ratio falls below that value, a subscriber would be identified as suspicious and can be taken out of service for a preset period of time (as either a warning, or until an explanation can be ascertained) or permanently, until all issues are resolved. If the threshold has been reached, then the subscriber's status is changed and the next authorization attempt by the same subscriber will result in a message reading: Service Denied.

[0027] As described, an essential feature of the system and method of the present invention is allowing for transaction authorization for both accounts that are registered and accounts that are not registered with the system to be indistinguishable to the service subscriber involved in the transaction. It also allows authorization for transactions authorized in the past up to a certain time limit.

[0028] The system and method of the present invention allows for authorization to occur even in transactions where the customer's valid alphanumeric string was once valid, but has now expired. This preferable feature to the system is more particularly shown in FIG. 2. As shown, in those cases where a merchants inquiry included a customer's once valid alphanumeric string found to be invalid due to elapsing of the specified valid time span (caused, for example, by a small time discrepancy between the internal clock of the CAS and the customer's token generator), the system determines if this particular string was valid for a time interval within a pre-determined time span of the request. For example, the system may determine if the entered customer's alphanumeric string was once a valid string but one that has just recently expired, or if it was never a valid string. If it was never a valid string, then the system sends the message: Authorization Denied. However, if the string was valid in the recent past (“recent” being pre-specified in the system), then the system may send the message: Authorization Approved.

[0029] A still further preferable feature of the authorization system of the present invention is that it may maintain and compile various statistics regarding account activity. These activity statistics are updated after each successful or failed authorization attempt. Such updates allow for constant monitoring for any suspicious activity. This feature additionally provides for improved system security. A variety of activity reports for accounts, or for customers, or for subscribers can be generated by the system. Such information can be used for customer information, statistical analysis, billing, and etc. Such action might include immediately customer notification, or temporary or permanent account inactivation.

[0030] The system disclosed herein of transaction authorization significantly increases security for any types of financial and information exchange transactions carried over the Internet, telephone or even in the presents of an authorizing person.

[0031] New accounts can be “linked” to an owner's alphanumeric string(s), if one is already established with the system, even before they are activated and plastic cards for them are issued. That makes identity theft, much more difficult to achieve.

[0032] This inventive method allows for processing authorization for customer accounts both registered and not registered with the system. Either case is completely indistinguishable, one from the other for the service subscriber. No transactions should be lost due to the fact that a customer is not participating in the proposed system. The only result is that the non-subscriber just does not get any protection from it. This feature gives customers the freedom to choose whether or not to participate in the transaction authorization system and further allows for a gradual system phase in.

[0033] The method described can be used in a variety of applications where secure any transaction authorization required. Thus, while the invention has been particularly shown and described above with reference to preferred embodiments, the foregoing and other changes in form and detail may be made therein by one skilled in the art without departing from the spirit and scope of the invention.