HK1214065B - Nfc device comprising configurable notification means and a communication method for the same - Google Patents

Description

NFC device including configurable notification component and communication method thereof

Technical Field

The present invention relates to a near field communication device designed to establish a near field communication channel with an external device and provide application data transmitted by the external device to a first main processor of the device.

Background Art

So-called NFC technology (Near Field Communication) enables two devices, each of which includes an antenna coil, to exchange data through inductive coupling. Establishing an NFC channel requires that one of the two devices, called a "reader," emit a magnetic field, and the other, called a "card," brings its antenna coil close enough to one of the first devices for the magnetic field to generate an antenna signal in the latter. In another known NFC method, known as "peer-to-peer" (or point-to-point), each device alternately emits a magnetic field. In recent years, NFC devices have been developed that are designed to connect to a host processor and enable them to execute NFC applications in reader, card emulation, or peer-to-peer mode.

Figure 1 schematically illustrates the structure of a conventional NFC device D1 of the type described above. The device comprises a CLF (Contactless Front End) communication interface circuit, an NFC controller designated NFCC1, a program and data memory MEM1, and communication ports P1 and P2, all coupled via a bus BS. Ports P1 and P2 enable connection of host processors HP1 and HP2 to the device D1. Memory MEM1 receives the operating system OS of processor NFCC1 and the routing program RPGR executed by processor NFCC1. The interface circuit CLF is equipped with an antenna coil AC1 and is configured to establish an NFC channel with an external device EDV, which includes an antenna coil AC2.

Such near field communication devices are described in patents or patent applications EP 1 327 222, EP 1 758 049, EP 1 855 229, and EP 1 855 389. EP 1 327 222 teaches providing a card emulation mode. EP 1 855 229 describes a method for powering the device from a magnetic field received when the device is in card emulation mode. EP 1 855 389 describes a method for routing incoming data (data received by the interface circuit CLF) so that the host processor to which the data is intended can be determined. EP 1 327 222 describes a routing method using a routing table. Moreover, standards or specifications define certain features of the device more precisely, such as: the ETSI TS 102 622 standard (“Smart Card; UICC - Contactless Front End (CLF) Interface; Host Controller Interface (HCI)”); the ETSI TS 102 613 standard, which defines the operation of the CLF interface circuitry; or the NCI specification (“NFC Controller Interface”).

It is assumed here that the main processor HP1 is a secure component dedicated to applications requiring a certain level of security, in particular payment applications or applications that directly or indirectly involve payment, and that the processor HP2 is a non-secure processor having access to components for communicating with the user. The processor HP1 is, for example, a UICC-type card (Universal Integrated Circuit Card) equipped with NFC functionality or a more general secure element-type processor (a secure processor dedicated to NFC applications). The processor HP2 is, for example, the baseband processor of a mobile phone and also controls various human/machine interface peripherals, such as a display and input components (real or virtual keyboard).

FIG1 also illustrates an example application in which device D1 operates in card emulation mode for host processor HP1, enabling host processor HP1 to perform transactions with an external device EDV, such as a point-of-sale device. During this transaction, host processor HP1 and external device EDV exchange application data, such as APDU (Application Protocol Data Unit) data of the type described by the ISO 7816 standard. More specifically, the external device sends a command CAPDU (designated C-APDU in the standard), and host processor HP1 sends back a response RAPDU (designated R-APDU in the standard). Such data passes through device D1, and a controller ensures its routing from interface circuit CLF to host processor HP1 and vice versa.

When the transaction is complete, the main processor HP1 can provide information about the transaction to the processor HP2. The processor HP2 can then present such information to the user. For example, the processor HP2 can display a confirmation, possibly along with an audible signal: "Purchase transaction of product X for quantity Z on date Y."

Furthermore, the ETSI TS 102 613 standard (version V9.2.0) defines, in its paragraph 11.2, a method for enabling two host processors to exchange information about transactions. This method defines a connection gate, a "PRO_HOST_REQUEST" command, and the EVT_CONNECTIVITY, EVT_OPERATION_ENDED, and EVT_TRANSACTION events. The latter event is formed in the manner indicated below and includes the "AID identifier" ("application ID") of the application involved.

illustrate Code Length in bytes AID '81' 5 to 16 parameter '82' 0 to 255

This communication of information about the execution of a transaction depends on the configuration of the application executed by the processor HP1 or of the program that starts the application through the above-mentioned connection function.The communication of information related to a transaction to the third processor therefore requires the provision of specific programming lines when specifying the application.

Summary of the Invention

It would therefore be desirable to provide a method for transmitting information related to a transaction, taking into account that the information to be transmitted may differ from one application to another, wherein the transaction is independent of the application program executed by the host processor and the transaction can be managed and configured in a centralized manner for all applications.

