WO2015029559A1

WO2015029559A1 - Communications system

Info

Publication number: WO2015029559A1
Application number: PCT/JP2014/066488
Authority: WO
Inventors: Thibaut Collet; Olivier Dong
Original assignee: Nec Corporation
Priority date: 2013-08-30
Filing date: 2014-06-13
Publication date: 2015-03-05
Also published as: GB201315525D0; GB2517762A

Abstract

There is provided a communication device, which communicates with a universal integrated circuit card (UICC). The communication device sends to the UICC a command relating to a first task. The UICC, in responsive to said first command, sends a response message indicating that the command is being processed. The communication device sends to the UICC a second command relating to a second task before sending a further command relating to the first task. In response to the further command, the UICC sends a further response message relating to the first task (e.g. the results of the first task or a further indication that the task is being processed).

Description

DESCRIPTION

Title of Invention

COMMUNICATIONS SYSTEM Technical Field

[0001]

The present invention relates to a communications system. The invention has particular but not exclusive relevance to wireless communications systems and devices thereof operating according to the European Telecommunications Standards Institute (ETSI) / 3rd Generation Partnership Project (3 GPP) standards or equivalents or derivatives thereof. The invention has particular although not exclusive relevance to controlling communications between a mobile telephone and a Universal Integrated Circuit Card (UICC).

Background Art

[0002]

The latest developments of the 3 GPP standards are referred to as the Long Term Evolution (LTE) of EPC (Evolved Packet Core) network and E-UTRAN (Evolved UMTS Terrestrial Radio Access Network). Under the 3GPP standards, a NodeB (or an eNB in LTE) is the base station via which communications devices connect to a core network and communicate to other communications devices or remote servers. Communications devices might be, for example, mobile communications devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop computers, tablet computers, web browsers, e-book readers and the like. Such mobile (or even generally stationary) devices are typically operated by a user.

[0003]

In order to provide authentication services between the mobile telephone and the network, a UICC module, e.g. in the form of a Subscriber Identity Module (SIM) card, is provided in the mobile telephone. However, such an authentication application is just one of many applications a UICC card can be used for. Such applications may be hosted on the mobile telephone itself and/or hosted remotely (e.g. in the network) and accessed via the mobile telephone.

[0004] The UICC communicates with various applications using protocols defined in the ETSI 102 221, ETSI 102 223, and International Organization for Standardization (ISO) 7816 standards, the contents of which are incorporated herein by reference.

[0005]

The above standards specify that communication between the mobile telephone and the

UICC card is carried using request-response procedures. In particular, the standards also specify that each application communicates with the UICC independently and in parallel using

respective separate and dedicated logical channel. This approach ensures that data exchanged between each application and the UICC (using an application's dedicated logical channel) cannot e accessed by any other application.

[0006]

Further, in paragraphs 8 and 9, ISO 7816-3 describes the two types (T=0 and T=l) of transmission between the mobile telephone and the UICC. Transmission is half duplex as there is only one line to exchange data between the mobile telephone and the UICC (in accordance with ISO 7816-3 paragraph 4.3.3). The mobile telephone is the master and sets the data line as an output or input. The mobile telephone can initiate communication by sending a command to the UICC (data line set to output) and then waits for an answer form the UICC (data line is set as an input). The Terminal cannot send a new command (set data line as an output) before receiving an answer from the UICC.

[0007]

In summary, therefore, the standards specify that only one request/response pair can be processed at any time thus effectively limiting each application's access to the UICC resources to one request at a time (regardless of which application sent the request). In other words, once an application has sent a request to the UICC and whilst a corresponding response from the UICC is not yet sent, none of the applications is able to initiate any further requests, regardless of the fact that each application has an independent channel to the UICC.

Summary of Invention

Technical Problem

[0008]

However, some applications (e.g. non-telecommunication applications, such as banking applications, data encryption applications) require the execution of algorithms (e.g.

cryptographic algorithms) that can potentially take a long time, in the order of tens of seconds. Although the UICC can send so-called 'NULL procedure bytes' to the mobile telephone in order to indicate its need for additional processing time and to prevent expiry of a transaction timer associated with the request, such long processing times may prevent additional commands (such as an "Authenticate" command) from being executed in a timely manner. This may result in the user of the mobile telephone being unable to communicate via the mobile telephone (e.g.

initiate/receive calls, communicate data) whilst such processing intense commands are executed by the UICC.

[0009]

Another similar procedure for obtaining additional UICC processing time, dedicated for the SIM toolkit only, involves the SIM toolkit indicating that it has a new SIM toolkit command to send to a terminal. The terminal responds, as normal, by requesting the command (using a

'Fetch' command). However, instead of sending a normal command when the UICC receives the Fetch command, the UICC instead sends a so-called 'MORE TIME' message to the mobile telephone. The MORE TIME 'command' is really a dummy command which is generated in order to maintain the UICC clock active thereby obtaining additional processing time. However, like the NULL byte message, the use of the MORE TIME command can simply block the link between the terminal and the UICC thereby preventing access to the UICC for other, unrelated, tasks.

[0010]

Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which address or at least partially deal with the above needs.

Solution to Problem

[0011]

Although for efficiency of understanding for those of skill in the art, the invention will be described in detail in the context of 3GPP user equipment (UMTS, LTE), the principles of the invention can be applied to other systems in which applications on (or via) user equipment Communicate with a UICC.

[0012]

In one aspect, the invention provides a mobile communication device for controlling interaction with a universal integrated circuit card (UICC) accessible via said mobile

communication device, the mobile communication device comprising: means for communicating with said UICC via a data line provided between said mobile communication device and said UICC. The communicating means is operable to: send, to said UICC, a first command corresponding to a first task requested by a first application; receive, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; send, to said UICC, a second command corresponding to a second task, different to said first task; receive, from said UICC responsive to receipt of said second command, a second response message relating to said second task; send, to said UICC, a further command relating to said first task, after said second command; and receive, from said UICC responsive to receipt of said further command, a further response message relating to said first task. The mobile communication device comprises means for providing an answer message, relating to said first task, to said first application responsive to a response message indicating that processing of said first task has ended.

[0013]

The data line might comprise a half-duplex data line that is switchable between: i) an output mode, in which said mobile communication device can send a command to said UICC but in which said UICC cannot send a response to said mobile communication device; and ii) an input mode in which said mobile communication device can receive a response from said UICC but in which said mobile communication device cannot send a command to said UICC. The communicating means might be operable to switch the data line to said output mode in response to receiving a response message. The communicating means might be operable to switch the data line to said input mode after sending a command.

