CA2176163C

CA2176163C - Transaction authorization and alert system

Info

Publication number: CA2176163C
Application number: CA002176163A
Authority: CA
Inventors: Greg E. Blonder; Steven Lloyd Greenspan; Jean-Robert Mirville; Binay Sugla
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1995-05-31
Filing date: 1996-05-09
Publication date: 1999-04-06
Anticipated expiration: 2016-05-09
Also published as: DE69617097T2; JPH08339407A; EP0745961A2; DE69617097D1; EP0745961B1; CA2176163A1; EP0745961A3; US5708422A

Abstract

An automated method for alerting a customer that a transaction is being initiated and for authorizing the transaction based on a confirmation/approval by the customer thereto. In accordance with one illustrative embodiment, a request to authorize the transaction is received, wherein the request includes a customer identifier; a determination is made whether to authorize the transaction based on the customer identifier; if the determination is to authorize the transaction, that fact is communicated to the customer; a confirmation that the transaction should, in fact, be authorized is received back from the customer; and the transaction is authorized in response to the customer's confirmation thereof. In accordance with another illustrative embodiment, a transaction initiated by an agent of the customer (i.e., the principal) is authorized by the principal when one or more threshold parameters that may be pre-defined by the principal are exceeded. A preferred method of alerting the customer and receiving a confirmation to authorize the transaction back from the customer is illustratively afforded by conventional two-way pagers.

Description

~ 1 217~163 TRANSACTION AUTHORIZATION AND ALERT SYSTEM

