System for communicating in a contact-less manner, and corresponding removable chip card, terminal and method

A system for communicating via contact-less chip with an external contact-less communicating device comprises a removable chip card, a contact-less communicating chip and a terminal. The contact-less chip is carried by a flexible medium. A chip of the card is coupled, via a card connector, to the contact-less communicating chip, and a microprocessor of the terminal. The card chip is configured to act as an intermediary entity between the contact-less communicating chip and the terminal microprocessor. A card chip microprocessor exchanges data with the contact-less chip by using a first data communication protocol. The card chip microprocessor exchanges data with the terminal microprocessor by using a second data communication protocol. The terminal microprocessor is configured to send, through the card chip, to the contact-less communicating chip, data that is previously encapsulated within first communication protocol data that is itself encapsulated within second communication protocol data.

FIELD OF THE INVENTION

The invention relates, in a general manner, to a system for communicating in a contact-less manner.

Furthermore, the invention also pertains to a removable chip card for communicating in a contact-less manner.

Moreover, the invention concerns, as well, a terminal for communicating in a contact-less manner.

Finally, the invention relates, in a general manner, to a method for communicating in a contact-less manner.

Within the present description, the adjective “contact-less” used within the expression “contact-less manner” means notably that a device (as a communicating system) communicates, via a short range radio-frequency link, with an external device by using, for example, International Organization Standardization/International Electrotechnical Commission (or ISO/IEC) 14 443 specifications, a Ultra High Frequency RadioFrequency IDentification (or UHF RFID) technology or the like.

Likewise, the expression “a removable chip card” is a removable medium carrying an electronic object that is intended to communicate with the outside world.

STATE OF THE ART

A known solution for communicating in a contact-less manner is based upon a Near Field Communication (or NFC) enabled handset, such as a mobile telephone. The NFC enabled handset comprises an NFC chip soldered on its Printed Circuit Board (or PCB). The NFC chip is connected to, on the one hand, an antenna configured to exchange data, through a short range radio-frequency signal, with an external contact-less communicating device, and, on the other hand, a handset microprocessor.

However, if no NFC chip is soldered on the PCB handset, then the handset is not able to communicate data with an external contact-less communicating device.

Thus, there is a need to transform a handset, as user terminal, into an NFC enabled handset.

SUMMARY OF THE INVENTION

The invention proposes a solution for satisfying the just hereinabove specified need by providing a system for communicating in a contact-less manner. The system comprises a removable chip card, a contact-less communicating chip and a terminal.

According to the invention, the contact-less communicating chip being carried by a flexible medium, the chip of the card being coupled to, on the one hand, the contact-less communicating chip, and, on the other hand, a microprocessor of the terminal, the card chip is adapted to act as an intermediary entity between the contact-less communicating chip and the terminal microprocessor. And the terminal microprocessor is adapted to communicate, through the card chip, with the contact-less communicating chip.

The principle of the invention consists in a card chip that is connected to a contact-less communicating chip born by a flexible medium and a terminal microprocessor, so that the card chip is interposed in a communication between the contact-less communicating chip and the terminal microprocessor.

The card chip is used as a router and a proxy device that interfaces between the contact-less communicating chip and the terminal microprocessor. More exactly, the card chip receives data originating from the contact-less communicating chip and sends data to the terminal microprocessor and/or conversely, i.e. receives data originating from the terminal microprocessor and sends data to the contact-less communicating chip.

The terminal microprocessor communicates thus, through the card chip, with the contact-less communicating chip.

Due to an interconnection of the contact-less communicating chip with the card chip connected to the terminal microprocessor, the invention system allows to transform the terminal into a contact-less communicating terminal.

The invention system is therefore convenient for such a terminal user who does not need to acquire a terminal originally equipped with a contact-less communicating chip that is soldered on its PCB.

It is to be noted that contact-less communicating chip is not connected to the terminal microprocessor.

According to an additional aspect, the invention is a removable chip card for communicating in a contact-less manner. The chip of the card is likely to cooperate with a contact-less communicating chip and a terminal.

According to the invention, the contact-less communicating chip being carried by a flexible medium, the chip of the card being coupled to, on the one hand, the contact-less communicating chip, and on the other hand, a microprocessor of the terminal, the card chip is adapted to act as an intermediary entity between the contact-less communicating chip and the terminal microprocessor.