[0014]

The communicating means might be operable to send each of said first and said second commands (and to receive each of the associated first and the second response messages) using a respective logical channel uniquely associated with the application that requested the task to which that command corresponds.

[0015]

The further command might comprise a request for a response indicating the result of processing said first task to completion.

[0016]

The communicating means might be operable to send said further command after a predetermined amount of time has elapsed following receipt of said first response message (or following sending of said first command).

[0017]

The predetermined amount of time might be preconfigured prior to said first command being sent. For example, the predetermined amount of time might comprise an amount of time corresponding to a time-out value. Optionally, the first response message might comprise an indication of said predetermined amount of time.

[0018]

The first response message might comprise an indication of processing time (e.g. an estimated remaining processing time) required by said UICC to process said first task to completion. In this case, the communicating means might be operable to send said further command after said indicated processing time has elapsed following receipt of said first response message (or following sending of said first command).

[0019]

The further command might comprise a 'Get CMD Result' message.

[0020]

The further response message might include the results of said first task. In this case, the answer message might comprise the results of said first task.

[0021]

The further response message might comprise a response message indicating that said first command is still being processed by said UICC.

[0022]

: The further command might comprise a request to cancel processing of said first command. In this case, the further response message might comprise a response message indicating that processing of the first command has been cancelled. The answer message might comprise a message indicating that processing of said first task has ended by virtue of cancelling said first task.

[0023]

The second command might correspond to a second task requested by a second application that is different to said first application. The second command might correspond to a second task requested by the first application.

[0024]

The first response might comprise an 'In Progress' message.

[0025]

The first response message might indicate that processing by said UICC is estimated to take longer than a predetermined threshold. For example, the predetermined threshold might be agreed in advance, e.g. by said communicating means sending a command to the UICC preceding said first command.

[0026] The mobile communication device might further comprise means for executing said first (and/or second) application, and said requesting application might be installed locally on said mobile communication device (or remotely on a server).

[0027]

The mobile communication device might comprise at least one of a mobile telephone, a tablet computer, and other user equipment in accordance with the Long Term Evolution (LTE) standard.

[0028]

The mobile communication device might comprise means for indicating, to said UICC and prior to sending said first command, that the mobile communication device is compatible with response messages indicating that a command is being processed by said UICC.

[0029]

In another aspect, the invention provides a universal integrated circuit card (UICC) comprising: means for communicating with a mobile communication device via a data line provided between said mobile communication device and said UICC, wherein said

communicating means is operable to: receive, from said mobile communication device, a first command corresponding to a first task requested by a first application; send, to said mobile communication device responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; receive, from said mobile communication device, a second command corresponding to a second task, different to said first task; send, to said mobile communication device responsive to receipt of said second command, a second response message relating to said second task; receive, from said mobile

communication device, a further command relating to said first task, after said second command; and send, to said mobile communication device responsive to receipt of said further command, a further response message relating to said first task.

[0030]

The UICC might further comprise means for estimating a time required for processing said first task to completion; and means for providing said estimated processing time to said mobile communication device in said first response.

[0031]

The UICC might be operable to receive each of said first and said second commands (and to send each of the associated first and the second response messages) using a respective logical channel uniquely associated with the application that requested the task to which that command corresponds. [0032]

The UICC might include the results of said first task in said further response message.

[0033]

The UICC might comprise means for indicating, to said mobile communication device and prior to receiving said first command, that the UICC is compatible with response messages indicating that a command is being processed by said UICC.

[0034]

The UICC might comprise a universal subscriber identity module (USIM).

[0035]

The invention provides a mobile communication device comprising the above described

UICC.

[0036]

In one aspect, the invention provides a system comprising the above described mobile communication device and the above described UICC.

[0037]

In one aspect, the invention provides a method, performed by a mobile communication device that is operable to communicate with a universal integrated circuit card (UICC) via a data line provided between said mobile communication device and said UICC, for controlling interaction with said UICC accessible via said mobile communication device. The method comprises: sending, to said UICC, a first command corresponding to a first task requested by a first application; receiving, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; sending, to said UICC, a second command corresponding to a second task, different to said first task; receiving, from said UICC responsive to receipt of said second command by the UICC, a second response message relating to said second task; sending, to said UICC, a further command relating to said first task, after said second command; receiving, from said UICC responsive to receipt of said further command by said UICC, a further response message relating to said first task; and providing an answer message, relating to said first task, to said first application responsive to receiving a response message from the UICC indicating that processing of said first task has ended.

[0038]

In one aspect, the invention provides a method performed by a universal integrated circuit card (UICC) operable to communicate with a mobile communication device via a data line provided between said mobile communication device and said UICC. The method comprises: receiving, from said mobile communication device, a first command corresponding to a first task requested by a first application; sending, to said mobile communication device responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; receiving, from said mobile communication device, a second command corresponding to a second task, different to said first task; sending, to said mobile communication device responsive to receipt of said second command, a second response message relating to said second task; receiving, from said mobile communication device, a further command relating to said first task, after said second command; and sending, to said mobile communication device responsive to receipt of said further command, a further response message relating to said first task.

[0039]

communication device, the mobile communication device comprising a processor and a transceiver configured to communicate with said UICC via a data line provided between said mobile communication device and said UICC. The transceiver is operable to: send, to said UICC, a first command corresponding to a first task requested by a first application; receive, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; send, to said UICC, a second command corresponding to a second task, different to said first task; receive, from said UICC responsive to receipt of said second command, a second response message relating to said second task; send, to said UICC, a further command relating to said first task, after said second command; receive, from said UICC responsive to receipt of said further command, a further response message relating to said first task; and provide an answer message, relating to said first task, to said first application responsive to a response message indicating that processing of said first task has ended.

[0040]

In one aspect, the invention provides a universal integrated circuit card (UICC) comprising a processor and a transceiver configured to communicate with a mobile

communication device via a data line provided between said mobile communication device and said UICC. The transceiver is configured to: receive, from said mobile communication device, a first command corresponding to a first task requested by a first application; send, to said mobile communication device responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; receive, from said mobile communication device, a second command corresponding to a second task, different to said first task; send, to said mobile communication device responsive to receipt of said second command, a second response message relating to said second task; receive, from said mobile

[0041]