Therefore, some embodiments of the present invention relate to a near field communication device, which is configured to establish a near field communication channel with an external device, and provide application data sent by the external device to a first main processor, provide notifications related to the characteristics or content of the application data provided to the first main processor to a second main processor, and configure the notifications according to characteristic parameters of the application in the framework of the data sent by the external device to the first main processor.

According to one embodiment, the device is designed to configure the notification according to at least one of the following characteristic parameters: an identifier of the application in the framework in which the external device sends data to the first host processor; a technology by which the near-field communication channel is formed; or a communication protocol by which the near-field communication channel is formed.

According to one embodiment, the device is designed to provide a notification to the second host processor, the notification comprising data present in the application data or an item of information regarding data present in the application data.

According to one embodiment, the device is configured to provide a notification to the second host processor of an identifier of the application contained in a frame in which the external device sends data to the first host processor.

According to one embodiment, the device is configured to identify application data sent by the external device, select a data analysis program based on the result of the data identification and the characteristic parameters of the application, analyze the application data through the selected analysis program, and configure notification based on the result of the data analysis.

According to one embodiment, the apparatus is configured to identify the application data via a series of identification masks by comparing each mask with the application data until a mask corresponding to the data is found.

According to one embodiment, the apparatus is configured to analyze the application data by combining the application data with a data mask forming or comprised in an analysis program of the selection.

According to one embodiment, said application data are command CAPDUs within the meaning of the ISO 7816 standard.

According to one embodiment, the device is configured to: provide application data sent by the first main processor to the external device, provide notification related to the characteristics or content of the application data sent by the first main processor to the second main processor, and configure the notification according to the characteristic parameters.

Some embodiments of the present invention also relate to a near field communication method, comprising the following steps: establishing a near field communication channel between an external device and a near field communication device; providing application data sent by the external device to a first main processor of the near field communication device; providing a notification related to the characteristics or content of the application data provided to the first main processor to a second main processor of the near field communication device; and configuring the notification according to characteristic parameters of the application in the framework of the data sent by the external device to the first main processor.

According to one embodiment, the notification is configured according to at least one of the following characteristic parameters: an identifier of the application in the framework of the external device sending data to the first main processor; a contactless communication technology, through which the near-field communication channel is formed; or a contactless communication protocol, through which the near-field communication channel is formed.

According to one embodiment, said notification provided to said second host processor comprises an item of data present in application data or information about data present in said application data.

According to one embodiment, the method includes the following steps: after receiving an application selection command sent by the external device and provided to the first main processor, providing a notification to the second main processor, the notification containing an identifier of the application in the frame in which the external device sends data to the first main processor.

According to one embodiment, the method includes the following steps: identifying application data sent by the external device; selecting a data analysis program based on the result of the data identification and the characteristic parameters of the application; analyzing the application data through the selected analysis program; and configuring notifications based on the result of the data analysis.

According to one embodiment, the method comprises the use of a routing and notification table for designating the first host processor and the second host processor according to a characteristic parameter of the application.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are described below with reference to, but not limitation to, the accompanying drawings, in which:

- FIG1 as described above schematically shows the hardware and software structure of a conventional NFC device,

- FIG2 schematically shows the hardware and software structure of an embodiment of an NFC device according to the present invention,

- FIG3 shows an embodiment of a notification configuration module according to the present invention,

- Figures 4A and 4B describe the steps of a notification method using the module of Figure 3,

- FIG5 shows another embodiment of a notification configuration module according to the present invention and an embodiment of a notification table according to the present invention,

- Figures 6A and 6B describe the steps of an embodiment of a notification method using the module of Figure 5,

- FIG. 7 shows another embodiment of a notification configuration module according to the present invention,

- Figure 8 shows another embodiment of a notification table according to the present invention, and

- Figure 9 shows an embodiment of a routing and notification table according to the present invention.

DETAILED DESCRIPTION

Figure 2 schematically illustrates the structure of an NFC device according to the present invention, designated D2. Device D2 has the same general structure as device D1 described above and includes a CLF communication interface circuit ("contactless front end"), an NFC controller "NFCC2," a program and data memory MEM2, and communication ports P1 and P2, all coupled via a bus BS. Ports P1 and P2 enable connection to host processors HP1 and HP2. Memory MEM2 receives an operating system OS, a routing program RPGR, which may include a routing table RT, and a notification program NPGR according to the present invention. The interface circuit CLF is equipped with an antenna coil AC1 and is configured to establish a near-field communication channel with an external device EDV, which itself includes an antenna coil AC2. Device D2 and host processors HP1 and HP2 can be located in a portable device MP, such as a mobile phone.