The card may have different form factors.

The card may be of different types, such as a Subscriber Identity Module (or SIM) type card, a Secure Digital (or SD) type card, a micro SD type card, a Multi-Media Card (or MMC) or other(s).

According to still an additional aspect, the invention is a terminal for communicating in a contact-less manner. The terminal is likely to cooperate with a contact-less communicating chip and a chip of a removable card.

According to the invention, the contact-less communicating chip being carried by a flexible medium, the chip of the card being coupled to, on the one hand, the contact-less communicating chip, and on the other hand, a microprocessor of the terminal, the terminal microprocessor is adapted to communicate, through the card chip, with the contact-less communicating chip.

As terminal, it may be, for example, a mobile telephone, a smart phone (i.e. a mobile phone with a Personal Digital Assistant (or PDA) capability), a set-top box, a Personal Computer (or PC), a tablet computer, a desktop computer, a laptop computer, an audio-player, a video-player, a media-player, a game console, a netbook and/or a PDA.

According to still an additional aspect, the invention is a method for communicating in a contact-less manner.

According to the invention, a contact-less communicating chip being carried by a flexible medium, a chip of the card being coupled to, on the one hand, the contact-less communicating chip, and, on the other hand, a microprocessor of a terminal, the contact-less communicating chip and the terminal microprocessor communicate through the card chip, as an intermediary entity.

DETAILED DESCRIPTION

Herein under is considered a smart card, as a removable chip card, coupled to a mobile telephone, as a terminal.

However, instead of a removable chip card, it may also be a dongle, as a removable chip medium.

Likewise, instead of a mobile telephone, as a terminal, it may be another user terminal, such as a smart phone, a set-top box, a PC, a tablet computer, a desktop computer, a laptop computer, an audio-player, a video-player, a media-player, a game console, a netbook and/or a PDA.

Naturally, the herein below described embodiment is only for exemplifying purposes and is not considered to reduce the scope of the present invention.

The system10, as an NFC enabled terminal, includes a flexible tape12which carries an NFC chip122, a Subscriber Identity Module (or SIM) type card14and a mobile telephone16, as terminal.

For a sake of clarity and conciseness, the NFC chip122, the SIM type card14, the mobile telephone16are termed hereinafter the CLF (acronym for “Contact-Less Front-end”)122, the card14and the phone16respectively.

A housing of the phone16contains, among others, a battery (not represented), electronic components relating to the phone16, the flexible tape12, as an add-on removable element, and the card14.

The flexible tape12is constituted by an insulating material, such as a plastic material.

The flexible tape12carries the CLF122, one connector (not represented), and preferably a short-range antenna124.

The connector of the flexible tape12is inserted between a corresponding card connector142and a corresponding phone16connector (not represented) with eight electrical contacts termed C1to C8. The connector of the flexible tape12is thus sandwiched between the card connector142and the phone16connector.

A first side of the connector of the flexible tape12is provided with eight contacts that are compliant with the International Organization Standardization (or ISO) 7816, namely C1, for a supplying signal (or Vcc), C2, for a ReSeT (or RST) signal, C3for a CLocK (or CLK) signal, C4for a Reserved Future Use (or RFU), C5, for a ground signal (or GND), C6, for another supplying signal (or Vpp), C7for an Input/Output (or I/O) signal, and C8for RFU. Among the eight contacts, only four contacts, namely C2, C3, C5, and C7are connected, via four corresponding holes filled with electrically conductive material, to corresponding ISO 7816 contacts of a second side of the connector of the flexible tape12.

The second side of the connector of the flexible tape12is connected to the card connector142to corresponding ISO 7816 contacts, through a first link132, namely C1, and a second link134, namely C5, and, through a third bi-directional link136, such as a Single Wire Protocol (or SWP) link, namely C6. The other five ISO 7816 contacts, namely C2, C3, C4, C7and C8of the second side of the connector of the flexible tape12are insulated, i.e. are not connected, with respect to the CLF122.

The CLF122is connected, through the three links132,134and136of the first side of the connector of the flexible tape12, to a chip carried by the card14, as chip medium.