Aspects of the invention extend to computer program products such as computer readable storage media having instructions stored thereon which are operable to program a programmable processor to carry out a method as described in the aspects and possibilities set out above or recited in the claims and/or to program a suitably adapted computer to provide the apparatus recited in any of the claims.

[0042]

Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the invention independently (or in combination with) any other disclosed and/or illustrated features. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually. Brief Description of Drawings

[0043]

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:

[0044]

[Fig. 1]

Fig.1 illustrates schematically a communications system to which embodiments of the invention may be applied;

[0045]

[Fig. 2]

Fig.2 is a block diagram of a mobile telephone forming part of the system shown in

Fig. l ;

[0046]

[Fig. 3] Fig.3 is a block diagram of a universal integrated circuit card forming part of the system shown in Fig.1 ;

[0047]

[Fig. 4]

Fig.4 is an example timing diagram illustrating a method carried out by components of the mobile telephone shown in Fig.1 ; and

[0048]

[Fig. 5]

Fig.5 is an example timing diagram illustrating another method carried out by components of the mobile telephone shown in Fig.1.

Description of Embodiments

[0049]

Overview

Fig.1 schematically illustrates a communications network 1 in which a mobile device 3

(in this example a mobile telephone), and other communications devices can communicate with each other and/or other communications devices via a wired and/or a wireless connection.

Communication between the devices may be carried out via a base station 5 (e.g. eNB) and a core network 7. As those skilled in the art will appreciate, whilst one mobile telephone 3 and one base station 5 are shown in Fig.1 for illustration purposes, the system, when implemented, will typically include other mobile telephones and other base stations.

[0050]

