ISO/IEC 12905:2011

INTERNATIONAL ISO/IEC
STANDARD 12905
First edition
2011-07-15
Integrated circuit cards — Enhanced
terminal accessibility using cardholder
preference interface
Cartes à circuit intégré — Amélioration de l'accès aux terminaux via une
interface d'acquisition des préférences du porteur de carte

Reference number
©
ISO/IEC 2011
©  ISO/IEC 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2011 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Symbols and abbreviated terms .2
5 Overview.2
5.1 Universal Cardholder Information .2
5.2 Flexibility .3
5.3 Privacy of user related information .3
6 Requirements for interoperability.3
6.1 Basic Rules of UCI.3
6.2 UCI Structure .4
6.3 Organization of UCI .4
6.3.1 Organization of Global UCI.4
6.3.2 Organization of Local UCI.5
7 UCI organization and content .5
7.1 General structure of Global UCI.5
7.2 Global UCI components.6
7.2.1 Global UCI, Tag '65' .6
7.2.2 Cardholder preferred language, Tag '5F2D'.6
7.2.3 Tag allocation authority and proprietary cardholder's requirements. Tag '68'.6
7.2.4 Proprietary cardholder's requirements, Tag '70'-'77' except '73' .7
7.2.5 Cardholder's requirements for included features, Tag '7F22' .7
7.2.6 Cardholder's requirements for excluded features, Tag '7F23'.7
7.3 General structure of Local UCI .7
7.4 UCI data objects .7
8 Construction of UCI.8
8.1 Construction of Global UCI .8
8.2 Construction of Local UCI .9
9 Procedure for reading UCI.9
9.1 In case of Global UCI which exists in EF_ATR/INFO (Case 1).10
9.2 In case of Global UCI which exists in UCI_DF/DO (Case 2) .11
10 Maintenance.12
Annex A (normative) Data Element Specification for users with special needs.13
A.1 User interface data objects.13
A.2 Coding of user requirements .14
A.3 Coding of user requirements for input.15
A.4 Coding of user requirements for terminal output .23
Annex B (normative)  Summary of tags and meanings .37
Annex C (informative) Comparison between Annex A and ISO/IEC 24786.39
Bibliography.41

© ISO/IEC 2011 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 12905 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
iv © ISO/IEC 2011 – All rights reserved

Introduction
Card system terminals, which are commonly used worldwide in modern society and whose numbers are still
growing, do not operate effectively enough for cardholders with special needs or senior citizens because most
of those terminals only have uniform man-machine interfaces.
This International Standard aims to improve the man-machine interface through which cardholders interact
with terminals by defining a mechanism by which terminal functions can be adjusted to the individual's
preferences.
It can help terminal design to be more user-friendly by allowing the cardholder to carry his preferences within
his card. This will benefit both ordinary cardholders and those with special needs.
The purpose of this International Standard is to prescribe the contents and the form of unifying assistance
information that can be mutually used in international systems to improve interoperability. Moreover, this will
benefit manufacturers as currently system developers have to design and fund for each system.

© ISO/IEC 2011 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 12905:2011(E)

Integrated circuit cards — Enhanced terminal accessibility
using cardholder preference interface
1 Scope
This International Standard specifies a set of data elements to be personalized into an integrated circuit card,
encoding cardholder preferences. These data elements are to be retrieved from the card and to be used to
indicate to the terminal that the user has special needs regarding the user interface. It is not intended to
standardize the actual application programming interface or other terminal-specific software allowing the
functionality, nor does it cover the actual alignment of the card to the card-reader slot.
This International Standard is independent of the physical interface and is applicable to situations where the
cardholder operates the card-accepting equipment (e.g. a cash dispenser, ticket machine, vending machine).
It applies not only to ID-1 type cards, but also to SIM/UIM (ID-000) on mobile phones and form-factor-free
contactless integrated circuit cards which are specified in ISO/IEC 14443.
This International Standard comprises:
⎯ data elements containing the user preferences,
⎯ the storage/retrieval formats for input and output of these data elements,
⎯ security related to the information contained in these data elements,
⎯ the access method to these data elements, and
⎯ protection of cardholder information.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 7816-6:2004, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for
interchange
ISO 639-1:2002, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO/IEC 19785-3:2007, Information technology — Common Biometric Exchange Formats Framework —
Part 3: Patron format specifications
© ISO/IEC 2011 – All rights reserved 1

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
data element
item of information seen at the interface for which are specified a name, a description of logical content, a
format and a coding
[ISO/IEC 7816-4:2005]
3.2
data object
information seen at the interface consisting of the concatenation of a mandatory tag field, a mandatory length
field and a conditional value field
[ISO/IEC 7816-4:2005]
3.3
template
set of BER-TLV data objects forming the value field of a constructed BER-TLV data object
[ISO/IEC 7816-4:2005]
3.4
UCI dataset
set of data elements for each cardholder preference
4 Symbols and abbreviated terms
ACR access control rule
b8.b1 bits one to eight of a byte
BCD binary coded decimal
DO data object
ICC integrated circuit card
PIN personal identification number
SMS short message service
TLV tag, length, value
UCI universal cardholder information