Thus, the phone16connector is connected, through the connector of the flexible tape, to the card connector142, for only four signals, namely the RST, the CLK, the GND and the I/O signal.

The CLF122is insulated from a phone16I/O interface (not represented) and therefore not connected to a phone microprocessor (not represented).

According to another embodiment (not represented), instead of being carried by a single medium, the CLF122, the connector, and the short-range radio antenna124are carried by two distinct and separate media. The CLF122and the connector are carried by a medium while the short-range radio antenna124is carried by another medium. The short-range radio antenna124is connected to the CLF122through either the connector or another connector.

The CLF122includes, in particular, a microprocessor(s) (not represented), as means for processing data, one memory(ies) (not represented), as means for storing data, and at least one I/O interface (not represented) for exchanging data with the outside world, which are internally linked together through a data and control bus (not represented).

The CLF122is connected to the short-range antenna124.

The short-range antenna124is configured, so as to exchange, through a short-range radiofrequency link, with an external entity, data transported by a short-range radio-frequency signal.

The short range radiofrequency is, for example, 13.56 MHz.

The CLF122is adapted to control a powering of the card14chip.

In a reader mode, i.e. when the system10also powers an external Contact-Less communicating Device (not represented) (or CLD), the CLF122receives power from the phone16battery, the CLF122powers the CLD by sending a short range radio-frequency signal. The card14chip and the electronic components of the phone16are powered by the phone16battery.

In a card emulation mode (or transponder mode), i.e. when the system10is powered at least in part by an external Contact-Less communicating Reader (or CLR) (not represented), the CLF122receives power from the CLR and provides power only, through the first and second links132,134, to the card14chip. The electronic components relating to the phone16are powered by the phone16battery.

In both modes, namely in the reader mode and in the card emulation mode, the CLF122communicates only with the card14chip, as its single interlocutory, through the third link136. The CLF122exchanges with the card14chip by implementing a protocol of the Host Controller Interface (or HCI) type, as high level protocol, i.e. a protocol used for exchanging from an application run by the CLF microprocessor to an application run by a card14microprocessor (not represented).

The application run by the card14microprocessor may be written in an object-oriented language, such as Java or Javacard, also termed applet when developed in Java.

The CLF122plays a role of a modulator-demodulator (or modem) for the system10, i.e. a device that may:

modulate an analogical carrier signal to encode digital information received from the card14to be transmitted, over the short-range antenna124, to an external contact-less communicating device (not represented); and/or

demodulate a received analogical carrier signal to decode encoded digital information that is received, over the short-range antenna124, from an external contact-less communicating device (not represented).

The system10is adapted to communicate, in a contact-less manner, with an external contact-less communicating device.

The external contact-less communicating device may be either a CLR or a CLD.

The CLD may be an RFID tag that stores data, such as an Uniform Resource Identifier (or URI), an Uniform Resource Locator(s) (or URL), an Internet Protocol (or IP) address and/or a phone number.

The card14is coupled to, on a first side, the CLF122, and, on a second side, the phone16microprocessor.

The card14is a SIM type card (not represented), such as a SIM card, a UICC (acronym for “Universal Integrated Circuit Card”) card, a CSIM (for “CDMA Subscriber Identity Module”) card, a USIM (for “Universal Subscriber Identity Module”) card, a RUIM (for “Removable User Identification Module”) card, an ISIM (for “Internet protocol multimedia Services Identity Module”) card and/or the like.

The card14incorporates an Integrated Circuit (or IC) or chip (not represented).

According to one important feature of the invention, the card14chip is adapted to act as an intermediary entity between the CLF122and the phone16microprocessor.

The card14chip comprises at least one microprocessor (not represented), as data processing means, at least one memory (not represented), as data storing means, and at least two I/O interfaces (not represented) for communicating with the exterior of the card14chip, which are all linked together through a control and data bus.

The card14chip I/O interfaces are used for receiving data from and sending data to outside, notably, through the CLF I/O interface, with the CLF122and, through a phone I/O interface, with the phone16.

A first card14chip I/O interface includes an I/O interface over a SWP using preferably an HCI, as high level protocol, i.e. a protocol used for exchanging between an application run by the card14chip microprocessor and an application run by the CLF122.