In this exemplary system, the mobile telephone 3 comprises a UICC 38 and an applications module 47 capable of executing a number of applications (denoted Άρρ # to 'App #N' in Fig.l). Some of the applications might be hosted on the mobile telephone 3, whilst other applications may be hosted remotely, e.g. on an application server 1 1 in the core network 7 (but accessed via the mobile telephone 3). Applications executed by the applications module 47 can communicate with the UICC 38 via the mobile telephone 3 (if required). Using one or more of such applications, the user of the mobile telephone 3 can thus access the services provided by the UICC 38.

[0051]

In this example, the mobile telephone 3 is capable of executing a plurality of applications in parallel, including at least a first application (e.g. 'App #1 ') and a second application (e.g. 'App #2') which can access the UICC 38 via the mobile telephone 3. Whenever one of the executed applications requires processing of a command by the UICC 38 (e.g.

authentication, retrieval of contact data, storing user data, encryption of data, and the like), the mobile telephone 3 sends a command to the UICC 38 on behalf of that application over the channel associated with the application.

[0052]

In order to allow communications between the applications and the UICC 38, the mobile telephone 3 (acting as a terminal in accordance with ISO 7816) operates a half-duplex data line (or data link) to the UICC 38. The mobile telephone 3 acts as a master, and it sets the data line between output and input in accordance with the ISO 7816 standard. Specifically, when the data line is set to output, the mobile telephone 3 is able to send a command (e.g. a message corresponding to an application's request) to the UICC 38 but the UICC 38 is not able to send any messages to the mobile telephone 3 (or the applications) whilst the data link remains in the output mode (i.e. output refers to the direction of communication from the master's point of view). However, whilst the data line is set to input, the UICC 38 is able to (and sometimes it is expected to) send a response to the mobile telephone 3. Since the data line is half-duplex, the mobile telephone 3 is not able to send any command to the UICC 38 whilst the data line is set to input. Since the communication between the mobile telephone 3 (as terminal) and the UICC 38 follow a request-response procedure, once a request is sent to the UICC 38, the data line is set to input so that a corresponding response can be received by the mobile telephone 3. Also, when a response has been received, the data line is set to output again so that a subsequent request can be sent to the UICC 38, if necessary.

[0053]

In this system however, the mobile telephone 3 and the UICC 38 are configured such that an additional request (or additional requests) can be initiated by the mobile telephone 3 even when a request has already been sent to the UICC 38 without a specific response for that request having been received back. Instead, when the UICC 38 receives a request from the terminal, e.g. for a processor intensive task, it is configured to estimate the amount of processing time that is likely required for the requested task and, if the processing time is above a certain threshold, to respond to the request with a response indicating that the task is being processed (but has not yet completed). The UICC 38 then proceeds to process the request in the background. The terminal, on receipt of the response indicating that the task is being processed resets the data line for outputting requests and can then output a further request (e.g. a newly generated or queued request) whilst the original request is still being processed. The new request may then be processed by the UICC 38 in parallel with the original request and if the newly requested task is a relatively processor light task then it may be completed before the original task, and an associated response sent to the terminal. The terminal is advantageously able to request the response to the original request, at an appropriate juncture, after sufficient time has elapsed to allow the UICC 38 to complete the associated processor intensive task. In response to this request for a response to the original request the UICC 38 can then respond with an appropriate response (if the processor intensive task has completed).

[0054]

Accordingly, blocking of the interface between the UICC 38 and the mobile telephone 3 can be avoided even if lengthy processing is required for a request by one of the applications interacting with the UICC 38. The mechanism allows one application to initiate communication with the UICC 38 while another application is awaiting the results from the UICC 38. There is no need to send 'NULL' messages either (to keep the channel alive) to indicate that a request is still being processed by the UICC 38.

[0055]

An additional benefit associated with setting the data link to output mode whilst a command is processed by the UICC 38 is that the processing can be cancelled by the requesting application by sending an appropriate message (e.g. a 'cancel' command) to the UICC 38 over the channel associated with the application. The cancel command in turn reduces the need for unnecessary processing of commands by the UICC 38 and makes the resources of the UICC 38 available for the processing of other commands sooner thereby increasing the overall efficiency of the mobile telephone 3.

[0056]

Mobile Telephone

Fig.2 is a block diagram illustrating the main components of the mobile telephone 3 shown in Fig.l. As shown, the mobile telephone 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5 via one or more antenna 33. The mobile telephone 3 has a controller 37 to control the operation of the mobile telephone 3 and a removable and replaceable subscriber identity module which, in this embodiment, comprises a Universal Integrated Circuit Card (UICC) 38. The UICC 38 is removable from the mobile telephone 3. The controller 37 is associated with a memory 40 and is coupled to the transceiver circuit 31. The mobile telephone 3 might of course have all the usual functionality of a conventional mobile telephone 3 (such as a user interface 35) and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory 40 and/or may be downloaded via the telecommunications network or from a removable data storage device (RJV1D), for example.

[0057]

The controller 37 is configured to control overall operation of the mobile telephone 3, and interaction with the UICC 38, by, in this example, program instructions or software instructions stored within memory 40. As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, a UICC command module 45, and an applications module 47.

[0058]

The communications control module 43 controls the communication between the mobile telephone 3 and the base station 5.

[0059]

The UICC 38 has its own processing capability (not shown) and comprises a local memory 39 that holds a list of applications configured to interact with the UICC 38 and respective associated logical channels used by each application. The local memory 39 also stores information identifying which command has been initiated by which application (e.g. based on an identifier of the application, an identifier of the channel used by the application, and/or the like). Upon receipt of a command from the UICC command module 45 (on behalf of an application via the applications module 47), the UICC 38 estimates the processing time required for the received command and provides this information to the UICC command module 45 in an appropriate response message (such as an 'In progress' message) sent over the logical channel used by the application requesting the processing.

[0060]

The UICC command module 45 manages the interaction with the UICC 38 and access to the information stored in the local memory 39 of the UICC 38 via interfaces defined by 3GPP, ETSI, and/or ISO. The UICC command module 45 facilitates communication between the UICC 38 and the applications (via the applications module 47) and keeps track of estimated processing times for each request based on indication provided by the UICC 38. The UICC command module 45 controls the data link between the mobile telephone 3 and the UICC 38, e.g. by setting it to output or input mode, in accordance with incoming requests from the applications and corresponding responses from the UICC 38. When an application communicates with the UICC 38, the UICC command module 45 uses the appropriate logical channel associated with (reserved for) that application in order to prevent unauthorised access to the application's data by other applications. [0061]

The applications module 47 manages applications installed on (and/or remotely accessible by) the mobile telephone 3 and controls their access to the other modules of the mobile telephone 3, including the UICC 38.

[0062]

UICC

Fig.3 is a block diagram illustrating the main components of the universal integrated circuit card 38 used with the mobile telephone 3 shown in Fig.l. As shown, the UICC 38 has a transceiver circuit 51 that is operable to transmit signals to and to receive signals from the mobile telephone 3 via a terminal interface 52. The UICC 38 has a controller 53 to control the operation of the UICC 38. The controller 53 is associated with a local memory 39 and is coupled to the transceiver circuit 51. Software may be pre-installed in the local memory 39 and/or may be downloaded via the telecommunications network or from a removable data storage device (RMD), for example.

[0063]

The controller 53 is configured to control overall operation of the UICC 38, and interaction with the terminal (and hence the applications), by, in this example, program

instructions or software instructions stored within the local memory 39. As shown, these software instructions include, among other things, a command execution module 55.

[0064]

The command execution module 55 executes the processing of tasks requested by the terminal and provides the results of the processing to the terminal. When it is configured to do so, the command execution module 55 estimates the required processing time and provides an indication of the required processing time to the terminal, for example, in an 'In progress' message.

[0065]

In the above description, the mobile telephone 3 and the UICC 38 are described for ease of understanding as having a number of discrete modules (such as the communications control module, the UICC command module, and the applications module). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these. [0066]

Operation

A more detailed description will now be given (with reference to Fig.4 and 5) of the scenario discussed above where applications communicate with the UICC 38 (via the mobile telephone 3 acting as a terminal) whilst the UICC 38 (using its command execution module 5) is carrying out background processing of an application's request.

[0067]

Fig.4 is an example timing diagram illustrating a method carried out by components of the mobile telephone 3 shown in Fig.1.

[0068]

As can be seen, a number of applications (e.g. Άρρ # and Άρρ #2') are provided (either locally or remotely) via the applications module 47 of the mobile telephone 3.

[0069]

There is a standard (e.g. operating system specific) application programming interface (API) provided between the applications and the other modules of the mobile telephone 3. Thus using the API, each application can also communicate with the UICC 38 (via the UICC command module 45).

[0070]

In this example, the applications module 47 of the mobile telephone 3 provides two applications, denoted 'App #1 ' and Άρρ #2', respectively. The first application (Άρρ #1 ') and the second application ('App #2') access the UICC 38 via the UICC command module 45 of the mobile telephone 3 (denoted 'Terminal').

[0071]

Initially, the first application requires processing by the UICC 38, therefore, it generates and sends, in step S401a, an appropriately formatted request ('Request #Γ) to the UICC command module 45. In turn, the UICC command module 45 assigns a logical channel to the first application (if not already assigned) and then it generates and sends, in step S402a, an appropriately formatted command to the UICC 38 over the logical channel associated with the first application. In this case, it is assumed that the data link between the mobile telephone 3 and the UICC 38 is in the output mode. After sending the command at S302a, the UICC command module 45 sets the data link to input mode so that it can receive messages back from the UICC 38.

[0072] Upon receipt of the command for the first application's request, the command execution module 55 of the UICC 38 estimates the processing time required for completing the request. When it is done, the UICC 38 generates and sends, in step S402b, and appropriately formatted message back to the UICC command module 45, the message indicating that the request is being processed (e.g. an 'In progress' message). The UICC 38 also includes in this message an indication of the estimated processing time required for that request. This message prevents the first application re-sending the same request or initiating another request for the same task, e.g. due to a timeout for the earlier sent request, especially if the earlier request requires extensive processing by the UICC 38 (e.g. such as cryptographic processing). In turn, this may also reduce the load (e.g. the number of messages exchanged) over the data line between the mobile telephone 3 and the UICC 38.

[0073]

Upon receipt of the UICC's 38 message, the UICC command module 45 sets the data link to the UICC 38 to output mode (for example, for the duration of the indicated required processing time) so that other applications are able to communicate with the UICC 38 whilst the first application's request is being processed. Thus, even though the UICC 38 is still processing the first application's request (CMD #1), the mobile telephone 3 does not have to keep the data line in the input mode unnecessarily because the UICC 38 provided an indication of the estimated processing requirement (processing time) for that request (CMD #1).

[0074]

Depending on implementation, the UICC command module 45 may also notify the first application about the request being processed by the UICC 38 (and may also indicate the estimated processing time) by sending a notification message, in step S403, to the applications module 47.

[0075]

In the meantime, as generally shown at step S405, the second application also initiated processing by the UICC 38 by sending an appropriately formatted request ('Request #2') to the UICC command module 45. Although the message at S405 is shown to be sent before the 'In progress' message at S402b, it will be appreciated that 'Request #2' may be sent at any time after the first application's request (but before the response for the first application's request is provided by the UICC 38).

[0076]

Since the data link is set to output mode after receipt (at S402b) of the 'In progress' indication for the first request, the UICC command module 45 is able to process the second application's request without delay, even before completing the on-going request/response procedure(s) with the UICC 38 (e.g. before receiving a response for the first application's request from the UICC 38).

[0077]

Therefore, in response to the second application's request, the UICC command module

45 generates and sends, in step S406a, an appropriately formatted command to the UICC 38 over the logical channel associated with the second application. After sending the command at S406a, the UICC command module 45 sets the data link to input mode again so that it can receive messages back from the UICC 38.

[0078]

Upon receipt of the command for the second application's request, the command execution module 55 of the UICC 38 processes the second application's request (e.g.

substantially in parallel with the first application's request). Although not shown in Fig.3, the command execution module 55 may also estimate the processing time required for completing the second application's request.

[0079]

In this example, the second application's request does not require complex processing by the UICC 38, therefore, the results for this request can be provided almost instantaneously (e.g. before the results for the first application's request are available). Therefore, the UICC 38 generates and sends, in step S406b, an appropriately formatted response back to the UICC command module 45, the message including the results of the processing requested by the second application.

[0080]

In step S407, the UICC command module 45 sends the answer to the second application for the request received at S405. As can be seen in Fig.3, the UICC command module 45 is able to answer the second request even before the first request has been fully processed by the UICC 38.

[0081]

After the indicated time required for processing the first command (CMD #1) has passed, the UICC command module 45 sets the data link to input mode again for receiving the appropriate response to the first application's request over the logical channel associated with the first application. In this example, before setting the data link to input mode, the UICC command module 45 generates and sends (at step S408a) an appropriately formatted message (e.g. a 'Get CMD Result' command) for retrieving the response to the first application's request (that was sent at S402a). The UICC command module 45 includes in this message an identifier of the request (in this example, CMD #1) for which a response is expected. The identifier of the request might comprise an identifier of the command message, the requesting application, and/or the logical channel on which the corresponding command (CMD #1) was sent.

[0082]

Upon receipt of the message at S408a, the UICC 38 retrieves the results for the corresponding command from its command execution module 55 and then it generates and sends, at S408b, an appropriately formatted response (e.g. 'Response #1) including the results for the first application's request. In step S410, the UICC command module 45 sends the answer to the first application for the request that was received at S401a, and sets the data link to the UICC 38 to output mode again so that any further requests (by either application) can be handled without delay.

[0083]

Fig.5 is an example timing diagram illustrating another method carried out by

components of the mobile telephone 3 shown in Fig.1.

[0084]

In this example, the procedure begins by the first application sending, in step S501a, a request ('Request #3') to the UICC command module 45. In turn, the UICC command module 45 generates and sends, in step S502a, an appropriately formatted command to the UICC 38 over the logical channel associated with the first application (whilst the data link is in the output mode). After sending the command at S502a, the UICC command module 45 sets the data link to input mode so that it can receive messages back from the UICC 38.

[0085]

Upon receipt of the command for the first application's request, the UICC 38 generates and sends, in step S502b, and appropriately formatted message back to the UICC command module 45, the message indicating that the request is being processed (e.g. an 'In progress' message). If it can be estimated, the UICC 38 may also include in this message an indication of the estimated processing time required for that request.

[0086]

When the UICC's 38 'In progress' message is received at S502b, the UICC command module 45 sets the data link to the UICC 38 to output mode so that the applications are able to communicate with the UICC 38 whilst the first application's request is being processed.

[0087] Depending on implementation, the UICC command module 45 may also notify the first application about the request being processed by the UICC 38 (and may also indicate the estimated processing time, if known) by sending a notification message, in step S503, to the applications module 47.

[0088]

Since the UICC 38 is not able to send the results of the processing whilst the data link is set to output mode, the UICC command module 45 may check (either periodically or upon expiry of the indicated processing time, if known) whether the UICC 38 has completed processing of the request. In order to do so, the UICC command module 45 generates and sends, at step S506a, an appropriately formatted message (e.g. a 'Get CMD Result' command) for retrieving the response to the first application's request (that was sent at S502a). The UICC command module 45 includes in this message an identifier of the request (in this example, CMD #3) for which a response is expected.

[0089]

In this example, the processing of 'CMD '3' (by the command execution module 55) is not yet complete. Therefore the UICC 38 generates and sends, at S506b, another 'In progress' message (with or without an indication of the estimated time to completion). Although not shown in Fig.3, the UICC command module 45 may check again (either periodically or upon expiry of the indicated processing time, if known) whether the UICC 38 has completed processing of the request by repeating step S506a.

[0090]

After sending the request at S501a, the application sending the request is able to request termination of the processing by the UICC 38 by sending an appropriately formatted message (e.g. 'Cancel' request) identifying the request to be terminated (in this example, 'Request #3'). Termination of a request may be requested, for example, at the expiry of a timer or upon user action.

[0091]

Upon receipt of the message at S507, the UICC command module 45 generates and sends, at S508a, an appropriately formatted message (e.g. 'Cancel' command) to the UICC 38 and identifies in this message the command to be cancelled.

[0092]

The UICC 38 terminates the corresponding command (and discards any result obtained thus far) and sends, at S508b, an appropriately formatted response (e.g. a 'Command cancelled' response) identifying the request being cancelled. Next, in step S510, the UICC command module 45 sends an answer to the cancelled request, the answer indicating that 'Request #3' has been cancelled. In addition to (or instead of) the message at S510, the UICC command module 45 may send a confirmation that the cancel request was successful.

[0093]

Accordingly, the above mechanisms can prevent blocking of the data line between the

UICC 38 and the terminal even if an application's command results in a lengthy processing by the UICC 38. Thus one application is able to initiate communication with the UICC 38 while another application is awaiting processing results from the UICC 38. Further, since the data link is set to output whilst a command is processed by the UICC 38, the application is able to cancel a previously requested task by sending an appropriate 'Cancel' command to the UICC 38.

[0094]

UlCC-terminal interface messages

A more detailed description will now be given of an exemplary implementation of the 'In progress' and 'Get CMD Result' messages that may be exchanged between the mobile telephone 3 and the UICC 38.

[0095]

"In Progress " response

The format of the "In Progress" response may be defined as: SW1 SW2 = 0x94XY where:

SW1 = 0x94 (94 is given as an example, any other values not currently specified by the standards may be used)

SW2 = OxXY

In case of SW2, 'X' indicates the identification associated with the request executed in the background. For example, the value of 'X' may be coded on four bits 'b5' to 'b8'. Ύ' represents a value corresponding to the In Progress Time (IPT), e.g. the expected time to execute the request. IPT is computed by the UICC 38. The value of Ύ' may be coded on four bits 'bl ' to 'b4'. The coding of 'X' and 'Y' is further illustrated in Table 1 below.

Table 1

As an example, this IPT could be a multiple of:

a) WWT for protocol T=0 (ISO 7816-3, clause 8.2). For example 2^Y*WWT or

( Y+ 1 )* WWT. With Y=0, IPT = WWT wherein WWT stands for Work Waiting Time, which indicates the maximum delay between two subsequent characters sent by the UICC 38 to the Terminal (or vice versa) on the link between them. In this example, T=0 is the half-duplex transmission of asynchronous characters protocol as defined by ISO 7816.

b) BWT for protocol T=l (ISO 7816-3, clause 9.5.3.2). For example 2^Y*BWT or

(Y+1)*BWT. With Y=0, IPT = BWT i.e. can replace a WTX request,

wherein BWT stands for Block Waiting Time, which indicates the maximum delay between the last character of a block received by the UICC 38 and the first character of the next block sent by the UICC 38. In this example, T=l is the half-duplex asynchronous transmission of blocks protocol as defined by ISO 7816.

Note: the UICC 38 may be configured not to compute the IPT. In that case, Ύ' may be set to OxF, and it's up to the mobile telephone 3 to define a maximum allowed processing time (which may be standardized or vendor specific)

[0096]

'Get CMD Result ' command

The format of the command for obtaining results from the UICC 38 may be defined as follows (using parameters specified in the ISO 7816-4 standard):

• CLA: identical to the CLA of CMD

• INS: OxCl (value given as an example, any other values not currently specified by the specs could be used)

• PI : set to the identifier of the request being executed in the background (e.g. set to the value of 'X' of the "In Progress" response described above)

• P2: Set to 0. For future use

• Lc: not used

• Data: not used

• Le: identical to the "Le" parameter of the corresponding command (or "0x00" if "Le" was not present in the command)

wherein:

'CLA' represents the 'class byte' of a command, which indicates e.g. the logical channel number for the given command (and the corresponding response);

'INS' represents the 'instruction byte', which indicates the action to do (e.g. read, update, etc.); 'PI ' and 'P2' are 'parameters bytes', the content of which depends on the INS byte. These bytes give more details about what to do (e.g. what record to read if INS=READ RECORD);

'Lc' represents the length of the data field of a command (e.g. data sent by the terminal to the UICC 38);

'Data' : data sent by the terminal to the UICC 38 in the command; and

'Le' represents the maximum number of bytes expected in the data field of the response from the UICC 38.

[0097]

Response to the 'Get CMD Result ' command

In response to the 'Get CMD Result' command, one or more of the following responses may be given by the UICC 38:

• The expected result for the corresponding command (CMD)

• another "In Progress" response if more time is needed (e.g. if the processing is not yet complete)

• an error code

In order to ensure backward compatibility, the mobile telephone 3 may indicate to the UICC 38 whether or not it supports the 'In Progress' and/or 'Get CMD Result' procedures.

[0098]

For example, this can be achieved using the existing "Terminal Capability" command and adding the mobile telephone's 3 compatibility information to the additional interfaces support data within the "Terminal Capability" command (clause 1 1.1.19.2.3 of ETSI TS

102.221). In this case, the coding of additional interfaces may be achieved e.g. as illustrated in

