Reading of an EF can be done in two different ways.

1. If the short file identifiers are used the following procedure applies:
   • If short file identifiers are used, EFs that support SFI within the Current Directory can be read without explicitly selecting the EF. The terminal selects the DF or ADF and sends a READ command. This contains the short file identifier of the EF to be read and the location of the data to be read. If the access condition for READ is fulfilled, the application sends the requested data contained in the EF to the terminal. If the access condition is not fulfilled, no data will be sent and an error code will be returned.
2. If the short file identifiers are not used the following procedure applies:
   • The terminal selects the EF and sends a READ command. This contains the location of the data to be read. If the access condition for READ is fulfilled, the application sends the requested data contained in the EF to the terminal. If the access condition is not fulfilled, no data will be sent and an error code will be returned.

Updating of an EF can be done in two different ways:

1. If the short file identifiers are used the following procedure applies:
   • If short file identifiers are used, EFs that support SFI within the Current Directory can be updated without explicitly selecting the EF. The terminal selects the DF or ADF and sends an UPDATE command. This contains the short file identifier of the EF and the location of the data to be updated and the new data to be stored. If the access condition for UPDATE is fulfilled, the application updates the selected EF by replacing the existing data in the EF with that contained in the command. If the access condition is not fulfilled, the data existing in the EF will be unchanged, the new data will not be stored, and an error code will be returned.
2. If the short file identifiers are not used the following procedure applies:
   • The terminal selects the EF and sends an UPDATE command. This contains the location of the data to be updated and the new data to be stored. If the access condition for UPDATE is fulfilled, the application updates the selected EF by replacing the existing data in the EF with that contained in the command. If the access condition is not fulfilled, the data existing in the EF will be unchanged, the new data will not be stored, and an error code will be returned.

Increasing of an EF can be done in two different ways:

1. If the short file identifiers are used the following procedure applies:
   • If short file identifiers are used, EFs that support SFI within the Current Directory can be increased without explicitly selecting the EF. The terminal selects the DF or ADF and sends an INCREASE command. This contains the short file identifier of the EF and the value which has to be added to the contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, the application increases the existing value of the EF by the data contained in the command, and stores the result. If the access condition is not fulfilled, the data existing in the EF will be unchanged and an error code will be returned.
2. If the short file identifiers are not used the following procedure applies:
   • The terminal selects the EF and sends an INCREASE command. This contains the value which has to be added to the contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, the application increases the existing value of the EF by the data contained in the command, and stores the result. If the access condition is not fulfilled, the data existing in the EF will be unchanged and an error code will be returned.

A successful completion of one of the following procedures grants the access right of the corresponding PIN for an application session. This right is valid for all files within the application protected by this PIN. After a third consecutive unsuccessful completion of one of the following procedures associated to the same PIN, not necessarily in the same application session, the PIN becomes "blocked" and if the PIN status is set "enabled", the access right previously granted by this PIN is lost immediately. An access right is not granted if any of the following procedures are aborted.

The terminal checks the PIN and the following procedures apply:

• If the PIN status is set "enabled" and the PIN is "blocked", the procedure ends and is finished unsuccessfully.
• If the PIN status is set "disabled" and the PIN is "blocked", the procedure ends and is finished successfully. The terminal shall, however, accept applications which do not grant access rights when the PIN status is set "disabled" and the PIN is "blocked". In that case terminal shall consider those applications as "blocked".
• If the PIN status is set "disabled" and the PIN is not "blocked", the procedure is finished successfully.
• If the PIN status is set "enabled" and the PIN is not "blocked", the terminal uses the VERIFY PIN function. If the PIN presented by the terminal is equal to the corresponding PIN stored in the application, the procedure is finished successfully. If the PIN presented by the terminal is not equal to the PIN which protects the application, the procedure ends and is finished unsuccessfully.

The terminal checks the PIN and the following procedures apply:

• If the PIN status is set "disabled" or the PIN is "blocked", the procedure ends and is finished unsuccessfully.
• If the PIN status is set "enabled" and the PIN is not "blocked", the terminal uses the CHANGE PIN function. If the old PIN presented by the terminal is equal to the PIN which protects the application, the new PIN presented by the terminal is stored instead of the old one and the procedure is finished successfully.
• If the old PIN presented by the terminal and the PIN which protects the application are not identical, the procedure ends and is finished unsuccessfully.