A second card14chip I/O interface includes an ISO 7816 type interface using preferably an Application Protocol Data Unit (or APDU) type protocol, as high level protocol, i.e. a protocol used for exchanging between an application run by the card14chip microprocessor and an application run by the phone16microprocessor.

Alternately, instead of an APDU type protocol, the second card I/O interface may include an Internet Protocol (or IP) type interface, a Mass Storage type interface, a Universal Serial Bus (or USB) type interface, a Secure Digital (or SD) type interface, a Multi-Media Card (or MMC) type interface, so as to let communicate the card14microprocessor and the phone16microprocessor.

The card14chip memory can be constituted by one or several EEPROM (for “Electrically Erasable Programmable Read-Only Memory”), one or several ROM (for “Read Only Memory”), one or several Flash memories, and/or any other memory(ies) of different types, like one or several RAM (for “Random Access Memory”).

The card14chip memory stores, preferably in a secure manner, data relating to a user, such as an identifier relating to a card user, like an International Mobile Subscriber Identity (or IMSI), an encryption algorithm, a decryption algorithm, a private key allowing the user to securely exchange data with an entity that is external to the card14, and/or a public key associated with the private key. The private key is used for encrypting data to be exchanged with the external entity.

The card14chip memory stores preferably, besides an Operating System (or OS), at least one application, termed proxy application, accessible through the CLF122and the phone16microprocessor.

According to such a corresponding embodiment, the card14chip memory stores a JVM that interprets and executes the proxy application.

The proxy application allows, when executed by the card14microprocessor, to discuss, on the hand, with the CLF122and, on the other hand, with the phone16microprocessor, so as to let communicate the CLF122and the phone16microprocessor.

The card14chip microprocessor controls and communicates with all the components of the card14chip, such as the card14chip memory to read it and/or write into it.

The card14chip microprocessor controls a data exchange, through the card14I/O interface, with outside of the card14chip, notably the phone16and the CLF122.

The card14chip microprocessor executes preferentially, besides the OS, the proxy application for exchanging data, on the one hand, with the CLF122by using a first data communication protocol and, on the other hand, with the phone16by using a second data communication protocol.

The proxy application is able to convert data transmitted with the first data communication protocol and originating from the CLF122into data to be transmitted with the second data communication protocol and intended to the phone16microprocessor.

Conversely, the proxy application is able to convert data transmitted with the second data communication protocol and originating from the phone16microprocessor into data to be transmitted with the first data communication protocol and intended to the CLF122.

The phone16includes at least one microprocessor (not represented), at least one memory (not represented) and at least one I/O interface (not represented).

The phone I/O interface includes an I/O interface for exchanging data, via a bi-directional contact link15, through a corresponding card I/O interface, with the card14microprocessor.

The phone I/O interface may comprise a radio interface for exchanging, through an antenna166, data with a mobile radio-communication network (not represented).

The phone I/O interface comprises preferably a display screen162, a keyboard164, and a phone loudspeaker (not represented), as Man Machine Interface (or MMI).

The phone microprocessor processes data originating from and/or intended to any internal component and data originating from and/or any external device through the phone I/O interface.

The phone16microprocessor executes, besides an OS, an NFC application(s) supported by the phone16, so as to offer to the phone user corresponding NFC service(s).

The NFC service(s) may encompass a transport service(s), a wallet service(s), a mobile banking service(s), and/or any other service accessible through an NFC type communication technology.

According to an important feature of the invention, the phone16microprocessor is adapted to communicate, through the card14chip, with the CLF122.

The phone16microprocessor executes an application, termed exchange application, for exchanging data, through the card14chip, with the CLF122.

According to such a corresponding embodiment, the phone16memory stores a JVM that interprets and executes the exchange application.

The phone16memory stores, besides an OS, the NFC application(s) and the exchange application.

The exchange application may allow sending, through the card14chip, to the CLF122data, in particular one command(s) for administrating the CLF122, such as a command for configuring at least one radio-frequency parameter of the CLF122. The command may constitute notably a command for switching on or off a type, like type A or type B. To switch from one current type to the other type, for example, the exchange application allows sending, through the card14chip, to the CLF122, a first command for switching off the current type followed by a second command for switching on the other type.

