FR2921739A1 - Application data managing method for near field communication system of e.g. portable telephone, involves generating application data within near field communication system, and providing application data to processors and external server - Google Patents

Abstract

The method involves receiving external application data via a contact less data receiving/transmitting interface (CLINT). Complementary application data is generated within a near field communication (NFC) system (NFCS2) in response to a routing or transferring action of external application data received or transmitted via the data receiving/transmitting interface. The complementary application data is provided to host processors (HP1-HP3) and an external server of the system. An independent claim is also included for a device for managing application data in a near field communication system.

Description

Method and apparatus for managing application data in an NFC system in response to sending or receiving contactless data

The present invention relates to a method for managing application data in an NFC system comprising at least one host processor and a contactless transmission / reception interface. The present invention also relates, in general, to the realization of an NFC system. NFC technology is being developed by an industry consortium called the NFC Forum (http://www.nfc-forum.org). It is derived from RFID ("Radio Frequency IDentification") technology and uses NFC components with several modes of operation, including a "Reader Mode" and a "Card Emulation" mode. In the "reader" mode, an NFC component functions as a conventional RFID reader for reading or writing access to an RFID chip (smart card or contactless tag). It emits a magnetic field, sends data to the RFID chip by modulating the amplitude of the magnetic field and receives data from the RFID chip by charge modulation and inductive coupling. This mode is also called active mode, since in this mode the component emits a magnetic field. In the "emulation" mode, described in the European patent published under the number EP 1 327 222 in the name of the applicant, an NFC component operates passively in the manner of a transponder to dialogue with another reader and be seen by the other reader as an RFID chip. The component does not emit a magnetic field, receives data by demodulating a magnetic field emitted by the other reader and transmits data to this other reader by modulating the impedance of

its antenna circuit (charge modulation). This mode is also called passive mode, since in this mode the component does not emit a magnetic field. Other modes of communication may be implemented, including a "device" mode where an NFC component must pair with another component in the same operating mode, each component alternately in a passive state (without field emission) to receive data and in an active state (with field emission) to transmit data. In addition to these various modes of operation, an NFC component can implement several contactless communication protocols, for example ISO 14443-A, ISO 14443-B, ISO 15693, Felica, etc. Each protocol defines a magnetic field emission frequency, a magnetic field amplitude modulation method for transmitting data in active mode, and an inductively coupled load modulation method for transmitting passive mode data. An NFC component can therefore be a multimode and multiprotocol device. The Applicant markets for example an NFC component under the designation "MicroRead". Due to its extensive communication capabilities, an NFC component is intended to be integrated into portable devices such as mobile phones or Personal Digital Assistants (otherwise known as PDAs, or "Personal Digital Assistant"). It is therefore necessary to make an NFC system of the type shown in Figure 1 under the reference NFCS1. The NFCS1 system includes an NFC component designated "NFCR1" and at least a first host processor HP1. The term "host processor" means any integrated circuit comprising a microprocessor or a microcontroller and which is connected to a port of the NFC component. In many applications, the NFC system also includes a

second HP2 host processor, or even a third HP3 host processor. The host processor HP1 is the main processor of the device in which the NFC component is embedded.

It is generally an insecure application processor, for example the baseband circuit of a mobile phone ("baseband" circuit or radiotelephone circuit) and this one controls various peripheral elements of the telephone, in particular the keyboard, the display, microphone, earphone etc. The second HP2 host processor may be a secure circuit, for example the secure processor of a SIM card ("Subscriber Identification Module") issued by a mobile operator and having a subscriber identifier. The third HP3 host processor may also be a secure circuit delivered by another service provider, for example for secure payment applications. Such a processor also includes a user identifier of the service. NFC component resources are made available to HP1, HP2, and HP3 processors to enable them to manage contactless applications. Examples of applications are illustrated in FIG. 2 which shows a mobile telephone 30 equipped with the NFCS1 system of FIG. 1. There are distinguished here: 1) API applications in which the NFCR1 component of the mobile telephone 30 is in reader mode for communicating in reading and / or writing with a contactless integrated circuit CLCT or with a component NFCR1 'in card emulation mode. In this case, the mobile phone is used as an NFC reader. This type of application can be free and consist for example of a reading of advertising data inserted in an advertising display of an aubette. The application can also be paid and consist for example of a reading of information reserved for subscribers. The

The API application program can be owned and executed by the HP1 processor if the service is free or owned and executed by one of the HP2 or HP3 processors if it is paying for it then requires an identification of the subscriber or the user. 2) AP2 secure applications in which the NFCR1 component of the telephone 30 is in card emulation mode to be read by a conventional reader RD or by another component NFCR1 ', in payment applications or paying access control (machine payment, subway entrance, etc.). The mobile phone 30 is then used as a smart card. The program of the AP2 application is preferably owned and executed by the secure processor HP2 or HP3, as shown in Figure 1, because access to the service requires identification of the subscriber or the user. 3) unsecured AP2 'applications in which the NFCR1 component is also in card emulation mode for playback by conventional RD readers or other NFCR1' component. The mobile phone 30 is then also used as a smart card, but the program of the AP2 'application can be owned and executed by the unsecured processor HP1 or the processors HP2, HP3 (the paid service providers can offer applications Free). 4) AP3 applications in which the NFCR1 component of the telephone 30 is in "device" mode and dialogue with a component NFCR1 'embedded in another mobile phone or in a computer. This type of application is generally free and can transfer data packets from one device to another (transfer of point-to-point files in particular). The program of the AP3 application is preferably owned and executed by the insecure processor HP1, as illustrated in FIG. 1, which has a computing power greater than the processor

secure HP2 if it is a SIM card processor or HP3 secure processor. Thus, the realization of an NFC system involves the routing or at least the transfer, within the NFC system, of data transmitted by the processors HP1, HP2, HP3 and to be routed to the NFC component (outgoing data transmitted via the NFC system). non-contact data transmission channel), and conversely the routing or the transfer of data received by the NFC component and to be routed to one of the processors HP1, HP2, HP3 (incoming data received via the data transmission channel without contact). FIG. 3 schematically represents an exemplary architecture of the NFCR1 component within the NFCS1 system. The NFCR1 component comprises a CLINT contactless transmission / reception interface equipped with an antenna circuit ACT, the wired communication interfaces INT1, INT2, INT3 connected to the CLINT interface, and a routing or communication processor. NFCC1 data transfer. The interface INT1 is connected to the host processor HP1, the interface INT2 connected to the host processor HP2 and the interface INT3 connected to the host processor HP3. In front of the component NFCR1 is represented an external device EXTD. This external device may be an NFCR1 'component or a conventional RD reader arranged in a computer, a payment terminal, a mobile phone, etc., or a contactless chip CLCT and its antenna circuit arranged on a support such as a card plastic or paper, an electronic tag, etc.

When an NFC transaction is initiated between the NFCS1 system and the external device EXTD, the processor NFCC1 provides routing or transfer to an HP1-HP3 host processor application data read from or provided by the external device EXTD, these data being received via the CLINT interface. The NFCC1 processor also provides routing or data transfer to the external device EXTD via the interface

CLINT, application data from an HP1-HP3 host processor. An object of the present invention is to improve the processing of application data in an NFC system to improve the functionality offered by NFC systems to users. For example, some RFID chips (for example CLCT in Figure 3) are equipped with a low-cost memory and limited capacity and can therefore contain only a small amount of information. In particular, there are RFID chips containing only 48 bytes of data, so that the application data that can be read by an NFC system in this type of chip are reduced. This reduces the possibility of exploitation or presentation of this data by the host processor that receives and processes them within the NFC system. As another example of the current limitations of NFC systems, when data is exchanged between an NFC host processor and an external EXTD device, there is generally no recorded trace of the exchanges performed if the receiving host processor or data transmitter exchanged is not the main application processor of the NFC system, for example the processor HP1 in FIG. 3. In practice, there may be a direct connection between the processor HP1 and one of the processors HP2, HP3, for example a bus ISO 7816, which is not shown in Figure 3, but the service providers who control the functionality of the host processors have limited the possibilities of operating this connection so that the possibilities for information exchange between the processors are reduced. Thus an HP2 or HP3 processor can exchange application data with an external device via the CLINT interface without the processor HP1 being informed.