5 Overview
5.1 Universal Cardholder Information
This standard specifies a set of data elements to be personalized into the card encoding cardholder
preferences. A set of data elements is called Universal Cardholder Information (UCI).
2 © ISO/IEC 2011 – All rights reserved

The UCI is held on the card, supplied and approved by a cardholder and openly accessible by all. It may be
used by the terminal and its applications to provide service in the form required by the cardholder.
The UCI core dataset is intended to be read before the cardholder uses the application. That is, it may be read
just after the card is presented to the terminal or just after application selection.
5.2 Flexibility
The UCI should be specified in a flexible manner to cater for existing pre-defined situations, new and as yet
undetermined environments (i.e. systems and terminal types), different application scenarios, and provider-
specific requirements. UCI should be independent from specific systems or terminals.
In addition, the UCI may be modified either temporarily or permanently by cardholder request; for example, if
the cardholder is subject to a change in his / her circumstances.
The implications of this are:
⎯ many of the UCI dataset elements are optional, as determined by the cardholder, where the provision of
personal preference information is concerned. Where optional data elements specified in this standard
are used, the formats shall be as specified in this standard;
⎯ UCI allows itself to be formally extended through the use of versions and version numbers, as well as
informally extended on a case by case basis by providers and implementers who need to supply
additional information in a standardised manner;
⎯ a certificate or digital signature may optionally be associated with UCI data to warrant its authenticity and
integrity;
⎯ implementation of the on-card UCI application is not confined to its use in IC Cards compliant with
ISO/IEC 7816. It may also be implemented on IC Cards compliant with other specifications providing that
those cards support the provisions of this standard.
5.3 Privacy of user related information
User privacy is provided as follows:
⎯ the terminal shall not retain the data elements or objects stored on the card;
⎯ a set of the data elements which is used for user preference should not be used for personal identification
purposes. It may be linked to the personal information or it may be used without such a link;
⎯ the data elements which are defined in this standard are not intended as a description of any or all of the
obstacles faced by cardholders;
⎯ the UCI shall always be available;
⎯ modification of UCI preferences data by user shall require the permission of the cardholder.
6 Requirements for interoperability
6.1 Basic Rules of UCI
The UCI dataset is accessible as chains of constructed data objects (DOs), with access mechanisms specified
in this standard. Each constructed DO is known as one UCI Component. Constructed DOs shall use BER-TLV
format. Constructed DOs shall use BER-TLV encoding according to ISO/IEC 7816-4.
© ISO/IEC 2011 – All rights reserved 3