When the main processor HP1 and the external device EDV perform a transaction, the controller NFCC2 executes a routing procedure RPGR and transmits a command CAPDU sent by the external device EDV and received by the interface circuit CLF to the main processor HP1, or transmits a response RAPDU sent by the processor HP1 to the interface circuit CPF so that it is transmitted to the external device EDV. The controller also executes a notification procedure NPGR according to the present invention and transmits notifications related to the characteristics and/or content of the data CAPDUs and RAPDUs exchanged between the processor HP1 and the external device EDV to the processor HP2.

According to one embodiment, the controller sends the following notification to the processor HP2:

- N[AIDi]: application selection notification containing the application identifier AIDi present in the application selection command SELECT_AID transmitted to the processor HP1,

- NCj: notification related to the command CAPDUj received by the interface circuit CLF and transferred to the processor HP1,

- NRj: notification related to the command RAPDUj sent by the processor HP1 and transferred to the interface circuit CLF.

The notifications NCj, NRj associated with a command or response may include any type of information or data, such as:

- information about the characteristics of the command or response (e.g. the type of command),

- information about the content of the command or response (e.g., the presence of given data in the command or response), and/or

- One or more data items to be included in a command or response.

The notification NCj or NRj is generated according to a characteristic parameter of the application in the framework of the data APDU exchange between the external device EDV and the host processor HP1. In some embodiments described below, this characteristic parameter is the identifier AID of the application.

For this purpose, the notification program NPGR comprises a set of notification configuration modules MAi (MA0, MA1, ... MAn), each module Mai being associated with an identifier AIDi. The structure of the modules MAi is schematically represented in FIG3. Each module comprises:

- Command Identification Program (CIP)

- a set of command analysis rules (CAR0, CAR1, ... CAR _Ni ) associated with the commands CAPDUj (CAPDU0, CAPDU1, .. CAPDU _Ni ) that the procedure CIP can enable to be recognized, and

- a set of response analysis rules RARj (RAR0, RAR1, ... RAR _Ni ) associated with the response RAPDUj (RAPDU0, RAPDU1, ... RAPDU _Ni ) that the procedure CIP can enable to be identified

Each response analysis rule RARj is associated with a command analysis rule CARj, and each command analysis rule CARj is associated with a command CAPDUj that can be recognized by the program CIP. Each rule CARj enables the controller NFCC2 to generate a notification NCj that is transmitted to the processor HP2. Similarly, each rule RARj enables the controller to generate a notification NRj that is transmitted to the processor HP2.

Therefore, since the rules CARj, RARj by which notifications may be generated may be different, the same command CAPDUj or the same response RAPDUj may generate different notifications NCj, NRj depending on the application in the framework in which it is sent.

Furthermore, the identification program CIP associated with an application is not necessarily designed to recognize any command or response that the application is likely to use. When designing the program CIP, only the commands or responses for which notifications are desired should be considered. Furthermore, a command may generate a notification NCj, while the corresponding response itself does not generate a notification NRj, or vice versa.

4A and 4B illustrate an embodiment of the notification method according to the present invention implemented by the notification program NPGR. It is assumed here that the processor HP1 operates in card emulation mode, so that the input application data (data sent by the external device EDV and received by the interface circuit CLF) is a command CAPDU, and the output application data (data sent by the host processor HP1) is a response RAPDU.

Referring to FIG4A , the method includes an initial step S1 of waiting for the routing of incoming data CAPDUj received by the interface circuit CLF. When this data is routed to the processor HP1 by the routing program RPGR, the controller NFCC2 proceeds to step S2, where it determines whether the command CAPDUj is an application selection command "SELECT_AID." If so, the controller proceeds to step S3; otherwise, the controller proceeds to step S6.

In step S3, the controller extracts the identifier AIDi from the command CAPDUj. During step S4, the controller stores the command CAPDUj as the current command and the identifier AIDi as the current identifier. During step S5, the controller sends a notification N[AIDi] containing the identifier AIDi to the processor HP2 and then proceeds to step S12.

If the input data CAPDUj is not an application selection command, step S6 is executed after step S2. It is assumed that the identifier AIDi was already stored as the current identifier during the previous step S4, since the command SELECT_AID is the first command sent by the external device EDV at the start of the application. Therefore, in step S6, the controller selects the notification configuration module MAi associated with the current identifier AIDi from among all modules MA0 to Man. During step S7, the controller identifies the command CAPDUj using the program CIP present in module MAi and stores it as the current command in step S8. In step S9, the controller accesses the analysis rule CARj present in module MAi. In step S10, the processor uses the rule CARj to analyze the command CAPDUj and generates the notification NCj, which it sends to the main processor HP2 in step S11, before proceeding to step S12.

It should be noted that the step S4 of storing the identifier AIDi as the current identifier may comprise storing the rank "i" of this identifier in the list of identifiers and using the index associated with each rank i as a notification to the configuration module MAi. Similarly, the step S8 of storing the command CAPDUj as the current command may comprise storing the rank j of this command in the list of commands CAPDU0 to _CAPDUNi (a list of commands that the procedure CIP of the module MAi enables to be recognized), the parameter j allowing to find the analysis rules CARj, RARj applicable to the command CAPDUj.

