WO1992017852A1

WO1992017852A1 - Interactive sequencing method for etc systems

Info

Publication number: WO1992017852A1
Application number: PCT/US1992/002559
Authority: WO
Inventors: Robert W. Grate; Wesley S. Camden; Patricia M. Heliger; Kenneth D. Carbullido; Dennis P. Galvin; Bradley K. Winking
Original assignee: First Data Resources Inc.
Priority date: 1991-03-29
Filing date: 1992-03-27
Publication date: 1992-10-15
Also published as: MX9201443A; AU1905192A

Abstract

An interactive sequencing method for reducing erros and enabling editing of consumer transactions in a host based system (10) having a plurality of remote terminals is disclosed. Some consumer transactions may be performed off-line at a remote terminal (14) and stored (14) and stored (24) for eventual transmission to the host (12), while others need to be performed on-line requiring immediate communication with a host (12). Specifically, off-line transactions are transmitted from the remote terminal (14) to the host (12) during the time period in which the remote terminal (14) is awaiting host authorization to transmit an on-line transaction to the host. Additionally, a balancing procedure is performed during which host transaction data is reconsiled with terminal transaction data. By comparing transaction data relating to the number of transactions in a batch, the monetary value of such transactions, and the number of transactions transmitted before a close transaction during the same communication call, errors can be detected and corrected.

Description

Interactive Sequencing Method for ETC Svstems

Field of the Invention

This invention relates generally to telecommunication systems and, more specifically, to an interactive sequencing method for reducing errors and enabling editing of transactions in an electronic ticket capture (ETC) system having a plurality of remote terminal and at least one host computer.

Background of the Invention

A conventional ETC system employs a plurality remote terminals which communicate over telephone lines v/ at least one host computer. Such an ETC is used to electronically process credit sales and the like.

Typically, such remote terminals are located at retail establishments and are referred to as point-of-sale (POS) terminals. These POS terminals provide the host computer with information relating to a variety of transactions generally performed by or at the request of a consumer or merchant operating the POS terminals. Such transactions include sales, returns, authorizations, deposit inquiries and voiding of a previously entered transaction. An authorization is a transaction seeking approval from the host computer-, and typically is required for credit card sales. An authorization may be performed alone or with other transactions such as sales.

Transactions which require authorization from host or which generally communicate with the host when th transaction is performed, are referred to as on-line transactions. Transactions which may be performed at the remote terminal and do not require interaction with the h are referred to as off-line transactions. Each on-line transaction typically requires a phone call to the host for approval at the time the consume attempts the transaction. Since off-line transactions do not require communication with the host when a user attempt 5the transaction, the cost of the telephone call is saved. However, such off-line transactions eventually need to be communicated to the host. Typically, these off-line transactions are transmitted to the host during end-of-day processing. End-of-day processing is a procedure in which

^,0the off-line transactions are transmitted to the host, checked for errors, errors corrected to the extent possible and databases updated, etc. Of course, a telephone call still needs to be made to transmit such off-line transactions, but the cost is less than making a call for

¹⁵ each off-line transaction.

Any of a wide variety of payment schemes may be employed by the consumer to purchase goods or services at the POS terminal. For example, credit cards, debit cards, ®personal checks, cash, etc. may be employed. Except for cash, an authorization is typically performed prior to accepting payment.

In accepting any or all of these forms of ⁵payment, it is important that the retail establishment be assured that a line of credit extended is sufficient to cover the charge incurred and that the consumer is current in payments made to the credit card service, or that the consumer's checking account and payment history are 0 sufficient to warrant acceptance of a personal check. For these reasons, a variety of services have been established which enable a retailer to verify the validity of a credit transaction. Particularly in the case of credit cards, thi may include the circulation of pamphlets or other listings indicating the account numbers of credit cards which are no to be honored for various reasons, including poor credit risk and theft. However, such listings are generally cumbersome in use, and exhibit an inherent time lag between distribution of the pamphlets and their actual use which ca result in the posting of a charge to an account which shoul not properly have been honored. Also to be considered is that such systems are not readily applicable to the verification of personal checks.

0 As a result, a variety of automated systems have been developed which enable a retail merchant to communicat with the company issuing the credit card, or a company whic will guarantee the personal check, to obtain an immediate indication as to whether or not the credit card or check ^should be accepted or rejected. Such systems may take the form of a clearing house which can be contacted by telepho to provide verification against listings maintained at the clearing house. More recently, such voice communications have been replaced with automated dial-up systems which ®enable magnetic markings provided on the credit card or check to be read automatically, and which automatically access a database for interrogation as to whether or not t credit card or check may be accepted.

While reducing the need for human intervention i ⁹the verification of credit transactions to the extent possible, and improving reliability by decreasing delays between compilation of a listing of unacceptable numbers a accessing the compiled listing, such systems are still subject to a number of drawbacks. Such drawbacks include 0high data transmission errors, high cost of transmission, lengthy and complex end-of-day processing, inadequate erro detection and error recovery schemes, and limited capabilities of the POS terminals.

5 For example, dial-up telephone lines are notorious for introducing errors into data transmitted thereover. Accordingly, the use of such dial-up telephone lines represents the main source of errors in many data ^communication systems. These errors are generally resolved during end-of-day processing at which time data relating to all of the off-line transactions performed at the terminal during that day is transmitted to the host. The host processes such data and determines whether errors exist and ^whether such errors are correctable by the host.

Unfortunately, the transmittal of such data during end-of- day processing still requires the use of error-prone dial-u telephone lines and, of course, payment for use of such lines. 15

In addition to the charges associated with telephone co r nications to transmit data relating to off¬ line transactions, the end-of-day processing must process all of the errors associated with such off-line transaction ® in a relatively short time. Unfortunately, since the error associated with such off-line transactions are generally only detected and processed during end-of-day processing, such processing is inherently time consuming, costly, and requires significant processing power. Moreover, in ⁵ measuring success as the number of errors detected at end- of-day, conventional systems such as that described above leave much to be desired.

Additionally, the problem of inadequate error processing is aggravated by the inadequate error detection and error recovery schemes presently employed. For example many systems employ a single character to determine success and many systems have little or no capability for error recovery. 5 Moreover, ETC systems such as the POS system described above employ a communications protocol which is not sufficiently interactive, as seen from the inability t allow any significant editing or viewing of transactions. The POS terminals are often relatively crude and simple da entering devices. Often, such POS terminals do not allow one to revise a previously entered transaction, whether or not the transaction was transmitted to the host.

Summary of the Invention

This invention relates to an interactive sequencing method for reducing or eliminating errors detected during end-of-day processing and enabling editing of transactions n an ETC system. More specifically, this invention relates to an interactive sequencing method in which off-line transactions are transmitted from a remote terminal to a host computer during the time period in whic the remote terminal is awaiting host authorization to transmit data relating to an on-line transaction to the host. Such on-line transactions are transmitted throughou the day. Accordingly, by the end of the day, if all off¬ line transactions have already been sent to the host by

"piggy-backing" onto on-line transactions, the end-of-day processing should result in the detection of no errors relating to such previously sent off-line transactions, since any such errors should have already been detected. processing during otherwise wasted time that which is normally processed only during end-of-day processing, the present invention provides an efficient, interactive and error-minimizing system. Additionally, the end-of-day processing includes balancing and reconciling of host data or values with terminal data or values in order to detect and correct errors, and to accommodate revisions made to transactions throughout the day. One particular embodiment of the invention relat to an interactive sequencing method for processing data relating to transactions in an electronic ticket capture system. Specifically, this method involves performing a least one off-line transaction at a_. remote terminal, the off-line transaction not requiring communication with a host when performed; then performing an on-line transact at the remote terminal, the on-line transaction requirin communication with the host when performed; and establishing a communications channel with the host when the on-line transaction is performed. After the communications channel is established, data relating to on-line transaction is transmitted to the host, along wit additional data relating to the off-line transaction. Th communications channel may then be disconnected from the host and from the remote terminal.