An embodiment of the invention thus relates to a method for managing application data in an NFC system comprising a contactless transmission / reception interface, comprising the steps of generating, within the NFC system, complementary application data in response to a routing or transfer action within the NFC system of external application data received or transmitted via the contactless transmission / reception interface, and providing the application data complementary to at least one element of the NFC system. According to one embodiment, the method comprises the steps of receiving the external application data via the contactless transmission / reception interface, generating the complementary application data within the NFC system, and transferring to the same element of the NFC system the external application data and the additional application data.

According to one embodiment, the method comprises the step of concatenating or mixing the complementary application data and the external application data before transferring them to the NFC system element.

According to one embodiment, the method comprises the step of transferring the external and complementary application data to a main processor of the NFC system, ensuring the control of peripheral elements comprising at least one display device. According to one embodiment, the method comprises the step of including in the complementary application data at least one of the following data of the external application data display parameters, data intended to be displayed with the external application data, data forming with external application data

a connection command to a server accessible via the Internet, data forming with the external application data a command to download a file from a server accessible via the Internet.

According to one embodiment, the method comprises the step of generating the complementary application data from the external application data, by means of a transformation function such as a cryptographic function.

According to one embodiment, the method comprises the steps of receiving external application data from a first element of the NFC system and transmitting them via the data transmission / reception interface, or receiving: the data of external application via the data transmission / reception interface and transfer them to the first element of the NFC system, generate the additional application data within the NFC system, and transfer to a second element of the NFC system the application data. complementary.

According to one embodiment, the method includes the step of including in the complementary application data espionage data relating to the external application data or a transaction in which the external application data is provided. are exchanged. According to one embodiment, the method comprises the step of including in the complementary application data at least one of the following data transaction time information, information of a type of communication or transaction, an identifier of a file, all or part of the external application data, the identity of an NFC system element to which the external application data is transferred or which transmits the application data.

According to one embodiment, the complementary application data is sent directly to an external server.

According to one embodiment, the complementary application data is generated in a given format to simulate data that would be read into or provided by an external component via a contactless communication channel. According to one embodiment, the method comprises a step of formatting in a given format the result of concatenation or mixing of the complementary application data and the external application data, to simulate data that would be read in or provided by an external component via a contactless communication channel. An embodiment of the invention also relates to an application data management device in an NFC type communication system, comprising an NFC-type contactless transmission / reception interface and a routing or communication processor. data transfer for carrying out application data transfer actions between at least two elements of an NFC system to be connected to the data management device, wherein the routing or data transfer processor is configured to generate in the NFC system, additional application data in response to a routing or transfer action within the NFC system of external application data received or transmitted via the contactless transmission / reception interface , and providing the complementary application data to at least one element of the NFC system.

According to one embodiment, the routing or data transfer processor is configured for, upon receipt by the NFC system of external application data via the contactless transmission / reception interface generating the application data. in the NFC system, and transfer to the same element of the NFC system the external application data and the additional application data.

According to one embodiment, the routing or data transfer processor is configured to concatenate or mix the complementary application data and the external application data before transferring them to the NFC system element. According to one embodiment, the routing or data transfer processor is configured to transfer the external and complementary application data to a main processor of the NFC system, ensuring the control of peripheral elements comprising at least one display device According to one embodiment, the routing or data transfer processor is configured to include in the complementary application data at least one of the following data external application data display parameters, data intended for be displayed with the external application data, data forming with the external application data a connection command to a server accessible via the Internet, data forming with the external application data a command to download a file from a server accessible via the Internet. According to one embodiment, the routing or data transfer processor is configured to generate the complementary application data from the external application data, by means of a transformation function such as a cryptographic function.

According to one embodiment, the routing or data transfer processor is configured to, in response to the provision by a first element of the NFC system of external application data to be transmitted via the transmit / receive interface of data, or the reception via the interface of transmission / reception of data of external application data to be transferred to the first element of the NFC system: generating the data

in the NFC system, and transfer to a second element of the NFC system the additional application data. According to one embodiment, the routing or data transfer processor is configured to include in the complementary application data espionage data relating to the external application data or to a transaction in which the data external applications are exchanged. According to one embodiment, the routing or data transfer processor is configured to include in the complementary application data at least one of the following data transaction time information, information of a type of communication. or transaction, an identifier of a file, all or part of the external application data, the identity of an NFC system element to which the external application data is transferred or which transmits the application data. According to one embodiment, the routing or data transfer processor is configured to directly send the complementary application data to an external server.

According to one embodiment, the routing or data transfer processor is configured to generate the complementary application data in a specific format to simulate data that would be read from or provided by an external component via a contactless communication channel. . An embodiment of the invention also relates to an NFC system comprising an application data management device according to the invention, and at least one host processor connected to the device.

An embodiment of the invention also relates to an electronic portable object, in particular

mobile phone, comprising an NFC system according to the invention. Exemplary embodiments of the invention will be set forth in the following in a nonlimiting manner, in relation to the appended figures among which: FIG. 1 previously described represents in the form of blocks a conventional NFC system architecture, and external elements; with which this NFC system can dialogue, - Figure 2 previously described illustrates various applications of an NFC system integrated in a mobile phone - Figure 3 previously described represents in block form the conventional architecture of a NFC component 15 present in the NFC system of FIG. 1, FIG. 4 schematically illustrates an NFC system in which embodiments of the data management method according to the invention are implemented, FIGS. sequences of data exchange between elements of the NFC system of FIG. 4 and illustrate embodiments of the invention, FIG. e 8 represents an exemplary hardware architecture of an NFC component present in the NFC system 25 of FIG. 4, and FIG. 9 represents an exemplary software architecture of the NFC component of FIG. 8. FIG. schematically an NFC system designated "NFCS2" in which is implemented an embodiment of the data management method according to the invention. The architecture of the NFCS2 system shown here is only one example in which the invention is implemented. Still as an example, it is considered here that the NFC system is integrated into a mobile phone, shown schematically in FIG.

The NFCS2 system includes an NFC component designated "NFCR2" and host processors HP1, HP2, HP3 or "application processors" as supposedly each capable of performing NFC transactions or participating in such transactions. The NFCR2 component comprises an NFCC2 processor and a CLINT contactless transmission / reception interface equipped with an antenna circuit ACT. The HP1 host processor is here the main processor of the NFCS2 system. This is the radiotelephone processor ("baseband" processor) of the mobile phone. The host processor HP1 controls the mobile phone's radio circuit and various peripheral elements of the telephone, such as a display screen, a keyboard, an earpiece, a microphone, etc., which have not been represented for the sake of simplicity . It is assumed here that the HP1 processor is able to connect to the Internet via the radio circuit or a possible WiFi or Bluetooth ° interface, this feature being present in the majority of the latest generation of mobile phones. The HP2 host processor and the HP3 host processor are here secure circuits, for example a SIM card and a credit card chip.

In this example, the component NFCR2 comprises a routing member HCIADM ("Administrator HCI") implementing a routing protocol called "HCI" ("Host Controller Interface"). The HCIADM routing member provides the creation of data paths or routing channels for the routing of data within the NFC system. The routing unit HCIADM is for example a software function executed by the processor NFCC2, which is thus used as a routing processor or data transfer within the NFC system. The action of the HCIADM routing member on the transfer of data between the CLINT interface and the HP1, HP2, HP3 host processors or on the data transfer between the HP1 processors