In step S12 of FIG4B , the controller waits for outgoing data RAPDUj, sent by the main processor HP1, to be routed by the routing program RPGR to the interface circuit CLF. This data is assumed to be a response RAPDUj to the current command CAPDUj. When routing this outgoing data, the controller accesses the module MAi associated with the current identifier AIDi during step S13, and then accesses the response analysis rule RARj associated with the current command CAPDUj during step S14. In step S15, the controller uses the rule RARj to analyze the response RAPDUj and generates a notification NRi, which it sends to the main processor HP2 in step S16. The controller then returns to step S1, waiting for a new command to be routed to the processor HP1.

The method just described can include exceptions that prevent the processor NFCC2 from executing certain steps. In this case, a default notification can be provided. For example, if, in step S6, it appears that the current identifier AIDi is not pre-stored or that there is no notification configuration module MAi associated with the stored current identifier AIDi, the controller proceeds to step S17a, where it sends a notification related to the exception to the host processor HP2, and then proceeds to step S12. This notification indicates, for example, that no application identifier is associated with the command sent to the processor HP1, or that no notification configuration module is associated with the current identifier. In step S7, if the program CIP does not recognize the command CAPDUj, the controller proceeds to step S17b, where it sends a notification related to the exception to the processor HP2, and then proceeds to step S12. Similarly, in step S9, if the current module MAi does not contain any command analysis rules CARj, the controller proceeds to step S17c, where it sends a notification related to the exception, and then returns to step S12. In step S13, if the current identifier AIDi is not pre-stored, or if the controller does not find any module MAi corresponding to the current identifier, the controller proceeds to step S17d, in which it sends a notification related to the exception to the processor HP2, and then returns to step S1. Finally, in step S14, if the controller does not find any response analysis rule RARj associated with the current command CAPDUj in the module MAi, or if the current command CAPDUj is not pre-stored, the controller proceeds to step S17e, in which it sends a notification related to the exception to the processor HP2, and then returns to step S1.

In an alternative embodiment of the method, the step S1 of waiting for the routing of the input data and the step S12 of waiting for the routing of the output data are performed simultaneously, so that the controller can notify the processor HP2 of the routing of two consecutive commands without the processor HP1 sending any response to the first command (no output data). Moreover, it should be noted that if a second command is received after the first command without a response to the first command already sent by the processor HP1, the response sent by the latter after receiving the second command is considered to be a response to the second command and not to the first command.

FIG5 illustrates an embodiment of a notification configuration module MBi (MB0 to MBn) that replaces the module MAi described above. Each module MBi comprises three columns and Ni+1 rows (the number of rows can vary from module to module). Each row includes a command identification mask IMj in the first column, analysis rules CARj in the second column, and analysis rules RARj in the third column. Mask IMj is a bit string that is combined bit by bit with the command CAPDU to be identified using an XOR function. According to one embodiment, each mask IMj is accompanied by a value mask that is applied to the command using an AND function to remove insignificant bits or bits that cannot be identified using the mask (unpredictable value bits). The result ("clean" command) is then combined with the mask IMj using an XOR function. If the result of combining each bit of the command identification mask IMj with the corresponding bit of the command is equal to 0, the command is considered identified by this mask, and the analysis rules CARj and RARj are read in the row containing the mask IMj. In another embodiment, recognition of the command may be ensured by a configurable, hard-wired logic function that is a combined function of the value mask and the recognition mask.

As shown in FIG5 , a notification table AT1 is also provided, associated with each application identifier AIDi of a module MAi. Table AT1 comprises a first column containing the identifier AIDi or the rank i of the identifier, and a second column containing values A(MBi) (A(MB0), A(MB1), ... A( _MBn )) specifying the module MBi associated with the identifier AIDi. These values can be addresses in the memory MEM2 of the module MBi or indexed addresses of these modules, for example, the module's rank in the address index. Notification table AT1 thus forms a lookup table between application identifiers and corresponding notification configuration modules.

Furthermore, the command analysis rule CARj may include a data mask DMj or a more complex command analysis procedure than a data mask. Indeed, some known commands have a fixed-size data field located at a fixed position, which can be extracted using a data mask. Therefore, when the rule CARj includes a data mask DMj, this mask is combined with the command via an AND logic function, and the result of this combination is the data to be communicated to the processor HP2. However, other known commands have fields with variable positions and lengths, such as commands in TLV ("Type Length Value") format. Such commands then require locating a tag within them that allows the searched value to be found, which requires a more complex analysis procedure than a simple data mask.

However, it is assumed here that no data mask can be used in the response analysis rule RARj, since the analysis program is required to analyze the variable structure of the response RAPDU, generally in TLV or LV format, provided by the ISO 7816 standard.