Preferably, once the host receives a transaction, it is examined for errors. In the event an error is detected, additional information is requested from the remote terminal. Such requested additional information i then transmitted to the host prior to disabling the communications channel.

In one embodiment, during end-of-day processing, balancing and reconciling are performed by comparing host transaction data (i.e., data maintained by the host and relating to past transactions) to terminal transaction da (i.e., data maintained by the terminal and relating to pa transactions) to determine, among other things, whether data may have been lost as such past transactions were transmitted from the terminal to the host throughout the day. ..Illustrative host and terminal transaction data include a calculation of the monetary value of all transactions in the group (i.e., batch) of transactions under consideration (net batch amount) , the number of transactions in such a group or batch (batch item count) , and the number of transactions transmitted during that communication between the host and the terminal.

Advantageously, in the event such host and termin transaction data do not balance, i.e., they are not equal the host may request additional information from the terminal in an attempt to identify which specific transaction was erroneously transmitted or otherwise presents a problem. Additionally, such a system enables the terminal to make various revisions to and edit a previously performed transaction which may have already been transmitted to the host.

Another aspect of this embodiment involves performing a plurality of off-line transactions and a plurality of on-line transactions, and when such on-line transactions are transmitted to the host, appending or "piggy-backing" as many off-line transactions as feasible onto the on-line transaction. At a specified time, and after the plurality of on-line transactions are performed a communications channel is established between the remot terminal and the host so as to enable data at the remote terminal to be reconciled with data at the host. Such reconciling preferably comprises transmitting any off-lin transactions remaining at the terminal to the host, and examining the transmitted remaining off-line transactions for errors. In the event an error is detected, additiona information is requested from the remote terminal, and an attempt is made to resolve the error. In the event no errors are detected or all errors have been resolved, or the event there were no transactions remaining at the remote terminal, the communications channel established f reconciliation is disabled. Advantageously, this results in minimizing the number of errors detected during the reconciliation, or close batch processing, relating to th off-line transactions, as well as minimizing the number o off-line transactions transmitted to the host during the ° reconciliation.

Another embodiment of the invention relates to an interactive sequencing method for use in processing consumer credit transactions. Specifically, a dial-up ^ communications channel is established between a host and remote terminal by the remote terminal dialing a phone number associated with the host. The host then transmits signal requesting packet communications from the terminal. Responsive to the signal requesting packet communications,

15 the terminal sends an authorization request to the host requesting approval of a consumer credit transaction. Responsive to the authorization request, the host polls t terminal to inform the terminal that the host is prepared to receive off-line transactions. Responsive to the 0 polling, the terminal transmits at least one off-line transaction. The host then transmits a host response to the terminal, the host response including an approval or denial of the authorization request. The dial-up communications channel may then be disabled. 5

In another embodiment of the invention, a dial-up communications channel is established between a host and remote terminal by the remote terminal dialing a phone number associated with the host. The host then transmits 0 signal requesting packet communications from the terminal. Responsive to the signal requesting packet communications, the terminal sends a batch transaction signal to the host indicating that at least one off-line transaction remains at the terminal and needs to be transmitted to the host. Responsive to the batch transaction signal, the host polls the terminal to inform the terminal that the host is prepared to receive off-line transactions. Responsive to the polling, the terminal transmits to the host all of th off-line transactions remaining at the terminal. After t last of the transactions remaining at the terminal is transmitted to the host, a close transaction signal is transmitted to the host from the terminal. After receivi the close transaction signal, data relating to the off-li transactions received by the host from the terminal following the batch transaction signal is reconciled and balanced. After such reconciling and balancing, a host approval signal is sent to the terminal from the host, followed by disabling the dial-up communications channel.

Accordingly, an object of the present invention i to provide a new and improved communications protocol.

Another object of the invention is to provide a method for reducing errors detected during the processing of transactions in an electronic ticket capture system.

A further object of the invention is to provide a interactive method for communicating between a host computer and a remote terminal.

A still further object of the invention is to provide an error-reducing sequencing method which reduces the time needed to perform end-of-day processing.

Another object of the invention is to provide mea for communicating off-line transactions from a remote terminal to a host computer during a wait state of the terminal in which the terminal is awaiting authorization an on-line transaction from the host. Brief Description of the Drawings

These and other objects, features and advantages the present invention will become more readily apparent ^ from the following detailed description of the invention which:

Fig. 1 is a block diagram of an illustrative electronic ticket capture (ETC) system implemented as a ⁰ point-of-sale (POS) system;

Fig. 2 depicts a standard interactive protocol fo a normal transaction;

^ Figs. 3a and 3b depict a standard interactive protocol for a negative response to a general poll;

Fig. 4 depicts a standard interactive protocol fo a correctable receive error in an on-line transaction; 0

Fig. 5 is a flowchart outlining balancing and reconciling of host data with terminal data;

Fig. 6 depicts a close batch interactive protocol for a normal- transaction; and

Figs. 7a and 7b depict a close batch interactive protocol with host polling to reconcile the terminal and host. 0 Detailed Description of the Drawings

Prior to describing the interactive sequencing method of the present invention in detail, an understandi of a typical operating environment in which the method ma be practiced is desirable.

Accordingly, Fig. 1 depicts a block diagram of an illustrative electronic ticket capture (ETC) system 10 implemented as a point-of-sale (POS) system. ETC system comprises a central system or host computer 12 and a plurality of merchant locations or terminals 14, in this case four although there could be more or fewer than four. Each merchant location 14 includes at least one computer unit 16 such as a microprocessor and associated periphera which communicates over a common bus 18 with, for example, a consumer data input device 20, a transaction data input device 22, a memory 24 and an input/output (I/O) device 2

Consumer data input device 20 is located at the point-of-sale to a consumer of merchandise or services fr a selected merchant. Device 20 may be a keyboard into which a consumer manually enters identification data and the like. Illustratively, such data may include the consumer's account number, date of birth, and form of payment, i.e., credit card type. Device 20 preferably includes a magnetic card reader adapted to read the magnetic stripe on a conventional plastic card as a consumer swipes the card through the card reader. In the latter event, the magnetic stripe could be encoded with t consumer's account number, date of birth, and type of car Where a plastic card is used, device 20 may also include keyboard for entry of a personal identification number (PIN) by which to verify against a code stored in the magnetic stripe that the card is being used by the -n-