HP3 is schematically represented by a kind of "cloud" arranged on a global data path GP of the NFC system. This global data path is controlled by the HCIADM and connects the CLINT interface to the HP1-HP3 host processors as well as host processors to each other. The HCIADM creates a particular data path within the global data path by assigning it a routing channel number CHANi after a request for creating a data path has been issued by an application processor. or after establishment by the CLINT interface of a link with an external device EXTD at the request of the external device (transactions that can be initiated either by the host processors or by the external device). The HCI protocol implemented here uses data frames of type {CHANi; DATA} comprising a header field having a routing channel number CHANi and a data field containing DATA application data. In FIG. 4, source or destination points of a data stream in the NFC system are designated P1 (point located in the host processor HP1), P2 (point located in the host processor HP2), P3 (point located in the host processor HP3) and Pc (point located in the CLINT contactless interface). It will be noted that the manner in which the routing is performed as well as the NFC system architecture described herein constitute only the implementation context of the embodiment of the method of the invention which will be described in the following. Embodiments of the method of the invention can also be implemented in an NFC system without data routing, for example comprising only data exchange buffers to ensure the internal transfer of data without generation of routing channels. and without the use of routing frames. Thus, in the following, the term

"Routing" can also refer to a simple transfer of data from one point to another within the NFC system. The CLINT interface may also be provided as an integral part of the NFCC2 processor and entirely under its control, and not as a source point or destination Pc distinct from the NFCC2 processor. In this case, the NFCC2 processor manages the contactless communication protocol. The CLINT interface includes only contactless communication hardware and can not behave as an intelligent device capable of responding to or generating routing commands. If such a design option is retained, FIG. 4 as well as FIGS. 5, 6 described below are modified so as to represent the interface CLINT and the routing point Pc inside the block representing the processor NFCC2. First aspect of the invention generating application data during the routing of external data According to one embodiment of the data management method according to the invention, the component NFCR2 comprises a complementary application data generation member designated " DTGEN "in Figure 4. Like the HCIADM routing member, the DTGEN member is for example a function or" layer "software that is executed by the NFCC2 processor and relies on the hardware interfaces of the processor . The DTGEN member and the HCIADM member may moreover form only one software entity, the distinction between each of the members being made here essentially for the purpose of distinguishing the characteristics of the invention from the conventional characteristics of routing or transfer. of data. This is called DATAI "external application data", data that is transmitted or received via the CLINT contactless interface. In response to a routing action of external DATAI application data,

DATA2 complementary application data is generated by the DTGEN member. These complementary data DATA2, if they are destined for the same destination point as the DATAI data, can be combined with the DATAI data.

Such a combination may comprise a concatenation operation or a mixing operation of the complementary DATA2 data and the DATAI application data, or both operations at a time. The result of the combination can be incorporated into the same routing frame, of the type:

{SINGING; DATAI, DATA2}

If the additional data is destined for another destination point than the DATAI data, it can instead be integrated into another routing frame, of the type:

{CHANj; DATA2}, in which the routing channel CHANj is different from the routing channel CHANT. The complementary application data DATA2 is generally data that can be used by one of the application processors HP1, HP2, HP3 to execute a determined action, either in the form of parameters making it possible to completely define the action to be executed. or in the form of at least a portion of the instructions forming the action to be performed. First Embodiment of the First Aspect of the Invention In a first embodiment of the first aspect of the invention, the complementary application data DATA2 is generated by the DTGEN 35 to enrich the DATAI application data and are transmitted with them to the receiving element of the DATAI data. When the recipient element is a

As an NFC system application processor, adding the DATA2 supplemental data to the DATAI initial data allows the application processor to perform more complex actions than it could have done by simply receiving the DATAI data. This makes it possible, for example, to carry out such actions from elementary data read from or supplied by low-cost chips or RFID tags whose memory capacity is insufficient to record commands corresponding to these actions. For example, when the DATAI data is intended for the main processor HP1 as application processor and includes raw information intended to be displayed on a screen of a device comprising the NFC communication system, here the screen of the mobile telephone , such as the words "Hello world", the complementary application data DATA2 can be "<b>" on the one hand and "</ b>" on the other hand. The DATA2 data is concatenated with the "Hello world" data so as to form the following command:

<b> Hello world </ b>

which is coded as html and means that everything between <b> tags must be bolded. Thus, upon receipt of this instruction, the processor HP1 displays the words "Hello world" in bold. The DATAI data display can also be enhanced by adding DATA2 data that drives (in the sense of "cause") the application processor to connect to an external server EXTSVR for display instructions. Using the previous example, where the DATAI data is "Hello world", the complementary data are for example: http://www.insidefr.com/parser.php?display= 25

and are concatenated with the DATAI data to form the following statement:

http://www.insidefr.com/parser.php?display=Hello world The command obtained is a redirection to the website "insidefr.com" and a call to the function "parser.php" for the execution of the display function "display". For example, parser.php returns a command to the HP1 processor to display a menu or an advertisement, a wallpaper, and so on. while displaying "Hello world". The HP1 processor can also receive from the web server display commands ensuring a display on the screen of better quality (font, color, positioning of text, etc.). Another example of an application is the automatic downloading of a sound file based solely on DATAI data including for example a serial number. In this case, DATAI data "call 61321" read in an RFID chip can be supplemented by the following DATA2 data:

"http://www.insidefr.com/parser.php?load=", to form a complete ringtone download instruction:

"Http://www.insidefr.com/parser.php?load=61321". The user therefore does not need to call himself the number from which the download is to be made. Thus, by reading elementary data in a chip or in a tag (RFID) tag, the method can generate sophisticated commands that are executed by the application processor.

Yet another example of an application makes it possible to improve the display of information without necessarily going through an external server. If, for example, the NFCR2 component stores one or more images in memory, it is possible to display DATAI data such as a telephone number "0487654321" in the form of an image rather than text and / or preceded by a logo. operator. The additional data DATA2 are for example: display ("logo.jpg")

and are concatenated with the DATAI data to form the following display instruction, executed by the HP1 processor:

display ("logo.jpg") 0487654321

It is also possible to supplement the DATAI data by adding information, for example advertising. If a DATAI menu "listen to your messages" is read in an RFID chip, new DATA2 menu lines can be added by the NFCR2 component such as "display your account, access your WAP server, call support". Many other applications of this first embodiment of the first aspect of the invention may be provided by those skilled in the art, depending on the nature of the complementary application data DATA2. Second Embodiment of the First Aspect of the Invention According to a second embodiment of the first aspect of the invention, the complementary application data DATA2 is generated by the DTGEN member for the attention of a different processor. than the one to whom the DATAI application data is intended.

This second embodiment of the first aspect of the invention makes it possible in particular to perform a kind of spying of a processor by another, as do the programs called "spywares". For this type of application, the data exchanges between two elements of the NFC system give rise to the generation of DATA2 complementary data concerning these exchanges which can be exploited by another processor, preferably the main processor HP1, or by an external server . For example, this can be used to manage user profiles. The elements to be spied on are, for example, the HP2 or HP3 secure host processor and the communications established between EXTD external devices and these processors via the CLINT interface.

Thus, for example, when the HCIADM sends to one of the processors HP2, HP3 data sent or read in the external device EXTD via the interface CLINT, the unit DTGEN generates data DATA2 which can include information of transaction time, information on the type of communication or transaction in progress (communication with a reader, with a card, etc.), the content or the identifier of a selected file, the nature and / or the content of the data exchanged if they are not encrypted, and the identity of the processor HP2 or HP3 leading the communication or the transaction. This data is then communicated to the main processor HP1 which can send them to an external server or are sent directly to the external server by the processor NFCC2. In general, any information conveyed to a host processor or transmitted by a host processor is likely to be passed on to the processor HP1 or an external server by the DTGEN member to allow the processor HP1 to manage a user profile or allow a remote server to manage a user profile. Of course, other goals can