The UCI dataset is recorded to the individual card for providing customization options when the cardholder
uses the terminal (e.g. change the size of characters on screen or change the contrast of the screen). See
Annex A for a full list of options.
Annex C shows the relationship between the data objects listed in Annex A and those listed in ISO/IEC 24786,
Information technology — User interfaces — Accessible user interface for accessibility settings on information
devices.
6.2 UCI Structure
There are two types of UCI - Global or Local. Global UCI is common to all applications in an ICC. Local UCI
exists in each application file. For the Local UCI, different Access Control Rules (ACRs) may apply. Figure 1
shows the Global UCI and Local UCI.
The Global UCI shall be mandatory for any implementation complying with this standard. In addition,
application files may contain application specific user preferences in each Local UCI after a successful
application selection.
Figure 1 — Global UCI and Local UCI
6.3 Organization of UCI
6.3.1 Organization of Global UCI
The Global UCI shall be constructed as a logical hierarchy of Data Objects, both constructed and primitive
(see ISO/IEC 7816-4:2005). A DO with tag '65' shall constitute Global UCI root, meaning that after initialization
or after selection of Global UCI, Global UCI shall be accessible directly at the interface as a constructed DO
with tag '65'.
Figure 2 illustrates the types of data element specified in Global UCI. It does not show all possible data
elements or components.
4 © ISO/IEC 2011 – All rights reserved

‘65’
‘5F2D’
Cardholder
Language Preference
related data
‘7F22'
‘68’
Cardholder requirements –
Identification of
included features
allocation authority
Proprietary
‘7F23'
cardholder’s
requirements
Cardholder requirements –
excluded features
Figure 2 — Global UCI DOs
6.3.2 Organization of Local UCI
Figure 3 illustrates the types of data element specified in Local UCI. It does not show all possible data
elements or components. Local UCI may include Tag '68' as root, Tag '7F22' and Tag'7F23'.
‘7F22'
‘68’
Cardholder requirements –
Identification of
included features
allocation authority
Proprietary ‘7F23'
cardholder’s
requirements
Cardholder requirements –
excluded features
Figure 3 — Local UCI DOs
7 UCI organization and content
7.1 General structure of Global UCI
The Global UCI dataset as seen at the interface (card edge) is held in a card and shall be composed of
Components, each of which shall be a single constructed DO identified by a tag as specified in Table 1.
© ISO/IEC 2011 – All rights reserved 5

