CA2086572A1 - Data card terminal with embossed character reader and signature capture - Google Patents

Abstract

"DATA CARD TERMINAL WITH EMBOSSED
CHARACTER READER AND SIGNATURE CAPTURE"

Abstract of the Disclosure A data card terminal, such as a credit card transaction terminal, is disclosed. The terminal includes a transaction terminal comprising an embossed character reader and magnetic stripe reader, with a separate signature capture printer. The transaction terminal is operative for detecting the physical presence of a data card during a card transaction. The embossed character reader employs a tactile imager and pattern recognition for detecting the embossed characters on the data card. A signature capturing printer prints a paper receipt, which is signed by a cardholder at a signature capturing window on the printer. A signature capturing system digitizes and compresses signals corresponding to the signature of the card holder.
Transaction data including compressed signature signals and signals indicative of the presence of the card are transmitted to the host computer system of a transaction processor, who guarantees the transaction as chargeback-protected under certain circumstances. Also disclosed are methods for operation of the terminal, and methods for operation of transaction processor systems responsive to signals from the terminal, such as providing chargeback protected transactions and providing electronic and off-line transaction authorizations.

Description

"DATA CARD TERMINAL WITH EMBOSSED
CHARACTER READER AND ~IGNATIJRE CAPTURE~' The present invention relates generally to data card transaction systems that use ~erminals such as credit card transaction terminals, and relates more particularly to a data card transaction terminal that detects the physical presence of a data card wi~h an emboss2d characeer reader and a magnetic stripe 2s reader~ provides signature capturing capability, and may be utilized in trans~ction information processirlg systems for conducting ~ransactions that are chargeback protected to a merchant utili ing the tenninal.
:~
30 ~
This application discloses subject matter in common with application Serial No. _ filed concurren~ly herewith, on December 31, 1992.

2~ $~r-~

The use of data cards or payment cards~ such as credit cards, has gained widespread acceptance as a method of paying for goods and services. As used herein, the term "data s card" will be generally used to signify such cards, which can include credit cards, debit cards, and other financial account cards. Data cards in use ~oday typically include a magnetic stnpe containing account and other information, and most often include an account number and other information in embossed or raised 10 eharaeters.
Two elements must be present be~ore a credit card transaction can be completed successfully. First, dle consumer or eardholder must possess a valid credit card. Secorld, the merchsmt must be authorized to accept the card as payment for 15 the goods or services and to receive payment from the organization that issued the credit card. The card issuing organization subsequently receives ]payment from the cardholder.
Credit cards are issued by banks and other financial organizations, gene~ally as members and under the regulations of 20 a credit card issuing association or entity. VISA~, MasterCard~, DISCOVER CARD~, and AMERICAN EXPRESS~ are examples of credit card issuing associations or entities ~or particular brands OI data cards. When a credit card is issued, the issuer is, in effect, grantirlg a line of credit ~o the cardholder. Because the 2s issuer is granting a line of eredit, a credit card will be issued only after ~e issuer has con~ucted a credit b~ckground check and is satisfied as to ~he cardholder's ability and willingness to repay ~e debts incurred. T~e issuer's confidence is reflected in ~e amount of credit granted, which may range ~rom a ~ew hundred dollars 30 to tens of ~ousands of dollars.
M~y data card transactions involve third-party credit card transaction processors in addition to ~e merchant and credit card issuer. Transaction processors, which are sometimes independent busiIless institutions, provide mershan~s with data 3s processing services that facilitate ~e flow of credi~ card transaction data and the corresponding payments of monies :

between the merchants and card issuers~ The ~low of transaction dat~ from dle merchant to the issuer via a ~ransaction processor is commonly referred to as '~processing" or "clearing" ~he transactions. Tl e ~low of money from the issuer to the merchant 5 via a processor is known as "settlement". The term "transaction processor", as used herein~ generally means a third-party institution that processes card transactions independently of a card issuer, but can also include card issuers and card issuing associations that process their own ~ansactions.
lo In a typical credit card transaction, a card holder presents a credit card to a merchant, who records transaction data by using either an electronic terminal or a mamlally impnnted sales draf~. The recorded data include~ the amount of the purchase, the cardholder9s account number9 the card's expiration 1S date, the merchant identification num~er, and the date of the transaction. In most cases, the card~older is also required to sign a copy of the receipt.
At ~e end of each day, the merchant determines the total dollar volume of the credit card transactions completed and 20 prepares a deposit slip indicatiI~g tha~ amouIlt. All of the transaction data is then transferrecl to the merchant's credit card transaction processor and entered into ~e transaction processor's computers. This transfer may be e~ctronic, in which case a data capture terminal transfers the data directly to the processor's 2s compu~er. Altematively, ~e transfer may involve ~e deposit of imprinted paper sales drafts and subsequent entry of the data into ~he computers by ~he processor's da~a entry personnel.
Once the data is received by the transaction procPssar, ~e amount of the merchant's "deposit" is verified and 30 recorded. At ~at point, dle transactions are separated according to dle type of credit card used to complete ~e ~ransaction. The transaction processor ~en ~ sfers the corresponding ~ansaction data to the appropriate credit card issuer or card issuing association. After the data is transferred to the issuer, the issuer 35 posts the individual ~ransactions to the appropriate cardholder's account.