Table 2.

Table 2

[0099]

In another example, the mobile telephone's 3 compatibility information is indicated to the UICC 38 using the Answer to Reset (ATR) / Protocol Parameter Selection (PPS) procedure (as specified in the ISO 7816-4 standard)! In summary, ATR is the initial set of data sent by the UICC 38 to the terminal when the UICC is reset/powered up. PPS is a procedure following the ATR which allows the UICC 38 and the Terminal to determine the parameters to use for their subsequent operations. In this example, the UICC 38 may indicate in the ATR with TBi (i>2) after T=15 (wherein TBi is a specific byte in the ATR, as described in clause 6.3.3 of TS

102.221) if it supports 'In Progress' / 'Get CMD Result' messages and the mobile telephone 3 may use that PPS procedure with a PPS2 byte (wherein PPS2 is specific byte in the PPS, as described in clause 6.4 of ETSI TS 102.221) to indicate if it supports the 'In Progress' / 'Get CMD Result' messages.

[0100]

The coding of TBi (i>2) after T=15 and the PPS2 byte may be implemented e.g. as illustrated in Table 3.

Table 3

[0101]

Modifications and Alternatives

Detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

[0102]

In the above description, the UICC estimates the processing required for completing a task requested by an application. It will be appreciated that the processing time may depend, for example, on the capabilities of the UICC (such as processor characteristics, memory size, and the like). The processing time may also depend on the type of task being requested. For example, for tasks that are likely to take long (such as data encryption/decryption operations), based on e.g. the size of the data to be processed, the size of the cryptographic key used (if any), the algorithm used to process the task, and the like, the UICC is able to estimate the approximate time required to completion of a given task. However, the UICC may not be configured to compute an estimate of processing time.