Table 1 — Global UCI Components
Name Tag Mandatory Content
Optional
Global UCI '65' M Global Universal Cardholder Information (UCI)
Preferred Language '5F2D' M Cardholder preferred language according to ISO/IEC 7816-6
and ISO 639-1.
Tag allocation authority and
'68' M Template containing at least a tag allocation authority (tag
proprietary cardholder's '06', '41', '42' or '4F'), and. a data object by which this
authority indicates proprietary cardholder's requirements,
requirements
possibly related to a disability.
Non-interindustry DOs defined by a Tag Allocation Authority
Proprietary cardholder's '70'-'77' O
requirements by tag shall be encapsulated in the template of the DOs '70' to '77',
Except
allocation authority.
along with a DO which identifies the Tag Allocation
'73'
Authority.
Cardholder's requirements '7F22' O Data element containing a cardholder's requirements for
for included features included features.
Cardholder's requirements '7F23' O Data element containing cardholder's requirements for
for excluded features excluded features.

7.2 Global UCI components
Each Global UCI Components DO shall be formatted according to the structure (BER-TLV) and encoding
specified in ISO/IEC 7816-6. The Global UCI is made up of DOs of the following sources.
7.2.1 Global UCI, Tag '65'
The Global UCI shall be constructed as a logical hierarchy of DOs, both constructed and primitive (see
ISO/IEC 7816-4:2005). A DO with tag '65' shall constitute Global UCI root, meaning that after initialization or
after selection of Global UCI, Global UCI shall be accessible directly at the interface as a constructed DO with
tag '65'.
7.2.2 Cardholder preferred language, Tag '5F2D'
Language preferences, in desired priority order, to be used, for example, by the terminal to communicate with
the Cardholder (display, printer, audio). The first language shall be mandatory. Up to 4 languages may be
included. This DO has a variable length with value field of 2-8 bytes. The value field of this data object shall
encode the language coded according to ISO 639-1 in 2 bytes. The first (left-most) language coded has
highest priority and should be used by the terminal as the default value.
7.2.3 Tag allocation authority and proprietary cardholder's requirements. Tag '68'
Within the UCI Component, the special needs constructed DO (tag '68') template shall contain at least the
DOs specified or referenced in this and following sub-clauses, containing the data elements for user
preferences for the configuration of the terminal interface and environment. Refer to Annex A for a description
of these data elements and to Annex B for a table for the Tags used for the BER-TLV encoding of these data
elements.
The template of the DO '68' may in addition contain DOs encoding cardholder special needs defined in other
standards or specifications, by using a compatible tag allocation scheme as defined in ISO/IEC 7816-6. The
length of the UCI constructed DO is determined by the number of special needs code data elements present,
as decided and confirmed by the cardholder.
6 © ISO/IEC 2011 – All rights reserved

The template contains at least a tag allocation authority (tag '06', '41', '42' or '4F'), and a DO by which this
authority indicates the proprietary cardholder's requirements. The DO identifies the Tag Allocation Authority
('06' for an OID encoding a standard reference, tag '41' Country code (ISO 3166-1) and optional national data,
tag '42' Issuer identification number (ISO/IEC 7812-1) and tag '4F' AID).
7.2.4 Proprietary cardholder's requirements, Tag '70'-'77' except '73'
DOs defined by a Tag Allocation Authority other than the present standard shall be encapsulated in the
template of the DOs tag '70' to '77', along with a DO which identifies the Tag Allocation Authority (tag '06' for
an OID encoding a standard reference, tag '41' national authority, tag '42' Issuer identification number).
7.2.5 Cardholder's requirements for included features, Tag '7F22'
Data element containing a cardholder's requirements for included features e.g. cardholder requires audio
assistance from an ATM (automated teller machine).
7.2.6 Cardholder's requirements for excluded features, Tag '7F23'
Data element containing cardholder's requirements for excluded features e.g. cardholder is not able to use
fingerprint verification.
7.3 General structure of Local UCI
The Local UCI dataset as seen at the interface (card edge) is held in a card and shall be composed of
Components, each of which shall be a single constructed DO identified by a tag as specified in Table 2.
Table 2 — Local UCI Components
Name Tag Mandatory Content
Optional
Tag allocation authority and
'68' M Template containing at least a tag allocation
authority (tag '06', '41', '42' or '4F'), and a DO by
proprietary cardholder's
which this authority indicates proprietary
requirements
cardholder's requirements, possibly related to a
disability.
Non-interindustry DOs defined by a Tag Allocation
Proprietary cardholder's '70'-'77' O
requirements by tag allocation Authority shall be encapsulated in the template of
Except
authority.
the DOs tag '70' to '77', along with a DO which
'73'
identifies the Tag Allocation Authority.
Cardholder's requirements for '7F22' O Data element containing a cardholder's
included features requirements for included features.
Cardholder's requirements for '7F23' O Data element containing cardholder's
excluded features requirements for excluded features.

7.4 UCI data objects
In addition to DOs described in Table 1, UCI interindustry DOs described in Table 2 may be found within any
template of the UCI data set having the meaning defined by ISO/IEC 7816-6. Table 3 shows General use DOs.
© ISO/IEC 2011 – All rights reserved 7

Table 3 — General use DOs
DO Name Tag Definition and Additional Information
Controls
Taglist '5C' List of tags of DOs; use to indicate UCI Components to which a management
Component applies.
Certificate '7F21' Used by the Card or UCI Issuer for traceability (Format not specified in this
standard. A Country code is expected to specify the format if required for its
UCI Components (tag '7F22' and '7F23'). It may be found within the template
of the DO UCI (tag '7F22' and '7F23').
Object Identifier '06' DO identifying for the Tag Allocation Authority.
(OID)
Discretionary '53' Use in the UCI for the Component plain text name (e.g. "CEN URI UCI" or
data object "Universal Cardholder Information").
URL '5F50' May be used to point to a service provided by a server addressed by URL:
Display Message '5F45' Data element containing a message to display.

8 Construction of UCI
8.1 Construction of Global UCI
In a generic scenario, the structure of the template of the DO tag '65' may be of the form as shown in Table 4.
Table 4 — Example construction of Global UCI (Tag '65') General use data objects
Tag L Value
'65' var Root of Global UCI Data objects
Tag L Value
'5F2D' var Language (4 max)
Language 1
Language 2
Language 3
Language 4
'68' var Tag allocation authority and proprietary cardholder's requirements
Tag L Value
Identification for Tag allocation authority. or '41'
'06' var
or '42'
Proprietary cardholder's requirement 1 by tag allocation
'70' var
authority.
Proprietary cardholder's requirement 2 by tag allocation
'71' var
authority.
'7F22' var Cardholder requirements –included features
T1 L1 V1:Cardholder requirements –included feature 1
T2 L2 V2:Cardholder requirements –included feature 2
T3 L3 V3:Cardholder requirements –included feature 3
'7F23' var Cardholder requirements – excluded features
V1:Cardholder requirements –excluded feature
T1 L1
V2:Cardholder requirements –excluded feature
T2 L2
8 © ISO/IEC 2011 – All rights reserved

8.2 Construction of Local UCI
In a generic scenario, the structure of the template of the DO '68' may be of the form as shown in Table 5.
Table 5 — Example construction of Local UCI (Tag '68') General use data objects
Tag L Value
'68' var Tag allocation authority and proprietary cardholder's requirements
Tag L Value
'06' var Identification for Tag allocation authority. or '41' or '42'
'70' var Proprietary cardholder's requirement 1 by tag allocation authority.
'71' var Proprietary cardholder's requirement 2 by tag allocation authority.
'7F22' var Cardholder requirements –included features
T1 L1 V1: Cardholder requirements –included feature 1
T2 L2 V2: Cardholder requirements –included feature 2
T3 L3 V3: Cardholder requirements –included feature 3
'7F23' var Cardholder requirements – excluded features
T1 L1 V1: Cardholder requirements – excluded feature 1
T2 L2 V2: Cardholder requirements – excluded feature 2

9 Procedure for reading UCI
Retrieval of the Global UCI components from the IC card may be done using any of the mechanisms
described in ISO/IEC 7816-4. If all the procedures described hereafter fail to return the Global UCI
components, the card is deemed not to have any Global UCI components.
The setting of Global UCI and Local UCI are out of scope in this standard.
It is not recommended to update and/or add to DOs for Global UCI. It is possible to update and/or add to DOs
for the Local UCI. If the same DO(s) exist in both Global and Local UCI, the priority shall be the DO in the
local UCI.
Global UCI components specified are either:
⎯ prioritized over any authentication processes which relate to the cardholder. It is accessed freely; or
⎯ accessible upon a successful PIN presentation.
Global UCI components may be stored in the card and accessed either as
⎯ Case 1, a sequence of DOs directly stored in the EF.ATR/INFO file that shall support data object
handling; or
⎯ Case 2, single independent application with AID "E8 28 E4 69".
Case 1
Global UCI can be read using a read command function when the Global UCI components are available as a
sequence of DOs stored in the EF_ATR/INFO.
© ISO/IEC 2011 – All rights reserved 9

Case 2
In case the Global UCI is implemented as an independent application, the implicit selection application is
recommended. The UCI AID should be present in the historical bytes ('Fy' (y: length) +AID) or in the initial
data string according to ISO/IEC 7816-4. Or, the Global UCI shall be selected using the SELECT DF
command using the AID as DF name.
9.1 In case of Global UCI which exists in EF_ATR/INFO (Case 1)
Figure 4 shows the procedure for reading of Global UCI which exists in EF_ATR/INFO. When Global UCI
does not exist in EF_ATR/INFO, go to Figure 5 for searching Global UCI.
1) Card enabled through contact or contactless interface
2) Check UCI_AID in historical byte
⎯ If UCI_AID exists, go to Case 2 (Select UCI_DF/DO)
⎯ If UCI_AID does not exist, go to 3.
3) Check the Global UCI in an EF_ATR/INFO
⎯ If the Global UCI exists in an EF_ATR/INFO, then go to 4.
⎯ If the Global UCI does not exist in EF_ATR/INFO, then go to Case 2 (Select UCI_DF/DO).
4) Read Global UCI and go to Selection of Application