In most cases, settlement occurs very soon a~ter the data is cleared. For e~annple, after a transac$ion processor receives a merchant's daily transaction data, ~e balance due the merchant is calculated and paid to the merchant via check, direct 5 deposit, or wire transfer. llhe transaction processor so~s the transaction data from all of its client merchants according to the type of card used and forwards that data ~o dle appropriate card issuer. The issuer or card association then determines ~e balance due ~e transact;on processor and transfers ~at amount to ~he 10 transaction processor.
As a part of transac~ion settlement, transaceion processors and issuers assess fees for processing ~he credit card transaction. These fees are commonly referred to as the ';discount rate" and are usually calculated as a percentage of the 5 iFace value of the credit card transaction. The issuer deducts its fee as perceneage from the total amount due the transaction processor. ~
Although credit c ards provide significant convenience for both cardholders and merchants, there are also 20 well known risks associated with credit card ~ransaceions. The principal risk is loss resulting fN~m fraudulent or unauthorized ~se of the credit card. In such a case~ the goods or services are ta~en by the cardholder and are usually un~ecoverable. ~e loss mllst then be absorbed by ~e merchant, credit card transaction 2s processor, and/or the credit card issuer.
Over the years, card issuers ~d merchants have relied on several dif~erent me~ods to protect ~emselves ~rom ~raud or misuse and to verify ~e ~alidity of a credit c~d before comple~ing a transaction. Initially, the card issuers provided 30 "warning bulletins" to merchants. Waming bulletins, which are still in widespread use, are booklets ~a~ list ~e account numbers of credit cards that should no longer be accepted. Account ~umbers are included on dlese lists if dle card has been reported stolen, if ~he cardholder has exceeded his or her c~dit limit or 3s has become delinquen~ in the payments to the issuer, or if a card should not be accepted for ano~er reason (such as mistakenly , . . .

, ~

issued cards and cards that are invalid outside their country of orig~n)-More recently, card issuers and card issuingassociations have provided real-time access ~o ~heir computerized s da~abases. This allowed merchants to request telephonie authori~ation for a ~ransaction based on a search of a continually updaeed database be~ore completing each transaction. For a typical transaction authorization, ~he merchant obtains an "au~horization code" or authorization indicia from an 10 authorizatlon source or institution, often via telephone.
- Authorizatiorl sources inelllde card issuing associations, card issuers ~hemselves3 as well as independent credit card trarlsaction processors that also provide clearing and settlement services between merchants and card issuers.
1~Several different methods are currently used for obtaining authorizations. In one me~hod, a merchant uses a telephone to call a phone number provided by an authorization source or institution; an operator as~ociated wi~ ~e authorization institution enters the transaction data into a computer and zo provides an au~orization number or code to the merchant if the transaction is authorized. Some authorization institutions also provide a forrn OI audio response unit (ARU) that responds to dual tone multiple ~requency (DTMF~ signals entere~ from a merchant's TOUCH-TONE~ telephone. In this way, the 25 merch~t dire~tly en~ers the numerie ~ransac~ion data into a computer and receives an au~orization nurnber if dle transaction is au~orized.
Some transaction processors and card issuers provide electronic terminals ~at read ~e accoLult number and e~piration 30 date from a magnetic stripe on the credit card. Once ~he merchant enters the purchase amoullt into ~e terminal, the terminal au~omatically dials an authorization source host computer and initiates an autholization re~questO The terminal displays and/or stores an approval code (authoriza~ion ~ndicia~ if 3S ~e transact;on is au~orized. In each case, the approval code is recorded along wi~ the o~er transaction data. --, . ", ' ~ . : .
:

One particular dif~lculty ~at has been encountered in the use of prior art authorization systems is when a data çard transaction terminal is unable to communicate with the authorization source, or when communications with the s authoriza~ion source are interrupted. Such situations generally result in the merchant being forced to accept the risk of the transaction if ~e merchan~ decides ~o proceed wi~ dle transaction without receiving an authorization.
Another difficulty that often arises with known authorization systems is when a card issuer or card issuing association issues a "call me" in response to an authorization request. A "call me" or refe~Tal, as defined hereinbelow, typically results in a delay while the merchant places a telephone call to the entaty issuing the "call me~'. Such delay~ cause inconvenience to the merchant and cardholder, and can result in a possible lost sale. Again, the merchant is at risk if the merchant decides to proceed with the transaction wi~out contacting the authorization source and/or receiving authorization for the transaction.
Current manual systems for handling "call me"
responses and referrals are therefore in need of improvement.
Moreover, the inability of present systems to handle the interruption or failure to establish communications with audlonzation sources is in lleed of correction.
2s In order to insure ~at au~horization is received and that all transaction data is properly recorded, card issuing associations have established a variety of operating regula~ions.
These regulations include procedures for handling and present transactions for payment by ~e card issuing institution. If the merchant does I ot comply with the regulat;ons and/or procedures, the transaction may be 'Scharged back" to the merchant, who would then bear the loss associated with ~hat sale.
A "chargeback9' occurs when a credit card issuing association refuses to honor a presentment of a processed 3s transaction because the issuer believes it violates a specific operating regulation. The chargeback results in reversal of the - " , .
. . ~ . , . .

~ - . .
:

7 ~ 3~

transaction to the transaction processor or merchant. Some transaction processors provide research services on behalf of their customers/merchants in an effort to resolve the dispute to the bene~lt of the merchant and re-present the transaction to the s issuer for paymeIlt. Chargebacks are allowed only ullder specific conditiorls as provided in the associatiorl's operating regulations, and can be resolved or reversed only under speci~led conditions.
Chargebacks generally are of ~wo basic types. A
first comprises situations or disputes originating with a card 10 issuer or card issuing association alleging improper or incomplete transaction proeedures. A second comprises complaints originating with a cardholder regarding the origin of the transaction or the quali~y of the goods or seTvices received.
Disputes regarding transaction procedures can be lS further classified to include authorization-related disputes, retrieval~related disputes, and transaction data disputes.
Authorization related disputes are usually initiated by the card issuer when ~e credit card account is in a delinquent, over limit, or otherwise allegedly uncollectible condition, and the issuer 20 cannot loca~e a record indicating that the transaction was authorized. The premise ~or the dispute is that the issuer claims the tra~saction would not have beerl authorized if ~e merchant had properly sought authorization at the t~e of ~e transaction.
Retrieval-related disputes can be initiated by a ~5 cardholder or by a card issuer. These disputes commonly arise when a cardholder sees an unfamiliar transaction posted to his or her account. At that point, the cardholder is entitled to request, throu~h ~he issuer, a copy of the paper documentation supporting dle tsansaetion. In other situations, ~e card issuer may request 30 copies to aid in its research of disputes or fraud. Such requests are called "retrieval requests.'l Once the cardholder or issuer properly requests a copy of ~e documentation, ~e transaction - may be charged back ~o the transac~ion processor or merchant if the reguested docurnen~ation is not provided wi~in a prescribed 35 time limit. A ~ransaction can also be charged back when ~he cvpy of the transaction provided is of poor quality or legibility, or , .

does not include ehe minimum information re~quired by the card issuer9s regulatiolls.
Transaction data disputes typically occur when there are problems associated with the cardholder's account numker, s the amount of the purchase, the signature, the date of the transaction, the validity of ~e card on the date of ~e transaction, etc. Such problems may occur when any of the above data are imp~.operly entered or illegible. These disputes are commonly referred to as "technical" disputes or chargebacks, since they are based on errors in merchant procedures or in the entry of the data.
Cardholder disputes occur when the car&older denies partieipatioll in the transac~ion, or where the cardholder is dissatisfied with the merchandise or sen~ice purchased. In ~ese ls cases, federal laws provide a cardholder with certain consumer righ~s. Cardholder disputes may also include claims ~at a single transaction was processed more than one time, that a credit issued by the merchant to the cardholder was not processed, or that the cardholder had revoked a merchant's authority to charge his accoun$. ;
In each of the above situations, the transaction may be re-presented to the issuer and the chargeback reversed if ~e transac~ion processor and/or merchant are able to provide data d~at refutes or disproves the chargeback and substantiates the 2s transaction. As a result, ~e process of reversing a chargeback typically requires research and/or retrieval of transaction da~ on the part of the processor and/or merchant. ~ some cases, the issuer's operating regulations require that copies OI the sales drafts be re~ined by ~he merchant for three years from the date of ~e transaction. In addi~ion, ~e regulations typically impose fairly strict time limits for responding to retrieval re~quests or chargeback notices. As a result, a ~strieval or chargeback notice may require a merch~t ~o sort ~rough a very large number of archived paper receipts in order ~o locate the receipt Ln question and provide the information necessary to comply with ~he issuer's request.

. . . , -.
, -r ~

In recen~ years, several devices and senrices havebeen created in order to simplify the storage and retrieval of transaction data, and ~o reduce the likelihood of authorization-related and technical chargebacks by insuring the S accuracy of the recorded transactibn data. So-called electrorlic "data capture" data card transaction terminals eIectronically detect and decode the cardholder's account nurn~er and expiration date from the magnetic stripe, and receive a purchase amount from a keypad. Once ~he data is entered in this fashion, it is used to print lo a receipt and is electronically transmitted to a transaction prncessor.
The use of data capture ~erminals has helped eliminate keying errors and insures dlat the data recorded on a cardholder's receipt is ~e same data used to process and settle ~e 15 transaction. Howe~er, even when data capture devices are used, dle merchant still must keep paper copies of ~e receipts ~or up to ~ree years and comply wi~ any retrieval requests.
Some third party creflit card transaction processors marl~et their au~onzation, processing, and settlement services to 20 merchants in conjunc~ion with a "chargeback de~ense system" of some sort. The chargeback defense systems promoted by some processors include a review of ch~rgebacks against the operating regulations promulgated by card issuing associations. In addition, some transaction processors maintain databases of ~ransaction 25 infonnation ~hat allow the processor to obtain reversal of certain ~ypes of chargebacks on behalf of its custorners/merchants. For example, i an issuer refuses to honor a transaction because it is unable to locate an authori~atioll record, the processor may be able ~o reverse ~e chargeback without involving ~e merchant by 30 providing ~e missing record of authoriza~ion to the issuer.
Although transaction processors often attempt to reverse chargebacks without the involvement of the merchant, certain retrieval requests or chargeback regulations still require ~hat the merchant be involved in order to provide a copy of a 3s receipt or reply to a dispute regarding the quality of the goods or services received by the cardholder. Accordingly, merchants must , .

s~iLI maintain voluminous paper records of ~ansactions for many years, resulting in inconvenience and expense when these paper records must be searched in order to respond to a retrieval request or a chargeback situation.
s It is possible ~at d~ta card transactions where a card is physically presented by a card holder to a merchant and the accolmt number is electrollically obtained are more likely to be valid transactions of the card holder than ~ansactions where the account number was manually eneered at a keyboard. If it were possible to compare and verify the account number, e~piration date, or other ~nformation obtained from reading dle magnet;c stripe of a data card against anodler source of information associated with ~e card (such as the embossed characters on the data card or a second trac3c of information on the magnetic stripe), it would be even easier to verify that a card was physically present for the transaction. It would then be possible to provide c~dit card issuers and/or transaction processors with greater assurance ~at a data card was indeed physically present at a transaction terminal on a given date in connection wi~h a given transaction. Such greater assurances could there~ore provide an incehtive to a transaction processor or other entity to guarantee such transactions and make them "chargeback protected" for the merchant.
In addition, requirements for storage of paper 2s receipts gen~rated in connec~ion widl data card transactions could reduced or possibly eliminated if ~e information essential to verifying a transaction could be obtained and stored elec~o~ically. ~n many cases, the signature of a card holder is a key piece of information d~at reminds the card holder ~hat he or s~e actually pa~icipated in a par~icular transaction, or helps the card holder ascertain tha~ ~e signatu,re is a ~orgery. If signatures associa~ed with data card transactions could be electronically captured, sto~d, and associated with other transaction data, and such information could be readily retrieved upon request, it 3s might be possible ~o eliminate ~e requirement for retention of signa~ure-beanng paper transac~ion receip~s.

, Graphic digieizer devices enable provision and storage, as electronic signals, of the X and Y coordinates of a stylus relative to a tablet or other surface. Examples of such devices are shown in U.S. Patent Nos. 4,689,448, 4,705,919, and s 4,771~138. It is possible wid~ such devices, coupled ~o a computer sys~m, tc elçctronically capture and store a slgnature as an array of digi~al signals in a computer memory. However, because a signature is essentially a graphic object bounded in two-dimensional space by a rectangle enclosing ~e signature, it takes many digital signals to represent and store the signature electronically. Such a large volume of digital signals takes a long time to communicate electronically and consumes large amourlts of memory for storage. The data stnrage requirements and corresponding signal transmission time of the data representing a digi~ized ~ull signature have presented signifieant technical challenges to practical signature capture at data card terminals and concurrent transmission o:f the signature signals via tel~communication links to the host computer systems of transaction processors.
Apparatus for identifying cards based on embossing imparted to the surface of the card are known in the art. U.S.
Patent No. 4,783,823 of Tasaki et ~ll. describes a device including an embossment sensor or detector that is adapted to contact with the upper sur~ace of a card for ~ereby producing a signal 2s representative of the result of ~he detection. A memory associated wi~ dle card is loaded widl patten:l data corresponding to ehe pa~ern defined by the embvssment. When the card is inserted into the reader, the card is apparen~ly moved pas~ a linear array of sensors, and a circuit operates to read out identification data (pattern data) from the card's memory and detennine that the inserted card is ~e authorized one when ~e identification data read from the memory coincides with the info~mation (pat~ern3 camed by the embossed area formed in the card and read by the embossment detector.
T'ne Tasaki et al. ~atent provides little useful information as ~o how ~he pattern detectaon is actually -, , ~ ~

accomplished. It appears that the device merely detects a simple geometric pattern of raised areas embossed on the card ins~ead of embossed characters, since ~ere is no discussion that the pat~ern is encoded with information such as account number, name, 5 expiration date, or the like. Moreover, ~e movement of ~e card past the linear array of sensors requires a special mechanism to move and handle the card. It would be more useful and efficient in data card applications if ~he embossed character Iegion, whîch in credit cards contains name, account number, expira~ion date, 10 ete., could be read and decod~d to obtain ~e infolmation encoded ~erein, wi~out a complex card moving mechanism.
U.S. Patent No. 5,055,83~ describes a capacitive silicon tactile imaging array comprising a matri~ of sensors and a method of making same. Such devices migh~ be employed ~or 15 taking an electronic "picture" of the embossed character regions providled on many current data cards; this picture conceivably could be used in verifyin~s the accoun~ inforrnation provided in dle magnetic stripe of the data card. However, such an electronic 'Spicture" requires many digital si~snals to represent, resultin~s in 20 large memory storage requireme]nts and processing delays to handle the large amounts of data. In addition, it is a non-trivial problem to adapt a matrix sensor for making such an electronic picture of the embossed area of a card and accurately determining, with a computer or other eleetronics, what 2s characters are present in ~e embossing on dle card.
Accordingly, although attempts have been made to simplify the process of storing and retrieving data in connection wi~ retrieval requests and chargebacks, and in detecting the au~henticity of data cards, ~ere are still needs for substan~ial 30 improvement~ in facilitating data ca~ transac~ions. l~ere is still need for improved systems and me~ods dl?t simplify ~he storage, ~ansmission, and retrieval of transaction data associated wi~ data card transactions, including ~he signature, in a manner that automatically insures compliance wi~ dle operating procedures 3s promlllgated by the card issuing associations.

. :..... : :

~ addi~ion, there are needs for improved systems enabling provision of transaction chargeback protection in favor of merchants that assures the merchant that the operating procedures of card issuing associations have been complied with, s ~at all relevant data for receiving chargeback pro~ection for a given transaction has been properly obtained, stored, and ~ransmitted to a transaction processor, and that the risk of receiving a technical, authorization-related, or retrieval-related chargeback resulting from a given transac~ion has been 10 trans~erred to the transastion processor.

m~LL~l~e ~nvel-~lon Briefly described, ~e present inventions include an improved da~a card terminal wi~ an embossed character reader 15 and a signature capture printer, ~or facilitating the provisioll of chargeback protection and other features by a transactioll processor for the benefit of a mer(hant. l~e preferred terrninal includes means for detecting the physical presence of a data card at a data card te~ninal at which the transaction is r~corded and ~o for providing a card present flalg. The terminal is ~urther operative for obtaining transaction information corresponding to the particular transaction. The terminal filr~er includes means ~or electronically ob~aining card identifying information relating to dl data card ~rom an informa~ion c~ying medium associated 2s wi~ ~e data card A preferred system incorporating ~he terminal comprises a signature capturing printer. ~e pre~erred signature captllring printer includes means for receiving a sig~ature from a holder of dle da~a c~rd who is purportedly authonzed ~o conduct 30 a transactiorl wi~ the data card, and fcr providing signature signals corresponding to dle signature. ~e disclosed signature captllnng printer, while especially suitable for use in connection with methods and systems described herein, is also suitable for use as a stand-alone printer device, for use in eonnection with . ~
~ .,. ~ .

other types of data card terminals and other types of data processing apparatus.
I'he preferred terminal includes means responsive to the card present flag, the signature signals, and the card s identifying information ~rom the card identifying mformation obtaining means for providing a transaction protected flag associated with the transac~ion info~nation. Communication means associated with the terminal transmits the transaction information, including the signature signals and the transaction lo protected flag, to a transaction processor. Tra~saction processing means, associated with ~e transaction processor, is responsive to the transaction protected flag for processing the transaction represented by the transaction information in a manner sn ~at the merchant is not charged back for ~e transaction.
As is known, card identifying inforrnation in present day data cards is provided in a plurality of sources on the data card, for example, dle account number and other information is provided on a plurality of tracks on a magnetic stripe on the card, a~d the account number, cardholder name, and expiration date 20 are typicallly embossed on the card. According to another aspect of ~e invention, the card identifying information obtaining means comprises means for obtaining the card identifying information from a ~Irst source of the plurality of sources and from a second source of ~he plurality of sources. Means are provided for 2~ verifying dle accuracy of card identifying information obtained from dle ~lrst source. And, means are provided for restonng at least a portion of ~e card identifying infolmation obtained from dle first source wi~ information obtained from th~ second source in response to a determination by the verifying mearls that the 30 card identifying information obtained from the ~Irst source is not accurate or complete.
The first source of card identifying information may comprise a magnetic stripe reader, and the second source may comprise an embossed card rcader. Altematively, ~e ~ source 35 of card identifying information may comprise a first track of the magnetic stripe read by dle ma~netic stripe reader, and the second .~. .

~ , . . ~ .
...... ~ ,, . ,~ .
i source may comprise a second tracl~ of the magnetic stripe read by the magnetic stripe reader.
The preferred verifying means comprises means for computing ~he longitudinal redundancy check ~LRC) associated s with a track on the magnetic stripe, and tlhe restoring means is operative for restoring at least a portion of the accolmt number read from the magne~ic stripe reader with at least a portion of the account number read from the embossed card reader.
Alternatively, the veri~ying means may comprise means for 10 checking a checksum associated with the account n~nber.
According to ano~er aspect of the invention, the card present flag comprises info~nation indicative that the card identify~ng information obtaining means successfully obtained ~e card identifying inforrnation ele6tronically from ~e data card.
15 The magnetic stripe reader, operative for obtaining card identii~ying information from a first trac}c of the magnetic stripe and from a second traclc of ~e magnetic s~ipe, and the embossed card reader9 are preferred for electronically obtaining the card identifying information.
~0 According to another aspect of the invention, a remotely located authorization source, which may be associa~ed with a card issuing association, a card issuer, or the transaction processor, provid~s transaction authorization indicia. The terminal is operative for iniliating a communication session with 25 the authorization source via the transaction processor's host computer sy~tem and requesting authorization indicia. Lsl such an embodLment9 ~e ~ransaction protected flag mealls is responsive to the autlhoriza~ion indicia, ~he card present flag~ the signature signals, and dle card identifying infolmation for providing the 30 transac~ion protected flag.
According to another aspect of ~he inYention, the authorization mearls comprises a ~ransaction processor host computer system that is operative to communicate with a remotely located authorization source independent of the 35 transactiQn processor for seeking the authorization indicia, or is altematively opera~ive for providing the au~o{i~atiorl indicia in , ~:. .; ; ' .
, ~ ~
:

16 ~ ta,!~

the event that the host computer system is unable to comrnunicate with the authorization source. Typically9 the remotely located au~horization source comprises a computer system asso~iated with a card issuing association or a card issuer. In accordance with s this embodiment of the invention, the transaction processor host computer system operates as the authorization source and as the transaction processing means. The preferred data card terminal commllnicates with the transaction processor host computer system i~r requesting and obtaining dle authorization indicia, and 10 is operative ~or transmitting the signature signals, the transaction protected flag, and the transaction information to ~e transaction processor host computer system while the data card terminal is communicating with ~e host computer system for reques~ing ~he authorization indicia.
Preferred embodiments of the terminal include memory means for storing the signature signals, the transaction protected flag, and the transaction information as a transaction record ln a transaction batch. In such embodiments, the data card terminal is operative for transmitting the transaction batch to the 20 transaction processor host computer system during a communications session. Accordlingly, the the preferred data card terminal is operative for communicating a transaction record associated wi~h a transaction be~g conducted at the data card tcrminal du~g a~ authorization communications session when 2s ~e eerm~al communicates wi~ the transaction processor host computer system for obtaining ~e audlorization indicia, and is alternatively operative for transmittîng the transaction record to the transaction processor host computer system during a subsequent communications session in the event ~at ~e da~a card 30 terminal is unable to communicate wi~ dle transaction processor host computer system during an authorization cor~nunications s~ssio~.
Yet ano~er aspect of the inventions relates to methods of operation of a transaction processor tha~ receives 3s transaction information ~rom a merchan~ utilizing a terminal constructed in accordance with the present invention. The : ' !.:: ., `

~'' '` ` ' ' : ' .

method relates to guaranteeing a ~inancial transaction conducted by a cardholder utilizing a data card against chargebacks of the transac~ion to a merchant participating in the transaction. The disclosed me~od includes ~e step of providing to the merchant a data card transaction terrninal. At ~e termirlal, and in response to the presentation of a data card by a cardholder in connection wi~h a proposed transaction, the method comprises au~omatically detecting the physical presence of the da~a card at the terminal, alltomatically detecting an account number associated with the data card, and capturing a signatllre oiF the cardholder in comlection with the ~ransaction.
In further response to the proposed transaction, the termixlal requests authorization indicia from an authorization source. In fur~er response to the presentation of the data card, S the method comprises obtaining and storing in the terminal financial information corresponding to the transaction, the au~orization indicia, and the cardholder signature.
In response to the storing of the infolmation in ~he preceding step, ~e method cornprises storing a transaction protected flag in the temlinal indicative dlat the transaction is chargeback protected, and communicatirlg the financial info~nation corresponding to the transaction, the authorization indicia, the car&older signature, and the transaction protected fla~ to a transaction processing host computer system.
23 Finally, ~e method comprises the step of processing the transaction so ~at the merchM~ is not charged back for ~e ~ran3actioD.
According to another aspect Qf the inventions, the me~od comprises providirlg a chargeback protection flag from a remote location to the p~eferred terminal during a configuration download session, to selected merchant3 who have arranged with the tr~saction processor for chargeback protection services. In such an embodiment, ~e terminal i5 resporlsive to the state of the chargeback protection flag, as well as to the presence of the card, 3s the au~horization indicia, the signature, and the transaction information for providing the transac~ion protected flag.

. . . .
....
: , ~

According to yet another aspect of ~he invention, there is disclosed a method of obtaining authorization indicia from an authorization source, preferably carried out by a data card terminal. The method comprises establishing a s commlmication link with a transaction processing host computer system. Once ~e coIT~nunication lin3c is established, the te~minal provides the detected account number associated with ~he data card to the transaction processing hos~ computer system, and provides a proposed transaction amount to the tr~nsaction processing host computer system~
The me~od further comprises, at the transaction processing host computer system, attemptillg to establish a communication link to an au~orization source co:mputer system corresponding to the card presented~ The transaction proeessing host computer system, in response to establishment of the communication link with the authori~ation source computer system, provides the detected account number associated with the data card and the proposed l:ransaction amount to the authorization source computer system.
The transaction processing host computer system then receives authorization indicia from the au~orization source computer system as remotely obtai~ed authorization indicia~
~ response to failure of establishment of the eommunication link with the authorization source computer 2s system, t~ transaction processing host computer system detennines whether to authorize the ~ransaction, and if so, provides transac~ion processor authorization indicia~ The au~ori2ation indicia, whe~er the remo~ely obtained au~orization indicia from the authorization source computer system or the transaction processor authoriza~ion indicia, are then provided to the terminaL
In response to a failure to obtain the remotely obtained au~orization indicia or a dete~mination not to authorize the transaction by the transaction processing host computer 3s system~ method comprises providing a "call me" indicia to the terminal, and terminating the communicatioll between the . : ~

te~ninal and the transaction processing host compu~er system. In response to being provided the call me indicia, the preferred terminal automa~ically seeks authorization from an audio response unit (ARU).
s 'rhe step of automatically seeking authori~ation from an ARU comprises automatically dialing an ARU authorization telephone number associated with a voice grade telephone line, switching the telephone line to an audio means associated wi~ ~e tersninal to ~e communication lirlk. The merchant may also be lo signalled to pick up a telephone handset and communicate verbally with an entity associated wi~ the ARU.
According to yet ano~er aspect of the invention, there is disclosed a me~od, particularly suitable for use wi~ ~he disclosed terminal, for providing electronic au~orizations to a 1~ merchant in connection with a proposed transaction associated with a data card presented by a cardholder. Bliefly described, the method comprises ~e steps of: j.
(1) automatically attempting to connect the terrninal for co~nunications via a telecommunications link to an authori~ation computer system;
(2) in response to ~failure to connect the terminal to the authorization computer system or receip~ of a call me signal from ~e au~orization computer system, automatically attempting to comlect the tem~inal wi~ an audio response unit 2S (ARU~ via a second telecommunications link;

(3) in response to con~ ction of ~e terminal to ~he ~U, providing info~nation associated with the data card and wi~ ~e proposed transac~ion ~ the ~orm of data signals to the ARU; and (43 provid~g an audible authorization approval code received from the ARU to the merchant.
Preferably, the me~od is carried Ollt by a data card terminal including audio means, and the step of at~empting to connect ~e terminal with an audio response unit ~ARIJ3 via a 3s second telecommurlica~ions link comprises automatically dialing a telephon~ number associated with the ARU, and connecting ~ ~ ~ $ ~J ~ 2 audible authorization indicia from the ARIJ to the audio means, such as a speaker.
The tenninal operator is then pre~erably prompted to en~er the audible authorization sode into a keyboa~ associated S with the terminal. In response to entry of the authorization code at the terminal, the telminal validates a checlc digit associated widl the ~ransaction data to detect keying errors or fictitious codes. In response to detection ~at an incorrec~ code has been entered9 ~he te.~ninal prompts the operator to re-enter the code. In the event 10 ~at a valid check digit is not entered after a predetermined mlmber of at~empts by the terminal operator, the transaction is voided.
The method preferably ~urther comprises the steps of, a:fter prompting the merchant to e~ter the audible autholization code into a keyboard associated wi~ the ~erminal, identi~ying the transaction as containing an ';off line"
authorization code in ~e te~ninal. The terminal then stores transaction data associated with transactions indicated as "off line"
in a memory associated with the terminal. Subsequently, 20 transaction data ;dentified as containing an "off line"
au~horization codes are transmitted to a transaction processing computer system via a telecommunications link.
More particularly described, a preferred system for providing authorizations in connectioIl wi~ data card transactions 2s includes a data card te~ninal comprising means for detecting an ac~ount number associated with a data card presented by the cardholder in eonnection with a proposed transaction, a first communication means ~or connectillg the terminal for data communications via a first ~eleco,~nuIIications link, a second 30 communications means for connecting ~he terminal for data communica~ions via a separate second telecommur~icat;ons link in the event of failure to establish commuIlications via the first telecommlmications link, and a ~ird communications me~s for connecting ~e terminal ~or communications via a separate voice 3s grade third telecornmunications link in the event of failure to ~5`~`..P~`~ 7~

establish communications via the first telecommunications link or ~e second telecommlanications link.
The system further comprises a communications processor associated wi~h a transaction processor, including s me~ns for communicating widl data card te~ninals via the first telecommunications liDk or alte~natively via the second telecommunications link, means for communicatin$ with an ~uthorization source computer system associated with an authorizatioll source via a host/authorization source telecommlmications link. The commlmications processor is operative ~r connecting the data card te~ninal to the authorization source computer system via the first telecomrnunications link or the second telecommunications link, whichever is established, and the host/authorization source telecomnnunications link. The authorization source computer system is operative for providing authorization indicia to the terminal via the established comnnunication iinks.
The third telecomnnunications link is operative for connecting the terminal to an audio response means associated with an audio response unit (.A~RU). 'rhe ARU provides authorization indicia to the terminal via the third telecommwnications link, in the event of failure to communicate with ~e authorizatioIl source computer system or the transaction processor host computer sys~m.
2s According to yet another aspect of the invention, ~ere is disclosed a data card te~ninal operative for receiving electronic authorization3 in cormection with a proposed t~nsaction associated with a data card presented by a car&older ~o a merchant. The preferred ~elminal comprises first communication means ~or automatically connec~ing dle ~erminal for da~ communications wi~ a transaction processing host compu~er system via a first telecommunications link. A second communications means is provided ~or automatically connecting the te~ninal for data communications with the transaction 3s processing host cornputer sys~em via a separate second t~lecommunica~ions link. A third communications means is ~ps;~ f ~ r ~
~ r _~ ~ P~

provided for automatically connecting the terITlinal for co~nunications with an audio respons uni~ (AR13) via a separate third telecommunications link in response to failure to establish the first telecommunications link or the second telecommunications link.
The terminal further includes means for reques~ing authorization indicia from the transaction processing host computer system via the ~lrst telecommunications link or the second ~eles~ommunications link in connection with a proposed lo transaction. Authorization indicia received from via the first telecommunications link or the second telecommunications link are considered electronically receiYed authorizations, and are automatically associated with o~er transaction infolmation and stored in the terminal for subsequent communications to the transaction processor.
In the even~ that communications cannot be established for electronically receiving ~e authori~ation indicia from an authorization source via ~he first telecommunica~ion link or the second telecomrnunication link, there is provided audio means fo~r providing an audible authori~ation indicia fro-n the audio response unit (ARU) to the merchant. Means are provided ~r receiving the manual entry of the audible aut~orization indicia from ~e merchant as manually entered authorization indicia.
Means for verifying ~he manually entered authorization indicia determil~e whe~her the au~horiza$ion iIldic;a entered by the merchaIlt a~e valid (to reduce mistakes and fraud~. Finally, there is pr~vided means for storing authorization indicia received from th~ transaction processing host computer system or ~e manually entered au~ori~ation indicia.
The prefened terminal filrther comprises means for detec~ing an account number associated with the data card presented by the cardholder in connection wi~ the proposed transaction, and mearls for automatically providing ~e detected account number to said tra~saction processing host computer system or said ARU, in ~he maa~ner descril~ed in cormection with other prefelTed embodiments. The preferred account number providing means comprises signal means for providing the detected account number ~o the transaction processing host computer system, and DTMF means for providing the detected account number to said ARU.
s If the ~ransaction processing host computer system or an authorization source connected to the transaction processing host compu~er system provides a "call me" signal, or in response to failure to establish communications with the transaction processing host computer system, the third communication means is automatically operative for dialing a telephone number associated with the audio response unit (ARU), providing information associated with the data card and widh ~e proposed transaction in the form of DTMF signals via the ~hird telecommunications link, connecting the audible authorization irldicia ~rom the ARU to the audio means. The merchant is then prompted to enter the audible authorizaeion indicia into the terminal, where it is verified for errors or ~raud.
Accordingly, it is an objec~ of the present invention to provide an improved data card transaction telminal.
~0 It is another object of the present invention to provide a signature capturing and embossed card reading capability in a data card transaction terminal.
It is a furdler object of the p~esent invention to provide improved systems, methods and apparatus by which a 2s merchant may be ~uaranteed against chargebacks for the bene~lt of merchants.
It is another object of the present invention to provide an improved data card transaction terminal dlat detects the physical presence of a da~a card in connection with a transaction, thereby providing a greater degree of assurance of dle validity of the transaction to a transaction processor and the ability to treat a transaction as chargeback-protected to a merchant.
I~ is another object of the present invention to 3s provide an improved data card transaction terminal that detects . . , , ~ ~
.; . . .
,,.. ~ . ..
.
.
, . . . ~ ,~

24 i~ ~ ~3 r ~

~he physical presence of a da~a card and provides a signal indîcative of the s~ne.
It is a further object of the preserlt invention to provide an improved apparatus and method by which a credit card ~ransaction terminal will ensure ~at all da~a related to a transaction is collec~ed be~ore the transaction is completed.
I~ is a filr~er object of the present invention to provide an improved apparatus and medlod by which an off-line approval code may be requested in the event the terminal is 1~ unable to ccmmunicate with a host compu~er.
It is a fur~er object of the presen~ inventions to provide a me~od by which an off-line authorization code may be valida~ed for authenticity.
It is a fu~er object of the present invention to 15 provide an improved data card transaction telminal and method ~or operation of sarne by which a car&older's signature will be captured and stored electronically along with o~er data related to a transaction.
It is a further object of the present invention to 20 provide an improved data card transaction terminal that will control the transmission of a digitized signature from the terminal to a data card transaction host or store data associated with ~e transaction at ~e terminal, depending on whether d~e terrninal is able to communica~e with ~e host eompllter.
2~ It is a fur~er object of the present invention to provide improved systems for use in handling da~a card transactions ~at will allow a credit card transaction processor to respond to retrieval reques~s without the involvement of the merchant.
It is a further object of ~he present invention to pro~ide improved systems for use in handling data card transac~ions ~hat allow reduc~ion or elimination of paper transaction reeeipts stored by merchan~s.
It is a further object of the present invention to provide an improved apparatus and method that allows a transaction processor to respond to chargebacks without the involYemen~ of the merchant.
It is a fu~er object of the present invention to provide an improved da~a card transaction terminal that will s au~oma~ically read ~he data that is embossed on ~he face of a paymen~ card.
It is a fur~er objec~ of the presen~ invention to provide an improved apparatus and method that will automa~ically read data from multiple sources on a data card and restore data detected as being erroneous, and verify ~e data 50 read i~L order to ensure that the restored data are accllra~e.
- It is another object of the presen~ invention to provide irnproved methods and apparatus for facilitating the provision of chargeback protected data card tra~nsaction services, from a transaction processor to a merchan~, facilitated by detecting predetermined characteristics of a given data card transaction indicative of the validity of the transaction, in particular, detection of the physic,al presence of a data card in connection with the given transaction.
It is another object of the present invention to provide a data caLrd transaction processor with a greater degree of confidence that a given data card tralnsaction is a valid one, so that the transaction processor may elec~ to assume the risk of the particular transaction on behalf of a merchant, by capturing 2s additional information associated wi~ dle transaction, namely, information from both ~acks of ~e data card, info~nation from the embossing on the card, and digitized information corresponding to the signat~re of the cardholder in conrlection wi~ a transaction.
These and other objec~s, features, and adYantages of the present invention may be more clearly unde~stood and appreciated ~rom a review of the following detailed descrip~ion of - the disclosed embodiments arld by re~erence ~o the appended drawings and claDm~.
3~

.. .... . . . .
. ., . . i, ~ , ~ . , 2b ~.~3_ FIG. 1 provides an overview of a prior art credit card transaction processing system.
FIG. 2 illustra~es a c~edit card ~ransaction processing s system ~at employs a data card transaction te~ninal constructed in accordance wi~h the preferred embodiment of the present invention.
FIG. 3 is a perspective view of an improved data card termiIIal/prints~r constructed in accordance with the preferred embodiment of the present invention, comprising a transaceion terminal and a signature cap~nure p~ter.
FIG. 4 is a top plan view of the prefelTed t~saction terminal illustrated in FIG. 3.
FIG. S is a rear elevation view showing the connec~ors provided in the pre~erred transaction terminal of FIG.
3.
FIG. 6 is a block diagram illustrating the primary components of the preferred data card transaction terminal/printer of l~IG. 3.
FIG. 7 is a schematic diagram of the circuitry employed in the preferred tr~nsaction termirlal fonning a par~ of the te~ninaVprLnter of FIG. 6.
FIG. 8 is a schema~is~ diagram of ~he card swipe inter~ace circuitry employed in the preferred transaction terminal 2S of FIG. 6.
FIG. 9, consisting of FIGS. 9A--9E, are partial diagrammatic end views of an embossed card reader employed in ~e prefe~ed transaction term~al of FIC3. 6, showing the method of operation.
FIG. 10 is a block schematic diagram of the embossed card reader circuitry employed hl the preferred transaction terminal of FIC}. 6.
FIG. 11 is an e~ploded view of the embossed card reader.
FIG. 12 iS a bottom plan YieW of ~e embossed card reader, showing the loca~ion of ~e switches.

.
.: . . .: , .. .. . ..

FIG. 13 is a partial fron~ elevation of the embQssed card reader.
FIG. 14 illustra~es ~e imaging array of the embossed eard reader and the division OI the array into character cells for S the pre~erred me~hod of recognizing the embossed characters.
FIG. lS. is a flow char~ illustrating the me~hod employed in ~e preferred embodLment ~or recognizing embossed charac~ers on a data card, carried QUt iIl the preferred embossed card reader.
FIG. 16 is a top plan view of the prefe~ed signat capture pnnter illustrated in FIG. 3.
FIG. 17 is a side cut-away view of the pre~erred signature cap~re printer of FIG. 3.
FIG. 18 is a block schematic diagram of dle signature capture circuitry of the preferred signature capture printer of FIG. 3.
FXG. l9 is a partial exploded view of the signature capture printer of FIG. 3~ showing the relationship between the paper, top cover, and digiti~.er printer circuit board.
FIG. 20 illustrates t'he X-Y coordinates of the signature capturing window provi.ded on a signature capture printer constructed in accordance ~ith the preferred embodiment illustra~ed in FIG. 16.
FIG. 21. illustrates ~e data fo~at of ~e digital 2s signature signals generated in connection wîda a signa~ure capture by a signatllre capture printer constlucted in accordance wi~ the p~eferred embodiment illustra~ed in FIG. 16.
FIG. 22, consisting of FIGS 22A--22BI is a flow diagram of a signature capturing and signature signal 3û comp~ession me~hod formirlg a part of the transaction ~emlinaUprinter software.
FIG. 23 illustrates e~emplary strokes of a partial exemplary sig~Aature en~ered in the signature capturing window, which is coded into compressed signàture signals according to the 3~ method of FIG. 22.

.. . . ~ , FIG. 24 is a flow diagram illustrating the method by whish compressed signature signals are decompressed in order to reproduce a stored signature.
FIG. 25 is a flLow diagram illustratin~ the main s program loop of the operation of a te~ninal constructed in accordaIIce wi~ ~e present invention, implemented as computer software.
FIG. 26 is a iFlow diagram illustrating a preiFerred subroutine for conducting a credit card transaction with card 10 detection, ~ransaction authorization, and signature capture fomling a par~ of the transaction teml;nal/printer software rne~od of FIG. 25.
FIG. 27 is a diagram illustrating the data encoded on track 1 and track 2 of a ma~snetic stripe of a typical data card.
FIG. 28 is a iElow diagram illustrating dle preferred read eard da~a subroutine iFormhlg a part of the transaction terminal/pnnter soiFtware me~od oiF FIG. 2S.
FIG. 29 is a flow dia~sram illustrating the preferred capture signature subroutine forming a part of the transaction terminal/printer so~ware method o~F ~:IG. 25.
FIG. 30 is a flow diagram illustrating the preferred request au~orization subroutine forming a part of dle ~r~saction termiIlaVprinter software method oiF FIG. 25.
FIG. 31 is a flow diagram illustrating the preferred store data subrou~ine tForming a part of the Iransac~ion terminaUprinter software method of FIG. 25c FIG. 32 is a flow diagram illustra~ing the close tenninal subrou~ine forming a part of the transaction terminalfpnnter software me~hod of FIG. 25.
FIG. 33 is a flow diagram illustrating the re~rieval request proeessing method employed in a t~ansaction processing host computer system constmcted in aecordance widl ~e present invention.
FIG. 34 is a flow diagram illus~ating ~e chargeback 3s processing me~hod employed in a transac~ion processing host computer system construc~ed in accordance with the presene invention.
~ ;. 3~, consisting of ~IGS. 35A--35C, is a flow diagram illus~ating a medlad ~or provid1ng off-line au~orization s for transactions in accordance with the present invention, carried ~ut by a host system.

Referrin~ now ~o the drawings, in which like numerals indicate lil~e elemen~ throughout ~e several YieWS and drawing figures, it may be helpfulL ~o r~view ~e operation of a data card transaction processing sys~em before turning to a description of the preferred embodiments of a data card transaction terminaVprinter, and associated systems constructed in accordance witll the present invention for providing chargeback protection and the like.

Definition~
Before ~urning to an explanation of the disclosed embodiments, some de~lnitions are in order:
A "data card" can mean a debit card, a credit card, or o~er ~mancial accolmt card. Such d~ta cards typically have a magnetic s~ripe associated with ~he card, carryirlg an account number assocîated with the card, e~piration date, issuing ~titution, and o~er in~o~naeion, as well as a visible indication of an account number and other info~nation in an area of embossed characte~s. The e~rms "data card'~, "credit card", etc.
a~e used interchangeably herein.
A "merchant" is an insltitutioIl ~at renders goods or services in e~change ~r payment, bu~ also can include o~r types of institu~ions ~at rely upon information provided to ~em by way of data cards, for e~ample~ health service providing institutions.

.. ..
.,, ~, :
~,, . ; ,.

A data sard "transaction" is a transaction typlcally involving the exchange of information and/or goods and/or services and/or money between a eard-holding consumsr and a goods or service provider such as a merchant. However, the te~n s "transaction" is generally meant in ~e broadest sense to include other types of informaeion e~changes between institultions ~volving a data card, for e:~ample, ~e exchange of in~onnation pertaining to health insurance benefi~ cards and health providers would be considered a "transaction".
A "transaction processor" is an i:nstitution that processes data card transactions, for example a credit card transaction processing company. Transaction processors are sometimes independellt third party institutions that are no~ related to any par~icular credit card issuer. However, since many c~rd issuing associations and card issuers also process transactions, card issuing associations and card issuers are generally included within the term "transactioll proccssor", e~ccept where a distinc~ion between the institutions is required.
A "card issuing association" or enti~", as used hereirl, is an institution or other entity ~at issues regulations governing a particular brand of da~a card, for e~ample VISA(~, MasterCard~, AMERICAN EXPRESS(~9, DISCOVER~), and the like. Some associations called "bankcard associations" t~ically comprise "member banks" ~hat actually issue the credit cards, for e~ample 2s VISAd~' and MasterCard~' banl~card associations. O~er non-bank endtics such as AMERICAN EXPRESS~9 are inell~ded wi~in the term for puIposes of ~is invention. Card issuing associations typically accumulate ~ransaction data ~rom trans~ctiorl processors and send it to ~e individual cardholder's bank.
A "card issuer", as used herein, is an insti~u~ion or organization, o~en a banlc, dlat ;ssues a data card such as a debi~
or credit card. Card issuers are generally members of a card issuLng association. However, ~e terms '~card issuer" and 'Scard issuing association" are sometimcs used synonymously when the 3s conte~t suggests an elltity that is responsible ~or issuance and/or regulation of tr~nsactions involving cer~ain data cards.

, ~,. . :
. ~,. ~.: .. ..

.

0~ f 2 "Settlement" refers to dle proeess by which fimds are ~ransferred from a card issuer to a merchant.
"Clearing" a transaction refers to the process by which da~a pertaining to a merchant's credit card transactions is 5 trans~erred ~o a card issuer. Transaction clearance is ofteIl provided nowadays by transaction processors that are independent of credit card issuers. However, sinee card issuers also clear transactions themselves, they are o~ten ~ansaction processors as well.
'~Authorization indicia", also referred to as "authorization codes", 'Sauthorization approval", or "approval code", re~ers to predetermiIled signals or codes r~ceived from a card ;ssuing association or other authorization source, indicative that a pa~icular transaction has be,en authorized. These indicia 15 may be electronlc or may be aud;ble. The authorization indicia or codes are generally associated with other transaction data, ~o flag the transaction as having been pre-approved.
"Re~erral" means a signal or predetermined indicia received by a merchant from an authorizat;on source indicative 20 that ~ merchant should contact the authorization source, or a card issuer, in connection with a particular transaction. A
referral is often generated in response to a determination that a transaction should not be corllpleeed because the account associated wi~ a presented card is over its credit limi~, may have 25 been stolell, or for some o~er ~ason.
A "call me" signal is ~e same as a referral.
An "audio nesponse unit" or "ARU" is a synthesized voice ge~erating apparatus ~at responds to dual tone multiple ~requency (DTMF~I signals provided by s~andard TOUCH-30 TONE~9 tel~phones to enter ~e accoun~ number, e~cpiration dateand purchase amount. ~ addition, the ARIJ ¢ontains circuitry that is capable of recogr~iz~g certain spoken words and numbers.
If a transaction is approved, ~e ARU's voiee syn~esizer provides an approval number and is opera~ive for generating an audible 35 but synthes~ed voieg message corresponding to a predetermirled message. For e~ample, an ARU may be programmed to provide - ... . ~ , . ' ~ : i . ~

messages such as, "Transaction authorized, approval code is 1234~", or 'iTransaction declined, call me." Such messages are generated and delivered ~o merchants automatically and telephonically, wi~out human intervention or participatio~
s A "retrieval reguest" is a reguest or inguiry made of a merchant or merchan~'s transaction processor, ~ypically ~rom a cardholder or card issuer, for a hard copy of documen~ation associated widl a given traIlsaction. Typically, a transaction may be charged back to dle transaction processor or merchant if ~e requested documentation is not provided wi~Ln a time limit set under card issuirlg association regulations.

General Descriptiolll of Credit Card 1[ ransact;o Processing System~
FIG. 1 illustrates generally a ~pical pr;or art system 8 used to process and settle data card tr~sactions. The system 8 is known in the art, and is subject to many of the dif~lculties to which the present inventions are addressed. The system 8 contemplates that a transactlon processor 12 (which could be a ~o card issuer or an independent transaction processor) is employed for transaceion clearing and settlement. A merchant 13 may transer transaction data to the transaction processor 12 elec~ronically or in dle ~orm of paper sales dra~ts. Ihe data is typlcally trans~erred from the transaction proeessor to the credit card issuer el~c~onically. Once dle car~ issuer receives the data, ~e transactions are posted to the appropriate cardholder's account or stored for subsequent posting to ~he ~ppropnate cardholder's account. Settlemerlt occurs as ~unds are transferred from the issuing instinltion to dle merchant.
In a typical transaction, a cardholder proposes to purchase goods or services and p~sents a credit card, such as one of the types 15a~d9 to ~e merchan~ 13 as dle me~od of payment.
In some cases9 ~e merchant commumcates wi~h ~e transaction processor 12 as an authorizatiorl source in order to have the 3s proposed transac~ion authorized prlor to completing the transaction. In od~er cases, ~e me~chant communicates with a ~2~

separate authorization source 17 for requesting ~ransaction au~orization. Either authorization source may communicate with a card issuing association lB or a card issuer 19 ~or authorization.
s If ~e transaction is approved9 the merchan~ receives an authorization number or code ~'~authorization indicia") from the au~orization source, which is recorded along with the other transaction data. In response ~o ~e authonzation reques~, the merchant may also receive a "decline", in which case the transaction is terminated, or a "referral", in ~e event the issuer or au~honzation source desires to spea~ wi~ ~e merchant before au~orizing ~e transaction.
The merchant 13 in ~e system 8 uses an electrol~ic terminal 16 or ma~lual imprinter to record the data pertaining to the l:ransaction. The recorded data includes the account number and expiration date shown on the card, the amount smd date of the purchase, the authorization number (if the proposed transaction is approved~, and ~e rardholder's signature.
Periodically (e.g., daily), the merchamt trans~ers ~e data from all of the credit card lransactions to the transaction processor 12 so that the transalctions may be processed or "cleared". Some ~ra~saction processors handle transactions for different types of credit cards, thereby obv;ating the merchant's need to communica~e separately wi~ different card issuers. In such cases, dhe transaction processor 12 separates that merchant's transactions aecording to the type of card used. The transaction processor ~en combines ~e ~ransactions for each type of card wi~ those received from o~er merchan~s and iForwards ~e data to the r~spec~ive credit card issuing associa~ion l~a-d.
~ ~e case oiF VISA;~9 and MasterCard@~ card issuing associations, ~ entities that ~eceive ~le da~a ~rom ~e transaction processor 12 comprise associations 18a-b ~at are formed by "m mber banks9' 19a-b ~hat actually issue ~e c~edit cards. These associations 18a-b accumulate dle da~a and send it to the 3S individual cardholder's bank. ~ the ease of other credit card issuing as30cia~ions, e.g., DISCOYER~ 18c and AMERICAN

.

::: : : : ~ : : :

EXPRESS~ 18d, the transaction processor 12 transmits data directly to the credit card issu~ng association. In either case, once the entity $hat issued ~e credit card to the cardholder receives the da~a9 each transaction is posted to ~e apprupriate account and a s statement or bill 21a-d is subsequently sent to the car&older.
Al~ough ~e known transaction processing sys~em 8 provides for autholization of transactions and has served the ~siness community ~well, ~e system does not allQW for provision of chargeback protection on behalf of merchants to t~e extent ~at 10 is desir~d by merchants, nor does the system allow for adequate handling of $ransactions in ~e event ~at the telmLnais 16 are una~le to communicate wi~ ~e host computers of the transaction processor, nor does the system allow for handling retrieval requests regarding particular transactions without involvement of 15 ~he merchant.

Pre~erred Credit Card Transaction Processing System Employing Present In~entioll FIG. 2 illustrates a preferred data card transaction 20 processing systcm 25, implemented as a credit card transaction processing system, that incorporates the present inventions, including a da~a card terminal/prinl~er 30 constructed as described herein. In the preferred system 25, the cardholder purchases goods or services and presents a credit card l~a, for e~ample a 2s VISA c~d, to ~e merchant as the form OI payment, as in the system 8.
At that point, the merchant uses the preferred data ca~ ~ransaction temlinaVprinter 30, which includes a transaction terminal 3 and a signature capture printer 3~, to record the 3a transaction data. More particularly, the tenninal 3S reads ~he aeeount number and expiration date directly from the card by means of a card swipe inter~ace, and may also obtain information from an embossed card reader. The transaction terminal 3~
thereby detec~s the physical presence of the data card at ~e 35 terminal, and provides a "card present" signal. The ~rminal then prompts the merchant to enter the purchase amoun~ via the keyboard. Once the purchase amount is entered, the printer 38 prints a portion of a paper receipt and the transaction terminal 3S
prompts the merchan~ to have the car&older sign the receipt.
The signature capture printer 38 digitizes the signature and transmits the digitized value to the terminal 35, where data signals representative of the signature are processed and stored along with other data pertaining to the transaction. This process is described in more detail below.
Once ~he terminal 35 has acquired transaction in~ormation and signature signals, irl the preferred embodiment the terminal is operativ for communicating the data to a transaction processor 12 in one or more communications sessions, ~or requesting an authorization and/or for transmitting transaction information for settlement. Communications from the terminal 35 are effected over a telephone line 48, which is connected to telecommunications netwodc S5.
Ln preferred methods, the terminal 35 initiates an au~orization communications sess]îon with a host computer 40 operated by the transaction processor 12 that serves as an authorization source (or as a communications facility to an authorization source), and transmits an authorization request to the authorization source. The host computer 40 preferably includes sof~ware 42 for signature decompression, when necessary in connection with a retrieval, in the manner to be 2S descri~ed ~elow.
It should be understood at this juncture that authorization sources, for providing authorization indicia in connection with proposed transactions in response to an aud~or~zation reguest9 include card issuers as well as transaction processors. In ~e sys~em 25 illustrated in FI~:;. 2, ~e hos~
computer 40 operated by ~he transaction processor 1~ transmits ~e authorization request to a card issuing institution 18a or a card issuer 19a (bank~, or may provide the authoriza~ion indicia under certain circumstances.
CommunicatioIIs sessions wi~ ~e host computer 40 are effected via telecommlLnication ne~works 55. ~ a preferred -:

, . ~
, ; . , . .

36 ;~ 5~

embodiment, the terminal 35 is opera~ive for automatically attempting to establish a communications link vvith the host computer 40 via a ~Irst telecommunicat;ons link 58a by dialing into a packet communications network provided by a major s telecommlmications provider such as AT&T, MCI, SPRINT, or the like. ~ e event ~at the terminal 35 is unable to establish ~e first telecommunication link 58~, ~e terminal is automa~ically oper~tive for atternpting to establish a communications link with the host computer 40 via a second telecommunications link 58b lo by dialing into arl independent, separate packet communications network provided by a major telecommunications provider such as AT&T, MM9 SPRINT, or the like.
If the firs~ telecommunica~ions lin~ ~ga or the second telecommunications link 58b are established, the terminal 15 communicates wid~ dle host 40 by transmitting and receiving signals via an internal modem (not shown), using a coIlventional but high speed data sommunications protocol.
If the terminal is unal~l[e to establish either the first telecommunications link or the second telecommunications link, 20 the te~minal 35 is automatically operative for dialing over the line out 48 via a voice grade telephone line 52 to an ARU 70 operated by the transactiQn process,or 12.
S~ill referring to FIG. 2, the terminal 35 may be connected to other like termillals (not shown in FIG. 2~ via a local 2s area network (LAN) 51. ~ particular, the $erminal 35 may be connected to a separate "back of~lce" computer system 57 that performs accounting functions for ~e merchant andlor terminal configuratioIl software.
If the telecommunication link wi~ ~e authori~ation 30 source (via host computer 403 is successIul, ~e terminal 35 transmits certain predetermined transaction data to the host computer 40. The host computer 40 dlen relays dle ~ransaction ~ata to a credit card issuing institution 18a, ~r e~ample a VISA~
card association, in order to receive authorization. If the 3s transaction is au~orized, an au~orization code or indicia 60 is relayed from the credit card issuing institution 18a (or other .' . ` ~

allthorization source) to the host computer 40, and from the host computer to the transaction teIminal 35. The host computer 40 stores the transaction data and signature in a data storage facility 64. The telminal 35 also stores all of the transaction data (except 5 the signature in the preferred embodiment, which is not retained in the terminal since the signature is transmitted to the host during the authorization communica~ions session.
As in the general credit card transaction processing system 8 described in conjunction with FIG. 1, the transaction 10 processor 12 separates the transaction data according to ~he type of cardl used and periodically transfers dle data to the credit card issuing institution 18a, which in blrn relays it to ~e card issuing bank :19a. At that point, each transaction is posted to the appropriate individual cardholder's account.
The preferred system 25 also provides an alternative me~od for providing "off-line" authorization if t:he terminal 35 is unable to communicate with the host 40, or if the host 40 responds to ~e terminal's au~orization request with a "referral".
Off-line authorization is effected automatically under 20 predetermined conditions, namely, if a primary telecommunications network is una.ble to connect the te~ninal 3~
to the host terminal 40, if a secondary telecommunications netwo~k is unable to connect the terminal 35 to the host terminal 40, or if a call me signal is generated a~ the host. In the 2s preferred embodiment of the terminal 3 5, an off-line autlhorization is sought automatically under the indicated conditions.
lhis off-line au~orization method comprises use of an audio response unit ("ARU") 70, and a voice services 30 depar~nerlt 72. The audio respol~se uI~it 70 ~sponds to dual tone multiple ~requency (DTMF) signals provided by a merchant's standard TOUCH-TONE(~) telephone correspond~g to ~e account nunnl~r, e~piration date and purchase amount for the proposed transaction. If ~ae transaction is approved, ~e ARU's voice 35 synthesizer provides an approval number as the authorization indicia, which ~e merchant manually enters into the te~ninal 35 !
,, '~ '~
~, ' .

via i~s keypad. In the preferred embodiment, the manually entered approval n~ber is verified by logic in the terminal 35, to reduce mistakes and fraud.
Since the transaetion terminal 35 was unable to s obtain an authorization indieia directly (i.e., an electronic author;zation) from the host computer 40 if the ARU 70 is reached, ~e transaction data, including ~e si~nature, is stored in the terminal 35 until subsequen~ communica~ion wi~h the host computer 40 is established.
The voice services department 72 provides conventional "live operator" voice communications on behalf of the transac~ion processor 12, in ~e usual manner, in the event that communications were not es~ablished with the hos~ and for sorne reason dle ARU 70 was not operative, or a call me referral lS was received.
Af~er discussion of the features of the preferred terminaUprinter 30, those skilled in ~e art will understand how the present inventions facilitate provision of transaction processing services by a transaction processor 12, including ~e 20 provision of improved chargeback protection ser~ices and off-line au~orization services on behaliF of merchan~s.

Preferr@d Embodiment of Termi~al/Printer FI(}. 3 illustrates the preferred embodiment of a data 2S card transaction processing terminal/printer system 3 0 constmcted in accordance wi~h the present invention. The te~al/printer system 30 comprises a transaction teIminal 35, and a signa~re cap~ure printer 38. The te~ninal 35 includes an injec~on molded plasltic hous.ing or case 101. A card swipe slot 30 103 is fonned in the top por~ion of ~e case 101. When a card 15, such as a credit card, having a magnetic data stripe 110 is passed d~ough ~e card swipe slot llD3, ~e te~al 35 reads and decodes the dat~ ~at is encoded in the card's magnetic stripe.
~e preferred transaction terminal 35 also comprises 3s an embossed card reader 112, comprising a ~ctile imager. When f .2 a card 15 having embossed characters 115 is inserted into the embossed card reader 112, the te~ninal 35 reads and decodes the account number embossed on the card. ~e embossed card reader 112 is located interiorly of a slot 113 in the housing 101, s preferably opening toward the front of ~he terminal 35 for ease of access by a user.
According to a preferred aspect of the invention, the card is placed in the embossed c~rd reader 112 only if the magnetic stripe is damaged or provides elToneous data, as 10 detected by the terminal software. According to o~er aspects of dle invention, the card may ~ placed in ~e embossed card reader 112 as a matter of course immediately after a swipe of the card to read ~e magnetic stripe.
A card swipe reader in the card swipe slot 103 and 15 the embossed card reader 112, in combinaeion and separately, comprise means for detecting the physical presence of the card during the transac~ion. When used together, such means provide an even greater confi~mation that ~e card was actually presen~.
According to the preferred embodiment of the 20 invention, in the event the magnetic stripe 110 is damaged and unable to be read, the c~rd will be placed in the embossed c~rd reader 112 to detect the account ~umber from the embossed area of ~e card.
Aceording ~o o~er aspects of ~e inven~ion, in the 2s event the magnetic stApe 110 is clamaged and unable to be read, ~e embossed card reader 112 may be used to detect the account number and~ under certaiIl circumstances, to restore ~e account nwnber by utilizing a~ least a par~ of the account number read from ~e embossed area on th~ card, ~or dle missing or defective 30 account num~r, or portions thereof, read i~rom the magnetic s~ripe.
The pre~erred terminal 3S also includes a keyboard 12û that allows a user, such as a merchant, to enter various information concerning a transac~ion into ~e te~ninal, and a 3s liguid crystal display (LCD) 1123 in order to display alphanumeric messages to ~e tenninal user.

.~.

.~ .

~, ; ; -:.

~S~ ~t~

In addition to the te~ninal 35, FIG. 3 also illustrates the preferred embodimen~ of a signature capture printer 38 construc~ed in accordance with the present invention. The signature capture printer 38 is connected to dle terminal 35 via a s cable 14S, preferably a serial data link. The signature capture printer 38 includes an injection molded plastic cover 1~0 ~at encloses the print engine, a digitizer printed circuit board, and a paper roll (not shown). The signature capture prin~er 38 is operative for printing a paper receipt 152 of a transac~ion~ which 10 is given to the cardholder, and ~or capturing the cardholder's signah~l~ in connection wi~ dle transaction.
After the paper receipt 152 is printed by the print engine, it emerges from the printer through a paper slot 1~.
The paper slot 155 incorporates a buil~-in cutting edge lS9 that 15 may be used to neatly tear the paper when the transaction is complete.
More particularly described, for a transaction the terminal 3 5 first collects the card' s account number and expiration date, and the proposed purchase amount. Once this 20 data is collected, the signature capturing printer 38 prints the "header" por~ion of the receipt, which typically includes the date and time of ~e purchase, the account number, expiration date, purchase amount, and a line ~or the cardholder's signature. The printer ~eIl advances ~e paper until ~e line for the cardholder's 2s signature is positioned over a signature capture window 160 located on ~e printer 38.
At that point, ~e paper receipt 152 will be pressed against a signature space or window 160 ~at is formed on the top sur~ace of the printer 38. The cardholder will be instructed ~o 30 use an attached or tethered magnetic/ink stylus lb5 ~ sign his or her name in ~e space provided on the receipt; the stylus 165 preferably contains a ballpoint pen-type cartridge and is tethered by a current-carrying stylus cord 167.
The stylus 16 5 in the preferred embodiment 35 comprises a pressllre sensing switch and a magnetic coil that is positione~ within the tip of ~e pen. The pressure sensing switch ,.

.. . ~ , .
- -: : , . ::

41 2~";` r~ J~

is operative to detect when the stylus 16~ is in contact with the receipt paper 152. Toge~er, the magnetic coil and the digitizer printed circuit board are operative to prodllce digital signals corresponding to t~ position of the stylus as the cardholder signs s the receipt. In particular, dle pressu~e sensing switch provides a "stroke started" signal when ~e s~lus comes in contact wi~ the signature capture window 160 and a "stroke comple~ed" signal when the stylus leaves the signature capture window. These signals allow detenrlination of ~he number of strokes in the 10 signature, which is merely a graphic object, a stroke being determined by an initial starting coordinate provided in response to the stroke s~arted signal and a ~mal coordinate provided in response to the stroke completed signal. This process will be discussed more completely below.
After the signature is captured by the signature capture printer 38, in preferredl embodiments the terminal ~quests a transaction authorization from a host computer. Once the authorization approval is rec:eived, the printer prints the remainder of ~e receipt (typically, a receipt body and a receipt footer), which includes the approv,al code received from the host computer. The printed and signed receipt 152 is ~en removed from the printer 38 and given to the cardholder. At the discretion of ~e merchant, t vo part paper may be used, wi~ the second copy suitable for retention by ~e merchant.
FIG. 15 more clearly illustrates the relationship between the paper 152 and the signature space or window 160 in the sigIlature captllre printer 38. Once ~he header of the receipt 152 is printed by the pnnt engine and emerges ~rom ~he paper slot 155, ~e paper is pressed down against the sign~ture capture window 160. When ~e remainder of the receipt is printed, the merchant may simply tear off ~he receip~ by using the serrated cutting edge lS9 ~at is posi~ioned adjacen~ to ~e paper slot lS~.
- - FIG. 4 illus~ates the tenninal 3~, and in par~icular, the preferred keyboard 12û that is incorporated into the terminal. The keyboard 120 comprises 48 keys that are arranged in three sections. Twelve keys are grouped toge~her in a first 42 ~ r~

section to provide a standard telephone-type keypad 171 including asterisk (*) and pound sign (#) characters, with the addition of "clear elltry", "backspace", ~'-", and "enter" keys. A
second section includes 26 keys and comprises an alphanumeric s keypad 172. l'he alphanumeric keypad includes a key for each letter of the alphabet, a "punctuation" lcey, and a "clear all" key.
l'he third section comprises four çonte~t sensitive, or "so~t", keys 17~ whose functions vary according to the operation being performed by the terminal. Those skilled in the art w;ll 10 understand that the function assigned to each of the conte~t sensi~ive keys 175 at any given time is displayed directly above ~e key on the liquid crystal display 123.
FIG. S depicts the va~ious electrical connectors located on the rear panel 201 of the bransact;on terminal 35. The 15 rear panel 201 includes two RS-485 ports 205a, b labelled LAN
IN and LAN VUT that are used to connec~ the telminal to a local area network (LAN). Preferably, a multidrop type LAN is employed, where each terminal is coImected to a host system as "mas~er" that collects transaction data for the merchant' s 20 entelprise as a whole. Such multi~rop networks will be known to those skilled in ~e art7 and will not be discussed further herein.
The terminal 3~ also includes four serial ports ZOX, labelled SE~RIAL 1, SERIAL 2, SERIAL 3, and PRINTER. The ports 208 are RS-232~C compatible and may be used to provide 25 connection~ to va~ious peripheral devices, including t~e signature captur~ printer 3~ via the cable 145, an electronic cash register, a bar code reader, and a personal identi~lca~ion number (PIN) pad.
l'he terminal 35 further includes tWQ RJ-ll-type 30 telephone connectors 212a, 212b labelled LINE and PHONE.
The L.INE 212a connector is used to connect a s~andard telephone line 48 ~o the telminal 35. In addition, there are ~wo means by which a telephone or ~elephone handse~ may be cormected to the terminal 35 in order to allow the ~erminal user to speak with a 35 credit card processor or issuer. A standard telephone ~not showII) may be connected to ~e PH(:)NE, connector 212b on the - ~

rear panel 201. Altematively, a telephone handset 21$ may be connected to an RJ 14-type telephone connector 22~ located on the termillal's side paneL The handset 218 rests on the detachable cradle 223 when ~e handset is not in use.
s Power is provided to the terminal 3~ via a sel~-locking power connector 226. Finally, a volume control 229 is also provided in order to control dle volume of a built-in speaker (not shown).
0 Transaction Termin~l Turning now to FIG. 6, the electronic components of the pre~erred transaction terminal 35 will be described. The preferred transaction terminal 35 comprises a ~erminal circuit board 250, which includes a central processing unit (CPU) 255 and its associated memory 2~8. The memory 258 comprises read only memory (ROM) ~or sysb~m code storage, and random access memory (RAM) for both applications program storage and data storage~ including storage of transaction data and compressed signature signals.
The terminal circuit b~ard 2S0 receives transactional data in four ways. Firstly, the ke,ypad 120 provides means by which ~he operator may enter alpham~meric data and/or designate a specifie operation for ~e terminal to per~orm. Secondly, the card swipe slot includes a magnetic read head 261 that allows ~he 2s te~al 35 to detect the data encoded on bvd~ track 1 and track 2 of a data card. This analog signal is then amplified and eonditiongd by the card swipe interface circuit 26~, before it ;s decoded by ~ VO processor 270. Thirdly, an embossed card reader 112 employs ~actile sensing elements to detect and decode ~e account number as represented by the embossed numerals located on a payment card. Four~ly, compressed signature signals are provided to dle transaction terminal 35 from the signa~ure capture printer 38 via a serial data link 145.
In dle preferred transaction terminal 3S, data from the card swipe interface 265, ~e keypad 120, and ~he embossed card reader 112 are decoded by the UO prosessor 270. The VO

: ~

L~ $ ~ r~

processor 27û then conveys the data to the central pro~essing unit 2~ as clocked serial da~a.
'~he preferred terminal 35 further includes a liquid crystal display (LCD~ 123 that is used to display alphanumeric s messages to the terminal user. The LCD 123 is prefera~ly driven directly from one of the input/outpllt ports of the CPU
2~5.
The transaction terminal 3~ further comprises a communications subsection 275 by which the terminal 10 communicates wi~ other electronic devices. In the preferred embodiment, dle communications subsection ~7S comprises four serial pOltS 208, a local area network (LAN) interface 205, a modem circuit, and the associated interface electronics. The communications subsection 275 also includes ports for connecting 15 a telephone or telephone handset 218 to ~e tenninal 35 in order to facilitate voice con~nunications.
The signature capture printer 38 is connected by a cable 14~ to one of the serial ports 208 (preferably the PRIMTER port) that is operativel~y connected to the tenninal's 20 communications subsection 275. S,erial data from ~e printer 38 is assembled and transmitted by the printer controller printed circuit board 280, located in the signature capture printer 38.
The preferred sigIlatllre capture printer 38 also includes a print engine 285, and signature (~ap~ure circuit comprising the printer 25 controller board 280 operating together with a digitizer printed circui~ (PC) board 300.
Inasmuch as many of the fimctions of the pre~erred terminal/printer 30 are common to data cardl transaction ~e~ninals known in the art, for example reading data from the 30 magnetic s~ripe of a data card, receiving transaction in~o~nation ~rom a keypad, displaying transaction in~ormatiorl on a display, assembling transaction data in a memory, attempting and conducting data communications with a host cornputer via modem, obtaining electronic authorizatiotl ~rom an authorization 35 host compllter system, continuing or terminating a transaction according to signals received from an authorization source, :
., :' : ' printing transaction information on a prin~er, etc., no further discussion of such basic operations of the pre~erred card transactinn terminal and printer will be provided. However, to the e~tent required ~or a complete unders~anding of ~e present 5 ;nvention, after a general description of the circuitry, there will be a discussion of ~e operation of ~e me~ods carried out in the present invention.
Termillal Circuitry ~G. 7 is a detailed schematic representation of ~e circuitry implemented on the preferred terminal circuit board 250. The terminal circuit board 250 is located in ~e terminal 35, andL comprises ehe CPU ass, memory 25~, I/O processor 270, card swipe interface circuit 26S, and liquid crystal display 15 123. The terminal circuit board 250 is directly connected to ~e embossed card reader 11l2, the ke~ypad 120, and the magnetic read head 261, which are also located in the preferred terminal 35.
The preferred central processing unit or CPU 255 is ~0 a type V-20 microprocessor manufactured by NEC Electronics, Mountain View, Califo~nia. Details of the preferred microprocessor are a~aila~le in the literature supplied by the manufacturer.
II1 addition to $he microprocessor 255, terminal 25 circuit board 2SQ includes a PC core logic circuit 256. The PC
core logic circuit 256 is a type 82C100 manufactured by Chips - and Tec~ologies, San Jose, California. Those slcilled in the art will understand ~at the PC core logic circuit 256 provides the signals ~at a~e ~equired in order for dle pre~erred te~ninal 35 to 30 olperate as aIl M[S-DOS-compatible computer system. Details of the PC core logic circuit 256 are available in ~e literature supplied by d~e manufacturer.
The memory 258 on dle ~e~ninal circuit board 250 comprises an electronically programmable read only memory 35 (EPROM) 410, a dynamic random access memory (DRAM~ 412, and a battery backed-up random access memory 43LS. The r~
~6 cen~al processing unit 255 is connected to the EPROM 410 and the battery ~acked-up random access memory 415 memory 258 by an address/data bus 420, an address bus 421, and a control bus 422. The DRAM 412 is connected directly to the PC core s logic circllit ~56.
The address/data bus 4120, address bus 421, and control bus 422 are opera$ive ~or conducting address signals, data signals, and control signals from ~e preferred nnicroprocessor 255 and core logic circuit 256 to ~e various peripheral devices 10 connected to such buses, in the manner knowrl to those skilled in the art and as described in ~he literature supplied by the manufacturer. II1 particular, ~hese buses 420, 421, 422 are connected to the memory 25$, communications subsection 2759 and LCD 123.
The EPROM 410 is a preferably a type 27C010 manufactured by Atmel, San Jose, California. The EPROM 4:10 is operative to store ~e software programs that are executed by the microprocessor 255. Thoe skilled in ~e art will appreciate that ~e software programs stored in ~e EPROM include a basic 20 input/output system (BIOS~, a MS-l)OS compatible disk operating system program (RC)M DOS), ancl a boot disl~ emulator (ROM
DISK).
The dynamic random access memory (DRAM) 412 provides memory that dle microproce~sor 255 uses to manipulate 2s data and to store application-type code ~hat is read from the battery bac~ed up RAM 415 dwing ~e operation of ~e te~ninal.
The pre~er~ed DRAM 412 comprises four 256k x 4 memory chips, type 81C4256, manufac~ured by Fujitsu Microelectronics of San Jose, California, and two 2S6k ~ 1 memory chips, type 30 53(:25S, manufactured by Hyundai Electronic Industries of Kyungki-Do, Korea. Those skilled in the art will appreciate that ~is eonfiguration pravides a total of memory of 512k bytes of RAM wi~ 1 parity bit.
Finally, the memory 258 includes bat~ery backed-up 35 random access memory 415 that is usecl to store terminal application software, terminal parame~ers7 and tra~saction data in what ~hose skilled in the art have denominated a "RAMDISK". In the preferred embodiment, the battery backed-up RAM 41S
comprises two, three, or four 128k x 8 devices, type AM628l28, manufactured by Hi~achi America of Brisbane, CaliiFornia. The s implementation herein described provides a minimum of ?56k bytes of battery backed up RAM, which may be e~panded to 512k bytes in 128k incrernents.
The terminal circuitry also includes a realtime clock circuit 430 ~at is operative to provide ~e date and time signals 0 to ~e microprocessor 255. ~he realtime clock 430 i~ preferably a type DSl285, manufactured by Dallas Semiconductor, I)allas, Texas, details of which are available in the literatllre supplied by the manufacturer. Those skilled in the art will appreciate ~at dle realtime clock 430 allows the terminal 35 to determine and l5 transmit the date and time of the transactions during normal operation.
The preferred liquid crystal display (LCD) 123 is a type LBN 242F-90 manufactured by Philips Components, Sla~ersville, Rhode Island, that is operative to dlsplay 20 alphanumeric characters provided by the microprocessor 255, in a manner tha~ may be read by l~he operator. Details of the operatioll and interface requiremeIlts for the preferred LCD 123 are available ~ ~e literature supplied by ~e manu~acturer.
An I/O processor 270 receives input ~rom the 2s embossed eard reader 112, the card swipe interface 265, and the keyboard 12û. In the preferred embodiment, the preferred VO
processor comprises a type 80CSl eight-bit microcontroller manufactured by Intel Corporation, Santa Clara, California, programmed and configured for inputloutpu~ functions. Details 30 of the preferred microcon~roller are a~ailable in the li~erature supplied by ~e manui~acturer. The card swipe inter~ace 265 and dl~ embossed card reader 112 will be described in more detail in - conjunction wi~ other figures.
~ particular, however, it should be unders~ood that 3s the I/O processor 270 includes on-board ROM for program storage and ~or storage of pattern data for purposes of decoding , ~ ? 5~

characters read by the embossed card reader 112, and is connected ~o external static random access memory 271 for storing character daea provided by the embossed card reader. In the pre~erred termirlal, the sta~ic RAM 271 is a type 6264, s manufactured by Hitachi America, Brisbane, (:~alifomia.
Still referring to FIG. 7, the preferred cormmmications subsection 27~ includes serial port circuitry 440, a local area network interface eircuit 443, and a modem circuit 446. ~e preferred modem circuit 446 is a 2400 baud 0 modem comprising a type SCllO11 modem controller, and a type SC11024 modem device, both manufactured by Sierra Semiconductor, San Jose, California. The modem circuie 446 operates in the known manner9 under control of microprocessor 255, to permit the transaction tetminal 35 ~o comrnunicate wi~
lS other computing devices, such as an authorization host or transaction processor's host, via standard dial-up ~elephone lines, using the telephone line out 48.
It will be understood that ehe preferred terminal 35 is capable of cornmunicating with a remo~e host computer, an 20 audio response unit responsive to dual tone multiple frequency (DTMF) signals, or a live operator. Thus, the preferred modem 44C is capable of transmitting data at up to 2400 baud to a remote host via line 48. ~ addition, the preîerred modem 446 is responsive to ~e keyboard 120 to provide stand~rd DTMF
2s signals via line 48 for communication wi~h an audio response unit. Moreover, the telephone line 48 may be switched to the handse~ 218 for live eaLk or for provision of synthetic speech to ~e merchant, Ot to a speaker 451 for p~ovision of speech.
Thus, the preferred terminal 3S also includes an 30 audio speaker 451. The speaker 451 is connected to a telephone line interface eircuitry 45 in order to moni~or eall progress. It is also operative to provide beeps and other audible tones genera~ed by the PC core logic 256 and is opera~ive ~r generating audible tones to attract the attention of the terminal 35 operator.

., :
i,, , ~9 The preferred modem 446 connects to the telephol2e line out 48 via the telephone line interface circuitry 4~. Those skilled in the a~ will appreciate that ~he telephone line interface circuitry 455 includes hook switch relays, isolation transformers s and other known circuit components~ utilized in the known manner to connect for data and voice commlmications to a conventional telephorle line.
The preferred serial port circuitry 440 is RS-232-C
compa~ible and is operative for driving ~he ~our serial ports 208.
10 ~he serial ports 208 are controlled by two serial communications controllers 460a, 460b. The pseferred serial communications controllers 4 6 Q a, 4 6 0 b are type 82C452 controllers, manufactured by United Microelec~ronics, Hsirlchu ~ity, Taiwan.
The serial commL~ications controllers 460 receive 15 data ~rom the microcomputer 2~5 via the address/data and control buses 420, 421, 422 and operate in the known marmer to convel~ parallel data from the microcomputer into serial data for provision via the ports 2 0 8 . In addition, the serial communications controllers 460 are operative to contsol the baud 20 rate, parity, number of stop bits, etc., associated with the serial data. When serial data is received from a connected serial device (for example, ~rom the signature capture pnnter 3B), the serial communications controllers 460 a~ operative to convert the serial da~ into parallel data and~to convey that data to the 25 microcompllter 255.
~ addi~ion to the serial communications controller 460, ~e serial interface 440 includes serial port drivers 462.
The senal port drivers 462 comprise two type 145406 drivers, and two typ~ 145407 drivers, bo~ manufactured by Motorola, 30 Schaumberg, Illinois, and one type 1489 ~river manufac~ured by National Semiconductor, Santa Clara, Califomia. The serial port drivers 462 are operative to convert ~e signals from the serial communications controllers 460 to a voltage level compatible with dne RS-232-C standard. Finally, the serial port drivers 462 3s are connected to four 8 pin DIN comlectors comprising the serial ports 208.

Still refernng to FIG. 7, ~e pre~rred terminal 35 may also be cormected to a local area network (LAN) 51 via a LAN interface circu;t 443. The prefelTed LAN in~rface circuit 443 includes a serial controller 46 and aIl RS-485 driver 468.
5 The preferred serial controller 465 is a type 16C450/16C550 Universal Asynchronous Receiver/Transmi~ter (UART) manufactured by Texas ~strumen~s, l:~allas, Te~as. The serial controller 465 is cormected to th~ RS-485 driver 46~, preferably a type DS75176, manufactured by National Semiconductor, Santa 10 Clara, California. The l~S-48~ driver circuit 468 is operative to convert ~e signals from the LAN controller 465 to a signal level compatible with the RS-485 stan~rd.
CaFd Swipe Interface C;rcuitry As will by now be lmderstood, informa~ion contained on the magnetic stripe of a data card is read from ~e card in a transaction terminal 30 when a data card transaction is initiated.
The information on the magnetic stripe lL10 includes the card's account mlmber, expiration date, and other information, in a 20 ~ormat speci~led by ANSI Standard X4.16-1983. l~is standard is published by the American National Standards Institute, Inc., 1430 Broadway, New York, New York, and is incorporated her~in by reference.
The in~ormation is ob~ainsd from ~he m~gnetic stripe 2s by swiping ~e card through a swipe slo~ 103 in ehe transaction tenninal 35 (FIG. 3) of ~e terminal/printer combination 30.
The swipe slot 103 includes a magnetic read head ~61 dla~ is connccted ~o the card swipe inte~face circuitry 26S (FIG. 63.
Toge~er, dle read head and card swipe interface circuitry are 30 operative to read signals from a swiped card's magnetic stripe, and to provide ~ese signals for interpretation by the CPU 255.
Turning now to FIG. B, the preferred card swipe interface circui~ 265 comprises a Track 1 circu;t 480 and a Trac~c 2 circuit 481, and is comnectsd to a magrle~ic read head 35 261. The prefelTed read head 261 is cor~lgured to read the data recorded on both track 1 and track 2 of ~e magnetic stripe on a . .
.
. , .

; . ., : . ~ ~ !
~`:

data card simultaneously. 'Ihe signal corresponding to track 1 data is provided on a first pair of terrninals 485, and the signal corresponding to track 2 data is provided on a second pair of termLnals 486.
s The first pair of terminals 4~S is connec~ed ~o a Traek 1 circuit 480, which provides an output signal F2FTRKl ~o ~e VO processor 270. l~e second pair of terminals 486 is connected to a Track 2 circui~ 481. which provides an output signal F2FTRK2 to ~he IIO processor 270 (~IG. 6). Since the Track 1 circuit 480 and Track 2 c;rcuit 481 are s~bstantially identical, only ~e Track 1 circuit 480 will ~e described in detail.
As shown in FIG. 8, the Track 1 circuit 480 is connected to the read head 261, and is opera$ive to condition signals generated by m~vement of a magnetic card s~:ipe past the read head 261 durhlg a card swipeO ThP circllit 4~0 is opera~ive to provide these signals to the I/O processor 270 as a self-clocking synchroIlous signal, F~FTRKl.
The preferred Track 1 circuitry 480 includes a first amplif;er 490, having its inverting and noll-inverting inputs connected ~rough input resistors R2, R3, rcspec~ively, to the two telminals 485 of the read head 261. A feedback resistor Rl connected between the output of the amplifier 490 and the inverting input de~errnines the amount of gain, together wi~h other components, in the manner which will be understood by those skilled in th~ ar~. A bias voltage VBIAS is connected through resistor R4 to the non-inverting terminal, to bias the output voltage level of the ampli~ler 49Q.
The output of ~e first amplifier 490 is connected to a differentiating amplifier 495, which is operative to detect peaks in the signal received form the amplifier 4 9 0 . The differentiatillg amplifier 495 includes a pair of diodes Dl, D2 conrlected in opposite bias directions be~ween the output and inverting input. The diodes, in conjunction with a capacitor C3, opera~e in the known manner to conduct sharply when ~e voltage 3s across the output and the noll-inver$ing input of the diferentiating ampli~ler ~95 rises to a predetermined level.

, . , . ' :

.:
. , ,.. ~ .. .. , ~ , - ~

5~ 2 The output of the d;fferentiating amplifier 495 is ~en connected to a zero crossing detector 497 that provides I~I~
level bu~fering for the signal and generates the F2FIRK1 signal at its output. Resistors R6 and R7 are connected between the 5 output and non-inverting input of the zero crossing detector 497 in order to provide hysteresis as the voltage level changes at the iIlpUt of dle zero crossing de~ector 497.
The Track 2 circuitry 481 is substantially iden~ical to the Track 1 circuit 480, bu~ instead provides a self-clocking lo s~mchIonous signal, F2FrRK2, to the I/O processor 270.
As discussed more fully herein, ~e present invention is operative under certain circumstances to read the account number information frorn track 2 as ~ alternative source of in~olmation conceming ~e account number, expiration date, etc.
15 In preferred embodiments of the ilnvention, the terminal 35 may be made operative to restore deiFeetive or erroneous information read from track l, in whole or in part, by substituting, in whole or in part, the account number and/or expiration date, to forrn a complete account number tha~ satis:~les the known account number 20 checksum operations. This operation, in addition to providing a signal indicative that a card wa~; physically present during a transaction, ensures that a complete account number can be obtained from the card, and cross.checked against the various sou:rce~ of the accoun~ n~mber islformation, as further checks on 2s ~e accuracy of ~e account number and validi~r of ~e card.
Embossed Cal d Reader As has been discussed in geneMl earlier, preferred embodiments of the transaction ~enninal 35 include a tactile 30 imager operating as an embossed card reader 112, shown in FIO.
9 and PI(3. 10. The embossed card reader 112 ;s opera~ive to tactilely sense ~e raised or embossed charaeters on data cards and provide signals corresponding to the characters ~hereformed.
These characters are then utilized to ~orm an accolmt number 35 associated with ~e data card.

.. . . . . ; . ,:
.: ~
- . .. .. .

According to a preferred aspect of the presen~
invention, the account number formed with the embossed card reader 112 is utilized as an electronically captured account number only when the account number cannot be obtained from s readirlg the magnetic stripe on dle card.
According to ano~her aspect of the invention, the account nurnber obtained from the embossed card reader may be used to restore a defective or erroneous account number, in whole or in part, by substitution of ~he account n~nber, or 0 selected characters thereof, where ~e magnetic stripe is damaged or is producing read errors. In yet another alternative embodiment, the data read from the embossed card reader may be used to compare against the acco~t number obtained ~rom ~e magnetic stripe as a furd~er check on the validity of the card.
FIGS. 9A -- 9E are a series of partial diagrammatic end views of the preferred embossedl card reader 112, illustrating the operation of insertion and reading of a card 15. The embossed card reader comprises an embossed sensor board 505 including a two-dimensional ~actical imaging array 538, a control circuit 510 connected to the embossed sensor board via a zebra strip 540 (an electrical connector), a switch for detecting ~he insertion of a data card, a switch for de~ec~ing ~he completion of the read cycle, and means for moving an inserted card into operative con~act wi~ ~e tactile imaging alTay.
2s As illus~ated in FIG. 9A, the means for moving ~he inserted card ~nto opera~ive contact wi~ the t:acdle ~aging array comprises a cam shaft S30 that Ieleases a pressure plate 531 to be urged by a p~essure spling 534 to bîas an inserted card against ~ie tactile imaging array. The pressure plate ~31 is pi~otably mounted and comprises an entry edge 541 for receiving the inserted card, a pressure plate actua~ng a~n 542, and a pressure applying area 543 that corresponds to the embossed region 115 of the inser~ed card and is adjacemt ~e imaging array 538. The pressure spring 534 is also pivotably mounted and comprises a 3s pressure applying su~face 544, a cam con~act region 545, and a pressure spring ac~ua~ing arm 536.

'2~Ag~

An inserted card is read during a read cycle, in which the cam shaft 530 completes an entire rotation. At the begimling of each cycle (i.e., before the card is inserted~ e cam is in an initial position, with the lobe 546 on ~e cam shaft 530 is S at its highest position. At ~is initial position of the cam, the pressure plate actuating arm ~42 is held upward, so that dle entry edge ~41 and pressure applying area 543 are forced downward in order to facilitate inse~tion of the card 15 into dle slot 113.
FI&. 9B illustrates the insertion of a card 15 into the 10 slot 113 folmed in the plastic terrninal case 101. When a credit card 1~ is completely inserted into the slot 113, it strikes a first switch actuating arm ~lL5 positioned at the rear of ~e reader 112, causing it to move downwardly in the direction of arrow 516. '.l~e first switch actuating arm 515 pivots about an axis and 15 its opposite end actuates a first switch ~17a located on the control circuit 510, which produces a CARD INSERTED signal indicating that a card has been inserted into the embossed card reader.
With ~he card completely inserted to cause actuation 20 of the first switch 517a, the embossed characters 11~ on the card lS are positioned in operative juxtaposition, but not contacting with, the tactile imaging array 538 on the board 505.
The CARD INSERTED signal is provided to the I~O
processor a70. At that point, the I/O processor 270 causes 2s electIical power to be applied to a drive motor 547 (not shown, see FIG. 11). The drive motor is operatively connected to the cam sha~t 530 by a reduction gear train S49 (not shown; see FIG. 11). I'he action of the motor and gear train causes the cam sh~t 530 to rotate in the direction of the arrow ~19.
As ~e cam shaft 530 rotates, the lobe 546 leaves it highes~ position, thus rotating away from ~e pressure plate 531 and toward the pressure spnng 534. This allows the pressure plate actuating arm 542 to ~all as the pre~sure spring's cam contact region 545 is forced downward in the direction of the arrow 520, thus causing ~he pressure applying surface ~44 and ,; , 2~

pressure applying area ~43 to be forced upward in the direction of the arrow 521.
As illustra~ed in Fl(}. 9C, when ~he cam shaft ~30 is halfway through its ro~ational cycle, the lobe 546 is at its lowest 5 po~nt, pressing against the pressure spring 534. l~his causes pressure applyLng surface of ~he pressure spring 534 to pivot upwardly and reach i~s highest point. l~his, in turn, biases ~he pressure applying area 543 of the pressure plate ~31 to its maximum upw~rd position.
At this position, shown in FIG. 9C, the embossed characters are pressed firmly into the imaging array 538. The embossed card reader 112 ~en is operative to sense ~e signals ~rom ~he imaging array, in the manner described, and decode ~he characters associated with embossed region 115 of ~e card. The 15 process of detecting and decoding the embossed characters is accomplished as the cam continues to rotate, and is completed by time the cam lobe leaves its lowest position.
Altematively, the terminal could cause the motor S47 to stop, and the cam sha~t 5~50 and pressure plate 531 to 20 maintain pressure OIl the card until dle read process is complete.
At that time, the motor would be restarted and the cycle completed. Such an alternative embodiment would provide additional time for ~e electronics to complete the reading of the embossing~ or time i~or repeated readings of the embossing for 25 error checking, if desired or needed.
In PIG. 9D, ~e lobe 546 has left its lowest position aIld is roeating towards completion of a read;ng cycle. A~ the cam 530 rotates in ~e position OI the arrow 522, ~e pressure plate achlating arm 542 is now driven upward back toward its 30 initial po~ition, ~orcing the entry edge 541 and pressure applying area 543 of ~e pressure plate S31 downward in the direction of dle arrow 523, for release of ~e card.
The final portion of the embossed charac~er read cycle i5 illustrated in l~IG. 9E. The re~d cycle i~ complete when 3s the entry area 541 and pressure applying area 543 have re~urned to ~eir initial, downward position. At ~is point, the cam shaft r has comple~ed one revolution, allowing the pressure spring act~lating arm 536 to actuate a second switch 517b associated with the control circuit 510. The actuation of the second switch 517~ produces a CYCLlE COMPLETE sîgnal to the I/O
s processor 270, which dlen causes power to be removed from the drive motor 547. Once the entry edge 541 and pressure applying area 543 have ret;urned to their original position, the card lS may be easily removed from the slot 113.
FIG. 10 illustrates ~e circuitry incorporated in~o the 0 embossed card reader 112. As described earlier, the embossed card reader 112 comprises an embossed sensor board S05 and arl embossed reader electronics board Slû. l~e p~erred sensor board 505 mounts a two-dimensional silicon imaging array 538 and is connected to the electronics board 510 by means of an 15 electrical connector hlown to those skilled in the art as a "zebra strip" 540. The electronics board 510 includes all of the electronic somponents necessary to decode data from the imaging array. Those skilled in ~he art will understand that the embossed sensor board 505 and electronics board 510 together operate in 20 accordance with the silicon tactile imaging array described in U.S. Patent No. S,055,838 to wise e~ al., the disclosure of which is incorporated herein by reference~ and made a part hereof. The reader should re~er to U.S. Patent No. S,05~,838 for specific in~ormation regarding the operation of the tactile imaging a~Tay 2s 53~.
Generally described, the imaging array 538 of the embossed sensor board 505 includes a plurality of elements - arranged in rows and columns, to forrn a twv dimensional array.
The rows and columns are connected at each intersection by 30 pressure sensitive capacitive elements. The capacitance of these elements varies in proportion to ~ amoun~ of force applied to the sensor. Thus, ~ose capacitive elem nts ~at come in con~ct with ~e raised sur~aces of ~e characters ~rmed in ~e embossed region 115 will display different charaeteristics than those 35 elemen~ at are adjacent to the spaces between the characters.

, ,. , ~ , :

57 ~ d ~

As is more fully described in the above referenced patent, the electronics board 510 causes each of the rows to be strobed with an elec~r;cal pulse. As each of the rows is strobed, the device detects the sign~l presen~ at each of the columns. The s amplitude of the output vol~age pulse is proportional to the capacitance, which is in turn propor~ional to the local force applied. Those skilled in the art will appreciate that the process employed in ~e present invention is analogous to those methods known in the art by which keyboards are polled. The signals thus 10 detected are representative of the standard numeric characters formecl in the embossed region 115 of the credit card 15, and may ~ decoded by the teIminals I/O processor 270.
~ the preferred embodiment, each intersection of a row and column in the array 538 is spaced apart by 0.5 lS millirneters, thereby providing a resolution of 50.8 dots per inch.
It will be understood ~hat the fc~rm of the characters in the embossed region is govemed by the Farrington 7B standard, such that each character is 0.1 by 0.17 inches, and has a distinctive shape (font). The Parrington font îs described in ANSI Standard 20 X4.13-1983, which is published by the American National Standards Institute, Inc., 1430 Broadway, New York, New York, and is incorporated herein by reference.
A~ter strobing all rows of ~he imaging array 53$, there will stored in an imaging array RAM associated with the 2s I~O processor 270 as an array of digital signals colTesponding to ~e raised and fla~ areas of dle data card, comprising 1680 data elements or pi~els. In the preferred embodiment, these data elemeIlts are then examined utilizing a simple "pattern recognition" algorithm to dete~mine dle identity of the characters 30 iForming ~e accollnt number, by comparing the data in the imaging array RAM associated with the VO processor ~70 to pattems associa~ed with the Farrington 7B characters stored in ~he Farrington character pattern ROM associated with ~he I/O
processor 270O For example, data representing a single 3s Farrington character comprises 9 words of 8 bits each, which are compa~d row by row to dle rows of data elements sîored in the . : :

imaging alTay RAM. It will thus be appreciated ~at storage of all Falrington characters (10 numerals) only r~quires 90 bytes.
~ the same mamler, other information folmd in ~e embossed area such as expiration date9 etc., can be decoded if S desired.
I'he exploded view of FIG. 11 of the embossed card reader 112 illustrates the ju~taposition of the tactile imaging array 538 relatlve to ~he pressure plate 531. An electric motor S47 drives the reduetion gears 549 that rotate ~e cam 53û.
As best seen in FIG. 12, the first switch achlating alm 515 is operatively positioned widl respect to the ~lrst switch 517a Oll the side of ~e reader 112 closest to the motor 547, while the pressure spring actuating arm 536 is operatively positioned O~ e opposite side of the reader 112 with respect to 15 the second switch 517b.
Metlhod îor Decoding 'Embossed Characters FIG. 14 illustrates the imaging array 538 and exemplary embossed Farrington c:haracters 550a, 550b. In the 20 preferred embodiment of ~e present invention, ~e imaging array 53$ measures 6 millimeters x 70 millimeters and has a resolution of 0.5 millimeters. Thus, the preferred array measures 12 x 140 da~a elements or pixels 5~2, and ha~ a total of 1,680 elements or pi~els~ An embossed Farrington character 5~0 on a typical data 2s card will fit within a 5 x 9 pixel alTay, thereby de~ining a character cell 5~1. Thus, it will be appreciated ~hat the pattem data defining a data card Farrington charac~er requires 45 bits of informatlon.
As can be seen in FIG. 14, if a typical character is 9 3û pi~els high, and given that ~e preferred array is 1~ pi~els high, ~ere is tolerance for movement of ~e embossing on ~e data card of + 3 pi~els widl respect to ~e imaging aITay 538.
Once a da~a card 15 is read by ~he embossed card reader 112, the 45 bits of data representatiYe of the embossed 3s region llS are temporarily stored in random access memory associated with the I/O processor 270 until a complete account number is fo~ned and provided to CPU 255.
Tuming now to FIG. 15, a method 553 by which the data representative of ~he embossed characters is decoded will be s described. The pre~erred embossed charac~er decode method 5S3 is implemented as software for ~e VO processor 270, and begins at step ~54, when the imaging array 53$ is scanned and 1,680 bits of digital data representative of dle embossed character region 115 o the card 15 is ~ormed. Once this da~a is fomled, it 10 is temporarily store~ in the random access memory provided in t~e VO processor 270.
At step 555, the VO processor 270 scan ~he data representative of the embossed characters and locates the pixel that forms ~e upper/le~t corner of ~e ~Irst character, such as the 1S comer 556 in FIG. 14. Once this corner 556 is located, the method advances to step ~57, whereupon a character cell 551 is defimed about the first character. Those skilled in the art will unders~and that the upper left cornèr of the 9 x 5 character cell 551a will coincide with ~e upper left comer of the character ~0 550a, and ~his defines ~he top and bottom, and left and right boundaries of the cell ~51.
At step 559, the VC) processor 270 begins the process of decoding the character corltained wi~hin ~e cell 551.
In the pre~erred embodiment of the present invention, this is 2s accomplished by comparing ~he 45 bi~s of data in the cell 5~1 with pattem da~a or reference Gharacters representative of each of the ~arrington charactgrs that is storcd in a portion of the read only memory provided in ~e VO processor 270.
Generally described, the s~ep of comparing the 30 charac~r read by the imaging array~with the reference characters involves comparing the pixels 552 that fonn ~he character read ~rom the card with the pixels that would form each of ten reference characters, the numerals 0 ~hrough 9. The pre~erred comparison step comprises perfon~ing a logical exclusive-OR
3s operation upon each of ~he 45 lbits of the cell 5Sl with the corresponding 45 bits of each of numeral s~ored in ROM. The ~o ~um~er of matches is then added up to obtain a comparison count.
A '~match'9 is deemed to have occurred if there is a complete correspondence between each bit in the sell 551 and each bit in the pattern stored in ROM.
However, it will be appreciated that the characters may also be decoded by deeming a "match" to occur for the particular character ~at produces ~e greatest number in the comparison count. Moreover, it will be appreciated that a "ma~ch" could be deemed to occur if a comparison count for a 10 particular character e~ceeds a selectable p~determined threshold, or if the comparison count e~ceeds the ne~ close3t comparison count by a predetermined amount. Those skilled in the art will appreciate that a selectable threshold may be established for dle number of matches required ~o identify the character in question.
15 This ~reshold may be adjusted according to a desired tolerance.
It should also be understood that the ~hreshold of the number of matches also detèrmines whether the characters read ~rom the card are "acceptable'9, that is, generally within the speci~lcations prescribed for embossed characters on data cards.
20 Those skilled in the art will appreciate that tbe embossed characters on a credit card comply with the lFarrington 7B
standard. However, the resolution of the disclosed embossed card reader 112 does not allow determination whether the characters of the embossing are within ~he precision set forth in the 25 F~gton 7B standard. Nonetheless, ~is resolution is sufficient to penxlit determination as to whether dle characters are grossly out of proportion, sizeS alignment, spacing, etc., and can detect badly wom cards or certain ~raudulent cards. Thus, the determination of whether the embossed characters are 30 '~acceptable" will vary widl ~e reolution of dle embossed card reader and ~e degree to which ~e transac~ion processor decides to set parameters of acceptabili~.
For pu~poses of the present invention, characters may ~ deemed acceptable if ~e size and spaciIlg of dle characters 35 is within the tolerance of the tactile imager, that is, about 0.5 - ., ;., : . .
.

- ~
. . ~ , ~ . .
.

millimeters, and/or the comparison count exceeds a predetermiIled threshold which is empirically determi~ed.
Once the character is decoded at step 559, the method proceeds to step 5~1. At this step, ~he character that was s decoded in step 559 is temporarily stored in dle I/O processor's memory. At step 563, ~e VO processor 270 determ;nes whe~her the last character decoded represents ~e end of the character array 53$. IiF not, the method returns to step 555 whereupon the character cell 551b (FIG. 14) is moved to the 10 posi~ion of the next character. This may be aceomplishçd by simply repositiQniIlg ~e charae~er cell at a new position a iFixed number oif pixels away from the original position due to ~e ~act dlat the Farrington standard specifies a predetermined spatial separation between characters. Once the ne~t character cell is 5 establis~ed at step 56S, the method repeats the step ~59 and decodes ~e next character.
IiF at step 563 the VO ]processor 270 determines that the last character decoded represented the end of the embossed character region 115 oiF the card, the method advances to step 20 567, whereupon the VO processor 270 assembles each of the individual characters decoded to iForrn an account number, and provides thi number to the telminal's main CPU 25~ iFor subsequent use.
2s Sigllatule Capture Printer The preferred signature capture printer 38, as discussed above, is operative for printing a receipt of a transaction conducted with dle combination ~erminal/printer 30, capturing the signature of ~e cardhol~er as a plurality of digital sigllature signals corresponding to the (X,Y) coordinates of the stylus 165 relative ~o a signature window 160, compressing the signature signals to provide eompressed signature signals, and transmitting ~he compressed signature signals to ~e terminal 35 so tha~ the signature signals caIl be associated with other 3s transaction data andl transmiteed to tlie transactiorl processor host.

::

~r~

It should be unders~ood, however, that while the signature capture plinter 38 is especially su;ted for operation in combination wi~ the terminal 35 to perform certain methods for chargebaek protection in accordance with methods disclosed s herein, the signature capture printer may be considered a "stand alone" i~em that can be connected to other types of data transaetion te~ninals, as well as other data communications and processing devices such as personal computers, for providing prlnting and/or signature capturing functions.
Mechanical Construction of Signature Capture Printer Referring now to FIG. 16 and FIG. 17, ~e pre~erred signature capture printer 38 comprises a print engine 285 for 15 printing a paper receipt 15a of a transaction, a signature capturing window 160 in which a cardholder's signature is impressed, a tethered stylus 165 to be used by a cardholder in signing his or her name in the signature window in connection wi~ the transaction, a signature capturing circuit 280, 300 ~or 20 obtaining signature signals corre~sponding ~o the cardholder's signature from the signature cap~uring window, means for compressing the signature signals to obtain compressed signature signal3, and means for transmitting ~e compressed signature signal to an external source (sueh as the terminal 3S or other 25 utilization means).
A paper roll 570 in the signahlre captu~ printer 38 ls stored in a eovered rear housing 571 of the printer. Paper from ~e paper roll is fed along a paper path 575 into a print engine 285. The prefelTed print engine 285 is a model M-267 30 dot matri~ printer manufactured by Epson America, Inc., Torrance ,California .
As the print engine 28~ prints on ~e paper9 the pap~r is fed out of ~e plint engine 2X5 and up through ~he paper slot 155 that is forrned in the top of the printer case 1~0. As the 35 paper emerges from the paper slot 155, it rests on the top surface of ~e cover 15û and the signature capture window 160.

.
.
-;~ - ' -- ; . - .
, ~ .. .. ,; ~ , ;
-: :,' "

The printer controller board 280 is positioned in the bottom interior of the printer 38. The printer controller board controls the operation of the printer~ including the print engine 285 and paper feed mechanism (not shown).
In addition, the printer controller board 2 8 0 includes circuitry in the ~orm of a programmed microeompllter that receives digital values for the X and Y coordinates in the form of STYLIJS POSITION signals corresponding to the signature from a digitizer printed circuit board 3 0 0 and 10 compresses these signals to obtain compressed signature signals.
This signature capture circuitry compresses the digital X-Y
conrdinate signals with a compression algorithm before the signature data is transmitted to the transaetion telminal 3~ or other utilization means.
The printer controller board 280 also controls the transfer of the compressed signature signals to, and printer commands from, dle preferred terminal 35.
Printer Colltroller and Signature Digitizer Printed Circuit Boalàs Turning now to FIG. 18, the printer controller circuit bo~rd 280 and digitizer printed circuit board 300 will be described. As discussed earlier, the printer eontroller board 280 is electrically connected to ~e tenninal 3S, print engine 285, and 2s digitizer PC board 300. In particular, the printer controller board and digitizer PC board 300 comprise a signature capture means implemented as a circuit and software. Generally described, ~he prin~er co~troller board 280 is oper~tive to - receive serial data and control signals from the telminal 35 and the digitizer PC board 300 and to ~ransmit serial data and control Sig~ 3 to the terminal 35 and print engine 285.
The printer control:ler board 280 comprises a printer cene~l processing unit (CPU) 580 and assoc;ated memory 581. The preferred printer CPU 580 is a type 8ûC52, manufactured by Signetics9 Sunnyvale, Califo~nia. l~ose skilled in the art will appreciate ~at the printer controller function itself , . .~

is irnplemented in software that is stored in the printer CPlJ's integra~ed read-only memory (ROM). lhe printer controller board 280 also includes random access memory (RAM) ~81.
The printer RAM is used to ~emporarily store data as it is 5 manipnlated by the printer CPU 580, or as it is ~ransferred between ~e printer controller board and other devices. The preferred printer RAM 581 provides 32K by~es of storage, and is a type 58256, manufactured by Hi~achi America? Brisbane, California.
In the pre~rred printer controller board 280, the printer CPU 580 is connected to the terminal via a serial inter~ce 585. The serial interface 585 comprises a serial communications device and an RS-232 compatible bu~fer. The serial communications device operates in the known manner to convert serial data into parallel data, and vice versa. The preferred serial communications device is a type 82C50 serial communications controller, manufactured by VLSI, Tempe, Arizona. The preferred RS-232 bu~fer is a type MAX 232, manufactured by MAXIM, Sunnyv,ale, California.
The printer colltroller board 280 is connected to the digitizer PC board 300 by means of a simple serial data coDnectiorl. Buffered serial data from ~e digitizer PC board 300 is ~ed directly into ~e pnnter CPU 580. This serial signature daea, comprising a signature signal, is in the ~orm of (X,Y~
2S coordina~e pairs representative of ~e signature provided by the cardholder. This data i3 then compressed by the printer controller board 280 be~ore it is transmitted to the ~emlinal 35.
The eompression algorithm utilized by the printer controller board is described in greater deta;l below.
Finally, the printer controller board 280 is operative to control dle print en8ine 285. The data that is to be printed on the receipt by the print head is trans~erred from the prin~er CPU
580 to the print engine 28S. Inasmuch as ~ose skilled in the art will understand that the print engine 28~ is operated in the manner of dot matrix printers known in the art, the details of its operation will be omitted.

-. . . ......
,, . , ~ ., ., ~ . .
, , .
. . .

~ r ~
~5 Turning now to FIG. 18 and 19, the digitizer PC
board 300 will be described. The d;gitizer PC board 300 is opera~ive in conjunction with and in response $o a magnetic/iIlk stylus 165, colmected via a stylus cord 167. ~he digitizer s pnnted circuit board 300 includes 3n X- and Y- grid 601, 602, a digitizer central processing unit 610, and analog cireuitry 612 to ampli~y and condition ~he signals received from ~e stylus ~65.
~ he digitizer PC board 300 and stylus 165 operates in ~e manner described in U.S. Patent No. 3,873,770 to Ioannou, lo which is incorporated herein by re~erence ancl made a part hereof, and provide3 data corresponding to the (X,Y) coordinate pairs that are representative of the signature provided by ~e cardholder. The pre~erred digitizer comprises 11 horizontal wires and 21 ver~ical wires on the top surface, called grid wires.
15 Wherl any one of these grid wires is pulsed, dle wire transmits electromagnetic energy to the space above it. The pick-up coil in dle stylus captures some of this energy in a fashion similar to ~a~
of an antenna in a radio receiver. This energy is amplified and processed by a microprocessor or CPU 610 associated with the 20 digitizer PC board 300. ~e microprocessor is programmed to pulse a grid wire and ~hen listen for a response from the stylus.
It pulse~ eaeh wire in rapid seque~nce and stores each response from the stylus in a memory array corresponding to the coordinates of ~e window. By interp~ting ~e stored data and 25 pe~fo~nin~ ma~ematical calculations on it, the microprocessor can pin poin~ the locatinn of the stylus ~o a r~solution better dlan 0.004 inches.
A pressure sensitive swi~ch wi~in ~e stylus 16~ (not illustrated) genera$es a CONTACT signal on line 615 to the 30 digitizer CPIJ 610 that indicates th~ stylus is in contact widl the pape~. This CONTACI signal is asserted when the stylus comes in~o contac~ with ~he signature capture window 160 (and may be considered a stroke searted signal) and is negated when dle stylus is lifted from the w;ndow (and may ~en be considered a stroke 3s completed signal).

,. . .

~6 .

The elements of the X and Y grids 601, 602 are energized in a sequential manner as the stylus is used to SigII the receipt. As the stylus is used in the vicinity of the energized grids, an electric current is induced in the magIletic coil in the s stylus. This signal is carried back to the digitizer printed circuit board 3û0 and is amplified and conditioned by the analog electronics 612. The conditioned signal is ~en supplied to the digiti~er CPU 610, which is operative ~o derive X and Y
coordinate data from the induced signal.
0 Once the digieizer CPU 610 creates the signature signals representative of the signa~ure, the digitizer PC board 300 transmits the data to the printer controller ~oard ~80 in the form of (X,Y) coordinate pairs, at predetermined sample times. The printer controller board 280 is thereafter operative to compress the signature signals to form compressed signature signals before they are transmi~ted to the eransac~ion terminal 35 via the serial data link 145 from the signaeure capture prineer 38.
Details of the preferred method of compressing the signature signals to form compressed signature signals are provided in greater detail below. Those skilled in the art will appreciate that the procegs of compressing the data reduces the amount of memory required to store the signature and thus facilitates more effilcient use of ~e te~al hardware.
2~ Si~nature Window of Signature Capture Printer Re~rring for a momeIlt to FIG. 16, ~e relationship be~ween ~e top part of the plastic cover 1$0, the receipt paper 152, and the digitizer printed circuit board 300 will be described. As discussed earlier, ~e receipt paper 152 emerges 30 ~rom the printer through the paper slot 155 after it is p~ted on by the print engine contained intemally to ~e signatl;lre capture printer 38. As the paper emerges ~rom the paper 310t lS5, it is directed upward so tha~ it lies flat on ~e top portion of ~e plastic cover 1~0.
3s Turning now ~o FI&. 19, the signature capture window 160 is located just above ~e paper slot 155. The prin~er . .

.; , . I .

will advance the paper 152 until a prhlted signa~re line 625 is positioned directly above the signature caph~re window 160. At that point, the cardholder will be instrusted to sign the receipt paper 152 with the magnetic/ink s~ylus 165. The signature 5 capture window 160 is positioned immediately above the digitizer prin~ed circuit (PC) board 300 that translates movement of the stylus 165 into digital signals indicative of the X-Y position of the stylus relative to the window, where X is the elongate dimension of the window and Y is the height of ~e window.
In the prefPrred embodiment, the digitizer printed circuit board 3ID0 is a si~ layer pnnted circuit b~ard comprising an X-Y coordinate grid. An X-grid 6û1 is formed on a first layer of the digitizer printed circuit board 301). A Y-grid 602 is formed on a second layer of the digitizer printed circuit board ts 300. As the elements of the X- and Y-grids are selectively energlzed, electromagnetic fields are esta~]ished. The magnetic coil in the stylus 165 acts as an antenna and detects these electromagnetic ~lelds as the cardholder uses it to sign the receipt.
The electrical curren~s induced in the coil by the electromagnetic 20 fields provide signals from which the position of the stylus can be derived.
Two shield layers 630, 631 form the third and four~ layers of dle digitizer pr~ted cireuit board 300. The shield layers 630, 631 are provided in order to isolate the 2s eleclronic components mounted on ~e bottom surface 635 of the circuit board from the elec~romagnetic ~lelds ~at are induced by the X- and Y- grids 601, 602, which form the ~Irst and second layers of the digi~izer printed circuit board 300. As was described above, these ~lelds are in~entionally induced in order to 30 be detected by ~e stylus as it is used by ~e cardholder to sign ~e receipt 152.
A trace layer 638 is fomled on the ~lf~ layer of the digi~izer printed circuit board 300. The elec~rical traces etched on t~e trace layer 638 provide electrical connections between the 3s X grid 300, ~he Y grid 602, and the components layer 635.
Finally, the component layer or surface 635 is formed on the ~ .
.. : .
. ~, ~ .~ ... .

.. ..
.. . ~.
.
. .. .
, , ~ ~ .! .

68 ~¢

bottom surface of the digitizer printed circuit board 300. The component layer 635 provides a surface upon which to mount all of ~he analog and digital elec~ronic components neeessary to detect and digi~ize ~he analog signal induced in the magnetic/ink S stylus as ~e X- and Y- grids 601, 602 are energized. Ihe output of ~e signature capture circuit board 300, from the board 300~
in the fo~n of X-Y coordinate pairs, are provided in ~e ~olm of digital STYLIJS POSlTION signals that are compressed, stored, and transmitted in the manner described herein.
Method for Compressing and Decompressing Signature Signals Turning now to ~IGS. 20--24, the me~od by which the signature signals are campressed and decompressed by the 15 signature capture circuit will be dlescribed. FIG. 16 generally illustrates ~he boundaries of the preferred signature capture window 160, which is positioned over the X- and Y-grids 601, 602 that are ~ormed on the digitizer printed circuit board 300.
As described above, the X- and Y-grids are formed on the top 20 two layers of the digitizer printer circuit board 300 and are operative to emit an electromagnetic pulse which is detected by the magnetic/ink stylus 16S, as it is used to sign the receipt. As the magnetic field is detected, the di~it;zer printed circuit board 300 produces serial data corresponding to the (X,Y) coordinates 2s of ~e cardholder's signature.
In ~he preferred ernbodiment of the present invention, the resolution of the X- and Y-grids is 300 dots per inch (dpi~. Inasmuch as the preferred signature capture window 160 measures 2.75 inehes by 1 iIlch, there are 825 pixels 30 arranged in ~e X direc~ion9 and 300 pixels arranged in the Y
direction. This arrangement is illus~rated in FIG. 16. `~
As described above, ~he digitizer printer circuit board 300 provides serial data representative of ~he signature in the form of (X9Y) coordinate pairs, at predetermined sample 3s times, every 10 milliseconds in the preferred embodiment.
Generally9 a signahlre is made up of a number of strokes. Each .
. ., ; .~

.
. .

2~ 2 stroke is measured ~rom the time the s~ylus 16~ comes in contact with the paper ~o the time the stylus is removed. Tlhis is determined by the pressure sensitive switch in the stylus and the CONTACT signal 615 that is provided to the digitizer CPU 610.
s Once ~he pressure sensitive switch in the stylus indicates that the cardholder has began a new s~roke, the digi~izer printer circuit board 300 provides an (X,Y) coordinate representative of the starting location of the stylus, and subsequently provides addit;onal (X,Y) coordinates at predetermined intervals or sample times until the stroke is comple~d. This process is repeated for each stroke until ~e signature is complete.
Those skilled in the art will understand that the amount of da~a used to represent the cardholder's signature directly affects the amount of memory required to store the data related to each transaction, and ~he time required to transmit the data from the transaction terminal 35 to the transaction processor's host computer 40. The present inventors believe that the amoun~ of memory required to store the signanlre data can be ~o significantly reduced by storing each stroke as a starting coordLnate and data indicating the c]h~nge ~rom each coordinate to ~e next. Thus, small changes between two coordinates may be represented by fewer bits than large changes between two coordinates.
2s FIG. 21 illus~rates the formae ~at is employed by the present invention to store the data representative of a car&older's signatu~. The compressed data for each digitized signature comprises (1) the number of strokes in dle signatur~ and (2) data associated with each stroke. The data pertaining to each stroke SpeCifleS the stroke's point of origin in relation to both the X- and Y-grids 601, 602, ~he number of (X,Y) pairs required to describe ~he stroke, and the (X,Y) pairs ~emselves. Each of the (X,Y) pairs indicates the distance and direction from the last coord;nate in the signature to ~he current coordinate. Each of the 3s elements of the compressed signature data is described below:

. : ,.. ,., ~:

r~ d~
7~

LSB 651 Least signi~lcant byte of 16 bit value indicating number of strokes in signature.
MSB 652 Most significant byte of 16 bit s value indicating number of strokes in signature.
STROKE 0 65~a Data describing the first of n strokes dlat make up signature (see S troke n Fo~mat, below).
STROKE 1 6S5b Data describing dle second of n s~okes ~at make up signa~re (see Stroke n Format, below).

STROKE n 655n Data describ;ng the last of n strokes that make up signature (see S~roke n Fonnat, below).
~o XLSB ~61 Least signi~lcant byte of offset ~rom ori~in in X directionO
~SB 66~ M[ost slgnificant byte of o~fset 2s from origin in X direction. ..
YLSB 671 Least signi~lcant byte of of ~set from origin in Y direction.
YM~B 672 Most significant by~e of offset from origin in Y direction.
COUNT LSB 681 Least significant byte of nurnber of (X,Y~ pairs in stroke.
COUNT MSB 682 Most significall~ byte of number of (X,Y) pairs in 3~ stroke.

: .
.

y~

(X,Y) PAIRS 690 Pairs of data related to each of the successive coordinates required to represellt stroke; a value 691 relating to the X-s coordinate appears :first, and is followed by a value 6 9 2 pertai~g to ~e Y-coordinate.
In order to reduce the amount of data ~equired to store each signature, ~e (X,Y) PAIRS 690 will include data in one of four formats, depending on ~e magnitude of the change between ~e previous point and ~e current pOiIlt. Each of ~e four formats comprises a two-b;t "type" code or identifier, followed by a string of bits corre$ponding to dle type of change.
When there is no change in ei~er the X- or Y-direction, the value 691, 692 of t}~Q (X,Y) PAIR 690 pertaining to that direction will be represented by two bits, which indicate a "no change" type identifier. If the change in eidler the X- or Y-coordinate is only 1 pixel, the data will be represented by three blt~ -- two bits indicate a "one pixel" change type identi~ier, with one bit indicating the direction of the change, plus or minus.
Larger changes between two coordinates will ~ stored in fo~ats requiring si~ or nine bits. Thus, it wiU be underst~od that the data represented by the (X,Y) PAIRS 690 will be 2, 3, 6, or 9 2s bi~s long, and will cross byte (i.e., 8-bit) boundaries. Each of the four fo~nats or type~ is described b~low in T~LB I: -.

- .: ~ , ; .
. ~ ,, TABLE~
00 No change from the previous coordina~e.
s 01S A change of +/- 1 pixel from ~he previous coordinate; S=0 if positive;
S=l if negative.
10SX~ A change of +2 to ~9 or -2 to -9 pixels;
S=0 if ~ositlve; S=l if negative;
(XXX+2)=change from previous coordinate.
:LlS~X~ A change of ~10 to ~73 or -10 to -73;
S=0 if positive; S=l if negative;
(XXXXXX~10)=change from previous coordinate Once the signature data is encoded in the ~bove-described compressed format by the printer CPU 580, it is transmitted to the terminal 35 as serial dat~. At t~at point, the signature data is used to process the proposed credit transaction along with ~e other data collected by the terrninal. In the 2s preferred system 25 (illustrated iri FIG. 2), the signature data (compressed signa~re signals) are stored by ~he merchant's transaction proeessor 12.
Method for Complessirlg Signature Signal~
Turning now to FIG. 22, a signature compression me~hod 710 will be described. The signature compression nnethod 710 in the preferred embodiment is implemented as computer software for the printer CPU 580 in the printer controller board 280 (FIG. 18), in response to rece;pt of 3s STYLUS POSl~ION signals from the digitizer printed cireuit board 300. Eaeh OI such sig~als consists of a pair of digital values representative ~he X and Y coordinates of ~e stylus at ~he time the sample is obtained. In dle preferred embodiment, these samples ~re provided every 10 milliseeonds.

';: " `

' Once the signature compression method 710 is invoked, it is operative to receive data associated with the card~older's signatll~ until the signature is complete, and ~o provide COMPRESSED DATA 703 signals as an output. This is 5 determined by allowing a ~rief period of ~ime between strokes during which ~he cardholder would lift the magnetic/ink stylus 165 from the signature captuIing window 160. If the stylus is not returned to the signature capturing window within a predetermined period of time, the method 710 times out and 0 determines ~at ~e signature has been completed. At ~his point, the method 710 is operative to provide a compressed signature signals as COMPRESSED DATA signals 703 from the printer controller board 280. As described earlier, the compressed signature signals contain all of the compressed data required to 15 accurately store and reproduce a cardholder's signature.
The method 710 begins at step 712, where the printer CPU 5$0 clears a stroke counter STRKCNTR, which is used to count the number of strokes that constitute the signature~
The method 7t0 dlen proceeds to step 714, whereupon 2 timer 20 STRKTMR is reset. As described more completely below, this timer times out after a predetelmined period of time and therefore indicates ~at a signature is complete.
At step 716, the method determines whether the CONTACT signal is be~g asserted by the digitizer printed circuit 25 board 300. l~e receipt of the CONTACT signal indicates that ~e magnetic/ink stylus 16~ is in contact with ~e signature capture window 16û, and that STYLIJS POSlTION signals will be e~pected at predetermined sample L~tervals. If, at step 716, it is determined ~a~ the stylus is in contact with the signa~re 30 capture window, ~e method proceeds to step 718.
At step 718, a pairs colmter PRCNTR is reset. This counter is used to COUllt the number of paLrs of coordinate signals required to represent each of the strokes that cons~itute the signature. As discussed earlier, the pair coun~er will be used to 3s provide ~he COUNT LSE~ 681L and COUNT MSB 682 data~

.

:

At step 720, the stroke coun~er STRKCNTR is incremented to indicate a new stroke. At step 722, the first coordinate pair is received ~rom the digitizer printed circuit board 300~ At step 724, this çoordirlate is stored as the origin s for that particular stroke. At step 726, the same coordinate pair is stored in a temporary storage location or register and labeled coordinate "A'1.
At s~ep 728, a next coordinate is received. At step 730, ~is coordinate is stored in a temporary storage location or 10 register "B9'. At step 732, the printer controller board determines whe~her ~e first coordinate "A~' is ~e same as the second coordinate 'sB". Those skilled in the art will understand tha~, at the sampling rate of ,100 samples per seeond, oversampling will occur and a plurali~hy of coordinate pairs may 15 be produced while the magnetic/ir~k stylus is in the same position, as when the cardholder holds the stylus against the window preparatory to signing his or her name, or pauses for some reason. If this is determined to be the case at step 732, the me~hod returns to step 728 and receives the next coordinate. If 20 at step 732 it is determined tha~ the coordinate "B" is not identical to coordinate "A", ~e me~thod proceeds to step 734.
At step 734, the printer CPU 580 receives the next coordinate pair ~rom the digitizer prineed eircuit board 300. A~
5tep 736 this coordinate pair is stored in a temporary storage 2s location or register "C". At step 73$, ~e printer CPU again determines whether oversampling ~as occurred by deteImilling whe~er ~e coordinate "B" is iden~ical to ~e eoordinate "C". If so, the method returns ~o step 734 and reeei~es the next coordinate. If at step 738, ~e printer CPU determines that the 30 coordinates "B" and "C" are not identical, the me~od proceeds to st~p 740.
At s~ep 740, the method 710 is operative to further compress the daea by removing data corresponding to extra coordinate pairs that may be located in horizontal or vertical 3s lines. Generally described, the medlod of removing lines is accomplished by detennining whether a plurality of points form a line and, if so, simply subsequently specifying the line by its end points and deleting any coordinates located in the center section of the line. Thus, at step 740 ~he method 710 dete~nines whether the portion of the stroke represented by the three points "A", "B", s and "C'9 form a vertical or horizon~al line. If not9 the method advances to step 742.
At step 7 4 a the printer CPU determines the di~ference between the first coordinate position signal "A" and ~e second coordinate position signal "B", inasmuch as it has now 0 been detelmined ~at the~e is a change in position of the stylus.
As was described above, the data format representative of the ch~ge ~etween ~e poiD~s "A" and "B" is determ~ned by the difference between ~e two points. Thus, ~is me~od is opera~ive to foml the data denominated (X, Y) PAIRS 690 by dete~nining the magnitude of the change for each coordinate X and Y for the data pair "A" and "B"9 and assl~ing the appropria~e code as set forth above in TABLE I.
Once the data reprlesentative of this pair is determined, ~e method proceeds to step 746 whereupon the pair counter PR(:NTR is incremented. At step 748 the method prepares to determine the next segment of the line by replacing the value in ~e '~A" register with the value in the "B" register.
Then at step 750 ~e value in the "B" register is replaced with the value in ~e "C" register.
2s At step 7529 the printer CPU S80 is operative to de~ermine whether dle magnetic/ink stylus 165 remains in contact wi~ the signature capture window 160 by monitoring the CONTACT sigrlal and the SIYLUS POSmC)N signals. If a~ step 7~2, dle printer controller board determines ~at ~e stylus is still in contact with dle signature capture window, ~e method retu~ns to step 734 and receives the ne~t coordinate.
Rehlrning now to step 740, if ~e prin~er controller boasd determines that the por~ion of the signatNre stroke formed by the points "A'9 asld "C" ~orm a lLine, the medlod advances to 3s step 754. At this step, the compression method 710 effçctively deleees ~e midpoin~ in the line and replaces it with ~he current .
, .. .

' . . .

76 ;~ b~

end point by replacing the value iIl the register "B" with the value stored in register "C".
If at step 752, the pri~er CPU determines that it is no longer receiving coordinate values from the digitizer printed s circuit board, the method 710 inalizes and s~ores the data associated with the current stroke and prepares to receive coordinate values associated with any subsequent strokes.
At step 756 the method 710 determines the di~erence between ~e points represented by ~e culTent values of the registers "A" and "B". At step 7589 this data is stored as (X, Y) PAIR~, 690 according to TAE~LE I. At step 760, the method increments ~e counter PRCNTR. The value of the counter PRCNTR represents ~e number of (X, Y) PAIRS 690 required to represent that stroke.
The method then proceeds to step 762, whereupon the printer controller board is operative to provide all data associated with that stroke in the form prescribed for each stroke 65~ of the compressed signatu~e signals. At ~is step, the method returns to step 714 and prepares to receive any coordinate data associated with subsequent strokes. As discussed earlier in conjunction wi~ dlis step, the timer STRKTMR is cleared and is therefore oper~tive to de~ermine whe~her ~e signature is complete. A~ step 716, dle printer CPU determines whether the stylus has again come in contact wi~h ~he signature capture 2s window. If not, ~e me~od proceeds $o step 764. I at step 764, t~e timer STRKTMR has not yet reached the predetermined value, the method retums to step 71~. However9 it at step 764 the timer has reached the predeten~ined value, the method proceeds to step 766.
At s~ep 76C, the printer CPU 58û has determined th~t the signature is eomple~e and ~hat data pertaining to each of ~e strokes ~at constitute ~e signature has been received. Thus, at step 766, the printer CPIJ is operative to provide the compressed signature signal as C~:)MPRESSEI) DATA signals consistent wid~ ~e ~ormat described hereina~ove. Once this is accomplished, dle method te~nînates.

'.rD ~

Method îor Decolmpressing Signature Signals to Retrieve and Reprodllce Sigrlatllre It will now be understood that the compressed s signature signals are associa~ed with other transaction information and ~ransmitted to ~he transaction processor's host computer system 40 when the p~:~elTed terminal con~nunicates with the host for requesting an authorization. lhe host system 40 stores the transaction informatîon and compressed signature signals for la~r use and retrieval in ~e data storage facility 64.
Should it become necessary for the transaction processor to provide a ~acsimile of the cardholder's signahlre, the signature may be reconstructed by deeompressing the signature data a~d thereby reversing the process described above. Those skilled in the art will understand tba~ the process of decompressing the compressed signature data comprises steps similar to those employed ~or compressing the signature signals, e~cept that ~e steps are taken in the reverse order. Thus, each stroke of the signa~ure will be drawn by starting at the origin as represented by the data XLSB b6l, XMSB 662,. YLSB 671, YMSB G72 (FIG. 21), and providing the subse4uent points as represented by the data COUNT LSB 681, COUNT MSB 6~2, and (X,Y) PAIRS 690. Each strc)~ is re-drawn in ~his manner until the ~acsimile of ~e desired signature is complete.
As an aid to unders~rlding the method carried out in ~e present invention for compressing and decompressing the signa~ure signal, refer now to FIG. 23 ~r an illustrative example. FI~ 3 illust~tes dle signature capture window 160 wi~ two e~emplary strokes 655a, 655b superimposed thereon.
The beginning and ending of each segment of the strokes 655a, 655b corresponds to the points labeled Pl ~rough P5, and P6 through Pl 1, respectively. A strirlg of hexadecimal-coded COMPRESSED DATA 7Q3 represents ~he two strokes 6~S~, 655b after the two-stroke "signatu~" in dle window 160 has been subjected to the preferred signa~ure compression method.
The da~a values 6~1, 652 (0200 H, least s;gnificant by~e first) ~-$~

represent ~he number of strokes in the "signature" (which is two), as per FIG. 21, while ~e data values 661, 6~2, 671, 672, 681, 6$2 and 690 represent the other data parameters discussed in comlection with FIG. 21, with the (X, Y) pairs for the two S strokes represented by 690a arld 690b.
FIG. 23 also illustrates the binary equivalent values 707a, 707b corresponding to the hexadecimal compressed data 690a and 690b, represe~tative of the two strokes 655a, 655b af~er they have been compressed according to the method described above.
Tuming now to FIG. 24, ~e method 800 by which the prefelTed system decompresses ~e compressed signature data will be described. l~is meehod will be described in ~e context of ~e strokes 655a, 655b and corresporldirlg compressed data string 703, 707 appearing in FIG. 23. It will be understood thae the steps of the method for decompression are preferably carriPd out as steps of a compu~er program 42 for the host computer 40 of a transac~ion processor 12 in the preferred data card transaction system 2 (see FIG. 2), inasmuch as signature decompression and reproduction will most often take place at a transaction processor when it is necessary to e~ctract a si~p~ature associated with a givell transaction. T~us, or purposes of discussing FIG. 23, it will be assumed dlat ~e decompression is taking place at a decompressor 42, which will typically will be a host computer 40 of a 2S ~ansaction processor.
The me~od begins at step 802 in FIG. 24. As an initial step, the decompressor 4~ determines dle number of strokes ~at make up ~e ~aesimile of dle cardholder's signature.
This as accomplished by readi~g ~he value3 LSB 6~1 and MSB
s5a from ~e data string 703 of FIG. ~3. In the example, the rst ~our hex characters 651, 652 indicate that the number of strokes is 0~ 00 (hex, LSB ~lrst). O11Ce ~e number of strokes included in ~e signature is determined, dle method proceeds to step 805.
3s At step 805, the deeompressor 42 clears a s~roke couIlteF STRKCNTR and proceeds ~o step 807. At this step, the , .; ; . .

decompressor 42 reads ~he first data segment 655a associated widl the first stroke, STROKE 0. The first data element recorded for each stroke is an X offset, wh;ch is represented by the variables XLSB 661 and XMSB 662. Together, these variables s prescribe t}~e offset from ~e X origin. In the e~ample, the next four he~ characters 661, 662 indicate that the first coordinate is located at a point OAOO (he~, LSB first) pi~els from the X origin.
A~ step $10, ehe decompressor 42 reads the values that speci~y ~
Y offset9 YLSB 6~1 and YMSB 672. The data of the example lo 65~a places the first conrdinate at a poine 0001 (he~, LSB first) from the Y origin. Once ~e starting origin ~or the initial stroke STROKF~ O is determined, ~e medlod proceeds ~o step 812.
A~ step 812, the decompressor 42 looks to the variables COUNT LSB 681 and COUNT MSB 682 to determine lS the number of (X,Y) pairs that are stored to represent that particular stroke. The hex characters 6$1, 682 of the example in FIG. 18 indicate that there are 0400 (hex, LSB first) pairs of (X,Y) coordinates associated with the first stroke 655a. Once the number of pairs is determined, the me~od proceeds to step 815 20 and moves to the initial stroke's origin poine as determined at steps 807, 810. In nG. 23, the first coordinate of the stroke 65~a is at the point labeled Pl.
At step 817, the decompressor 42 clears a pair coun~er PRCNTR, and proceecls to s~ep 8 2 0, where the 25 decompressor reads the first (X~Y~ pair 690a. Once the (X,Y) pair is read, ~e method is operative at step 822 to cause a line to be drawn between the starting point Pl and the point represented by dle (X,Y3 pair, which is P2. ~ ~e e~ample, the X element 691 of ~e (XtY) pair 690 is 00, dlùs indicating ~at there is no 30 change in the X coordinate. The Y element 692 is 011, indicating ~at the second coordinate i5 (-1) from the first coordinate. Thus~ ~he second point, which is labeled P2 in FIG.
23, is directly above the ~st coordinate Pl.
Those skilled in the art will understand ~hat the 35 "drawing" Qf the line from point Pl to P2 associated wi~ step 822 may be on a display device such as a CRT (ca~ode ray tube) , .: . ,." :, ...

or o~er screen associated with a terminal connected to the host computer or other decompressos 42, or may be on a printer so as to obtain a hard copy of ~e reproduced signa~u~.
Once a point is ~ead and drawn, the method advances S to step 825, where dle counter PRCNTR is incremented. At step 8Z7, the value of PRCN~ is compared to the nurnber of (X,Y) pairs read from the variables COUNT LSB and COUNT MSB
681, 682. If the PRCNTR is less than dle number of pairs expec~ed, the method returns to step 8 2 0, where the 10 decomp~ssor 42 reads ~e ne~t (X,Y) pair 69~. The steps 820, 8 2 2, 825, 827 are repeated Imtil all of the (X,Y) pairs associated wi~ ~e iI~itial stroke STROKlE 0 are read and drawn.
Once this is accomplished, ~e value of ~e variable PRCN~ will be equal to the number of (X,Y) pairs expected in the initial 1S strol;e STROKE 0 65$a, and the d~ecompressor 42 will branch to step 830 from step 827.
At step ~30, the decompressor 42 increments t'ne stroke counter STRKCNTR, which counts ~e number of strolces drawn. The incremented value of this eounter STRKCNTR is 20 tested at step 832. If the value is less ~an ~e mlmber of strokes in dle signature, ~e medlod returns to s~ep 8û7, where the data associated with ~e next stroke, STROKE n, is read and ~e stroke is drawn. When~ at step 832, the value of the stroke counter variable STRKCNl~ equals ~ nu,mber of strokes e~pected, as 25 represented by the data values 651, 652, dle method proceeds to step 835 and te~ninates.
It will now be understood that there has been de~cribed a me~od for digitally encoding a graphic object, such as a siglrlature, provided in the fo~n of coordinate position signals 30 ~om a graphic digitizer and for providin~ compressed graphic object signals, comprising first de~ermining a number N of strokes ~ the graphic object, a stroke being determined by an initial s~arting coordina~e provided in response to a stroke star~ed signal and a ~mal coordinate provided in response to a stroke 35 completed signal. For each s~oke of ~e N strokes in the graphic object, output signals are dete~nined by receiving a first , ~ ~

~ ~ r;~ t~ 1 2 coordinate position signal corresponding ltO a first sample time, receiving a second coordinate position signal corresponding to a second sample time subsequent to the first sample time, and determining the dif~e~nce between ~e first coordinate position signal and the second coordinate position signal. The COMPRESSED DATA output comprises providing an a bit digital code as ~he output signal if dle di~rence is less than a first predetermined value, and providing a b bit digital code as ~e output signal if the difference is greater than the first predete~nined value but less than a second predetermined value, where a is less than b.
The fo~egoing steps are repeated ~r a plurality of sample tirnes, thereby providLng a plurali~y of coordinate position signals between the initial starting coordinate and the final coordirlate. The COMPRESSED DATA signals comprise the number of strokes N and the digital codes for each stroke.
More particularly, there has been described a method for digitally encoding a grapnic object, such as a signature, provided in the form of coordinate position signals from a graphic digitizer and ~or providing compressed graphic object signals, comprising the steps of filst determining the number of strokes in the graphic object, a stroke being determined by an initial star~ing ccordinate provided in ~esponse to a stroke started signal and a final coordinate provided in response to a stroke 2s completed signal. An X o~fset from ~he origin of a coordinate system to t~e initial starting coordinate of a given stroke of the graphic object is then determined. A Y offset from the origin of ~e coordinate system to the initial starting coordinate of the given st~oke oî ~e graphic object is then ~etermined.
Next7 the number of (X,Y) pairs in dle given stroke is determined, each (X,Y) pair corresponding to a coordinate position si~nal provided at one of a plurality of sample times bet:ween the stroke started signal and ~e stroke completed signal.
An X-output signal and a Y output signal are provided 3s corresponding to the difference between a first (X,Y) pair at a ., . ~
.
. ~ , .................. .

p~

firs~ sample time and a second (X,Y) pair at at subsequent second sample time, each outpu~ signal compnsing:
an a bit code if there is no change in the respective coordinate between the first (X,Y) pair and the second (X,Y) p~
a b bit code if dle~ is a change of g picture elements in the respective coordinate between ~e first (X,Y) pair and the seconcl (X,Y) pair;
a c bit code if dlere is a change of between g~l and k 0 picture elements in the respective coordinate between ~e ~lrst (X,Y) pair and ~e seeond ~X,Y) pair; and a d bit code if there is a change of between h~l ~nd i picture elements in dle respective coordinate between dle first (X,Y) pair and the second (X,Y) pair.
Next, for each stroke, the X-offset, the Y-offset, a count of the number of (X,Y) pairs, the X-output signal, and the Y-output signal are provided to represent the graphic object.
Preferably, a ~ b ~ c < d, ~nd in ~e preferred embodiment a=2,b~3,c=6,andd=9,andg=l,h=9,andi=73.
Methods o~ Operation of Pre~erred Terminal/Printer General Method for Operatioll o~ the Preferred Terminal ~ Main Program Flow 2s It will be recalled that one of ~e plincipal objects of the pre~ent invention is ~o provide improved me~hods and apparatus for facilitating the provision of chargeback protected data card tra~sac~ion services, grom a transac~ion processor to a mer~hant. ~n ~e preferred esnbodiments, ~e provision of such 30 chargeback protection ser~rices is ~acilitated by detecting predetermined charaeterist;cs of a given ~ata card transaction indicative of the validity of the transaction9 in particular, detection of the physical pr~senee of a data card in connection with the given tranaction. Transaction processors who utilize 35 terlrlill~S such as ~e preferred terminal~prin~er 30 rnay elect to provide char~eback protection services to merchan~s who contract ', ' o5~

for ~ransaction processing services, since use of the preferred terminal provides additional ir~ormation concerning the data card used in coImection with a transaction. This additional information, namely, information ~rom both tracks of the data card, in~olmation from ~e embossing on ~e card, and digitized in~ormation corresponding to ~e signature of ~e cardholder in connection with a transaction, provides ~e transaction processor w;th a greater degree of con~ldence that a given transactioll is a valid one, so that the tr~saction processor may elect to assume 10 ~e risk of the particular transaction on behalf of a merchant.
It will therefore be understood dlae the present invention includes novel methods for providing chargebaclc protection in connection with pasticular data card ~ransactions. I~
order to provide a transaction processor with the greatest S con~ldence of ~e validity of a given transaction, it is of course preferable that all information that can be obtained from ~e card itself and iFrom the cardholder be captured and electronically associated with the transaction data in a convenientl compact~ and readily transmissible form. However, it will be unders~ood that 20 not all items of information may be required by a given transaction processor for all its transactions. For example, a tr~sa~tion processor may decide to assume greater risk in connection wi~ certain types of tra;nsactions.
Thus, for purposes of explaining the pre~erred 2S mode~ of the pre~ent inven~ion, the operation of the preferred terminal/prirlter 30 will be described in connection with obtaining in~onnation from both tracks of ~e magnetic stripe of a data card, infonnation from ~e ernbossed area on ~e data card, authorization indicla from an authorization ~ou~ce, and a 30 signature associated with the transaction. It will then be understood ~at ~ese various items o~ information may be combirled in a manner chosen by the t:ransaction processor, in implementing chargeback protection and other services as desired.
3~ Those skilled in the art will appreciate ~a~ in ~e preferred terminal 35, as in prior a~ terminals, the specific ; . , ~
;
.

terminal operations are governed by a variety of parameters that are stored within the terminal, and software that is operative on the terminal. GeIlerally, ~hese parameters and their corresponding operatiolls ~all into two categories -- those which S may be changed or altered by a user (typically a merchant), and those that may be altered only by the transaction processor 12.
For e~ample, in the preferred terminal, the merchant may utilize a terminal se~-up routine to corltrol the types and forma~ of reports ~hat a~ printed regarding ~e merchant's transactions. In 0 addition, ~e terminal allows the merchant detelmine greetings and other information that will be printed on the receipt.
Examples OI parameters ~hat are controlled exclus;vely by ~he transaction processor include the types of data cards that the terminal will accept, the telephone numbers ~at the lS terminal will dial to reach various transaction processor host computers, audlorization sources, the ARU9 etc.
Those skilled in dle art will appreciate that a terminal constructed in accordarlce wi~ the prefe~red embodirnent of the present invention will include at ]least three unique parameters that are cantrolled exclusively by the transaction processor. LT1 the pre~erred embod~ent, ~ese parameters are indicated by the s~a~e of certain trans~c~ion processor data items or flags s~ored in the tenninal's memory. These flags may set remotely during a download routine for COIlfig~g the terminal ~or operation, or ~5 alternative~y may be set "at the factory" prior to delivery of the terminal to ~e merchant.
The preferred transaction processor flags include a "signature capture flag" which is op~ra~e to deteImine whe~er the signature will be captured by the preferred signature capture printer 38. The transae~ion processor flags also include an "embossed reader flag" alld a "ehargeback protcc~ion flag".
When set, the embossed reader flag indicates that the embossed eard reader 112 of ~e prefe~ed terminal 35 is aetivated and operable.
Likewise, ~e chargeback protection ffag is operative to indica~e tha~ the merchant has engaged the transaction .
. "
.. .

2$~

processor to provide transaction processing services that include the chargeback protection services. ~Iowever, unlike the signature capture flag and the embossed data reader flag, a separa~e chargeback protection flag exists wi~in the terminal for S each of the credit cards ~at may be accepeed by the terminal.
Thus, i~ is possible for the transaction processor to provide chargeback protection to a merchant in conjunction with some specified data cards, and to provide conventional transaction processing services to the same merchan~ with respect to other 10 data cards.
Those skilled in ~he ar~ will understand that the tenninal parameters uniquely COIlfigllre ~e terminal. As a result, the terminal parameters, in conjlmction with a specific transaction, are operative to detennine the speci~lc data that are 15 sent to the transac~ion processor hose computer during a credit card processing transaction. In ~e preferred te~ninal, ~e state of ~e embossed reader flag and chargeback protection flag, in conjunction with the nat~ire of t.he data used to process the transaction, determine whether a "guarantee" or "transaction 20 pro~ected" flag is set when ~e ~ransaction data is sen~ to the host for processing. The presence of ~he transaction protected flag indicates that the traIlsactioII data relates to a transaction that is chargeback protected.
In the pre~lTed embodiment, the states of each of 2s the aorsmentioned flags may be illustrated by the following TABL~

, - . :

::: ' ~ '.

8~ .

ERF - Embossed Reader Flag (set or cleared by transaction processor) CPF - Chargeback Protection Flag (set or cleared by transaction processor ~or each card type) GUAR - Transactioll Protected Flag, in~dicated transaction is guaranteed (based on ERF9 CPF and type of transaction) - (set ox cleared for each transaction in the terminal) ~E Ç~ ~
&roup 1 Y Y Y Magneticstripe da~a entry Y Y Y Embossed reader data entry (when magnetic stripe reading fails) Group 2 N Y Y Magneticstripe data entry N Y Y Mam~al data en~y (whenmagnetic stripe data entry fails) Group 3 Y N N Ma~g~eticstripedata entrg Y N N Embossed reader data entry (when mag skipe fails) Y N N Manual dataentry (whenmagnetic 2s stripe and em~ossed reader ~ail) Group 4 N N N Maglletics~ripedata entry N N N Manrlal en~ry (whe~ magnetic stripe data entry fails) In the preferred te~minal, as ill terminals constructed according to the prior art, the parameters that are within the exclusive control of the transaction processor are downloaded *om the transaction prosessor to each terminal. This may be 3s accomplished in one of two ways; it may be accomplished before the terminal is deployed to the merchant, or the data may be . , .
. . . . :
, ., - : ~ . .... .

J~ ~ ~

~ownloaded ~rom the transaction processor to the terminal via a telephone line.
From the information i:ncluded in TABLE II, it should be understood that when a mercha:llt has engaged a s transac~ion processor to provide only conventiollal non-chargeback protected transaction processing services, the chargeback protection fla~g will be cleared (set to "N") by the ~ransaction processor, either du~ng con~iguration of the terminal or remotely during a configuration download. As a result, none of the merchant's transactions will be flagged as char~eback protected (i.e., the terminal will never set the tr~nsaction protected flag to s'Y").
In the same manner, whenever a merchant has engaged a transaction processor to provide chargeback protected transaction processing se~vices, the chargeback proteetion flag will be set to " Y" by the transactio:n processor. In order to more completely understand the present invention, a discussion of the two portions of TABLE II where the ohargeback protection flag is set to "Y" is appropriate.
In the first group ~Group 1), ~he chargeback protection 1ag and embossed card reader flag are both set to "Y".
When this is the case, the merchant is expected to obtain the card identi~ying data directly ~rom the card's magnetic stripe or embossed characters. I~us, there should be be no manual entry 2S of the card identifying information, and all of the merchant's t~ansactions should be chargeback protec~ed (i.e., the transaction protected flag will be set to "Y" ~or each of the transactions)O
Those skilled in the art will appreciate that mail order/telephone order (MOTO) transac~ions will not be chargeback protected regardless of the sta~us of ~he chargeback protection flag, since a card is not present, ~rld the data must be entered manually by the merchant.
In the second group (Group 2), the chargeback protected flag is set to "Y" and the embossed card reader flag is set to "N". In the prefelTed embodiment of the presen~ invention, this status will occur only after ~he embossed card reader becomes , inoperative, a1ad the transaction processor has been notified of the failure. The preferred embodiment is operative to notify the merchant of a malfunction in the embossed card reader via the LCD 123, a~d ~o prompt the merchant to call the transaction s processor. The tra~saction processor will then be apprised of the malfu~ction and order that a replacement embossed card reader be sent to the merchant, or take other remedial steps such as repair ~he embossed card reader.
The eransactiOn processor may elect, at its option, to conti~ue to provide chargeback protected transaction processing services to merchants in the event of a failure of the embossed card reader ~or the benefit of its merchants/customers, although doing so will require that the merchant enter card identifying data mamlally in the event the card swipe fails. This aspect of the present invention is described more completely in conjunction with FIG. 28.
It will be appreciated that the transactions shown in Groups 3 and 4 are not chargeback protected.
Turning now to FIG. 25, the preferred method 850 for the initialization and operatic~n of the terminal will be described~ This method is implemented as software ~or the terminal's CPU 255, and is stored :in the program memory 258 associated with ~he terminal. Ge~erally, the method 850 is operative to initialize the terminal 3~ upon power-up and determine whet~er the terminal is properly con~igured. If not, the termi~al initiates a download request. Once the tenninal is properly con~igured, the method 850 causes the preferred terminal to enter a main loop or "idle" state from which the terminal may be instructed ~o execute a variety o ~unctions.
The preferred method 850 begins at step 8~3 when power is applied to the termi~al. At this step, the terminal determines whether it has previously received the proper :

,: ~

parameters and application software from the transaction processor. If not, the te~ninal will detect that i~ needs to re~uest a download and will branch to step 85S. It will be recalled from earlier discussion that the telminal's memory 258 comprises read s only memory ~RO~vI) for system code storage, and random access memory (RAM) for both applications program storage and data storage, including storage of transaction da~a and compressed signature signals. The systern code is operati~e to carry out the download routines3 if necessary, while applications programs 0 (which utilize the flags discussed above) are stored in battery backed up RAM.
At s~ep 85S, the terminal is operative to prompt the merchant to initialize a download request, for e~ample by displaying a message on the LCD 123. When a download request 5 is ini~iated by the merchant, by invoking a predetermined keystroke combination, the ternninal dials a predetermined telephone number associated with a download host computer that is operated by dle transaction processor.
Once the communication is established, the teIminal 20 sends a download re~quest. At step 857, ~e terminal receives the appropriate download parameters (including ~e CPF and ERF, if applicable) and application software from the transaction processor. Those skilled in the ar~ will apprecia~e that the download parameters sent by the transaction processor are 2s determined according to the nature of the agreement between the mercharl~ and ~e transaction processor and the services provided ill connection wi~ ~at agreement.
At step 860 the terminal stores $he received parameters and proceeds to step 862 where the terminal en~ers 30 the main program loop.
If at step 8~3, the terminal determines that the proper parameters are resident in the terminal and that a download is not required, the method 850 branches to step 862, whereupon the termillal enters the main loop or idle state. Those 3s skilled in the art will underst3nd that it is from ~is main loop that ~e terminal may be instructed to carry out any of a variety of : -functions. For example, from dle main loop, ~e terrninal may beinstructed ~o initiate, ~or example, a credit sale authorization transaction 900. A credit sale authorization transaction 900 is initiated when a magnetic card 15 is swiped through the swipe s slot 103, or by the activation of one of the buttons on the ~erminal's keypad 120. The credit sale authorizat;on transaction 900 is discussed more completely below.
In addition to the rnethods associated with the completion of a credit sale trcmsaction, those skilled in ~e art will 10 underst~d that both ~e preferred terminal cmd other prior art terminals are capable of per~rming a close terminal routine 932.
Generally described, a close te~ninal routine is performed at predetermined intervals, and eomprises s~eps wherein the terminal transmits all data related to transactions occurring 15 during a predetermined accounting period to the transaction processor.
Other functions which may be accessed -from the main loop 862 include a terminal set-up routine 865. As described briefly above, a termi~al set-up routine is typically 20 operable to allow a merchcmt to determine the nature and format of reports provided by the terminal., the text of messages that may be printed on the receipt, etc. 'Those skilled in the art will app~ciate ~at there are a variety of other func~ions common to pnor art terminals ~at may also be implemented in the preferred 2s te~inal, and will not be discussed further herein.
U~e o~ Pre~erl ed Terminal ill Conne~tion with Chargeback Protection Method FIG. 26 illustra~es a rne~od 900 ~at is executed by 30 ~e preferred ~erminal/printer 30 during an e~emplary credi~ sale au~horization transaction. The method 900 is preferably implemented as program steps for ~e te~ al CPU 255.
This e~Eemplary credit sale authorization transaction is carried out within the context of the preferred data card 35 traIIsaction system 25 constructed in accordance with FIG. 2.
Such an exemplary credi~ sale is processed with transaction data :
.~

5 G~?~

capture by the terminal/printer 30, with authorization from an authorization source such as a host computer 40, and subsequent ~ransmission of transaction data including compressed signature signals to the host 40. (It should be understood that while the S host computer 40 in FIG. 2 is providing both authorization functions and trallsaction data processing functions, the authorization system and the transaction data processing system could be separate and independent systems.) A credit sale authorization tra~saction is selected 10 when the merchant desires to authorize a transaction and capture the transaction data simultaneously. When the transaction is authorized by the host computer 40, the transaction data will be captured by both the terminal 3S and the host computer 40. The method 900 is operative to insure that ~he data card is present9 ls that the proper transaction data is collected and retained, and that the transaction qualifies for chargeback protection.
In FIG. 26, the method 900 begins at step 901 when a credit sale authorization transaction is initiated by the merchant, in respo~se to presentation of a data card by a cardholder in connection 20 with a proposed transaction. This typically occurs when a credit card lS is swiped through the card swipe slot 103. At this step, a transaction record for the transaclion, in which transaction information is stored for subseguent transmission to the host computer 4û, is created. It will be understood that the transaction 25 record will include ~he transaction protected flag set in accordance with t~e state of the chargeback protection flag (CPF). The state of the transaction protected flag can also be conditioned upon whether or not an authori~ation has been received, as well as the nature of the authorizatio~ indicia received (such as whether the authorizaton 30 indicia is elec~ronic authorization or off-line authorization~, at the discretion of the transaction processor.
It will therefore be appreciated that at this step the transaction protec~ed flag is determined and stored with other transaction data in a transaction record, for transmission to the 35 transaction processor.

?

: ,. ~ ~ ' ' ` .

t--~a~

If the card is not present at the time of the transaction, as would be the case in the event of a mail order or telephone order (MOTC)) transaction, the merchant may manually enter the account number from the keyboard and complete the s transaction. HoweYer, a MOTO transaction, where the card is no~
present, will not be chargeback protected (i.e., the transaction protected flag is cleared) since the evidence indicative of the validity of the transaction (e.g., the card is physically present and a signature is captured) is simply not available. Such transactions, 10 being of a conventional nature, will not be discussed any further.
At step 905, a subroutine 90S denominated READ
CARD DATA is executed. The READ CARD DATA subroutine 905 determines the account number and expiration date of the credit card. Generally, the preferred method attempts to reduce 15 the likelihood of chargebacks by reading the account number and expiration date from the most rsliable source available, which is usually the magnetic stripe. Thus, the READ CARD DATA
subroutine 905 first attempts to read the account number and expiration date ~rom the card's magnetic stripe. If reading the 20 magnetic stripe is unsuccessful, the terminal prompts the m erchantto insert the card into the e m bossed card reader 112 by displaying a message on the LCD 123. Once the card is inserted into the embossed card reader, the terminal 30 attempts to read the account number from the characters that are embossed on ~he 2s card. The READ CARD DATA subrouti~e 905 is discussed in m ore detailin coD~nection with FIG. 28.
I~ should understood at this juncture that the disclosed steps of reading the magnetiç stripe first and prompti~g ~or insertion of the card into the embossed card reader only in the 30 event of ailure of the magnetic stripe are pre~e~red steps. Other embodiments of the invention contempiate usage of ~he embossed card reader in connectioll with the transaction regardless of whether the magnetic stripe was successfully read or not.
Subsequent to execu~io~ of the READ CARD DATA
35 subroutine 905, the terminal/printer 30 performs steps to detennine whether the account number associa~ed with the card is ~ .
.. , ;
: .

valid (with the known checksum calculation) at step 907, whether the card type is one that may be accepted by the merchant (i.e., whether the terminal accepts a given issuer's card) at step 911, and whether the card has expired at step 913. If any oie the steps s 907, 911, 913 result in a negative answer, the transaction will be tenninated and the subroutine will return to the idle state in FIG. 25 (the main loop).
Once the account number and expiration date are determined to be valid, the method 900 proceeds to step 918. At 0 step 918, the INPUT AMOUNT subroutine is executed.
Generally desoribed, the INPUT AMOUNT sulbroutine 918 prompts the merchant to enter the proposed purchase amount with the keyboard 120. The purpose of the subroutine is to obtain a proposed purchase amount ~rom the merchant and to 15 rehlrn that value.
The subroutine 918" which is not separately illustrated, causes the terminal's liquid crystal display 123 to display a message instructing the merchant to "ENTER
PURCHASE AMOUNT" into the keyboard 120. The program 20 then waits ~or the merchant to enter a number corresponding to the purchase amount. Once this number is input, it exits the INPUT AMOUNT subroutine 918 and returns control to the program 900.
After collecting the account number, expiration date, 2~ and proposed purchase amount, the terminaVprinter 30 executes step 921, whereupon the signature capture printer 38 prints a portion of the sales receipt, typically a header portion. The portion of the receipt that is printed includes the date and time of the purchase, the account number, expiration date, purchase 30 amount, and a line ~or the cardholder's signature. The signature capture printer 38 ~hen advances the paper until the line for the signature is positioned over the signahlre capture window 160 located Oll the signature capture printer 38.
Afl;er printing the first portion of the receipt at step 3S 921, the terminal/prirlter 30 executes step 923 and jumps to a subroutine denominated CAPTURE SIGNATURE. As described ~ . . . . ..

r ~ ~?

earlier, the cardholder uses a magnetic/inlc stylus 16S to sign the receipt on the signature capture window 160, which covers the printer's digitizer printed circuit board 300. The CAPTURE
SIGNATURE subroutine 923 is operative to digitize and s compress the signature and transmit the compressed signature signals ~rom the signature capture printer 38 to the terminal 35, where it is temporarily stored. The CAPTURE SIGN~TURE
subroutine 923 is described more fully in conjunction with FIG.
~9.
Once the signature is transmitted to the terminal 35 and stored in memory, the terminal/pri~ter 30 proceeds to step 926, where upon a REQUEST ~UTHORIZ~TION subroutine is executed. At this point, the terminal 3S attempts to dial the transaction processor's host computer 40 in order to request 15 authorization for the transaction.
It will be understood that, in the preferred embodiment, once the connection with the host is established, all of the data associated with the transaction (includiIlg compressed signature) is transmitted to the host computer 40. If the 20 transaction is authorized, an authorization number or indicia is returned to the te~minal and the R]EQUEST AUTHORIZATION
subroutine is complete. If the transaction is not authori~ed, the transaction is terminated. The REQUEST AUTHORIZATION
subroutine 926 is discussed in more detail in conjunction with 25 FIG. 30.
At step 929, the signature capture printer 38 is made to print the remainder nf the sales receipt, which includes the authorization number received from the host computer. The program then proceeds ~o step 930 and jumps to a STORE
30 D~TA subroutine. Generally described, the STORE DATA
subroutine 930 causes the terminal to store the data related to the transaction. This subroutine is described in more detail in conjunction with ~IG. 31.
Once the terminal stores the data, the credit sale 35 authorization transaction routine 900 is complete and returns t~

control to the main loop or idle state in FIG. 25, awaiting further transactions.
Restoring Track 1 Data with Track 2 Dat~
s It will be recalled from earlier discussion that many card issuing instihltions, such as VISA~ and MasterCard~, promulgate regulations gos~erning the manner for handling transactions associated with their card(s). If a merchan~, transaction processor, or other presenter ~or payment does not 0 give evidence of compliance with ~he reglllations, transactions presented for payment may be refused or returned, resulting in chargebacks to the merchant or other presenter.
Individual card issuers have historically been responsible ~or payment of transactions accompanied by evidence of a card presented in connection with the transaction, with a check-digited account number containing an identifying prefix assic3ned to them by a card issuing association.
In an effort to reduce fraudulent uses of accoun~
numbers, card associations began requiring encoding of info~nation on the back of the plasl~ic card (via a magnetic stripe) as well as embossing of the ~ont of the card. Present day data cards include a plurality of tracks on the magnetic stripe, generally referred to as "~rack 1~ and "track 2". Originally, only track 2 of the magne~ic stripe was required to be encoded with information. Accordingly, prior art tenninals were created with the ability to read only inormation in track 2 of the magnetic stripeO
Current regulations generally require that information be encoded on both tracks, as shown in FIG. 27. It will be noted that the iDformation on track 1 includes all of the information required on track 2 and includes additional information such as the cardholder's narne and expanded '~discretionary data". More recently, da~a card processing terminals have been designed to allow reading of track 1 in~ormation or, optimally, to read the contents of both maC~etic tracks.

,. - .
.~ ~

$. Y g-Card association regulations allow some protection for transactions where "proof" that the account number was electronically read (rather than manually entered) can be provided (i.e., indicators that the the authorization request has s been generated from the magnetic stripe data~, or alternatively where an impression (imprint) of an embossçd card can be produced to "pzove" that a card bearing the account number was actually presented for payment. Chargeback protectiorl is limited to certa;n disputes regarding the validity of the account n~mber, 10 and issuers can obtain "counterfeitn loss protections for items paid on counterfeited cards.
Due to ~he skill of counterfeiters in producing properly embossed and encoded cards, issuers have set in motion plans to imbed a code in the discretionary data area of the 15 magne~ic tracks that can be used to validate the encoding, using a "secret" algorithm known only to the issuer or association acting on behalf of the issuer. These plans will eventually require that the entire magnetic stripe track be captured and transmitted to the issuer/card association for validat;on during the authorization 20 process. Transactions not meeting tbis criteria may, in the future, when the ability to validate these "card verification values" is fully impleme~ed, be subject ~o chargeback by the issuer.
In light of ~his trend, the abi~ity to read both tracks on a card's magnetic stripe, and to be able to restore information 25 where only a small da~a area is damaged, is desirab~e. Proposed regulations require that either track be read and transmitted with the authorization request; track 1 in~ormation, allowing capture and printing of the cardholder's name and transxission of more information to the issuer during the author;zat;on process, is 30 preferred over track 2 in~ormation.
As previously mentioned, many data cards nowadays include more than oIle track of information on the magnetic stripe. These multiple tracks contain redundant infolmatiorl, for example, both track 1 and track 2 con~ain the account number and 35 expiration date, that could be used in the event o a ~ailure to be able to read one of the tracks. Moreover9 the embossing on the ~$~

card contains the account number and expiration date. It would be desirable to be able to utilize these other sources of information of the account number, expiration date, etc. in the event of errors in reading the information from the magnetic s stripe, for example if only a portion of the magnetic stripe were damaged. Alternative embodiments of the present invention allow such operation.
Transaction processors and others may therefore find it advantageous to utilize embodiments of the present invention 0 that are operative to obtain information from one track or from the embossed card reader to construct a complete or error-corrected account number, expiration date, or the like in the event that an error occurs in ~eading another track of the magnetic stripe data. However, it will be understood that the l5 preferred embodiments of the invention are constructed to obtain the desired infonnation from the m'agnetic stripe.
In this regard, the data card magnetic stripe encoding standard in widespread use today is found in ANSI Standard X4.16-1983, published by the American Na~ional S~andards 20 Institute, New York, New York, which is incorporated herein by reference. FIG. 27 illustrates the method of encoding clata on track 1 1001 and track ~1002 of the magnetic stripe of a typical da~a card in accordance with this ANSI standard.
In track 1 1001, data characters are encoded as six 25 bit values, with one parity bit, for a total of seven bits per character. I~e major components or fields included in the track 1 data are an account number region, an account holder's name region, an expiration date regicn, and a longitudinal redundancy check (LRC) region. In addilion, track 1 includes a start sentinel 30 (SS~) a format code (FC), a plurality of field separators (FS), discre~ionary data, and an end sen~inel (ES). Those s~illed in the art will also understand that the track 1 data illustrated in FIG. 27 are both preceded and ~ollowed by a series of clocking characters (logic 0'5) that are read by ~he magnetic stripe read circuitry and 35 used solely for the purpose of synchronizillg the decode circuitry.

, . . .

'",:'. ,i - ' ~ - ~
.

Track 2 1002 contains data characters that are encoded as four bit values, with one parity bit, for a total of five bits per character. The major components or fields included in the track 2 data are an account mlmber region, an expiration date S region, and an LR(: region. In addition9 track 2 data also includes a start sentinel (SS), a field separator (FS), discretionary data, aIl end selltinel (E~), and a series of leading and trailing clocking characters like those discussed in conjunction with track 1 1001.
The account numbers and expiration daees that are encoded on track 1 1001 and track 21002 are identical to each other and to the embossed account mlmber and expiration date that appear on the Pace of the data card. Each traclc 1001,1002 has a unique LRC that allows the terminal to verify the acouracy 15 of the data read from the card. Generally described, the bit configuration of the LRC characters are identical to the bit configuration of the data characters. Thus, the LRC of track 1 1001 consists of seven bits including one parity bit, and the LRC
of track 21002 consists of ~ive bits including one parity bit. The 20 LRC character recorded on each track is calculated so that a total number of ONE bits encoded in the corresponding bit location of all characters of the data message, including the start sentinel, data, end sentinel, and LRC characters, is even. The LRC
character's parity bit is calcula~ed so that the total number of 2s ON~ bits in the LRC character, including ~he parity bit, is odd.
Those skilled in the art will understand that a tenni~al 3S constmcted in aocordance with the present irnention will calculate a value for the I,RC ~or the data read ~om t~ack 1 1001 and compare it to the LRC encoded on track 1 1001. If 30 the two are identical, it is dete~nined that the data has been read from traek 1 1001 without errors.
In the event tbe two are not ideIltical, the terminal also calculates a value for the LRC for the traclc 2 data and oompares it to the LRC encoded on track 21002. If they aTe 35 ide~tical, it is understood that the terminal 35 has read the encoded data in track 2 without encountering errors. However, if :

the LRC encoded on either track does not match that calculated by the terminal 35~ it is determined that the data read from the magnetic stripe, both track 1 and track 2, is erroneous and should not be used to process the transaction or should be restored, if possible.
Those skilled in the art will appreciate that it is possible with the present invention to restore the data read from the magnetic stripe in the event the LRC calculated by the terminal for the data read does not match that stored on the magnetic stripe. Even if the LRC for track 1 or track 2 indicates that the magne~ic stripe read contained errors, it is possible that the account number was read properly, in whole or in part. By obtaining at least a portion uf the account number ~rom another source, such as the other track of the magnetic stripe or from the embossed card reader, replacing selected characters of the account number which may be in error with corresponding characters from the al~ernative source account number, and verifying the accouIlt code checksunn, the account number may be restored to its original error-free state.
In the preferred embodiment, each character of the account number that is read by the embossed card reader 112 may be conver~ed into the appropriate character format for track 1 or track 2 data, and used to restore at least a portion of the account ~umber read from the magnetic stripe. Likewise, since e~ch character in the account number of track 1 and or track 2 includes parity bits, it may be possible to identify which one of the plurality of alphanumeric characters forming the account mlmber or expiration da~e is e~oneous.
It is thus possible with thc prese~t invention to (1) iden~i~y a character or characters in the data read from a first track of the magnetic stripe that have incorrel~t parity, and substitute the coITesponding charac~er from a second track of the magnetic stripe or from the embossed card reader, or (2) substitute the entire account number or other data read ~om a first track with data read from a second track, or frorn the embossed card reader, and (3~ thereaf~er recalculate the value for .
, 2~ $~

the checksum ass~ciated with the account number and/or LRC for the entire track to determine if it then matches the account number checksum and/or the LRC for the entire track.
If the checksum and/or LRC calcullated from the s account number i~ormed by substituting selected characters or by substituting the entire account number, matches the account number checksum and/or LRC associated for the respective track, it will be determined that the data originally read ~rom the particular track of the magnetic stripe was erroneous, that the 10 error has been corrected, and that the accuracy of the account number, expiration date, etc. data has been verified by recalculating the checksum and/or LRC. By this method, it is possiblle to utilize data frorn any of the three sources ~o dete~nine the account number and expiration date and to maintain a hi~gh lS level of confidence as to the accuracy of those numbers.
Subroutine READ CARD DATA
Turning now to FIG. 28, the preferred subroutine READ CARD DATA 90S will be described. This subroutine 20 comprises steps taken in the preferled te~ninal for automatically reading the accou~t nurnber and expiration date from the card, and verifying the accuracy of the data to the extent possible.
Namely, the READ (:ARD D~TA subroutine 905 first attempts to read the account number and expiration date from a card's 25 magnetic stripe. If the LRC is verified and the data appears to be accurate, ~he transaction is processed using that i~onnation. If the LRC verii~ication fails and the magnetic data ~herefore is determi~d to be inaccurate, the subroutine reads and decodes the account number from the characters that are embossed on the face 30 of the card, and prumpts the merchant ~o man~ally enter the expiration date from the keyboard. This data is then used to restore portions of the da~a read from the magnetic stripe and the LRC is recalcula~ed. If the LRC is verified, the transaction is processed using the restored magneti data. However, if the 3s attempt to verify LRC fails again, the transacticn is processed . : , 101 ~ r ~

using the account data that was read from the embossed characters.
The subroutine 90~ begins at step 1020 when a card 15 is swiped through the card swipe slot 112. At this step, the s preferred card swipe interface 265 reads and decodes the data recorded on both track 1 1001 and track 21002 of the card's magnetic stripe 110. Those skilled in the art will understand that the method by which the magnetic stripe data is read and decoded is substantially similar to that used in prior art devices. A
0 description of a method of reading and decoding the data contained in a magnetic stripe associated with ~ data card may be found in copending U.S. Patent application serial no. 07/790,658, filed November 8a 1991, entitled "Card Transaction Te~ninal", the disclosure of which is incorporated herein by reference and 15 mads a part hereof, and in U.S. Patent No. 4,788,420 to Chang et al. Thus, the decode algorithm will not be described herein in any additional detail.
At step 1022, the CPU 255 calculates LRC values for the data read from both tracks 1 and 2, and compares them to 2Q the LRC values encoded Oll the card's magnetic stripe. ~f the data from either track is determined to be valid, the method proceeds to step loas. If neither track 1 1001 nor track :21002 is valid, the subroutine proceeds to step 1027 and the merchant is prompted to swipe the credit card 11 S through the card swipe slot 2s 103 again, by displaying the message "CARD NOT :READ -PLEASE SWIPE CARD AGAIN" on the LCD 123 on the te~inal. When the card 15 is swiped through the card swipe slot 103 the seco~d time, the preferred card swipe inter~ace 265 again attempts to read and decode the data recorded on both track 30 1 1001 and track 21002 of the card's magnetic stripe 110.
Ater the card is swiped for the second time, ths subroutine 90 proceeds to step 103al, and repeats the tests carried out at step 1022. l'hus, the LRC values for the data read from both ~racks 1 and 2 are calculated and compared to the LRC
3s values encoded on the magnetic stripe. If either track 1 1001 or track 21002 is valid, the subroutine proceeds to step 1025.

r~

At step 1025, the terminal determines whether the track 1 data possessed a valid LRC. If so, the track 1 data is determined to be valid, and the CPU proceeds to step 1032. At step 1032, a flag is set to indicate that the data used to process the s transaction is "swiped track 1 datan and the CPU 255 exits the READ CARD D~TA subroutine 905 and returns to the CREDIT
SALE AUTHORIZ~TION routine 900.
Returning now to step 1025, in the event the track 1 data is determined to be invalid, the terrninal proceeds to step 0 1035, where the track 1 account number is compared to the track 2 account number. If the account numbers read from track 1 and track 2 are dif~erent, the CPU 255 proceeds to step 1037 and begins the process of using the account number read from track 2 to restore the data read from track 1. If the account numbers are found to be identical, at step 103~, the method 905 advances to step 1045, which is discussed below.
Those skilled in the art will understand that even though track 1 and track 2 both inc:lude the account number and expiration date, it is preferable to process a trarlsaction using track 1 data if possible, since it includes the cardholder's name and additional discretion~ry data. In addition, the track 1 discretionary data may include alphanumeric characters~ whereas all track 2 is limited to numeric data.
At step 1037, the defective traok 1 data 1001 is 2s restored by substituting at least a portion of the account number from track 2 into the account number field oiE track 1~ With the track 1 data reconstructed in ~his manner, the terminal proceeds to step lQ40 and attempts to verify the validity of the restored track 1 data by retesting the LRC. If the LRC is detennined to be valid, the terminal proceeds to step 1032 whereupon it sets a flag to indicate that the data used to process the transaction is "swiped track 1 data built using track 2", exits the READ CARD DATA
subroutine ~ 0 5, and returns to the CREDIT SALE
AUI'HQRIZATION method 900.
If, a~ step 1040, the reconstructed track 1 data is determined to be invalid, the te~ninal proceeds to step 1047. At .~ . .
:

step 1047~ the terminal sets a flag indicating that the data used to process the transaction is "swiped track 2 data", exits the READ
CARD I)ATA subroutine 9Q5 and returns to the CREDIT SALE
AUTHORI~ATION method 90Q. ^~
Turning now to step 104~, if the track 1 and track 2 expiration dates are determined to be di~ferent, the prograrn advances to step 1050. At this step, the terminal attempts to restore the data read from track 1 by replacing the track 1 expiration date with the expiration date read from track 2. The method 90S then returns to step 1040, where the terminal recalculates the track 1 LRC and tests the validity of the restored track 1 da~a. If the restored track 1 data is now valid, the tenninal proceeds to step 1037, whereupon the program sets a flag to indicate that the data used to process the transaction is "swiped track 1 data built using traclc 2n, leaves the READ CARD
DATA subroutine 905 and returns to the CREDIT SAI,E
AUTHORIZATION method 900.
If, at step 1040, the rleconstructed track 1 data is determined to be invalid, the termir~al proceeds to step 1047. At step 1047, the terminal sets a flag irldicating that the data used to process the transaction is "swiped track 2 data", exits the READ
CARD DATA subroutine 9û~ and returns to the CREl:)IT SALE
AUTHORIZATION method 900.
Returning now to step 103lD7 the preferred steps 2s executed in t~e event neither track 1 nor track 2 are valid will be described. II, at step 1033, neither track 1 nor track 2 are determined to be valid, the program advances to step 1055, and dete~ines whether ~he embossed card reader 1.1~ is activated. If s~, the terminal proceeds to step 1057. If ~he terminal's embossed card reader is not activated, the program proceeds to step 1084 and allows the merchant to manually enter the account number and expiration date. This process is described more completely below.
At step 1057, the terminal first causes the liquid 3s crystal display 123 to display a rnessage instructed the merchant to insert the card 15 into the te~ninal's embossed card reader 112, for example "IN~ERT CARD ~NTO EMB(:)SSED CARD
READE}?". Once the card is inserted, the embossed card reader 112 automatically reads and decodes the numeric characters 115 that are representative of the account number and embossed on the face of the card.
Once the embossed characters are read7 the program proceeds to step 1060, and determines whether the characters read from the card are "acceptable", that is, genera~ly within the specifications prescribed for embossed characters on data cards.
10 Those skil~ed in the art will appreciate that the embossed characters on a credit card comply with the lFarrington 7B
standard. However, fhe resolution of the disclosed embossed card reader 112 does not allow determination whether the characters of the embossing are within the precision set ~rth in the 15 Farringto~ 7B standard. Nonethe1ess, this resolution is sufficient to permit determination as to whether the characters are grossly out of proportion, si~e, alignr~ent, spacing, etc., and can detect badly worn cards or certain fraudulent cards. Thus, the determination of whether the embossed characters are 20 '~acceptable" will vary with the resolution of the embossed card reader and the degree to which the transaction processor decides to set parameters of acceptability. Por purposes of the present inventio~, characters are acceptable if the size a~d spacing of the characters is wi~hin the to~erance of the tactile imager, that is, 25 about 0.5 millimeters.
It will of course be expected that as the resolution of tac~ile imagi~g technology improves, it wi]l be possible with future e~bodiments of the present inve~tion to determine whether embossing on cards is within the tolera~ces provided by 30 the Farringto~ standard, thereby providin~ still further levels of confidence i~ the validity of the card and of the trarls~ction.
In addition to de~ermining whether the embossed characters themselves are accep~able at step 1060, the te~ al also tests to see if the data ~rom ~he embossed card reader is al3 35 numeric, if the ~ength oP the account number is valid for the card type, and if the account number passes the MOD 10 cbeck, that is, , : , :

: ~: .. . . :.

j? ~ "~

the known checksum calculation associated with credit card account numbers. If any of these tests fail, the characters read by the embossed card reader is determined to be not acceptable.
If the embossed characters 11S are determined to ~e S acceptable, the program proceeds to step 1062.
At step lQ62, the terminal causes the liquid crystal display 123 to instruct the merchant to enter the expiration date via the keyboard 120. Once the merchant has read the expiration date from the credit card and entered it from the keypad, the 0 program goes to step 1064. At this step, the terminal determines whether it was able to read any data from the magnetic stripe at the previous steps 1020,1027. If the tenninal determines that the magnetic data was nonexistent, th~ program advances to step 1066, whereupon the terminal sets a flag indicating that the data 15 used to process the kansaction is "embossed data only". The terminal then exits the READ CARD DATA subroutine 905 and returns to the CREDIT SALE AUTHORIZATION method 900.
Again, it will be unde~;tood that transactions flagged as "embossed data only" may not be afforded the same treatment 20 as magnetically read transactions by certain card issuing institutions or card issuers. Nonetheless, transaction processors who employ the present invention may elect to trea~ "embossed data only" transactions in the manner as it desires, inasmuch as the election to take the risk for a given transaction rests with the 25 transaction processor. It will of course be appreciated that users of the present invention may realize a greater degree of conidence that a card was actually present during a transaction, when the data read from the embossing matches da~a read from track 1 and/or track 2 of the magnetic stripe, and that the card 3n was a valid one if the characters read from the embossing are deemed acceptable.
If, at step 1064, the terminal determines that magnetic track da~a does exist, the program proceeds to step 1068. At this step, the tenninal reconsttl3cts the data read from 35 tra~c 1 by replacing the account number and expiraeion date from track 1 with the account number read by the embossed character . , .

,.

reader 112 and the expiration date that was manually entered by the merchant. Once the reconstruction is complete, the program proceeds to step 1070, and recalculates the LRC for the restored traek 1 data. If the LRC is veri~led and the restored track 1 data S is detennined to be valid, the terminal proceeds to step 1072, where it sets a flag indica~ing that the data used to process the transaction is "embossed data inserted into track 1", exits the READ CARD D~TA subroutine 905 and returns to the CREDIT
SALE AIJTHORI:ZATION method 900. If the reconstructed track 1 data is invalid, the program goes to step 1074.
At step 1074, the terminal reconstructs the ~rack 2 data by replacing thç accolmt number and expiration date read from track 2 with the account number read by the embossed character reader 112 and the expiration date entered by ehe merchant. Once the reconstructioxl is complete, the program proceeds to step 1076, and recalculates the LRC for the restored traclc 2 data. If the LRC is veri~led and the restored track 2 data is thus determined to be valid, the terminal proceeds to step 1078, where it sets a flag indicating ehat the data used to process the transaction is "embossed data inserted into track 2". The terminal then exits the READ CA~]:~ DATA subroutine 9Q5 and returns to the CREDIT SALE AUTHORI~ATION method 900.
If the reconstmcted track 2 da~a is invalid9 the program goes to step 1080.
2s At step 1080, the te~ninal sets a flag indicating that the data used to process the transaction is "track 1 or track 2 data with embossed data inserted and LRC ~ailure". The program then exits the RE~D CARD D~TA subrou~ e 90S and returns ~o the CREDIT SALE ~UTHORIZATION method 900.
Returning now to step 1060,the steps that follow a deternnination thatthe characters read by ~he embossed character reader are not acceptable will be described. If the embossed characters read ~om the card are not acceptable) the prog~am proceedsto step 1082 and deternnines whetherthe embossed card 3s reader 112 is broken. If not, the ternninal advancesto step 1088 and causesthe liquid crystal display 123 to instruct the mercbant ~

to request another form of payment from the customer. The credit sale transaction is then terminated.
If the embossed card reader 112 is determined to be inoperative at step 1082, the program proceeds to step 108~, s where it causes the liquid crystal display 123 to direct ~he merchant to notify the transaction processor 12 t~at the embossed card reader appears to be defective. Once notified, the transaction processor will cause the terminal software to be modified temporarily to allow the terminal to contillue processing 0 credit sales until the embossed card reader can be repaired or replaced. The progr~m then proceeds to step 1084 where it allows the merchant to manually enter the account number and expiration date. Once the accoullt ~umber and expiration date arc manually entered by the merchant, the terminal proceeds to step 15 1086, where it sets a flag indicated that the data used to process the transaction is "manually enterledn, exit~ the REAI:) CARD
DATA subroutine 90S, and returns to the CREDIT SALE
AUTHORIZATION method 900. Again, it will be understood that transaction processors and credit card issuers may not aff~rd 20 the same treatment to transactions ilagged as "manually entered"
as they would to magnetically read transactions.
An al~ernative embodiment of the present invention contemplates additional verification of the authenticity of the account mlmber read from ~he card. For example, a terminal 25 oonstlucted according to an altemative embodiment con~emplates that the credit sale transaction would be terminated if the terminai is unable to read the data ~orn the card's magnetic stripe. In addition, once tbe data is sucessfillly read from the magnetic stripe, the terminal prompts the mercha~t to insert the card into 30 the em~ossed card readçr or to manually enter the account number via the keyboard so ~hat the magnçtically read accouIlt number can be veri~led against the number obtained manually or read from the embossed card rçader. In this manner, a transaction processor is enabled to receive additional assurance 3s that a catd is genuine and that the embossed characters and/or magnetic stripe have not beerl altered by the cardholder.

~ S~2 From the foregoing, those skilled in the art will understand and appreciate that the "restoration" of data which has a redundant source is an option available with use of the present invention. It will be appreciated that one method of restoring 5 data involves reconstructing the account number and/or expiration date read from a first track with data read from a second track and/or the embossed card reader. Another common use would be to restore either track's data with data read from the embossed card reader. In any case, preferred embodiments of the 0 present invention will identify the manner of obtaining the data and transmit information corresponding thereto, such as "embossed data inserted into track 1n~ "em~ossed data inserted into track 2"~ "track 2 data inserted into track 1", 'Ctrack 1 or track 2 data with embossed data inserted and LRC failure", and 5 the like.
Those skilled in the art will furthermore understand that transactioII processors, card issuing institutions, card issuers, and others may elect to dif~erentiate between transactions as a function of the manner in which the data was obtained.
20 Specifically, it is expected that ma,gnetic stripe data, unrestored and original, is more likely to be accepted under stringent regulatio~s of certai~ card issuing insti~utions. However, track 1 data restored with track 2 data and/or embossed card data is e.qually reliable, as is track 2 data restored with track 1 and/or 25 embossed card data. Accordingly, the present i~vention's ability to restore data obtained from o~e source of information associated with a data card with information obtained from a redunda~t source will now be appreciated.
Subroutille CAPTURE SIGNATURE
Turning to FIG. 29, the CAPTURE SI&NATURE
subroutine 923 will now be described. Generally, the subroutine 923 is operative to cause the signature capture printer 38 to digitize and compress the data representative of the cardholder's 3s signature The method 923 begins at step 11017 when the terminal causes the liquid crystal display I23 oP ~he terminal 35 .: . " . ~ . , to prompt to merchant to ask the cardholder to sign the receipt, by displaying a message prompt such as "ASK FOE~
SIGNATURE~ he program then proceeds to step 1105.
As described earlier, the portion of the receipt s printed at step 921 of the method 900 (FIG. 26) inc~udes the date and time of the transactioll, purchase amount, credit card account num~er and expiration date. After the information recorded on the receipt is verified, the cardholder signs the receipt over the signature capture window 160 on ~he si~gnature capture printer lQ 38 using the magnetic/ink stylus 165.
As the cardholder signs the receipt, the magnetic field generated by the X- and Y- grids 601, 602 on the digitizer printer circuit board 300 is detected and converted into electrical signals by the magnetic/ink stylus 165. At step 1105, the 15 digitizer printer circuit board 300 receive~ the sig~als from the magnetic/ink stylus. Then, at step 1107, the digitizer printer circuit board converts these electric,al signals into a digital signals representative of the strokes of the signature provided by the cardholder. These signals are thlen transmitted to the printer 20 controller printed circuit board 280.
At step 1112, the circuitry on the printer controller board 280 compresses the ~umeric data received from the digitizer printed circuit board, in the manner described in connection with FIG. 18 through FIG. 24.
2~ Those slcilled itl the art will app~eciate that the compression o the X, Y data points comprising the signature signals is e~fective to reduce the amount of data required to accurately represent the cardholder's signature. Since an object of the prese~ invention is to provide arch;val-type storage of a 30 faesimile of the cardholder's signature, the compression of the data facilita~es storage of ~he signature by reducing the amount of memory required to accomplish this objective. In addition, inasmuch as the facsimile of the signature must be transmitted from the terminal 35 to the host compu~er 407 the time required 35 to transfer the data is seduced by decreasing the amount of data that must be transferred. Finally, compression of the data , ~ ~

increases the number of transactions that can be stored in the limited memory available in the terminal 35. This is essential in the event the terminal is unable to communicate with the host computer, in which case the termillal must store the facsimile of 5 the signature along with all of the other transaction data that is typically stored in the terminal~ until such time as communications with ~he host can be re-established.
Once the data is compressed, the compressed data represe~tative of the signature is trans~erred from the signature 0 captllre printer 38 to the preferred terminal 35 at step 1115.
Once the facsirnile of the signature is received by ~he terminal, the method 923 proceeds to step 1117) where the terminal exits the subroutine 9 23 and reeurrls to the CREDIT SAL~
AUTHORI~ATION method 900 in FIG. 26.
Subroutille REQUEST AUTlHORIZATION
FIG. 30 illustrates the method that is embodied in the REQUEST AUTHORIZATION subroutine 926, which is executed by the telminal 35. Ge:nerally described, the method 20 926 causes the terminal 35 ~o initiate communications with the host computer 40 of a transaction processor. During the es~ablished communications session, the terminal transmits the data pertaining to the proposed ~ransaction and requests an au~horization indicia or code from the host computer. The 25 authori~ation will be granted if the card issuer or its agent so stipulates, or, in the even~ of failure to communicate with the card issuer or its agent, if the transaction data received by the host computer falls withi~ predetermined parameters that are presc~ibed by the credit ~rd transaction processor 12 or by the 30 card issuing association 18a-d.
In the event the terminal 35 is unable to establish communications with the hose computer 40, or communications are interrupted, the terminal then attempts to initiate and receive an off-line authorization from an altemative facility lcnown as an 35 audio response unit (ARU) 70. If the transaction is not approved by one of these two means, the transaction is terminated.

.

.. , ~'&~$~17 lll However, if the transaction is authorized, the subroutine causes the authorizatior~ number to be stored and the routine terminates and returns to the CREDIT SALE AUTHORI:ZATION routine 900.
s The subroutine g26 begins at step 11~0 when the CPU 2~S in the terminal 35 causes the modem 446 to dial a predetermined first or primary telephone number corresponding to a primary authorization source (~or example, a front end processor of the host computer 4ID of the transaction processor 0 12 in the case of preferred embodiments of the invention).
Dialing this number comprises an attempt to establish a first telecommunications link between the terminal 35 and an authorization source.
It will be understood that the terminal 3 5 is preprogrammed with the telephone number of the primary authorization source computer system. In the preferred embodiment, the authorization source telephone number consists o an access code and telephone number utilizing a first or primary telecommunications carrier, and the authorization source is preferably the transaction host computer system 40.
At step 115~, the inqluiry is made whether the authorization source host system has responded. If so, the program branches to step 1160.
If at step 1152 the primary authorization source has not responded, then step 1155 is executed. At step 1155 the CPU 2S5 in the ~erminal 35 causes the modem 446 to dial a predetermi~ed secondary telephone n~mber corresponding to a secondary authorization sou~ce ~for example, a direct dial in port associated with the host computer 40 of the transactio~ processor 12 in the case o preferred embodiments of the invention).
Dialing this number comprises an attempt to establish a second ~elecommunications link between ~hç terminal 35 and a secondary authorization source.
At step 115~, the inquiry is made whe~her the 3S secondary authorization SGUrCÇ has responded. If so, the program r~

branches to step 1160. If not, the program branches to step 1159 to attempt to obtain an off-line authorization.
I~ will be understood that the terminal 3 S is preprogrammed with this secondary authorization source 5 telephone number. In the pre~erred embodiment, the secondary authorizatlon source telephone number consists o an access code and telephone number ~tilizing a secondary telecommunications carrier, and the secondary authorization source may be a dial-in port associated with the transaction host computer system 40.
It should be understood that in ~he preferred systems, the attempts to establish a first and then a second telecommunication link comprises attempts to commllnicate with the trarlsaction processor host system 40, which serves as a commurlication channel for obtaining authorizations from an 15 originating authorization source such a card issuer or caxd issuing institution, as in FI~. 1 and FIG. 2. Of course~ the host system 40 itself could be the authorization. source. Moreover, it should be Imderstood that the first telecomrnullication link and the second telecommuni~ation links are preferably independent packet 20 networks, so as to provide redundant communication meaIls.
Thus, the primary authorization source and the secondary authorization source could comprise the same host compllter system, but may be considered separate authoriza~ion sources becatlse of the fact that the host is accessed via separate, redundant ~5 telecomml~nicatio~ links.
It will thus be appreciated that the provision of separate primary and secondary telephone numbers, each associated with a difgerent telecommunications calTie~, allows independent and therefore redundant access paths to the host 30 system 40 of the ~ransaction processor, which performs the authoFizatioTl ~unetions on behalf of the merchant and transaction processor. Such redundant communication paths increase the l;kelihood tha~ an electronic authoriza~ion can be obtained for any given ~ransaction, which is a pre~rred result to an off-line 35 au~horization.

,:

.
.
, ~ , .
. , :

~'2 In the e~ent that communica~ions with either the ptimary authorization source or the secondary authorization source have been established, at step 1160 ~he program causes the transaction data accumulated by the terminal to be transmitted to s the host computer. Once the accoullt number, expiration date, purchase amou~t, transaction date, and compressed signature signals are transmitted to the host computer 40, the program proceeds to step 116a. Such a transmission compnses a request for authorization of the transaction.
It will be apprçciated here that the described method of transmitting to the host all trar~;action data (account number, expiration date, purchase amount, transaction date, compressed signa~ure signals, and transaction protected flag) upon establishrnent of communications for purposes of seeking an 15 authorization is presently preferred for use in the present invention. Nonetheless, those skilled in the art will appreciate that other sequences of operation are considered within the scope of the present invention. For exam3pleg alterllative embodiments of the present invention contemplate operatio~ wherein the 20 authorization is sought immediately after obtaining the account number, and wherein the compressed signature signals are transmitted af~er obtaining the authorization. However, it will be appreciated that for transac~ion procçssors electing to provide cbargeback protection on behal of mercharlt/customers, it is 25 advantageous to capture all relevant in~ormatioII concerning the transaction illcludi~g ~he signature prior to seeking authorization.
At s~ep 1162, the program receives a response from the host computer i~ responss to the authoriza~ion reques~. If at step 1164 the response i a "decline", the subroutine exits and 30 control is retu~ed to tbe CREDIT SALE ~IJTHORIZ~TIQN
routine 900. If the response wa~ not a decline, tbe inquiry is made ~t step 1166 whether the respone was an approval.

~ .

If the response was an approval, the program branches to step 1170, where the approval eode is recorded within the ~ern inal's memory associated with the other transaction data. The approval code will be retained with the s other transaction data until ~e terminal is closed, in accordance with the CLOSE TEl?MINAL subroutine. rhe subroutine exits and control is returned to the CREDIT SALE
A~ORIZATION routine 980.
If at ~he inquiry step 11~6 the response received 10 from the authorization source is not an approval, the only other alterna~ive is a "re~erral" or call me. ~ this case, the program branches to step 1185.
Returning now for a moment to step 11~6, if no response has been received from either the primary or ~he 15 secondary authorization sources, step 1159 is reached. Steps of the method subsequent to this point, which is reached if the attempts ~o es~ablish communications via the first telecommunication link and ~e second telecommunication link to obtain an electronic authorization 'have failed, may be considered ~o steps of an "off-line au~orization" method.
At step 1159, ~e inquiry is first made whether the proposed transactio~ amount is lçss ~han a prede~ermined ~loor l~it or min~nurn tran~action siæ for which an au~orization is required. If ~e transaction is beneath dle floor limit (e.g., ~he 2s transaction is less than, say $10.00), a '~floor limi~" process is carried out ae step 117 7, comprising in the preferred embodiment ~e genera~ion of an off-line approval code within ~e te~mirlal itself, indicative of a less ~an floor limit transaction.
No co~nunicatiolls with any e~cternal off-line au~orization 30 source are attempted, since it nnay not be deemed economically feasible to obtain a~n o~f-line approval code for small transactions.
It should be unders~ood that the term "off-line au~horization", as used herein, signifies d~at an authorization is being sought from an au~horization source other than that 3s provided by ~he data communication link normally established between ~e ~erminal and the transactiorl host sys~em 40. Such an . . .
- .. , -- , ~$~ .

"of~-line au~orization" may a verbal authorization or telephonic authorization instead of an electronic authorization comprising au~oriza~ion indici~ that is transmitted electronically from an au~orization source and electronically stored and associated with s the kansaction data without intervention by or data entry by the merchant.
If at step lL159 the transaction is of a magnihlde ~hat e~;ceeds the floor limit amount, the program branches to step 1175. At step 1175, the terminal automatically dials a 10 preprogrammed number assoeiated with the transaction processor's off-line authorization source. Such an off^line authoriza~ion source in the preferred system is the transaction processor's own ARU 70. It will be appreciated ~at ~e attemp~
to cormnunicate with the ARU is made via a voice grade ls telephone connection, instead of a packet networ3c as in the case of the first telecommunications link and/or the second teleco~nunications link.
At step 1176, data associated wi~h the proposed transaction is transmitted by the termLnal 35 using DTMF tones 20 generated lby the modem 446. The response of the ARU 70 and o~f-line authorization source constructed in accordance with the present invention is described in cormection with FIG. 35.
Once ~e ARU 70 answer~, ~e transaetion data is transmitted from the terminal 35 to the audio response Ullit 70 25 u~ing dual tone multiple frequency (DTMF) signals, such as those produced by a TOUCH-TONE~ telephone. It will be appreciated ~hat the preferred terminal 3S is prvgrammed to automatically transm;t the transaction data via DTMF signals when communicating with ~e ARU, but ~is operation is selec~ive and 30 the te~rninal can be made operative to require keyboard entry of transactiorl data.
If au~oma~ic DTMF transmission of transac~ion data is not selected, ~e merchan~ will enter ~e account number, e~piration date, and purchase amount using the portion of the 3s keyboard 120 ~at ~orrns a telephone-type keypad. Once the audio response unit 70 receives the transaction data, the ARU

, ~ , : , . .
~........ . .

automatieally at~empts to obtain an authoriza~ion approval from ~he card issuer via its cormection to an appropriate authorization source, or, in the event of a host outage, determines whether the transaction may be approved according to predetermined s guidelines for off-line àuthorizations maintained by the transaction processor 12. If so, the ARU produces an audible series of nurnbers corresponding to an off-line authorization number. If the transaction may not be approved, the ARIJ will automa~ically refer the call to a live operator in the voice services 10 department 72 (FIG. 2) in order to accommoda~e a direct voice telephone call to the card issuer.
Further details of the off-line authorization system are provided in connection with FIG. 35.
At step 1180, the inquiry is made whether an 15 approval was received from the ARU 70. If not, the terminal branches to step 1182, where the inquiry is made whether the response to the authorization relquest was a decline. If the response was a decline, the at step 1184 the terminal displays "DECLINE" on the LCD 123 and the subroutine exits and 20 control is returned to the CRED][T SALE AUTHORIZATION
routine 900. The merchant of course must at this juncture decide whether to proceed with the transaction using another source of payment.
If at inquiry step 1180 the transaction is to receive 25 an off-line approval, the program branches to step 1192. A~ step 1192, it is assumed that a speech-synthesized three-digit autho~i~atlon code has been spoken to the merchant by ~he ARU
70, iXl accordance with the discussion in connection with FIG. 35.
The merchant at 1192 ;s then prompted (by synthesi~ed speech 30 from ~e ARU) to enter this ~ree digit code via the keypad. As describecl below, two of the three digits are derived from any authori~a~ion code obtained from a card issuer or card issuing assaciation's authorization system by the ARU 7~ while ~
digit is a check digit designed t~ che~ ~ mistaken or 3s fraudulently entered authori~a~ion codes.

At step 1193, a check is made whether the ~'charge back protection" (CPF) flag (described in TABLE II) has been set. If not, the subroutine exits to the CREDIT SALE
AUTHORIZATION routine. 900.
s If at step 1193 the CPF flag has been set, the program checks the approval code entered by the merchant at the keypad at step 1194. If a valid approval code has been entered, the subroutine exits and control is returned to the main loop 900.
The terminal perfo~ns a predetermined chçck-digit-type authentication algorithm as a part of step 1194 to validate the authenticity of the purported off-line approval code. Those skilled in the art will understand that because the off-line authorization code is being provided in the form of synthesized speech, via the telephone, to the merchant, and the merchant is entering the numbers via the keyboard, there is a possibility that the authorization code could be wrongly or fraudulently entered.
In preferred embodiments of the present invention, a three-number authorization code is provided from the ARU 70 -- the first two mlmbers are a subset comprising the least significant digits of any actual multiple digit authorization code received from a card issuer or card issuing association's authorization system (as described in greater detail in connection with FIG. 35), while the third number is a checlc digit computed according to a known check digit algori~m for purposes of ensuring that a valid 2s approval was actually received and/or entered by the merchant.
The terrninal 3~ in the preferred embodiment is programmed to check ~e three numbers entered by the merchant for correctness via the check digitt using the same algorithm as utilized by the ARU 70 in generating the three numbers, which is discussed in conjunction with FIG. 35.
If at step 1195 the approval code is not valid, as determined by check digit logic carried out within the terminal 35, the ~erminal will display a prompt on the LCD for the merchant to re-enter the approval code, by branching to step 3s 1192. The merchant will be a~forded two opportunities to enter the approval code including check digit properly, after which the . . . . .

terminal assumes that the approval code was no~ heard properly by the merchant or is fraudulent, and the subroutine will exit and return control to the main loop 900.
Returning now to step 1182, if the response from s the o~f line approval source was not a decline, it is deemed ~hat the respGnse is a "call me", and the program branches to step 1186. At this step, d~e merchant is advised via a messa~e on the LCD 123 to call the card issuer for an approval or other message. In alternative embodiment, the terminal may be 10 programmed wi~ the telephone number of the card issuer and the tesminal will be automatically operative for initiating a call to the issuer. After calling the card issuer, the program branches to step 1188 and transmits any required data to the card issuer, if applicable, and exits. Typically, in such cases the terminal will 15 switch the telephone line to the handset, since a voice communication with a live operator associated with the card issuer will likely follow. Thus, in some cases the merchant may speak directly to a voice services operator. After step 1188, ~he subroutine exits and control is returned to the CRE~DIT SALE
20 AIJTH{)RI~ATION routine 900.
Subloutine STORE DATA
Turning now to FIG~ 31, the subroutine STORE
DATA 930 will ~ described. Generally described, the STORE
25 DATA subrou~ine is operative to store the transaction related data, including signature signals, in the terminal 35 after the terminal has received an authorization code from the host computer 40 or the audio response Ullit 70. If the authorization code was received from the host computer, the host computer will 30 have received and stored all of the transaction data including the signature. In SUGh a case, ~he terminal will store all of the transaction data exeept the car&older's signa~ure, thereby freeing memory for storage of additional transactions.
On the o~er hand, it will be understood that if the 3s transaction was authorized by an off-line authorizatlon code, the transaction data will not have been transferred to the host , . : :
. ~, . , 119 . ..

computer since the terminal was unable to establish communications with the host computer. Thus, the; rminal stores all of the transaction data including the cardi-, 'der's signature until such time as the terminal again estat ;hes communications with the host computer and is able to trai ~er transaction data to the host. Those skilled in the art i~ ll understand that the data stored in the terminal remains there om untii the terminal is "closed" periodically and the transaction data is transferred to the transaction processor for clearing and l0 settlemen~.
The STORE DATA subroutine 930 begins at step 1202, where the terminal determines whether the authorization code received by the terminal at step 926 was an off-line authorization code. If it was not an off-line authorization, the lS method proceeds to step 12 0 4, where the terminal's microprocessor 401 causes all data corresponding to the transaction, except the signature signals, to be retained in the terminal's memory 258. Memory formerly utilized for storing the signature associated with the transaction is then released for 20 other uses by the microprocessor 401, including storage of other transaction data. Once the data is stored at step 1204, the program exits and returns to the CREDIT SALE
AUTHORIZATION routine 90Q.
If, at step 1202 dle authorization was det nined to 2S have been received via an off-line authorization code, the method advances to step 1206. At this point, ~he CPU 255 in the terminal causes all of the transaction data including the signature to be stored in the terminal's memory 258. Once the appropriate data is stored, the program exits and returns to the CREDIT
30 ~SALE AUTHORIZATION routine 900.
Routille for Terminal Closillg ~ IG. 32 is a flow chart illustrating the prefesred CLOSE TERMINAL subrou~ine 932, described generally in 3s connection with the main loop in FIG. 25, ~hat is operative to "close" a terrninal/printer 30 constructed in accordance with the . . ~ " ,, , :
.

~ ~3 presen~ invention. As discussed earlier1 the terminal is "closed"
periodically (e.g., daily) when the merchant transfers accounting period data to the transaction processor 12, for example an amount corresponding to the toîal of all transactions during a given accounting period, along with the data associated with ~he particular transactions. The CLOSE TERMINAI, subroutine 932 of FIG. 32 is implemented as a function which may be initiated from the main program, as illustrated in FIG. 25.
Those skilled in the art will understand that in the present invention and in prior art data capture terninals, the transaction data is preferably transmitted to the transaction processor at the time of each transaction. Thus, it may only be necessary to transmit a total amount representing the merchant's accounts receivable from the transaction processor when ~he telminal is closed. However, there are times when ~e terminal is unable to communicate with the host computer, and terminals constructed in accordance with the present invention store all transaction data until it can be transmitted to the host computer 40 at the time the terminal is closed.
At step 122~, the ternninal 3S determines whether it has been instructed to execute the close procedure. This may be upon command by the merchant with a predetermined command keystroke on the keyboard, or the terrninal 3 5 may be programmed to close automatically at a predetermined time each day. In either case, the program advances to step l229 if the close instruction has been issued. If not, the program exits the CL()SE TERMINAL routine and returns to the idle state.
At step 1229, the terminal software (which can include separate accounting software not forming a part of the present invention but operative in the MS-DOS compatible terminal CPU 255) detelmines the amount of the "deposit" made by the merchant to the transaction processor. It will be understood that the "deposit" comprises an amount corresponding to a number of transactions, for which ~e merchant is seeking 3s payment from the transaction processor or other paying entity. If the close proce~ure is entered manually, the merchant will be .. .
~ ., . ..... ,' ' .
~, .

prompted ~o enter the amount of the deposit via the keyboard. If the close procedure is initiated automatically, the terminal 35 detelmines ~he total amount of the deposit as represented by the transactions accumulated since the terminal was last closed. Once s the deposit amount is determined, the method proceeds to step 1~32.
A~ step 1232, the terminal determines which of the transac~ions stored in the terminal need ~o be transmitted to the host. As discussed earlier, in the preferred embodiment only ~ose transactions that are stored wi~ o~f-line authorization codes have not already been transmitted to the host. Thus, the telminal only transmits the transaction data and signatures associated with those transactions that are stored with off-line authorization codes.
It should be understood that a normal terminal closing will result in all transactioxl data elements being deleted from memory (i.e., the terminal's memory is made available for new transactions), thereby freeing all memory for new transactions. Such a closing would be deemed a "complete~' closing. However, those skilled in t}~e art will understand that the steps of FIG. 32 may be modi~led to provide for a "partial"
closing, whereby a portion of the terminal's free memory is allocated for a new batch of ~ransactions, while a- previous batch of transaction data is retained in memory, pending closing or 2s other acco~mting reconciliation.
Once any data is transmitted, the method proceeds to step 123~, where the terminal causes the signature signals associated with the transactions just transmitted to the host to be deleted from the terminal's memory 258. The program then exits the subroutine 932 and re~ellters the main loop awaiting ~ur~er transactions or commands in FM. 25.

Methods of Operation of Tran~action Processing Systems Employing Preferred Terminal/Prillter After the foregoing discussion, those skilled in the art will be enabled to construct a data card terminal/printer - ' .
.. ;. . , ;

;ncluding a signature capture printer, with embossed card reader, having the ability to provide more information concerning a particular data card transaction than has heretofore been possible.
Transaction processors will be able to enjoy the advantages s provided by such a terminal/printer combination, or even merely certain subcombinations such as the signature capture printer, the restoration of unreadable or damaged data read from a first magnetic stripe track with data from a second magnetic stripe track or with data from the embossed card reader. Because of the 10 additional confidence in the validity and collectability of a transaction afforded by use of the disclosed terminal/printer 30, it may be expec~ed that transaction processors will be able to provide additional types of services Oll behalf of their merchant/customers, namely, the provision of chargeback 15 protection for transactions conducted using the terminal.
Furthermore, a transaction processor, such as the transaction processor 12, that utilizes the present invention to capture and s~ore the transaction data including signature signals on behalf of its customers/merchants will be able to provide 20 valuable services on behalf of its customers. Such services include the retrieval of transaction data upon request of a card issuer or card issuing association, thereby eliminating any involvement of and inconvenience to the merchant, and by eliminating ~e need for the merchant to retain paper records of 2s transac~ions.
Moreover, the disclosed terminal 30 facilitates the provision of o~-line authorization capability by a transaction processor which also serves as an authorization source. In such cases, the inability of the terminal to communicate directly with 30 the transaction processor's host to obtain on-line authorization does not preclude the transaction processor from providing chargeback protection for ~ransactions that obtain an off-line authoriza~ion, as described herein.
Such advantages provided by use of the present 3s invention will be described next.

Retr;ev~l ~Request Processing Method Turning now to FIG 33, a me~hod 1400 tha~ is employed by a ~ransaction processor hos~ compu~er 40 to process a retrieval request will be described. A system constructed in s accordance with the present invention facilitates retrieval requests by providing a method for storing infolmation corresponding to transactions, including the signature, in a compact electronic form. ~i l chants who retain the services of a transaction processor that uses systems constructed in accordance with the 10 present invention will find that they no longer have the need to store paper records of their data card transactions, since such data is stored electronically, paperlessly, in the database of the transaction processor. Transaction processors using the present invention can respond to retrieval requests on behalf their 15 customers (e.g. merchants) quickly and efficiently since all data is stored in the transaction processor's host computer, allowing the transaction processor to provide~ a valuable service to the merchant.
Generally, the method 1400 in FIG. 33 allows a 20 transaction processor to respond to a retrieval request without the involvement of the merchan~. This is possible because the present invention insures that all of ~e transaction data, including the cardholder's signature, is recorded and stored by ~he transa~tion processor 12 in a data storage facility 64 (FIG. 2~ such as a bank 25 of disk drives, tape drives, optical drives, or the like.
Starting in FI(}. 33 at step 1401, a transaction processor 12 receives a retrieval request from one of the card issuing associaeions 18a-d. This retrieval request contains certain identifying in~ormation such as a transaction re~erence number, 30 cardholder account number, transaction date, and transaction arnount. At step 1405, the host computer 40 of ~he transaction processor causes a receipt file stored in data storage 64 to be searched by the reference number (or other identifying information~ contained in the retrieval request to locate a data 3s item corresponding to the transaction in ques~ion. Once this data , item, also considered a "receipt", is located9 the method proceeds to step 1407.
A~ step 1407, the host computer causes a facsimile of the data item or receipt corresponding to the requested S transaction to be printed by the transaction processor 12.
Reproduction of the receipt generally involves printing all data assoc;ated with the transaction such as purchase amount, account number, expiration date, authorization number, merchant' s product identifying or other inventory code, and cardholder 10 signature. l'he cardholder signature of course is stored in its compressed form, so printing the receipt requires decompressing with the decompressor software 42 and reconstructing the strokes of ~e signature in the manner described in connection with FIG.
24.
Thus, the cardholder's signature is reproduced along with the other transaction data. 'l'he retrieved receipt is then plinted at step l407, and includes the reconstructed signature.
At step 1409, the printed receipt containing the transaction data and signature is forwarded to the credit card issuing association 20 or other entity that initiated the retrieval request.
Chargeback Processing Method Turning now to FIG. 34, a method 1500 that is employed by the transaction processor host computer 4û in the 2s preferred systçm to process a chargeback will be described.
Generally, the preferred method lS00 allows a transaction processor that utilizes terminals 30 and software constructed according to ~e presen~ invention to respond to most chargebacks without ~e involvement of the merchant. This is possible because 30 a sys~em constructed in accordance with the present invention insures that all of the transactlon data, includin~ the cardholder's signature, is recorded and stored by the transaction processor 12 ln a storage facility 64. Use of the present inveIItion therefore allows a transaction processor to assume the risk of certain types 3s of chargebacks on behalf of its customers (merchants) if it so , .
, '7.

chooses, with a high level of confidence that the transaction was a valid one.
Starting in FIG. 34 at step 1501, the transaction processor 12 receives a chargeback from one of the credit card s issuing association 18a-d or ~rom another source within the chain of data card transaction communications. The method then proceeds to step 150S, where the hos~ computer 40 determines whether the a copy of the transaction receipt will be needed in order to respond to the chargeback. This would be the case when l0 a cardholder initiates a chargeback because he or she believes there is a discrepancy in the transaction data. It will be appreciated that certain types of chargebacks may require documentation in accordance with card issuing institution regulations, while others may not.
If a receipt is needed, the method proceeds to step 1507, where the host computer 40 causes the receipt file stored in data storage 64 to be searchecl by the reference number or other identifying information that ;s contained in the chargeback transaction, matching it against the reference number assigned by 20 the transaction processor at the time the transaction is processed~
Th;s search process is identical to the search process conducted in connection wi~h a retrieval request.
Once the receipt is located, at step 1510 the host computer causes a facsimile of dle receipt corresponding to ~e 2s disputed transaction to be printed. The receipt printed a~ this point will contain all of the transaction data including the signature, as in the case of a retrieval request. Once the receipt is printed at step 1510, ~he method proceeds to step 1513.
If at step 1505 it is determined that a copy of the 30 receipt is not needed, or after ~e receipt is printed at step 1510, the method advances to step 1513. At step 1S13, the host computer determines whether the chargeback is "retrieval related", that is, the chargeback mllst be responded to by retrieving and reproducing the transaction receipt. If the 35 transaction is retrieval related, the method proceeds to step 1517, and the receipt and chargeback are returned to the card issuer that ~ . .
.
'~ :

. . .. . ~;
:` :' genera$ed the chargeback transac$ions. If the chargeback is not retrieval related, the method proceeds instead to s~ep 151g.
At step 1519, the host computer dete~nines whether the chargeback is related to a customer dispute. If so, ~e method 5 advances to step 1522, where the dispute is researched and, if the dispute appears valid, the responsibility for the chargeback is ~ransferred to the merchant. It will be recalled that a customer dispute chargeback typically arises when the customer (cardholder) denies participating in a transaction, or is dissatisfied 10 with the goods or services purchased. When possible, the transaction processor will refute cardholder disputes by us;ng information obtained by the terminal, i.e., the card present indicator and/or the cardholder signature. In other cases, the transaction processor can not assume the risk of the chargeback, lS since the transact;on processor has no control over disputes that arose from a customer (cardholder) of the merchant. Thus, it will be left to the merchant to ret`ute charges related to these disputes.
If, at step 1520 the chargeback is determined not to 20 have arisen from a customer dispute, the method proceeds to step 1525. A~ this step, the transaction processor 12 absorbs the loss associated with the chargeback.
It will be appreciated that use of the pre~erred terminal/printer 30 can provide a transaction processor with 25 substantial assistance in connection wlth a cardholder or customer dispute mainly when the cardholder can be assuaged wi~ a copy of the receipt bearing his or her signature, and is satis~led that the signature is authentically his or hers, or is reminded (~or example by reviewing the date, merchant name and location, etc.) that he 30 or she ach~ally par~icipated in ~e ~ansactlon in ques~ion.
It will also be appreciated that use of the present inventi3n minimizes what may be termed ~'teçhnical chargebacks"
to a merchant, and allows a transaction processor ~o offer to assume the risk of such chargebacks provided that the merchant 35 uses a terminal cons~ructed in accordance with the present invention. Technical chargebacks often result ~rom erroneous : .

l27 keying in of transaction data, such as the account number or purchase amo~mt, by the merchant. While the preferred ~erminal cannot assist the merchant in keying in the proper purchase amount, when coupled with known bar code scanners, comlected s to one of the RS-232 serial ports 208 associated with the terminal 35, the terminal can minimize amount entry errors.
By ensuring that a card is presen~ during every transaction ~such as by verifying the account number read from a second track and/or the embossed card reader against a first lO track's account number), obtaining an authorization from an authori~ation source, bar code scanning the UPC codes to obtain purchase amoun~s, automatically computing ta~es and other discounts, and requiring that a signature be obtained before a transaction will be accepted at the terminal, systems constructed 15 in accordance with the present invention proYide transaction processors and their customers/merchants with high levels of assurance that a given transaction will not be charged back because of keying errors or other technical reasons.
Furthermore, since the sarne transaction data is used for the initial 20 transaction capture, authorization, clearing (closing), and settlement, use of systems and terminals constructed in accordance with the present invention reduces keying errors and thereby fur~er minimizes the likelihood of a technical chargeback.
2s O~-Line Authorization System and Methods Turning now to FIG. 35, a method 1600 tha~ is employed to request an off-line authorization approval will be described. Generally, the method 1600 allows a merchant to obtain an authorization detelmination in the situation wherein the terminal is unable to ~omrnunicate with ~e host or whenever a card issuer has issued a "call me" refelTal in order to speak wi~h the merchant. The method illustrated in FIG. 35 is preferably implemented as a compu~er program opera~ive in the audio response unit ~ARU) 70 in the preferred transaction processing system 12 shown in FIG. 2.

.
. .

- ~
: ..... , .: .
~ , : .

Starting at step 1601, the program resident in the ARU 70 examines the number dialed (DNIS). Those skilled in the art will understand that many transaction processors utilize telecommunications services provided by private telecommunications firms (such as AT&T, US SPRINT, MCI, etc.) for connecting merchant terminals ~o their host systems.
Such private telecommunications providers have the ability to identify calls originating with certain merchants by virtue of the phone number dialed in order to access a particular incoming telephone line. This capability is called by those skilled in the art as "DNIS". Essentially, DNIS comprises information available to the ARU 70 concerning the number dialed by an incoming caU on a part;cular telephone line. DNIS typically allows identification of a particular merchant or category of merchant (for example, one category of merchant may include large retailers conducting business from a number of stores ~rough a centralized facility) that is a customer of the transaction processor 12, as well as determination whether a merchant has DTMF-capable telephone equipment or rotary dial equipmenl:.~
Similarly, telecommunications feaeures known as "automatic number identification'~ or "ANI" are also available from telecommunications providers. ANI-capable telecom-munications results in the provision of information identifying the "calling number" or the telephone number from which the 2s incomislg telephone call originated. This information is provided at ~e begilming of an incoming telephone call and contains the telephone number of ~e onginating telephone.
If at step 1601 ~e examined DNIS is one assigned ~o merchants with rotary telephones, the program proceeds to step 1605. If a non-rotary telephone nu~ber was dialed, the program then proceeds to step 1607.
At step 1607, the program checks the dialed number ~DNIS3 for one of a series of unique mJmbers assigned to specific merchants. If a match is found, the program proceeds to step 3s 1610. At step 1610, the number is searched against a table of numbers in order to determine a merchant iden~ification number which9 in turn, is placed in the merchant number field of a host authorization transaction record. The program than proceeds to step 1613.
Returning to step 1607, if ANI has been provided by 5 the telecommunications provider, the pro~ram will also check for the existence of a merchant mlmber in a file ordered by the calling telephone number. If a match is found, the merchant number found will be inserted in the host au~horization transaction record and the program will proceed to step 1613.
Returning to step 1607, if neither the number called nor the calling number is indicative of ~e merchant, the program will proceed to step 1613. At step 1613 ~e program causes the ARU to accept the sale amount and car&older account nurnber, if present in the form of DTMF signals from the terminal. In the lS event the data has not been presented by the merchant or by a data card terminal constructed in accordance with the present invention9 with of~-line transaction capability, the program ~ill cause the ARU to request the data, one field at a time, where needed. If some data elements are already present, such as the 20 merchant number, this field will not be requested. Similarly, individual fields may be re-requested in an iterative process if subsequent validation logic detects errors or omissions. The program then proceeds to step 1619.
At step 1619, the ARU program tests for the receipt 25 of any DTMF tones. If none are found (as where a merchant used a rotary phone or opted to ignore TOUCH-TC)NE~ response requests), the program proceeds ~o step 1605. If DTMF tones were received, the program proceeds to step 1621.
At step 1621, ~he program checks each field for a 30 variety of conditions, depending on the individual ~lelds. Among ~hese are field length~ numeric content, reasonableness, and, in the case of a cardholder account number, check digit verification. If an error is found in any field, the program proceeds to step 1625 before proceeding to edit the nex~ field.

, ... , . ~
, . .

.

r~ t At step 1625, the program checks for the validation status of eaeh field. If an error is found, the program proceeds to s~ep 1628.
At step 1628, a program counter is checked to 5 determine if previous attempts have been made within the current transaction to re-request the erroneous field. If there have been previous attempts, the number of attempts is compared to a program constant to control the number of iterations of requests.
Currently, the preferred value of this constant is '2', allowing two 10 attempts at ob~aining the data for each field. The preferred program, however5 allows for ease of changing the value of this constan~ based on experience gained in the operation of the system. If the maximum number of attempts has been made and a validation error condition still exists, the program will proceed to 15 step 160S. If the maximum mlm~r of attempts have not been made, the program will retum to step 1613 to re-request the data for ~he field in error.
Returning to step l 6 2 S, if the program has determined that all data fields have passed all the edit criteria, the 20 program then proceeds to step 1630.
At step 1630 the program checks ~or the availability of the mainframe host authorization computer. If coIILmunications with the host computer are not able ~o be established, the host computer is deemed to be not available and 2S ~e program proceed to step 1633.
At step 1~33 the program compares the sale amount of the host authorization transaction to a program constant identified as a floor limi~ he sale amount is greater than the floor limit, the program proceeds to s~ep 1635. If the sale 30 amoun~ is equal or less than dle ~loor limit, the program proceeds to step 1640.
A~ step 16 4 0, the program generates an au~onzation approval ~ode and proceeds to seep 1680.
Returning to step 1630, ;f the program is able to 3s communicate with the host computer, the host is deemed to be available and the program proceeds to step ll6S0. At step 1650, $

the host authorization transac~ion is transmitted to the host computer and when a response is received, ~he program proceeds to step 1652.
At step lL652, the authorization response received s from the host cornputer is analyzed in order to determine ~he ensuing steps to be taken. If the response was an approval, the program proceeds to step 1655.
At step 1655, the program edits the authori~ation response code received from the host computer. Once the 10 response code is received from the authorization source, the program substitutes any alphabetic characters in the low-order, or terminating position of the authorization code with a zero. The two low-order positions of the au~orization code are then moved to the ARU response code field and the program proceeds to step 15 16~.
At step 1680, the program checks the number dialed to deterrnine if the transaction originated from a data card terminal constructed in accordance with the present invention with off-line authorization transaction generation capability. If it 20 did, the program then proceeds to step 1681.
At step 1681, the program calculates a check digit based on information that is already contained in the terminal, such as the account number, expiration date, purchase amount, transaction date, etc., and appends it to the end of the two-digit 25 ARU response code, for form a three-digit approval code. The ARU response code thus formed is stored by the ARU in a manner ~a~ corresponds with the authonzation indicia that was received from the authorization source, so that the authorization indicia may subsequently be associated with the transaction. The 30 program then proceeds to step 1682.
Returning to s~ep 168Q, if the program determines from the number dialed (DNIS) that the transaction did not originate at a data terminal eonstructed in accordance with the present invention with off-line authorization capability, the 3s program proceeds to step 1682.

: : ~ ,. ~ . ,- :
: : , . ; ~ . i At step 1682, the program causes the ARU to speak an approval message along with the original sale amount and the three-digit ARIJ approval code. Currently, the preferred form of this message is '~Your approval for X dollars is Y'~, where X is s the original sale amount and Y is the three-digit ARU approval code or indicia (including the check digit). The form and content of this message may be varied from time to time to promote better comprehension by ~he merchant while keeping ~e duration of the rnessage as short as possible, consistent wi~ the need for 0 comprehension by ~e merchant. The program then proceeds to step 1685.
At step 168~, the program causes the ARU to pause approximately three seconds before proceeding to step 1688.
The time interval may be changed from time to time to 15 accommodate the needs of merchants that may not have heard, comprehended, or noted the response issued at 1682.
At step 1688, the approval message spoken at step 16~2 is repeated, the call is disconnected, and then the program exits the routine.
At step 160$ the prograrn causes the ARU to accept the sal~ amount, cardholder number, through the use of voice recognition circuitry in the ARU. ~n the event the data has not been presented by the merchant via a data card termirlal cons~ucted in accordance with the present invention, having OI~-2s line authorization capability, the program will cause the ARlJ to request ~e data, one field at a time, where needed. If some data elements are already presen~, such as the merchant num~er, this field will not be requested. Similarly, individual filelds may be re-requested in an itera~ive process if subsequent valida~ion logic 30 detects errors or omissions. ~e program then proceeds to s~ep 1691.
At step 1691 the program checks each field for a variety of conditions, depending on ~he indlvidual ~lelds. Among ~ese are field length, numeric content, reasonableness, and, in the 3s case of a cardholder number, check digit verification. If an error is ~ound in any field, the program proceeds to step 1693 before proceeding to edit the nex~ field.
At step 1693, the program checks for the valida~ion status of each field. If an error is i~ound, the program proceeds to s step 1695.
At step 1695, a program counter is checked to determine if previous attempts have ~en made wi~in the current transaction to re-request the erroneous field. If there have been previous attempts, the number of attempts is compared to one of 0 two program constants to control the nwnber of iterations of reques~s. Currently, ~he pre~erred value of these constants are '2' and '3'9 allowing two or ~ree attempts at obtaining ~e data for each field. If no DTMF tones were ever received, the constant '3' is used to control the number of iterations. If DTMF tones were detected, the constant '2' is used. The preferred program is written to allow for ease of changing the value of these constants based on experience gained in the operation of the off-line authorization system.
If the maximum allowed number of at~empts has been made and a validation error condition still exists, the program will proceed to step 1635 If the maximum number of attempts have not been made, the program will return to step 1605 to re-reques~ ~e data ~or the ~leld in elTor.
Reb~rning to step 1693, ~e program has determined 2~ that all data fields have passed all the edit criteria, the program th m proceeds to step 1630.
Retuming now to step 1652, if the authoriza~ion response received from the host computer was a '6decline", the program then proceeds to step 1697. At step 1697, the program czuse3 the ARU to speak a "decline" message of the currently pre~rred form, "Your customer's ~ank has declined this transaction9'9 disconnect the call, and then e~its. The form and con~ent of ~his message may vary ~rom time to time to accommodate the need for comprehension by ~e merchant.
3s Returning again to step 1652, if the au~horization response received from the host computer was a "referral", the : .

t ~ , program ~en proceeds to step 1635. At step 163~, the program causes the ARU to speak a "r~ferral" message of the foIm "Please hold", ~en automa~ically transfers the call, along wi~ identifying data, to an operator in the voice services department 72 ~FIG. 2).
5 The program then exits.
The present invention has been described in relation to particular embodiments which are intended in all respects to be illustrated rather than restrictive. Alternative embodiments will become apparent to those skilled in the art to which the present 10 invention pertains without departing from its spirit and scope.
Accordingly, the scope of the present invention is defined by the appended claims rather than the foregoing description.

, :

.

Claims (141)

1. A data card transaction terminal operative for communicating information corresponding to a data card transaction, comprising:
card reading means for obtaining card identifying information from an information source associated with a data card;
signature means for capturing a signature of a customer in connection with a proposed transaction and for providing signature signals; and communication means for communicating said card identifying information and said signature signals to a remote transaction processor.

2. The terminal of Claim 1, further comprising card detecting means for detecting the physical presence of a data card presented in connection with a proposed transaction and for providing a card present signal.

3. The terminal of Claim 2, wherein said card detecting means comprises means for reading a magnetic stripe associated with the data card.

4. The terminal of Claim 2, wherein said card detecting means comprises means for detected embossed characters formed in the data card.

5. The terminal of Claim 1, wherein said card identifying information obtaining means comprises means for reading a magnetic stripe associated with the data card.

6. The terminal of Claim 1, wherein said card identifying information obtaining means comprises means for detecting embossed characters formed in the data card.

7. The terminal of Claim 1, further comprising authorization means for requesting transaction authorization indicia from an authorization source.

8. The terminal of Claim 1, wherein said card identifying information is provided in a plurality of sources on the data card, wherein said card reading means is operative for obtaining said card identifying information from a first source of said plurality of sources and from a second source of said plurality of sources; and further comprising:
means for verifying the accuracy of card identifying information obtained from said first source;
means for restoring at least a portion of said card identifying information obtained from said first source with information obtained from said second source in response to a determination by said verifying means that said card identifying information obtained from said first source is not accurate.

9. The terminal of Claim 8, wherein said first source comprises a magnetic stripe reader, and wherein said second source comprises an embossed card reader.

10. The terminal of Claim 9, wherein said card identifying information comprises an account number associated with the data card, and wherein said verifying means comprises means for computing a longitudinal redundancy check (LRC) associated with said magnetic stripe, and wherein said restoring means is operative for restoring at least a portion of the account number read from said magnetic stripe reader with at least a portion of the account number read from said embossed card reader if said verifying means determines that data read from said magnetic stripe is not accurate or complete.

11. The terminal of Claim 8, wherein said first source comprises a magnetic stripe reader operative for reading a first track associated with the magnetic stripe on the data card, and wherein said second source comprises a magnetic stripe reader operative for reading a second track associated with the magnetic stripe on data card.

12. The system of Claim 11, wherein said card identifying information comprises an account number associated with the data card, and wherein said verifying means comprises means for computing a longitudinal redundancy check (LRC) associated with said first track, and wherein said restoring means is operative for restoring at least a portion of the account number read from said first track with at least a portion of the account number read from said second track if said verifying means determines that data read from said first track is not accurate or complete.

13. A data card transaction terminal, comprising:
means for reading a magnetic stripe associated with a data card presented in connection with a proposed transaction and for providing card identifying information;
embossed card reader means for detecting embossed characters formed in the data card and for providing card identifying information;
signature means for capturing a signature of a cardholder in connection with a proposed transaction and for providing signature signals; and communication means for communicating signals associated with a data card transaction to a remote transaction processor.

14. The terminal of Claim 13, further comprising means for detecting the physical presence of a data card at the terminal and for providing a card present flag; and means responsive to said card present flag, digital signature signals provided by said signature means, and said card identifying information from said magnetic stripe reading means or said embossed characters detecting means for providing a transaction protected flag associated with said transaction information.

15. The terminal of Claim 14, wherein said communication means is operative for requesting and receiving an authorization indicia from an authorization source, and wherein said transaction protected flag providing means is responsive to said authorization indicia, said card present flag, said digital signature signals, and said card identifying information for providing said transaction protected flag.

16. The terminal of Claim 13, wherein said signals communicated to said remote transaction processor include an authorization request signal for requesting authorization indicia from an authorization source, and wherein said communication means is operative for communicating said authorization request signal to an authorization source as a request for authorization indicia.

17. The terminal of Claim 16, wherein said signals communicated to said remote transaction processor include said signature signals and transaction information signals, and wherein said communication means is operative for transmitting said signature signals and said transaction information signals to said remote transaction processor while the terminal is communicating with said transaction processor for requesting said authorization indicia.

18. The terminal of Claim 17, further comprising memory means for storing said signature signals and said transaction information signals as a transaction record in a transaction batch, and wherein said communication means is operative for transmitting said transaction batch to said remote transaction processor during a communications session.

19. The terminal of Claim 18, wherein said communication means is operative for communicating a transaction record associated with a transaction being conducted at the terminal during an authorization communications session when said communication means communicates with said remote transaction processor for requesting said authorization indicia, and is alternatively operative for transmitting said transaction record to said remote transaction processor during a subsequent communications session in the event that the terminal is unable to communicate with the remote transaction processor during said authorization communications session.

20. The terminal of Claim 14, wherein said signals communicated to said remote transaction processor include said transaction protected flag.

21. The terminal of Claim 14, wherein said card present detecting means comprises said magnetic stripe reading means.

22. The terminal of Claim 14, wherein said card present detecting means comprises said embossed card reader means.

23. The terminal of Claim 13, wherein said card identifying information comprises an account number associated with the data card.

24. The terminal of Claim 13, wherein said magnetic stripe reading means comprises means for reading a first track of information stored on the magnetic stripe of a data card and means for reading a second track of information stored on the magnetic stripe of the data card, said first track and said second track including said card identifying information, and further comprising means for restoring a portion of said card identifying information read from said first track with card identifying information read from said second track.

25. The terminal of Claim 24, wherein said card identifying information provided by said magnetic stripe reading means comprises an account number associated with the data card, and further comprising means for verifying the accuracy of the data read from said first track, and wherein said restoring means is operative for restoring at least a portion of the account number read from said first track with at least a portion of the account number read from said second track if said verifying means detects that the data read from said first track is not accurate or complete.

26. The terminal of Claim 25, wherein said verifying means comprises longitudinal redundancy check (LRC) means.

27. The terminal of Claim 25, wherein said verifying means comprises means for validating a checksum digit associated with the account number.

28. The terminal of Claim 13, further comprising means for restoring at least a portion of said card identifying information read from said magnetic stripe reading means with at least a portion of said card identifying information provided by said embossed card reader means.

29. The terminal of Claim 28, further comprising means for verifying the accuracy of said card identifying information provided by said magnetic stripe reading means, and wherein said restoring means is operative for restoring at least a portion of card identifying information provided by said magnetic stripe reading means with at least a portion of said card identifying information provided by said embossed card reader means if said verifying means detects that said card identifying information provided by said magnetic stripe reading means is not accurate.

30. The terminal of Claim 29, wherein said verifying means comprises longitudinal redundancy check (LRC) means.

31. The terminal of Claim 29, wherein said verifying means comprises means for validating a checksum digit associated with the account number.

32. A data card transaction terminal, comprising:
means for detecting the physical presence of a data card at a data card terminal at which a transaction is recorded and for providing a card present flag, said data card terminal being utilized by a merchant, said data card terminal being further operative for obtaining transaction information corresponding to the particular transaction;
means for electronically obtaining card identifying information relating to the data card from an information carrying medium associated with the data card;
means for capturing a signature provided by a holder of the data card who is purportedly authorized to conduct a transaction with the data card and for providing signature signals corresponding to the signature; and means responsive to said card present flag, said signature signals, and said card identifying information from said card identifying information obtaining means for providing a transaction protected flag associated with said transaction information.

33. The terminal of Claim 32, wherein said card identifying information comprises an account number associated with the data card.

34. The terminal of Claim 32, wherein said card identifying information is stored on a magnetic stripe associated with the data card, and wherein said card identifying information obtaining means comprises magnetic stripe reading means operative to obtain at least a portion of said card identifying information from the data card.

35. The terminal of Claim 34, wherein said magnetic stripe reading means comprises means for reading a first track of information stored on the magnetic stripe of the data card and means for reading a second track of information stored on the magnetic stripe of the data card, said first track and said second track including said card identifying information, and further comprising means for restoring at least a portion of said card identifying information read from said first track with card identifying information read from said second track.

36. The terminal of Claim 35, wherein said card identifying information comprises an account number and/or an expiration date associated with the data card, and further comprising means for verifying the accuracy of the data read from said first track, and wherein said restoring means is operative for restoring at least a portion of the account number and/or the expiration date read from said first track with at least a portion of the account number and/or the expiration date read from said second track if said verifying means detects that the data read from said first track is not accurate.

37. The terminal of Claim 36, wherein said verifying means comprises longitudinal redundancy check (LRC) means.

38. The terminal of Claim 35, wherein said card identifying information comprises an account number associated with the data card, and further comprising means for verifying the accuracy of the account number read from said first track, and wherein said restoring means is operative for restoring at least a portion of the account number read from said first track with at least a portion of the account number read from said second track if said verifying means detects that the account number read from said first track is not accurate.

39. The terminal of Claim 38, wherein said verifying means comprises means for validating a checksum digit associated with the account number.

40. The terminal of Claim 34, wherein said card identifying information obtaining means further comprises an embossed card reader operative to obtain at least a portion of said card identifying information from an embossed character region of the data card, and further comprising means for restoring at least a portion of said card identifying information obtained by said magnetic stripe reading means with card identifying information obtained by said embossed card reader.

41. The terminal of Claim 40, wherein said card identifying information comprises an account number and/or an expiration date associated with the data card, and further comprising means for verifying the accuracy of the data read by said magnetic stripe reading means, and wherein said restoring means is operative for restoring at least a portion of the account number and/or the expiration date read by said magnetic stripe reading means with at least a portion of the account number and/or the expiration date read by said embossed card reader if said verifying means detects that the data read from said first track is not accurate.

42. The terminal of Claim 32, wherein said card identifying information is embossed in an embossed character region on the data card, and wherein said card identifying information obtaining means comprises an embossed card reader operative to obtain at least a portion of said card identifying information from the embossed character region of the data card.

43. The system of Claim 42, wherein said embossed card reader comprises:
means for detecting the insertion of an embossed data card and for providing a card inserted signal;
a tactile imaging array for providing matrix signals corresponding to the impression of a contacted object;
contacting means responsive to said card inserted signal for causing said tactile imaging array to operatively contact with the embossed character region of the inserted data card; and means responsive for interpreting said matrix signals from said tactile imaging array and for providing a data output corresponding to the embossed characters in said embossed character region.

44. The system of Claim 43, wherein said contacting means comprises:
a pressure plate comprising a pressure applying region corresponding to the embossed character region of the inserted data card; and means for biasing said pressure plate against the inserted data card, whereby said tactile imaging array contacts with the embossed region of the inserted data card when said pressure plate is biased by said biasing means.

45. The system of Claim 44, wherein said contacting means further comprises:
a drive motor;
a first switch operative to be actuated upon insertion of the data card and apply power to said drive motor; and cam means rotatably attached to said drive motor for releasing said pressure plate to be biased by said biasing means, such that said pressure plate is held away from said tactile imaging array when no card is present.

46. The system of Claim 45, further comprising a first switch actuating arm for initially contacting an inserted data card and for actuating said first switch.

47. The system of Claim 45, wherein said cam means comprises a cam shaft operative to rotate in response to motion by said drive motor.

48. The system of Claim 47, wherein said cam shaft assumes an initial position such that an edge of said pressure plate is lowered to facilitate insertion of the data card, and a half-way position that allows said pressure plate to pivot against the inserted data card.

49. The system of Claim 45, further comprising:
a pressure plate actuating arm operatively connected to said pressure plate; and a second switch positioned to be actuated by said pressure plate actuating arm, for removing power from said drive motor upon completion of movement of said cam means.

50. The system of Claim 45, wherein said pressure plate is pivoted by said cam means to bring said pressure applying region into contact with the inserted data card.

51. The terminal of Claim 42, wherein said card identifying information is also stored on a magnetic stripe associated with the data card, wherein said card identifying information obtaining means further comprises magnetic stripe reading means operative to obtain at least a portion of said card identifying information from the data card, and further comprising:
means for restoring at least a portion of said card identifying information read from said magnetic stripe reading means with at least a portion of said card identifying information provided by said embossed card reader.

52. The terminal of Claim 32, wherein said card present flag comprises information indicative that said card identifying information obtaining means successfully obtained said card identifying information electronically from the data card.

53. The terminal of Claim 52, wherein said card identifying information obtaining means comprises a magnetic stripe reader for obtaining said card identifying information from a magnetic stripe on the data card.

54. The terminal of Claim 52, wherein said card identifying information obtaining means comprises an embossed card reader for obtaining said card identifying information from an embossed character region on the data card.

55. The terminal of Claim 32, wherein said card identifying information is provided in a plurality of sources on the data card, wherein said card identifying information obtaining means comprises means for obtaining said card identifying information from a first source of said plurality of sources and from a second source of said plurality of sources; and further comprising:
means for verifying the accuracy of card identifying information obtained from said first source;
means for restoring at least a portion of said card identifying information obtained from said first source with information obtained from said second source in response to a determination by said verifying means that said card identifying information obtained from said first source is not accurate or complete.

56. The terminal of Claim 55, wherein said first source comprises a magnetic stripe reader, and wherein said second source comprises an embossed card reader.

57. The terminal of Claim 56, wherein said card identifying information comprises an account number associated with the data card, and wherein said verifying means comprises means for checking a checksum associated with said account number, and wherein said restoring means is operative for restoring at least a portion of the account number read from said magnetic stripe reader with at least a portion of the account member read from said embossed card reader.

58. The terminal of Claim 56, wherein said first source comprises a magnetic stripe reader operative for reading a first track associated with the magnetic stripe on the data card, and wherein said second source comprises a magnetic stripe reader operative for reading a second track associated with the magnetic stripe on data card.

59. The terminal of Claim 32, further comprising communication means for communicating said transaction information, said signature signals, and said transaction protected flag from said data card terminal to a remote transaction processing means.

60. The terminal of Claim 59, further comprising chargeback protection flag means associated with said data card terminal for indicating whether transactions conducted with said data card terminal are chargeback protected, and wherein said communication means is operative for receiving indicia transmitted from a remote location for selectively setting said chargeback protection flag.

61. The terminal of Claim 60, wherein said transaction protected flag means is further responsive to the state of said chargeback protection flag for providing said transaction protected flag.

62. The terminal of Claim 59, wherein said communication means is operative for receiving transaction authorization indicia from a remotely located authorization source, and wherein said transaction protected flag providing means is responsive to said authorization indicia, said card present flag, said signature signals, and said card identifying information from said card identifying information obtaining means for providing said transaction protected flag.

63. The terminal of Claim 62, further comprising chargeback protection flag means for indicating whether transactions conducted with said data card terminal are chargeback protected, and wherein said transaction protected flag means is further responsive to the state of said chargeback protection flag for providing said transaction protected flag.

64. The terminal of Claim 55, wherein said communication means is operative for receiving indicia transmitted from a remote location for selectively setting said chargeback protection flag.

65. The terminal of Claim 62, wherein said remotely located authorization source comprises a computer system associated with a transaction processor, card issuing association, or a card issuer.

66. The terminal of Claim 62, wherein said transaction processor host computer system operates as said authorization source, wherein said data card terminal communicates with said transaction processor host computer system for obtaining said authorization indicia, and wherein said data card terminal is operative for transmitting said signature signals, said transaction protected flag, and said transaction information to said transaction processor host computer system while said data card terminal is communicating with said host computer system for obtaining said authorization indicia.

67. The terminal of Claim 66, further comprising memory means in said data card terminal for storing said signature signals, said transaction protected flag, and said transaction information as a transaction record in a transaction batch, and wherein said data card terminal is operative for transmitting said transaction batch to said transaction processor host computer system during a communications session.

68. The terminal of claim 67, wherein said data card terminal is operative for communicating a transaction record associated with a transaction being conducted at the data card terminal during an authorization communications session when said data card terminal communicates with said transaction processor host computer system for obtaining said authorization indicia, and is alternatively operative for transmitting said transaction record to said transaction processor host computer system during a subsequent communications session in the event that said data card terminal is unable to communicate with said transaction processor host computer system during an authorization communications session.

69. The terminal of Claim 32, wherein said signature capturing means comprises:
a stylus;
a signature capturing window in which the card holder enters a signature with said stylus;
digitizer means for providing coordinate position signals of said stylus with respect to said signature capturing window;
means for compressing said coordinate position signals and for providing compressed signature signals.

70. The terminal of Claim 69, wherein said compressed signature signals comprise digital signals.

71. The terminal of Claim 69, further comprising contact signal means for providing a contact signal indicative of the stylus being in operative contact with said signature capturing window, and stroke detecting means responsive to said contact signal for causing said compressing means to provide a stroke signal indicative of the starting coordinate and the final coordinate of each stroke of a signature.

72. The terminal of Claim 71, further comprising stroke counting means for providing a stroke count signal corresponding to the number of strokes in a signature, and wherein said signature signals comprise said stroke count signal and a plurality of coordinate position difference signals corresponding to differences between said coordinate position signals provided by said digitizer means.

.alpha.

73. The terminal of Claim 69, wherein said compressing means comprises:
means for providing a stroke started signal;
means for providing a stroke completed signal;
means for determining a number N of strokes in a signature, a stroke being determined by an initial starting coordinate provided in response to said stroke started signal and a final coordinate provided in response to said stroke completed signal;
means for providing, for each stroke of the N strokes in the graphic object, compressed output signals comprising a difference between a first coordinate position signal provided at a first sample time from said digitizer means and a second coordinate position signal provided at a second sample time from said digitizer means.

74. The terminal of Claim 73, wherein said compressed output signals comprise an a bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is less than a first predetermined value; and a b bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is greater than said first predetermined value but less than a second predetermined value, where a is less than b.

75. A data card terminal operative for receiving electronic authorizations in connection with a proposed transaction associated with a data card presented by a cardholder to a merchant, comprising:
first communication means for automatically connecting the terminal for data communications with a transaction processing host computer system via a first telecommunications link;
second communications means for automatically connecting the terminal for data communications with the transaction processing host computer system via a separate second telecommunications link in response to failure to establish said first telecommunications link;
third communications means for automatically connecting the terminal for communications with an audio response unit (ARU) via a separate third telecommunications link in response to failure to establish said first telecommunications link or said second telecommunications link;
means for requesting authorization indicia from transaction processing host computer system via said first telecommunications link or said second telecommunications link in connection with a proposed transaction;
audio means for providing an audible authorization indicia from the audio response unit (ARU) to the merchant;

means for receiving the manual entry of said audible authorization indicia from the merchant as manually entered authorization indicia;
means for verifying said manually entered authorization indicia; and means for storing authorization indicia received from said transaction processing host computer system or said manually entered authorization indicia.

76. The terminal of Claim 75, wherein said authorization indicia received via said first telecommunication link or said second telecommunication link are automatically associated with other transaction data and stored in the terminal for subsequent communication to said transaction processing host computer system.

77. The terminal of Claim 75, further comprising:
means for detecting an account number associated with the data card presented by the cardholder in connection with the proposed transaction;
means for automatically providing said detected account number to said transaction processing host computer system or said ARU.

78. The terminal of Claim 77, wherein said account number providing means comprises digital signal means for providing said detected account number to said transaction processing host computer system, and DTMF means for providing said detected account number to said ARU.

79. The terminal of Claim 75, wherein said audio means comprises a telephone handset.

80. The terminal of Claim 75, wherein said audio means comprises a speaker.

81. The terminal of Claim 75, wherein said transaction processing host computer system or an authorization source connected to said transaction processing host computer system may provide said authorization indicia or alternatively may provide a "call me" signal, and wherein said third communication means is operative, in response to said call me signal or in response to failure to establish communications with said transaction processing host computer system, for:
automatically dialing a telephone number associated with said audio response unit (ARU);
providing information associated with the data card and with the proposed transaction in the form of DTMF
signals via said third telecommunications link; and connecting said audible third authorization indicia from the ARU to said audio means.

82. The terminal of Claim 81, wherein said first telecommunication link comprises a computer communications network accessed via the public switched telephone network;
wherein second telecommunication link comprises a computer communications network accessed via the public switched telephone network that is independent of said first telecommunications link; and wherein said third communications link comprises a voice grade telephone line.

83. A method for obtaining transaction authorizations in connection with a proposed transaction associated with a data card presented by a cardholder to a merchant utilizing a data card terminal, comprising the steps of:
automatically attempting to connect the terminal for data communications with a transaction processing host computer system via a first telecommunications link;
requesting authorization indicia from said transaction processing host computer system via said first telecommunications link in connection with the proposed transaction;
receiving authorization indicia from said transaction processing host computer system;
processing the proposed transaction in response to receipt of the authorization indicia;
in the event that communications with said transaction processing host computer system were not established via said first telecommunication link, automatically attempting to connect the terminal for data communications with said transaction processing host computer system via a separate second telecommunications link;
requesting authorization indicia from transaction processing host computer system via said second telecommunications link in connection with the proposed transaction;
receiving authorization indicia from said transaction processing host computer system;

processing the proposed transaction in response to receipt of the authorization indicia;
in the event that communications with said transaction processing host computer system were not established, automatically attempting to connect the terminal for communications with an audio response unit (ARU) via a separate third telecommunications link;
requesting authorization indicia from said ARU via said third telecommunications link in connection with a proposed transaction;
receiving an audible authorization indicia from the audio response unit (ARU) to the merchant via the third telecommunications link;
receiving the manual entry of the audible authorization indicia from the merchant as manually entered authorization indicia;
verifying the manually entered authorization indicia;
and storing authorization indicia received from the transaction processing host computer system or the manually entered authorization indicia.

84. The method of Claim 83, further comprising the steps of:
detecting an account number associated with the data card presented by the cardholder in connection with the proposed transaction;
automatically providing the detected account number to the transaction processing host computer system or the ARU.

85. The method of Claim 84, wherein the step of automatically providing the detected account number comprises providing the detected account number by digital signals to the transaction processing host computer system and by DTMF tones to the ARU.

86. The method of Claim 83, wherein the step of receiving an audible authorization indicia from the ARU
comprises delivering synthesized speech messages to the merchant via a telephone handset, wherein the transaction processing host computer system or an authorization source connected to the transaction processing host computer system may provide the authorization indicia or alternatively may provide a "call me" signal, and further comprising the steps of:
in response to the call me signal or in response to failure to establish communications with the transaction processing host computer system, automatically dialing a telephone number associated with the audio response unit (ARU);
providing information associated with the data card and with the proposed transaction in the form of DTMF
signals via the third telecommunications link; and connecting the audible third authorization indicia from the ARU to audio means associated with the terminal.

87. The method of Claim 86, wherein the first telecommunication link comprises a computer communications network accessed via a public switched telephone network;
wherein the second telecommunication link comprises a computer communications network accessed via the public switched telephone network that is independent of the first telecommunications link; and wherein the third communications link comprises a voice grade telephone line.

88. A method for providing electronic authorizations in connection with a proposed transaction associated with a data card presented by a cardholder to a merchant utilizing a data card terminal, comprising the steps of:
(1) automatically attempting to connect the terminal for communications via a telecommunications link to an authorization computer system;
(2) in response to failure to connect the terminal to the authorization computer system or in response to receipt of a call me signal from the authorization computer system, automatically attempting to connect the terminal with an audio response unit (ARU) via a second telecommunications link;
(3) in response to connection of the terminal to the ARU, providing information associated with the data card and with the proposed transaction in the form of signals to the ARU;
and (4) providing an audible authorization approval code received from the ARU to the merchant.

89. The method of Claim 88, wherein the method is carried out by a data card terminal including audio means, and wherein the step of attempting to connect the terminal with an audio response unit (ARU) via a second telecommunications link comprises:
automatically dialing a telephone number associated with the ARU;
connecting audible authorization indicia from the ARU to the audio means.

90. The method of Claim 89, wherein the audio means is a speaker.

91. The method of Claim 89, wherein the audio means is a telephone handset, and further comprising the step of providing a signal to an operator of the terminal to pick up the handset; and connecting the audible authorization indicia from the ARU to the handset.

92. The method of Claim 89, wherein the step of providing information associated with the data card and with the proposed transaction in the form of data signals to the ARU
comprises providing DTMF signals corresponding to the data card information and the proposed transaction.

93. The method of Claim 88, further comprising the steps of:
prompting a terminal operator to enter the audible authorization code into a keyboard associated with the terminal;
in response to entry of the authorization code at the terminal, validating a check digit associated with the transaction data to detect keying errors or fictitious codes;
in response to detection that an incorrect code has been entered, prompting the terminal operator to re-enter the code; and in the event that a valid code is not entered after a predetermined number of attempts by the terminal operator, voiding the transaction.

94. The method of Claim 88, further comprising the steps of:
prompting a terminal operator to enter the audible authorization code into a keyboard associated with the terminal;
in response to entry of the authorization code at the terminal, identifying the transaction as containing an "off line"
authorization code in the terminal;
storing transaction data associated with transactions indicated as "off line" in a memory associated with the terminal;
subsequently transmitting transaction data identified as containing an "off line" authorization code to a transaction processing computer system via a telecommunications link.

95. A signature capturing printer, comprising:
printer means for printing characters represented by an information signal provided to said printer; and signature capturing means for capturing a signature in connection with the transaction and for providing signature signals.

96. The signature capturing printer of Claim 95, further comprising memory means for storing said signature signals.

97. The signature capturing printer of Claim 96, further comprising data compression means for compressing said signature signals and for providing compressed signature signals, and wherein said memory means stores said compressed signature signals.

98. The signature capturing printer of Claim 95, further comprising communication means for communicating said signature signals to an external location.

99. The signature capturing printer of Claim 95, wherein said signature capturing means comprises:
a stylus;
a signature capturing window in which the card holder enters a signature with said stylus;
digitizer means for providing coordinate position signals of said stylus with respect to said signature capturing window;
means for compressing said coordinate position signals and for providing compressed signature signals.

100. The signature capturing printer of Claim 99, further comprising contact signal means for providing a contact signal indicative of the stylus being in operative contact with said signature capturing window, and stroke detecting means responsive to said contact signal for causing said compressing means to provide a stroke signal indicative of the starting coordinate and the final coordinate of each stroke of a signature.

101. The signature capturing printer of Claim 100, further comprising stroke counting means for providing a stroke count signal corresponding to the number of strokes in a signature, and wherein said signature signals comprise said stroke count signal and a plurality of coordinate position difference signals corresponding to differences between said coordinate position signals provided by said digitizer means.

102. The signature capturing printer of Claim 99, wherein said compressing means comprises:
means for providing a stroke started signal;
means for providing a stroke completed signal;
means for determining a number N of strokes in a signature, a stroke being determined by an initial starting coordinate provided in response to said stroke started signal and a final coordinate provided in response to said stroke completed signal;
means for providing, for each stroke of the N strokes in the graphic object, compressed output signals comprising a difference between a first coordinate position signal provided at a first sample time from said digitizer means and a second coordinate position signal provided at a second sample time from said digitizer means.

103. The signature capturing printer of Claim 102, wherein said compressed output signals comprise an a bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is less than a first predetermined value; and a b bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is greater than said first predetermined value but less than a second predetermined value, where a is less than b.

104. A transaction terminal operative for communicating information corresponding to a transaction concurrently with the transaction, comprising:
transaction means for obtaining transaction information corresponding to a proposed transaction;
signature means for capturing a signature of a customer in connection with the proposed transaction and for providing signature signals;
memory means for storing said signature signals and said transaction information;
communication means for attempting to communicate said transaction information and said signature signals to a remote transaction processor during an initial time period substantially concurrently with the transaction, said memory means operative to retain said transaction information and signature signals in the event that said communication means is unable to communicate same to said remote transaction processor during said initial time period, said communication means being operative for attempting to communicate said transaction information and said signature signals to said remote transaction processor during a second time period subsequent to said initial time period in the event that said signals were not communicated during said initial time period.

105. The transaction terminal of Claim 104, wherein said terminal is a data card transaction terminal.

106. Apparatus for reading embossed characters on a data card, comprising:
means for detecting the insertion of an embossed data card and for providing a card inserted signal;
a tactile imaging array for providing matrix signals corresponding to the impression of a contacted object;
contacting means responsive to said card inserted signal for causing said tactile imaging array to operatively contact with the embossed character region of the inserted data card; and means responsive for interpreting said matrix signals from said tactile imaging array and for providing a data output corresponding to the embossed characters in said embossed character region.

107. The apparatus of Claim 106, wherein said contacting means comprise:
a pressure plate comprising a pressure applying region corresponding to the embossed character region of the inserted data card; and means for biasing said pressure plate against the inserted data card, whereby said tactile imaging array contacts with the embossed region of the inserted data card when said pressure plate is biased by said biasing means.

108. The apparatus of Claim 107, wherein said contacting means further comprises:
a drive motor;
a first switch operative to be actuated upon insertion of the data card and apply power to said drive motor; and cam means rotatably attached to said drive motor for releasing said pressure plate to be biased by said biasing means, such that said pressure plate is held away from said tactile imaging array when no card is present.

109. The apparatus of Claim 108, further comprising a first switch actuating arm for initially contacting an inserted data card and for actuating said first switch.

110. The apparatus of Claim 108, wherein said cam means comprises a cam shaft operative to rotate in response to motion by said drive motor.

111. The apparatus of Claim 110, wherein said cam shaft assumes an initial position such that an edge of said pressure plate is lowered to facilitate insertion of the data card, and a half-way position that allows said pressure plate to pivot against the inserted data card.

112. The apparatus of Claim 108, further comprising:
a pressure plate actuating arm operatively connected to said pressure plate; and a second switch positioned to be actuated by said pressure plate actuating arm, for removing power from said drive motor upon completion of movement of said cam means.

113. The apparatus of Claim 108, wherein said pressure plate is pivoted by said cam means to bring said pressure applying region into contact with the inserted data card.

114. Apparatus for reading embossed characters on a data card, comprising:
a drive motor;
a first switch actuating arm for initially contacting an inserted data card;
a first switch operative to be actuated by said first switch actuating arm upon insertion of the data card and apply power to said drive motor;
a cam shaft operative to rotate in response to motion by said drive motor for an entire revolution;
a pivotable pressure plate comprising an entry edge positioned for receiving the inserted card, a pressure plate actuating arm, and a pressure applying region corresponding to the embossed character region of the inserted data card;
said pressure plate being pivoted by said cam shaft to bring said pressure applying region into contact with the inserted data card;
said cam shaft assuming an initial position such that said entry edge is lowered to facilitate insertion of the data card, and a half-way position that allows said pressure plate to pivot against the inserted data card;
a second switch actuated by said pressure plate actuating arm, for removing power from said drive motor upon completion of a full rotation of said cam shaft;
a pressure spring for biasing said pressure plate against the inserted data card when said cam shaft assumes said half-way position;

a tactile imaging array positioned so as to contact with the embossed region of the inserted data card when said pressure plate is biased by said pressure spring; and a control circuit responsive to signals from said tactile imaging array for interpreting the embossing on the inserted data card and for providing data characters corresponding to the embossing.

115. A data card transaction terminal, comprising:
means for reading a magnetic stripe associated with a data card presented in connection with a proposed transaction and for providing card identifying information;
embossed card reader means for detecting embossed characters formed in the data card and for providing card identifying information;
means for obtaining transaction information; and communication means for communicating signals associated with a data card transaction to a remote transaction processor.

116. The terminal of Claim 115, further comprising means responsive to card identifying information from said magnetic stripe reading means and/or said embossed card reader for providing a transaction protected flag associated with said transaction information.

117. The terminal of Claim 116, wherein said communication means is operative for requesting and receiving an authorization indicia from an authorization source, and wherein said transaction protected flag providing means is responsive to said authorization indicia and card identifying information from said magnetic stripe reading means and/or said embossed card reader for providing said transaction protected flag.

118. The terminal of Claim 115, wherein said signals communicated to said remote transaction processor include an authorization request signal for requesting authorization indicia from an authorization source, and wherein said communication means is operative for communicating said authorization request signal to an authorization source as a request for authorization indicia.

119. The terminal of Claim 118, wherein said signals communicated to said remote transaction processor include said signature signals and transaction information signals, and wherein said communication means is operative for transmitting said transaction information signals to said remote transaction processor while the terminal is communicating with said transaction processor for requesting said authorization indicia.

120. The terminal of Claim 119, further comprising memory means for storing said transaction information signals as a transaction record in a transaction batch, and wherein said communication means is operative for transmitting said transaction batch to said remote transaction processor during a communications session.

121. The terminal of Claim 120, wherein said communication means is operative for communicating a transaction record associated with a transaction being conducted at the terminal during an authorization communications session when said communication means communicates with said remote transaction processor for requesting said authorization indicia, and is alternatively operative for transmitting said transaction record to said remote transaction processor during a subsequent communications session in the event that the terminal is unable to communicate with the remote transaction processor during said authorization communications session.

122. The terminal of Claim 116, wherein said signals communicated to said remote transaction processor include said transaction protected flag.

123. The terminal of Claim 115, wherein said card identifying information comprises an account number associated with the data card.

124. The terminal of Claim 115, wherein said magnetic stripe reading means comprises means for reading a first track of information stored on the magnetic stripe of a data card and means for reading a second track of information stored on the magnetic stripe of the data card, said first track and said second track including said card identifying information, and further comprising means for restoring a portion of said card identifying information read from said first track with card identifying information read from said second track.

125. The terminal of Claim 124, further comprising means for verifying the accuracy of data read from said first track, and wherein said restoring means is operative for restoring at least a portion of the account number read from said first track with at least a portion of the account number read from said second track if said verifying means detects that the data read from said first track is not accurate.

126. The terminal of Claim 125, wherein said verifying means comprises longitudinal redundancy check (LRC) means.

127. The terminal of Claim 115, further comprising means for restoring at least a portion of said card identifying information read from said magnetic stripe reading means with at least a portion of said card identifying information provided by said embossed card reader means.

128. The terminal of Claim 127, further comprising means for verifying the accuracy of said card identifying information provided by said magnetic stripe reading means, and wherein said restoring means is operative for restoring at least a portion of card identifying information provided by said magnetic stripe reading means with at least a portion of said card identifying information provided by said embossed card reader means if said verifying means detects that said card identifying information provided by said magnetic stripe reading means is not accurate.

129. A signature capturing transaction terminal, comprising:
means for obtaining transaction information corresponding to a transaction;
a stylus;
a signature capturing window in which the card holder enters a signature with said stylus;
digitizer means for providing coordinate position signals of said stylus with respect to said signature capturing window;
means for compressing said coordinate position signals and for providing compressed signature signals;
means for storing said compressed signature signals and said transaction information in association.

130. The signature capturing transaction terminal of Claim 129, further comprising communication means for communicating said compressed signature signals and said transaction information to a remote location.

131. The signature capturing printer of Claim 129, further comprising contact signal means for providing a contact signal indicative of the stylus being in operative contact with said signature capturing window, and stroke detecting means responsive to said contact signal for causing said compressing means to provide a stroke signal indicative of the starting coordinate and the final coordinate of each stroke of a signature.

132. The signature capturing printer of Claim 131, further comprising stroke counting means for providing a stroke count signal corresponding to the number of strokes in a signature, and wherein said signature signals comprise said stroke count signal and a plurality of coordinate position difference signals corresponding to differences between said coordinate position signals provided by said digitizer means.

133. The signature capturing printer of Claim 129, wherein said compressing means comprises:
means for providing a stroke started signal;
means for providing a stroke completed signal;
means for determining a number N of strokes in a signature, a stroke being determined by an initial starting coordinate provided in response to said stroke started signal and a final coordinate provided in response to said stroke completed signal;
means for providing, for each stroke of the N strokes in the graphic object, compressed output signals comprising a difference between a first coordinate position signal provided at a first sample time from said digitizer means and a second coordinate position signal provided at a second sample time from said digitizer means.

134. The signature capturing printer of Claim 133, wherein said compressed output signals comprise an a bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is less than a first predetermined value; and a b bit digital code as the output signal if the difference between said first coordinate position signal and said second coordinate position signal is greater than said first predetermined value but less than a second predetermined value, where a is less than b.

135. A method for digitally encoding a graphic object provided in the form of coordinate position signals from a graphic digitizer and for providing compressed graphic object signals, comprising the steps of:
determining a number N of strokes in the graphic object, a stroke being determined by an initial starting coordinate provided in response to a stroke started signal and a final coordinate provided in response to a stroke completed signal;
for each stroke of the N strokes in the graphic object, determining output signals by:
(1) receiving a first coordinate position signal corresponding to a first sample time;
(2) receiving a second coordinate position signal corresponding to a second sample time subsequent to said first sample time;
(3) determining the difference between said first coordinate position signal and said second coordinate position signal;
(4) providing an a bit digital code as the output signal if the difference is less than a first predetermined value;
(5) providing a b bit digital code as the output signal if the difference is greater than said first predetermined value but less than a second predetermined value, where a is less than b;
repeating the above steps (1) - (5) for a plurality of sample times providing a plurality of coordinate position signals between said initial starting coordinate and said final coordinate;
and providing said number of strokes N and said output signals for each stroke as said compressed graphic object signals.

136. The method of Claim 135, wherein the graphic object comprises a signature.

137. The method of Claim 135, wherein said stroke completed signal comprises a negated stroke started signal.

138. A method for digitally encoding a graphic object provided in the form of coordinate position signals from a graphic digitizer and for providing compressed graphic object signals, comprising the steps of:
determining the number of strokes in the graphic object, a stroke being determined by an initial starting coordinate provided in response to a stroke started signal and a final coordinate provided in response to a stroke completed signal;
determining the X offset from the origin of a coordinate system to said initial starting coordinate of a given stroke of the graphic object;
determining the Y offset from the origin of the coordinate system to said initial starting coordinate of the given stroke of the graphic object;
determining the number of (X,Y) pairs in the given stroke, each (X,Y) pair corresponding to a coordinate position signal provided at one of a plurality of sample times between said stroke started signal and said stroke completed signal;
providing an X-output signal and a Y-output signal corresponding to the difference between a first (X,Y) pair at a first sample time and a second (X,Y) pair at at subsequent second sample time, each output signal comprising:
an .alpha. bit code if there is no change in the respective coordinate between said first (X,Y) pair and said second (X,Y) pair;

a b bit code if there is a change of g picture elements in the respective coordinate between said first (X,Y) pair and said second (X,Y) pair;
a c bit code if there is a change of between g+l and h picture elements in the respective coordinate between said first (X,Y) pair and said second (X,Y) pair, a d bit code if there is a change of between h+l and i picture elements in the respective coordinate between said first (X,Y) pair and said second (X,Y) pair; and for each stroke, providing the X-offset, the Y-offset, a count of the number of (X,Y) pairs, the X-output signal, and the Y-output signal to represent the graphic object.

139. The method of Claim 138, where a < b < c < d.

140. The method of Claim 139, where a=2, b=3, c-6, and d=9.

141. The method of Claim 138, where g = 1, h = 9, and i = 73.