[0103]

Similarly to the UICC, the mobile telephone may be configured to estimate the required processing time for a requested task, regardless whether or not the UICC is capable to do so. Further, the mobile telephone may be configured with a maximum allowed processing time for a particular task (which may be standardized and/or vendor specific), after which it proceeds to obtain the results for that task from the UICC (if available).

[0104]

In the above description of the estimation of the required processing time, the UICC provides an explicit indication of the required processing time to the mobile telephone. However, it will be appreciated that such indication may also be done implicitly, e.g. by sending the 'In progress' message instead of the results of the processing. Further, it will also be appreciated that a threshold for the minimum processing duration that needs to be indicated by the UICC may be fixed in advance, e.g. set by the terminal in an earlier request (possibly by application type and/or class).

[0105]

It will be appreciated that the estimation of the processing time and/or the time before the mobile telephone attempts to get the results from the UICC may be dependent on the task and/or the requesting application (e.g. an identity and/or type thereof).

[0106]

In the above description, the mobile telephone is described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0107]

In the above embodiments, a number of software modules were described. As those Skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the mobile telephone as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the mobile telephone in order to update it functionalities.

[0108]

Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0109]

This application is based upon and claims the benefit of priority from United Kingdom Application No.1315525.4, filed on August 30, 2013, the disclosure of which is incorporated herein in its entirety by reference.