Figure 4 — Case 1: ICC has a UCI in EF_ATR/INFO

10 © ISO/IEC 2011 – All rights reserved

9.2 In case of Global UCI which exists in UCI_DF/DO (Case 2)
Figure 5 shows the procedure for reading of Global UCI which exists in UCI_DF. When Global UCI does not
exist in ICC, ICC may have UCI in each application file.
1) Card enabled through contact or contactless interface or continue from Case 1;
2) Select UCI_DF/DO by the AID;
⎯ If the UCI_DF/DO exists in an ICC, go to 3.
⎯ If the UCI_DF/DO does not exist in an ICC, go to 5.
3) Check the access condition;
⎯ If the DF/DO has the access condition, clear the access condition and go to 4.
⎯ If the DF/DO does not have the access condition, go to 4
4) Read and parse the Global UCI. Use the information in the UCI to configure the terminal;
5) Select an Application;
6) Check the Local UCI;
⎯ If the Local UCI exists in the Application, go to 7.
⎯ If the Local UCI does not exist in the Application, go to 9.
7) Check the access condition;
⎯ If the DF/DO has the access condition, clear the access condition and go to 8.
⎯ If the DF/DO does not have the access condition, go to 8
8) Read and parse the Local UCI;
9) Go to processing the Application.
If there are the same DO(s) in both Global and Local UCI, the priority shall be the DO in the local UCI.
© ISO/IEC 2011 – All rights reserved 11