appropriate individual at the point-of-sale. The plasti card may be a credit card such as an American Express (T card, or a debit card, etc. Device 20 also preferably includes a display which may be used to provide feedback instructions, or the like to the consumer.

Transaction data input device 22 is also located the point-of-sale and typically comprises a keyboard or like by which the sales clerk, for example, would enter type of transaction and data relating thereto, such as t dollar amount of the merchandise purchased by the consum Device 22 may comprise a cash register. Device 20 and device 22 may share components and may be integrated as single unit.

The consumer data including card type and transaction data entered through devices 20, 22 may be stored in memory 24. Memory 24 stores all data relating on-line as well as off-line transactions at least until such data is transmitted to host 12, reconciled, and correctable errors corrected. Such reconciliation or balancing of data is typically performed at the end of e day during a procedure referred to as end-of-day processing. Advantageously, the merchant may edit the transaction -data in memory 24 to include, for example, a gratuity or tip, or to void certain transactions. In th event that data sent to host 12 appears to contain errors the host will request the corresponding data from memory which, in the event of a discrepancy, will generally be regarded as correct.

Memory 24 may also include merchant data along wi software to direct operation of computer 16 as will be described. The merchant data includes at least a merchan code number to identify that merchant. Merchant data may also include information indicating the time or location the sale and/or the identification of the sales clerk, a information relating to the merchant's account(s), such balance, and charges such as credits and debits chargeab to that merchant's account(s) .

As is well understood, computer 16 will function accordance with the operating program stored in memory 2 To this end, computer 16 may verify that the PIN number matches a code on the card to verify that the user is authorized on that card. Alternatively, host 12 may perform such PIN verification. Computer 16 may also be provided with or calculate charges associated with the transaction and may output to central system 12, through I/O device 26 and communication line 30, the consumer's account number and birth date, the merchant data, and da relating to the transaction performed or requested. As will be appreciated, computer 16 may take on a variety o forms and provide a variety of functions, including simp controlling the passage of data entered at devices 20, 2 to host 12.

Central system 12 communicates with line 30 thro its own I/O device 40. I/O devices 26 and 40 may be mod and line 30 a conventional dial-up telephone line, for example. Further, each merchant location 14 may communicate with central system 12 either separately through I/O device 40 or collectively through multiple I devices 40 (only one shown) as is well understood. Preferably, the merchant terminals are programmable and downline loadable from the host. The information communicated, upon appropriate formatting, may be transferred either by means of a multiplexing system, a packet switching system, etc. Of course, selection of t means used to establish communication between the variou components described above will depend upon the quantiti and nature of the information to be communicated among t several components illustrated, as well as the number of components which are to be included in a given system.

Data received by central system 12 through I/O device 40 is provided to common bus 42 which permits communication between I/O device 40, memory 42, various databases 44, 46, 48, 50, an automated clearing house (AC window 52 and host computer 54 which may be a microprocessor and associated peripherals.

Each of databases 44, 46, 48, 50 as well as ACH window 52 includes a plurality of consumer accounts and a plurality of merchant accounts. Each of such consumer accounts generally includes an account number unique to that account and consumer, and a balance. In one embodiment, a database is provided with a list of account numbers which are not to be honored. The account may include a PIN or the birth date of the consumer.

Similarly, each of the merchant accounts generally includ at least an account number unique to that account and merchant, and a balance. As will be appreciated, database 44, 46, 48, 50 as well as ACH window 52 are illustrative; any number of a wide variety of databases and services ma be accessed. Illustratively, such databases and ACH wind 52 are accessed only when necessary, such as when an on¬ line transaction requires authorization. Funds are usual only transferred during the night to take advantage of nightly rates, and when there is less volume on the syste

The data received at I/O device 40 is sorted out computer 54 under control of an operation program stored memory 42. Specifically, such data includes transaction data and data which identifies the form of payment and th the database to be accessed, as well as the consumer's account number. During nightly processing, once the prop account is found, the balance is credited or debited and the account updated as appropriate. The received merchan data is similarly employed to locate the appropriate merchant account. The merchant's balance is then credite or debited and the account updated as appropriate.

Periodically, such as once a month, each merchant account in each database is examined and a report issued that merchant. Each of the reports may include an added fee from the operator of central system 12 and the databases, and may further include a list of transactions for that merchant. Also, at selected times, each consume account in each database may be examined and a report issued to each consumer.

Illustrative transactions which may be communicat between the host and the remote terminal include the following: close batch, authorization and ticket, return/credit, ticket only, authorization only, void sale, void return, void ticket only, and previous processing da deposit inquiry. Of these, the close batch and the depos inquiry are typically requested only by the merchant. Additional transactions or, more specifically, communications, between the host and the remote terminal include revision inquiries and responses thereto, and polling and responses thereto. Inquiries are typically performed on-line. As will be appreciated, an operator having sufficient supervisory authority may decide which the transactions needs authorization and must therefore b performed on-line. Additionally, while some transactions are described as being communicated between the host and the remote terminal, it is to be understood that some transactions such as an authorization also require communication between the host and a selected database.

A close batch transaction is generally performed a the end of a predetermined time period or after a predetermined number of transactions have been processed. Typically, a close batch is performed at the end of each day to transmit to the host any remaining off-line transactions which were not yet received by the host, and to reconcile and balance transaction data in the terminal with transaction data in the host. As will be appreciated by transmitting off-line transactions throughout the day t the host during an idle period in which the terminal await acknowledgment from the host, the time for the close batch to be performed at the end of the day is significantly decreased. Moreover, time required for detection and correction of errors is also significantly reduced if not eliminated since any errors associated with the off-line transactions transmitted during the above-mentioned idle period would have been detected and corrected, to the extent possible, when transmitted.

An authorization and ticket transaction relates to a sale of goods or services or the like which typically requires an authorization from the host to be transmitted to the merchant location. For example, in the event a consumer wishes to purchase a relatively expensive item with an American Express (TM) credit card, the host must first authorize the sale. The host accesses the American Express (TM) database (44 in Fig. 1) to determine whether to authorize the sale. This transaction is typically performed on-line and requires a call to the host. A return/credit transaction relates to crediting a consumer's account by an amount. For example, if a consumer returns defective merchandise, his account would be credited with his cost of the merchandise. Typically, this transaction does not require authorization from the host and may be performed off-line.

A ticket only transaction relates to a sale which does not typically require an authorization from the host. For example, if a consumer purchases a relatively inexpensive item with a credit card, it may be economicall feasible and worth a calculated risk to forego approval from the host. Accordingly, this transaction is typically performed off-line, i.e., at the terminal.

An authorization only transaction relates to a consumer being approved to have a certain charge or hold placed against his account, but not actually crediting a merchant with any amount or charging the consumer an amount. For example, a credit card may be used to guarantee payment such as when one rents merchandise, regardless of how payment is eventually made. An authorization only transaction is typically performed on¬ line and requires a call to the host.

A void sale transaction voids a previously entered authorization and ticket transaction. The void sale transaction is typically performed off-line.

A void return transaction voids a previously entered return/credit transaction and is typically performed off-line. A void ticket only transaction voids a previousl entered ticket only transaction and is typically perform off-line.

A previous processing day deposit inquiry transaction is a request made to the host from the termi regarding the results of the previous day's close batch transaction. This transaction is typically performed o line. Other inquiry type transactions may also be performed, such as an inquiry of an off-line transaction not yet sent to the host; such a transaction would be performed off-line.

The above-described illustrative transactions, a well as other transactions, are preferably initiated by depressing a corresponding key on keyboard 20 or 22. Fo example, to initiate a typical credit card sale requirin authorization, a sales clerk may depress a key entitled "authorization and ticket" on keyboard 22.

Tables I-XI describe the data field formats associated with various transactions and communications between a terminal and the host. As will be appreciated, these fields are presented as merely illustrative of a w variety of suitable fields. Each of Tables I-XI corresponds to datastreams transmitted from the remote terminal to the host, and to payment by way of credit ca

As will be appreciated, some of the individual fields in these tables are machine-filled by hardware associated with the merchant location (e.g., merchant number, terminal ID) , while some of the individual field are input by an operator, such as the consumer or the sa clerk (e.g. , type of transaction as set forth in Table XVI) . More specifically, Table I sets forth a monetary transaction header format for a swiped account entry, wh Table II sets forth a monetary transaction header format for a manual account entry via a keyboard. Monetary transactions comprise those transactions in which charge are placed against an account, i.e., an amount is charge to the account. Monetary transactions in which a consum is given credit typically need to be authorized by the host, as may other transactions.

TABLE I MONETARY TRANSACTION HEADER FORMAT (SWIPED ACCOUNT ENTR

MAXIMUM ⁵ NAME OF FIELD DEFINITION CHARACTERS

1.

2.

3.

4.

5.

10 6.

7.

8.

9. 10. 11. 12. 13.

1514. 15. 16. 17. 18. 19. 20.

2021.

TOTAL 106

Referring to Table I, in one particular embodiment the start of text field is a standard ASCII start of text character; the non-standard flag is

25 defined as a "*" character and, if it exists, indicates that the transaction involves interactive protocol; the non-standard type indicates the specific type of interactive protocol required for the transaction

2_Q requested, as will be discussed in greater detail; the terminal ID is a three position field starting with "I" and ending with ".", with the second position defining the terminal type; the merchant number is the merchant code number which identifies the specific merchant g operating that remote terminal; the operator ID identifies the specific terminal and has a "#" in the first position with the remaining characters being any alphanumerics, and any unique set of such remaining characters defining at most one terminal; the field separator is an ASCII field separator character used to ° separate fields; the write control character defines whether the card was swiped or manually entered, and also indicates whether the authorization will be transmitted alone or in conjunction with other authorizations; the transaction type field defines the nature of the transaction being sent, i.e., whether it is on-line or off-line or part of a close batch, and is defined in more detail in Table XV; the transaction code defines the specific type of transaction, i.e., whether it is an authorization only, authorization and ticket, 5 void sale, etc. ; the track II data is data from the magnetic stripe of the card, with the start and end sentinels removed; the total amount is the amount of the transaction and, more specifically, the total of all amount fields prompted in the transactions (this field is edited by the terminal to disallow a zero or negative amount for all transactions except a close batch transaction) ; and the invoice number identifies the specific invoice and comprises up to eight alphanumerics.

A sequence number is also generated and is sent with every monetary transaction. The sequence number is employed during balancing and reconciling of the host and terminal to ensure the integrity of the received transaction. The sequence numb,_er comprises a batch number, an item number and a revision number.

More specifically, the batch number identifies which of up to ten possible different batches the transaction is part of, and is incremented by the terminal after a successful close batch transaction or if the terminal is manually cleared. The batch number is used by the host to detect errors such as that in which two terminals could attempt to process the same transaction(s) by using the same merchant number. The batch number thus ensures that the terminal and host are processing the same transactions. The item number identifies each monetary transaction or record in the batch, and may take on values from 001 to 999 for each batch. Specifically, the terminal assigns a unique item number to each monetary transaction within a batch. Such item number is employed during the balancing and reconciling process to detect and correct errors. For example, in the event a transaction is sent to the host and received but not acknowledged, the terminal would resend the transaction with the same item number but the host would not need to create a duplicate record. Rather, the host would compare the unacknowledged transaction with the resent transaction and modify the unacknowledged transaction in accordance with the resent transaction. The revision number identifies the number of revisions to a particular transaction, and is incremented every time the transaction is edited, voided, a tip added, or anything done to affect the total amount at the terminal level. The revision number is employed during balancing and reconciling to detect and correct the logging of the most current state of a transaction. For example, a sale transaction performed at the terminal and then sent to the host may then be voided at the terminal. The terminal would alter the transaction by changing the transaction code appropriately, and increment the revision number. Once the transaction is sent to the host, the host would check the item number received, compare the revision numbers, and then log the transaction that has the greatest revision number. TABLE II

TOTAL 79

Referring to Table II, in the particular 25 embodiment described above, the account number is the cardholder's card account number, e.g., the credit card number, while the expiration data is a four character fiel in month-year format, representing the expiration date of the credit card. 30

The remaining field formats to be appended to th headers in Tables I and II are set forth in Tables III, IV and V. specifically, Table III sets forth data field formats for an illustrative retail application, Table IV ³⁵ sets forth data field formats for an illustrative restaurant application, while Table V sets forth data fiel formats for an illustrative hotel application. As will b appreciated, such field formats may be tailored for specific industries, markets, and applications.

TABLE III

0

5

TOTAL 30 0

Referring now to Table III, in the particular embodiment described above, the format code is a number from 0 to 9 that identifies any additional data elements required for a specific application. Illustrative additional data elements are listed in Tables III-V for 5 three applications. The clerk ID identifies the specific clerk performing the transaction. Retail terms sets fort the credit terms of the transaction, such as payment withi 90 days, cash discounts, etc. Phone order flag indicates _Q whether the consumer has requested the transaction by way of a telephone. The descriptor code field may contain a plurality of 2 or 4 digit codes which define the type of product purchased, i.e., sporting goods, pharmacy, etc. The end-of-text field is a standard ASCII <ETX> character 5 defining the end of the datastrea . The data transmission error check method employed is a longitudinal redundancy check (LRC) in which the check character transmitted is an exclusive-OR of all characters in the datastream excluding the <STX> character.

10

15

TOTAL 32

0 Referring to Table IV, the food, beverage (bev) , tax, and tip amounts relate to dollar values for such goods/services.

5

0

5 NAME OF FIELD

1. FORMAT CODE

2. FIELD SEPARATO

3. OPERATOR ID

4. FIELD SEPARATO

10 5. ROOM NUMBER

6. FIELD SEPARATOR

7. ARRIVAL DATE

7. FIELD SEPARATOR

8. DEPART DATE

9. FIELD SEPARATOR 10. SPECIAL PROGRAM

1511. FIELD SEPARATOR

12. END OF TEXT

13. CHECK CHARACTER

TOTAL 28

Referring to Table V, the arrival date and 0 depart date fields relate to the day of arrival and day of departure in month-day-year format, while the room number field comprises alphanumerics which indicate the room number. The special program field is used to define the reason for the transaction, while the room rate field 5 specifies the room rate in dollar-cents format.

Table VI sets forth an illustrative void transaction format for a swiped account entry. For an authorization only transaction format, fields ±e, ±f and

0 of Table VI would be zero filled; otherwise, fields 17/and Offl-I

-Etβ- would identify the transaction to be voided. ή

5 TABLE VI

10

15

20

TOTAL 101

5 TABLE VII

TOTAL 76

25

30

5 Table VIII sets forth an illustrative previous processing day deposit inquiry transaction format.

TABLE VIII DEPOSIT INQUIRY TRANSACTION FORMAT

NAME OF FIELD

1. START OF TEXT

2. NON-STANDARD FLAG

10 3. NON-STANDARD TYPE

4. TERMINAL ID

5. MERCHANT NUMBER

6. OPERATOR ID

7. FIELD SEPARATOR

8. WRITE CONTROL CHAR.

9. TRANSACTION TYPE 1510. TRANSACTION CODE

11. FIELD SEPARATOR

12. FIELD SEPARATOR

13. FIELD SEPARATOR

14. FIELD SEPARATOR

15. FIELD SEPARATOR

16. FIELD SEPARATOR

17. FORMAT CODE

20 18. END OF TEXT

19. CHECK CHARACTER

TOTAL 40

25

30

35 Table IX sets forth a close batch transaction format.

TABLE IX

TOTAL 65

Table X sets forth the format for a negative response to a specific poll from the host. The item

30 number field is the item number of the transaction requested by the host in the host's specific poll. A specific poll of a terminal is performed by the host. In particular, a host specific polls a terminal when the host requires additional information from the terminal. 5 For example, a host may specific poll a terminal during end-of-day processing to request a specific transaction which may have been inaccurately transmitted to the host.

TABLE X NEGATIVE RESPONSE TO A SPECIFIC POLL

NAME OF FIELD

1. START OF TEXT

2. NON-STANDARD FLAG

10 3. NON-STANDARD TYPE

4. TERMINAL ID

5. MERCHANT NUMBER

6. OPERATOR ID

7. FIELD SEPARATOR

8. WRITE CONTROL CHAR.

9. TRANSACTION TYPE 1510. TRANSACTION CODE

11. FIELD SEPARATOR

12. FIELD SEPARATOR

13. FIELD SEPARATOR

14. FIELD SEPARATOR

15. FIELD SEPARATOR

16. FIELD SEPARATOR

17. BATCH NUMBER

20 18. ITEM NUMBER

19. REVISION NUMBER

20. FIELD SEPARATOR

21. FORMAT CODE

22. END OF TEXT

23. CHECK CHARACTER

25 TOTAL 46

30

35 Table XI sets forth the format for a response to a revision inquiry from the host. A revision inquiry is a request from the host regarding a revised transaction, and may be employed during end-of-day processing.

TABLE XI

Tables XII-XIV describe the data field formats associated with various transactions and communications between the terminal and the host. Each of these three tables corresponds to datastreams transmitted from the host to the remote terminal.

Specifically, Table XII sets forth a format for a standard host response to a terminal's authorization request or inquiry.

TOTAL 27

Table XIII sets forth a format for a specific poll generated by the host and transmitted to the POS terminal. The host may specific poll for an off-line item as well a a revised item. The request type is passed to the transaction type field of the item requested. NAME OF FIELD

1 . START OF TEXT

2 . ACTION CODE

3 . RESPONSE CODE

4 . BATCH NUMBER

5 . ITEM NUMBER 6. REVISION NUMBER

7. FIELD SEPARATOR

8. REQUEST TYPE

9. END OF TEXT

10. CHECK CHARACTER

TOTAL 12

Table XIV sets forth a format for a revision inquiry transmitted to the POS terminal.

TABLE XIV

REVISION INQUIRY

TOTAL 11

A general poll to a terminal consists of a standard ASCII <ACK> character, and indicates that the hosl is prepared to receive data. Table XV is the transaction type table ("TYPE"; referred to in Tables I-XIII, while Table XVI is the transaction code table ("TRAN") referred to in Tables I-

XIV.

TABLE XV

TRANSACTION TYPE TABLE

DEFINITION

Treat the same as host based

Item was captured off-line

(piggy-backed)

Item was captured off-line and sent with close batch.

Revised item (piggy-backed)

Revised item sent as part of close batch.

Specific poll for a revised item.

Specific poll for an off-line

item.

TABLE XVI

TRANSACTION CODE TABLE

DEFINITION

Close/balancing transaction

Authorize and capture ticket

Credit transaction

Capture the ticket only

Authorize only

Void ticket; attempt to void authorization

Void credit ticket

Void ticket only

Return the previous days deposit

Response to a revision inquiry

Negative response to a specific poll As will be appreciated by one skilled in the ar some transactions described herein may be captured at the remote terminal without host authorization or interaction. Other transactions, such as typical credit card purchases, require interaction with the host to receive real-time authorization to make the purchase.

Advantageously, an interactive method is employe to send the terminal-captured (i.e., off-line) transaction to the host. Additionally, transactions previously edited or revised at the terminal may similarly be sent to the host. This is accomplished by the host polling a terminal for additional transactions while the terminal would normally wait for a response from the host to the terminal's authorization request. Such polling and the corresponding trans ittal of additional transactions helps to ensure that the terminal is in balance with the host when end-of-day processing is performed. Such end-of-day processing generally includes a close batch, or close/balancing, transaction during which any transactions remaining at the terminal are transmitted to the host and reconciled.

A detailed description of the preferred embodiment of the protocol and sequencing follows.

Advantageously, the present invention processes during otherwise wasted time that which is normally processed onl during end-of-day processing, thus providing an efficient, interactive, and error-minimizing system.

Illustratively, the terminals will respond to an employ three different interactive protocol environments and polling techniques. Referring to Tables I, II and VI-

XI, it is seen that a "non-standard flag" field is defined as an "*" character near the beginning of the datastream, following the <STX> character, indicating interactive protocol for that transaction or communication. Similarly it is seen that a "non-standard type" field follows such flag, and may be a 1, 2 or 3 , identifying which of the three different protocol environments and polling techniques the transaction or communication employs. Such a 1, 2 or 3 shall be referred to as a protocol flag.

Type "1" protocol is the standard interactive protocol in which the host will general poll the terminal for remaining transactions, and in which such transactions are transmitted to the host, until a host response to a previous on-line transaction is received by the terminal.

Such an on-line transaction may be regarded as a request t pass data to the host. Once the terminal receives a suitable host response, no more off-line transactions will be sent to the host; the on-line transaction then will be transmitted to the host. In other words, once the request is approved, the actual sale or transaction may take place

More specifically, type "1" protocol is the mean for piggy-backing off-line transactions onto on-line transactions. As will be appreciated, such transactions can only be piggy-backed in an interactive protocol environment. ^■ On-line transactions such as authorization and ticket, authorization only, and certain inquiry transactions require a real-time authorization from, or communication with, the host. After the terminal transmit to the host its request for such authorization, and before the host transmits to the terminal its response, there exists an idle period during which there is typically no communication. It is during this idle time that the host general polls the terminal to send, seriatim, off-line transactions previously accumulated at the terminal and no yet sent to the host. The host typically acknowledges receipt of each such off-line transaction by transmitting an acknowledgment character <ACK>, except for the last off-line transaction after which the host sends its standard host response. Advantageously, such utilization of the otherwise wasted idle time improves efficiency and reduces batch transmission time at close as well as reduces balancing time. Such transmission time is the time required to transmit all remaining transactions to the host when a close batch is performed. Balancing time is the time required to balance and reconcile the terminal's transaction data with the host's transaction data. Close batch is generally performed during end-of-day processing and comprises transmitting the remaining transactions, if any, to the host and then balancing. Of course, any transactions that were piggy-backed previous to a close batch do not need to be retransmitted.

Figs. 2-4 depict illustrative examples of the method of the present invention in the context of type "1", or standard, interactive protocol. In each of these figures, the horizontal arrow indicates whether data flow is from the terminal to the host (arrow to right) or from the host to the terminal (arrow to left) . Each of these figures, as well as each of Figs. 5-6, corresponds to a single telephone call.

Referring to Fig. 2, there is depicted the standard interactive protocol for a normal, i.e., error free, transaction requiring real-time communication with the host. Typically, such transactions would include any transaction requiring an authorization, or certain inquiry transactions. More specifically, a terminal will first call the host (100) to establish a dial-up communications channel with the host. A conventional logon sequence (not shown) may also be employed, but need not be. The host will then send a standard ASCII <ENQ> character (102) to the terminal to request packet communications from the terminal.

The terminal will then respond by sending an on¬ line transaction (104, 106) having a non-standard flag "*" (106) which indicates an interactive protocol and a protocol flag of "1" (106) indicating a standard interactive protocol.

At this time, the terminal is in an idle or wait state, and is waiting for the host to respond to the on¬ line transaction, i.e., waiting for the host to indicate its authorization.

The host then general polls the terminal (108,

110) by sending an <ACK> character (110) , thus informing the terminal that the host is prepared to receive off-line transactions.

The terminal then responds by sending its next off-line transaction (112, 114). In this example, the off-line transaction also has a standard interactive protocol as indicated by the non-standard flag "*" (114) and protocol -flag "1" (114) .

For a normal transaction, the host then sends it response (116, 118) to the terminal's on-line transaction; such response is the host standard response as set forth i

Table XII. Of course, more than one off-line transaction, with each except the very last being followed by an <ACK> from the host, could have been sent from the terminal to the host before the host sent its host response to the terminal's on-line transaction. In fact, until the host . . . responds to the on-line authorization request or inquiry, the terminal will send the next available off-line transaction, and then the next, and so on. Such next off¬ line transaction is generally the oldest transaction that was revised which has yet to be transmitted to the host since it was revised, including any off-line transaction which has not yet been transmitted to the host. In this regard, an edited transaction is considered an off-line transaction unless its editing required host interaction. A transaction is considered to have been revised if it was ° voided or edited.

The terminal then acknowledges (120) that it received the host response (118) by sending an acknowledge character <ACK> (120) to the host. 5

The host then sends an end-of-transmission character <E0T> (122) to the terminal to indicate that it will disconnect (124) from the terminal.

⁰ Referring now to Fig. 3, there is depicted the standard interactive protocol for a negative response to a general poll. Steps 150, 152, 154, 156, 158, 160, 162 and 164 are similar to steps 100, 102, 104, 106, 108, 110, 112 and 114 of Fig. 2. After receiving an <ACK> character from the terminal {164), the host then general polls (166, 168) the terminal by sending an <ACK> character (168) . In the event that no off-line transactions remain at the terminal, the terminal will inform the host by sending an end-of- transmission <EOT> character (170, 172) . Thereafter, the host, when ready, will send its response (174, 176) to the terminal's on-line transaction. As in Fig. 2, such response is the host standard response set forth in Table

XII. Steps 173, 180 and 182 are similar to steps 120, 122 and 124 in Fig. 2. As will be appreciated, Fig. 3 relates to a negative response to a general poll by the host since the terminal sent an end-of-transmission <EOT> character (170, 172) , and not an off-line transaction, to the host in * response to the host's general poll (166, 168).

Alternatively, subsequent to the host's general poll (166, 168) , it is possible that the host does not receive any response to its general poll. In such a

10 situation, the standard host response (176) would follow the general poll, followed by steps 178, 180 and 182 (see Fig. 3). In one embodiment, the terminal sends its off¬ line transaction within a first predetermined time period after receiving the general poll, i.e., <ACK> character, ⁵ from the host. However, if the host does not receive such off-line transactions within a second predetermined time period, greater than the first, the host will send its response to the terminal's earlier on-line transaction. Illustratively, such first time period is one second, whil

²⁰ the second time period is three seconds. Such a scenario is referred to as a correctable failure to respond to a general poll.

Fig. 4 depicts the standard interactive protocol

25 for a correctable receive error in an on-line transaction.

Steps 200 and 202 are similar to 100 and 102 of Fig. 2, while step 204 is similar to step 104, 106 of Fig. 2. However, in the sequence of events depicted in Fig. 4, the host never received a proper on-line transaction (204,

30 206) . Illustratively, this error could have been the result of transmission of the data over a faulty telephone line, the error being detected by observing a parity bit o check character as is known. Such a check character appears as the last character of the transmitted datastrea 35 as indicated in each of Tables III-XI. Alternatively, a time-out during which the on-line transaction should have been sent, could have elapsed.

' In response to the error, the host transmits a negative acknowledgment character <NAK> (206) to the terminal, indicating that the host never properly received the previous transaction, and that the terminal may try to send such transaction again. Accordingly, the terminal ° again attempts to send the on-line transaction (208) , this time achieving success as acknowledged by the host (210) .

As in Fig. 1, while the terminal is idle, it transmits an off-line transaction (212) to the host. 5

At this point, the host responds (216) to the terminal's on-line transaction (208). Steps 216, 218, 220 222 are similar to steps 118, 120, 122, 124 of Fig. 2.

As will be appreciated, Fig. 4 relates to a correctable receive error since the <NAK> (206) character prompted the terminal to retransmit (208) the on-line transaction resulting in a correctly received transaction as indicated by the <ACK> character (210) transmitted by the host.

Alternatively, if the on-line transaction is incorrectly transmitted to the host a predetermined number of times, the host will disconnect from the telephone line, resulting in a non-correctable receive error.

As discussed, Fig. 4 relates to a correctable receive error in an on-line transaction; a correctable receive error in an off-line transaction may also exist.

In such a case, an off-line transaction is incorrectly sen to the host which responds with a negative acknowledgment <NAK>, which in turn prompts the off-line transaction to be sent again. In the event the off-line transaction is correctly received, the scenario is referred to as a correctable receive error in an off-line transaction.

As will be appreciated by one skilled in the art, the scenarios described in conjunction with Figs. 2-4 are illustrative, and further types of errors and combinations ° of errors may occur and be compensated for.

Type "2" protocol environment is the environment within which at least part of the close batch transaction is generally performed so as to balance the terminal and the host, preferably employing error detection and correction techniques. More specifically, a close transaction portion of the close batch transaction is transmitted utilizing type "2" protocol. Such close batch processing is the means for updating the host with off-line transactions which have not yet been sent to the host, and then reconciling or balancing the host's records with the terminal's records. Typically, close batch processing is performed at the end of each day during end-of-day processing. 5

Type "3" protocol is similar in form to type "1" protocol except that the host will not send its standard host response to an on-line transaction to the terminal.

Type "3" protocol environment is the environment within 0 which part of the close batch transaction may be performed, if it is necessary to perform such part. More specifically, a batch transaction portion of the close batch transaction is transmitted utilizing type "3" protocol. It is in this batch transaction that all of the 5 off-line transactions are transmitted to the host. The off-line transactions continue to be transmitted until the protocol flag is changed. Accordingly, each off-line transaction at the terminal will be transmitted to the hos without interruption by the standard host response. 5

Of course, in the event that all off-line transactions have previously been sent to the host by piggy-backing on to on-line transactions, the close batch transaction would not include the batch transaction, only the close transaction.

Fig. 5 is a flowchart outlining a balancing and reconciling process. More specifically, the terminal transmits a close transaction signal (400) to the host which then compares (402) its values for the net batch amount, batch item count, and items transmitted, with the corresponding values for that batch of transactions calculated by the terminal. Such values may be derived from, at least in part, the batch number, the item number and the revision number of the various transactions which make up the batch being balanced. As will be appreciated, the terminal has previously sent the transactions to the host, accordingly, all of such transactions do not need to be sent again unless errors are detected. If such a ° comparison results in no difference for these values, a close approval is sent to the terminal (404) .

However, in the event these host values and terminal values do not coincide, a search is performed

(406) to determine, for example, whi.ch i.tem (i..e., transaction) has not been received by the host for the batch under consideration. In the event a specific item i determined to be missing, a request (408) is made by the host for such item. Once the host receives that item, it again checks to see whether the host and terminal balance (402). In the event they balance, a close approval is sen (404) to the terminal. In the event they do not balance, and after processing all such missing items, the host issues a revision inquiry (410) and receives a list cf revised transactions from the terminal. The host then attempts to identify (412) the incorrect item by checking the revision numbers. In the event all revision numbers match, the host issues further revision inquiries (410) until all revised items have been considered. If an incorrect item cannot be found, a close approval (404) is transmitted. In the event an item is found for which the host's and the terminal's revision numbers do not match, that specific item is requested (408) and the host again attempts to balance (402) , check for missing items (406) , etc., until the terminal and host balance or all revisions have been considered and an incorrect item could not be found, whereupon a close approval (404) is sent to the terminal.

Figs. 6-7 depict illustrative examples of close batch processing and the types "2" and "3" protocol environments, as well as the steps employed in the balancing described in conjunction with Fig. 5. As in Figs. 2-4, the horizontal arrow indicates the direction of the flow of data.

Referring now to Fig. 6, there is depicted the close batch interactive protocol for a normal, or error free, transaction. More specifically, the terminal will first call the host (300) to establish a dial-up communications channel with the host. The host will then send an <ENQ> character (302) to the terminal to request packet communications from the terminal. For close batch processing, the terminal will respond by sending a batch transaction (304, 306), having a non-standard flag of "*" (306) which indicates an interactive protocol and a protocol flag of "3" (306) indicating a batch transaction.

The host then general polls the terminal (308, 5310) by sending an <ACK> character, thus informing the terminal that the host is prepared to receive all batch transactions, i.e., those off-line (including edited) transactions not yet sent to the host. The host general polls and continues to receive the batch transactions until the protocol flag is changed. Once all off-line items are transmitted by the terminal, the terminal then transmits a close transaction (312, 314) with a protocol flag of "2" (314) . This change to a protocol flag of "2" causes the host to stop general polling (316) and start balancing and processing the received transactions. Illustratively, and as described in conjunction with Fig. 5, such balancing includes comparing the terminal's and the host's calculation of the monetary value of all transactions in the batch (net batch amount) , the number of transactions in the batch (batch item count) , and the number of transactions transmitted before the close transaction during the same telephone call (items transmitted).

In the event that the host and terminal are out of balance, the host will employ error correction techniques including re-examining transactions from the terminal and revising calculations as necessary.

When balancing is complete, the host transmits a close approval (318) to the terminal. The terminal then responds by transmitting an acknowledgment character <ACK> (320) to the host whereupon the host transmits an end-of- transmission character <E0T> (322) to the terminal. Thus, the path defined by steps 312, 314, 316 an 318 of Fig. 6 corresponds to the path defined by items 400 402 and 404 in Fig. 5.

Advantageously, by piggy-backing off-line transactions onto on-line transactions in accordance with the present invention, the number of off-line transactions sent to the host as part of the batch transaction (306) is reduced and may in fact be zero. 10

Referring now to Fig. 7, there is depicted the close batch interactive protocol with host polling to reconcile the terminal and the host. Steps 324, 326, 328, 330, 332, 334, 336 and 338 are similar to steps 300, 302,

15304, 306, 308, 310, 312 and 314 of Fig. 6. Unlike Fig. 6 in which the host determined that no errors existed and then transmitted a close approval (318) , in Fig. 7 the hos detected an error and/or needed further information from the terminal to properly balance. Accordingly, the host

20 transmits a specific poll or revision inquiry (340, 342) t a specific terminal for further information. Such a specific poll is depicted in Fig. 5 as element 408 ("Request Specific Item"), while such a revision inquiry i depicted in Fig. 5 as element 410 ("Revision Inquiry") .

" *^st_ The terminal responds by transmitting the requested specific transaction or revision transaction (344) to the host. In the event that such additional information enables the host to properly balance, the host will then send a close approval (346) to the terminal. The terminal

30 then responds by transmitting an acknowledgment character

<ACK> (348) to the host whereupon the host transmits an end-of-transmission character <EOT> (350) to the terminal.

35 Referring now to Fig. 5 in conjunction with Fig. 7, it is seen that the path defined by steps 338, 340, 342 and 344 of Fig. 7 corresponds to the path defined by items 400, 402, 406 and 408 of Fig. 7 for a specific poll (i.e., request for a specific transaction) , or to the path define by items 400, 402, 406 and 410 of Fig. 7 for a revision inquiry (i.e., request for list of revised transactions).

As will be appreciated, numerous errors may be detected during close batch processing, some of which may be correctable and some of which may not be correctable. For example, the host may respond to the batch transaction (330 in Fig. 7) with a negative acknowledgment character <NAK>, indicating an error in the received batch transaction. In such an event, the terminal will retransmit the batch transaction which could then be acknowledged and any off-line transactions transmitted and balanced. Such a scenario is referred to as a correctable receive error. In the event that the retransmission of th batch transaction was also faulty, the host would respond by disconnecting from the telephone line. Such a scenario is referred to as a non-correctable receive error.

In the event that the terminal transmits a batch transaction (330 in Fig. 7) and the host responds with an acknowledgment character <ACK> (334 in Fig. 7) , the host will wait a predetermined amount of time for the terminal to start transmitting the remaining off-line transactions. Illustratively, such time amount is three seconds. In Fig 7, the terminal responded within this three second window. However, if the terminal does not respond within three seconds, the host may general poll again, transmitting another acknowledgment character <ACK>. The terminal should then respond with any remaining off-line transactions, or, if none, a close transaction. Such a scenario is referred to as a correctable failure to respon to a general poll. In the event that the terminal does no respond to the general poll within the three second window and does not respond to the subsequent general poll within the next three second window, a non-correctable failure to respond to a general poll would exist and the host would disconnect from the telephone line.

Similarly, in the event that the host does not respond within a specified time period, illustratively 45 seconds, to a close transaction (314 in Fig. 6) , the terminal will disconnect from the telephone line. This is referred to as a non-correctable failure to respond to a close transaction.

Likewise, if the terminal responds to a host's transmission of a close approval with a negative acknowledgment character <NAK>, the host would transmit another close approval. If the terminal acknowledges, a correctable host response transmit error would exist. If the terminal fails to acknowledge again, a non-correctable host response transmit error would exist, and the terminal and host would disconnect.

Additionally, if the terminal fails to acknowledge a close approval from the host within a specified time period, illustratively four seconds, the host will send another close approval. If the terminal again fails to acknowledge within the four second window, the host will disconnect from the phone line. This scenario is referred to as a non-correctable failure to acknowledge a host response. Similarly, if the host transmits a close approval, which is acknowledged by the terminal, and the host does not respond with an end-of-transmission characte <E0T> within a specified time period, the terminal will retransmit its acknowledgment. If the host again fails to respond within the time period, the terminal will disconnect.

Non-correctable errors generally result in a disconnect. The host and terminal may disconnect substantially simultaneously and/or independently; alternatively, if one disconnects, the other will recogniz the disconnect whereupon it will then disconnect itself.

The number of times a transmission is attempted, as well a the length of time-outs and specified time periods, depend on the specific embodiment.

By virtue of the foregoing there is thus provide an interactive communications sequencing method which enables off-line transactions to be piggy-backed onto an on-line transaction during communications between a host computer and a remote terminal. Advantageously, such a method enables end-of-day processing to be performed with minimum number of errors, if any.

While the present invention has been illustrated by description of an embodiment and while the illustrative embodiment has been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appea to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative example shown and described. For example, the invention is not limited to use in POS systems. Rather, the interactiv sequencing method disclosed and claimed herein may be used in any suitable communications network, such as a network of automatic teller machines (ATMs) . Additionally, while the sequencing method of the present invention has been described in the context of communications between the remote terminal and the host, it is also applicable to communications between the host and the various databases and the like. Accordingly, departures may be made from such details without departing from the spirit or scope of applicant's general inventive concept.

Claims

What is claimed is:

1. An interactive sequencing method for processing data relating to transactions in an electronic ticket capture system, comprising the steps of:

a) performing at least one off-line transaction at a remote terminal, said off-line transaction not requiring communication with a host when performed;

b) performing an on-line transaction at said remote terminal, said on-line transaction requiring communication with the host when performed;

c) establishing a communications channel with said host when said on-line transaction is performed;

d) after said communications channel is established, transmitting data relating to said on-line transaction to said host, and transmitting along with such data additional data relating to said off-line transaction; and