The exchange application allows sending, through the card14chip, to the CLF122data, in particular one command(s), that is previously encapsulated within the first communication protocol data, itself being encapsulated within the second communication protocol data.

The exchange application may allow reading data originating from the external of the system10and received by the CLF122by addressing, through the card14chip, to the CLF122.

The exchange application may allow accessing, thanks to data originating from the external of the system10and received by the CLF122, the phone16MMI, so as to exchange with a phone16user, while addressing, from the CLF122, through the card14chip, to the phone16microprocessor.

FIG. 2depicts an example of a message flow20that involves a Contact-Less communicating Device (or CLD)21, the CLF122, the card14chip, and the phone16microprocessor, when the system10operates in a reader mode with respect to the CLD21.

The card14chip (and more exactly the proxy application) constitutes, within the system10, the single interlocutory of the phone16microprocessor (and more exactly the exchange application) and also the single interlocutory of the CLF122.

The card14chip plays a role of a proxy gate.

The phone16microprocessor acts as a reader application gate that accesses only the card14chip. The phone16microprocessor sends to the card14chip a set of commands. The card14chip sends back to the terminal a set of corresponding responses, as further described herein below. The commands and responses are compliant with the European Telecommunications Standards Institute (or ETSI) 102.622 specifications, so as to discuss by using HCI protocol.

The CLF122, as host controller, plays a role of a radio-frequency reader gate, accessible only from the card14chip within the system10.

The card14chip sends to the CLF122a set of commands. The CLF122sends back to the card14chip a set of corresponding responses, as further described herein below. The commands and responses exchanged between the card14chip and the CLF122are compliant with the ETSI 102.622 specifications.

Firstly, a phone user activates a reader mode of the system10, for example, by depressing at least one button of the keyboard164.

The phone16microprocessor sends to the card14chip a first phone command22, such as “APDU_WRITE[HCI(EVT_READER_REQUESTED)]”. The first phone command22is built by encapsulating a CLF command, such as EVT_READER_REQUESTED, intended to the CLF122, within a first protocol data, namely HCI data, the encapsulated CLF command being encapsulated within a second protocol data, such as APDU data, such as APDU_WRITE, as a phone command. The first phone command22may include, besides the CLF command, CLF parameters, so as to set the CLF122in a desired type A or B.

The first phone command22allows addressing, from the phone16microprocessor, through the card14chip, to the CLF122, so as to set the CLF122in a reader mode.

The card14chip extracts or de-encapsulates the received first phone command22, so as to retrieve a first card command to be sent to the CLF122. Then, the card chip sends to the CLF122the first card command24, such as HCI(EVT_READER_REQUESTED), as a CLF command intended to the CLF122while being encapsulated within the first protocol data.

The card14chip sends back to the phone16microprocessor a first card response26, as response to the first phone command22, such as an APDU status word like 9000 without data. The first card response26allows telling to the phone16microprocessor that the card14has well received the first phone command22.

Then, during a polling phase (not represented), the phone16microprocessor sends periodically to the card14chip an additional phone command (not represented), such as APDU_READ, so as to request to the card14chip whether the card14chip has some data to give to the phone16microprocessor. The period may be set to 1 s (or second). While the card14chip has no data to give to the phone16microprocessor, the card14chip sends back to the phone16microprocessor a card response, as response to each additional phone command, like an APDU status word, like “9000”, without data. Such a card response allows telling to the phone16microprocessor that the card14has well received the additional phone command, but the card14chip has no data to provide to the phone16microprocessor.

Once the CLF122receives the first card command24, the CLF122executes it and is thus configured according to an operating mode, such as on a type A or type B.

Then, the CLF122sends an interrogating signal27, so as to power, thanks to the phone battery, any contact-less communicating device that is close (typically up to 20 cm) to the system10, as a contact-less communicating reader.

As soon as, for example, an RFID tag, as CLD21, has been powered, the CLD21sends to the system10a presence signal28, so as to indicate its presence in an electromagnetic field generated by the CLF122.

Once the CLF122has received the presence signal28, the CLF122sends to the card14chip data, such as EVT_TARGET_DISCOVERED, for signalling this latter that an interlocutory has been detected, encapsulated within first protocol data, namely HCI data, such as HCI(EVT_TARGET_DISCOVERED), as response210to the first card command24.