6A and 6B show an embodiment of a notification method using a notification configuration module MBi and a notification table AT1. The method comprises the following steps:

- Step S20 (FIG. 6A): The controller waits for input data CAPDUj to be routed by the routing program, then proceeds to step S21,

- Step S21: The controller combines the command CAPDUj with the mask MAID1 dedicated to identifying the command SELECT_AID (see the example in Appendix 2) by means of an exclusive OR function (XOR). If the result is equal to 0, the command is an identifier selection command and the controller proceeds to step S22, otherwise the controller proceeds to step S25,

- step S22: by means of an AND logic function, the controller combines the command CAPDUj with the mask MAID2 dedicated to extracting the identifier AIDi, which forms the result of this operation (see the example in Appendix 2),

- Step S23: The controller stores the mask MAID1 as the current mask and the identifier AIDi as the current identifier or the rank "i" of the identifier,

- Step S24: the controller sends a notification N[AIDi] containing the identifier AIDi to the processor HP2, then proceeds to step S32,

- Step S25: The controller selects the notification configuration module MBi corresponding to the current identifier AIDi through the notification table AT1,

- step S26: the controller reads in the module MAi the first command identification mask IM0 or the next mask IM if the mask has already been read during a previous step S26,

- step S27: the controller combines the command CAPDUj with the mask IM by an XOR function, possibly after having applied the value mask to it; if the result is a bit string equal to 0, the controller proceeds to step S28, otherwise it returns to step S26 to read the next mask,

- Step S28: The controller stores the mask IM as the current mask IMj, or only stores the rank "j" of the mask,

- Step S29: The controller reads the analysis rule CARj associated with the mask IMj in the module MAi. If the rule CARj includes the data mask DMj, the controller proceeds to step S30a; if the rule includes the analysis procedure, the controller proceeds to step S30b,

- Step S30a: The controller combines the mask DMi with the command CAPDUj through an AND logic function to extract the command data to be notified,

- Step S30b: The controller analyzes the command CAPDUj by means of the rule CARj to obtain the items of information to be notified, which may include data extracted from the command,

- Step S31: The controller sends a notification NCj containing data and/or information to the processor HP2, then proceeds to step S32.

- Step S32: (FIG. 6B): The controller waits for the output data RAPDUj to be routed to the interface circuit CLF. As described above, the controller may simultaneously wait for the second command to be routed in step S20 to cover the case where two simultaneous commands are received,

- Step S33: the controller reads the rule RARj associated with the current mask IMj or with the mask MAID1 in the current module MBi,

- step S34: the controller analyses the response RAPDUj using the rule RARj (see the example in Appendix 2) and generates a response notification which may include or consist of the data present in the response,

- Step S35: The controller sends a notification NRj containing such information to the processor HP2.

As above, the method may include all or part of the following execution exceptions:

- in step S25, if the current identifier AIDi is not previously stored or if no module MBi is associated with the current identifier, the controller proceeds to step S36a, in which it sends a notification related to the exception to the processor HP2, and then proceeds to step S32,

- in step S26, if none of the masks IM0 to IM _Ni of the module MBi corresponds to the current command CAPDUj, the controller proceeds to step S36b, in which it sends a notification to the processor HP2 indicating that the command has not been recognized, and then proceeds to step S32,

- In step S33, if the controller does not find any current identifier AIDi, it proceeds to step S36c, in which it sends a default notification to processor HP2, indicating that unrecognizable data not linked to any known application has been sent by processor HP1. If the controller does not find any module MBi associated with the current identifier AIDi, it proceeds to step S36d, in which it sends a default notification to processor HP2, indicating that unrecognizable data linked to the identifier application AIDi has been sent by processor HP1. Finally, if the controller does not find any analysis rule RARj associated with the current identifier AIDi and with the stored current mask IMj, it proceeds to step S36e, in which it sends a default notification to processor HP2, indicating that an unrecognizable response has been sent by processor HP1.

FIG7 shows another embodiment of a notification configuration module MCi according to the present invention. The identification program CIP is common to all modules MCi, and each module MCi includes only analysis rules CARj, RARj. In this embodiment, the module MCi no longer needs to be a separately selectable element. The notification program can directly access the pair NRi,j from the current identifier AIDi and the analysis rules CARj, RARj from the current command CAPDUj.

The above describes an example of a notification method applied to a device D2 linked to two main processors HP1 and HP2, where only the main processor HP2 receives notifications regarding data routed to or sent by the processor HP1. In practice, the device may include three or more main processors, each of which is susceptible to receiving notifications regarding the activities of the other main processors. The notification method according to the present invention can therefore also be configured to generate multiple notifications.