justify the production of this "spying" data concerning the activity of other HP1, HP2 processors. DATA2 data can thus take a form similar to "Insert database time, card, AID = 10". This is a command that writes to a database the time of a transaction, the type of the transaction (here of type "card") and an application identifier (.AID) of the transaction. This database is internal to the phone. The command could also be sent by the routing unit HCIADM to the processor HP1 for it to pass to an external application server for managing a user profile. NDEF Formatting of Complementary Application Data In each of the embodiments of the first aspect of the invention described above, as well as in a second aspect of the invention described later, it may be advantageous for the complementary data to be formatted. in an NDEF format. The NDEF format is well known to those skilled in the art and has been specifically designed for contactless data exchanges according to NFC technology. In particular, the NDEF format has been defined as part of the NFC Forum as a common data format for devices and chips that conform to the specifications of this Forum. This format therefore makes it possible to generate commands to which certain elements of the communication system would not otherwise have access. It will be noted that the NDEF format is unrelated to the HCI protocol for internal routing of data within an NFC system. The NDEF format is a data format for data transmitted in a contactless communication channel and is assumed to be interpretable by any NFC element receiving this data. For example, it is expected to code NDEF all the data inserted in the RFID tags.

Thus DATA2 in NDEF format can be encapsulated in a routing frame if a routing protocol is provided within the NFC system, or provided without encapsulation to the relevant application processor if no routing protocol is provided. In addition, the NDEF format also concerns the external application data DATAI (which is assumed to be read in this format when it is generalized) so that the result of the combination of the complementary data DATA2 and the application data DATAI (concatenation or blend) is also in NDEF format. To fix the ideas, the command "http: \\ www." in the format NDEF is written as follows: Dl 01 18 55 00 68 74 74 70 3A 5C 5C 77 77 77 2E

In this command, the values D1 01 18 55 00 form an NDEF header and the values 68 74 74 70 3A 5C 5C 77 77 77 2E form the text "http: \\ www.".

It will be noted here that, in one embodiment of the first aspect of the invention, the complementary application data DATA2 may also be security data related to DATAI data and generated by means of a DATAI data transformation function. . For example, the DTGEN may use an AUTHCT cryptographic coprocessor (see Fig. 8) to generate an encrypted signature of the DATAI data, forming the DATA2 data, and add such a signature to the DATAI data. The DATA2 signature data is then provided in NDEF format. They can also be concatenated or mixed (according to a certain mixing rule) with the DATAI application data, the result of the combination being then put in the NDEF format. This results in an NDEF command or data string that includes authentication data. These authenticator data: Lon are usable for example for

to authenticate the device equipped with the NFC system (here the mobile phone) with a service provider web server. If: The phone is not authenticated, the service is not provided by the web server This embodiment of the data management method according to the invention should not be confused with the fact, in itself known, adding a signature (e.g. CRC cyclic redundant verification code or cryptographic code) to data in order to secure a data transmission or to conduct error detection and correction steps. The DATA2 authentication data is here coded NDEF and does not form part of the routing protocol (if a routing protocol is used). They are seen by the application processor as DATAI data received via the contactless interface (eg data that would have been read in an RFID chip). Embodiments of the embodiments described above will now be described with reference to FIGS. 5 and 6. FIG. 5 illustrates an example of a complementary application data generation sequence according to the first embodiment of the first embodiment. aspect of the invention. In FIG. 5, step S10, DATAI application data are received by the NFCC2 processor via the CLINT interface. These data are provided by or read from an EXTD external device (see Fig. 4). The steps of initializing the contactless communication, including the exchange of RFID commands between the CLINT interface and the EXTD external device, are not shown for the sake of simplicity. More particularly, the DATAI data are received by the CLINT interface in a format specific to the contactless protocol used and are transmitted to the HCIADM routing member via a routing frame of type {CHANi; DATAI}

specific to the internal routing protocol used by the NFC system. It will be noted again that the use of a routing frame between the interface CLINT and the processor NFCC2 is not necessary if the interface CLINT does not form an individualized routing point Pc and is included in the processor NFCC2 from the point of view of routing. Step S10 triggers, in two possible variants, steps S11, S12, S13 or steps S14 and S15. Step S11 comprises supplying the DATAI data by the routing member HCIADM to the element HPi identified in the frame header by the channel number CHANi.

When: Step S12, the DTGEN member generates complementary application data DATA2. For this purpose the DATA2 data are for example read in a memory of the NFCR2 component to which the DTGEN member has access. This memory may comprise a correspondence table between several different complementary data and DATAI data identification parameters. These parameters can be determined by the DTGEN unit using an analysis of the received DATAI data. Thus, DATA2 data can be DATAI data. In step S13, the HCIADM routing nature feature encapsulates the DATA2 data in one transmits this new new routing and frame frame to the destination HPi element of the DATAI data using the same CHANT routing channel. As proposed above, DATA2 data can be in NDEF format. In a variant, step S10 directly triggers step S14, which is identical to step S12, but is carried out before the DATAI data is transferred to the processor HPi. The complementary DATA2 data is supplied to the routing unit HCIADM which combines them with the

DATAI data (concatenation or mixture) the set can be in NDEF format. Then: In step S15, the routing member transmits the data frame now including the DATAI data associated with the DATA2 data, to the recipient element HPi DATAI data. FIG. 6 illustrates an example of a complementary application data generation sequence according to the second embodiment of the first aspect of the invention. In FIG. 6, DATAI application data is exchanged via the CLINT interface between an external device EXTD and the host processor HP2. According to a variant (a), the DATAI data are read in the EXTD element via the CLINT interface or provided by the EXTD device at the CLINT interface. The DATAI data is then encapsulated in a frame of type {CHANi; DATAI} which is first transferred to the routing element HCIADM during a step S20 and is then transferred from the routing device to the host processor HP2 during a step S21 using the same routing channel . As indicated above, the routing action between the CLINT interface and the HCIADM member may be non-existent if the CLINT interface is part of the NFCC2 processor and is not seen by it as an individualized routing point. Step S21 triggers steps S24, S25 and S26 described below. According to a variant (b), DATAI data is sent by the secure host processor HP2 to the external device EXTD via the interface CLINT. In this case the DATAI data is encapsulated in a frame of type {CHANi; DATAI} and are routed to the HCIADM member during a step S22 and then routed to the CLINT interface during a step S23 (if it is seen as a routing point individualized by the NFCC2 processor). The DATAI data is then sent to the EXTD device in a frame specific to the

contactless communication protocol. Step S23 also triggers steps S24, S25 and S26. In step S24, the DTGEN generates additional application data DATA2. As indicated above, this DATA2 data is for example "spyware" application data that may include transaction time information, a type of communication, the content or the identifier of a selected file, the data read, the identity of the processor conducting the communication or transaction, etc. DATA2 data is provided to the HCIADM routing member. They can be in NDEF format, as previously explained. In step S25, the routing device encapsulates DATA2 data in a new routing frame of type {CHANj; DATAI} having a routing channel number other than ": i" and transmitting this frame to the application host processor HP1 for processing and analyzing the spying data. Optionally, during a step S26, the processor HP1 transmits this espionage data to an external server, the latter ensuring for example the management of the user's profile. In yet another variant, the NFCC2 processor has direct access to the Internet and directly transmits the espionage data to the external server EXTSVR, as illustrated by a dashed arrow in FIG. 6. In this case, it is considered that this server external is an element of the NFC system, although physically distant.

Second aspect of the invention generating application data in response to an NFC internal event In accordance with this second aspect of the invention, DATA3 application data is generated by the DTGEN in response to the realization an internal event. These data will be called "internal application data" to distinguish them from the data