5 Field of the Invention This invention relates to a t,~sa~lioll authorization and alerting system, and more particularly to a method and app~lus for using a commllnic~ti- ns system to alert an interested party of a recently completed transætion and/or to obtain authorization from the illle~ ed party for a pending transætion.
l of the Invention The credit card i~e"l;l;~ ;()n IlUlllI)el~ ign~-d to credit card customers are pl~s~lted to many dirrt;,c~ll people in a variety of cil~ n~es -- when applying for financial services, when con~ ling yurcllases in a store, and when making yu~;hases over the 15 telephone, through the mail, or over e-mail (electronic mail). The large number of people that have æcess to a customer's credit card nuIr~er has ~u~lllly led to fraud. The advantages of using credit cards, however, are slll~nti~l The customer finds their use advantageous in that he or she need not carry cash or write checks. Credit card purchases also have advantages to the retailer as co~ ed, for example, to payment by check, since the credit 2 0 card service provider ensures timeb payment to the retailer, regardless of when the customer pays the balance on the credit card æcount. However, credit cards or credit card IlUlllL)~
are often stolen, and credit card llullL~l~ are often used over the telephone or through the mail without any secure 1l~ 1ll for co~ "l~ Ig the customer's identity.
Telephone calling card IUlll~l~ have security problems similar to those of credit 25 cards. These IlUll~ i are often spoken aloud or entered through a touch tone keypad, thereby allowing others the OppOllul~ily to record them (either el~;lronically or by mere observation), and to then fr~ llkntly use the IIUIIL~I~. Another co~ on source of fraud stems from authorized usage of a credit card or a telephone calling card followed by a customer denial that he or she made the yul~;hase or plæed the call. Thus, simply controlling 3 0 æcess to the credit or calling card nu~er without more may be inadequate. Coll4,uler æcess to secure d~t~h~ces is yet another example of a tldl~sa;lion that depends upon private `~ 2176 16 3 customer identifiers (i.e., passwords) which through legal or illegal channels rnay become known to others, thereby allowing unauthorized access to these (l~t~b~cçs.
Prior art Ir~ n;~llL'i; for h~-lrlling such security concerns have not taken advantage of advances in co""".lnic~tions and computer systems to automate the alerting and approval 5 process. Most techniques which have heretofore attempted to address these security issues tend to si~nifir~ntly increase the complexity of the commnni-~tion protocol. For example, the customer may be asked additional questions (the answers to which it is expected that only the authorized party would know), or may be required to provide additional inforrnation as a part of each transaction such as a (secret) Personal Ide.-tir,~ ion Number (PlN). Moreover, 10 it rnay be required that such PlNs be modified on a routine basis in order to ~ their secrecy. To encourage customers to make use of these types of services (e.g., credit and calling cards), it has become common to lirnit the liability of the customer while increasing the - liability of the service provider (e.g., the credit card vendor or telephone CO~ 1y).
Unfortunately, unauthorized uses usually go nn-1etected until a periodic service report is 15 issued -- typically, at the end of a rnonthly billing cycle and long after the fraud was ted.
In addition to the above-described security issues, one commonly desired class of financial tr~n~tions involves a principal who ernpowers an agent to initiate and complete routine ll~lsal;liolls without the prin~ip~l's knowledge or approval. However, the prinrir~l 2 0 often reserves the right to be alerted to, or even to approve, such transactions, particularly when they are i~lentifi~bly non-routine or atypical. For exarnple, approval may be required when certain threshold pa~ ætel~ that are ~csoc;~ted with the tr~n.c~tion (which rnay, for example, be pre-defined by the principal) are ex~eeded.
Prior art ~ h~ Ls for h~n-lling such agent initi~tPcl transactions have also not25 taken advantage of advances in col,..."...,~ions and cornputer systems to autornate the alerting and approval process, thereby limiting the scope of applications of such t~ s~;liolls.
For example, a card owner, such as a col~o,ation (parent) that provides an employee (young adult) with a credit/debit card to charge business (personal) expenses, typically places certain restrictions on the use of the card by the cardholder to prevent abuses, excesses or fraud.
3 0 Those restrictions include, for exarnple, upper lirnits on either the total amount of money that can be charged to a colll.l~rcial credit card, or the number of transactions that can be authorized for a credit card number within a predPtennin~l period of tirne. Those re~lli.;liolls so"~t;"~.s operate to deny access to credit to a cardholder who is stranded or facing an ellæ~gell ;y situation, when ironically credit is rnost needed. This clearly defeats the purpose of empowering the employee or young adult. Yet, oversight of the use of those credit cards by the card owners is still needed since the card owners are ultimately financially responsible 5 for the expenses charged to those credit cards. This issue takes particular .signifir~nce when one considers that rnerchants concerned about lack of legal cornpetency of rninors to complete card tr~nc~ctions have been reluctant to accept debit or credit cards as a means of payment from minors. Hence, another specific problem of the prior art is lack of a flexible lc~lli;lio~ frh~ni.cm for principals to lirnit monitor, and/or approve use of a card by 10 cardholder for non-routine conJIl~sl.;ial tldns~tions.

Sun-mar~ of the Invention We have recognized that the aforernentioned problems result from the inability to quickly and efficiently inform the individual customer (e.g., the account holder or the 15 principal) that his or her customer i~entifi~.r (e.g., credit/debit/calling card number, PIN, password, etc.) is being used in a transaction for a particular purpose, and the inability of the customer to respond thereto in order to corfirm or deny its use. Thus, in accordance with certain illustrative embodiments of the present invention, an automated method for ~ullloli~illg a t~ sa;lion is provided in which the custon~.r is informed of à pending 20 auth~l,~tion thereof, and the transaction is then authorized only in response to a customer col~.,~lion. In accordance with certain other illustrative emboflin~.nt~, the invention provides a method and a system which allow a principal to be automatically alerted to, and/or to proll~ly authorize, an agent-initiated tl~sa~;lion which may, for example, be deerned atypical based on a pre-stored profile spe~ifi~d by the principal.
In accordance with one illu~tl~ e embodiment, a request to authorize a l~ ;lion is received, wherein the request includes a customer i~.ntifi~.r; a dete~ latioll is made whether to authorize the transaction based on the customer identifier; if the detellll-l~ation is made to authorize the transaction, the pending authorization is collllllulficated to the customer; a confirmation that the transaction is, in fact, to be authorized is received back 3 0 from the customer; and the lldns~;lion is authorized in response to the customer's col,ri""~ion thereof.

217616~

One approach to commllnir~ting such a determination to authorize the transactionand to receive such a confillllation to authorize from the custorner is illustratively afforded by conventional two-way pagers. For example, a computer database, charged with the task of autho~ g a transaction, may signal the customer via paging whenever his or her customer 5 irl~ontifi.or is used. Along with this notification, relevant information rnay be displayed on the pager's ~ h~ lic (or numeric) display. The customer may then respond (via the two-way pager) by cO~ g or denying the pending authorization.
According to one aspect of the invention, exception conditions that trigger a customer's alerting or approval process may be stored in a profile specified by the customer.
10 This profile associates those exception conditions to a personal commllnir~ti-~ns address, such as a paging nurnber or a "500" or "700" prefix telephone nurnber at which the customer can be reached. For credit/debit and calling card transactions, exception conditions rnay be caused, for example, by a request for credit arnount (or number of transactions) above threshold p~læters pre-imposed by the card owner for the use of the card, or breach of 15 other conditions pre-defined by the card owner for the use of the card. In accordance with the p,i,lci~les of the invention, the card owner may elect to sirnply receive the alert rnessage or to authorize/deny the cha gillg of the expenses to the card nurnber by transmitting an approvaUdi~a~lvval message to the card issuer as part of the card validation process.
According to another aspect of the invention, a merchant may request the approval of 2 0 a parent or guardian to a debit/credit card transaction, such as a stored-value smartcard, ~IGsented to the merchant by a minor alleging to act on behalf of the parent or guardian. In that casei the card number, or a proxy thereof, may be used as a search key to retrieve the parent or guardian's profile that identifies a co~",~"~ nS address for the parent or ~lal.iian. The tr~n~çtion is approved only if an authorization message is received from the 2 5 parent or guardian.

Bnef De:~li"tion of the D~ ,Y~
FIG. I is a telecollll~ tion system arranged in æcordance with the invention to allow a card owner to authorize, or to be alerted to transactions charged to the card by a 3 0 cardholder.
FIG. 2 illustrates an exemplary rnessage that is t~ ed by an automatic dialing unit at a rnerchant's location to a card issuer's validation database.

- 217~16~

FIG. 3 shows an illustrative table that ~ssoci~t~s alerting threshold parameters to card IlU~llbe;l:~.
FIG. 4 shows an illustrative generic message that is tri3n.s~ led by an automatic dialing unit at a ~IlGr~ allt's location to a card owner's commllni~tions device.
FIG. S shows specific exernplary rnessages that may be tr~ e~ by a card validation system to a card owner's co" " "" "i~l ions device.
FIG. 6 is a table that correlates merchant codes to types of col~ el~ial establ;.~l " "r,"l c, ~IG. 7 shows a flow diagram outlining illustrative programmed instructions ex~uted 10 by diLrGIGll~ elements of the co~"""~ ns system of FIG. 1 to receive approval for, or to alert a credit card owner to, a credit card transaction initiated by a card holder in acconlance with certain illustrative embodiments of the present invention.
FlG. 8 is a flow chart of illustrative programmed instructions executed by various coll~onGIlls of the co""~ n;l^atiolls system of FIG. 1 to receive approval from a parent or a 15 ~ ~a dian of a minor initi::lt~ debit card t~ sa~tion in accordance with a first illustrative ernbodirnent of the present invention.
~ G. 9 shows a flow chart of a credit card ~urchase tr~n.s~. ti~-n to which certain illustrative ernbodiments of the present invention may advantageously be applied.
FIG. 10 shows a flow chart of an authorization process in accordance with a second 2 0 illustrative embodiment of the present invention.
FIG. 11 shows a flow chart of an authorization process in accordance with a third illustrative err~bodiment of the present invention.
FIG. 12 shows a flow chart of an autho~ tion process in accordance with a fourthillustrative embodirnent of the present invention.
FIG. 13 shows a flow chart of a credit card purchase transaction to which a fifth illustrative ernbodiment of the present invention may advantageously be applied.~IG. 14 shows a flow chart of an authorization process in accordance with a fifth illustrative embodiment of the present invention.

3 0 Detailed Des l ;,Jtion Intrc~ c~iorl - ~- 217~163 Although the principles of the present invention may be applied tO many domains, the illustrative embodiments described in detail herein will focus on a credit card or debit card purchase transaction. In these embodiments, a cardholder, who may or may not be the customer of the credit or debit card issuer, uses a credit or debit card (or a credit card 5 nurnber) to instruct a retailer (a provider of a product or service) to charge a purchase to the given credit card account or to debit the arnount of the purchase from the given debit card account. The credit or debit card number serves as a customer identifier to the credit card service provider (e.g., the issuer of the credit card).
FIG. 1 shows a co"~""~"i~ ions system arranged in accordance with certain 10 illustrative embodiments of the present invention to i~ mel,L the principles thereof. The co"~ "i~tions system of FIG. 1 includes a co"""",~ l;ons network 102, a validation ~t~h~ce 106 and a paging system network 111. Col """ ~";l~tions network 102 includes one or a series of interconnected co~ tions switches arranged to relay to validation d~t~h~ce 106 (via lines 130-1 to 130-N) i,~lll~lioll received from card reader 101.
15 Spe~-ifi~ y~ when a credit card holder hands a credit card to a .l~lchalll to charge expenses ~csoci~tç 1 with a tr~nc~ction, the ..lt;rcl1~,l slides the credit card through card reader 101 to read the credit card number, for example, off the m~gn~tir stripe on the back of the credit card. An automatic dialing unit in~ rled in card reader 101 dials a telephone nurnber associated with a ~l~t~b~ce 10'6 of the card issuer to validate the card number. In particular, 20 card reader 101 ~ sllfits to validation tl~t~h~ce 106 a validation request message that is illustratively l~,ples~ ed in FIG. 2.
Similarly, when the cardholder wishes to use a debit card such as an Autornatic Teller Machine (ATM) card as a ~r~ans of payment for a COIIlll~l~,;al transaction, the Iller~h~
enters a special code into card reader 101 to initiate the alerting and approval process.
25 There~ler, card reader 101 retrieves the debit card number, for example, from the rn~gn~til~
stripe on the back of the debit card before p[O~ il-g the cardholder for a secret code (e.g., a PlN). Card reader 101 then transmits to validation d~t~b~se 101 a validation request message that is illustrated in FIG. 2.
The rnessage shown in FIG. 2 includes a card nurnber 201, a requested credit amount 3 0 202, a merchant code 203, and a validation request 204. When card number 201 is a debit card nurnber, it also includes the PIN entered by the cardholder. Merchant code 203 is a field that identifi~s the type of business from which the message as~sociated with the transaction, is - 21 7616~

",;l~e l Typically, the rnerchant code 203 is appended by card reader 101 after the requested credit amount 202 has been entered by the ll~ercllant, and the calling card number 201 has been retrieved from the m~netir stripe on the back of the card. The validation request field 204 stores the code entered by a merchant to receive approval from the party 5 authorized to give such approval for a debit card transaction. In the case where the cardholder is a minor, for example, by requesting approval of the transaction from a parent or guardian of the minor (i.e., the authorized party), the ll~l.;hallt and the debit card issuer are assured that the transaction cannot be voided by the minor at a later date on the ground that the minor lacked legal co~ y to enter into such transaction.
Upon receiving a validation request message, validation d~t~b~ce 106 uses card number 201 as a search key to perform a table look-up operation for the purpose of retrieving the profile associated with the card number. When the cardholder is a rninor, and the card is a stored-value smartcard, a passphrase or proxy il~lll~tion provided by the minor may be used as search key to retrieve the profile of FIG. 3.
Validation ~l~t~h~ce 106 is a processor-controlled centralized d~t~h~ce facility which is a repository of records or profiles for all credit/debit card nurnhers ~ccign~d by a card issuer to its customers. Validation d~t~h~ce 106 is decign~d to authorize transactions charged to card IIUII~I~ stored therein. Such authorization may be based on a set of pre-defined p~all~ters in~ ded in the profiles ~ccoci~fed with the card llùml)els. When a retrieved 2 0 profile does not include a re~lu~ll~ul for alerting or approval, validation of the card nurnber may be pelrolll~d in a conventional rnanner. When a profile stores alerting parameters that may require comm ...i~ti- ns with one or more called parties, validation ~t~b~ce 106 uses one of the Automatic Dialing Units (ADIJ) 110-1 to II0-N to dial a telephone number retrieved from a profile ~csoci~ted with a card number.
2 5 Shown in FIG. 3 is an illustrative table that associates alerting and approval threshold p~læters to credit card IIUn~l j. Each record in the table of FIG. 3 is a profile for a credit card number that is used to determine the manner in which transactions charged to that credit card number are processed. The table of FIG. 3 includes a cardholder's name field 301; a card number field 302; alert and autholi~tion flags 303 and 304, respectively; a trigger group 3 0 of fields; a co~ iC~tions address field 307; a no-answer-credit threshold field 309; and a no-answer-transaction thresholdfield 310. Cardholder's name field 301 stores the narne of a card holder associated with a particular card nurnber. The cardholder's name field may - ' 217~16~

contain, for example, the first and last name of the cardholder (as shown for the first and third record) or the first name (or ni~ ) of the cardholder (as shown for the second and fourth record3. Credit card number 302 is used as a search key in the table lookup operation ioned above, to retrieve the profile associated with that card number. The alert flag field 5 303 in~ tes that the card owner is to be notified, although possibly only under certain conditions. Such notification may be required, for exarnple, when processing of the transaction would either cause certain conditions pre-defined for the use of the card to be breached, or a threshold parameter to be exceeded. The approval flag field 304 alerts the card iss~er that credit card transactions that violate pre-established conditions need to be 10 authorized by the card owner as part of the card validation process. These pre-established conditions may be pre-selected by the card owner or they may be conditions imposed by the card issuer. The trigger group of fields depicted in FIG. 3 illustratively shows different ters which cause a card owner to be notified when those parameters exceed certain pre-defined thresholds. The "conditions" field 305 shows restrictions pre-selected by the card 15 owners for use of their credit cards. For example, the first record in~ tçs that the card owner wishes to be alerted whenever a cardholder charges more than one hundred (l00) dollars to the credit card nurnber. The third record illustrates that the card owner wishes to authorize any credit card transaction for more than three hundred dollars. By contrast, the owner of the credit card number associated with the third record wishes to be alerted 20 whenever that card is used at col~ ercial establ;il"-~"~ associated with specific l~lcha~l codes. Sorne card issuers assign distinct ~ .;hal~t codes to co~ ercial establ;~ c, such as bars, hotels and liquor stores, thereby allowing credit card transactions at those establ;~ t~ to be easily i-lentifiPrl Other .~;sl.ic~iuns that may be imposed by a card owner may include, for example, the 2 5 "Ill~illlUlll nu~er of tl~lsa.;~ions" field 306 which defines an upper lirnit on the nurnber of ll~lsa~lions that can be charged to a credit card number within a predeterrnined period of tirne. For example, the second record in~ir~tes that the card owner's approval is required to validate a credit card llansa~lioll when more than three credit card transactions have already been processed for that credit card nurnber within a twenty-four (24) hour period. Such a 3 0 condition rnay be useful, for example, in deteeting fraudulent use of a stolen credit card.
When a transaction threshold number is used as a p~læter for processing a credit card tldlls~;tion, the transaction counter field 307 is illclelllt;llled by l (one) every time a credit - _ 217~16~

card transaction is processed. The transaction counter field 307 is reset to "0" after the predetermined period (e.g., 24 hours) has expired. It will be appreciated that only a lirnited number of restrictions and/or authorizations are shown in FIG. 3 for ease of explanation, even though many other re~l~i ;lions, obvious to those of ordinary skill in the art, may be requested 5 by card owners or card issuers for inclusion in the profile of FIG. 3.
Whenever a card owner is to be notified of a condition-breaching credit card transaction, the commllni~tions address field 308 rnay be used to identify a telephone nurnber or an electronic mail address at which the card owner can be reached. Preferably, the co."""~ lions address field stores a pager number associated with a commllni~tiQns 10 carrier which provides paging service on a nationwide basis to contact, for example, the card owners associated with the first and the fourth record. Altematively, a personal telephone number, such as a "S00" or a "700" prefLlc number rnay be used as a reach number for a card owner, such as the card owner associated with the second and third record shown in FIG. 3.
As another aiternative, an ele~ nic mail address may be used which, in various illustrative 15 embodiments, may be either an address to which conventional electronic mail rnay be sent or an ele ;llol~ic address for use in other forrns of electronic cign~ling such as, for example, a direct message co~,-",~ ie~l to the cornputer screen of a logged-on user or an interactive ele~;l.ol~ic two-way col....l .li~ n ~rl~ (e.g., a "chat" or "talk" program).
Also included in the p'rofile of FIG. 3 is no-answer-credit threshold field 309 and no-20 answer-transaction threshold field 310. Those fields identify respectively, the maxirnum amount of credit that can be approved, and the maximum number of pe..~ll3sil~ nsa~;lions within a given period of time, when the card owner cannot be reached by the co~ "~ ;ons system of FIG. 1. When the card owner does not wish any transactions to be authorized when he or she cannot be reached, then those fields are set to zero.
2 5 When the cost associated with the co~ ;ial transaction is charged to a debit card, as opposed to a credit card, only the card holder's name field 301, the card number field 302 and the comml...i~ s address field 308 are of particular relevance since the request for approval is initi~tloA by the n~ t and the co~ . ;;al transaction is not cornpleted when the debit card holder cannot be reached.
Referring back to FIG. 1, when a trallsa~lion request message, such as the one illustrated in FIG. 2, is received by validation ~t~h~ce 106, the latter uses a) the ilL[~3lll-ation in~ ded in that message, and b) the retrieved profile associated with the card nu~er in that -i- 217616~

rnessage to determine whether at least one card owner pre-imposed condition hac been breached (or a card owner pre-defined threshold has been exceeded). If so, validation d~t~h~ce 106 fetches the col~""~"i~ions address of the credit card owner and any other a~p,opliate ilrol~l~tion to forrnat an authorization request and/or alert rnessage that is 5 transrnitted to the card owner. One such message is illustrated in FIG. 4 which shows a card holder's narne field 401, a dicplay field 402 and a field 403 that is populated by an entry in the table illustrated in FIG. 5. The card holder's narne ic populated by the narne that is included in the profile retrieved by validation ~t~b~ce 106. Field 402 ic a dicplay field that always containc the two words "Credit Card." Field 403 is populated by one of the entries in the 10 table of FIG. 5.
The table of FIG. S shows three separate entries 501, 502 and 503 I~:~leselllillg di~r~lcnt sections of three different rnessages. Each entry is comprLced mainly of display illrOIll~tioll and one field that is populated baced on the particular condition that has been breached or the specific threshold that has been exceeded. For example, when the requested 15 credit amount for the llailsal;lion exceeds the charging lirnit pre-selected by the card owner, field 505 will be populated by the diLre~nce betwæll the rnaximum charging amount and the req~lestecl credit amount. Similarly, when validation of a card number for a trancaction would cause the maximum number of transactionc per day pre-sel~cted by the card owner to be ex~eede l, the content of the llal~sa~;~ion counter field is moved into field 506. Likewise, 2 0 when the card holder ~lell~l~ to charge to a credit card nurnber the expenses related to the .lrchase of an item from a co~ cial est~bl;~ l that is associated with a prohibited Illt;~ha ll code, that code is translated to one of the establ;~ "l type entries shown in the table of FIG. 6. That table correlates each ll~lchant code to a particular type of coll~ c;rc;al esta~ l",~!" For example, hypothetical Illt;lcll~-l code 1234 is associated with liquor 25 stores, while fictitious ll~lcllant code 4567 is mapped to hotels and motels. Thus, once a ull code is mapped to a colllll~lcidl establisll~ type entry, that entry is sirnply copied to field 507 of FIG. 5.
By populating field 403 of FIG. 4 with one of the entries in FIG. 5, a cornpleternessage is form~ ted for l~"~",~ n to the card owner. Thereafter, validation d~t~b~se 30 106 retrieves the col~",~,u~ic~ti~)ns address in the profile to send to the card owner the message illustrated in FIG. 4 via an idle autornatic dialing unit selected from ADU 110-1 to ADU 110-N. The latter are arranged a) to initiate phone calls by dialing telephone IIUIII~

17B16~

received from vaLidation ~t~b~se 106 and, b) to bridge those caLls to other commllnir~tions devices upon detecting a feedb~l~ signal from the card owner. ADU 110-l to 110-N are also designed to terminate the call if no feerlb~rl~ signal is received after a predetermined period of time.
If the commnnir2tions address is a personal telephone number, such as a "500" or"700" prefix number (shown, for exarnple, in the third record of FIG. 3), then ~t~h~ce 106 lrdll~ln,ts the message illustrated in FIG. 4 to Interactive Voice Response System (IVRS) 125 before sending the comm~lnir~tionS address of the card owner to an idle ADU. Upon receiving the nurnher dialed by ADU 110-1, for example, co~ ns network 102 translates the "500" or "700" prefix telephone nurnber to a Plain Old Telephone Service (POTS) telephone nurnber at which the card owner can he reached. When ADU 110-1 detects a feedback signal from the card owner, it bridges the call ~via line 140) to Interactive Voice Response System (IVRS) 125 that delivers the message of FIG. 4 in audio forrn to the card owner at telephone set 145, for exarnple. Specifically, rVRS 125 is a processor that 1 5 ex~utes text-to-speech synthesis prograrr~ned instructions deci~nPd to use ASCII input, such as one of the rnessages shown in FIG. 4, to generate a "read aloud" audio rendition of that ASCII input in a m~rhin~ s~ h~s;~P,d voice. IVRS 125 is also arranged to prompt a card owner to provide some input to approve or disapp.ove a particular l"..~c~ n. For exarnple, a card owner may be prornpted to enter a "1" on a telephone dialpad to approve a2 0 llal1s~liol1, or a "2" on the dialpad to disa~p.ove the transaction. Also included in IVRS 125 is a means to respond to touchtone colllll~lds from a caller . In particular, IVRS 125 is a,ldilged to translate the Dual Tone Multi-Frequency (Dl~) signal received from the card owner to a m~rhin~-readable format, such as ASCII, that is recognizable by validation l~t~b~se 106. Alternatively, IVRS 125 may include a word recognition unit that is arranged 2 5 to output digitally recorded words, such as the messages in FIG. 5, to prompt a card owner for particular il~lll~lion that is converted to ASClI format for delivery to validation ~1~t~, 106. Furthe..l~ , in order to insure that the person approving the transaction is the card owner, as opposed to an impostor, IVRS 125 may also include a speaker recognition unit that stores templates of pre-recorded digiti7P,d voice messages of the card owner that are 3 0 con~a ed to any input received from the called party to certify that the "real" card owner is the person approving the transaction.

- 21~6~

If the commllni~tions address is a paging telephone number, then one of the ADUs110-1 to 110-N dials the paging telephone number to initiate a call to that paging telephone number for the purpose of delivering one of the messages of FIG. 4 to pager device 135 of the card owner. The call is routed over col"~ tions network 102 which uses one of the 5 demodulators 120-1 to 120-N to tl~sfullll the received message into proper signaling forrnat for delivery to paging system network l l l which may be, for example, a satellite-based nationwide paging service network. Alternatively, paging system network 111 may be a cellular co"~ tions network or a Personal Comm -nit~tions Services (PCS) network.
Paging ~ystem network 111 includes a base station (not shown) that receives the dialed 10 number along with the message of FIG. 5. The base station then identifies a particular frequency associated with that paging telephone number to code the received message as a series of pulses represented by a carrier that is modulated on that frequency for delivery to pager 135. The latter converts the pulses into a series of bytes representing the message of FIG. 5. Thereafter, pager 135 emits a loud beep to signal the card owner of an incoming 15 message. Alternatively, pager 135 could be a vibrating pager which silently alerts the card owner of the incoming message through a vibration signal generated therein in response to the reception of a message.
When the incoming message is an alert signal from validation ~i~t~b~ce 106, pager 135 can be any co~ ially available paging device with a small screen for displaying the 2 0 message of FIG. 4. However, if an approval/di~ploval response is requested by validation d~t~h~se 106, pager 106 rnay advantageously be a two-way paging device, such as the device available from Mobile Telecollllll...li~;~iolls Technology Inc. of Jackson, Mississi~i. In that case, the card owner hal~lllils an approval/disapproval message by entering a pre-defined code in the two-way pager. The pre-defined code is then ll~ ed to validation d~t~h~ce 25 106 via paging system network 111. The pre-defined code is received by one of the demodulators 12~1 to 120-N which demodulates the signals associated with the received code for prese~t;~ n to validation ~t~b~ce 106. Alternatively, pager 135 may be a one-way pager. In this case, if an approvaVdis~ploval response is requested by validation ~t~h~ce 106, the card owner may co~ e an approval/di~ploval message to validation 3 0 d~t~h~se 106 by other means, such as with use of a conventional telephone, for example.

A first illustrative embo~~ t 2176~ 3 FIG. 7 shows a flow diagram in accordance with certain illustrative embodiments of the present invention outlining prog~ .læd instructions executed by different elements of the co~ ;c~tions system of F~G. I to receive an approval from a credit card owner for, or to alert a credit card owner of, a credit card transaction initiated by a card holder. The process 5 shown in FIG. 7 is initi~t~ in step 701 when validation ~t~h~ce 106 receives a validation request for a credit card number. As rnentioned above, the request for approval rnay be received in the form of a data message, such as the one illustrated in FIG. 2. Upon receiving the credit card nurnber, validation l~t~b~5e 106 uses the received credit card number as a search ~ey in an attempt to retrieve a profile for the credit card number. If no profile is 10 available in the validation ~t~b~se for the credit card nurnber, as determined in step 702, validation ~l~t~b~ce returns an "unauthorized transaction" message to card reader 101 via co~ ,...ic~tions network 102. When validation d~t~h~ce 106 is able to retrieve a profile for the card nurnber, the profile is analyzed in step 704 to determine whether the requested credit amount or the type of transaction, for example, triggers any alerting or request for approval 15 conditions. If no such conditions are triggered, validation d~t~h~ce 106 proceeds with the validation process in a conventional manner. Otherwise, in step 706, validation ~t~tMse 106 ascellaills whether the card owner is only to be alerted when the pre-defined condi~ioll is encoullleled. If so, validation l~t~b~se 106 retrieves from the profile the card owner's co,~ alions address to which the alerting message is sent, as in~ te~ in step 707.
20 Thereafter, validation cl~t~h~ce 106 proceeds with the validation process in a conventional manner.
When the profile retrieved by validation d~t~b~c~ 106 in~ tes that the card owner is to approve the credit card transaction (such as the one requested by the card holder) validation ti~t~ce 106 forrnulates a request for approval message (using applu~liate entries 25 in FIG. 4 and FIG. S) for llA~ sion to the card owner, as in~ t~l in step 708. As mentioned above, the request for approval message may be delivered in the form of a telephone call or a paging message. After the tlAI~c~ cic)n of the message, validation d~t~b~ce waits for a response from the card owner. When validation cl~t~h~se determines, in step 709, that no response is forthcorning after a pre-defined period of time has expired, 3 0 validation cl~t~h~ce 106, in step 711, assesses whether the requested credit amount exceeds the no-answer-credit threshold. As in~ir~tçd earlier, the no-answer-credit threshold is a field in the profile for a card number which stores the maximum amount of credit that can be 217616~

approved for a credit card tl~s~lion when the credit card owner cannot be reached by the co"""~ C~tions system of FIG. 1. If the requested credit amount exceeds the no-answer-credit threshold, as determined in step 711, then validation d~t~h~ce 106 returns an "unauthorized tr~nc~tion" rnessage to card reader 101. If the requested credit arnount does 5 not exceed the no-answer-credit threshold, the content of the tr~ncaction counter field in the profile is compared to the no-answer-transaction threshold to determine whether this threshold has been exceedçd If so, validation ~ b~ce 106 returns an invalid card message to card reader 101, as in~ ted in step 705. If neither of the no-answer-thresholds has been exçP~I, validation ~l~fab~ce 106 completes the validation process in a conventional manner, 10 as in~1ir~te~1 in step 703.
When validation d~t~h~se 106 receives a response from the card owner within a pre-defined period of time, as determined in step 709, validation d~t~h~ce 106 then assesses whether the response in(li~tes approval of the transaction by the card owner. If so, validation d~t~h~ceæompletes the validation process in a conventional manner, as intli-~ted in 15 step 705. Optionally, the cardholder may be required to provide a secret code that m~t~hPs a sirnilar code included in the res~onse received from the card owner hefore the transaction is .ltl,ol~ed. If a disapproval lesponse is received from the card owner, validation ~t~h~ce 106 returns an "un~llthorized t~ sa~;tioll" message to card reader 101.
FIG. 8 ic a flow chart outlir~ing instructions ~lr~Jlllled by the elements of the 20 illustrative col"-",l"icati-ns system of FIG. 1 to validate a debit card tl~sa;lion in æcordance with a first illustrative embodiment of the present invention. The process depicted in FIG. 8 is initi~ted in step 801 when validation cl~t~b~ce 106 receives a debit card number and a password entered by a rninor card holder. Validation cl~t~b~ce 106l~nn~.hPs a query on its storage devices to dçtçrmirlP. in step 802, whether a profile can be retrieved for 25 the received card number. If no profile is found, validation d~t~h~ce 106 transmits an '~un~ulll~l~ed tr~nc~ction" message to card reader 101, as in~ ted in step 803. Upon retrieving a profile for the card number, validation d~t~b~ce 106 formulates a message using one of the entries of FIG. 4 for tl~ ",;c~ n to the card owner. Thereafter, validation database 106 waits a pre-defined amount of tirne to determine whether a response is received 3 0 from the card owner. If the pre-defined amount of tirne expires before a response is received from the card owner, validation t~t~b~ce 106 returns an "unauthorized transaction" message to card reader 101, as in~ t~A in step 803. When a response indicative of the card owner's 217~ 163 approval of the tr~n~rtion is received from the card owner, as deterrnined in step 806, validation ~1~t~h~ce 106 proceeds with the validation process in a conventional manner, as inrli~teA in step 807. If the card owner sends a message disapproving the debit card transaction, validation d~t~h~ce 106 sends an "unauthorized transaction" message to card S issuer 101, as inrlic~te~l in step 803.
In other illustrative emhodiments of the present invention, the authorization of a transaction rnay need to be approved by more than one party. For example, if the charge account is a corporate account and the arnount of the charge is over a certain predef~lied thresho;d, it may be required that two authorized parties (e.g., corporate executives) approve 10 the l~ n. This is analogous, for example, to the comrnon requirernent that corporate checks over a certain amount (e.g., $1,000) include two authoriæd signatures to be valid.
Similarly, if the transaction involves, for example, the di~ellsing of n~ tions in a hospital (see below), it may be desirable that both the patient's doctor and the hospital's ph~rm~rist approve the treatment. In these cases, step 806 of FIG. 8 is rnodified to deterrnine whether 15 all parties which are required to approve the t~ sa lion have done so.

A second illustrative ~ bo l;~ "~
FIG. 9 shows a flow chart of a credit card purchase tr~n.c~ction to which certain illustrative embodiments of ~he present invention rnay advantageously be applied. The 2 0 llallS~;liOI1 is inhi~te~ by a cardholder (i.e., the customer) who instructs a retailer to charge a ~ul-,hase to a given credit card account (step 11). This instruction usually takes the form of providing a credit card or a credit card nurnber to the retailer. This tl~lsa~lion may occur with the customer and the retailer co-present and in real-time, while the customer is waiting.
In this case, the tin~lin~ss with which the authorization process is cornpleted is clearly of 2 5 great importance, since the relevant parties are awaiting such authorization before they rnay proceed with other endeavors. (For exarnple, they rnay be waiting so that the retailer rnay hand over the goods to the customer or provide a service thereto.) Thus, the CO~ iQI1 to the customer and a cor~l~tion or denial of authorization by the customer should advantageously occur quickly. For this reason, the use of two-way pagers is p~f~lled for 3 0 this type of application of the principals of the present invention.
In alternative applications, the custorner may have instructed the retailer (or an agent of the retailer) in person or via some col""l,l,~ ion n~~ lll (e.g., a phone, rnail, facsimile or electronic mail) at a time prior to the initiation of the transaction. Such instructions rnight cover an imm~ te one-time purchase, a future purchase (e.g., the goods or service may not be immPAj~ely available) or a series of purchases to occur over a period of time. In cases such as these where the customer and the retailer are not co-present, the 5 parties st typically do not require the authorization to be cornpleted before they rnay proceed with other endeavors. That is, it rnay be acceptable in these cases that the authorization process be cornpleted over a longer period of time such as, for example, several hours or even a day. In these cases, therefore, other less imm~ te co"""..i~ir~;ons .c may be used, such as those provided by conventional telephones, e-mail, or, in 10 sorne cil-;ul~ res, even physical mail.
In any event, the retailer's typical l~sL,onse to such instructions is to signal a transaction processing center (or a network of such centers) which is associated with the credit card service provider that a particular customer (identified by his or her credit card number) wishes to purchase goods or services of a particular value. Thus, the retailer 15 requests an autholL~Lion for the charge from the ll~sa;lion processing center (step 12).
Typically, this request is initiated by swiping the credit card through an automated card reader (such as card reader l0l of FIG. l) which reads the m~gn~ti~ stripe on the credit card, dials the tr~n.~~tion processing center, sends the relevant il~l,l~Lion thereto and receives either an authorization code or a def~ial in ~onse liR~LullL The illrollnation transmitted to the 2 0 transaction processing center typically includes the credit card number, the arnount of the colllell~ldted ~ul-;hase, and the retailer's store ~ rir~ code (e.g., card nurnber 201, re~ est~ credit amount 202, and ll~l~;hdllt code 203 of FIG. 2, respectively). The retailer then waits for an authorization from the transaction processing center which replc;sellts that the charge will be underwritten (i.e., insured) by the credit card service provider. This 25 al~Llloli~dtion is typically sent to the retailer in the form of an authorization code which ir~ s the transaction and can thereby be used to verify that the authorization process was properly adhered to by the retailer. One typical reason for denial, on the other hand, is that the balance on the customer's account has exceeded (or, if the given purchase were authorized, would exceed) a predetermined credit lirnit associated with the customer's 3 0 account. In accordance with certain illustrative embodiments of present invention, another reason for denial is the lack of the receipt of an a~ropliate col~illl~tion (or the receipt of an explicit denial) by the customer whose account is to be charged.

. 2176163 At the tr~rl.C~tion processing center, the authorization process is perforrned automatically by a computer based system comprising, inter alia, a d~t~b~se (e.g., validation d~t~h~ce 106 of FIG. 1) containing account illfo~ ion for each credit card subscriber (step 13). That is, such a system autornatically makes the decision whether to authorize or deny 5 the transaction -- no human intervention is typically required at the transaction processing center. If the tr~ lion is authorized (decision 14), as is typically in-lic~ted by the a~pe~ dllce of the authorization code on the display of the retailer's card reader, the retailer is thereby authorized by the credit card issuer to accept the charge for the purchase. Thus, the charge i,s accepted and the transaction is completed (step lS). If, on the other hand, the 10 transaction is denied by the transaction processing center (typically in~ir~ted by the a~pea ance of a denial code on the card reader's display), the retailer denies the charge and terminates the tl~".c~c~ion (step 16).
FIG. 10 shows a flow chart of an automated authorization process which rnay be - used to implement step 13 of the process of FIG. 9 in accordance with a second illustrative 15 ernbodiment of the present invention. The process of FIG. 10 is illustratively executed by a computer system at the ~ sa~Lion processing center in response to each received request for the authorization of a llallsa~;lion. The received authol~tion request (typically ll~"~"l~ed by an automated card reader at the retailer's location such as card reader 101 of FIG. 1) inrhldec, in particular, a customer i-l~ntifi~r (ie., the credit card number) and may, for 2 0 example, also include the amount of the proposed ~ur~hase and the retailer's store rntl ion code (step 20). Based on the customer identifi~o.r, a database (such as validation d~t~h~ce 106 of FIG. 1) is consulted to detelll~ille whether the transaction should be a.llllol~d (steps 21 and 22). For example, the i~t~b~Cp may include account balance and credit limit ii~fGtlll~ltiOII in-lir~tin~ that the customer's account balance is not permitted to 25 exceed a given credit limit. In such a case, the system will deterrnine that the tr~nc~rtion should not be authorized if the sum of the account balance and the amount of the purchase to be authorized exceeds the credit limit. In addition, invalid or (known to be) stolen credit cards obviously should not be authorized.
If it is determined from the analysis of step 22 that the purchase should not be3 0 authorized for some reason (decision 23), the system will format a denial code (step 24). If, on the other hand, there is no basis for denying the ll~ls~lion, the system will, in accordance with the principles of the present invention. rnake an attempt to have the (tentative) 18 217~16~
authorization co~ æd by the customer. In particular, and in accordance with a second illustrative embodiment thereof, the system will autornatically page the customer (using, for example pager 135 of FIG. 1), supplying to him or her any relevant information concell~i.lg the purchase (step 25). For example, the system might supply the customer with an identity 5 of the retailer and/or the arnount of the ~ chase, in order to enable the customer to more accurately ensure that the transaction to be authorized is, in fact, the one he or she is presently undertaking, or, alternatively, that the transaction is one being undertaken by an agent and the principal (ie., the customer) approves thereof. The customer's pager number (i.e., the telephorie nurnber which is used to co~"".~ e with the pager) may, for example, be stored 10 in the ~t~b~ce and associated with the customer's account, as is shown in FIG. 3.
Once the customer has been paged, the system of the second illustrative embodiment waits for a confirmation from the customer which may be supplied with use of the custorner's two-way pager (step 26). If the customer responds with an applop,idte collr~ iol1 (decision 27), the system generates, formats and stores an authorization code which will 15 enable the tr~nC~rtion to be completed. If, on the other hand, the customer does not confirm the ll~ls~lion (e.g., if no Icsponse is received from the customer within a predetermined amount of time), the system formats a denial code (step 24). A~ter either a denial code or an autholi~tion code has been rolll~Lled~ it is sent to the retailer (e.g.., to card reader 101 of FIG. 1) who originally submitted the autholi~tion request (step 29).
A Third ~ dlive Emho l;-....,~
FIG. 11 shows a flow chart of an autornated authorization process which may be used to implement step 13 of the process of FIG. 1 in accordance with a third illustrative embodiment of the present invention. As can be seen from the figure, the illustrative process 2 5 of FIG. 11 is itlel-ti'`:~l to the illustrative process shown in FIG. 10 except that decision 27, which clete~ 1 whether a co-~,l~ation was received from the customer is replaced by decision 30, which determines whether a denial is received from the custorner. Other ernbodiments of the present invention may combine those shown in FIG. 10 and FIG. 11 by accepting either a co-~ll ation or a denial from the custorner. In such a case, the default 3 0 (i.e., timeout) criterion rnay be either an ~cs~ CO"~",~Iion or an assumed denial.