Similarly, it has been assumed above that the main processor HP1 can manage only one application at a time, so that the notifications sent to the main processor HP2 are attached to the same application identifier, called the "current identifier". According to one embodiment, the processor HP1 and the external device EDV can carry out several applications simultaneously. In this case, the data exchanged in the framework of one application are distinguished from the data exchanged in the framework of another application by logical channels. Therefore, the ISO 7816 standard provides for the possibility of using 4 to 20 logical channels by parameterizing bits 0 and 1 of the first byte CLASS of a command or response (whose default value is 0 when only one application is executed at a time). The "global platform" specification provides for 4 additional bits, which define 16 logical channels in addition to the 4 logical channels provided by the ISO 7816 standard, that is, a total of 20 channels.

In this case, the storage of application identifiers is insufficient for selecting analysis rules applicable to commands and responses routed by device D2. Indeed, the identifier AIDi is present in the command SELECT_AID, but is not included in subsequent commands or responses. The notification method according to the invention uses in this case a notification table AT2 of the type represented in FIG8 , which, in addition to the columns containing the identifiers AID0 to AIDn (or their rank i) or the column containing the address A(MBi) of the communication configuration module MBi, also includes a "logical channel" column. This "logical channel" column is initially empty and is dynamically updated when a command SELECT_AID containing a logical channel number is received and routed to the main processor.

The steps of the method represented in FIG6A are then modified as follows:

In step S23, when the identifier AIDi has been extracted from the received first command SELECT_AID, the corresponding logical channel is recorded in the notification table AT2 in association with this identifier. Assuming that the identifier is "AID0" and the logical channel number selected by the external device is "CH01", the channel CH01 is associated with this identifier in the notification table AT2, as shown in Figure 8.

- During another iteration of step S23, when another identifier such as identifier "AID2" is extracted from another command SELECT_AID and assuming as an example that the logical channel number "CH02" is found in the command, in the notification table AT2, this logical channel number CH02 is associated with the identifier AID2.

- Then, when step S25 is executed, the logical channel number present in the received command is used as an entry point for the notification table AT2 to determine which module MA0 or MA2 must be selected. Therefore, in this embodiment, it is not necessary to store the identifier AIDi in step S23. Instead, the identity (address in memory or indexed address) of the module MA0, MA2 associated with each logical channel on which a command may be received is stored.

Some embodiments of the routing method according to the present invention have been described above, wherein the characteristic parameter selected to configure the notification is the identifier AIDi of the application or a logical channel associated with the identifier.

In other embodiments of routing method according to the present invention, can use other characteristic parameters of application to configure notification.Specifically, these parameters can be those that are used by routing program RPGR to determine the main processor of the destination point that forms input data.Under such situation, therefore might merge the routing table RT that will be used by routing program RPGR and the notification table that is used by notification program NPGR, to obtain route and the notification table RNT that substitutes traditional routing table RT.

A specific example of a routing and notification table RNT is described in Table 1 in Appendix 1 and is shown in Figure 9. The table RNT is designed here in conjunction with the NCI specification of the NFC Forum (TC DEV NCI 00058R013 NFCForum TS NCI 1.0).

NCI specification paragraph 5.3 recommends a routing method when the NFC device is in "listening" mode based on the following three parameters:

- Application Identifier AID,

- If the identifier AID cannot be found, the protocol,

- If agreement cannot be determined, then technology.

The NFC Forum's "Digital 1.0" specifications define "protocols" and "technologies." The protocols can be "Type 1 Tag," "Type 2 Tag," "Type 3 Tag," "Type 4 ATag," "Type 4B," "ISO-DEP," or "NFC-DEP." The technologies can be "Type A," "Type B," or "Type F," all of which use a 13.56 MHz carrier frequency, or any other so-called "proprietary" protocol, such as ISO 15. The NFC Forum's specifications define a technology as a set of transmission parameters, such as the RF carrier, communication mode, bit rate, module scheme, bit-level encoding, frame format, and protocol.

The routing and notification table RNT therefore comprises the following characteristic parameters for configuring routing and notification:

- AID: Application Identifier,

- "PROT": "Protocol" within the meaning of NCI specifications,

- "TECH": "Technology" within the meaning of NCI regulations.

- "BAT", the state of the battery of the device D2 (not shown in FIG. 2 ).

The identifier AID is found in the SELECT_AID command as described above (step S3 or S22). However, the routing program RPGR detects the identifier AID here for the purpose of routing the incoming data, and such detection therefore does not need to be performed again by the notification program. This can thus provide a simplification of the notification program. Generally speaking, the notification program and the routing program can be combined within the framework of routing and notification management based on the same characteristic parameters of the application. The protocol is detected during the so-called "discovery" step provided in the NCI specification. The technology is also detected during the "discovery" step. More precisely, in the section entitled "Behavior", the specification provides the following steps: 1 - Technology detection; 2 - Conflict handling (selection); 3 - Activation of the device; 4 - Data exchange; 5 - Deactivation of the device. The technology is identified in step 1, and the protocol is identified in steps 1 and 3.

