Note: Descriptions are shown in the official language in which they were submitted.
~.~8(~5~
SMART CARD APPARATUS AND
METHOD OF PROGRAMMING SAME
~ackground of the Invention
The present invention relates to a smart card
apparatus and a method for programming the same. More par-
ticularly, the present invention relates to a smart card
apparatus and method for programming same with an open archi-
tecture approach.
Substantially flat, thin plastic articles such as
credit cards, bank cards, driver licenses, membership cards,
etc., are currently in widespread use. Recently, manufac-
turers of these cards have provided such cards with their own
microcomputer. Such cards are commonly being referred to as
smart cards. The potential uses for such smart cards are
tremendous. For example, a smart card might contain a per-
son's entire medical history, financial information, etc. In
addition, such cards might be used to automatically debit
one's bank account when purchasing items such as groceries,
clothes, etc. In view of the large potential use of the
smart card, a smart card and method for programming the same
is required which will allow rapid mass production and per-
sonalization of such smart cards. Moreover, there is a need
for a smart card wherein the data may be readily stored,
altered, retrieved, and protected. In addition, there is a
need for a smart card which can be readily adapted to dif-
ferent applications as they arise. Also, there is a need for
a smart card which is very secure and resistant to tampering.
The present invention solves this problem and many other
problems associated with smart cards.
Summary of the Invention
The present invention relates to a smart card
apparatus including a microcomputer. The microcomputer is
programmed to include a smart card control program. In addi-
tion, the microcomputer is programmed to include a data dic-
tionary and personalized, user data.
, ~
1 ~80~
--2--
The present invention also relates to a method of
making a smart card as described above. The method includes
the steps of programming the microcomputer with the smart
car~ control pro~ram. Programming a data dictionary for
definin~ the data, security and feature reguirements of the
smart card control program. Programming the microcomputer
with application specific data and personalized user data.
The present inven~ion provides a smart card that
can be treated similar to a disk device wherein data may be
stored, altered, retrieved and protected. The application
developer (card issuer) defines the data environment as part
of the application development and this definition resides in
the smart card as a data dictionary along with the associated
data elements. The present invention provides a smart card
whose data can be accessed and used much in the same way that
a disk based filing system is used.
Additionally, the present invention provides a
~eneric smart card and associated utilities and development
tools to the application community to assist in development
of smart card application. The tools will be in the form of
standard message -formats and protocols to address the smart
card. The message formats and protocols will preferably be
ISO compatib]e.
The present invention provides a generic smart card
apparatus which will be cheaper overall since there is one
standard product_-
Additionally, the present invention avoids the needfor special masks which will result in better response time
from su~pliers of the microcomputer.
Yet another advantage of the present invention is
that the time and cost of programming an application is
reduced and therefore will facilitate use of smart card
apParatus .
In a preferred embodiment of the present invention,
.
80~
the use of electrically erasable programmable read only
memory (EEPROM) wil] enhance the logical lifespan of smart
card apparatus by reusing memory resources.
Yet another advantage of the EEPROM embodiment of
the present invention is that the EEPROM will allow modifica-
tion of smart card apparatus in a much cheaper and faster
manner than with ~PROM based products, although EPROM might
be used in certain applications.
Yet another advantage is that there is less risk in
application development by the card issuer because the tech-
nical functions are already included. Moreover, this
trans]ates into reduced development time and cost.
Still another advantage of the present invention is
its transparency to the actual microcomputer features. The
microcomputer can be changed and such change will be
transparent to the user. As prices and features change this
is important since microcomputer products are quickly out-
dated.
A particularly advantageous feature of the present
invention is that it enables the rapid, mass production of
smart card apparatus. The microcomputers can be programmed
with the smart card program prior to being associated with the
smart card apparatus. Subsequently, the smart card apparatus
can then be programmed for the particular application and
programmed with personalized user data.
Another particular advantage of the present inven-
tion is the open ended architecture approach of the present
invention which makes the smart card apparatus of-the present
invention very flexible and adaptable to different applica-
tions. The present invention utilizes predefined interfacing
nlles and a data dictionary which facilitates the open ended
nature of the present invention.
Additionally, the present invention provides a
smart card with increased security. Varying levels of
805~
--4--
security can be readily built into the smart card; for
example, certain fields of data might be required to match;
i.e., PIN number, or the smart card will be deactivated.
These and various other advantages and features of
novelty which characterize the invention are pointed out with
particularity in the claims annexed hereto and forming a part
hereof. ~owever, or a better understanding of the inven-
tion, its advantages, and objects obtained by its use,
reference should be made to the drawings which form a further
part hereof and to the accompanying descriptive matter, in
which there is illustrated and described a preferred embodi-
ment of the invention.
Brief Description of the Drawings
In the drawings, in which like reference numerals
and letters indicate corresponding parts throughout the
several views,
FIGURE 1 is a diagrammatic top plan view of a smart
card apparatus in accordance with the principles of the pre-
sent invention;
FIGURE 2 is a view similar to that of FIGURE 1 with
a portion of the smart card apparatus broken away so as to
disclose the microcomputer and its interconnection to exposed
contacts;
FIGURE 3 is a diagrammatic view illustrating the
general arrangement of microprocessor memory in accordance
with the principles of the present invention; and
FIGURE 4 diagrammatically illustrates an arrange-
ment for programming of the microprocessor and memory in
accordance with the principles of the present invention.
Detailed Description of the
Preferred Embodiment
Diagrammatically illustrated in FIGURE 1 is an
embodiment of a smart card apparatus in accordance with the
principles of the present invention, the smart card being
~80~
aenerally referred to ~y the reference numeral 20. In the
embodiment illustrated, the smart card includes an encoded
magnetic strip 22. Exposed are eight contacts 31-38 which
enable access to a microcomputer 40 embedded in the smart
card 20 on a support media 42. This is more clearly
illustrated in FIGURE 2 wherein a portion of the smart card
has ~een broken away so as to illustrate the interconnections
between the contacts 31-38 and the microcomputer 40. In the
embodiment shown, the microcomputer is enclosed by a layer 44
so as to provide protection therefore. As illustrated, the
smart card 20 might have written indicia 46 on the surface
thereof; for example, the user's name and address.
An examPle of a microcomputer which might be uti-
]ized is the Motorola MC68HC805C4, a C~OS chip with approxi-
mately 4K EEPROM memory, 172 bytes of RAM, a timer, and a
serial port (UART) through which all communication with the
smart card reader will take place. CMOS and EEPROM are cho-
sen for the preferred embodiment for a variety of reasons,
most primarily are their adaptability to the concepts of the
present invention and the extended life of the smart card.
The microcomputer 40 is programmed with a smart
card control proaram 5n, a data dictionary 52 which defines
the data, security and feature requirements of the smart card
program S0 and the particular application and personalized
data.
The smart card program 50 and the microprocessor 40
follow the International Standard Organization (ISO stan-
dards; i.e. (ISO/TC 97/SC 17/WG 4N97 electronic signals and
exchanqe protocalls, ISO/TC 97/SC 17/WG N166 dimension and
location of contacts, and ISO/TC 97/SC 17/WG N105 physical
characteristics).
The external card contacts 31-38 follow the ISO
standards. The contexts are defined as follows: 31 = VCC
circuit supply voltage. 32 = RST reset signal. 33 = CLK
* trade mark
, .. ..
'Al '
0~11
--6--
clock signa~. 34 = RFU reserved. 35 = GND ground. 36 = VPP
programming voltaqe. 37 = I/O data I/O. 38 = RFU reserved.
The EEP~OM memory is divided into two zones
referred to as Zone A and zone B. Zone A will be used for
volatile data storage such as transaction data 56 and Zone B
will be used for code, data dictionary and storage of non-
volatile data. Data fields in Zone A of the preferred embo-
diment are stored in memory, from the low address to the high
address and are formatted as data, field ID and length. (In
this applicationr volatile data includes data subject to
change when the smart card is in use.)
Data = Data value of field, trailing spaces truncated.
Field = The field identifiers defined in the data dic-
tionary.Length = The length of the field.
A data dictionary 52 is used to define the data
stored in the smart card memory to the smart card program.
The data dictionary defines for each data element how the
data element is structured and if it is volatile or non-
vo]atile. This data will include both system data relating
to manufacture of the card, application data relating to the
specific smart card application; and personalized data
relating to the end user of the smart card. The data dic-
tionary 52 thus serves a template for the data stored in each
smart card. This information is then included in each smart
card that is created. The data dictionary will include a
fixed portion 52a defined at the time the smart card control
program 5~ is programmed and a variable portion 52b con-
taining definations of personalized data used in each appli-
cation which will be defined when the smart card is
personalized. The fixed portion, including both system and
application data definitions, of the data dictionary might be
defined as follows:
~80~
--7--
U5AGE SOURCE
Total size of dictionary/
data System
Card Provider Code Application
Application Code (internal) Application
Application Code (ISO message) Application
Internal Security Code System
Manufacturing Batch Application
Card Manufacture Date System
Extended Commands (Y or N) Application
Watchdoa for dictionary System
DCC application verification Application
Unused
Threshold of consecutive bad Application
commands or field identifiers
Action taken on threshold Application
(I=Ignore, S=Sleep, K-Erase card)
~lumber of variable fields in System
dictionary
Watchdog for personalization System
The application specific portion of the data dictionary will
include definition of personalized data fields such as user
data 54 and will be defined as follows:
USAGE
Data Pield ID (x'OO'-x'FE')
Length of Field
Data Attribute (Volatile/non-volatile/match)
Reader Permissions (2 types)
~: Writer Permissions ~2 types, ignored if
non-volatile)
~ It will be appreciated that the data dictionary
may taken on varYing contents and structure and still be in
keeping with the principles of the present invention.)
Memory is reserved for the data defined by data
.~
, :
' ~
~.~805~'~
dictionary when the microcomputer is programmed with the
smart card control program 50. Moreover, the structure of
the data dictionary will be predefined and the smart card
pro~ram 50 will know the ~ocation of each of the elements of
the data dictionary. A utility program, which might be used
in a personal computer or othel terminal, is used by the
application user to interface with the smart card control
program and define the data dictionar~ for personalized and
application specific data and write the system data, applica-
tion data, and personalized user data into the microcomputer
memory. The utility program will include the data dictionary
template and will query the user to define the application
data of the fixed portion and the personalized data of the
variable portion. Once the user has accomplished this at a
personal computer terminal, the smart card can be per-
sonalized by writing the user data 54 to the smart card.
It will be appreciated that the above description
is of a preferred embodiment and that alternate embodiments
may take on different configurations in keeping with the
principles of the present invention.
The smart card control program 50 performs command
processing, service routines such as memory management, I/O
driver, and specialized code for handling miscellaneous com-
mands from the programming equipment of the application user.
The smart card control program will contain logic to
load/reload cards so as to allow refreshing or updating of a
smart card. This will enable new code, and new data to be
introduced to a previously used smart card as a command,
rather than through various boot strap procedures as is done
at initial load time. Communication with the smart card
program will be accomplished by predefined interfacing rules.
Service functions are those routines which address
diagnostic and technical issues rather than the execution of
specific commands, for example,
--
g~f~80~
g
1. INITIALI ZATION
The initialization process is invoked at power up
or ollowing a Reset. The functions performed are:
- initialize hardware states
- check if "BOOT2" present (live vs personalized)
- if "BOOT2" present do card personalization
- check watchdogs for card validity
- find the next volatile write location in Zone A.
- find the end of the non-volatile data in Zone B.
2. SECURITY VALIDATION
If application security verification has been activated
for this application it is done immediately after the
initialization. This involves putting the I/o into read
status, accepting the verification message and vali-
dating against the values in the Data Dictionary. The
values are returned as in the data portion of the "V"
recorded. If successful the terminal type is saved for
field verification. Also a message is returned to the
application as a positive response to the security vali-
dation. If there is a 'Match' field defined in the dic-
tionary this fields data must be included as additional
information is the verification record and is compared
with the data in the card. If there is no match a bad
status is returned to the application.
3. DICTIONARY SEARCH
From the field identifier in the message locate the
field in the dictionary and stash the address for
further usage (save the index value).
4. MEMORY SEARCH
The memory search will be supplied with a field ID and a
command ~next, most recent etc.). If application valid-
fation is active the field security is checked to deter-
mine if the user may access the field. With the
supplied arguments memory will be searched for the data
field and the data placed into the RAM buffer in the data
portion of the huffer area. If data is not found a sta-
tus message is stored in buffer area.
On the first request of a field the dictionary is
inspected to determine whether the field is volatile or
non-volatile and the address generated will be either
the address of the next available byte minus one in Zone
A, or the end of the Zone B personalized data.
~L~ ~3Qri~
--10--
On mu]tiple requests of a field the address will be that
of the last occurrence accessed minus one.
A block move routine is used to move the data to the
buffer from the add~ess of the located data field.
When the last field of the supplied ID has been found,
and a next read co~mand is issued, the status message is
stored in the buffer area.
S. WRIT~ TO MEMORY
The Data Dictionary attributes are checked to ascertain
that the field is not a non-volatile field, and if the
application v21idation is specified that the user may
write this data. Having done the validations the
routine will w~ite the data portion of the RAM buffer
into the EEPP~M volatile memory ard up~ate address poin-
ters to the next available area ~o write. Appended to
the data will be -he field identifier and length.
7. MEMORY REFRESH
Memory Refresh is part of the 'reorg' of the card at the
time the card is approaching full. A 'reorg' command
from the appropriate terminal will cause the data Zone A
to be erased.
The actual erase is a routine which is furnished zone
id and may also be used ~o intentior.ally destroy the
card on reauest.
In use, predefined comrands are passed from the application
terminal such as an automatic teller terminal (ATM) and are
recJests for some form of ac~io-. The commands fall into
several major categories:
Applicatior: Those which are issued by the application
for a file request. Normally an ASCII alphabetic value.
Svstem: Proprietary commands used to perform diagnostic
functions.
Respons~: A card res~onse back to the application con-
veying a status or acknowledgment. Normally ASCII
numeric.
R~ader: These commands instruct the device
.-eading~writing to the smart card. These co~ands are
ignored by the smart card.
Sample commands are:
R Read applic. Reads the most recent field
value from the card to the
application.
W ~rite applic. Writes the data for the spe-
cified into memory from the
application.
M Memory applic. a request for a~ount of
remaining memory in zone A.
This is returned as a two byte
data value in the data portion
of the record in hex format.
N read Next applic. reads the next oldest
occurrence of a field from the
card to the application (First
command gets the most recent,
subsequent commands get next
oldest, etc. The requests must
be contiguous on a request for
another field terminates the
sequence).
V validate applic. This command request contains
the necessary security data to
identify the reader and appli-
cation to the card (required if
apolication verification is
set).
D destroy applic. The application requests the
total destruction of the card.
The data portion contains the
application and the Card
Provider code. These must
match the data dictionary
values before this is allowed
to happen.
C clear applic. arbitrarily clear Zone A.
Follows same rules as 'D', used
as step in reorganizing a full
card.
S stop applic. orderly stcp, required for bat-
tery powered products.
1 status applic. a response to the application
from the card on an exception.
~8()~
-12-
The data portion of the message
will have the status returned.
Examples are card full, field
not found, I/o error, or an
'OK' acknowledgment.
P proqram reader turns on programming voltage if
applicable.
L lock door reader locks door on reader to keep
card.
U unlock reader unlocks the door.
Z reset reader issue a hardware reset.
x'EO' set mode system a preliminary command required
to set system mode. No other
system commands can be
recognized unless sytem mode
has been set.
x'EA' erase/reload system Loads bootstrap to RAM, erases
both zones of EEPROM and then
reloads memory from serial port
x'EB' dump dict. system dump the entire dictionary out
serial port.
x'ED' dump all
card system pass entire card as data por-
tions of multiple records.
It will be appreciated that the smart card control
program (50) might take on any number of different
embodiments. A program structure for one such embodiment is
illustrated below:
A. SMART CARD tEntry Point)
A.l INITIALIZATION
A.l.l. SET ~ARDWARE STATES
A.1.2 DETERMINE MODE
A.1.2.1 Check if live or personalization (Boot2)
A.1.2.2. If personalization
A.1.2.2.1 Invoke Boot2 to load data
A.1.2.2.2 Clear Zone A
A.1.2.2.3 reset RAM pointers
o~
A.1.2.2.4 Check errors (checksum, I/O)
A.1.2.2.5 Pass completion [ACK/NAK1/NAK2 (pick one
depending on result)]
A.1.3 CHECK WATCH DOGS
A.1.3.1 Check System Watch Dogs
A.1.3.2 Check Application W~tch Dogs
A.1.4 INITILIZE RAM
A.1.4.1 Determine next write address
A.1.4.2 Set variables to initial va]u~s
A.1.5 RESPONSE TO RESET
(per ISO spec)
A.1.6 APPLICATION VALIDATION
A.1.6.1 Determine if required
A.1.6.2 Read validation message from terminal
A.1.6.2.1 Serial I/O Driv~r in read mode
A.1.6.3 Validate application ID
A.1.6.4 Save Terminal Type
A.l 6.5 Ca~culate remaining memory in card
A.1 6.6. Return status message to application
A.2 COMMAND PROCESSOR
A.2.1 READ REQUEST
A.2.1.1 Serial I/O Driver in read mode
A.2.1.2 Verify message
A.2 2 VERIFY COMMAND
A.2 2.1 check command list
A.2.3 CHECK ABEND STATUS
A.2.3.1 Do if over defined error threshold
A.2.3.1.1 if "ignore" continue
A.2 3.1.1 if "deaf & dumb" STOP processor
A.2 3.1.2 if "kill" do DESTROY command
A.2.4 PROCESS THE COMMAND
A.2.4.1 SYSTEM COMMAND
A.2.4.1.1 ~ALIDATE AUTHORITY
A.2.4.1.1.1 Chec~ data portion of record for DCC
special sequence
A.2.4.1.1.2 If not present bump error count,
A.2.4.].1.3 If not a Set Mode and not in system
mode bump error count and exit
A.%.4.1.2 SET MODE
A.2.4.1.2.2 set system into the "system mode"
A.2.4.1.3 ERASE/RELOAD CARD
A.2.4.1.3.1 Clear Zone A
A.2.4.1.3.2 Set up RAM instruction sequence
A.2.4.1.3.3 Clear Zone B from RAM
A 2.4.1.3.4 branch to ROM Boot to begin reload
A 2.4.1.4 DUMP DICTIONARY
A.2.4.1.4.1 Set dump range as dictionary
through personalized data DUMP
command.
A.2.4.1.5 DUMP CARD
~305~
-14-
A.2.4.1.5.1 Set dump Range = $00 - End of
personalized Data DUMP command
A.2.4.1.6 DUMP
A.2.4.1.6.1 Set ranges to dump
A.2.4.1.6.2 Set record preamble
A.2.4.1.6.3 Dump entire range as standard
formatted records
A 2 4 2 APPLICATION COMMAND
A 2 4 2.1 Set mode as "application Mode"
A.2.4.2.2 Find field in Data Dictionary
A.2.4.2.3 Verify Permissions
A.2.4.2.4 Route to Command
A.2.4.2.5 READ COMMAND
A.2.4.2.5.1 Get Address of Card Data
A.? 4 2 S 1.2 Read most recent
A.2 4 2 5 1.2 Read Next NOTE: Read next will
always bet "only" non-volatile field
each time
A.2.4.2.5.2 Block move EEPROM to RAM data portion
of buffer
A 2 4 2 5 3 ~uild rest of message (ISO format)
A 2 4 2 5 4 Write message back to terminal
A.2.4.2.6.4.1 Serial I/O driver in write mode
A 2 4 2 7.1 Get next address to write to
A.2.4 2.7.2 Check for Zone full
A.2.4 2.7.3 If full send status message indicating
full
A.2.4.2.7.4 Do STATUS MESSAGE Exit
A.2.4.2.7.5
A.2.4.2.7.6 Write each byte from data portion of
I/O buffer to EEPROM
A.2.4.2.7.7 Set field and length flags in EEPROM
A.2.4.2.7.8 Update RAM address of next available
byte to write to
A.2.4.2.7.9 Format successful status message
A.2.4.2.7.10 Do STATUS MESSAGE
A 2 4 2 8 CLEAR COMMAND
A 2 4 2 8.1 Validate Provider, terminal and
application
A.2.4.2.8.2 Clear Zone A
A.2.4.2.8.3 Write sentinel record in 1st byte
Zone A
A.2.~.2.8.4 Reset Pointers
A 2 4 2 9 DESTROY COMMAND
A 2 4 2 9.1 Validate Provider, terminal and appln.
A.2.4.2.g.2 Clear Zone A
A.2.4.2.9.3 Set up RAM erase sequences
A.2.4.2.9.4 Clear Zone B
A.2.4.2.10 STOP COMMAND
A.3 ROUTINES
o~
-15-
A.3.1 STAT~S MESSAGE
A.3.1.1 Set preamble
A.3.1.2 SERIAL I/~
A 3.2 SERIAL I/O DRIVER
A 3.2.1 READ MODE
A.3.2.2 WRITE MODE
A 3 3 BLOCK MOVE TO RAM 2UFFER
A 3 3.1 Get beginnina address of send area
A 3 3 1 G Set OP code and beginning of
address
A.3.3.4 MOVE EA alter instruction addre
A 3 3 4 2 perform instruction and RTS in RAM
The initia3 state of the microcomputer is shown as
follows:
RAM ZONE A ) EEPROM (1792 bytes)
* * * * * * * * * * * * * * * *
* 176 bytes * *
* RAM *
* * *
************************************************************
$0n50 $00sF $0100 $09FF ~OA00 $10FF
The ROM boctstrap (BootO) which comes with the
microcomputer loads Bootl into RAM address space beginning at
$0050. Control is then passed to Bootl which loads the smart
card control program 50, Boot2 which will subsequently per-
sonalize~ the smart card, and vectors to pass subsequent
control to the application. The prosramming of the microcom-
puter with the smart card control program 50 is preferably
done by program equipment 70 while the microcomputer 40 is on
the carrier substrate 42 but is not yet imbedded in the smart
card 20 as generally illustrated in FIGURE 4. As
illustrated, the carrier substrate 42 might be fed from and
to tape-like reels 72. The programmer equipment 70 has the
standard ISO contacts as well as the switch contact which
~.~8~
will direct execution to t~e ROM bootstrap. The results of
the smart card load are acknowledged from the smart card. No
response or a NAK ~ill result in the carrier being
scored/holed so that the ~art is recognizable and per-
sonalization time is bypassed. Also, provision is made to
disable the circuitry, or vectors for loading the smart card.
The memory map after loading the smart card control program
through Bootl is illustrated below:
ZONE A ZONE B
RAM EEP~M (2304 bytes) EEPROM (1792 bytes)
*****************~*****************************~************
*176 bytes * B ¦ * SMA?~T *
* RAM * O initialized * CARD *
* -1- * * CONTROL *
* * T * PROGRAM *
**********~******** ********************************* ********
$0050 $0nBF $0100 $09FF $0A00 $10FF
In use, at the time cf initial personalization of
the smart card 20 by the app'ication user, the smart card
control program 50 at the time of being powered up will
recognize that Boot2 is present in memory and will perform
that function. Boot2 will load data dict onary 50 and per-
sonalization data into memory Zone B, loac the personalized
user data into the smart card 20 beyond the data dictionary,
erases Boot2 from memory Zone A, and writes a Sentinal to
indicate the beginning of Zone A. The card personalization
process is initiated by an interactive process which defines,
batch, date, customer and data dictionary to use. This
extracts the necessary information to define the user's input
and the fixed data to include in the data dictionarv.
Personalization data is preferably stored on a suitable
storage media and r~ad in by the utility program and written
to a smart card as it passes a reader. The chip carrier
might have been imbedded into the smart card prior to the
~,Z80S~
persona]ization process so as to reduce waste or might later
he imbedded in the smart card. In any event, the contacts
31-38 are presented ~o the card personalization ~erminal
which will be programmed to interface with the smart card
control pro~ram 50. Power is applied to the smart card and
the smart card will initiate dialog with the personalization
terminal. After personalization, the memory map will appear
as follows:
ZONE A ZONE B
RAM EEPROM (230~ bytes) EEPROM (1792 bytes)
***************************~********************************
* 176 ~ytes * S * SMART DATA USER *
* RAM * N initialized * CARD DICT. DATA *
* -1- * T * CONTROL *
* * L * PROGRAM *
****************** ************************** ****** ***** ******
S0050 $00BF $0100 $09FF $0A00 $10FF
Transactions are entered by the smart card being
placed in a reader and the application program issuing com-
mands to write data to the smart card. The data is written
in the next available location. The smart card of the pre-
sent invention has the capability to reinitialize Zone A of
the memory and reload sele_ted transactions to make room for
more. During transaction processing the memory map generally
appears as follows:
~ao5~
-18-
ZONB A ZO~E B
RAM EEPROM (2304 bytes) EEPROM (1792 bytes)
************************************************.~************
* * * SMART DATA USER *
* 17h bytes * Trans. iritia]i- * CARD DICT. DATA *
* RAM * zation * CO~TROL *
* -1- * PROGRAM *
********************** *********************~ ***~** ***** ******
S0050 SOOBF S0100 $09FF $0A00 510FF
It is to be understood that even though the above
numerous characteristics and advantages of the invention have
been set fcrth in the foregoing desc-iption, together with
details of the structure function of the invention, the
disclosure is illustrative only, and changes may be made in
detail, especially in matters of shape, size and arrangement
of parts within the principle of the invention, to the full
extent indicated by the broad general meaning of the terms in
which the aPpended claims are expressed.
.