The phone16microprocessor sends to the card14chip a second phone command212, such as APDU_READ, so as to request the card14chip whether the card14chip has some data to give to the phone16microprocessor.

Once the card14chip has received the response210to the first card command24, the card14chip encapsulates the received response into a second protocol data, namely APDU. Then, the card14chip sends to the phone16microprocessor the resulting encapsulated response214, such as APDU[HCI(EVT_TARGET_DISCOVERED)], accompanied with an APDU status word, as response to the second phone command212. The response214to the second phone command212allows informing the phone16microprocessor that an interlocutory has been detected, and the card14chip has well received from the phone16microprocessor the second phone command212.

The phone16microprocessor receives and interprets the response214to the second phone command212.

Then, the phone16microprocessor builds a third phone command comprising a reading command, such as WR_XCHG_DATA, so as to read data originating from the CLD21, as interlocutory of the CLF122.

To build the third phone command, firstly, the phone16microprocessor encapsulates the reading CLF command intended to the CLF122within first protocol data, namely HCI data, and, then, the phone16microprocessor encapsulates the encapsulated reading CLF command within second protocol data, namely APDU data.

Once built, the phone16microprocessor sends to the card14chip the resulting third phone command216, such as APDU_WRITE[HCI(WR_XCHG_DATA)].

The card14chip extracts or de-encapsulates the received third phone command216, so as to retrieve a corresponding card command to be sent to the CLF122. Then, the card14chip sends to the CLF122a second card command218, such as HCI(WR_XCHG_DATA), as a CLF command intended to the CLF122while being encapsulated within the first protocol data, namely HCI data.

Then, the CLF122receives the second card command218and extracts from this latter the reading command, namely WR_XCHG_DATA, as CLF command originating from the phone16microprocessor.

The CLF122executes the reading command by sending to the CLD21a command221for fetching data.

The CLD21retrieves data stored within the CLD21and sends back to the CLF122the retrieved data222.

Then, the CLF122sends back to the card14chip a response224to the second card command218. The response224comprises the read data.

Meanwhile, during another polling phase (not represented), the phone16microprocessor sends periodically to the card14chip an additional phone command (not represented), such as APDU_READ, so as to request the card14chip whether the card14chip has some data to give to the phone16microprocessor.

The phone16microprocessor sends to the card14chip a fourth phone command226, such as APDU_READ, for requesting the card14chip to transfer data to the phone16microprocessor.

Once the card14chip has received the response224to the second card command218, the card14chip encapsulates the received response into a second protocol data, namely APDU. Then, the card14chip sends to the phone16microprocessor the resulting encapsulated response228, such as APDU[HCI(WR_XCHG_DATA)], accompanied with an APDU status word, such as “9000”, as response to the fourth phone command226. The response228to the fourth phone command226allows informing the phone16microprocessor that an interlocutory has provided the CLF122with read data that is attached and the card14chip has well received from the phone16microprocessor the fourth phone command226.

Then, the phone16microprocessor receives the read data within the response228to the fourth phone command by extracting the read data.

The phone16microprocessor processes the read data.

Optionally, the phone16microprocessor informs, through the phone MMI, the phone user about either the read data or data derived from the read data.

The phone16microprocessor sends to the card14chip a fifth phone command230, such as “APDU_WRITE[HCI(EVT_END_OPERATION)]”. The fifth phone command230is built by encapsulating a CLF command, such as EVT_END_OPERATION, intended to the CLF122, within a first protocol data, namely HCI data, the encapsulated command being encapsulated within a second protocol data, such as APDU data, such as APDU_WRITE, as a phone command. The CLF command allows the CLF122to close the open reading session.

Then, the card14chip sends to the CLF122a third card command232, after having de-encapsulated the fifth phone command230and extracted the third card command.

The card14chip sends back to the phone16microprocessor a fifth card response234, as response to the fifth phone command230, such as an APDU status word, like “9000” without data. The fifth card response234allows telling to the phone16microprocessor that the card14has well received the last phone command230.

The CLF122closes the open reading session.