e) disabling said communications channel from said host and from said remote terminal.

2. The method of claim 1 further comprising the steps of:

a) examining each transaction transmitted to the host for errors once the host receives each of such transactions; b) in the event an error is detected, requesting additional information from said remote terminal prior to disabling said communications channel; and

c) in the event such additional information is requested, transmitting such requested additional information to said host prior to disabling said communications channel.

3. The method of claim 2 wherein said step of examining comprises comparing terminal values associated with at least some of said transactions with host values associated with at least some of said transactions.

4. The method of claim 3 wherein said values compris at least one of a net batch amount, a batch item count and an items transmitted.

5. The method of claim 1 further comprising, prior t the step of disabling, the steps of:

a) attempting to balance host transaction data with terminal transaction data; and

b) - in the event an error is detected, requestin data from said terminal regarding a specific transaction.

6. The method of claim 1 further comprising, prior t said step of disabling, the steps of:

b) in the event an error is detected, examining revision numbers associated with said transactions.

7. The method of claim 6 wherein said step of examining revision numbers comprises comparing a terminal revision number for a particular transaction with a host revision number for said particular transaction.

8. The method of claim 1 further comprising the step of:

a) performing a plurality of said off-line transactions at said remote terminal;

b) performing a plurality of said on-line transactions, each requiring independent communication with the host when performed;