complementary application DATA2 issued in connection with DATAI data exchange with an external device. As with the complementary application data DATA2, the internal application data DATA3 can be used by one of the application processors HP1, HP2, HP3 to execute a determined action. After being generated, DATA3 data is transferred to one of the host processors. If an HCI routing protocol is implemented in the NFC system, as has been assumed in the foregoing, the application data can then, as before, be integrated into a routing frame of the type {CHANi; DATA3} to be sent by the routing element HCIADM to the element of the NFC system identified in the CHANi header. In addition, DATA3 data can be NDEF formatted so that the application processor "sees" them as if they were received via the CLINT contactless interface. The internal event is for example the realization of an EVT clock event. In this case, the component NFCR2 is connected to a clock device CLKD or includes such a clock device (see Figs 4 and 8) and receives a clock signal CLK. The clock device CLKD is for example the quartz clock device of the mobile phone, external to the NFCS2 system, which allows the phone to calculate the time and date of the day. The clock signal CLK is for example a square or sinusoidal signal. For generating clock events, the component NFCC2 for example uses a counter CMPT (shown as being external to the processor NFCC2 in FIG. 4 for purposes of illustration) which generates the event EVT for example every "N" seconds after being activated. In an embodiment of this second aspect of the invention, in response to the realization of

the EVT event the NFCR2 component provides DATA3 data to one of the application processors of the NFC system. The DATA3 data is preferably in the NDEF format or in a format understandable to the application processor (the NDEF format being assumed here the standard format of the application processors). The NDEF formatted DATA3 data are for example an encrypted signature, a clock value, etc. In general, the various examples of complementary data DATA2 or data combination DATA1 and DATA2 described above can form internal application data DATA3. In an exemplary application, the NFCR2 component issues NDEF commands at times determined by the clock device and / or at regular intervals according to the clock signal CLK. The EVT clock event is for example a recurring event which corresponds to the flow of a determined period of time, for example 1 minute, 10 minutes, one hour ... The component NFCR2 may also include a pseudo generator. random dynamic password capable of generating a dynamic password on completion of the event. The internal event can also be the reception, by the NFCC2 processor, of a request REQj (command or instruction) issued by one of the host processors. Thus, in another embodiment of this second aspect of the invention, the component NFCR2, on receipt of: The request REQj issued by an NFC system element, for example the host processor HP2, generates DATA3 data that simulate data read from or provided by an RFID chip or other external EXTD device. The data DATA3 is transmitted to another host processor than the one having sent the request, for example the processor HP1. This embodiment makes it possible, for example, to simulate the reading of an RFID chip on request from one of the elements of the NFC system. That is

useful, for example, for transmitting to the application processor HP1 data conforming to a set of commands (for example data in the NDEF format) to which the element issuing the instructions, notably a SIM card, does not have access. Steps illustrating the implementation of these two embodiments above are shown in FIG. 7. According to a first variant (a), the processor NFCC2 receives the signal CLK from the clock device CLKD during a step S30. (This signal is received continuously but is shown schematically by step S30). The signal CLK triggers, at a given instant (for example every minute) the EVT clock event. The EVT event triggers steps S32 and S33 described below. According to a second variant (b), the processor NFCC2 receives a request REQj from the host processor HPj (where j = 1, 2 or 3) during a step S31. This request also triggers steps S32 and S33.

In step S32, the DTGEN member of the processor NFCC2 generates DATA3 application data. As indicated above, the data DATA3 may include a clock data (time, date, etc.), a specific command (variant a) or a command and / or a simulation of data read in or provided by an external device EXTD ( variant b). In step S33, the processor NFCC2 transfers the data DATA3 to one of the host processors HPi (where i = 1, 2 or 3). Here, this transfer is performed by the routing member HCIADM which encapsulates the DATA3 data in a routing frame of the type {CHANi; DATA3} and transmits this frame to the destination processor. In variant (b), the destination point Pi identified by the channel number CHANi is different from the point Pj that has issued the request REQj. As another example of application, the EVT clock event causes the sending to the host processor HP1,

by the DTGEN device, a security key generated by means of the AUTHCT cryptographic coprocessor (see Fig. 8) mentioned above. The processor HP1 then transmits this key to an external server EXTSVR to which the user has connected. The key is for example renewed every minute and is transmitted every minute to the website. Without this key the external server cuts the connection or refuses to perform the service. As represented by a dotted arrow in FIG. 7, the key can also be sent directly by the processor NFCC2 to the external server EXTSVR, considered in this case as an element of the NFC system. It will be apparent to those skilled in the art that the second aspect of the invention is independent of the first, since it is possible to configure the NFCR2 component to generate the internal DATAS application data without the configure to generate the complementary application data DATA2 at the time of transferring or routing DATAI application data, and vice versa. Similarly, as already indicated, the first and second aspects of the invention can be implemented independently of the implementation of a routing protocol within the NFC system, including the routing protocol which will now be described by way of example. Example of Routing Process For the sake of simplicity, it is assumed here and in what follows that the CLINT interface can transmit or receive data only in three protocols PT1, PT2, PT3, for example ISO 14443-A or "ISOA". , ISO 14443-B or "ISOB" and ISO 15693 or "ISO15". It has for example three operating modes Ml, M2, M3, namely "reader", "card emulation" and "device". It is also assumed that the CLINT interface is configured as a

source point or individual destination for data routing. The HCI protocol implemented here has the following general characteristics: the forecasting of CMD commands for managing a data path (routing channel), in particular commands for opening, closing and modifying data paths , these CMD commands comprising a header field and a routing data field comprising the characteristics of the routing channel, - the use of data frames comprising a header field having a routing channel number CHANi and a data field containing DATA application data.

The NFCC2 processor routes the data frames using a routing table that allows it to keep in memory the correspondence between each CHANT routing channel number and the characteristics of the corresponding routing channel.

The data paths stored in the routing table are differentiated from one another by at least the following parameters:

CHANi; IDsp, IDdp, Mi, PTi CHANT being the routing channel number assigned to the data path, IDsp an identifier of the source point of the data path, IDdp an identifier of the destination point of the data path, Mi and PTi being the mode and contactless communication protocol used by the CLINT interface to transmit or receive data over a non-contact data transmission channel. Whenever the processor NFCC2 assigns a CHANT routing channel number to a data path, it enters in the RT routing table the parameters IDsp, IDdp, Mi, PTi indicated in the command.

Commands for opening, closing, or modifying a data path are issued by one of the host processors HP1, HP2, HP3, or through the CLINT interface and specify the Mi operating mode and the PTi protocol of the host. CLINT interface for the data path concerned. If the opening of a data path is requested by one of the HP1, HP2, or HP3 host processors, the Mi mode and the PTi protocol in the command are used to configure the CLINT interface for the channel contactless communication that the CLINT interface must create to transmit the data that will be received via the data path. If the opening of a data path is requested by the CLINT interface, the Mi operating mode and the PTi protocol specified in the command issued by the CLINT interface are informative and specify the operating mode and protocol conditions. in which the CLINT interface has received the data it wants to transmit in the data path.

An example of a routing table created by the NFCC2 processor is described in Table 1 in Appendix 1, which is an integral part of the description. This routing table is created after receiving a series of route opening commands having source points located in one of the processors HP1, HP2 or HP3 (a source point P1, P2 or P3). Optionally, the NFCC2 processor may define a secondary destination point for receiving a copy of the data flowing in the data path. The secondary destination point or notification point is determined by the processor NFCC2 from a notification table (not shown in the figures) which indicates the data paths for which the data must be notified to the other host processor. . Although presented statically in Table 1, the routing table is dynamic and is updated in real time according to the commands of creation,

