Method and apparatus for controlling communications6934945Abstract The present invention relates to preparing and processing information to be communicated via a network or to or from other data carriers. For implementation of a novel "virtual machine" of the present invention, a minimal amount of hardware is required. Prior art virtual machines tend to slow down operation of the device as they interface between an application program and device drivers. The novel virtual machine incorporates a virtual message processing means that is arranged to construct, deconstruct and compare messages and applied in the native code of the processor. The message instruction means directs and controls the message processor. Similarly, a protocol processor means governs and organs communications, under the direction of a protocol instruction means in the application. These elements of the novel virtual machine increase the speed and efficiency and allow implementation of a practical device for use in communications, able to be implemented on different hardware having different BIOS/OS. Claims 1. A communication device which is arranged to process messages for communications, comprising a virtual machine means which includes Description From a first, general aspect, the present invention relates to a method and apparatus for preparing and processing information to be sent or received via a network. A network in this instance may be implemented as data carried either over communications lines and/or stored on smart cards (or other data carriers) and physically transported.
2. Data Representation (i.e. Ascci, Binary, etc.). This indicates what representation form the data is in and/or what it is to be converted to. 3. Format. This provides a description of the format that the data is in and/or is to be placed in. 4. Test Function. The index of a function processor set of instructions to determine if the current field is to be included or excluded at this time 5. Line & Column. Relative position for use in constructing messages for display or printing. These values are used to determine the quantity of space characters, and or new line characters that are required in the buffer. 6. Substitution list. A list of text representations to substitute for numeric values e.g., display the value "1" as "Monday" and "2" as "Wednesday". 7. Additional description options as required by the application or prove useful in future embodiments. Each message instruction will therefore include a description of a field of message data, providing instruction for the virtual message processor means which enable it to carry out a number of tasks: 1. To compare a message with a message description to see if it is the correct required message. 2. To take a message of the correct description from a location and place it in an-other location. 3. To take a message and deconstruct it into various components and place the various components into other locations. 4. To take data and build a message in accordance with the message description and place the built message in a location. 5. Compare one message with another message. Other functions may also be carried out by the message processor as required by the application. The message processor can manipulate data in any desired way in accordance with descriptions provided by the message instructions. Messages comprising data can therefore be billed, placed in locations, taken from locations, deconstructed with elements being placed in locations, etc. for subsequent operation on the data by the application. Any device which deals with significant amounts of messages in such form can therefore benefit from this arrangement. Each message description is labelled so that it can be identified by the application, e.g. each message description may be numerically labelled. A development tool for developing the application 104, in particular the message and protocol instructions 108, 109 comprises a graphical user interface based program which may be run on a PC or other general purpose computer. The program provides a graphical user interface based framework which enables message instructions to be built from data input by a programmer. Message instructions can subsequently be translated into code readable by the virtual machine 102, 101, 103 and downloaded into the application device. FIGS. 5, 6, and 7 are "screen dumps" which illustrate displays generated by the development tool for an example message instruction. In this case the message relates to data from a magnetic stripe of a customers card. The message instructions direct the message processor 105 to take the fields of the message and place them in known locations in accordance with the instructions. Such a message instruction may be called up in response to the SAVE primitive, in the event of a card read. Data from the magnetic stripe of the card would be stored away in the appropriate locations in accordance with the instructions, for subsequent processing. Each message is provided with a message name 30, in this case "TrackData". This message name identifier can be used to call up this particular set of message instructions in the development tool. An alternative numeric identifier is generated for use by the virtual processor. This numeric identifier may also be displayed by the development tool. Each message is made up of a number of message "fields" 120. In this particular example, there are seven fields, being "Track1", "Track2", "Track3", "CustName", "PAN", "ExpD" and "End-Of-Form". Each of the seven field is converted to a message instruction for use by the virtual message processor. This is the information which is typically found on any magnetic stripe card. The message instructions in accordance with this embodiment direct the message processor to process these elements. Each field is associated with descriptors which provide further instructions for the handling of that element. FIG. 6 illustrates a display 33 which enables a programmer to provide message descriptors to CustName element. Each field 120 has a "format" descriptor 34. There is an instruction as to the Data Representation ("Type") reference numeral 35. In the illustrated embodiment there are four types, Ascll, Hex, Binary and BCD. There is also a logical operation instruction (option test), reference numeral 36. This logic instruction can be used to determine whether or not the message processor will process this element at all, for example, i.e., it will only include the CustName element in the message when the logic function equals "True". Other instructions designate the data source, reference numeral 37, in this case a field, and the field label, reference numeral 39. The format 34 is labelled with a name, in this case, "Tracks". There are further instructions which dictate the format Tracks to be applied to CustName. FIG. 7 shows a display which illustrates the instructions for the format "Tracks". The message processor is responsive to all the message instructions to load the data from the magnetic stripe card into the appropriate fields with the appropriate formats in accordance with all the rules designated in the instructions. This embodiment of the present invention includes another class of message instruction means, known as a "Form". Instead of a Data Representation as a message descriptor, a Form includes description of a Location of the data field in the Form. FIG. 8 is a display provided by a development tool enabling the programmer to prepare message instructions for a Form message. On the left hand side of the display a panel 70 illustrates Form layout. The fields in the Form include MerName, Address Line 1, etc. The location of these fields can be moved within the panel 70. The location in the panel is provided as a descriptor and for the message instruction. The Form type of message instruction controls displays, reports, print-outs, and the like. The type of Form is given by the instruction designated by reference numeral 71, in the example illustrated in FIG. 8 being a print-out. The message processor takes the fields from known memory locations or other locations and enters them in the locations enabling the Form described by the Form instruction to be produced. As discussed previously, another major function of a SNAC device is communications. For example, it is necessary for the majority of remote payment transactions for communications to be able to occur between an account acquirer location, in order to enable access to an account, and the remote payment device. Communication with a data carrier, such as a smart card device may also be required. The protocol processor 106 is arranged to organise communications, in accordance with directions from the protocol processor instructions 108. Referring to FIG. 4, in a typical remote payment transaction, after a card has been swiped, a PIN number has been input and a charge amount has been input, information then needs to be communicated to an external computer, at the account acquirers, in order to enable further processing of the transaction. After an event such as a communications message arriving, therefore, HAL 102 detects the event (step 1) and activates the protocol processor (step 2), FIG. 4. The protocol instruction 108 for the event is rolled up (step 3). The protocol processor 108 implements the protocol instructions for that event, (step (4)). The protocol instructions are divided into "sections" 130, "lines" 131 and "protocol commands" 132, as illustrated in FIG. 12A. FIG. 12B illustrates how an instruction is displayed on a development tool for protocol instructions. Protocol instructions describe message flow both from and to the device. The top line specifies outgoing messages and the other lines display possible incoming results. A protocol consists of lines and sections. At the start of each section is a line 1 (optional for the first section) which describes the outgoing message. There are a number of protocol commands, and these include: 1. Protocol-Run a sub protocol 2. Message-Send a message or handle an incoming message using the virtual message processor means 3. Retry-re execute the steps of protocol from and indicated point 4. End-End of the protocol 5. Exit-Stop the protocol from an intermediate point 6. Timeout( )-Specify the a delay after which the protocol should automatically jump to the point at which the timeout instruction is placed. 7. Control-Specifies a control character to be send or received. 8. Function-Execute a virtual function processor function Protocol instructions are organised in lines and sections. In each section Line 1 indicates the information to be send by the SNAC device and subsequent lines indicate actions to be taken in response to the alternate possible events which may occur in reply. The first instruction on each of these subsequent lines is used to identify the response. Control( ), Message( ), Function and timeout( ) may all be used to identify responses as follows. 1) When the time specified by a timeout instruction elapses then the line commencing with the timeout will be selected. 2) When data is received it will be sequentially compared to a lines commencing with Control( ) Message( ) or Function to see if the data matches the control character, matches the message of causes the test contained in the function to evaluate to true. FIGS. 9 and 10 illustrate displays of a development tool for protocol instructions for the protocol "General" which is the Protocol Name (reference numeral 42). Instructions are presented as a screen dump in the form of a table 43, which can be accessed by a programmer if he wishes to alter the protocol. Protocols are arranged to control message flow both from and to the target device (e.g., account acquirer computer). The top line of the display panel 44 specifies outgoing messages and the other lines display possible incoming results. A particular protocol is able to call up other protocols "nested" within it and is also able to call up the message engine to deal with messages. Referring to FIG. 10, the top line of panel 44 specifies the outgoing message. The first operation of protocol "General" is to call up and carry out a further protocol, "Reversal". FIG. 11 illustrates instructions for the protocol Reversal, reference numeral 45. Reversal operates to call up the message engine to construct message number 0400 and this message is then sent to the target device. The either 1) Message number 0410 should then be received back from the target device and the message processor will be called up to deal with that data, which involves the message processor comparing the incoming message against the description specified by the message instruction means and storing the data if a match occurs. Or 2) A timeout of 100 tenths of a second elapses. Then the protocol is ended and re-turned to the protocol General, which causes a further message, 0100 to be formulated and sent out. Then either 1) A message matching 0110 will be received or 2) A message matching 820 will be received or 3) neither 1 or 2 will occur for the timeout( ) period, in this case specified as 000 tenths of a second. If the message 0110 should then be received from the target device and compared by the message engine, then another protocol "adjustments" will then be carried out. The protocol would then end. If the message 820 should be received from the target device, which can be dealt with by the message engine and compared with the instructions from the message instruction means. The "Retry" instruction will then be executed causing the virtual protocol processor to move execution back to the sending of the (0100) message. The retry count of zero indicates this loop would continue whilst 820 messages are received. If the Timeout occurs, then the retry(5) would be applied causing the protocol processor to move execution back to the Send 0100 message. This loop would occur up to five times as indicated by the retry(5). After the fifth time execution would move to the next section causing the protocol to End. More details of operation and build up of messages and protocols are given in the appendix A. The device in accordance with the present invention, for example a payment terminal, may be implemented in GAVA by defining a class library payment terminals. This class library would contain calls to all the functions of how HAL and preferably the message and protocol engines. Similarly, a specialised network access computer or card computer could be implemented in GAVA. Please note that the arrangement of the present invention can be used to deal with any payment transaction device, including one which deals with smart cards. The present invention can also be used to implement a specialised network access device, which may use similar hardware to that provided for a payment terminal. In the attached Appendix A, the term "CardScript" is the name the applicants have given to programming required to implement this embodiment of the invention. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. APPENDIX A Contents. Introduction Introduction Help for CardScript Scribe The Scribe program assist in the design of stored information & programs for EFTPOS terminals, PINpads, Electronic Cash Reqisters and other small computer systems. Writing A Program For help on writing a CardScript, program, rather than operation of the Scribe tool, see Writing A CardScript Program A CardScript program is more similar to a Windows RAD tool program than a conventional C Language or Assember program. The "target" device has several keys, one or more card readers, and usually one or more communications ports. Defining a program consists of attaching actions to these events, or the special events of terminal power on and terminal idle. CardScript programs-as all other program-manipulate data. Data is defined in a Data Dictionary. Unlike normal programs, it is normal to write many CardScript programs using the same Data Dictionary. Standard Data Dictionaries are available from CardSoft for EFTPOS and several other application types. It is recommended to write initial applications based on one of these standard dictionaries. Once the program is experienced, the Data Dictionary for an Application may be modified. see Configure Data Dictionary Data Dictionary Usage The Data Dictionary represents the list of all "variables" or information values used in the target device. These "variables" are in formation which may change over time, or be different from device to device. Information which is fixed for all devices usually is defined by strings. All information to be included in displays, receipts, messages etc, comes from either the Data Dictionary or from STRINGS. Data Dictionary fields may have an initial value set from the Initial Data Tables Structure Tables The Data Dictionary is divided into tables. Each record displayed in Configure Data Dictionary describes one table. Fields are placed by selecting add and clicking on the Panel. Field Attributes Double Clicking on any field reveals and allows viewing and/or editing of Data Dictionary Field Attributes. Field Order Layouts are stored indexing fields by table#1field#. This means existing scripts will behave strangely if the Data Dictionary is changes the number Of referenced fields. For example if "Merchant Name" is table 3/field 2 and "Address" is table 31field 3. Then deleting field table3/field1 will make any prior references "Merchant Name" now reference "Address". This can be remedied by inserting a dummy table3/field 1 as a placeholder. Generally this problem does not arise since new dictionaries are not to be used for old applications, and existing dictionaries are usually only extend. In the rare event that a dictionary used by existing applications is to have fields deleted, it recommended to rename them to "dummy" or "unused". Be careful since any existing data in the files will be rearranged when retrieved, it will simply be move from the record into the fields in the order listed at the time. New fields added in graphic display mode are always added at the end Reserved Settings see Reserved Data Dictionary Settings see also Data Dictionary Field Attributes The field attributes which may be set are as follows Type Type refers to the format in which data is held. "X-Ref' is a special value used to indicate that another table will be referenced at run time and thus must be included in the build. Binary Data Fields Binary. either 1 or 2 bytes in length for Integer values in calculations, longer fields hold bit fields or keys. 250 bytes is the maximum permissible number of bytes Maximum Integer values Depending on the number of bytes used to represent the Binary number, the following values are possible
Text-up to 250 bytes BCD up to 250 bytes Date/Time (2 Bytes for Dates, 2 or 3 bytes for Time) see Date & Time Fields Amount-10 bytes, internal format is target device dependent Packed Amount-not currently used X-Ref-Advanced use only Flags 0=Field is fixed and never reset 1=Reserved for future use 2=Reserved-used with deleted fields 3=Field is reset when terminal is loaded 4=Field is reset at power on 5=Field is reset by idle function Bytes The leright of stored data in bytes Length Caution: When you create new data dictionary fields, make sure their leright is not zero if you want to use them, or they will be invisible. The number of characters allocated to display the field as text Name The name of the field for display on receipts etc. Table The "refer" Initial Data File from which the field initial value is extracted. Blank if the field is extracted from the default file. Table ldx When "Table" is non-blank, "Table ldx"specifies the "refer" of the Initial Data Field in the default file used to indicate the record number in "Table" from which data is to be extracted. In other words the join field between the default table and the joined table. Field The "refer" of the Initial Data Field from which the initial value of the field is to be obtained. Creating a New Application As suggested above to create any application, it is recommended to copy a "template" application. Simply copy the entire template directory. To then work with the new directory, select File/Installation and edit the data directory. (Don't forget the trailing I) Is the recommended to exit Scribe and restart. Scribe and restart. Console/Display The display console used with CardScript is quite sophisticated. see The Console CardScript can be used in a variety of devices, some of which may not support all the features described here. Features The CardScript Console has a number of sophisticated features Hot Keys Keys used to launch only one action, where the action is part of the application, are known as hot keys. Typically the action may be activated only when the terminal is idle. For further information see the "KeyBd" primitive. In an EFTPOS application, on a terminal with Keyboard Buttons available for allocation, Hot Keys will normally be allocated to such functions as "Sale", "Adjustment", "End of Day" etc. Hot keys normally would have their label printed on the keyboard, or on the physical button. Multiple Field Input On any Layout displayed on the console, several field may be selected for input. The OK key steps from one input to the next. Any soft key terminates all input. Scrolling The display may be scrolled, permitting a larger virtual display than the physical display. Scrolling is performed automatically by the driver in the target device. All that is needed to enable scrolling is to tell the scrolling driver what keys on the keyboard perform scrolling. The keys used to scroll are set by the Console Primitive Console(Command,Parameter) The command determines which of the following console options is set. Command I-Set Scroll Keys The Parameter is a string of four hex values, in order-key-left,key-right,key-up,key-down The keyvalues specified are assigned to the scrolling engine within the target device. Note scrolling my not function on all CardScript "targets" and the size of the scrollable area may vary. Command 2-Set Keymap The parameter is a Key board map. This command is now the preferred method for setting the keyboard map. The old Keymap primitive will be obsolete in a future version. See KeyMap Structure of Keymaps The"field" or String used as a keymap must be a list of 4digit-hex blocks, the first two digits of each block representing the hex code of the key to be mapped and the next two digits representing the hex value to map be returned. Usually used from the startup function, using a field from the terminal groups record. Note that the following key codes have special meaning. 08 Represents a backspace or 'CLR' code. OA Represents an 'OK or 'Enter 1B Represents a cancel. 30 through 39 Represent the digits "0123456789" Command 3-Keybd The parameter is evaluated to zero, or non zero. Upon entering idle state, the action of the keyboard is determined by the last KeyBd command. The keyboard (except cancel) will be ignored if off was specified. This command replaces the old keybd primitive, which will be obsolete in a future version. Command 4-Invalid Entry The parameter is the text message to be displayed. This command is designed to be called from an input validation function. Calling this command indicates the input is invalid, the text specialised in the parameter should be display to indicate the error. Soft Keys Some keyboard buttons on a target device may be used as soft keys. As opposed to Hot Keys these are buttons which may be used to initiate different actions, depending on the display present when they are pressed. Since the principle of Soft Keys is to use the same buttons for different actions, displays must in some way indicate to the user the operation of each currently active soft key. Soft Key Button Sets Target devices may allocate certain buttons on the keyboard for use as soft keys. Button sets are numbered from zero. If a specified set is not available, then set zero is used. By convention:- Set 0=keys 'O' thru '9' (the numeric keys) Set 1 are dedicated soft keys, usually positioned directly adjacent to the display, in order that the display may be easily used to indicate their function. Set 3 is the new standard for dedicated soft keys-hex values 81,82 . . . AO. Set 3 will normally be requested on forms where numeric/text input is also required. Set 4 is the same as set 3, but allowing use of the numeric keys if no dedicated soft keys are available. Set 4 should not be specified on screens where numeric input is also available, since this may cause a conflict. Soft Key Action Groups These are the groups of actions that may be offered at any given time. In Layouts/Forms, a soft key action set may be selected for any display. Individual functions may be assigned to an action group from the Function/General Purpose Functions, in the Function activation section. Note Action group 0 is used to indicate a function is NOT part of any group Correlation of Actions to Buttons If a display allows soft key Button Set 0, (Keys '0', '1', '2', '3' etc ) and action set "I" then when the '2' key is pressed, then soft key group '1', An Group '2' (Key '2' minus the first key in the action set equals 2), if it exists, will be activated. The Keyboard To control the features available, and make best use of your terminal,you can recode the keys on your keyboard using the keymap primitive. This allows you to customise the target device to allow portable and easy to operate applications. See Keyboard Codes The Keyboard codes are designed to accommodate a wide variety of keyboard configurations. At any given time each key (or button) will act as one of the following key types 1 Control/Data Entry Control 2Data Entry 3Soft/Hot key function activation Control/Data Entry Control Some keys are required for control. Control keys should not be used for any other purpose than control, otherwise the user interface will incredibly confusing. Minimum Requirements All CardScript drivers should provide these key codes without any mapping required. 08 Backspace or Cir 1B Cancel OA OK or Enter 1A Fn-For general Function selection, and for double (or triple) zero. Additional Options OD or complete form (combined with tab as an alternative to OA) 09 Tab (move to next field-does not complete form) OB Vertical Tab-Used as back tab or move to prior field. 1 1 (XON)DCI-Used as cursor left 12 DC2-Used as cursor right 13 DC3-Dedicated double zero 14 DC4-Dedicated Function Key (combined with DC3 as an alternative to 1 A). Data Entry Three levels of data entry may be available at any one time. Text, Hex,Alpha. The bios can automatically determine the available level and act accordingly. Minimum Requirements 30.39 (Numerics) Additional Options A B C D E F (allowing Hex data entry) Full 'querty' keyboard Soft & Hot keys Soft keys previously were recommended to be 'a''b-c' etc Now the are recommended to be hex 818283 etc up to a maximum of AO allowing up to 32 dedicated Soft keys. The change in recommended values is to allow for terminals with full alphabetic keyboards. Hot Keys (When/Additional to soft keys) should be allocated from Al . . . DO Program Portability Portable Programs CardScript allows the writing of totally portable programs, it is also possible to write programs that are not very portable. Any CardScript program will "execute" on any CardScript enabled target, however the result could be of no use on the target if special hardware characteristics are required for practical operation of the program. CardScript provides a mechanism for avoiding the traps and keeping programs portable whilst still taking advantage of special hardware when available. Keyboard Traps The key map primitive represents a trap in that this function should never be used with a literal string, or your program won't be portable. Processing Cards Magnetic Cards Automatic Processing Automatic Magnetic Card Processing, from Upon Card read, data from the card is placed in the Receive buffer. The format in the buffer is Track 1 (I terminated) Track 2 (I terminated) Track 3 (I terminated) Customer Name (I terminated) PAN (I terminated) Expiry Date (6 bytes ASCII) If the read occurred at terminal idle, the Calculation Result is set to zero and the system event Magnetic Card Read is generated. After executing any function for the Magnetic Card Read Event, if the Calculation Result is non zero this value is used to select a function for further processing of the specific card type. Automatic Magnetic Card Processing Upon card swipe, the data dictionary fields Transaction/Track2 tru Transaction/Customer Name are filled with the card details. These are data dictionary fields Tablel/Field2 thru Tablel/Field7. see Reserved Data Dictionary Settings for details. Table 5 is then scanned to find a column matching the PAN of the swiped card. If a column in table 5 is found then the tables 3 & 4 have their columns set according to the entries for Issuer & Acquirer in Table 5. Table 5 is set during the build to indicate the appropriate action should a card be swiped at idle. If the terminal was idle at the card swipe this function is now executed. Typical Processing. For standard processing, create a function as follows store (O,CardMsg) if ColFind(Pan,PanLow,PanHigh)
Smart Cards Two primitives are available for controlling Smart Cards. Card(Command,Field/Value) 1A command of 1 is used to read the smart card status into the field "FieldNalue". Using a value for "FieldNalue" does achieves nothing. 2A command of 2 is used to control the power to the card. If "FieldNalue" is 1, the card is powered on, if "FieldNalue" is 0 the card is powered off. 3Select. A command of 3 is used to select which smart card reader(or plug in is currently selected. By convention, 1 is the user card(or if only one reader is present, this reader), 2 is the separate merchant card slot or the plug in, where present. "FieldNalue" contains the card number to be selected. 4A command of 4 is used to read the Smart Card Type Code 5A code of 5 performs a logical test on smart card type. If the field/value supplied matches the Smart Card Type Code of the current code, the logical true flag is set. This command is designed to be used in an "if" test 6Code 6 reads the CardEntryMode into the specified FieldNalue. See CardEntryMode 7Set Card entry mode to the value specified in FieldNalue see Also TPDU(Command, SendMsg,RxMsg,Status) The TPDU primitive is used to send a command to the card. If the TxMsg is present this data is also sent to the card. If the RxMsg is present then a response is expected from the card and is stored in the RxMsg buffer. Command This if the actual 5 bytes TPDU to be send to the card SendMsg This optional parameter specifies the message used to build the data send to the card. RxMsg This optional parameter specifies message used to store any data returned by the card in response to the TPDU. Status This mandatory message specifies the location of status variables to record the status of the TPDU operation. The TPDU primitive with Synchronous (Memory Cards) 416 Cards Drivers for 416 Cards support the following TPDU Commands ReadBytes WriteBytes EraseBytes Present Key see Commands for Memory Cards The present Key uses the length indicator to select either the CardSecret Code (2 bytes) or the application erase secret code (4 bytes) Answer to Reset, & Card Type The 416 has a card type code of 4 and an answer to reset of 3Bh 00 00 00 00 00 Commands For Memory Cards ReadBytes CL (any) INS BO ADDR XXXX (Byte Address an Card) LN LL Number of bytes to read. WfiteBytes CL (any) INS DO ADDR XXXX (Byte Address an Card) LN LL Number of bytes to write. EraseBytes CL (any) INS DE ADDR XXXX (Byte Address on Card) LN LL Number of bytes to erase. PresentKey CL (any) INS 20 ADDR XXXX (Byte Address on Card) LN LL Lenght of Key. Other Smart Card Commands For selecting the smart card reader, and control of the reader. For sending information to the card, and receiving information from the card. Smart Card Type Codes 1 Async ISO type Card 2416 Running A CardScript Program To run the program on the PC simulator, see PC Simulator There is a implementation of the CardScript Virtual machine available on the PC that not only runs your program, it also emulates the keyboard layout and other controls of any target machine. To run the simulator-select "Build/Run Simulation of Build" Stored Information-Data Tables For Information on setting & changing values in the Data Tables See- Tables Menu CardScript includes all tools for maintaining data tables to control the set up and distribution of Data Tables required for any application. The System Data Table The system data table has a fixed format identical in all systems. This table contains general information and current setting for use within the scribe program. See- System Table Settings Settings in the system table are used to both miscellaneous settings in the script, and options for viewing the script. Loader Settings Terminal For Mask Load Not used by scribe Default Prompt (or String) Table The string table displayed within Scribe. Multiple string tables may be used to support multi language applications. Peripherals Description the peripherals of a the target system here and displays and receipts will in scribe will show guides to assist in design. These setting have no affect on program execution in target devices and may be changed at any time. Reserved Functions Idle State Set this pointer to indicate a function to be executed each time the "target" becomes idle. Abort Normally left at Initial This function is executed at "target" power on. Processor Previously used to indicate the byte order used in the "target". It is now recommended to use "Low-High (INTEL)" for all systems. Configurable Data Tables The data tables used by CardScript can have their names, field names, layout and even the number of tables used altered according to the current system set up. Configure Initial Data Initial Data Usage The purpose of initial data tables is to provide a database of information for initial values for the data dictionary loaded into the target device. Configuration Structure Each record in the configuration describes one table. Fields are placed on the Panel and dragged to the appropriate position. Field Attributes Double Clicking on any field reveals and allows viewing and/or editing of Initial Data Field Attributes. Field Order Clicking on "Graphic Display" toggles between the standard graphic view of the fields and a simple ordered list of the fields. In the ordered list mode fields may be dragged to rearrange the field order. Be careful since any existing data in the files will be rearranged when retrieved, it will simply be move from the record into the fields in the order listed at the time. New fields added in graphic display mode are always added at the end. Reserved Initial Datal3ase Settings Certain fields must be present in the for the build process. File Usage File 1-"Terminals". The name may be changed however this file is used to initialise individual target devices with the optional "NetMgr" module. No other special usage at present File 2 "Groups" -no special considerations File 3 "Issuers" no special considerations File 4 "Aquirers" no special considerations File 5 "Card Ranges"-must be used as card ranges, and must have fields "lo" "hi" and "Ien" File 6 "Products" no special considerations File 7 "Region Settings" no special considerations File 8 "Issuer Sets" no special considerations File 9 "Card Sets" must contain the fields "cards" as an index into card ranges see also Initial Data Field Attributes Type Flags Current usage 0=Place label to Left I=Place lable above Repeat The number of times the field is to appear on the form X-Pos The current value of X-position of the field on the form. Usually modified by dragging the field. Y-pos The current value of Y-position of the field on the form. Usually modified by dragging the field. Label The label to appear for the field on screen. Refer The "refer' label used to access the field when building the initial data dictionary Display (Type=Text only) The number of characters to be displayed on screen. 0 (zero) for default. Size Functions For information on defining functions in your application see- Functions Menu see also Function Primitives For Describing any function within the "target" to the system, or in program terms for writing scripts see General Purpose Functions Use this selection for describing functions Label The function name Description A brief description of the function. The function can be located by description Action A window to the function actions. Double click on this window to see or edit the full Function Action. see also Function Primitives & Function Primitive Categories. see Function Action Double clicking on a function action block brings a panel into view for editing the function actions. Adding Actions Select the appropriate action from the alphabetical list beside the add option, select add and then click on the panel at the appropriate position. Clicking over an existing action will insert the new action before the existing action Deleting, Actions Select delete and click on the action. Take care to deselect delete before clicking on other actions. Editing Actions Double Click on any action to activate the edit dialog box. Function Index Shown for reference purposes. Cannot be changed. Strings See your driver information. Currently this information is not used by most drivers. Function Activation Specifies when this function will be executed. see Starting A Function Function Number Each function may be assigned a number. The operator may then enter the number and the program easily select from the list using the Function# primitive. Hot Key Code Each function may be assigned a hot key code. Enter a non-zero code in HEX and if a key with this code is pressed at idle, or any other time hot keys are activated, the function will be activated. Note that the Cancel Key is regarded as system event. System Events System Events are similar to hot keys, only instead of keys being pressed (Note that the Cancel key, IS a system event), other actions on the target device are involved. For each target machine a list of System events is maintained, but these should always include the standard events. Only one function may be assigned to any System Event. See Standard Event Codes Keyboard. Keys on the keyboard with a value less than 128 (Ox8O hexadecimal) generate an event code with the value of the key. Other event Codes 0=Reserved 1 System becomes Idle 2Cancel Key Pressed 3System Power On 4Numberic Entry 5Smart Card Insertion 6Smart Card Extraction 7Magnetic Card Swiped 8Checksum Error Detected on Batch 9Checksum Error Detected on Data Card Set Select a card set. When any card belonging to this set is swiped at idle, the function will be activated. Usage Flags Operator Function-The operator of the target device selects the function Library Function-The function is an internal "subroutine" Not Used- The function is not used For adding actions to functions which may be varied by issuer or by acquirer see Transaction Function Input Transaction Function Approval Function Primitive Categories. Function script is a sequence of calls to system and user primitives. For information ol primitives available see Function Primitives Assignment Primitive Field1:=String/FfeW Set field1 to the string/field2. => (goes to) primitive => field The value of the last logical or other operation using the "calculation result" is stored in field specified eg Account==000 => zAccount Would set the field zAccount to 1 if Account was zero, other size zAccount would be zero. => result (goes to) primitive => field The value of the last logical or other operation using the "calculation result" is stored in field specified Account==000 => zAccount Would set the field zAccount to 1 if Account was zero, other size zAccount would be zero. see also Calculation Result. Calculations generate a "Calculation Result". Think of this value as the value you would see on the display of a calculator if the calculation was performed on a calculator. Math Primitives Field1+=Number/Field2 Field1-;=Number/Field2 Field1*=Number/Field2 Field1/=Number/Field2 Field1 is modified by thefield2/number. Relational Primitives Fieldl1value1 Fieldlvalue1>Field/value2 Fieldlvalue1==Field/value2 The two fields or values are compared. If one field is text and the other numeric then the return value will always be false. < > != >= <= For not equals (whether thought of as < > or !=), greater than or equals (>=) and less than or equals (<=) use the opposite case. With the WHILE PRIMITIVE and REPEAT UNTIL primitive then use the NOT option. With the IF PRIMITIVE use the ELSE clause. Abort Primitive abort This primitive causes the target device to stop all functions and become idle Alarm Primitive Alarm (noise type) Makes the sound specified 1 error alarm 2bip type noise 3most severe alarm Bit Manipulation Bit Numbering All binary fields can be accessed as a number of bits where the number of bits no.of.bytes*8 The MSB of each byte has the highest bit number and the LSB the lowest bit number. Note ISO bitmaps do NOT follow this rule, but these do not need bit manipulation by the application. This result in the LSB of the last byte being bit 0 (zero) and the MSB of the first byte being no.of.bytes*8 -;1. Eg for two bytes 15. Bitcount Primitive bitcount(field,start,end,bitvalue) start & end These are both bit numbers. see bitnumbering. Direction of counting is from start to end, either may be the larger number. bitvalue Notes The number of sequential bits of the value "bitvalue" starting from bit "start" and working towards "end" is counted. If the result is non-zero the logical true status is set, otherwise the logical false value is set, allowing "if' type tests of the result The count is stored as the "working value" allowing storage via the "-;>" (goes to) primitive. see -;> (goes to) primitive Setbits Primitive Setbits(field,startbit,endbit,value) Bits number "start bit" thru "endbit" are set to the value "value". No all values are extracted from the least significant bits of value. e.g. For a 1 bit field, all values are considered either 1 or 0. (Odd numbers are 1) Batch Primitive Batch (Operation) CardRead Primitive Card (string, field form, default) This primitive is identical in operation to the show primitive, with three extra facilities 1Input is terminated by either the introduction of a smart card, or the swiping of a magnetic card. 2Data from a magnetic card read is stored in the reserved fields 31f the (card entry mode) is non zero, this primitive does nothing. This allows logic to read a card only if the card is not already read. See also Example A function requiring input of both "Tip Amount" and "Cash Out Amount" can -input both using the same field. Create a form as follows. Edit the PFIELD to indicate an input field.
Where "Tip" and "Cash" are strings. On the first call to show the display will prompt "Tip" and accept input into the TipAmt field. On the second call to Show the display will prompt "Cash" and accept input into the CashAmt field. Show (string, field jorm, default) Action This primitive is specialised for displaying input forms. Two parameters (string and field) substitute with PSTRING and PFIELD in forms, allowing the same form to be used for multiple inputs. String String to replace the PSTRING field on the form. Field Field to replace the PFIELD field on the form. Form The Form may be selected from the list box-or alternatively by selecting Field-;> Value[X] taken from a field in the data base. Default A value of one (1) if the existing value of the field is to be displayed as a default, otherwise 0. Reserved Data Dictionary Settings The driver in the "target" makes direct use of some fields in the data dictionary. Using these table#/field# settings for other use will have strange results and is not recommended. Table 1 (Transaction Table) Fields in this table may be initialised to default values only. The first fields in the transaction table are reserved for (in order) 1ROCNUM 2Track 2 3Track 1 4Track 3 5PAN 6Expiry Date 7Customer Name 8Protocol Status 9Card Entry Mode Table 2 (Totals Table) No reserved settings, however a fixed ten copies are available. Initialisation of fields to default values only. Table 3 (Terminal Table) This table is the basis of the build of terminal groups, and may be initialised from the Initial Data Table. There is always only one record in the table. Table 4 (Issuer Table) One record per issuer, with the current record selected automatically when a card is swiped. Table 5 (Acquirer Table) One record per acquirer, with the current record selected automatically when a card is swiped. Table 6 (Card Table) Fixed layout, Dictionary specification currently ignored. Coffind Primitive ColFind(value,LowField,HighField) Both LowField and HighField must be in the same table. This table is scanned for a column with the value 'value' between the two fields. The primitive is normally used to locate the CardTable Column for a card. The result variable is set to 0 if no match is found, or 1 if a match is found. ColSelect Primitive ColSelect(Column, Table, Reset) Selects the relevant column of the table indicated. Column The column to use. The transaction table has only one column, the totals table has ten. The other tables (issuers, acquirers etc have one column for each record in the corresponding initialisation data base Table For comparability, 0 (zero) selects the totals table. The tables are as follows 1 Transaction 2Totals 31ssuers 4Acquirers 5Card Ranges Reset If reset is 1 then all fields in the column are reset. CommStat Primitive CommState(port, value, field) port indicates the port to be. tested value indicates a value to compare and set the status accordingly. field (optional) indicates a field to store ComsState Value. This function reads the state of the port store the value in field (if specified) and sets the current function result status to true if the value matches "value". Date Primitive Date(commdnd , date-field , time-field) 1Read system date into date field and time field 2Set system date from date field and time field see also Dates and Times Dates & Times are special data types both are stored as special numbers. Date Fields A Date field is a two byte number, representing a date since 1Jan1940 to 1Jan2110. Subtracting two dates reveals the number of days between the dates, dividing by 7 reveals the day of the week (Monday=0, Tuesday=1 etc). When moving to or from a text field a date is converted to a text format of DDMMYY. If a format is used this may be converted to DD/MM/YY by using a currency symbol of / in the format. The text format of a date may be either 6 or B bytes long-showing the year as 2 or 4 digits. Date Fields only contain valid dates. Since every date is stored as a day number, the storing the string 32/01/1980 will give is the actual date 01/01/1980. If data is entered directly into date fields, then dates are corrected in this manner automatically. If you wish to check the was entered correctly, then enter the data to a text field, then move the value to the date and check it is equal to the string. e.g Repeat
The above example will continue to ask for a date until a valid date is entered. Time Fields Time fields may be either two or three bytes representing either the time of day to 2 seconds (two bytes) or 1/100 of a second (three bytes) accuracy. Moving a time to a 2 byte integer gives the number of two second periods elapsed this day. Moving to a 1 byte integer extracts the 1/100s second fraction (up to 199) Moving to a value or larger integer extracts the total number of tics (1/100s sec) which have occurred prior to the time. Moving a time to of from a text field results in either HHMIVISSFF when moving to a 8 or more byte field and HHMMSS when moving to/from a six byte field. This text value may be formatted with a format to give HH:MM:SS.FF Moving values between data and time fields and other numeric types results occurs without conversion. Moving to and from text values results in conversion. See specific entries for conversion details Dial Primitive Dial(phone numberphone number) The numbers specified must be fields. Immediately following each number field in the data dictionary must be a timeout field then a retry field and then a mode field. The upstream prot is implied. Do Primitive Do (Function) also known as DoFunc(Function) This primitive is used to activate another script function as a subroutine call Event Primitive Event(Function,system event) Sets the specified function to be activated whenever the event occurs Exit Primitive Exit(Now?, Value) This primitive is used to set the return value of the current function, and optionally, exit immediately. The 'Value' is stored in the Calculation Result, which will be regarded by any calling function as a result. If 'Now" is true (is 1) exit will be immediate, otherwise the exit value will be established. Func Number Primitive Function#ffieldlnumber. bad number function) Execute the function with the assigned function#. Typically this primitive will be used by a user function set to be activated by a Hot Key on the target device labelled "Fn" or "Function" or similar. Such a user function would prompt for a number and then call this primitive (Function#) with that number as a parameter. See Function Activation. The "Bad-Number-Function" is a function in the script to be executed if the no function matching the first parameter exists. This is used to implement number functions-for example clearing memory might be function 1055. The user presses the "Function" hot key, then enters 1055 to execute the function. To achieve this 1a function containing this primitive should created and set up under function activation to have the appropriate key code. 2A function containing the appropriate action for the numbered function should be created and set up under function activation to have the appropriate function number The function number also returns the logical result of the request to call the numbered function. i.e false if no function exists, otherwise true. If Else End Primatives The next primitive is executed. If true then all primitives between the if and the else are executed. If false all primitives between the Else and End are executed. If nothing is required between for false then Else may be omitted. If ! (if with Else Optional in an If see above. End Marks the end of an If or While. See While End KeyBd Primitive KeyBd(mode)-(O=off/I=on) Upon entering idle state, the action of the keyboard is determined by the last KeyBd command. The keyboard (except cancel) will be ignored if off was specified. MAC Primitive mac(key,mode,message,field) All targets must support the storing and use of 4 64 bit keys. mode I Calculates a mac of the 'message' and stores the value in the 'field' specified. Uses the 'key' specified. If the 'message' is 8 bytes in length only (or less) then a single DES encryption only results. mode 2 Stores the specified key into secure memory from 'field' Mod Mod (Value,Divisor) The value "value" id divided by the divisor, and the remainder is the result. e.g.-the following example would set the Data Field "Remainder" to 4. (25 divided by 7 has a remainder of 4. Mod(25,7)
Pin Primitive pin (field) Retrieves pin block from pinpad. Not supported on all CardScript devices Print(Display/Report, Part) Form The Display/Report may be selected from the list box-or alternatively by selecting Field-;>Value[X] taken from a field in the data base. Part Values-0=all, 1 pre print/header, 2=body, 3=post print/footer see Forms-end of Header/PrePrintt & Start of Footer/Post Print Action The selected section (or all) of the display is displayed or, in the case of a report, printed. With displays, any input fields will be accepted, however the Show Primitive is recommended for input operations ProcDown Primitive Procdown(protocol, port) The specified protocol is started on the port specified. This function is normally used for downstream protocols such as an ECR. This function is intended for more advanced users and the protocol must specify its own success and fail functions. Protocol Primitive Prot (protocol, Function 1, Function 2) The specified protocol is started on the bank coms (upstream) port. The current function execution continues. KeyBd(Off) is set (it may be overridden). If the protocol returns a value of zero, Function 1 will execute, if any other value is return Function 2 will execute. (A KeyBd(On) will automatically happen before either function. Range Primitive Range(field,Min,Max) Returns true if the value specified is >=min and <=max value Repeat/Until Primitives Repeat Repeat sets the execution point for a following until Until(Case) Cases are 0=False, 1=True Executes the next primitive and if the result agrees with Case then the Repeats everything after the repeat primitive. Report (Form, Function) Action First prints any pre print or header from "Form". Then for each transaction in the batch calls "Function" and prints the details section of "Form". After cycling throughout the batch, then prints any post print data from "Form". Form The Display/Report may be selected from the list box-or alternatively by selecting Field-;>Value[X] taken from a field in the data base. Function A function to be executed before each detail section is printed. For any transaction in the batch for which the function returns FALSE will be skipped. Restore Primitive Restore(layout,field,secondary field) This primitive is used to retrieve information from the Batch Area. Layout This optional ("none" is permitted) parameter specifies which transaction layouts are considered for retrieval. WARNING! All records searched using a field other than RECNUM are actually retrieved, changing the contents of the data fields in their layout. Using a value of "none" may have side effects! Field The primary search field. Searching will advance through the Batch Area until a match is found. Secondary Field an optional (Use RECNUM for "none") secondary search field. Rom Function Primitive Rom(valuelfield, Message) Generally the parameter passed is passed directly though to the bios. The following values are assigned for portability. The message parameter is ignored unless otherwise stated. 1Go to ROM mode. 2Erase memory and return to Rom 3Start TIVIS download (from ROM mode). 4Store Rom Params. Uses Message and returns Success status. See ROM SETTINGS. 51-oad Rom Params. Uses Message and returns Success status. See ROM SETTINGS. 6Activate Rom Edit. Returns Success status. See ROM SETTINGS see Also ROM SETTINGS What are ROM SETTINGS Sub Heading Normally target devices store programs in RAM memory, and are capable of loading these programs over the telephone Network. In order to achieve remote loading the device must store telephone number and other details required. The device must have a method of loading and/or editing these details. Methods vary from device to device with information normally being obtained from the keyboard, a smart or magnetic card or some combination. Obviously the information must be able to be set prior to the application loading. Communication Between Rom & CardScript Two possible reasons for CardScript to interact with the ROM Settings arise. 1 The parameters may need to changed in a device already loaded with the CardScript application. 2A CardScript application may need access to the ROM Setting values. Edit Rom Settings-Rom Function 6. The desired method of allowing change to the settings is to use this function primitive call. (see Rom Function Primitive.) This primitive may not be supported by all Drivers and (check with the driver provider) but provides the only device independent method of implementing the function. An advantage of this function is the operator sees the same interface as when configuring the terminal prior to loading CardScript. Load Rom Settings-Rom Function 4. This function is used to obtain the ROM settings in a Script. Store Rom Settings-Rom Function 5. A Script Program may load the Rom Settings with Function 4, allow editing of values and use this function to store the settings. It is recommended to use function 6 (edit) in place of this prAc6edure where available as this mechanism allow changing of device specific settings. The Rom Communications Buffer. To provide a much device independence as possible using functions 4 and 5 CardScript defines a standard Communications Buffer Layout with a private area at the end. All Fields are ASCII. The first three fields are assumed to be used for all communications. 2 bytes connection mode. Lan Leased Line etc 4 bytes station/Lan Address 8 bytes telephone prefix-eg "9," Field 1 16 Bytes Terminal ID. The ID as seen by the software management system and not necessarily other systems. 8 bytes terminal type 24 bytes phone number 24 bytes connection string Save Primitve Save(transaction layout) Saves the current transaction to the batch using the layout specified. A new Transaction Index is generated according to the method specified by the last TxnIdx: Primitive, with the new index stored in field(0,0) RECNUM. For details on RECNUM see Reserved Data Dictionary Settings. The number of transactions (of the selected layout) which can be stored is returned. If zero is returned, then the save could not work! If 1 (one) is returned then no more may be saved. If two is returned then only one more may be saved, etc. Store Primitive Store(offset,messageLayout) The store Primitve stores the last received message, starting at byte Tots Primitive Tots(valuer Field) Selects the relevant totals column. This primitive has been replaced by the ColSelect primitive. Old programs are automatically upgraded, since parameter 2 or LineTble, when zero, will select the totals table Txnldx Primitive. Set Transaction Index. Txnldx(Field1,Field2,mode) Field1 is optional. If include the first two digits of the Index are set from this field. Field2 specifies the main field on which the Index is based. By default this is the ROC field. the mode specifies how CardScript increments the Txn Idx. 0=add 1 1=Amex Style 2=None. Incremented by script. This function would normally only ever be used in a start up function. The calculated value is always stored in the ROC field. User Function Primitive The user function primitive is used to call any of a range of functions. The functions call by user function are NOT standard. Primitive-Extensions It is possible to extend the primitives available to CardScript. The extensions take to form of a block of 'C' code loaded with the Script. 'C' code, of course, has the restriction of being non portable. The existence of these extensions is to allow extensions to a set of primitives to be tested without changing the core driver. Any extensions initially tested by this means must be added to the set of primitives in a new release, otherwise the code calling them will never be portable. Wait Primitive wait(minutes, 100 msecs) The current function pauses for then number of minutes+10ths of seconds specified. A delay of up to 1000 minutes (over sixteen hours is possible) and as small as 1/10 of a second. While/End Primitives While(Case) Cases are 0=False, 1=True The next primitive is executed. If the result matches Case then all primitives between the While and the End are executed, then we come back again to the While. If the result does not match Case then execution continues with the primitive following the End. End Marks the end of an If or While. See also-.-If End For specific categories of primitives see Communications Primitives Data Entry Primitives Displaying and Printing For information on configuring CardScript for target device function primitives (advanced users only) see Configure Function Primitives For advanced users only!! Usage-Name Changes Changing the name of a primitive or a primitive parameter will cause all scripts using the name change to be automatically updated. Both this type of change and any changes to the "infix" status of a function will have no affect on the driver and scripts will function without further change. Usage-Adding, Deleting, Changing Parameter Types Parameter Settings Each function parameter has the following possible categories 1A Field from the data Dictionary 2Numeric Value-Which may be displayed as an index to a file 3A String Any parameter may legally accept any combination of categories Layouts CardScript allows you to graphically enter your layout specifications. For details on Receipts, 'Reports, Displays, Messages, Protocols, and Transactions see Layouts Menu Layouts are the main engine of any application. Although all layouts must bee brought into operation by functions, layouts also in turn launch functions and other layouts. Form layouts, message layouts, and transaction layouts are similar in operation. All three are an arrangement of fields and strings called a field panel. For details see Field Panels All field Panels (Displays/receipts, messages and transactions) have a Panel Control box in common. The selection in the Panel Control box selects the action to take place when the left mouse button is clicked over the panel. Additional controls are present of some panels, however, this box always contains An add field-control with field edit box and palette selector Clicking on the p'a'nel when [add] is selected adds a new field as displayed in the edit box Before-clicking on the edit box to set the field to be added, select the appropriate type of item in the "from palette" drop down list box Clicking on the edit box brings up either the Select Field Dialog or the Enter String Dialog, in accordance with the palette selector A dealt field control Select [delete] and then click on the appropriate field A select field Control Select [delete] and then click on the appropriate field Field Editing To edit any field, double click on the field Forms (Displays and Reports) see also Field Panel, Print Primitive, Show Primitive and Report Primitive The Screen is Divided into four sections The Form (Display/Report) Panel The panel is a Field Panel where the location of the of each field corresponds to the place actual data will appear on the display/printer The Dashed Boundary Depending on the Display/Report type, a dashed line will appear showing the limits of the display or printer. This boundary is drawn in accordance with the settings in the Tables/System menu and can be changed at any time. Form Name The display report name is used for reference to this screen and should contain a meaningful name. Panel Control In addition to the panel controls discussed in Field Panel, two additional controls are present. < Pre-Print fields appear with a grey background Select this item and click on the field after the end of the header section of the report. Used in reports, the header section is printed once at the beginning of the report. The sections following the header will be printed once for each transaction in the batch. see Report Function for further details Used in receipts (see Print Function for further details) used to divide the receipt not sections Start of post print Post-Print fields appear with a grey background, and can only be distinguished from Pre-Print fields if there are fields in between. (As would normally be the case.) Select this item and click on the first field of the post print section of the report. Used in reports, the Post-Print section is printed once at the end of the report. see Report Function for further details Display/Report Type The types are Display-layout will always appear on the display, and in scribe will have a border reflecting display width and number of lines Secure Display-reserved for future use Printout-layout will always appear on the printer, and in scribe will have a border reflecting printer width Soft Keys The Soft Keys Button allows selection of a soft key set. see Messages Output messages A messages buffer is built from fields in the data dictionary, and from strings in much the same way a printout is build. However, in messages, all data may be represented in forms other than ASCII. (see "the message engine". Formats may be used to specify data within the selected representation. Input Messages Messages are also used to specify how data is transferred from a received buffer and stored in data fields. see also The Message Engine (Processor) The message engine is used both to transfer information both from data fields not a message buffer, and from a message buffer to data fields see also Message Data Mapping Every field in a message buffer is converted from the type in the data field, to the representation of in the message buffer. For "Forms" all data in the buffer is Ascii, but in other messages the Oata may be any of the following Ascii Ascii Representation Strings and Text Fields Strings & text fields are simply copied. If the source is shorter then the destination, spaces are used for padding Integer Integer to Asch For one & two byte integers, the binary value is converted to its string equivalent and then formatted according to any format specified. Larger integer conversion may appear in a later | ||||||||||||||||||||||||||