|
PatentVote.com: Vote on your favourite invention!
|
|
 |
Title: Transaction execution system with secure data storage and communications
Description: Description:
CROSS REFERENCE TO RELATED APPLICATIONS This application is related to the following patent applications which are concurrently filed herewith and assigned to a common assignee: 1. "TRANSACTION TERMINAL WITH UNLIMITED RANGE OF FUNCTIONS", Ser. No. 483,058, filed June 25, 1974, by William A. Boothroyd et al. 2. "MODULAR TRANSACTION TERMINAL WITH MICROPROCESSOR CONTROL", Ser. No. 482,860, filed June 25, 1974, by William A. Boothroyd. BACKGROUND OF THE INVENTION 1. Field of the Invention This invention relates to transaction execution systems and more particularly to secure transaction execution systems having a central data base in communication with remote terminals which permit the execution of transactions such as the issuance of cash or the interaccount transfer of funds. 2. History of the Prior Art For reasons of public convenience and economy a variety of systems have been developed for executing user requested transactions. One example is a check cashing machine. Such a machine reads data from a check inserted therein and issues cash equal to the amount of the check if the check is found to be in order. Other systems have been developed for use in conjunction with credit cards. One credit card system stores credit card account information in a central data base. In response to the submission of an account number from a remote terminal, the system provides information relating to the account. For instance, the system may indicate that the card has expired, that it has been stolen or may indicate the dollar amount of available credit. After a transaction is completed the system properly adjusts the stored information to account for the transaction. Other credit card systems, which are frequently used by banks to extend their services during times of heavy business or business closure, permit the issuance of cash or the receipt of deposits through a terminal. Such a terminal typically includes a mechanism for receiving and reading information from a credit card, a keyboard, a display and document entry and exit apertures. The terminal may operate in conjunction with a data base or as a stand alone unit. Increased security for the issuance of cash without human intervention is attained by issuing a personal ID number with each credit card. A credit card transaction is then enabled only when an ID number corresponding to the account number read from the credit card is entered through the keyboard. This required correspondence prevents a thief or mere finder of a credit card from receiving cash from a terminal. If a terminal operates in conjunction with a data base the correspondence between account numbers and ID numbers can be chosen at random, but frequently the ID number is derivable from the account number in accordance with a predetermined code. This predetermined relationship permits a stand alone terminal to check the ID number by algorithmically relating the ID number to the account number. While this dual credit card and ID number identification technique improves the security of cash issue terminals, there are still weaknesses that may be exploited to gain access to the large amounts of cash that are stored in the terminals. For instance it may be necessary to employ a substantial number of computer operators, programmers, analysts and other people at the host data base who have at least limited access to information stored in the host data base. It would be possible for any of these people to compile lists of account numbers and corresponding ID numbers to be used in conjunction with forged or stolen credit cards to obtain cash. An equally serious problem relates to the security of the encryption algorithm for terminals which are capable of stand alone operation. A large number of operators or maintenance personnel are required for the day-to-day support of cash issue terminals. For example, one or two people at each branch bank location may have internal access to the cash issue terminals. Often times these people may have access to the encryption key for normal maintenance. Alternatively, with only a little training these people could learn to acquire the key by measuring electrical signals on the internal circuitry. Once the encryption key is acquired, a correspondence between a large number of account numbers and ID numbers could be generated. Another possible security problem arises from the transmission of account information and ID information between a terminal and a host data base. These transmissions often involve utility communication lines and are therefore subject to monitoring by a large number of people. Encryption is often used to improve communication security but anyone who is able to break the code or gain access to the code would be able to extract and compile a list of correspondence between credit card account information and ID numbers by monitoring these transmissions. In addition, by generating fake terminal communication traffic a person might gain access to the host data base and fraudulently transfer funds within data base accounts. Thus, while protected against a common thief, conventional systems which use this dual identification technique are not adequately protected against a sophisticated thief having knowledge of modern data processing equipment. SUMMARY OF THE INVENTION A transaction execution system in accordance with the invention includes a host data processing system having a data base of stored information for many accounts and a plurality of transaction terminals. The host operates to approve or disapprove indicated transactions, to properly account for executed transactions and provide support information for the terminals. The transaction terminals are operatively stand alone units which are connected for communication with the host from scattered locations. Each terminal includes a document handling subsystem for cash or transaction statements, a credit card reading subsystem, a host communication subsystem, a user communication subsystem, and an operational control subsystem including a programmable microprocessor. The document handling subsystem includes a cash storage mechanism, a transport mechanism for issuing cash to a user under the supervision and control of the microprocessor and a transaction statement dispenser issuing printed statements under control of the microprocessor. The credit card reading subsystem operates under control of the microprocessor to receive and read user credit cards which may be either returned or retained after the processing of a transaction request. The host communication subsystem provides an interface for the proper transmission of information between a terminal and a host in accordance with predetermined communication formats. The user communication subsystem operates in response to the microprocessor to control user access to the terminal and includes a keyboard receiving user commands and a display interactively providing user guidance. A user wishing to execute a transaction must insert a credit card into a terminal and then enter personal ID and transaction request information through the keyboard. The terminal then optionally encodes a selected portion of the credit card information using a first encryption key to obtain encrypted ID information which may be tested for correspondence with a selected portion of the keyboard entered ID information. In the absence of a predetermined correspondence the transaction is terminated, the host is informed via a message and the host reply defines the action against the card which is selectively returned or retained. If correspondence is found, the entered ID information is encoded using a second encryption key which may be the same as the first encryption key. The encrypted ID information is combined with variable information such as a sequential transaction number or cash count to prevent repetitive transmission of identical encryption fields and then encoded again using a third transmission key. This encryption process allows the host data base to have stored not the ID number, but only an encrypted ID number. The data base is thus secured against the surreptitious extraction of an account number and ID number correspondence list from which counterfeit cards could be created. The encrypted ID information is combined with clear text request and credit card information and is then communicated to the host data processing system. A three part transaction execution sequence begins with a transaction request message which provides the host with the encrypted ID number, which is combined with variable data and reencrypted, credit card information and transaction request information entered through the keyboard. For example, the user might request the issuance of $100 from his credit card account. Upon receipt of a request the host checks for correspondence between the transmitted encoded ID number and the encoded ID number stored in its data base, checks for account restrictions such as a maximum credit limit, and if everything is in order transmits a reply message authorizing the transaction. If all is not in order the host disapproves the requested transaction. Like the request message, the subsequent reply message includes an encrypted portion containing an action command and variable data such as a cash count number or a transaction number. After the encoded information is combined with clear text information such as transaction statement information and display information the reply message is sent to the requesting terminal. Upon receipt by the requesting transaction terminal of the transaction reply message, the terminal decrypts, checks the accuracy of the variable data to insure against error and then executes the commanded actions. The terminal then generates a status message to inform the host of the execution or cancellation of the transaction and of any error conditions at the terminal. An encrypted portion of the status message includes the transaction number, the number of status bytes in the message and the cash counter status. The host responds by properly accounting for the indicated transaction by recording the transaction or updating the data base. If an error condition is indicated the host may transmit a command message to attempt to correct the error or close the terminal if the error cannot be corrected. Use of this data message technique makes the encryption keys very difficult to break and provides a communication redundancy to insure that the host and a terminal are responding to correct messages. In addition, the correspondence between personal ID numbers and account numbers is protected by an encryption scheme that avoids the necessity of storing both in the host data base. BRIEF DESCRIPTION OF THE DRAWINGS A better understanding of the invention may be had from a consideration of the following detailed description taken in conjunction with the accompanying drawings in which: FIG. 1 is a functional block diagram representation of a transaction execution system in accordance with the invention; FIG. 2 is a functional block diagram representation of a transaction terminal used in the transaction execution system shown in FIG. 1; FIG. 3 is an operational block diagram representation of the manner in which a user initiated transaction request is initially processed by a transaction terminal; FIG. 4 is an operational block diagram representation of the manner in which transaction requests received by a transaction terminal are processed by a host data processing system; and FIG. 5 is an operational block diagram representation of the manner in which a transaction reply message from a host is processed by a transaction terminal. DETAILED DESCRIPTION Table of Contents Transaction Execution Terminal Terminal Information Bus Processor Support Subsystem Mechanical Control Subsystem User Communication Subsystem Transaction Statement Dispenser Subsystem Operator Function Subsystem Communication Subsystem Remote Connector Communication Message Format Transaction Message Assembly 1. Transaction Request Message 2. Transaction Reply Message 3. Execution and Status Message INTRODUCTION A transaction execution system 10 in accordance with the invention includes a host data processing system 12 and a plurality of user transaction terminals 14 in communication therewith. The host data processing system 12 includes a host central processing unit 16 such as an IBM system 370, a communication controller 18 such as an IBM 3705 and a data base 20 which may include electrically alterable random access memory, magnetic tape transports, and magnetic disks. The host CPU performs the arithmetic and logical operations which are required for controlling the operation of the host data processing system 12 and processing information which is received through the communication controller 18 or stored in the data base 20. The data base 20 stores information which is related to each customer of the host central processing system 12. For instance, for a banking customer, the data base might store account information for credit card, savings, checking or other accounts of the bank as well as payroll information and information relating to the financial status of the bank's operations. Each account might be typically addressable in accordance with an account number and have stored therein the current account information such as the current balance, a history of account transactions for a predetermined period of time, encoded personal ID numbers for persons who are authorized to use the account, a maximum credit limit, and any other information the bank may wish to store as part of an account. The communication controller 18 acts as an interface between the CPU 16 and a plurality of communication channels 20. The controller 18 arranges information received by the host 16 into a communication discipline and maintains communication synchronization. A transaction terminal 14 may be connected for communication with the host data processing system 12 in an almost unlimited number of ways with the various methods shown in FIG. 1 being only exemplary. For instance, a terminal may be connected directly to the communication controller 18 by either a local communication link such as cable 24 for local user transaction terminal 26 or a utility or radio link 28 for a remote user transaction terminal 30. Alternatively, a terminal may be connected to the host central processing system 12 through a controller 32 such as an IBM 3601 by either direct connection to the controller 32 as by cable 34 for terminal 36 or by connection in a communication loop 38. Although other devices may be included, the communication loop 38 is illustrated by way of an example as including a first teller work station 40, a second teller work station 42, a first user transaction terminal 44 and a second user transaction terminal 46. While the communication loop 38 may include remote transmission links such as radio communication or communication over commercial utility lines, for a bank system, the controller 32 might typically be located at a branch bank with all data processing terminals at the branch bank being connected into the loop 38. The controller 32 may itself be connected to a communication channel 22 of communication controller 18 either directly through a communication link 48 such as a utility communication line as shown in FIG. 1 or may itself be connected in a communication loop such as the loop 38 which extends to a communication channel 22 of communication controller 18. A description of one such communication system may be found in patent application Ser. No. 482,940, filed June 25, 1974, entitled "SEMI STATIC TIME DIVISION MULTIPLEX SLOT ASSIGNMENT" by C. McClearn and T. A. C. Miller IBM (KI973007). In general, the controller 32 merely acts as a relay device for information which is passed around the loop 38 but may also serve as the host data processing system when immediate, real time communications with the host data processing system 12 are not maintained. When serving as the host, the controller 32 must store transaction execution information for later processing by the system 12 and must provide host support functions which are required for operation of a terminal 14. TRANSACTION EXECUTION TERMINAL While the particular manner in which a transaction terminal 14 is implemented is not critical to the practice of this invention, a preferred embodiment of the transaction terminal 14 is shown in FIG. 2. The terminal 14 is generally modular in nature and includes a programmable microprocessor 60 coupled to a plurality of terminal subsystems by an information bus 62. The microprocessor 60 is driven by a clock signal from clock signal generator 64 and is operationally connected to a data storage module 66 providing both electrically alterable random access memory (RAM) and read only storage (ROS). The read only storage portion of the data storage 66 stores the various operating programs for the microprocessor 60. The random access memory portion of data storage module 66 provides a scratchpad for program execution. With typical IC memories the contents of the RAM are lost in the event of a power failure. TERMINAL INFORMATION BUS The microprocessor 60 communicates with the modular subsystems solely through the terminal information bus 62. This technique of interconnecting modular subsystems with the microprocessor 60 through the bus 62 permits the microprocessor 60 to receive detailed information on the terminal status and maintain detailed direction of terminal hardware operations without a large number of input and output information connections. The task of sensing terminal status information is performed by the individual terminal subsystems. This information is then transferred to the microprocessor 60 on command from the microprocessor 60. Similarly, the driver circuitry and hardware for executing microprocessor commands is contained within the subsystem modules. The microprocessor commands are extremely basic and detailed in nature. Each command accomplishes a basic subsystem operation such as the activation or deactivation of a motor, the display or printing of a character, the feeding of a bill or the reading of a communication character. The information bus 62 includes a system reset signal, nine data input signals (eight bits + parity) for carrying information to the processor 60, nine data output signals (eight bits + parity) for carrying information from the microprocessor 60 to an operably connected subsystem, and bus control signals for controlling the transfer of information onto and off from the bus 62. PROCESSOR SUPPORT SUBSYSTEM One of the operational subsystems which is connected through bus 62 to micro-processor 60 is processor support subsystem 68. Processor support subsystem 68 provides hardware assistance to the microprocessor 60 in contrast to other terminal subsystems which have functions related to particular aspects of terminal 14 operation. Processor support subsystem 68 receives a 1 MH.sub.z clock signal from clock signal generator 64 and divides this signal to generate lower frequency clock signals which are used in the other subsystems. One lower frequency clock signal is utilized for the generation of periodic interrupt commands at 10 msec. intervals. These interrupt commands cause interrupt logic within processor support subsystem 68 to generate a microprocessor interrupt every 10 msec. The microprocessor 60 utilizes these clock period interrupts to maintain an event control time base for the various operations of the terminal 14. Reset logic within subsystem 68 controls the reset line of the information bus 62. Activation of this reset line causes initialization of the processor 60 as well as all modules which are connected to bus 62 and cancels any pending user transaction. The processor 60 is returned to a predetermined program instruction from which program execution can begin anew following the reset. The reset signal is activated in response to AC power on, a reset switch, or a hang signal from a hang detector within operational hardware subsystem 68. The hang detector monitors the control lines of the bus 60 and generates a hang signal when bus activity ceases for a length of time which is sufficient to indicate that the microprocessor 60 is not operating properly. A run detector responds to the timer interrupt request signals and generates a run signal which is maintained active so long as the microprocessor regularly responds to the requests. If a predetermined period of time elapses without the processing of a timer interrupt request, the run detector terminates the run signal. The processor support subsystem 68 also includes read data logic which receives a string of serial information as it is read from a user credit card, separates the data from the clocking information, deserializes the binary bit stream and places the information on the bus 62 for processing by the microprocessor 60. MECHANICAL CONTROL SUBSYSTEM A mechanical control subsystem 70 provides the actual mechanical manipulation of various hardware features of the terminal 14. Subsystem 70, which like the other subsystems has no branching or decision making capability, executes basic, elemental commands from the microprocessor 60 and collects information on the physical status of the various hardware functions for communication back to microprocessor 60. As an example of the individual elementary nature of functions which are executed by mechanical control subsystem 70, a credit card handler mechanism responds to a credit card direction and move commands to activate a motor which drives a card conveyor system to move the credit card beneath a read head. Sensors (switches or photocells) are positioned to sense the presence of the credit card at (1) entry, (2) exit jam sensor, and (3) card escrow positions. When a sensor is activated an information bit is available in a status word to indicate this condition. When the microprocessor 60 periodically reads the various status words during a read operation it determines that the credit card has reached the escrow area where the card is held. Processor 60 then commands that the credit card feed motor be reversed for a short period of time to "brake", and then commands that the motor be turned off. In similar elemental fashion, the mechanical control subsystem 70 controls the complete processing the credit card such as retention or return to the user. Other functions include control of the depository wherein the user may deposit documents which are passed into a retention bin in such a manner that the user never has access to the retention bin. Similarly, the mechanical subsystem 70 controls the opening and closing of user access doors and the issuance of predetermined amounts of cash to an escrow area at which printed transaction statements may also be accumulated along with the cash and the issuance or retention of documents presented to the escrow area. In addition to sensing the status of mechanical hardware which is manipulated by mechanical control system 70, the control subsystem 70 senses the presence of cash stored by the cash issue hardware and indicates when there is not enough cash available to execute a maximum issue transaction. Subsystem 70 also senses several conditions that may be communicated to a remote control panel as well as the processor 60. These remote signals include an indication of whether the service door is opened, whether or not a penetration sensing grid has been disturbed, and whether or not an "intervention required" condition exists. Other signals which may be communicated to the remote panel include transaction statement forms or cash low, operator access service door open, communication between the terminal and host ready. Command switches located on a remote panel may include a terminal reset switch and a wrap switch which commands a test of the communication link. USER COMMUNICATION SUBSYSTEM A user communication subsystem 72 controls bidirectional communications between the terminal 14 and a user. The communication subsystem 72 includes a keyboard for receiving user generated commands, a display of 222 horizontal dots by seven dots and includes display control logic and a refresh buffer. The display control logic receives the "dot image" of the particular display and then continues the display until a contrary command is received. The keyboard is divided into several fields with a plurality of keys in each field. For instance, a transaction selection field indicates the type of transaction a user wishes to execute. Other fields include a from account select field indicating an account from which funds are to be taken, a to account select field indicating an account to which funds are to be deposited and a numeric keyboard field permitting the entry of decimal numbers such as personal ID numbers or dollar amounts. "Back lights" are provided on the function select, to account, and from account keys to generate an audit trail indicating to a user which keys have been selected in previously used fields. All back lights are illuminated in the field in which the next key activation should occur. For instance, as a user inserts his credit card into the terminal 14 he is requested to key in his personal ID number. After proper receipt of the ID number all of the keys in the function selection field would become lighted. As the user activates a particular key, such as a funds transfer key, the other back lights are extinguished with only the funds transfer key remaining backlighted. All keys in the next field such as the from account field are then illuminated in preparation for the next step in the transaction request. In this way an audit trail is provided to indicate previous selections and the next selection field is also indicated. Display messages and color coding may also be used to guide the user in the proper sequence. The keyboard control logic of the user communication subsystem 72 includes the circuitry necessary to back light specific keys commanded by the microprocessor 60 and to indicate to the microprocessor which keys have been activated by a user. TRANSACTION STATEMENT DISPENSER A transaction statement dispenser subsystem 74 includes a form handler for transporting transaction statement forms, a printer, printer control logic and logic for interfacing the subsystem 74 with bus 62. The transaction statement dispenser subsystem 74 performs only specific, basic commands such as starting movement or printing of specific characters. The subsystem 74 collects information on the physical status of the transaction statement dispenser hardware for communication through bus 62 to the microprocessor 60. This information is then used by the microprocessor 60 which operates under program control to detect the successful completion of a particular elemental function and commands the initiation of additional functions. OPERATOR FUNCTION SUBSYSTEM An operator function subsystem 76 provides operator maintenance interfacing and includes entry switches, a four digit hexadecimal display, power sense circuitry, a 128 byte power off protected auxiliary memory which is used for storing system parameters and logging exception information. Stored parameters include a cash counter number, encryption keys and a transaction number. Access to the operator panel is through a double locking door at the rear of the terminal 14 which must be closed for user operation. Opening of the access door and attempting a maintenance function causes destruction of encryption keys which are normally stored in this auxiliary memory. This destruction of the keys provides security of the keys from an operator who might seek to use electronic instruments to read the key from the nonvolatile memory. The keys must then be re-entered through the keyboard by a person of high trust before the terminal can be reopened. The eight byte keys are each entered as 16 hexadecimal digits two digits at a time. Only the two preceding digits are displayed as the keys are entered to increase the difficulty of an interloper discovering the keys. Alternatively, a Key A which defines the correspondence between account numbers and personal ID numbers may be even further protected by requiring entry of a deencrypted Key A (Key A') which is encrypted in accordance with a fourth encryption key to produce the actual Key A. Using this technique the actual Key A can remain secure from all personnel at the physical location of the terminal 14. The power sense circuitry monitors both the AC utility voltage level and the internal DC power levels and in the event of an indication that AC power is lost and the DC voltage levels are low but still usable, a signal is sent to the microprocessor 60 causing critical information to be saved and then access to the auxiliary memory is restricted while the memory is driven from an auxiliary power source. An indication signal is provided to the operator panel so long as the DC logic voltages are adequate. COMMUNICATION SUBSYSTEM A communication subsystem 78 provides communication interfacing between a communication channel and the information bus 62. Communication subsystem 78 is conventional in nature and receives information from or provides information to terminal information bus 62 one byte at a time. REMOTE CONNECTOR A remote signal connector 82 permits the connection of some status signals and some control signal inputs to a remote control panel which is actually part of the terminal 14. For instance, a bank branch might have five terminals 14 and a single centralized remote control panel with optical displays and control switches for each of the five terminals 14 at a convenient centralized location. These remote signals are primarily for monitoring terminal operation or controlling special conditions and are not utilized for normal user transactions. The particular remote panel has been previously explained. COMMUNICATION MESSAGE FORMAT There are essentially two different types of messages which may be sent from a terminal 14 to a host data processing system and four types of messages which may be sent from the data processing system 12 to a host transaction terminal 14. The terminal to host messages include a transaction request message which is the normal first communication message following a user initiated transaction and a status message which is typically the last of a three message sequence. There are two basic types of status messages. The first is a reply status message which serves as the third communication message in a normal user transaction sequence and informs the host of the completion or cancellation of a user requested transaction. The second is an exception status message which indicates a status or condition for a terminal 14 other than a normal operating condition. For example, an exception status message would be sent in reply to an inquiry command from the host data processing system, when the service door is opened, upon detection of a serious error condition such as a user door jam or a hard machine failure or any time initialization is required. The four types of messages which may be transmitted from a host data processing system 12 to a transaction terminal 14 include a transaction reply message, command message, a load initialization message, and an echo message. The transaction reply message is the normal response to a transaction request message during the course of a normal user transaction and informs the terminal 14 of the manner in which the requested transaction should be completed. A command message commands changes in a terminal 14 logical state and may also serve as an inquiry for a status message if no changes are desired. A load initialization message is sent from a host to a terminal 14 in response to an exception status message requesting initilization (IPL). The load initialization message contains message text, option selection information, font tables, program routines, and data information for storage in the volatile random access portion of data storage 66 of the microprocessor 60 within a terminal 14. An echo message is used as a diagnostic assurance test and can be sent only when a terminal 14 is in a closed state. The terminal 14 responds to an echo message with an echo message. There are only three basic message sequences which may be used for the communication of messages between a terminal 14 and a host data processing system 12. A single message sequence consists of an exception status message transmitted from a terminal 14 to a data processing system 12. The exception status message may either indicate that an abnormal condition has occurred or be a request for initialization. A "command message" from the host is not required. The message contents indicate which is the case. A two message sequence may include either a command message or a load initialization message from a host data processing system 12 to a terminal 14 followed by an appropriate status message from the terminal 14 to the host data processing system 12 or a host echo message followed by a terminal echo message. The transaction terminal 14 will reject a command that is received while the terminal is processing a previous command, an unintelligible message, or an unrequested transaction reply message. In each instance the host may be either a remote system or a directly connected local system. Each time the terminal 14 assumes an initial power on condition, for whatever reason, the terminal 14 must request and receive a load initialization message from the host data processing system before the terminal 14 can be reopened to accept transactions. Transaction terminals such as terminals 36, 44, and 46 in FIG. 1, which are connected to a controller 32 may operate in an off-line mode. Under such circumstances, the controller 32 serves as the host data processing system and merely records user transactions, for example on magnetic tape or disk. The transaction information is then made available to a transaction accounting system at a later time to permit the updating of accounts. If operating in an on-line mode, some host functions may be handled by the controller 32 such as storage of the initialization program for the terminals, but normally all communications are merely communicated to the host data processing system 12 without change. In such an on-line mode of operation, the host data processing system 12 may update account records stored in its data base in real time; that is as user requested transactions are executed. Each time a terminal 14 loses power information is lost from the RAM portion of data storage 66, and initialization must be requested at power turn-on. After the receipt of initialization information from the host a terminal 14 may be opened to receive user transactions, but only on command from the host. Initialization is accomplished by a terminal 14 using the single message format to send an exception status message requesting initialization. The host data processing system then initiates a new communication sequence by sending an initialization message (in multiple parts) containing the requested initialization information. Upon successfully receiving the initialization information the requesting terminal 14 completes the two part message sequence by sending a status message back to the host data processing system. Every message which is sent between a transaction terminal 14 and a host data processing system 12 begins with a four byte header field. Byte 1 of the header field is a message length byte (L) containing a binary count of the number of message bytes in the message text (including L). Byte 2 is a 1 byte transaction sequence number (N) in binary form. This number is incremented for each new user transaction and is included in all messages exchanged for that transaction. The number has a range of 1 to 255 inclusive. Zero (hex 00) is used for messages that do not relate to a user transaction. Thus, a transaction number counter which is incremented for each new user transaction overflows from hex FF to hex 01. The transaction number (N) is stored in the power out protected auxiliary memory of operator function sub-system 76 so that it remains available after a short term power outage. Byte 3 of the common header field is a class byte (C) which identifies the type of message and thus the format of the message which is being sent. Byte 4 is the final byte of the header field and identifies a message sub-class (SC) which serves as a modifier to the message class byte. Only a few of the possible combinations of message classes (C) and sub-classes (SC) are actually implemented. Class hex 01 identifies a transaction request message from a terminal 14 to a host data processing system. Within class 01, nine sub-classes have been implemented. Sub-class hex 00 indicates that a user requested transaction is incomplete because the ID number has not been properly entered. Sub-class hex 01 indicates a cash issue request. Sub-class hex 02 indicates an account inquiry. Sub-class hex 03 indicates that a user is requesting to deposit funds. Sub-class hex 04 indicates that a user is requesting to transfer funds from one account to another. Sub-class hex 05 indicates that a user is requesting to pay a loan or bill by depositing money in the transaction terminal. Sub-class hex 06 indicates a special transaction wherein the nature of the transaction is identified by entry of a predetermined number through the keyboard rather than by activation of a single key in the transaction selection field of the keyboard. Sub-class hex 07 indicates that a requested transaction is incomplete because the deposit flap covering the deposit bin has been jimmied. Sub-class hex 08 indicates a user request to pay a bill or loan by the transfer of funds from one account to another. A class of message designated C = hex 15 identifies a status message from a terminal 14 to a host data processing system 12. There are five sub-classes of messages under this class. Sub-class hex 01 indicates a transaction completion status message. Sub-class hex 02 indicates that the message is in response to the execution of a command and the status number, N, in the common header must be set to 0. Sub-class hex 03 is an exception status message indicating an error condition or requesting initialization and the transaction number N must be set to 0. Sub-class hex 04 indicates that the status message is in response to initialization and the transaction number N must be set to 0. Sub-class hex 08 is a recovery request or command response message and the transaction number N must be set to 0 for this message. A recovery request indicates that the host has lost track of the current transaction and requires an update. The terminal responds with an exception status message. A transaction reply message from a host data processing system to a transaction terminal 14 is indicated by class hex 0B. There are nine sub-classes indicated by the sub-class byte under this sub-class. Sub-class hex 00 indicates that the transaction is incomplete because the ID number was not properly entered. Sub-class hex 01 indicates a cash issue transaction request. Sub-class hex 02 indicates an account inquiry transaction request. Sub-class hex 03 indicates a deposit transaction request. Sub-class hex 04 indicates a funds transfer transaction request in which funds are to be transferred from one account to another. Sub-class hex 05 indicates a transaction request for the payment of a loan or bill by transfer of funds deposited in the terminal to an account. Sub-class hex 06 indicates a special optional selection transaction wherein the nature of the transaction is determined in accordance with a number entered through the numerical keyboard rather than by the activation of a single key in the transaction selection field of the user keyboard. Sub-class hex 07 indicates that the message relates to a requested user transaction which is incomplete because the deposit flap of the terminal 14 has been jimmied. Sub-class hex 08 indicates a user transaction wherein a loan or bill is to be paid by transferring funds from one account to another. Class hex 0C identifies a command message from the host data processing system to a terminal 14. A command message does not relate to a particular transaction and therefore the transaction number N of the header field is always set to 0. Sub-class hex 01 indicates an open command. Sub-class hex 02 indicates a command to close the transaction terminal 14. Sub-class hex 03 indicates an inquiry type of message in which a transaction terminal 14 may not perform any function in response to the command but must respond with a status message. Sub-class hex 04 indicates a command to change the third key (key B) which is the transmission encryption key from the present key to a key contained within the message. Sub-class 05 indicates a command to set the transmission encryption key (key B) using a back up key (key C). Sub-class hex 06 indicates that a transaction terminal 14 is commanded to request an initial program load. Sub-class hex 07 indicates that the message includes a command to either change the optical display or contains a written message to be printed by the transaction statement dispenser. Sub-class hex 08 is a command for transaction terminal 14 to send a class hex 15 sub-class hex 08 recovery request message back to the host. The load initial program message from the host to a transaction terminal is designated class hex 0D and has only one sub-class which is designated hex 01. An echo message from the host data processing system to a terminal 14 is designated by class hex 10. Within this class there are four sub-classes of echo messages. Sub-class hex 00 is the basic echo message and merely commands the transaction terminal 14 to retransmit the echo message back to the host data processing system. Sub-class hex 01 indicates an echo canned message command which is both checked for bit pattern and echoed. The bytes of data in the canned text are designed to send all possible bit patterns to check the operation of communication facilities. The message pattern is retained by the terminal for comparison with a second transmission of the message pattern. An echo variable record sub-class designated hex 02 is similar to the canned echo sub-class except that the message may contain host entered data. The transaction terminal echos the message back and also retains the message in storage for comparison with a second transmission of the same message. Upon receipt of the second transmission of the message, the transaction terminal checks and echoes as for sub-class 01. A log data request message is designated sub-class 03. This will cause the terminal to send the 8 most current error log records. No encryption or decryption is involved in the transmission of any echo message. The four byte common header field of each message is followed by the message data in a format that depends upon the particular type of message that is being sent. For a transaction request message from the terminal 14 to the host data processing system bytes 1-4 of the common header are followed by bytes 5-8 which contain a 32 bit encrypted field. This 32 bit encrypted field will be discussed in greater detail later, but in general the field includes an encrypted form of the personal ID number which was entered through the user keyboard and one byte of varying information which may be either the contents of a cash counter or a transaction number counter. Byte 9 is a from account select (FAS) byte indicating which key within the from account selection field of the user keyboard was activated. The data content of this ninth byte indicates the type of account from which the funds for the user requested transaction are to be taken. Hex 21 indicates from a checking account, hex 22 indicates from a savings account, hex 23 indicates from a credit card account, and hex 24 indicates from a special optional selection account, which is further defined by a numeric modifier. By making special arrangements with the bank, a user can open multiple accounts. These accounts can then be assigned predetermined three digit (decimal) numbers. By activating the special optional selection from account key on the keyboard the user is then permitted to enter up to three decimal numbers through the numerical keyboard to indicate which of possibly many predefined accounts he wants debited. This account identification number is transmitted one digit per byte in bytes 10-A where A may assume the values 10, 11 or 12 depending on whether the special keyboard determined account number contains one, two or three digits respectively. Because the FAS field may have a variable length, it must be followed by a field separator (FS) byte having the data content hex FE which is used to define the limits of variable length fields. Adjacent field separators indicate a zero length or no entry field between them. The FS byte delimits the end of the field preceding the FS byte. Following the FS byte for the from account select (FAS) field is a to account select (TAS) field designating an activated key within the to account select field of the user keyboard. Hex 31 indicates that funds are to be deposited to a checking account, hex 32 indicates to a savings account, hex 33 indicates to a credit card account, and hex 34 indicates to a special optional selection to account select key which may be modified by up to three digits (decimal) immediately following the first TAS byte. These numeric modifiers have the same meaning in the TAS field as in the FAS field. Because the TAS field is variable in length it must also be followed by a field separator (FS) byte having data content hex FE. Following the field separator byte for the to account select field, the data which is read from the magnetic stripe on the credit card is transmitted. By removing the parity bit from the standardized code of the American Bankers Association, it is possible to pack two four bit characters of credit card data in each byte of the message. In the event that an odd number of credit card characters appears on the credit card, the last byte is padded with a hex F to fill all bytes of the message. Start of card characters, end of card characters and longitudinal redundancy check (LRC) characters are excluded from the transmitted transaction request message in as much as they are checked by the terminal 14. A status message from a terminal 14 to the host data processing system begins with the four byte common header field identifying the message length (L), transaction number (N), message class (C), and message sub-class (SC) for the message. In byte positions 1-4. Byte positions 5-8 contain a 32 bit encrypted field. This 32 bit field will be discussed in greater detail below but in general contains a repetition of the eight bit transaction number (N), eight bits representing the revolving cash count for denomination two (CNTR2), eight bits indicating the number of status bytes (CB) and eight bits representing the revolving cash count for denomination one (CNTR1). The byte CB is a one byte field containing a binary count of a number of status and inquiry data bytes which follow the encrypted portion (bytes 5-8) of the message for a normal status message. For a "request recovery message" the CB field contains the "action field" from the transaction reply for the last transaction request message. The "action" field is an eight bit field transmitted as part of the 32 bit encrypted field of a transaction reply message. The eight bit counter portion (CNTR) of the 32 bit encrypted field indicates binary count of bills issued by the second and first cash issue mechanism. These numbers are taken from counters which are incremented for each issued bill and roll over from hex FF to hex 00. The counts are stored in the auxiliary memory of the operator function subsystem 76 so that the count is preserved during a short term power outage. Following the 32 bit encrypted field at bytes 5 to 8 is a data field. The data field includes a four byte status field in byte positions 9-12. These four bytes define the current status of a terminal 14 as discussed below. Most status messages terminate with an FS byte at byte position 13. However, a status message which is sent in response to an inquiry command message contains 112 of the 128 bytes stored in the auxiliary memory of the operator function subsystem 76 which are transmitted behind the four status bytes. For this message the field CB would contain the number 116. The 16 bytes of the non-volatile memory which are not sent in response to an inquiry message contain the two eight byte encryption keys. If the status message is being resent in response to a request recovery message, the four status bytes contain the four bytes of the last transaction status message and are followed by the complete original transaction request message. This information then would allow the host to re-construct the conditions which existed prior to the event which caused the host to request recovery. The 32 bit positions of the four status bytes at byte positions 9-12 of a status message each have a predetermined meaning. These meanings are assigned to define the physical and operating status of a terminal 14 with sufficient particularity that a host data processing system can assess and control the general operation of each terminal 14. These meanings are described in tabular form below with the number to the left indicating the status byte number ranging from 0 to 3 with status byte 0 in status message byte position 9 and status byte 3 in status message byte position 12. For each status byte there are eight bits designated bit 0-bit 7 with a bit 0 being in the most significant bit position and bit 7 in the least significant bit position.
Byte
Bit
Description
__________________________________________________________________________
0 0 Transaction completion status bit. This bit position
is set to logic 1 at the beginning of each transaction
to indicate that the transaction has not been com-
pleted because a transaction reply message is required.
The bit position is reset to logic 0 when a trans-
action has been executed as specified in a transaction
reply message.
0 1 Invalid transaction sequence number in transaction
reply bit. This bit position is reset to logic 0
each time a new transaction is started. The bit
position is set to logic 1 any time the transaction
number (N) within the common header field of a
message received from the host data processing system
is inaccurate. An exception is made for an echo
message which does not convey meaningful information
in the transaction number position of the header
field.
0 2 Invalid transaction subclass in reply message bit.
This bit position is reset to logic 0 at the
beginning of each new user transaction and set to
logic 1 any time the subclass byte in the fourth byte
of the common header field of a transaction
reply message does not match the subclass byte of
the corresponding transaction request message. Byte
0 bit 0 must be set each time this bit position is
set.
0 3 Invalid class bit. This bit position is reset to
0 after an exception status message has been sent and
is set to logic 1 any time a message is received from
the host data processing system containing an invalid
class designation in byte 3 of the common header
field. As an example, a terminal 14 might receive
a nonrequested initialization (IPL) message or a
nonrequested transaction reply message.
0 4 Amount error in transaction reply message bit. This - bit position
is reset to logic 0 at the beginning
of each new transaction and set to logic 1 any time
a transaction reply message is received with the
dollar amount byte within the encrypted field thereof
indicating an improper dollar amount. (AMT) Bit 0
of byte 0 must be set to logic 1 any time this bit
position is set to logic 1.
0 5 Unassigned.
0 6 Customer cancelled transaction bit. This bit
position is reset to logic 0 at the beginning of
each new transaction and set to logic 1 in the event
that a customer activates a cancelled key on the
user keyboard subsequent to the transmission
of a transaction request messgage.
0 7 User timeout bit. This bit position is reset to
logic 0 at the beginning of each new user trans-
action and set to logic 1 any time a user consumes
more than an allotted predetermined length of time
in entering a number through the user keyboard or in
depositing materials through the deposit flap. Bit
0 of byte 0 must be set any time this position or
position 0 6 is set to logic 1.
1 0 Command reject bit. This bit position is reset to
logic 0 after a command status message is sent.
The bit position is set to logic 1 upon receipt of
a command message which cannot be executed because
the terminal 14 is busy at the time a command is
received.
1 1 Invalid command bit. This bit position is reset
to logic 1 upon sending a command status message.
The bit position is set to logic 1 any time a
command message is received with missing fields
therein. For instance, a key change command which
does not include the new key or a change display
command without a new display field. This bit posi-
tion is also set to logic 1 in response to a command
message containing an invalid subclass designation
in byte 4 of the common header field.
1 2 IPL request. This bit position is reset to
logic 0 upon the proper receipt of a load initiali-
zation message from the host data processing system
and set to logic 1 each time a terminal 14 goes from
a closed to an open condition, for example, upon
closure of the operator/customer engineer access
panel, or upon command from the host data processing
system. This bit is also set to logic 1 each time
a terminal 14 receives a command message commanding
the terminal to request an IPL.
1 3 IPL and process bit. This bit position serves as
a modifier bit for bit position 2 of byte 1. A
combination of bit 2, bit 3 equal 00 indicates that
the terminal is initialized. This condition can
occur only when the terminal is in an open state.
The combination of bit 2, 3 equal 10 indicates that
initialization has been requested but the load
initialization message hs not been received. A
combination of bit 2, 3 equal 11 indicates that a
load initialization is in process.
1 4 Cash counter error bit. This bit position is reset
to logic 0 at the beginning of each new user
transaction. The bit position is set to logic 1
any time a transaction reply message is received
containing a cash counter byte (CNTR) within the
encrypted field thereof which does not match the
status of the cash counter within the terminal. The
cash counter is a rollover counter which is incre-
mented each time a new bill is issued. Byte 0,
bit 0 must be set to logic 1 each time this bit
position is set to logic 1.
1 5 C and CS field error bit. This bit position is reset
to logic 0 upon sending an exception status message.
It is set to logic 1 upon receipt of a command
message from the host data processing system con-
taining a class and subclass (C&SC) byte within
the encrypted data field that does not match the
class and subclass byte of the common header field.
This failure to match indicates a possible encryption
key synchronization error or host error. In a
normal command message, the two class (C) and
subclass (SC) bytes of the common header field are
combined into a single class and subclass (C&SC)
byte (packed by sensoring the four leading 0 bits
of each byte).
1 6 Communications timeout on transaction, reply sequence
bit. This bit position is reset to logic 0 at the
beginning of each new user transaction. The bit
position is set to logic 1 any time a predetermined
period of time expires following the transmisson
of a user transaction request message without the
receipt of a corresponding transaction reply message.
Byte 0, bit 0 must be set to logic 1 any time this
bit position is set to logic 1.
1 7 Unintelligible message bit. This bit position is
reset to logic 0 after sending an exception status
message. It is set to logic 1 to indicate an
unintelligible message any time a message is received
which does not correspond to the required predeter-
mined message format. For example, the number of
bytes may not agree with the message length (L)
designation in the common header or a parity error
may occur upon reading a data byte or a byte position
may contain invalid data.
2 0 Card retained bit. This bit is reset to logic 0
at the beginning of each new user transaction and
is set to logic 1 any time a user requested trans-
acton is terminated with the terminal 14 retaining
the credit card which was inserted therein by the
user. This bit position indicates that the card
was retained as a result of a hardware error at the
terminal 14 rather than in response to a command
from the host data processing system.
2 1 Dispense error bit. This bit position is reset to
logic 0 at the beginning of each new user trans-
action. The bit position is set to logic 1 any time
an error occurs during the dispensing of a document
such as a bil or a Unassigned. statement. This
bit position is set ay time a document is dumped
from an escrow area into a retention bin. Since the
transaction may be completed upon retry, this bit
positon does not necessarily indicate an incomplete
user transaction.
2 2 Unrecoverable depository error bit. This bit position
is reset to logic 0 at the beginning of each new
user transaction. This bit position is set to logic
1 ay time an error condition such as a jam occurs
in the terminal depository and the terminal is
unable to recover from the error condition.
2 3 Display table overflow bit. This bit position is
reset to logic 0 upon sending a status message.
The bit position is set to logic 1 upon receipt of
a change display command message from the host
data processing system containing more display data
than the terminal display system can handle. An
improper display message is not accepted by a
terminal 14.
2 4 Unassigned.
2 5 Unassigned.
2 6 Unassigned. Intervention requred bit. This bit
is set when an intervention requied condition
occurs. It is reset when the intervention requied
indicator is turned off.
2 7 Card removal timeout bit. This bit position is
reset to logic 0 at the beginning of each new user
transaction. The bit position is set to logic 1
whenever a predetermined period of time expires
following the availability of a credit card to a
user without the card being removed from a terminal
14. This bit position indicates that some kind
of intervention is required. Normally, the host
data processing system would respond by commanding
the terminal to retain the credit card.
3 0 Open/close bit. This bit position is rest to logic
0 any time the terminal opens and is ready to
receive a user transaction request. This bit position
is set to logic 1 each time the terminal closes.
3 1 Cash out condition bit. This bit position is reset
at the beginning of each new user transaction. This
bit position is responsive to a hardware switch
which indicates whether or not there is enough cash
stored in the terminal to execute a maximum cash
issue transaction.
A transaction reply message from a host data processing system 12 to a user terminal 14 is generated in response to a user transaction request message. The transaction reply message begins with the standard four byte common header field specifying total message length (L), transaction number (N), message class (C), and message subclass (SC). Following the four bytes of the common header field are four bytes or 32 bits of encrypted information, a variable length optional display data field, a field separater character (FS) and a variable length optional transaction statement print field, and a final field separation character (FS). The four byte encrypted field includes a one byte cash counter 2 number (CNTR 2), a single a Other info: Inventors: Anderson, Thomas G. (Los Altos, CA, US) Boothroyd, William A. (San Jose, CA, US) Frey, Richard C. (San Jose, CA, US) Application Number: 483084 Filing Date: 1974-06-25 Publication_date: 1976-05-11 Assignee: IBM Corporation (Armonk, NY) Primary Class(es): 705/72 235/379, 235/381, 340/5.74, 713/185, 713/194, 902/2, 902/39, 902/40 Other Classes: US Patent Ref:
Other Refs: Primary Examiner: Canney, Vincent P. Assistant Examiner: Attorney: Fraser and Bogucki |
|