FIG. 3shows an example of a message flow30that involves a Contact-Less communicating Reader (or CLR)31, as a Contact-Less communicating Device external to the system10, the CLF122, the card14, and the phone16microprocessor, when the system10operates in a card emulation mode with respect to the CLR31.

In the embodiment described herein after, the card14chip executes two applications33and35, termed card application1and card application2respectively in theFIG. 3, in which the card application2is the proxy application that interfaces with, on the one hand, the CLF122, and, on the other hand, the phone16microprocessor.

The card14chip (and more exactly the proxy application) constitutes, within the system10, the single interlocutory of the phone16microprocessor (and more exactly the phone application) and also the single interlocutory of the CLF122.

The card14chip plays a role of a card application gate/connectivity gate and a proxy gate.

The phone16microprocessor acts as a connectivity gate that accesses only the card14chip (and more exactly the proxy application). The phone16microprocessor sends to the card14chip a set of commands. The card14chip sends back to the terminal a set of corresponding responses, as further described herein below.

The CLF122, as host controller, plays a role of a card radio-frequency gate, accessible only from the card14chip (and more exactly the two applications) within the system10.

The card14chip sends to the CLF122a set of commands. The CLF122sends back to the card14chip a set of corresponding responses, as further described herein below. The commands and responses are compliant with the ETSI 102.622 specifications, so as to discuss by using the HCI protocol.

Firstly, a phone user switches on the phone16that is thus powered by the phone battery.

The CLR31sends an interrogating signal32, so as to power, thanks to the interrogating signal, at least in part any contact-less communicating device or system10that is close (typically up to 20 cm) to the CLR31.

The interrogating signal32is thus received by the CLF122. The interrogating signal32allows powering the CLF122and the card14chip.

The CLF122sends, to the card application133, data34, such as EVT_FIELD_ON, encapsulated within first protocol data, namely HCI, for informing the card14chip that the system10is present within an electromagnetic field generated by the CLR31.

The CLR31sends to the CLF122a signal36, so as to allow selecting the CLF122among several contact-less communicating device(s) and/or system(s) comprised within the electromagnetic field generated by the CLR31. Such a selection enables to avoid collision during data exchange between the CLR31and different contact-less communicating device(s) and/or system(s).

Then, the CLF122sends, to the card application133, data38, such as EVT_CARD_ACTIVATED, encapsulated within first protocol data, namely HCI, for activating the card14chip that the system10is selected for exchanging data with the CLR31.

The card application133receives the data38originating from the CLF122and is activated.

Once the CLR31has activated the system10, the CLR31sends to the CLF122data310, like, for example, a request for decrementing a value of a counter that manages a transport service, also termed ticketing service.

The CLF122sends, to the card application133, data312, such as EVT_SEND_DATA, encapsulated within first protocol data, namely HCI, for requesting the card14chip to process the data originating from the CLR31.

Then, the card application133processes the received data by, for example, decrementing a counter value managed by the card14chip.

Once the card application133has processed the data originating from the CLR31, the card application133sends back to the CLF122data314, such as EVT_SEND_DATA, encapsulated within first protocol data, namely HCI, for informing the CLR31that the data (sent by the CLR31) has been processed while possibly accompanying it with data resulting from the data processing by the card14chip.

The CLF122sends to the CLR31data315, such as the data resulting from the data processing by the card14chip and/or a simple acknowledgement of the receipt of the data originating from the CLR31.

The card application133sends to the CLF122data316, such as EVT_CONNECTIVITY, encapsulated within first protocol data, namely HCI, for informing the card application2that the data is to be transferred to the phone16microprocessor. Thus, a channel or pipe, termed “connectivity” pipe, between the card application133and the phone16microprocessor is to be created through the card application235. The connectivity pipe may be used for exchanging with the phone user through the phone MMI.

Then, the CLF122forwards data318, namely HCI(EVT_CONNECTIVITY), that has just been received from the card application133to the card application235.

Thus, the CLF122is a bridge between two applications executed by the card14chip that allows re-directing data originating from the card application133to the card application235.

According to an alternative, the card application133sends data to the card application235without interposing any entity external to the card14chip. According to such an alternative, the exchanged messages with the different involved actors are thus reduced.