The state of the battery can be "on" (battery with a satisfactory charge level), "low" (a level below a threshold), or "off" (battery empty or with insufficient charge to operate a particular unit of the device). Device D2 can have an empty battery mode of operation by obtaining energy from a magnetic field emitted by an external device EDV, as described in EP 1 855 229. In an alternative, a combination between the state of the battery and the state of the main processor ("on" for activation and "off" for deactivation) can be considered. A further column related to the state of the main processor should then be provided.

Furthermore, the routing and notification table RNT includes the following variables, which vary according to the feature parameters AID, PROT, TECH, BAT:

- TargProc1: specifies the target processor for routing the incoming data. It is assumed here that the device D2 is coupled to three main processors HP1, HP2, HP3, the processor HP3 being represented by a dotted line in FIG2 and connected to the port P3,

- TargProc2: specifies the target processor for sending notifications according to the present invention.

- A(MB): this column contains the values A(MB ₀ ), A(MB ₁ ), ..., A(MB _n ) as described above, which specify the module MBi, thanks to which it is possible to configure the notifications sent to the processor TargProc2 .

The NCI specification provides for determining the identity of the target processor (here "TargProc1") from the identifier AID if known or from the protocol if unknown (some NFC applications do not use the identifier AID) or even from the technology if neither the identifier AID nor the protocol can be determined.

The routing shown by table RNT thus takes into account three possibilities: known identifier AID, unknown identifier but known protocol, unknown identifier and protocol but known technology. The designations "PROT0", "PROT2", "PROT4", "TECH1", "TECH2" contained in table RNT are schematic and each corresponds to one of the above-mentioned protocols or technologies or any other applicable technology or protocol.

The architecture of the routing and notification table shows that the rules used to determine the target processor TargProc1 for routing input data can also be used to determine the processors to which notifications are sent and the notification configuration module to be used to configure these notifications.

According to one embodiment (not shown), the routing and notification table RNT includes a column "TargProc3" that specifies the second processor to receive the notification. It may also include a second column "MB" to specify a notification configuration module that can be used to generate the notification sent to the processor specified by the column "TargProc3". In this case, the notification can be configured differently depending on the processor to which the notification is sent.

Appendix 1

Forming the components of a description

Table 1 (Routing and Notification Table RNT)

Appendix 2

Forming the components of a description

1 – Example of identification mask for identifying command SELECT-AID

1.1 – Format of the command SELECT-AID

CLA INS P1 P2 Lc Inf Le 00 A4 04 00 xx AID 00

(Hexadecimal representation)

Command identification:

1.2 – Value Mask VM

(binary representation)

1.3 – Identifying Mask IM

(binary representation)

1.4 – Operations to be performed via mask

Match1 = [command to be analyzed] XOR VM (XOR = "exclusive OR")

Match2 = Match1 AND IM (AND = "and" function)

If Match2=00 00 00 00..., (hexadecimal), the command is recognized.

2 – Example of a mask for extracting the identifier AID of the command SELECT-AID

2.1 – Command Examples

CLA INS P1 P2 Lc Da0 Da1 Da2 Da3 Da4 Da5 Da6 Le 00 A4 04 00 07 A0 00 00 00 03 10 10 00

(Hexadecimal representation)

2.2 – Mask Example

The parameter Lc specifies the number of bytes present in the data field of the command APDU.In this example, the mask is calculated using parameter Lc=0.

CLA INS P1 P2 Lc D0 D1 D2 D3 D4 D5 D6 Le B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 00 00 00 00 00 FF FF FF FF FF FF FF 00

(Hexadecimal representation)

Bx = byte of command rank x

00 = unused byte

FF = byte to use

2.3 – Extracting Identifiers

AID_TEMP = [command to be analyzed] AND mask

AID = byte B5 to byte B(5+Lc-1)

AID = Byte B5 to Byte B11

3 – Example of identification mask used to identify command CAPDUj

3.1 Command Examples

"READ RECORD" command (MasterCard/PayPass transaction command). General format of the command:

Field Field Value describe CLA 00 Class byte that can be equal to 00 for payment applications INS B2 Command = READ RECORD P1 01 P1("Record Number") P2 xxxx x100 P2 (“reference control parameter”) Le 00 Response length

The field P2 above is expressed in binary, and the others are expressed in hexadecimal. The bits of value "x" are bits of variable value.

Such a command requires a different mask for each field ¨P1 ("record number"), since each READ RECORD command with field P1 invokes a different response. The number of masks depends on the amount of data to be retrieved and notified to the host processor. In this example, the mask can be as follows:

3.2 Examples of Value and Identification Masks