modification or deletion received by the NFCC2 processor. In an alternative embodiment, the routing table is static and has been prerecorded by the processor NFCC2, for example at the request of one of the host processors and when the system is powered up. Table 2 in Appendix 1 describes an example of a prerecorded routing table having, as source points, the points P1, P2 or P3 located in the host processors HP1, HP2, HP3. The CHANi channel number can also be prerecorded in the routing table for each possible routing configuration. In such a prerecorded table, a field "busy" and "open" or "authorized" is provided in each row of the table (a line corresponding to a routing channel). The processor NFCC2 writes the value "1" in the "open" field when it opens the corresponding data path, and writes the value "0" in response to a closing command of the data path. When a data path is used, the processor NFCC2 writes the value "1" in the "used" field. The transmission of the received data in the data frames is also under the control of the NFCC2 processor, which refers to the routing table to determine the destination points of this data. It is not necessary here that the source point that sends the data to the processor specifies all the parameters of the routing channel used: the header field of the routing frame simply includes parameter bits T and L and 6 channel number bits (allowing to simultaneously route 63 data paths, channel "0" being reserved for the administration of the HCI protocol). Thus, upon receipt of a routing frame, the NFCC2 processor returns the data to the designated destination point in the routing table, using the channel number as an index to find that destination point in the routing table.

(as well as eventually the point of notification). If the destination point is the Pc point (CLINT interface), the NFCC2 processor sets the CLINT interface to send the data in a non-contact data transmission channel according to the PTi contactless protocol information. and Mi operating mode appearing in the routing table. In an alternative embodiment, the CLINT interface itself performs its parameterization by reading the routing table when data is received in a routing frame. Thus, the routing table allows parameterization of the CLINT interface without the need to include the operating mode parameters Mi and contactless communication protocol PTi in the headers of the data frames. This routing table is therefore not a simple routing table in the conventional sense of the word, but also forms a parameterization table.

Table 3 in Appendix 1 describes an example of a dynamic routing table including data paths created at the request of the CLINT interface (having Pc as the source point). The routing table created here by the processor NFCC2 at the request of the CLINT interface indicates that the data must be sent to the three destination points P1, P2, P3 located in the host processors HP1, HP2, HP3, to the processor host that is not affected by the data to not respond to it and let the other host processor send response data to the CLINT interface. Data paths created at the request of one of the host processors HP1, HP2, HP3 or at the request of the CLIINT interface are preferably bidirectional. Thus, for example, once a data path has been created by a point P1 located in the processor HP1, to transmit data in a contactless communication channel defined by the mode parameter M2 and the

protocol PT2, all the data received by the interface CLINT in the mode M2 and following the protocol PT2 will be sent in this data path and will therefore be received by the point P1. Besides, the bidirectional data path prediction imposes a management of the data. possible conflicts, by prohibiting two bidirectional paths with different source and / or destination points using the same Mi mode and PTi protocol parameters for the CLINT interface. For example, the routing table described in Table 1 represents data paths that can not coexist (for example channel 1 and channel 9, these data paths being described in the same table for illustrative purposes only). Example of hardware and software architecture of the NFCR2L component FIG. 8 represents an example of a hardware architecture of the NFCR2 component of FIG. 4. The component comprises: the NFCC2 processor and the CLINT interface already described, as well as the device of FIG. CLKD clock (which remains optional if the second aspect of the invention is not implemented), - a memory array comprising a ROM1 program memory ROM (read only memory), a RAM type memory memory MEM2 (memory vivid), and an erasable and electrically programmable memory MEM3 of the EEPROM type in which the routing table RT is registered and in which the correspondence table possibly used by the DTGEN device can also be recorded, - an authentication circuit and a AUTHCT error correction including Data Encryption Standard (DES) and Elliptic Curve Cryptography (ECC) algorithms, or other cryptographic algorithms, - a connection port INT1 UART (Universal Asynchronous Receiving Transmitting) type, to which the host processor HP1 is connected here, - an ISO7816 type INT2 connection port to which the host processor HP2 is connected here (the processor HP2 being assumed here to be a SIM card ), an INT3 connection type SWP (Single Wire 5 Protocol) port for connecting the host processor HP3, a data bus DTB and an address bus ADB connecting the memory plane, the processor NFCC2, the interface CLINT and the ports INT1, INT2, INT3, and a CTB control bus allowing the NFCC2 processor 10 to control and access these various elements for reading and / or writing. It will be noted that the ADB, DTB, CTB buses and the INT: 1 to INT3 interfaces together form what has been previously referred to as the overall GP data path 15 of the NFC system (FIG 4). The interface CLINT and the ports INT1, INT2, INT3 each comprise a BUF1 input buffer with parallel input and a BUF2 output buffer with parallel output accessible in writing, respectively read, via the data bus and the bus. 'address. The exchange of data forming the routing commands or the data frames between the host processors HP1, HP2, HP3 and the NFCC2 processor or the CLINT interface is thus performed by data blocks of the size of the buffers BUF1, BUF2, And is clocked by the NFCC2 processor. FIG. 9 represents an exemplary software architecture of the component NFCR2 and the host processors HP1, HP2 (the host processor HP3 is not represented and assumed to have the same architecture as the host processor HP2). This software architecture comprises, for the NFCR2 component and the host processors of the system, several software layers ranging from the lowest level (data link layer) to the highest level (application layer). The representation that is made of these software layers in FIG. 9 is simplified with respect to the actual software architecture of a system.

NFC but is sufficient for those skilled in the art wishing to achieve the invention in the manner proposed herein. Each host processor HP1, HP2 comprises at least four software layers, in an increasing order of level: - a lower level layer HWML (Hardware Management Layer) which manages the operation of the hardware elements (hardware) allowing the host processors to exchange data with the NFCC2 processor. This is for example the management layer of the UART interface for the processor HP1 and the management layer of the ISO7816 interface for the processor HP2. an INTPL (Interface Protocol Layer) layer that manages the protocol of the communication ports INT1, INT2. This is for example the UART protocol management layer for the HP1 processor and the ISO7816 protocol management layer for the HP2 processor. an HCIL layer (HCI) which manages the HCI protocol described above, that is to say which manages the creation of a communication channel by generating the routing commands and processing the response messages with such commands . This layer relies on the INTPL and HWML layers which are almost transparent for it. a high level Application Layer (APL) layer that manages RFID applications such as those represented in FIGS. 2 and 4 (reading a smart card or an electronic tag, emulating a smart card, "device" mode with an external processor to exchange files, etc.). This layer can comprise several application programs, each one being secured or not (depending on the internal resources of the processor) and each using this type of protocol PTi and such operating mode Mi of the CLINT interface. Thus, this layer of high level relies on the layers HWML, INTPL and the layer HCIL, which are almost transparent for it. The speed of data transfer across the data paths created through the

The HCIL layer advantageously leads to a significant increase in the performance of the APL application layer. The source or destination points P1, P2 and P3 located in the host processors can be "services" (specific applications). These services may require the NFCC2 processor, each independently of the other, to create data paths to simultaneously use the CLINT interface (subject to mode and protocol collisions, as noted above). Thus, this software architecture makes it possible to implement a service as source or destination points of a data path, and allows the simultaneous creation of several data paths between two entities, for example between two host processors or between a processor host and the contactless transmission / reception interface. In a substantially similar manner, the NFCC2 processor comprises the following software layers: two HWML1 and INTPL layers of the same type as the HWML and INTPL layers present in the host processors. For the sake of simplification of the scheme, these layers are represented in the processor NFCC2 but are actually located in the ports INT1 and INT2, which are considered to be part of the NFCC2 processor, as well as the buses ADB, DTB, CTB. Indeed, the processing of the UART and 7816 protocols is provided here in the ports INT1, INT2, which make available to the processor NFCC2 their input and output buffers BUF1, BUF2 via the buses ADB, DTB, CTB. another low level layer HWML2 which allows the processor NFCC2 to write the buffers BUF1 and to read the buffers BUF2, via the buses ADB, DTB, CTB, by decomposing the data frames or the commands into blocks of data of the same size as buffers. an HCIADM layer or administration layer of the HCI protocol, which dialogs with the HCIL layers of the host processors HP1, HP2 as administrator of the