Reference Signs List

[0110]

1 NETWORK

3 MOBILE TELEPHONE

5 BASE STATION

7 CORE NETWORK

11 APPLICATION SERVER

31 TRANSCEIVER CIRCUIT

33 ANTENNA

35 USER INTERFACE

37 CONTROLLER

38 UNIVERSAL INTEGRATED CIRCUIT CARD (UICC)

39 MEMORY

40 MEMORY

41 OPERATING SYSTEM

42 COMMUNICATIONS CONTROL MODULE

45 UICC COMMAND MODULE

47 APPLICATIONS MODULE

51 TRANSCEIVER CIRCUIT

52 TERMINAL INTERFACE

53 CONTROLLER

55 COMMAND EXECUTION MODULE

Claims

[Claim 1]

A mobile communication device for controlling interaction with a universal integrated circuit card, UICC, accessible via said mobile communication device, the mobile communication device comprising:

means for communicating with said UICC via a data line provided between said mobile communication device and said UICC, wherein said communicating means is operable to:

send, to said UICC, a first command corresponding to a first task requested by a first application;

receive, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC; send, to said UICC, a second command corresponding to a second task, different to said first task;

receive, from said UICC responsive to receipt of said second command, a second response message relating to said second task;

send, to said UICC, a further command relating to said first task, after said second command;

receive, from said UICC responsive to receipt of said further command, a further response message relating to said first task; and

means for providing an answer message, relating to said first task, to said first application responsive to a response message indicating that processing of said first task has ended.

[Claim 2]

The mobile communication device according to claim 1 , wherein said data line comprises a half-duplex data line that is switchable between: i) an output mode, in which said mobile communication device can send a command to said UICC but in which said UICC cannot send a response to said mobile communication device; and ii) an input mode in which said mobile communication device can receive a response from said UICC but in which said mobile communication device cannot send a command to said UICC.

[Claim 3] The mobile communication device according to claim 2, wherein said communicating means is operable to switch said data line to said output mode in response to receiving a response message.

[Claim 4]

The mobile communication device according to claim 2 or 3, wherein said

communicating means is operable to switch said data line to said input mode after sending a command.

[Claim 5]

The mobile communication device according to any one of claims 1 to 4, wherein said communicating means is operable to send each of said first and said second commands (and to receive each of the associated first and the second response messages) using a respective logical channel uniquely associated with the application that requested the task to which that command corresponds.

[Claim 6]

The mobile communication device according to any one of claims 1 to 5, wherein said further command is a request for a response indicating the result of processing said first task to completion.

[Claim 7]

The mobile communication device according to any one of claims 1 to 6, wherein said communicating means is operable to send said further command after a predetermined amount of time has elapsed following receipt of said first response message (or following sending of said first command).

[Claim 8]

The mobile communication device according to claim 7, wherein said predetermined amount of time is preconfigured prior to said first command being sent.

[Claim 9]

The mobile communication device according to claim 8, wherein said predetermined amount of time comprises an amount of time corresponding to a time-out value.

[Claim 10]

The mobile communication device according to any one of claims 1 to 6, wherein said first response message comprises an indication of processing time (e.g. an estimated remaining processing time) required by said UICC to process said first task to completion.

[Claim 11]

The mobile communication device according to claim 10, wherein said communicating means is operable to send said further command after said indicated processing time has elapsed following receipt of said first response message (or following sending of said first command).

[Claim 12]

The mobile communication device according to any one of claims 6 to 11, wherein said further command comprises a 'Get CMD Result' message.

[Claim 13]

The mobile communication device according to any one of claims 6 to 12, wherein said further response message includes the results of said first task.

[Claim 14]

The mobile communication device according to claim 13, wherein said answer message comprises the results of said first task.

[Claim 15]

The mobile communication device according to any one of claims 1 to 12, wherein said further response message comprises a response message indicating that said first command is still being processed by said UICC.

[Claim 16]

The mobile communication device according to any one of claims 1 to 5, wherein said further command is a request to cancel processing of said first command.

[Claim 17] The mobile communication device according to claim 16, wherein further response message comprises response message indicating that processing of the first command has been cancelled.

[Claim 18]

The mobile communication device according to claim 17, wherein said answer message comprises a message indicating that processing of said first task has ended by virtue of cancelling said first task.

[Claim 19]

The mobile communication device according to any one of claims 1 to 18, wherein said second command corresponds to a second task requested by a second application that is different to said first application.

[Claim 20]

The mobile communication device according to any one of claims 1 to 18, wherein said second command corresponds to a second task requested by the first application.

[Claim 21]

The mobile communication device according to any one of claims 1 to 20, wherein said first response comprises an 'In Progress' message.

[Claim 22]

The mobile communication device according to any one of claims 1 to 21 , wherein said first response message indicates that processing by said UICC is estimated to take longer than a predetermined threshold.

[Claim 23]

The mobile communication device according to claim 22, wherein said predetermined threshold is agreed in advance, e.g. by said communicating means sending a command to the UICC preceding said first command.

[Claim 24] The mobile communication device according to any one of claims 1 to 23, further comprising means for executing said first (and/or second) application, wherein said requesting application is installed locally on said mobile communication device (or remotely on a server).

[Claim 25]

The mobile communication device according to any one of claims 1 to 24, comprising at least one of a mobile telephone, a tablet computer, and other user equipment in accordance with the Long Term Evolution, LTE, standard.

[Claim 26]

The mobile communication device according to any one of claims 1 to 25, comprising means for indicating, to said UICC and prior to sending said first command, that the mobile communication device is compatible with response messages indicating that a command is being processed by said UICC.

[Claim 27]

A universal integrated circuit card, UICC, comprising:

means for communicating with a mobile communication device via a data line provided between said mobile communication device and said UICC, wherein said communicating means is operable to:

receive, from said mobile communication device, a first command corresponding to a first task requested by a first application;

send, to said mobile communication device responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC;

receive, from said mobile communication device, a second command corresponding to a second task, different to said first task;

send, to said mobile communication device responsive to receipt of said second command, a second response message relating to said second task;