c) after said communications channel is established, at least for some of said on-line transactions, and said data relating to an on-line transaction is transmitted to said host, transmitting along with such data, additional data relating to said off-line transactions; and

d) after said plurality of on-line transactions are performed, establishing a communications channel between said remote terminal and said host so as to enable data at said remote terminal to be reconciled with data at said host, said step of reconciling comprising the steps of: i) transmitting any off-line transactions remaining at said terminal to said host;

ii) examining said transmitted remaining off-line transactions for errors; iii) in the event an error is detected, requesting additional information from said remote terminal, and attempting to resolve such error; and

iv) in the event no errors are detected or all errors have been resolved, or in the event there were no transactions remaining at said remote terminal, disabling said communications channel established for reconciliation.

9. The method of claim 8 wherein said step of requesting additional information comprises requesting dat from said terminal regarding a specific transaction.

10. The method of claim 8 wherein said step of requesting additional information comprises requesting dat from said terminal regarding revision numbers associated with said transactions.

11. The method of claim 8 wherein said step of attempting to resolve comprises comparing terminal values associated with at least some of said transactions with host values associated with at least some of said transactions. -

12. The method of claim 11 wherein said terminal values include a terminal value identifying the monetary value of transactions sent by said terminal to said host, and a host value identifying the monetary value of transactions received by said host from said terminal, wherein said terminal value is compared to said host value to determine whether an error has occurred.