Meanwhile, during a polling phase (not represented) from a power-on of the phone16, the phone16microprocessor sends periodically to the card14chip a phone command (not represented), such as APDU_READ, so as to request the card14chip whether the card14chip has some data to give to the phone16microprocessor. The period may be set to 1 s (or second). While the card14chip has no data to give to the phone16microprocessor, the card14chip sends back to the phone16microprocessor a card response, as response to each phone command, like an APDU status word like 9000 without data. Such a card response allows telling to the phone16microprocessor that the card14has well received the additional phone command but the card14chip has no data to provide to the phone16microprocessor.

The phone16microprocessor sends to the card14chip a first phone command320, such as APDU_READ, for requesting the card14chip to transfer to the phone16microprocessor data.

Once the card application235has received from the card application133data previously received, namely HCI(EVT_CONNECTIVITY), the card application235encapsulates the received data into a second protocol data, namely APDU. Then, the card application235sends to the phone16microprocessor resulting encapsulated data, such as APDU[HCI(EVT_CONNECTIVITY)], accompanied with an APDU status word, as first response322to the first phone command320. The first response322to the first phone command320may allow informing the phone16microprocessor that the card14chip processes data, for example, by using the phone MMI to exchange with the phone user, and the card14chip has well received from the phone16microprocessor the first phone command320.

Optionally, the card application133sends to the CLF122data324, such as EVT_TRANSACTION, encapsulated within first protocol data, namely HCI, that is to be addressed, through the card application235, to the phone16microprocessor by using the created “connectivity” pipe, between the card application133and the phone16microprocessor. Then, the CLF122forwards data326, namely HCI(EVT_TRANSACTION), that has just been received from the card application133to the card application235.

The phone16microprocessor sends to the card14chip a second phone command328, such as APDU_READ, for requesting the card14chip to transfer to the phone16microprocessor data available at the card14chip.

Once the card application235has received, through the CLF122, from the card application133data previously received, namely HCI(EVT_TRANSACTION), the card application235encapsulates the received data into a second protocol data, namely APDU.

The card application235sends to the phone16microprocessor resulting encapsulated data330, such as APDU[HCI(EVT_TRANSACTION)], accompanied with an APDU status word, as second response330to the second phone command328. The second response330to the second phone command328may allow informing the phone16microprocessor that the card14chip needs data from the phone user. For example, the needed data involves an exchange, through the phone MMI, by asking one question to the phone user. The second response330to the second phone command328allows informing that the card14chip has well received from the phone16microprocessor the second phone command328.

The phone16microprocessor sends to the card application2, a third phone command332, such as “APDU_WRITE[HCI(EVT_TRANSACTION)]”. The third phone command332is built by encapsulating a card command, such as EVT_TRANSACTION, intended to the card application133, within a first protocol data, namely HCI data, the encapsulated command being encapsulated within a second protocol data, such as APDU data, such as APDU_WRITE, as a phone command.

The card command allows the card application1, for example, to get from the phone user a response to an asked question. The card command encompasses the response.

The card application2sends to the CLF122a card command334, such as EVT_TRANSACTION, encapsulated within first protocol data, namely HCI, after having de-encapsulated the third phone command332and extracted the card command334.

The card14chip sends back to the phone16microprocessor a third card response336, as response to the third phone command332, such as an APDU status word, like “9000”, without data. The third card response336allows telling to the phone16microprocessor that the card14has well received the last phone command332.

The CLF122receives the card command334and sends to the card application133the received card command338, namely HCI(EVT_TRANSACTION).

The card application133processes the received card command338by exploiting the data originating from the phone16microprocessor.

The phone user moves away from the CLR31.

The CLF122does no more receive any signal issued by the CLR31.

The CLF122sends to the card application1data340, such as EVT_FIELD_OFF, encapsulated within first protocol data, namely HCI, for informing the card14chip that the open card emulation session is terminated.

A lot of amendments for the embodiment described supra in relation with the operating either in a reader mode or in a card emulation mode may be brought without departing from the spirit of the invention. For example, instead of an execution of two applications (or applets) by the card14chip for the card emulation mode in which one application discusses with the CLF122while another application discusses with the phone16microprocessor, the card14chip executes one and the same application that integrates functions carried out by the two applications.