receive, from said mobile communication device, a further command relating to said first task, after said second command; and

send, to said mobile communication device responsive to receipt of said further command, a further response message relating to said first task.

[Claim 28]

The UICC according to claim 27, further comprising means for estimating a time required for processing said first task to completion; and means for providing said estimated processing time to said mobile communication device in said first response.

[Claim 29]

The UICC according to any according to claim 27 or 28, wherein said data line comprises a half-duplex data line that is switchable between: i) an output mode, in which said mobile communication device can send a command to said UICC but in which said UICC cannot send a response to said mobile communication device; and ii) an input mode in which said mobile communication device can receive a response from said UICC but in which said mobile communication device cannot send a command to said UICC.

[Claim 30]

The UICC according to claim 29, wherein said mobile communication device is operable to switch said data line to said output mode in response to receiving a response message from the UICC.

[Claim 31]

The UICC according to any one of claims 27 to 30, wherein said mobile communication device is operable to switch said data line to said input mode after said mobile communication device sending a command.

[Claim 32]

The UICC according to any one of claims 27 to 31 , wherein said communicating means is operable to receive each of said first and said second commands (and to send each of the associated first and the second response messages) using a respective logical channel uniquely associated with the application that requested the task to which that command corresponds.

[Claim 33]

The UICC according to any one of claims 27 to 32, wherein said further command is a request for a response indicating the result of processing said first task to completion.

[Claim 34] The UICC according to any one of claims 27 to 33, wherein said communicating means is operable to receive said further command after a predetermined amount of time has elapsed following sending of said first response message.

[Claim 35]

The UICC according to claim .34; wherein said predetermined amount of time is preconfigured prior to said first command being sent by the mobile communication device.

[Claim 36]

The UICC according to any one of claims 27 to 33, wherein said first response message comprises an indication of processing time (e.g. an estimated remaining processing time) required by said UICC to process said first task to completion.

[Claim 37]

r

The UICC according to claim 36, wherein said communicating means is operable to receive said further command after said indicated processing time has elapsed following receipt of said first response message.

[Claim 38]

The UICC according to any one of claims 33 to 37, wherein said further command comprises a 'Get CMD Result' message.

[Claim 39]

The UICC according to any one of claims 33 to 38, wherein said further response message includes the results of said first task.

[Claim 40]

The UICC according to any one of claims 27 to 38, wherein said further response message comprises a response message indicating that said first command is still being processed by said UICC.

[Claim 41]

The UICC according to any one of claims 27 to 32, wherein said further command is a request to cancel processing of said first command.

[Claim 42]

The UICC according to claim 41, wherein further response message comprises response message indicating that processing of the first command has been cancelled.

[Claim 43]

The UICC according to any one of claims 27 to 42, wherein said second command corresponds to a second task requested by a second application that is different to said first application.

[Claim 44]

The UICC according to any one of claims 27 to 42, wherein said second command corresponds to a second task requested by the first application.

[Claim 45]

The UICC according to any one of claims 27 to 44, wherein said first response comprises an 'In Progress' message.

[Claim 46]

The UICC according to any one of claims of 27 to 45, wherein said first response message indicates that processing by said UICC is estimated to take longer than a predetermined threshold.

[Claim 47]

The UICC according to claim 46, wherein said predetermined threshold is agreed in advance, e.g. by said mobile communication device sending a command to the UICC preceding said first command.

[Claim 48]

The UICC according to any one of claims 27 to 47, comprising a universal subscriber identity module, USIM.

[Claim 49] The UICC according to any one of claims 27 to 48, comprising means for indicating, to said mobile communication device and prior to receiving said first command, that the UICC is compatible with response messages indicating that a command is being processed by said UICC.

[Claim 50]

A mobile communication device comprising a universal integrated circuit card, UICC, according to any one of claims 27 to 49.

[Claim 51]

A system comprising a mobile communication device according to any one of claims 1 to 26 and a universal integrated circuit card, UICC, according to any one of claims 27 to 49.

[Claim 52]

A method, performed by a mobile communication device that is operable to

communicate with a universal integrated circuit card, UICC, via a data line provided between said mobile communication device and said UICC, for controlling interaction with said UICC accessible via said mobile communication device, the method comprising:

sending, to said UICC, a first command corresponding to a first task requested by a first application;

receiving, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC;

sending, to said UICC, a second command corresponding to a second task, different to said first task;

receiving, from said UICC responsive to receipt of said second command by the UICC, a second response message relating to said second task;

sending, to said UICC, a further command relating to said first task, after said second command; receiving, from said UICC responsive to receipt of said further command by said UICC, a further response message relating to said first task; and

providing an answer message, relating to said first task, to said first application responsive to receiving a response message from the UICC indicating that processing of said first task has ended.

[Claim 53] A method performed by a universal integrated circuit card, UICC, operable to communicate with a mobile communication device via a data line provided between said mobile communication device and said UICC, the method comprising:

receiving, from said mobile communication device, a first command corresponding to a first task requested by a first application;

sending, to said mobile communication device responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC;

receiving, from said mobile communication device, a second command corresponding to a second task, different to said first task;

sending, to said mobile communication device responsive to receipt of said second command, a second response message relating to said second task;

receiving, from said mobile communication device, a further command relating to said first task, after said second command; and

sending, to said mobile communication device responsive to receipt of said further command, a further response message relating to said first task.

[Claim 54]

A mobile communication device for controlling interaction with a universal integrated circuit card, UICC, accessible via said mobile communication device, the mobile communication device comprising a processor and a transceiver configured to communicate with said UICC via a data line provided between said mobile communication device and said UICC, wherein said transceiver is operable to:

send, to said UICC, a first command corresponding to a first task requested by a first application; receive, from said UICC responsive to receipt of said first command, a first response message indicating that said first command is being processed by said UICC;

send, to said UICC, a second command corresponding to a second task, different to said first task;

send, to said UICC, a further command relating to said first task, after said second command; receive, from said UICC responsive to receipt of said further command, a further response message relating to said first task; and

provide an answer message, relating to said first task, to said first application responsive to a response message indicating that processing of said first task has ended.

[Claim 55]

A universal integrated circuit card, UICC, comprising a processor and a transceiver configured to communicate with a mobile communication device via a data line provided between said mobile communication device and said UICC, wherein the transceiver is configured to:

[Claim 56]

A computer implementable instructions product comprising computer implementable instructions for causing a programmable communications device to perform the method according to claim 52 or 53.