CLA INS P1 P2 Lc Inf Le 0000 0000 1011 0010 0000 0001 xxxx x 100 0000 0000

(binary representation)

The mask is a value mask (bit "x": bit to be ignored) and an identification mask (bits about 0 or 1), which can be decomposed into: a value mask, in which bit "x" is equal to 0 and all other values are equal to 1, which is combined with the command to be analyzed through the AND function; and an identification mask, in which all bits "x" are replaced with 0, while the other bits are kept to be combined with the result of the combination of the XOR function and the value mask.

4 – Example of an analysis procedure for analyzing a response (analysis rule RARj)

Example of a response:

The response is in TLV format (Type-Length-Value). In order to analyze its content, it is necessary to locate the tag that enables the value being searched to be found.

Example of a parser for a search on the "Placeholder Name" field:

The program must perform the following steps:

- Check SW1-SW2 = ‘9000’

- Locate tag '70' at the beginning of the response

- Position label '56' within the value of label '70'

The value is in a "Track 1 data" field that contains the name in a specific format (here, not a TLV format for historical reasons related to magnetic stripe cards, but with field delimiters). In this example, the "Track 1 data" can be sent to the host processor receiving the notification because the analysis used to extract the name would be too specific in the framework of the notification.

Claims (13)

1. A near-field communication device, comprising a communication interface circuit, a controller, a memory, and a communication port, and connected to a first main processor and a second main processor, wherein the near-field communication device is configured to: establish a near-field communication channel with an external device via the communication interface circuit, and provide the first main processor with application data sent by the external device. The controller is configured to, upon receiving application data transmitted via the external device: - Identify the application data sent by the external device. - Select a data analysis program based on the results of the data identification and based on the characteristic parameters of the application within the framework of the external device sending data to the first main processor. - Analyze the application data using the selected analysis program. - Configure notifications based on the results of the data analysis, the notifications relating to the characteristics or content of the application data provided to the first main processor, and - Provide the notification to the second main processor. 2. The near-field communication device according to claim 1, wherein the notification is configured according to at least one of the following characteristic parameters: - The identifier of the application within the framework of the external device sending data to the first main processor; and -The technique by which the near-field communication channel is formed; or... - The communication protocol that forms the near-field communication channel. 3. The near-field communication device according to any one of claims 1 and 2, configured to provide a notification to the second main processor, the notification including: data present in application data or information items about data present in the application data. 4. The near-field communication device according to any one of claims 1 to 2, configured to provide a notification to the second main processor, the notification including an identifier of the application in the framework of the external device sending data to the first main processor. 5. The near-field communication device according to any one of claims 1 and 2, configured to identify the application data by means of a series of identification masks in such a way that each mask is compared with the application data until a mask corresponding to the data is found. 6. The near-field communication device according to any one of claims 1 and 2, configured to analyze the application data by combining the application data with a data mask that forms a selected analysis program or is included in the selected analysis program. 7. The near-field communication device according to any one of claims 1 and 2, wherein the application data is a command within the meaning of the ISO 7816 standard. 8. The near-field communication device according to any one of claims 1 and 2, configured as follows: - Provide the external device with application data sent by the first main processor. - Provide the second main processor with a notification related to the characteristics or content of the application data sent by the first main processor; and Configure the notification based on the aforementioned feature parameters. 9. A near-field communication method implemented in a near-field communication device, the near-field communication device including a communication interface circuit, a controller, a memory, and a communication port, and connected to a first main processor and a second main processor, the method comprising the following steps: - A near-field communication channel is established between the external device and the near-field communication device via the communication interface circuit; - Provide the first main processor of the near-field communication device with application data sent by the external device; The method further includes the following steps: Once application data is received via the external device: - Identify the application data sent by the external device. - Select a data analysis program based on the results of the data identification and based on the characteristic parameters of the application within the framework of the external device sending data to the first main processor. - Analyze the application data using the selected analysis program. - Configure notifications based on the results of the data analysis, the notifications relating to the characteristics or content of the application data provided to the first main processor, and - Provide the notification to the second main processor. 10. The method of claim 9, wherein the notification is configured according to at least one of the following characteristic parameters: - The identifier of the application within the framework of the external device sending data to the first main processor; and - A contactless communication technology that forms the near-field communication channel; or... - A contactless communication protocol that forms the near-field communication channel. 11. The method according to any one of claims 9 and 10, wherein the notification provided to the second main processor comprises: data present in the application data or information items about data present in the application data. 12. The method according to any one of claims 9 and 10, comprising the step of: upon receiving an application selection command sent by the external device and provided to the first main processor, providing a notification to the second main processor, the notification containing an identifier of the application in the framework of data sent by the external device to the first main processor. 13. The method according to any one of claims 9 and 10, comprising: using a routing and notification table based on at least one characteristic parameter of the application, the notification table specifying the first main processor and the second main processor.