Start From Case 1
Select application
Y
Select UCI DF/
N
DO?
Local UCI?
Y
Y
Access free? N
Access free? N
Clear access
Clear access
Y
Y Y
conditions?
Y
conditions?
N
Read Global UCI
Read Local UCI
N
N
Go to application
Figure 5 — Case 2: In case of Global UCI which exists in UCI_DF/DO
10 Maintenance
Maintenance of UCI data elements (Annex A) of this standard shall be managed by
ISO/IEC JTC 1/SC17/WG 4.
It is the intention that every user requirements data object, specified at the time of publication, should be listed
in this International Standard. To allow the introduction, deletion or amendment of any data object,
ISO/IEC JTC 1/SC 17/WG 4 will review applications for new data objects and will authorize publication of a list
of requested data objects accepted by WG 4 on the ISO/IEC JTC 1/SC 17 web site. User requirements data
objects published on the SC 17 web site will be incorporated in the next revision of this International Standard.
12 © ISO/IEC 2011 – All rights reserved

Annex A
(normative)
Data Element Specification for users with special needs
A.1 User interface data objects
A.1.1 General remarks
The goal of each data object in this Annex is to;
⎯ support the cardholder’s preferred requirement, and
⎯ enable the support of these functions by the terminal.
Data objects for cardholder's requirements are listed according to their properties. Some of them related to
input/output functions are in Clause A.2; others related only to input function in Clause A.3 and others related
only to output function in Clause A.4. Detailed coding is given in each clause.
For each data object, the following descriptors may be present:
⎯ purpose (a short description of the use of the given data object);
⎯ format (giving the size of the data object and possibly a symbolic format used to describe the content);
⎯ content (the exact definition for the coding of the data object).
Absence of a data object in the card indicates that no special requirements apply in the area concerned.
Where data objects are not specified by the UCI, it is recommended either to decide each value by reference
to ISO/IEC TR 29138 series, or to apply the relevant functionality of the terminal if available.
A.1.2 Principles
The following principles apply to the identification of user preference data objects within this standard:
1) user preference DOs are encoded in this standard using contextual class tags according to
ISO/IEC 7816-6, which are stored in the tag '7F22' and '7F23' templates. When the same data object
exists in each template, the priority should be 'exclude';
2) a data element is generally presented in the value field of a data object;
3) a data object is the concatenation of the following string of bytes;
⎯ mandatory tag field, referred to as a tag;
⎯ mandatory length field indicating the number of bytes of the value field;
⎯ conditional value field of L bytes (when 'L' is not equal to '00').
© ISO/IEC 2011 – All rights reserved 13