A Fourth Illustrative F.mho.l~

~7616 3 FIG. 12 shows a flow chart of an authorization process which rnay be used to implement step 13 of the process of FIG. 9 in accordance with a fourth illustrative embodiment of the present invention. This fourth embodiment may advantageously be ernployed when the customer has only a one-way (as opposed to a two-way) pager, since it S allows for the customer's col~,nalion to be co,-""~ ;r~teci indirectly through the retailer.
Specifically, the i~lustrative process of FIG. 12 is identical to that of the i'~ustrative embodiment of FIG. 10 and FIG. 11 except in the mechanism by which the customer col~,llation is requested and received.
In particular, when decision 23 detem~ines that it is okay to authorize the t,allsa.;~ion, 10 the illustrative system of this fourth embodiment generates a confirmation code and supplies that code to the customer via his or her (one-way) pager (steps 41 and 42). The supplied co"ri.",~ )n code may, for example, be randornly generated so as not to be pre~ t~bl~.. In this manner, the collLII~tion code will be known only to the customer (and not, for example, to a fr~udlll~nt user of the customer's credit card number who is not in possession of the 15 custorner's pager). The co,lr"",i1t;ol code may then be used to indirectly confirm the aullloli~tion. For example, where the customer is making a face-to-face purchase in a store, the customer rnay provide the co~ lion code supplied by the trdl~saelion processing center to the retailer, who may, in tum, provide that confirmation code back to the tld,~.~lion processing center. This latter step may be pe,r~Jlll~ed, for example, with use of 2 0 the autornated card reader which is already in co"""~ a~;on with the transaction processing center.
Thus, after the illustrative process of FIG. 12 has supplied the col-r, -,~t;on code to the customer, step 43 waits for a responsive input which includes a (return) L:ollGIII~lion code (e.g., from the automated card reader). Then, the col~ll~lion code which was 25 supplied for the given transaction is coll4)~ed to the co-~ll~lion code that was received (decision 44) to ensure that the customer is, in fact, providing a proper collGllnation of the autholi~lion. If the supplied col~ll~lion code matches the received confinn~titln code, the system authorizes the llalLsa~lion (steps 28 and 29). If they do not rnatch, or if the system receives no responsive col~ lion code after a predeterrnined amount of time has elapsed, 3 0 the transaction is denied (steps 24 and 29).

A Fifth Illustrative Embo~ "~l~t . 2176163 FIG. 13 shows a flow chart of a credit card purchase transaction to which a fifth illustrative embodirnent of the present invention may advantageously be applied. This fifth ernbodiment e!irnin~tes the need for pelro~ .lg multiple commllni~tions at the tirne of ~ulchase. That is, the extra time that may otherwise be required to page the customer and 5 receive a coll[illl~tion or denial of the pending authorization are not needed when this fifth illustrative embodirnent is employed.
Prior to the initiation of the transaction itself, the customer requests and receives a co~ ll~tion code for use in a ~ecirlcally identified subsequent tr~ncacti-~n (steps 51 and 52).
Thic conr~ atioll code, which may, for example, be randomly generated, will be known only 10 to the customer who intends to execute the specific tr~nc~ction (e.g., make a particular ~urchase), or, alternatively, to an agent of the customer (ie., the principal) to whom the customer has co~ ir~ted the given confirrn~tion code. The specific transaction may, for example, be identifi~d based on the retailer's store i~ ri~tion code tsuch as ll~lchant code 203 of FIG. 2) or other identifying indicia of the retailer. Then, when the ~lc,hase is 15 initi~tç~, the customer (or the principal's inforrned agent) provides the previously received co-~r""~,lliQn code to the retailer, who, in turn, provides the col~ri""~ti~n code to the llans~;lion processing center which pelrulll~ the automated authorization process (steps 53-SS). The automated authorization system can then use the received cor~ll~tion code in a manner similar to that of the fourth illustrative ernbodiment shown in FIG. 12 for purposes of 20 confilming an authol~tion of the lld~sa~lion. Note that since the two-way co"""l~n,~i.lion process of steps S l and 52 need not occur at the time (or at the location) of the purchase but, rather, rnay precede the transaction by a subst~nti~l arnount of tirne, a wide variety of co""".~ lions devices (in addition to one-way or two-way pagers) rnay advantageously be used in realizing the fifth illustrative embodiment.
FIG. 14 shows a flow chart of an automated authorization process which may be used to implernent step 55 of the process of FIG. 13 in accordance with the fifth illustrative ernbodiment of the present invention. As des~nhed above, upon the receipt of a custorner's request for a co~ Illation code to be used in ex~utin~ a specific (future) transaction, the illustrative authorization system generates and supplies a confirrnation code to the customer.
30 In addition to its being supplied to the customer, however, this confi~Tnation code is associated with the customer identifier and, for example, the retailer store i-l~ntifi~tion code, and this data is then stored in the transaction processing center d~t~b~e (e.g., validation ll~t~h~ce 106 of FIG. 1) for later retrieval -- that is, when the identified transaction is actually executed Thus, upon a request for authorization of the given transaction, the illustrative process of FIG. 14 retrieves the previously supplied confirmation code from the d~t~b~ce based on the customer identifier and the retailer store identification code (steps 61 5 and 62). Then, after it is deterrnined that the transaction should (otherwise) be authorized, the system verifies that the confirmation code received with the request for authorization ch~s the confirmation code previously supplied to the customer (decision 63). If they do in fact match, the authorization rnay he confirmed (steps 28 and 29).

10 A Sixth Illustrative Embo linnPnt In accordance with a sixth illustrative embodiment of the present invention, a co~ ~tion code may he provided to a customer without the customer rnaking a specific request therefor. This embodiment may he advantageously applied to a credit card ~ulchase transaction in a similar manner to the fifth illustrative embodiment described above. In 15 particular, the flow chart shown in FIG. 13 may be modified by removing step S1 theleLollL
Then, instead of the customer requesting and receiving a co~",ation code for use in a s~ir~cally iden~ifi~ subsequent trdllsa~;lion, the customer (automatically) receives a new co"~"~lion after each l~lsa~;lion and/or periodically (e.g., each morning) for use in his or her next l,A~-~tion. By limiting the use of the given co,~i""ation code to, for example, a 2 0 single transaction, the advantages of the present invention in protecting against fr~ d-lk n~
transætions is obtained, while no direct col l ~ ;on from the customer to the transaction processing center is required. Thus, for example, as in the case of the fourth and fifth illustrative embodiments, one-way pagers may advantageously be used. Moreover, the use of a col~l~tion code which does not match the last previously supplied confirmation code but, 2 5 rather, m~t~h~s one used in a previous t,~s~;Lion may well be indicative of fraud.

Although a number of specific embodiments of this invention have been shown and descril~l herein, it is to be understood that these embodiments are merely illustrative of the many possible specific arrangements which can be devised in application of the principles of 3 0 the invention. Nurnerous and varied other arrangements can be devised in accordance with these principles by those of ordinary skill in the art without departing from the spirit and scope of the invention. For example, although the embodirnents described above have focused on a credit card purchase transaction, it will be obvious to those of ordinary skill in the art that the principles of the present invention may be applied to a wide variety of transætions including, but not limited to, telephone calling card transactions, banking l~ansa~;lions including those using PINs, stock and commodity trading transactions, and 5 secure access tr~nC~tions such as computer access transactions based on computer passwords. Ln addition, the principals of the present invention may be applied to numerous other types of secure access transactions such as physical access (ie., entry) tr~lS~liOnS
in~hl~ing those used for purposes of inventory control. For example, an entry door to a secure room (e.g., a hospital's n~ tion room) or to a secure facility may be locked by an 10 el~;lloluc locking system (e.g., co--ll,---ation keypad or card access entry) which is ele~;l.ol~ically linked to a central facility such as the transaction processing center described above. Then, any attempt to enter the room or facility may be made subject to co~ lion in accordance with the principals of the present invention.
In addition, although the above ernbodirnents focused primarily on co"""~ l;on 15 via wireless paging devices (e.g., one-way or two-way pagers), it will be obvious to those skilled in the art that many other co""""l,;,~lions ll~l`h~ llLC may be used instead of, or in addition to, wireless paging devices. These ~ h~ Lc include, for example, cellular telephones, conventional wired telephones, personal co--~ule.s, etc.

Claims

1. An automated method for authorizing a transaction, said transaction based on a customer identifier associated with a customer, the method comprising the steps of:

receiving a request to authorize said transaction, said request including said customer identifier;

determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

if said determining step determines that said transaction is to be authorized, communicating said determination to said customer;

receiving a communication from said customer confirming that said customer consents to said transaction being authorized; and authorizing said transaction in response to said communication received from said customer.

2. The method of claim 1 wherein said transaction comprises a sales transaction and wherein said customer identifier comprises a credit card number.

3. The method of claim 1 wherein said transaction comprises placing a telephone call and wherein said customer identifier comprises a telephone calling card number.

4. The method of claim 1 wherein said transaction comprises a banking transaction and wherein said customer identifier comprises a bank card number.

5. The method of claim 1 wherein said customer identifier comprises a Personal Identification Number.

6. The method of claim 1 wherein said step of communicating said determination to said customer comprises transmitting signals representative of said determination to a wireless telecommunications receiver.

7. The method of claim 6 wherein said wireless telecommunications receiver comprises a display and wherein said step of communicating said determination tosaid customer comprises communicating said customer identifier to said customer.

8. The method of claim 6 wherein said wireless telecommunications receiver comprises a display and wherein said step of communicating said determination tosaid customer comprises communicating an identity of said provider to said customer.

9. The method of claim 6 wherein said wireless telecommunications receiver comprises a pager.

10. The method of claim 6 wherein said wireless telecommunications receiver comprises a two-way pager and wherein said communication from said customer confirming that said customer consents to said transaction being authorized is transmitted by said customer with use of said two-way pager.

11. An automated method for authorizing a transaction, said transaction based ona customer identifier associated with a customer, the method comprising the steps of:

receiving a request to authorize said transaction, said request including said customer identifier;

determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

if said determining step determines that said transaction is to be authorized, communicating said determination to said customer; and determining whether a communication indicating that said transaction is not to be authorized is received within a given amount of time from said customer; and authorizing said transaction if said communication from said customer is not received within said given amount of time.

12. The method of claim 11 wherein said transaction comprises a sales transaction and wherein said customer identifier comprises a credit card number.

13. The method of claim 11 wherein said transaction comprises placing a telephone call and wherein said customer identifier comprises a telephone calling card number.

14. The method of claim 11 wherein said transaction comprises a banking transaction and wherein said customer identifier comprises a bank card number.

15. The method of claim 11 wherein said customer identifier comprises a Personal Identification Number.

16. The method of claim 11 wherein said step of communicating said determination to said customer comprises transmitting signals representative of said determination to a wireless telecommunication receiver.

17. The method of claim 16 wherein said wireless telecommunications receiver comprises a display and wherein said step of communicating said determination tosaid customer comprises communicating said customer identifier to said customer.

18. The method of claim 16 wherein said wireless telecommunications receiver comprises a display and wherein said step of communicating said determination tosaid customer comprises communicating an identity of said provider to said customer.

19. The method of claim 16 wherein said wireless telecommunications receiver comprises a pager.

20. An automated method for authorizing a transaction, said transaction based ona customer identifier associated with a customer, the method comprising the steps of:

communicating to said customer a confirmation code for use in executing said transaction;

receiving a request to authorize said transaction, said request including said customer identifier and said confirmation code;

determining, in response to said request, based on said customer identifier, and based on whether said received confirmation code matches said confirmation code communicated to said customer, whether to authorize said transaction;

authorizing said transaction if said determining step determines that said transaction is to be authorized.

21. The method of claim 20 wherein said step of communicating to said customer said confirmation code comprises encoding said confirmation code to provide a secure communication thereof.

22. The method of claim 20 wherein said transaction comprises a sales transaction and wherein said customer identifier comprises a credit card number.

23. The method of claim 20 wherein said transaction comprises placing a telephone call and wherein said customer identifier comprises a telephone calling card number.

24. The method of claim 20 wherein said transaction comprises a banking transaction and wherein said customer identifier comprises a bank card number.

25. The method of claim 20 wherein said customer identifier comprises a Personal Identification Number.

26. The method of claim 20 wherein said step of communicating said confirmation code to said customer comprises transmitting a signal representative of said confirmation code to a wireless telecommunications receiver having a display.

27. The method of claim 26 wherein said wireless telecommunications receiver comprises a pager.

28. The method of claim 20 wherein said step of communicating to said customer a confirmation code for use in executing said transaction is performed in response to receiving a communications from said customer indicating that said customer desires to execute said transaction.

29. The method of claim 20 further comprising the step of communicating a second confirmation code to said customer after authorizing said transaction, said second confirmation code for use in executing a second transaction subsequent tosaid transaction and being different from said confirmation code.

30. An automated method for authorizing a transaction, said transaction based ona customer identifier associated with a customer, the method comprising the steps of:

receiving a request to authorize said transaction, said request including said customer identifier;

determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

if said determining step determines that said transaction is to be authorized, communicating to said customer a confirmation code for use in completing execution of said transaction;

receiving a communication comprising said confirmation code; and authorizing said transaction in response to said received confirmation code matching said confirmation code communicated to said customer.

31. The method of claim 30 wherein said step of communicating to said customer said confirmation code comprises encoding said confirmation code to provide a secure communication thereof.

32. The method of claim 30 wherein said transaction comprises a sales transaction and wherein said customer identifier comprises a credit card number.

33. The method of claim 30 wherein said transaction comprises placing a telephone call and wherein said customer identifier comprises a telephone calling card number.

34. The method of claim 30 wherein said transaction comprises a banking transaction and wherein said customer identifier comprises a bank card number.

35. The method of claim 30 wherein said customer identifier comprises a Personal Identification Number.

36. The method of claim 30 wherein said step of communicating said confirmation code to said customer comprises transmitting a signal representative of said confirmation code to a wireless telecommunications receiver.

37. The method of claim 36 wherein said wireless telecommunications receiver comprises a pager.

38. An automated system for use in authorizing a transaction, said transaction based on a customer identifier associated with a customer, the system comprising:

a receiver adapted to receive a request to authorize said transaction, said request including said customer identifier;

means for determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

a transmitter adapted to communicate said determination to said customer if said means for determining determines that said transaction is to be authorized;

a receiver adapted to receive a communication from said customer confirming that said customer consents to said transaction being authorized; and means for authorizing said transaction in response to said communication received from said customer.

39. An automated system for use in authorizing a transaction, said transaction based on a customer identifier associated with a customer, the system comprising:

a receiver adapted to receive a request to authorize said transaction, said request including said customer identifier;

means for determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

a transmitter adapted to communicate said determination to said customer if said means for determining determines that said transaction is to be authorized;

a timer adapted to determine whether a communication indicating that said transaction is not to be authorized is received within a given amount of time from said customer; and means for authorizing said transaction if said communication from said customer is not received within said given amount of time.

40. An automated system for use in authorizing a transaction, said translation based on a customer identifier associated with a customer, the system comprising:

a receiver adapted to receive a communication from said customer indicating that said customer desires to execute said transaction;

a transmitter adapted to communicate to said customer a confirmation n code for use in executing said transaction;

a receiver adapted to receive a request to authorize said transaction, said request including said customer identifier and said confirmation code;

means for determining, in response to said request, based on said customer identifier, and based on whether said received confirmation code matches said confirmation code communicated to said customer, whether to authorize said transaction; and means for authorizing said transaction if said means for determining determines that said transaction is to be authorized.

41. An automated system for use in authorizing a transaction, said transaction based on a customer identifier associated with a customer, the system comprising:

a receiver adapted to receive a request to authorize said transaction, said request including said customer identifier, means for determining, in response to said request and based on said customer identifier, whether to authorize said transaction;

a transmitter adapted to communicate to said customer a confirmation code for use in completing execution of said transaction if said means for determining determines that said transaction is to be authorized;
a receiver adapted to receive a communication comprising said confirmation code; and means for authorizing said transaction in response to said received confirmation code matching said confirmation code communicated to said customer.

42. A method of processing a transaction, the method comprising the steps of:

receiving information associated with a transaction initiated by an agent of a principal;

retrieving a profile based on said information associated with said transaction;
comparing at least a portion of said information to data included in said profile; and in response to said comparison, notifying said principal of said transaction.

43. The method of claim 42 wherein said notifying step further includes the stepof transmitting a message to said principal to request approval for the transaction.

44. The method of claim 43 further comprising the steps of:

receiving an approval signal from said principal; and in response to receiving said approval signal, authorizing said transaction.

45. The method of claim 44 wherein the approval signal from the principal is transmitted from a paging device which received the notification in response to the comparison.

46. The method of claim 43 further comprising the steps of:

receiving a disapproval signal from said principal and in response to receiving said disapproval signal, invalidating said transaction.

47. The method of claim 43 further comprising the step of invalidating said transaction when no signal is received from said principal in response to said request for approval message.

48. The method of claim 42 wherein said comparing step further includes the stepof determining whether parameters included in said second subset of information exceed threshold values represented by said data included in said profile.

49. A system for processing a transaction, the system comprising:

a database which receives information associated with a transaction initiated by an agent of a principal and which stores a profile defined by said principal;

a processor which a) retrieves said profile from said database based on said information associated with said transaction, and b) compares at least a portion of said information to data included in said profile; and a network over which a notification signal is transmitted to said principal in response to said comparison.

50. The system of claim 49 wherein said notification signal includes a message requesting approval of the transaction.

51. The system of claim 50 further comprising:

an end-user device from which an approval signal is transmitted by said principal to said database; and means responsive to receiving said approval signal at said database, for authorizing said transaction.

52. The system of claim 51 further comprising a paging device which a) receives the notification signal in response to the comparison, and b) transmits the approval signal from the principal.

53. The system of claim 50 further comprising:

an end-user device from which a disapproval signal is transmitted by said principal to said database; and means responsive to receiving said disapproval signal at said database, for invalidating said transaction.

54. The system of claim 50 further comprising means for invalidating said transaction when no signal is received from said principal in response to said request for approval message.

55. The system of claim 49 wherein said processor further includes means for determining whether parameters included in said second subset of information exceed threshold values represented by said data included in said profile.