13. An improved interactive sequencing method for u in an electronic ticket capture system having a host computer and a plurality of remote terminals at which consumer credit transactions are performed, wherein such consumer credit transactions require communication with t host to determine whether such credit transactions will b authorized, such communication comprising placement of a telephone call to said host requesting authorization, followed by an idle period during which said host process said authorization request, followed by transmitting an authorization or denial to said terminal, wherein the improvement comprises the step of transmitting data relating to off-line transactions to said host during sai idle period, said off-line transactions having previously been performed at said terminal and not having required authorization from said host when performed.

14. The improved interactive sequencing method of claim 13 wherein the improvement further comprises the st of balancing terminal data relating to at least some of said transactions with host data relating to at least som of said transactions.

15. The improved interactive sequencing method of claim 14 wherein said step of balancing comprises compari data maintained by said host regarding at least some of said transactions with data maintained by said terminal regarding at least some of said transactions.

16. The improved interactive sequencing method of claim 13 further comprising the steps of:

a) examining each of said off-line transactions for errors upon being received by said host; and b) to the extent feasible, correcting any errors detected in said off-line transactions during the same phone call in which said off-line transactions were transmitted to said host.

17. The improved interactive sequencing method of claim 16 further comprising the step of performing close batch processing after a plurality of said consumer credit transactions have been performed, said close batch processing comprising the steps of:

a) placing a telephone call to said host thus establishing a communications channel between said host an said terminal;

b) transmitting all off-line transactions remaining at said terminal to said host;

c) reconciling data from said terminal with data from said host, such terminal and host data relating to consumer transactions including said consumer credit transactions; and

d) disabling said communication channel,

wherein the number of errors detected during said close batch processing relating to said off-line transactions is minimized, and wherein the number of off¬ line transactions transmitted to said host during said . . . . close batch processing is minimized.

18. The improved interactive sequencing method of claim 17 wherein any errors associated with said off-line transactions transmitted to the host before said close batch processing have been corrected.

19. An interactive sequencing method for use in processing consumer credit transactions, comprising the steps of:

a) establishing a dial-up communications channel between a host and a remote terminal by said remote terminal dialing a phone number associated with said host;

b) transmitting from said host to said terminal a signal requesting packet communications from said terminal;

c) responsive to said signal requesting packet communications, sending an authorization request to said host from said terminal requesting approval of a consumer credit transaction;

d) responsive to said authorization request, polling said terminal by said host to inform said terminal that said host is prepared to receive off-line transactions;

e) responsive to said polling, transmitting to said host from said terminal at least one off-line transaction;

f) transmitting a host response to said terminal from said host, said host response including an approval or a denial of said authorization request; and