A.2 Coding of user requirements
A.2.1 General characteristics
A.2.1.1 Language
Purpose: To indicate up to 4 preferred languages in order of user preference.
Format: 2 alphabetic characters per language.
Content: This element is coded in accordance with ISO 639-1 tag '5F2D' as defined in ISO/IEC 7816-6.
This data object is addressed through the use of tag '5F2D'
NOTE ― This sub clause corresponds to "5.4.17 Language" in EN 1332-4:2007.
A.2.1.2 Numeric, time and date presentation
Purpose: To indicate preferred numeric delimiter for showing the decimal point and preferred format for time
and date.
Format: 1 byte binary.
Content: The coding of the settings for the numeric presentation byte shall be in accordance with Table A.1.
Table A.1 — Content of numeric, time and date presentation data object ('9F6A')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - x x x Numeric
- - - - - 0 0 1 Use comma for decimal point
- - - - - 0 1 0 Use period (fullstop) for decimal point
- - - - - 1 0 0 Use space for decimal point
- - - - - Any other values Reserved for future use by ISO/IEC JTC 1/SC 17
- - - x x - - - Time
- - - 0 1 - - - Use 12 hour clock
- - - 1 0 - - - Use 24 hour clock
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
x x x - - - - - Date presentation data
0 0 1 - - - - - Use day, month, year
0 1 0 - - - - - Use month, day, year
1 0 0 - - - - - Use year, month, day,
Reserved for future use by ISO/IEC JTC 1/SC 17. All
Any other values - - - - -
bits set to zero
NOTE ― This sub clause corresponds to "5.4.28 Numeric, time and date presentation" in EN 1332-4:2007.
14 © ISO/IEC 2011 – All rights reserved

A.2.2 Special devices
A.2.2.1 SMS communication
Purpose: To indicate the SMS communication required.
Format: 1 byte binary.
Content: The coding of the SMS communication byte shall be in accordance with Table A.2.
Table A.2 — Content SMS communication data object ('9F5F')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - - 1 SMS input required
- - - - - - 1 - SMS output required
Reserved for future use by ISO/IEC JTC 1/SC 17.
x x x x x x - -
All bits set to zero
NOTE ― This sub clause corresponds to "5.4.12 SMS communication" in EN 1332-4:2007.
A.3 Coding of user requirements for input
A.3.1 General characteristics
A.3.1.1 Input requirements
Purpose: To indicate the preferred method for input of data into the terminal.
Format: 1 byte binary.
Content: The coding of the input requirements bytes shall be in accordance with Table A.3.
Table A.3 — Content of the input requirements data object ('9F59')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - - 1 Voice input required
- - - - - - 1 - Keyboard (hard) input required
- - - - - 1 - - Connect special keyboard
- - - - 1 - - - Wireless
- - - 1 - - - - Touchpanel
Reserved for future use by ISO/IEC JTC 1/SC 17.
x x x - - - - -
All bits set to zero
NOTE 1 ― For SMS input or output. See Table A.2.
NOTE 2 ― This sub clause corresponds to "5.4.10 Input requirements" in EN 1332-4:2007.
© ISO/IEC 2011 – All rights reserved 15

A.3.1.2 Time-outs
Purpose: To indicate a requirement for additional time beyond the normal time-out to complete user input
processes, thus reducing the potential for errors caused by device time-outs.
Format: 1 byte coded as two BCD digits.
Content: The number of seconds of time required before a time-out or a series of time-outs shall come into
force.
This data object is addressed through the use of tag '9F5C'.
NOTE ― This sub clause corresponds to "5.4.16 Time-outs" in EN 1332-4:2007.
A.3.1.3 Menu selection mode
Purpose: To indicate preferred settings for menu selections.
Format: 1 byte binary.
Content: The coding of the settings for Preferred modes (e.g. select by number rather than highlight) byte
shall be in accordance with Table A.4.
Table A.4 — Content of the menu selection data object ('9F73')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - x x Menu selection mode
- - - - - - 0 1 Select by highlight
- - - - - - 1 0 Select from numbered list
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
Reserved for future use by ISO/IEC JTC 1/SC 17. All bits
x x x x x x - -
set to zero
NOTE ― This sub clause corresponds to "5.4.35 Menu selection" in EN 1332-4:2007.
A.3.2 Input devices
A.3.2.1 Keyboard characteristics
Purpose: To indicate the preferred keyboard characteristics.
Format: 2 bytes binary.
Content: The coding of the keyboard characteristics bytes shall be in accordance with Table A.5 and A.6.
16 © ISO/IEC 2011 – All rights reserved