PIN enabling and disabling/disabling and replacement may be disallowed by an application. If it is allowed then the following procedures shall be followed:

• If either the PIN status is set "disabled" or the PIN is "blocked", the procedure ends and is finished unsuccessfully.

Disabling and replacement:

• If the application PIN is not "blocked" and both the application PIN and the alternative global key reference statuses are set to "enabled", the terminal uses the DISABLE PIN function. If the PIN presented by the terminal is equal to the PIN which protects the application, the status of the PIN is set "disabled" and the usage qualifier of the alternative global key reference is set to "use" ('08') and the procedure is finished successfully. If the PIN presented by the terminal is not equal to the PIN which protects the application, the procedure ends and is finished unsuccessfully.

Disabling, no replacement:

• If the PIN is not "blocked" and the PIN status is set "enabled", the terminal uses the DISABLE PIN function. If the PIN presented by the terminal is equal to the PIN which protects the application, the status of the PIN is set "disabled" and the procedure is finished successfully. If the PIN presented by the terminal is not equal to the PIN which protects the application, the procedure ends and is finished unsuccessfully.

PIN enabling and disabling may be disallowed by an application. If it is allowed then the following procedures shall be followed:

• If either the PIN status is set "enabled" or the PIN is "blocked", the procedure ends and is finished unsuccessfully.
• If the PIN status is set "disabled" and the PIN is not "blocked", the terminal uses the ENABLE PIN function. If the PIN presented by the terminal is equal to the PIN which is assigned to the application, the status of the PIN is set "enabled" and the procedure is finished successfully. If the PIN presented by the terminal is not equal to the PIN which protects the application, the procedure ends and is finished unsuccessfully.

The execution of the PIN unblocking procedure is independent of whether or not the PIN is "blocked". The terminal checks if the UNBLOCK PIN is "blocked". If the UNBLOCK PIN is "blocked", the procedure ends and is finished unsuccessfully. If the UNBLOCK PIN is not "blocked", the terminal uses the UNBLOCK PIN function. If the UNBLOCK PIN presented by the terminal is equal to the corresponding UNBLOCK PIN of the application, the relevant PIN becomes "unblocked" and the procedure is finished successfully. If the UNBLOCK PIN presented by the terminal is not equal to the corresponding UNBLOCK PIN of the application, the procedure ends and is finished unsuccessfully.

Application selection by use of the EFDIR file is the procedure where the terminal reads the content of the EFDIR file and presents the list of applications to the user whom can then make select one or more applications to activate. The terminal performs the read procedure with EFDIR and presents the applications that it supports to the user who may make a selection. If only one supported application is found this may be implicitly selected.

An application may be selected, without reading the content of the EFDIR file, by performing the SELECT procedure with the AID of the application to be selected.

See clause 8.5.1.2.

The terminal performs the SELECT function with the AID of the selected application as a parameter. If the SELECT function ends successfully the selected application's initialization procedure is executed. If the initialization procedure ends successfully the UICC enters the operation state. If the initialization procedure does not end successfully, the UICC remains in the application management state and sends an indication to the user that it was not possible to activate the selected application.

The list of applications residing in the UICC can be read at any time when the UICC is not inactive. Request:

An application session can be terminated at any time when the UICC is not inactive.

After activation of the UICC the terminal requests the Preferred Language (EFPL). The terminal shall execute the power negotiation procedure. If the terminal supports CAT, it shall perform the CAT initialization procedure. The terminal then performs an application selection procedure according to clause 14.3.

If an application present on the UICC has the requirement to ensure that the UICC has not been removed during a card session the following procedure applies. The terminal sends, at frequent intervals, a STATUS command on the UICC-terminal interface. The STATUS command shall be issued within a period of inactivity on the UICC-terminal interface. The period of inactivity and the conditions under which the presence detection takes place is specified by the applications active during the card session. Inactivity in this case is defined as starting at the end of the last communication or the last issued STATUS command. If no response data is received to this STATUS command the terminal shall take the appropriate actions after the work waiting time (T = 0) or block waiting time (T = 1) has expired as specified by the applications active. If the DF indicated in an error free response to a STATUS command is not the same as that which was indicated in the previous response, or accessed by the previous command, then the terminal shall take appropriate actions as specified by the applications active during the card session. This procedure shall be used in addition to a mechanical or other device used to detect the removal of a UICC. In case of a UICC supporting LSEs, this procedure shall be performed for each LSE that requires presence detection.