routing and form the organ HCIADM previously described. Thus, this layer executes the data path assignment tasks described above, and accesses the RT read and write routing table via the low level layer HWML2. a DTGEN layer forming the complementary data application data element DATA2 or of internal application data DATA3, which interacts with the HCIADM layer to implement one of the two aspects of the invention; as previously stated, the HCIADM and DTGEN layers can also be merged into a single software entity. a CLINTCL layer (Contactless Interface Control Layer) which manages the CLINT interface and which indicates to the latter the Mi mode in which it must be placed and the PTi protocol to be used to transmit data in a contactless communication channel. For this purpose, the CLINTCL layer exploits the parameters PTi and Mi present in the routing table. Specifically, the HCIADM writes these parameters to the routing table in response to open data path commands, while the CLINTCL layer searches for these parameters in the table using the channel number of the data frames as indexes. sent by HP1, HP2 host processors. This layer also controls the CLINT interface in non-contact data reception mode and cyclically asks it to scan the modes (reader mode, emulation mode, "device" mode ...) and, in each mode, to search for incoming data. This means that the CLINT interface emits a magnetic field at regular intervals to interrogate any contactless cards or tags (or other non-contact portable objects) that may be present in its interrogation field. The CLINT interface is also placed at regular intervals in a listening mode (mode

"emulation") to detect if an active mode reader is sending polling messages. an optional APL layer that can manage applications itself, like host processors. In this case, the data communication between the NFCC2 processor and the CLINT interface can be made via the communication channel HCI, if the CLINT interface is equipped with the INTPL layer, which is the case in the embodiment shown in Figure 9. This layer accesses the read and write correspondence table via the low level layer HWML2. Finally, the interface CLINT comprises the following software layers: on the processor side NFCC2, a low level layer HWML equivalent to the layer HWML2 of the processor NFCC2, for managing the data buffers BUF1, BUF2 via the buses ADB, DTB, BTC. an HCIL layer (as indicated above) which makes the CLINT interface compatible with the HCI protocol, on the side of the ACT antenna circuit, the Contactless Protocol Layer (CLPTL) and the Mode Control Layer (MCL) layers which ensure the control or the processing of the electrical signals applied to the antenna circuit ACT or received by it, for the implementation of the operating modes M1, M2, M3 and the protocols PT1, PT2, PT3. between the layers located on the side of the NFCC2 processor and the layers located on the side of the antenna circuit, a high level Layer (HLSL) central layer which makes it possible to define in the interface CLINT several source points or destination Pc to create multiple data paths with multiple points P1, P2, P3 in the APL application layers of the host processors HP1, HP2, HP3. Of course, this high level architecture is optional and multiple points Pc located virtually in the CLINT interface can be managed by the NFCC2 processor.

It will be apparent to those skilled in the art that the present invention is susceptible of various embodiments. Thus, the invention is not limited to a system comprising several host processors. It also covers the control of the execution of applications in a system having a single host processor and running several applications to communicate with each other. It should be noted that in the near future the host processors can be totally virtual and integrated in the NFCR2 component itself, which can then take the form of a multi-processor integrated circuit. Furthermore, although the examples of implementation of the invention described above relate to a mobile phone in which the processors H2, H3 are generally secure, applications of the invention may be based on the use of a processor HP2 host or even two HP2, HP3 host processors that are not secure, if these applications do not require a high level of security. Conversely, the host processor HP1 considered in the foregoing as the main processor of the NFC system in that it controls essential peripheral elements such as a display device or radiotelephone means, could be a secure processor.

42 Appendix 1 as an integral part of the description -Examples of routing tables Table 1: Example of dynamic routing table with source points located in HP1 or HP2 IDdp CHANi IDsp PTi Ni Send Notify Comments 1; ID (P 1). PTli Ml i ID (Pc) i ID (P2) Processor HP1 to CLINT interface: in ISOA reader mode 2 ID (Pl) PT2 M1 ID (Pc) - Processor HP1 to CLINT interface in ISOB drive mode 3 ID (Pl) PT3 Ml ID (Pc) - Processor HP1 to CLINT interface in I5015 reader mode 4 ID (Pl) PT1 M3 ID (Pc) ID (P2) Processor HP1 to CLINT interface in device mode ISOA 5 ID (Pl) PT2 M3 ID (Pc) ) - Processor HP1 to CLINT interface in "device" mode ISOB 6 ID (Pl) PT3 M3 ID (Pc) - Processor HP1 to CLINT interface in "device" mode ISO15 7 ID (Pl) - - ID (P2) Processor HP1 to SIM card (HP2) 8 ID (P2) - - ID (Pl) - SIM card (HP2) to HP1 processor 9 ID (P2) PT1 M1 ID (Pc) - SIM card (HP2) to CLINT interface in ISOA reader mode 10 ID (P2) PT2 Ml ID (Pc) ID (P2) SIM card (HP2) to CLINT interface in ISOB reader mode 11 ID (P2) PT3 M1 ID (Pc) ID (P2) SIM card (HP2) to CLINT interface in drive mode ISO15 12 ID (P2) PT1 M3 ID (Pc) - SIM card (HP2) to CLINT interface in "device" mode ISOA 13 ID (P2) PT2 M3 ID (Pc) ID (P2) Cart e SIM (HP2) to CLINT interface in "device" mode ISOB 14 ID (P2) PT3 M3 ID (Pc) ID (P2) SIM card (HP2) to CLINT interface in "device" mode ISO15 43 Table 2: Example table prerecorded routing with source points located in HP1 or HP2 IDdp CHANT IDsp PTi Mi Send Notify Open Busy Comments 1 ID (Pl) PTl Ml ID (Pc) ID (P2) 1 Processor HP1 to CLINT interface in drive mode ISOA 2 ID ( Pl) PT2M1 ID (PC) 1 - 0 Processor HP1 to CLINT interface in ISOB reader mode 3 ID (Pl) PT3M1 ID (Pc) - 0 Processor HP1 to CLINT interface in drive mode ISO15 4 ID (Pl) PT1M3 ID (Pc) ID (P2) 0 Processor HP1 to CLINT interface in "device" mode ISOA 5 ID (Pl) PT2 M3 ID (Pc) - 0 Processor HP1 to CLINT interface in "device" mode ISOB 6 ID (Pl) PT3 M3 ID (Pc) ) - 0 Processor HP1 to CLINT interface in "device" mode ISO15 7 ID (Pl) - - ID (Pc) 1 Processor HP1 to SIM card (HP2) 8 ID (P2) - -ID (P1) - 0 SIM card ( HP2) to HP1 processor 9 ID (P2) PTl Ml ID (Pc) - 0 SIM card (HP2 ) to CLINT interface in ISOA reader mode 10 ID (P2) PT2M1 ID (Pc) ID (P2) 0 SIM card (HP2) to CLINT interface in ISOB reader mode 11 ID (P2) PT3 Ml ID (Pc) ID (P2) 0 SIM card (HP2) to CLINT interface in ISO15 reader mode 12 ID (P2) PT1M3 ID (Pc) - 1 SIM card (HP2) to CLINT interface in "device" mode ISOA 13 ID (P2) PT2M3 ID (Pc) ID (P2) 0 SIM card (HP2) to CLINT interface in "device" mode ISOB 14 ID (P2) PT3M3 ID (Pc) ID (P2) 0 SIM card (HP2) to CLINT interface in "device" mode ISO15 44 Table 3 : Example of a dynamic routing table with a source point located in the CLINT interface and sending all the received data to the host processors HP1, HP2 CHANi IDsp PTi Ni IDdp Comments 40 ID (Pc) PT1 Ml ID (Pl) ID (P2 ) CLINT interface in ISO A drive mode to HP1, HP2 41 processors; ID (Pc); PT2; M1; ID (P 1); ID (P2) CLINT interface in ISO B drive to processor ~ s HP1, HP2 1 42 ID (Pc) PT3 M1 ID (Pl) ID (P2) CLINT interface in ISO 15693 drive mode to HP1 processors, HP2 43 ID (Pc ) PT1 M2 ID (P2) ID (P2) CLINT interface in ISO A emulation mode to HP1, HP2 processors 44 ID (Pc) PT2 ID M2 (Pi) ID (P2) CLINT interface in ISO B emulation mode to HP1, HP2 processors 45 ID (Pc) PT3 M2 ID (Pl) ID (P2) CLINT interface in ISO 15693 emulation mode to HP1, HP2 processors 46 ID (Pc) PT1 M3 ID (Pi) ID (P2) CLINT interface in ISO "device" mode A to processors HP1, HP2 47 ID (Pc) PT2 M3 ID (Pl) ID (P2) CLINT interface in "device" mode ISO B to processors HP1, HP2 48 ID (Pc) PT3 M3 ID (Pl) ID (P2) CLINT interface in ISO 15693 "device" mode to HP1, HP2 processors