Table A.5 — Content of the keyboard characteristics first data object ('9F5E')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - x x PIN pad top row
- - - - - - 0 1 PIN pad top row denotes the digits 1,2,3
- - - - - - 1 0 PIN pad top row denotes the digits 7,8,9
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
- - - x x x  Alphanumeric layout
- - - 0 0 1 - - Alphanumeric layout (QWERTY)
- - - 0 1 0 - - Alphanumeric layout (AZERTY)
- - - 1 0 0 - - Alphanumeric layout (alphabetic order)
- - - Any other values - - Reserved for future use by ISO/IEC JTC 1/SC 17
Reserved for future use by ISO/IEC JTC 1/SC 17. All
x x x - - - - -
bits set to zero
Table A.6 — Content of the keyboard input requirements second data object ('9F5E')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - - 1 Repeat keys (e.g. auto-repeat when held down)
- - - - - - 1 - Chording input (e.g. for Braille)
- - - - - 1 - - Sticky keys
- - - - 1 - - - Debounce
Reserved for future use by ISO/IEC JTC 1/SC 17.
x x x x - - - -
All bits set to zero
NOTE ― This sub clause corresponds to "5.4.11 Keyboard characteristics" in EN 1332-4:2007.
A.3.2.2 On-screen keyboard
Purpose: To indicate preferred presentation of an on-screen keyboard.
Format: 1 byte binary.
Content: The coding of the settings for the presentation of an on-screen keyboard byte shall be in accordance
with Table A.7.
© ISO/IEC 2011 – All rights reserved 17

Table A.7 — Content of the on-screen keyboard data object ('9F69')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - x X Keyboard
- - - - - - 0 1 Enhanced keyboard
- - - - - - 1 0 Standard keyboard
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
- - - - x x x x Layout
- - - - 0 1 - - Regular layout
- - - - 1 0 - - Block layout
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
- - x x - - - - Keys
- - 0 1 - - - - 101 keys
- - 1 0 - - - - 102 keys
- - 1 1 - - - - 106 keys
Any other
- - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
Reserved for future use by ISO/IEC JTC 1/SC 17. All
x x - - - - - -
bits set to zero
NOTE — This sub clause corresponds to "5.4.27 On-screen keyboard" in EN 1332-4:2007.
A.3.2.3 Touchpanel screen
Purpose: To indicate the preferred layout and icon characteristics for a touch panel screen input device.
Format: 1 byte binary.
Content: The coding of the touchpanel screen byte shall be in accordance with Table A.8.
Table A.8 — Content of the touchpanel screen data object ('9F5A')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 - - - - - - - Do not use touch-panel screen
0 - - - - - x x Button size
0 - - - - - 0 1 Large button size required
0 - - - - - 1 0 Very large button size required
Any other
0 - - - - - Reserved for future use by ISO/IEC JTC 1/SC 17
values
0 - - - - 0 - - Finger entering touch-sensitive area
0 - - - - 1 - - Finger exiting touch-sensitive area
Reserved for future use by ISO/IEC JTC 1/SC 17 All bits set to
x x x x x - - -
zero
In the above table, "button" refers to the target area to be touched on the screen to activate the input. This
data object is addressed through the use of tag '9F5A'.
18 © ISO/IEC 2011 – All rights reserved

NOTE ― This sub clause corresponds to "5.4.14 Touchpanel screen" in EN 1332-4:2007.
A.3.2.4 Pointer buttons
Purpose: To indicate preferred pointer button settings.
Format: 1 byte binary.
Content: The coding of the settings for the pointer buttons byte shall be in accordance with Table A.9.
Table A.9 — Content of the pointer buttons data object ('9F67')
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - - - 1 Switch primary and secondary buttons
- - - - - x x - Double click speed
- - - - - 0 1 - Double click speed – Slow
- - - - - 1 0 - Double click speed – Normal
- - - - - 1 1 - Double click speed – Fast
- - - - - 0 0 - Reserved for future use by ISO/IEC JTC 1/SC 17
- - - - 1 - - - Turn on Click Lock
Reserved for future use by ISO/IEC JTC 1/SC 17. All
x x x x - - - -
bits set to zero
NOTE ― This su
...