Request: Update:

A UICC may offer the possibility to run several selectable applications in parallel. This is done with the logical channel mechanism. Only one selectable application can run at a given time in a given logical channel.

The terminal shall attempt to select and read the UICC Maximum Power Consumption file (EFUMPC). If the file is present, the UICC is aware of the maximum power consumption values for Release 12 and higher. Else it is only aware of the values for pre-Release 12. If the UICC supports the TERMINAL CAPABILITY command (which is mandatory for Release 12 and higher), the terminal shall send a TERMINAL CAPABILITY command indicating the maximum available power supply of the terminal within the range that the UICC is aware of.

UICC suspension can be used by the terminal to suspend the UICC when access is not required for long periods of time, in order to reduce the overall power consumption. When the UICC is suspended, the terminal deactivates the contacts of the UICC, following the sequence specified in clause 4.5.2. The procedure can be used only when it is indicated as supported by the UICC in the UICC Maximum Power Consumption file (EFUMPC). The terminal shall maintain the logical status as before the suspension and it shall resume the UICC for any event for which it had previously registered: this includes events registered with SET UP EVENT LIST or TIMER MANAGEMENT proactive command, as specified in ETSI TS 102 223 [4]. When the terminal needs to resume the UICC, it first performs the initial communication establishment procedures, as described in clause 6. The terminal can optionally check if the content of the EFICCID matches the value used before the UICC was suspended. The terminal sends the SUSPEND UICC command with P1 = '01' and the Resume token received when the UICC was suspended earlier. The resume operation does not have impact on the parameters negotiated as part of the initial communication establishment procedures.

The higher level procedures, and contents and coding of the commands, are given in ETSI TS 102 223 [4]. Procedures relating to the transmission of commands and responses across the terminal-UICC interface are given in this clause. A UICC or terminal supporting CAT shall conform to the requirements given in this clause.

A terminal supporting CAT shall send the TERMINAL PROFILE C-APDU. A UICC supporting CAT shall return the response status words (SW1 SW2) '90 00' or '91 XX'. If any other value is returned, the terminal shall assume that CAT is not supported. In case of proactive command pending, the terminal shall then start the proactive polling procedure with the default value.

During idle mode the terminal shall send STATUS commands to the UICC at intervals no longer than the interval negotiated with the UICC (see ETSI TS 102 223 [4]). During a call the UICC presence detection applies. The default value for the proactive polling is the same as for the presence detection procedure. In case of a UICC supporting LSEs, the terminal shall perform the proactive polling on every LSI where CAT was successfully initialized with the interval negotiated on each specific LSI.

A terminal supporting CAT shall support the commands TERMINAL PROFILE, ENVELOPE, FETCH and TERMINAL RESPONSE.

A terminal supporting CAT shall support the response status words (SW1 SW2) '91 XX' and '93 00'. These responses shall never be used if the terminal does not support CAT.

Application and CAT operation shall be logically independent, both in the UICC and in the terminal. Specifically, this means:

• The currently selected EF and current record pointer in any active application shall remain unchanged, if still valid, as seen by the terminal, irrespective of any CAT activity.
• Between successive CAT related command-response pairs, other application (e.g. USIM) and UICC related command-response pairs can occur. The CAT task status shall remain unchanged by these command-response pairs.

If for any reason the CAT task of the UICC cannot process an ENVELOPE command issued by the terminal at present (e.g. other CAT processes are already running), the UICC can respond with a status response of '93 00'. The terminal may re-issue the command at a later stage. The BUSY status response has no impact on e.g. USIM operation.

The transport protocol provides a mechanism for the UICC to obtain additional processing time (i.e. NULL procedure byte for T = 0 and Work Waiting time extension (WTX) for T = 1) before supplying the response part of a command-response pair, during which time the terminal is unable to send further commands to the UICC. If a CAT activity in the UICC runs for too long, this may prevent the terminal from sending e.g. USIM commands which are time-critical, e.g. INTERNAL AUTHENTICATE. A MORE TIME command is defined in ETSI TS 102 223 [4], which ensures that the USAT task in the UICC gets additional processing time, while at the same time freeing the UICC/terminal interface. The MORE TIME command should be used in preference to the transport protocol specific mechanisms for obtaining additional processing time.