g) disabling said dial-up communications channel.

20. The interactive sequencing method of claim 19 further comprising the steps of: a) after said step of transmitting said host response, and before said step of disabling, transmitting an acknowledgment signal to said host from said terminal indicate that the terminal has received said host respons

b) after said acknowledgment signal is received by said host, and before said step of disabling, transmitting an end-of-transmission signal to said termin from said host, followed by said step of disabling.

21. The interactive sequencing method of claim 19 wherein said off-line transaction includes a flag which indicates that the following communication between said host and said terminal is to be interactive.

22. The interactive sequencing method of claim 21 wherein said authorization request includes a flag which indicates that the following communication between said host and said terminal is to be interactive.

23. An interactive sequencing method for use in processing consumer credit transactions, comprising the steps of:

a) -establishing a dial-up communications channe between a host and a remote terminal by said remote terminal dialing a phone number associated with said host

b) transmitting from said host to said terminal signal requesting packet communications from said termina c) responsive to said signal requesting packet communications, sending a batch transaction signal to said host from said terminal . indicating that at least one off¬ line transaction remains at the terminal and needs to be transmitted to the host;

d) responsive to said batch transaction signal, polling said terminal by said host to inform said terminal that said host is prepared to receive off-line transactions;

e) responsive to said polling, transmitting to said host from said terminal all of said off-line transactions remaining at said terminal;

f) after the last of said transactions remaining at said terminal is transmitted to the host, transmitting a close transaction signal to said host from said terminal;

g) after receiving said close transaction signal, reconciling and balancing data relating to said off-line transactions received by said host from said terminal following said batch transaction signal;

h) -after reconciling and balancing, sending a host approval signal to said terminal from said host; and

i) disabling said dial-up communications channel.

24. The interactive sequencing method of claim 23 further comprising the steps of: a) after receiving said host approval signal, an before said step of disabling, transmitting an acknowledgment signal to said host from said terminal to indicate that the terminal has received said host approval signal; and

b) after said acknowledgment signal is received by said host, and before said step of disabling, transmitting an end-of-transmission signal to said termina from said host, followed by said step of disabling.

25. The interactive sequencing method of claim 23 wherein said batch transaction signal includes a flag whic indicates that the following communication between said host and said terminal is to be interactive.

26. The interactive sequencing method of claim 25 wherein said close transaction signal includes a flag whic indicates that the following communication between said host and said terminal is to be interactive.

27. The interactive sequencing method of claim 23 further comprising the step of, after receiving said close transaction signal, reconciling and balancing data relatin to on-line transactions which were performed at said terminal prior to said terminal transmitting said transaction signal to said host.

28. The interactive sequencing method of claim 27 wherein said step of reconciling and balancing said on-lin transaction data comprises the step of comparing on-line transaction data maintained by said terminal with on-line transaction data maintained by said host.

29. An improved interactive sequencing method for us in an electronic ticket capture system having a host computer and a plurality of remote terminals at which consumer credit transactions are performed, wherein such consumer credit transactions require communication with th host to determine whether such credit transactions will be authorized, such communication comprising placement of a telephone call to said host requesting authorization, followed by said host transmitting an authorization or denial to said terminal, wherein an end-of-day processing is performed after a plurality of consumer credit transactions are performed, wherein the improvement comprises the step of balancing transaction data maintaine by a remote terminal with transaction data maintained by said host, said step of balancing occurring as part of sai step of performing end-of-day processing, said step of balancing comprising the step of comparing said terminal transaction data with said host transaction data to determine whether said terminal transaction data includes data relating to transactions which were not transmitted t said host.