Claims (25)

A method for managing application data (DATAI) in an NFC system comprising a contactless transmission / reception interface (CLINT), characterized in that it comprises the steps of: -generating, within of the NFC system, complementary application data (DATA2) in response to a routing action or transfer within the NFC system of external application data (DATAI) received or transmitted via the transmission / reception interface of contactless data, and - providing the complementary application data (DATA2) to at least one element (HP1-HP3, EXTSVR) of the NFC system. The method according to claim 1, comprising the steps of: - receiving the external application data (DATAI) via the contactless transmission / reception interface (CLINT), - generating the complementary application data (DATA2) within the NFC system, and transferring the external application data (DATAI) and the complementary application data (DATA2) to the same element (HP1-HP3) of the NFC system. The method of claim 2, including the step of concatenating or mixing the complementary application data (DATA2) and the external application data (DATAI) before transferring it to the element (HP1-HP3). NFC system. 4. Method according to one of claims 1 to 3, comprising the step of transferring the external application data (DATAI) and complementary data (DATA2) 45 to a main processor of the NFC system, ensuring the control of peripheral elements. comprising at least one display device. 5. Method according to one of claims 1 to 4, comprising the step of including in the complementary application data (DATA2) at least one of the following data. parameters for displaying the external application data (DATAI), data intended to be displayed with the external application data (DATAI), data forming with the external application data (DATAI) a control of connection to a server 15 accessible via the Internet, data forming with the external application data (DATAI.) a command to download a file from a server accessible via the Internet. 20 The method according to one of claims 1 to 4, comprising the step of generating the complementary application data (DATA2) from the external application data (DATAI), by means of a transformation function such as a function of cryptography (AUTHCT). 7. The method according to claim 1, comprising the steps of: - receiving from a first element (HP2) of the NFC system external application data (DATAI) and transmitting them via the transmission / reception interface of data, or receive the external application data (DATAI) via the data transmission / reception interface and transfer them to the first element (HP2) of the NFC system, 35 - generate the complementary application data (DATA2) at the within the NFC system, and-transfer to a second element (HP1, EXTSVR) of the NFC system the complementary application data (DATA2). The method of claim 7 including the step of including in the complementary application data (DATA2) espionage data relating to the external application data (DATA: L) or a transaction in the frame from which the external application data (DATAI) is exchanged. 9. Method according to one of claims 7 and 8, comprising the step of including in the complementary application data (DATA2) at least one of the following data: - transaction time information, - a information of a type of communication or transaction (AI: D), - an identifier of a file, - all or part of the external application data, - the identity of an element (HP1-HP3) of the system NFC to which the external application data is transferred or which transmits the application data. 10. Method according to one of claims 1 to 9, wherein the complementary application data (DATA2) are sent directly to an external server (EXTSVR). The method according to one of claims 1 to 9, wherein the complementary application data (DATA2) is generated in a specific format (NDEF) for simulating data that would be read in or provided by an external component (EXTD). via a contactless communication channel. The method according to claim 3, comprising a step of formatting in a given format (NDEF) the result of the concatenation or mixing of the complementary application data (DATA2) and the external application data (DATAI), to simulate data that would be read from or provided by an external component (EXTD) via a contactless communication channel. An application data management device (NFCR2) in an NFC-type communication system, comprising an NFC type contactless transmission / reception interface (CLINT) and a routing or data transfer processor (NFCC2, HCIADM, DTGEN) for carrying out application data transfer actions between at least two elements (HP1, HP2, HP3) of an NFC system intended to be connected to the data management device, characterized in that the routing or data transfer processor is configured to: generate, within the NFC system, complementary application data (DATA2) in response to a routing or transfer action within the NFC data system; external application (DATAI) received or transmitted via the contactless transmission / reception interface, and - supplying the complementary application data (DATA2) to at least one element (HP1-HP3, EXTSVR) of the system NFC . 30 The apparatus of claim 13, wherein the routing or data transfer processor is configured to receive, upon receipt by the NFC system of external application data (DATAI) via the data transmission / reception interface. non-contact (CLINT): -generate additional application data (DATA2) within the NFC system, and - transfer to the same element (HP1-HP3) of the NFC system the external application data (DATAI) and the data 5 complementary applications (DATA2). 15. Device according to one of claims 13 or 14, wherein the routing or data transfer processor is configured to concatenate or mix the complementary application data (DATA2) and the external application data (DATAI). before transferring them to the NFC system element (HP1-HP3). The device according to one of claims 13 to 15, wherein the routing or data transfer processor is configured to transfer the external (DATAI) and complementary (DATA2) application data to a main processor of the NFC system. controlling the peripheral elements comprising at least one display device Apparatus according to one of claims 13 to 16, wherein the routing or data transfer processor is configured to include in the complementary application data (DATA2) at least one of the following data. parameters for displaying the external application data (DATAI), data intended to be displayed with the external application data (DATAI), data forming with the external application data (DATAI) a connection control to a server accessible via the Internet; data forming with the external application data (DATAI) a command to download a file from a server accessible via the Internet. The apparatus according to one of claims 13 to 17, wherein the routing or data transfer processor is configured to generate the complementary application data (DATA2) from the external application data (DATAI), at the way of a transformation function as a cryptographic function (AUTHCT). The apparatus of claim 13, wherein the routing or data transfer processor is configured to respond to the provision by a first element (HP2) of the NFC system of external application data (DATAI) to be transmitted. via the data transmission / reception interface, or the reception via the external data / application data transmission / reception interface (DATAI) to be transferred to the first element (HP2) of the NFC system: - to generate the complementary application data (DATA2) within the NFC system; and - transferring the complementary application data (DATA2) to a second element (HP1, EXTSVR) of the NFC system. The apparatus of claim 19, wherein the routing or data transfer processor is configured to include in the complementary application data (DATA2) espionage data relating to the external application data (DATAI). or a transaction in which the external application data (DATAI) is exchanged. 21. Device according to one of claims 19 or 20, wherein the routing processor or data transfer is configured to include in the complementary application data (DATA2) at least one of the following data: - information transaction time, information of a type of communication or transaction (A: LD), identifier of a file, all or part of the external application data, identity of an element (HP1-HP3) of the NFC system to which the external application data is transferred or which transmits the application data. 22. Device according to one of claims 13 to 21, wherein the routing processor or data transfer is configured to directly send the complementary application data (DATA2) to an external server (EXTSVR). 15 Apparatus according to one of claims 13 to 21, wherein the routing or data transfer processor is configured to generate the complementary application data (DATA2) in a specified format (NDEF) to simulate data that would be 20 read from or provided by an external component (EXTD) via a contactless communication channel. An NFC system (NFCS2) comprising an application data management device according to one of claims 13 to 23 and at least one host processor (HP1-HP3) connected to the device. 25. An electronic portable object, in particular a mobile phone, comprising an NFC system according to claim 24.