WO2012146871A1 - Module de gestion d'une transaction entre un terminal et un dispositif electronique - Google Patents

Module de gestion d'une transaction entre un terminal et un dispositif electronique Download PDF

Info

Publication number
WO2012146871A1
WO2012146871A1 PCT/FR2012/050904 FR2012050904W WO2012146871A1 WO 2012146871 A1 WO2012146871 A1 WO 2012146871A1 FR 2012050904 W FR2012050904 W FR 2012050904W WO 2012146871 A1 WO2012146871 A1 WO 2012146871A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
electronic device
terminal
module
dsp
Prior art date
Application number
PCT/FR2012/050904
Other languages
English (en)
Inventor
Yves Eonnet
Original Assignee
Tagattitude
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=46146964&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2012146871(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Tagattitude filed Critical Tagattitude
Priority to EP12722470.7A priority Critical patent/EP2702523B1/fr
Priority to US14/114,425 priority patent/US9817962B2/en
Priority to AP2013007196A priority patent/AP3899A/en
Priority to CA2833665A priority patent/CA2833665C/fr
Publication of WO2012146871A1 publication Critical patent/WO2012146871A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/65—Environment-dependent, e.g. using captured environmental data

Definitions

  • Management module for a transaction between a terminal and an electronic device
  • the present invention is in the field of communication terminals, and in particular in the field of smart terminals otherwise known as the Smartphone.
  • Some of these applications may be used to perform a transaction with the resident application of another electronic device.
  • transaction will be understood as any exchange of information for the purpose of obtaining an agreement between the resident terminal applications, under the authority of a secure server, sometimes also called a trusted server.
  • the invention relates to a transaction module that can be integrated in a terminal to authorize a transaction between a first application residing in this terminal and a second application residing in an electronic device, this module comprising:
  • the transaction between the terminal and the electronic device is validated by the secure server, as soon as it receives the same code of each of these entities.
  • the code is converted into an audio signal by the terminal (modulation), emitted by the speaker of the terminal and picked up by the microphone of the electronic device;
  • the code is sent by the electronic device to the secure server, either in audio format, that is to say as captured by the microphone, or converted into digital form when the electronic device includes a demodulation function or means of 'recording.
  • the demodulation can therefore be performed by the secure server.
  • the only means necessary for the electronic device are the microphone for picking up the audio signal and means of communication with the secure server for transmitting this audio signal. Therefore, the electronic device party to the transaction may be a conventional mobile phone.
  • the terminal comprises means for generating the code and the means for obtaining the transaction module obtain the code from these generation means.
  • the means for obtaining the transaction module comprise an interface with a memory constituting a code reservoir.
  • This memory can be internal or external to the terminal.
  • a limited number of codes are installed by a server in an internal memory of the terminal, giving it the ability to perform only a limited number of transactions.
  • the terminal accesses codes generated by a trusted server, under specific conditions that are not the subject of this patent.
  • the transaction module comprises a software interface with the first resident application, the software interface comprising a function used by the first resident application to request authorization of the transaction, and a function allowing the first application resident to receive a representative value of the authorization of the transaction by the electronic device and the validation of this transaction by the secure server.
  • the electronic device of this other part may or may not include means for demodulating the audio signal picked up by its microphone.
  • the invention relates to a transaction module that can be integrated in the electronic device to authorize a transaction between a first application residing in this electronic device and a second application residing in a terminal, this module comprising:
  • the invention relates to a transaction module that can be integrated into an electronic device to authorize a transaction between a first application residing in this electronic device and a second application residing in a terminal, this module comprising:
  • this module comprises a software interface with the first resident application, the software interface comprising a function used by the first resident application to request the transaction module of authorize the transaction.
  • the invention also relates to a transaction module that incorporates the means of a transaction module according to the first aspect and the means of a transaction module according to the second or third aspect.
  • FIG. 1 represents a transaction between two smartphones incorporating transaction modules according to a first embodiment of the invention
  • FIG. 2 represents a transaction between a smartphone of FIG. 1 and a conventional mobile telephone
  • FIG. 3 represents a transaction between two smartphones incorporating transaction modules according to a second embodiment of the invention.
  • FIGS. 4 and 5 show communication modules according to two particular embodiments of the invention.
  • FIG 1 shows two smart mobile phones TRM, DSP commonly called Smartphone.
  • the TRM smart mobile phone constitutes a terminal within the meaning of the invention.
  • the smart mobile phone DSP is an electronic device within the meaning of the invention.
  • Each of these smart phones AQ, DSP includes a MOD transaction module according to the invention.
  • This MOD transaction module interfaces mainly with a software application RES1, RES2 resident in the smart phone TRM, DSP.
  • COM communication means of the smart phone interfaces with COM communication means of the smart phone and with software drivers DRV (driver) able to control devices of the smart phone, specifically an HP speaker in the case of the TRM smartphone and a MIC microphone in the case of the DSP smartphone.
  • DRV software drivers
  • the transaction module MOD furthermore comprises a software interface that makes it easy for the developer of the resident applications RES1, RES2 to interface with this transaction module.
  • the modem transaction module MOD of the smart phone TRM offers a software interface API with the first resident application RES1, this interface comprising two functions AUT_RQ, AUT_RX usable by the first resident function RES1, the function AUT_RQ to request authorization of a transaction and function AUT_RX to receive, a value representative of the authorization of the transaction by the smartphone DSP and the validation of this transaction by a secure server SRV; and
  • the MOD transaction module of the smart phone DSP offers the resident application RES2 an AP2 software interface comprising a function AUT_TX used by this resident application to request the transaction module MOD to authorize the transaction.
  • the COM communication modules included in the operating systems OS of each of the smart phones TRM, DSP are able to communicate with the aforementioned secure server SRV.
  • the smart phones TRM, DSP and the secure communication server SRV communicate via a mobile telecommunications network.
  • TR transaction can be performed between resident RES1, RES2 applications in smart phones TRM and DSP, in cooperation with the secure server SRV.
  • the mobile terminal TRM has an interface 34 to obtain OTP codes stored in a storage unit 15.
  • each of these codes is unique. It can preferably be designed to be used only once: it is called a one-time code OTP.
  • the resident application RES1 of the smart phone TRM uses the software application AUT_RQ provided by the programming interface API of the module MOD.
  • This function triggers the obtaining, by the transaction module MOD of the smart phone TRM, of an OTP code, via the interface 34, from the memory 15.
  • This OTP code is sent by the communication means OC of the operating system OS of the smart phone TRM to the secure server SRV in a validation request RQVAL.
  • RQVAL validation request
  • the validation request RQVAL also includes the identifiers TRM, DSP of the smart phones TRM, DSP.
  • the transaction module MOD of the TRM smartphone then converts the OTP code into an AUD audio signal. It uses for this purpose own conversion means CONV.
  • the TRM smartphone's MOD transaction module sends the AUD audio signal to an HP speaker on this phone for playback.
  • the interface between the MOD transaction module and the DRV software drivers controlling this loudspeaker is referenced 32.
  • the smart phones TRM and DSP must be close enough, and for example positioned "head-to-tail", so that the audio signal AUD, output by the speaker HP of the smartphone TRM, is captured by the MIC microphone of the smart phone DSP.
  • the DRSP software driver of the OS operating system of the DSP smartphone in charge of controlling the microphone, routes this AUD audio signal to the MOD transaction module of this phone.
  • the conversion means CONV of this transaction module MOD converts the audio signal AUD to regenerate the OTP (demodulation) code.
  • the transaction module MOD of the smart phone DSP command, via the interface 31, sending, to the secure server SRV of a message MSG including the OTP code obtained by conversion AUD audio signal received via the acoustic channel established between the HP speaker and the MIC microphone.
  • the secure server SRV is therefore able to verify that the OTP code received from the first smartphone TRM is identical to that received from the second smartphone DSP, this identity being representative of the acceptance, by the smartphone DSP of the transaction proposed by the TRM smart phone.
  • the SRV secure server sends a validation MSGVAL message to the TRM smart phone.
  • MSGVAL includes the OTP code and the DSP identity of the DSP smartphone.
  • This message is received by the transaction module MOD of the smart phone TRM via the interface 31.
  • the function AUT_RX accessible via the API software API of the transaction module MOD then returns to the resident function RES1 a value representative of the authorization of the transaction TR by the smart phone DSP and the validation of this transaction by the secure server SRV.
  • FIG. 2 shows a TRM smart mobile phone and a conventional TEL mobile phone conforming to the GSM standard.
  • the smart mobile phone TRM described with reference to this figure is identical to that described with reference to FIG.
  • the TEL mobile phone does not include a MOD transaction module according to the invention.
  • the MOD transaction module according to the invention is included in the secure server SRV.
  • the SRV server when the SRV server receives the validation request RQVAL comprising an OTP code of the smart phone TRM and the conventional telephone number TEL, it establishes a CH communication channel GSM with the conventional telephone TEL.
  • This communication channel enables the secure server SRV to receive the audio signal AUD sensed by the microphone MIC of the conventional telephone TEL.
  • the transaction module MOD of the secure server converts the audio signal AUD to generate the OTP code.
  • the secure server SRV is therefore able to verify that the OTP code received from the TEL telephone, in AUD audio form, by the GSM CH channel corresponds to that received from the TRM smart phone in the RQV validation request.
  • FIG. 3 shows two smart mobile phones TRM, DSP according to another embodiment of the invention.
  • the intelligent mobile phone TRM differs from that described in FIG. 1 in that its transaction module MOD generates a complex audio signal AUD * consisting of a first portion of audio signal CHRP and a second portion of audio signal AUD.
  • the first part CHRP is a predetermined audio signal, very easily recognizable.
  • the second part AUD corresponds to the conversion of the OTP code, as in the example of Figure 1.
  • the DSP smartphone differs from that of FIG. 1 in that its transaction module includes a detection unit CHRDET capable of detecting the first part of the audio signal CHRP when a complex audio signal AUD * is picked up by the microphone MIC.
  • a detection unit CHRDET capable of detecting the first part of the audio signal CHRP when a complex audio signal AUD * is picked up by the microphone MIC.
  • the detection unit CHRDET controls the recording means REC of the transaction module MOD so that they record the second part AUD of the signal AUD *, the recording, noted OTP *, being communicated to the server Secure SRV to validate the transaction.
  • the secure server SRV is therefore able to verify that the OTP code received from the first smart phone TRM corresponds to the OTP * record received from the second smartphone DSP, this correspondence being representative of the acceptance by the telephone Smart DSP of the transaction proposed by the TRM smart phone.
  • the invention can be used for any type of transaction, the interface of the transaction module MOD with the resident applications RES1, RES2 being generic.
  • MOD transaction modules can be used to play both roles.
  • FIG. 4 represents, for this purpose, a transaction module in a first preferred embodiment of the invention.
  • This transaction module comprises, in this example, an interface 31 with means for communicating an electronic device or a terminal, means 33 for interfacing with a microphone, means 32 for interfacing with a loudspeaker. speaker, means for converting an audio signal into an OTP code, and vice versa, an interface 34 for receiving an OTP code, and API, AP2 software interfaces with the resident applications in the electronic device or the terminal.
  • FIG. 5 represents a transaction module in a second preferred embodiment of the invention.
  • This transaction module differs from that of FIG. 4 in that the conversion module CONV only provides the modulation part but not the conversion of the audio signal received by the microphone MIC into OTP code. It includes CHRDET means for detecting the first part of the audio signal and REC means for recording the second part of the audio signal, this recording being sent to the secure server by the electronic device DSP which incorporates it with which it communicates via the interface 31.
  • the data exchanged between the TRM terminal and the SRV server consisted of the OTP code and the DSP, TRM identifiers. Only the OTP code is absolutely essential. In some applications, TRM and / or DSP credentials may not be communicated.
  • the server SRV maintains a database in which it records the identifiers of the equipment that incorporate a transaction module MOD within the meaning of the invention. This allows the server to spontaneously establish a GSM communication channel CH with the electronic device DSP, as in the example of Figure 2, when the electronic device does not have MOD module.
  • the transaction module MOD can be incorporated in terminals or electronic devices of any type: mobile communication terminals, cash register, cash dispenser, fixed terminal, smart card, SIM card, etc.
  • the transaction module MOD can also be integrated in a lock, the transaction between the lock and the electronic device DSP being in this case a door opening request subject to validation of the secure server SRV.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Ce module de transaction (MOD) peut être intégré dans un terminal pour autoriser une transaction entre une première application résidant dans ce terminal et une deuxième application résidant dans un dispositif électronique, ce module (MOD) comportant: - des moyens (10) pour obtenir un code (OTP); - une interface (31) avec des moyens (COM) de communication du terminal permettant l'envoi, à un serveur sécurisé, d'une requête de validation comportant le code (OTP); - des moyens (CONV) pour générer un signal audio (AUD) à partir du code (OTP); - une interface (32) avec un module du terminal apte à envoyer le signal audio (AUD) vers un haut-parleur (HP) du terminal en vue de sa restitution; et - des moyens (10) pour autoriser la transaction (TR) sur réception d'un message de validation en provenance du serveur sécurisé (SRV), ce message étant représentatif de la réception, par le serveur sécurisé, dudit code (OTP) en provenance du dispositif électronique

Description

Module de gestion d'une transaction entre un terminal et un dispositif électronique
Arrière-plan de l'invention
La présente invention se situe dans le domaine des terminaux de communication, et en particulier dans le domaine des terminaux intelligents autrement connus sous le nom de Smartphone.
Depuis peu, ces terminaux se sont fortement développés, et offrent la possibilité, à leurs utilisateurs, d'y installer de nombreuses applications dites applications résidentes.
Certaines de ces applications peuvent être utilisées pour effectuer une transaction avec l'application résidente d'un autre dispositif électronique.
Dans ce document, on entendra par transaction, tout échange d'informations dans le but d'obtenir un accord entre les applications résidentes de terminaux, sous l'autorité d'un serveur sécurisé, parfois aussi appelé serveur de confiance.
Le frein majeur, dans l'état actuel de la technique, au déploiement de ces transactions entre terminaux est indiscutablement dû au fait qu'il n'existe pas de solution simple pour la mise en place de ces mécanismes de transaction, solution pouvant s'appliquer de la même façon à tout type d'application résidente, quel que soit son contexte.
Par ailleurs, et de façon très dommageable, les solutions connues à ce jour imposent que les deux terminaux parties à la transaction mettent en œuvre la même application de gestion de la transaction ou du moins une application compatible
L'invention permet de résoudre les inconvénients précités. Obiet et résumé de l'invention
Plus particulièrement, et selon un premier aspect, l'invention concerne un module de transaction pouvant être intégré dans un terminal pour autoriser une transaction entre une première application résidant dans ce terminal et une deuxième application résidant dans un dispositif électronique, ce module comportant:
- des moyens pour obtenir un code ; - une interface avec des moyens de communication du terminal permettant l'envoi, à un serveur sécurisé, d'une requête de validation comportant le code ;
- des moyens pour générer un signal audio à partir du code ;
- une interface avec un module du terminal apte à envoyer le signal audio vers un haut-parleur du terminal en vue de sa restitution; et
- des moyens pour autoriser la transaction sur réception d'un message de validation en provenance du serveur sécurisé, ce message étant représentatif de la réception, par le serveur sécurisé, du code en provenance du dispositif électronique.
Ainsi, et d'une façon générale, la transaction entre le terminal et le dispositif électronique est validée par le serveur sécurisé, dès lors qu'il reçoit le même code de chacune de ces entités.
Conformément à l'invention :
- Le code est envoyé par le terminal au serveur sécurisé de façon numérique ;
- Le code est converti en signal audio par le terminal (modulation), émis par le haut-parleur du terminal et capté par le microphone du dispositif électronique ;
- Le code est envoyé par le dispositif électronique au serveur sécurisé, soit en format audio, c'est-à-dire tel que capté par le microphone, soit converti sous forme numérique lorsque le dispositif électronique intègre une fonction de démodulation ou des moyens d'enregistrement.
De façon très avantageuse, la démodulation peut donc être effectuée par le serveur sécurisé. Dans ce mode de réalisation, les seuls moyens nécessaires au dispositif électronique sont le microphone pour capter le signal audio et des moyens de communication avec le serveur sécurisé pour lui transmettre ce signal audio. Par conséquent, le dispositif électronique partie à la transaction peut être un téléphone mobile conventionnel.
Dans un mode de réalisation le terminal comporte des moyens pour générer le code et les moyens d'obtention du module de transaction obtiennent le code à partir de ces moyens de génération. Dans un mode de réalisation, les moyens d'obtention du module de transaction comportent une interface avec une mémoire constituant un réservoir de codes.
Cette mémoire peut être interne ou externe au terminal. Dans un mode de réalisation, un nombre limité de codes est installé par un serveur dans une mémoire interne du terminal, lui donnant la possibilité de ne réaliser qu'un nombre limité de transactions. Dans un autre mode de réalisation, le terminal accède à des codes générés par un serveur de confiance, sous des conditions déterminées qui ne font pas l'objet de ce brevet.
Dans un mode de réalisation, le module de transaction comporte une interface logicielle avec la première application résidente, l'interface logicielle comportant une fonction utilisée par la première application résidente pour demander l'autorisation de la transaction, et une fonction permettant à la première application résidente de recevoir une valeur représentative de l'autorisation de la transaction par le dispositif électronique et de la validation de cette transaction par le serveur sécurisé.
On considère en effet que le fait que le signal audio ait été reçu par le dispositif électronique est la preuve que l'utilisateur de ce dispositif électronique autorise la transaction, car cela lui impose de positionner son dispositif électronique à une distance très courte du haut-parleur du terminal.
On se place maintenant du point de vue de l'autre partie à la transaction.
Il a déjà été mentionné que le dispositif électronique de cette autre partie pouvait ou non comporter les moyens de démodulation du signal audio capté par son microphone.
Ainsi, et selon un deuxième aspect l'invention concerne un module de transaction pouvant être intégré dans le dispositif électronique pour autoriser une transaction entre une première application résidant dans ce dispositif électronique et une deuxième application résidant dans un terminal, ce module comportant:
- une interface pour recevoir un signal audio capté par un microphone du dispositif électronique, le signal audio ayant été émis par un haut-parleur du terminal; - des moyens aptes à générer un code à partir du signal audio ; et
- une interface avec des moyens de communication du dispositif électronique permettant l'envoi du code, à un serveur sécurisé, dans le but d'autoriser la transaction.
Et selon un troisième aspect, l'invention concerne un module de transaction pouvant être intégré dans un dispositif électronique pour autoriser une transaction entre une première application résidant dans ce dispositif électronique et une deuxième application résidant dans un terminal, ce module comportant:
- une interface pour recevoir un signal audio capté par un microphone du dispositif électronique, le signal audio ayant été émis par un haut-parleur du terminal;
- des moyens aptes à détecter une première partie du signal audio ; et
- une interface avec des moyens de communication du terminal permettant l'envoi de l'enregistrement d'une deuxième partie du signal audio enregistrée suite à ladite détection, à un serveur sécurisé dans le but d'autoriser la transaction.
Dans un mode de réalisation du module de transaction selon ce deuxième ou se troisième aspect, ce module comporte une interface logicielle avec la première application résidente, l'interface logicielle comportant une fonction utilisée par la première application résidente pour demander au module de transaction d'autoriser la transaction.
L'invention concerne aussi un module de transaction qui incorpore les moyens d'un module de transaction selon le premier aspect et les moyens d'un module de transaction selon le deuxième ou selon le troisième aspect.
Brève description des dessins
D'autres caractéristiques et avantages de l'invention ressortiront de la description faite ci-dessous en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu du tout caractère limitatif.
- La figure 1 représente une transaction entre deux téléphones intelligents incorporant des modules de transaction conformes à un premier mode de réalisation de l'invention ;
- La figure 2 représente une transaction entre un téléphone intelligent de la figure 1 et un téléphone mobile conventionnel ; - La figure 3 représente une transaction entre deux téléphones intelligents incorporant des modules de transaction conformes à un deuxième mode de réalisation de l'invention ; et
- Les figures 4 et 5 représentent des modules de communication selon deux modes particuliers de réalisation de l'invention.
Description détaillée d'un premier mode de réalisation de l'invention
La figure 1 représente deux téléphones mobiles intelligents TRM, DSP communément appelés Smartphone.
Le téléphone mobile intelligent TRM constitue un terminal au sens de l'invention.
Le téléphone mobile intelligent DSP constitue un dispositif électronique au sens de l'invention.
Chacun de ces téléphones intelligents AQ, DSP comporte un module MOD de transaction conforme à l'invention.
Ce module de transaction MOD s'interface principalement avec une application logicielle RES1, RES2 résidente dans le téléphone intelligent TRM, DSP.
II s'interface également avec un système d'exploitation OS de ces téléphones intelligents.
Plus précisément, dans l'exemple de réalisation décrit ici, il s'interface avec des moyens COM de communication du téléphone intelligent et avec des pilotes logiciels DRV (driver) aptes à contrôler des périphériques du téléphone intelligent, plus précisément un haut-parleur HP dans le cas du téléphone intelligent TRM et un microphone MIC dans le cas du téléphone intelligent DSP.
Dans le mode de réalisation décrit ici, le module de transaction MOD comporte en outre une interface logicielle permettant aisément au développeur des applications résidentes RES1, RES2 de s'interfacer avec ce module de transaction.
Plus précisément, dans l'exemple de réalisation décrit ici :
- le module de transaction MOD du téléphone intelligent TRM offre une interface logicielle API avec la première application résidente RES1, cette interface comportant deux fonctions AUT_RQ, AUT_RX utilisables par la première fonction résidente RES1, la fonction AUT_RQ pour demander l'autorisation d'une transaction et la fonction AUT_RX pour recevoir, une valeur représentative de l'autorisation de la transaction par le téléphone intelligent DSP et de la validation de cette transaction par un serveur sécurisé SRV ; et
- le module de transaction MOD du téléphone intelligent DSP offre à l'application RES2 résidente une interface logicielle AP2 comportant une fonction AUT_TX utilisée par cette application résidente pour demander au module de transaction MOD d'autoriser la transaction.
Les modules de communication COM compris dans les systèmes d'exploitation OS de chacun des téléphones intelligents TRM, DSP sont aptes à communiquer avec le serveur sécurisé SRV précité.
De façon préférée, les téléphones intelligents TRM, DSP et le serveur de communication sécurisé SRV communiquent via un réseau de télécommunications mobile.
Nous allons maintenant expliquer en détail comment une transaction TR peut être effectuée entre les applications RES1, RES2 résidentes dans les téléphones intelligents TRM et DSP, en coopération avec le serveur sécurisé SRV.
Nous supposerons, dans cet exemple, que le terminal mobile TRM comporte une interface 34 pour obtenir des codes OTP mémorisés dans une unité de stockage 15.
Ces codes sont, dans cet exemple, générés par un serveur de confiance non représenté.
Quoi qu'il en soit, chacun de ces codes est unique. Il peut préfé- rentiellement être conçu pour n'être utilisé qu'une seule fois : on parle alors de code à usage unique ou en anglais « one time password » OTP.
Nous supposerons dans cet exemple que les applications résidentes RES1, RES2 s'apprêtent à réaliser une transaction et ont au préalable établi un dialogue, éventuellement échangé des informations, qui ne font pas partie à proprement parler de l'invention.
Pour demander l'autorisation de la transaction TR, l'application résidente RES1 du téléphone intelligent TRM utilise l'application logicielle AUT_RQ fournie par l'interface de programmation API du module MOD.
Cette fonction déclenche l'obtention, par le module de transaction MOD du téléphone intelligent TRM, d'un code OTP, via l'interface 34, à partir de la mémoire 15. Ce code OTP est envoyé par les moyens CO de communication du système d'exploitation OS du téléphone intelligent TRM au serveur sécurisé SRV dans une requête de validation RQVAL. Sur la figure 1, on a référencé 31 l'interface entre le module de transaction MOD et ces moyens de communication COM.
Dans le mode de réalisation décrit ici, la requête de validation RQVAL comporte aussi les identifiants TRM, DSP des téléphones intelligents TRM, DSP.
Le module de transaction MOD du téléphone intelligent TRM convertit ensuite le code OTP en un signal audio AUD. Il utilise à cet effet des moyens propres de conversion CONV.
Le module de transaction MOD du téléphone intelligent TRM envoie le signal audio AUD vers un haut-parleur HP de ce téléphone en vue de sa restitution. Sur la figure 1, on a référencé 32 l'interface entre le module de transaction MOD et les pilotes logiciels DRV contrôlant ce haut- parleur.
Pour effectuer la transaction, les téléphones intelligents TRM et DSP doivent être suffisamment proches, et par exemple positionnés "tête- bêche", de sorte que le signal audio AUD, restitué par le haut-parleur HP du téléphone intelligent TRM, soit capté par le microphone MIC du téléphone intelligent DSP.
Lorsque c'est le cas, le pilote logiciel DRV du système d'exploitation OS du téléphone intelligent DSP, en charge du contrôle du microphone, achemine ce signal audio AUD vers le module de transaction MOD de ce téléphone.
Sur la figure 1, on a référencé 33 l'interface entre le module de transaction MOD et les pilotes logiciels DRV contrôlant ce microphone.
Dans le mode de réalisation décrit ici, les moyens de conversion CONV de ce module de transaction MOD convertissent le signal audio AUD pour régénérer le code OTP (démodulation).
On suppose, dans cet exemple, que la fonction résidente RES2 a demandé au module de transaction MOD, via l'interface logicielle AP2, d'autoriser la transaction TR en utilisant l'application AUT_TX.
Par conséquent, le module de transaction MOD du téléphone intelligent DSP, commande, via l'interface 31, l'envoi, au serveur sécurisé SRV d'un message MSG comportant le code OTP obtenu par conversion du signal audio AUD reçu via le canal acoustique établi entre le haut- parleur HP et le microphone MIC.
Le serveur sécurisé SRV est donc en mesure de vérifier que le code OTP reçu du premier téléphone intelligent TRM est identique à celui reçu du deuxième téléphone intelligent DSP, cette identité étant représentative de l'acceptation, par le téléphone intelligent DSP de la transaction proposée par le téléphone intelligent TRM.
Par conséquent, le serveur sécurisé SRV envoie un message MSGVAL de validation au téléphone intelligent TRM.
Dans le mode de réalisation décrit ici, ce message de validation
MSGVAL comporte le code OTP et l'identité DSP du téléphone intelligent DSP.
Ce message est reçu par le module de transaction MOD du téléphone intelligent TRM via l'interface 31. La fonction AUT_RX accessible via l'interface logicielle API du module de transaction MOD retourne alors à la fonction résidente RES1 une valeur représentative de l'autorisation de la transaction TR par le téléphone intelligent DSP et de la validation de cette transaction par le serveur sécurisé SRV. Description détaillée d'un deuxième mode de réalisation de l'invention
La figure 2 représente un téléphone mobile intelligent TRM et un téléphone mobile classique TEL conforme au standard GSM.
Le téléphone mobile intelligent TRM décrit en référence à cette figure est identique à celui décrit en référence à la figure 1.
Le téléphone mobile TEL ne comporte pas de module de transaction MOD conforme à l'invention.
Dans ce deuxième mode de réalisation, le module de transaction MOD conforme à l'invention est compris dans le serveur sécurisé SRV.
Dans ce deuxième mode de réalisation, lorsque le serveur SRV reçoit la requête de validation RQVAL comportant un code OTP du téléphone intelligent TRM et le numéro du téléphone classique TEL, il établit un canal CH de communication GSM avec le téléphone classique TEL.
Ce canal de communication permet au serveur sécurisé SRV de recevoir le signal audio AUD capté par le microphone MIC du téléphone classique TEL. Dans le mode de réalisation décrit ici, le module de transaction MOD du serveur sécurisé convertit le signal audio AUD pour générer le code OTP.
Le serveur sécurisé SRV est donc en mesure de vérifier que le code OTP reçu, du téléphone TEL, sous forme audio AUD, par le canal GSM CH correspond à celui reçu du téléphone intelligent TRM dans la requête de validation RQV.
Cette correspondance traduit le fait que les téléphones TEL et TRM ont été rapprochés l'un de l'autre, preuve de l'acceptation, par l'utilisateur du téléphone classique TEL de la transaction proposée par le téléphone intelligent TRM.
Description détaillée d'un troisième mode de réalisation de l'invention
La figure 3 représente deux téléphones mobiles intelligents TRM, DSP conformes à un autre mode de réalisation de l'invention.
Le téléphone mobile intelligent TRM diffère de celui décrit à la figure 1 en ce que son module de transaction MOD génère un signal audio complexe AUD* constitué par une première partie de signal audio CHRP et par une deuxième partie de signal audio AUD.
La première partie CHRP est un signal audio prédéterminé, très facilement reconnaissable.
La deuxième partie AUD correspond à la conversion du code OTP, comme dans l'exemple de la figure 1.
Le téléphone intelligent DSP diffère de celui de la figure 1 en ce que son module de transaction comporte une unité de détection CHRDET apte à détecter la première partie de signal audio CHRP lorsqu'un signal audio complexe AUD* est capté par le microphone MIC.
Lorsque cette détection est effectuée, l'unité de détection CHRDET commande des moyens REC d'enregistrement du module de transaction MOD pour qu'ils enregistrent la deuxième partie AUD du signal AUD*, l'enregistrement, noté OTP*, étant communiqué au serveur sécurisé SRV pour validation de la transaction.
Le serveur sécurisé SRV est donc en mesure de vérifier que le code OTP reçu du premier téléphone intelligent TRM correspond à l'enregistrement OTP* reçu du deuxième téléphone intelligent DSP, cette correspondance étant représentative de l'acceptation, par le téléphone intelligent DSP de la transaction proposée par le téléphone intelligent TRM.
L'invention peut être utilisée pour tout type de transaction, l'interface du module de transaction MOD avec les applications résidentes RES1, RES2 étant générique.
Dans les modes de réalisation décrits aux figures 1 à 3, nous avons séparé les fonctions de demande d'autorisation de transaction (rôle du terminal TRM) et d'autorisation de transaction (rôle du dispositif électronique DSP).
Bien entendu, en pratique, les modules de transaction MOD peuvent permettre de jouer les deux rôles.
La figure 4 représente, à cet effet, un module de transaction dans un premier mode préféré de réalisation de l'invention.
Ce module de transaction comporte, dans cet exemple une interface 31 avec des moyens de communication d'un dispositif électronique ou d'un terminal, des moyens 33 pour s'interfacer avec un microphone, des moyens 32 pour s'interfacer avec un haut-parleur, des moyens de conversion d'un signal audio en un code OTP, et vice-versa, une interface 34 pour recevoir un code OTP, et des interfaces logiciels API, AP2 avec les applications résidentes dans le dispositif électronique ou le terminal.
La figure 5 représente un module de transaction dans un deuxième mode préféré de réalisation de l'invention.
Ce module de transaction diffère de celui de la figure 4 en ce que le module de conversion CONV n'assure que la partie modulation mais pas la conversion du signal audio reçu par le microphone MIC en code OTP. Il comporte des moyens CHRDET pour détecter la première partie du signal audio et des moyens REC d'enregistrement de la deuxième partie du signal audio, cet enregistrement étant envoyé au serveur sécurisé par le dispositif électronique DSP qui l'incorpore avec lequel il communique via l'interface 31.
Dans la description faite précédemment, les données échangées entre le terminal TRM et le serveur SRV était constituées par le code OTP et les identifiants DSP, TRM. Seul le code OTP est absolument indispensable. Dans certaines applications, les identifiants TRM et/ou DSP pourraient ne pas être communiqués.
En fonction de l'application choisie, d'autres types de données peuvent être véhiculées et notamment des montants de transaction, des droits, des codes d'accès, des mots de passe, des clés cryptographiques, ou de façon plus générale tout paramètre utile à la transaction envisagée.
Dans un mode de réalisation, le serveur SRV maintient une base de données dans laquelle il enregistre les identifiants des équipements qui incorporent un module de transaction MOD au sens de l'invention. Cela permet au serveur d'établir spontanément un canal CH de communication GSM avec le dispositif électronique DSP, comme dans l'exemple de la figure 2, lorsque ce dispositif électronique ne comporte pas de module MOD.
On notera que le module de transaction MOD peut être incorporé dans des terminaux ou dispositifs électroniques de tout type : terminaux de communication mobiles, caisse enregistreuse, distributeur de billet de banque, borne fixe, carte à puce, carte SIM, ...
Le module de transaction MOD peut aussi être intégré dans une serrure, la transaction entre la serrure et le dispositif électronique DSP étant dans ce cas une demande d'ouverture de porte soumise à validation du serveur sécurisé SRV.

Claims

REVENDICATIONS
1. Module de transaction (MOD) pouvant être intégré dans un terminal (TRM) pour autoriser une transaction entre une première application (RES1) résidant dans ce terminal (TRM) et une deuxième application (RES2) résidant dans un dispositif électronique (DSP), ce module (MOD) comportant:
- des moyens (10) pour obtenir un code (OTP) ;
- une interface (31) avec des moyens (COM) de communication dudit terminal (TRM) permettant l'envoi, à un serveur sécurisé (SRV), d'une requête de validation (RQVAL) comportant ledit code (OTP) ;
- des moyens (CONV) pour générer un signal audio (AUD) à partir dudit code (OTP);
- une interface (32) avec un module (DRV) dudit terminal (TRM) apte à envoyer ledit signal audio (AUD) vers un haut-parleur (HP) dudit terminal
(TRM) en vue de sa restitution; et
- des moyens (10) pour autoriser ladite transaction (TR) sur réception d'un message de validation (MSGVAL) en provenance dudit serveur sécurisé (SRV), ce message étant représentatif de la réception, par ledit serveur sécurisé, dudit code (OTP) en provenance dudit dispositif électronique (DSP).
2. Module de transaction selon la revendication 1 caractérisé en ce et en ce que lesdits moyens (10) d'obtention comportent une interface (34) avec une mémoire (15) constituant un réservoir de codes (OTP).
3. Module de transaction selon la revendication 1 ou 2 caractérisé en qu'il comporte une interface logicielle (API) avec ladite première application résidente (RES1), ladite interface logicielle comportant une fonction (AUT_RQ) utilisée par ladite première application résidente (RES1) pour demander l'autorisation de ladite transaction (TR), et une fonction (AUT_RX) permettant à ladite première application résidente (RES1) pour recevoir une valeur représentative de l'autorisation de la transaction par le dispositif électronique et de la de validation de la transaction par ledit module (MOD).
4. Module de transaction (MOD) pouvant être intégré dans un dispositif électronique (DSP) pour autoriser une transaction entre une première application (RES2) résidant dans ce dispositif électronique (DSP) et une deuxième application (RESl) résidant dans un terminal (TRM), ce module (MOD) comportant:
- une interface (33) pour recevoir un signal audio (AUD) capté par un microphone (MIC) dudit dispositif électronique (DSP), le signal audio ayant été émis par un haut-parleur (HP) dudit terminal;
- des moyens (CONV) aptes à générer un code (OTP) à partir dudit signal audio (AUD) ; et
- une interface (31) avec des moyens (COM) de communication du dispositif électronique (DSP) permettant l'envoi dudit code (OTP) à un serveur sécurisé (SRV) dans le but d'autoriser ladite transaction.
5. Module de transaction (MOD) pouvant être intégré dans un dispositif électronique (DSP) pour autoriser une transaction entre une première application (RES2) résidant dans ce dispositif électronique (DSP) et une deuxième application (RESl) résidant dans un terminal (TRM), ce module (MOD) comportant:
- une interface (33) pour recevoir un signal audio (AUD*) capté par un microphone (MIC) dudit dispositif électronique (DSP), le signal audio ayant été émis par un haut-parleur (HP) dudit terminal;
- des moyens (CHRDET) aptes à détecter une première partie (CHRP) dudit signal audio (AUD*) ; et
- une interface (31) avec des moyens (COM) de communication du dispositif électronique (DSP) permettant l'envoi de l'enregistrement (OTP*) d'une deuxième partie (AUD) dudit signal audio (AUD*) à un serveur sécurisé (SRV) dans le but d'autoriser ladite transaction.
6. Module de transaction selon la revendication 4 ou 5, caractérisé en qu'il comporte une interface logicielle (AP2) avec ladite première application résidente (RES2), ladite interface logicielle (AP2) comportant une fonction (AUT_TX) utilisée par ladite première application résidente (RES2) pour demander audit module de transaction (MOD) d'autoriser ladite transaction (TR).
7. Module (MOD) comportant les moyens d'un module de transaction selon l'une quelconque des revendications 1 à 3 et les moyens d'un module de transaction selon l'une quelconque des revendications 4 à 6.
PCT/FR2012/050904 2011-04-29 2012-04-25 Module de gestion d'une transaction entre un terminal et un dispositif electronique WO2012146871A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP12722470.7A EP2702523B1 (fr) 2011-04-29 2012-04-25 Module de gestion d'une transaction entre un terminal et un dispositif electronique
US14/114,425 US9817962B2 (en) 2011-04-29 2012-04-25 Module for managing a transaction between a terminal and an electronic device
AP2013007196A AP3899A (en) 2011-04-29 2012-04-25 A module for managing a transaction between a terminal and an electronic device
CA2833665A CA2833665C (fr) 2011-04-29 2012-04-25 Module de gestion d'une transaction entre un terminal et un dispositif electronique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1153669 2011-04-29
FR1153669A FR2974695B1 (fr) 2011-04-29 2011-04-29 Module de gestion d'une transaction entre un terminal et un dispositif electronique

Publications (1)

Publication Number Publication Date
WO2012146871A1 true WO2012146871A1 (fr) 2012-11-01

Family

ID=46146964

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/050904 WO2012146871A1 (fr) 2011-04-29 2012-04-25 Module de gestion d'une transaction entre un terminal et un dispositif electronique

Country Status (6)

Country Link
US (1) US9817962B2 (fr)
EP (1) EP2702523B1 (fr)
AP (1) AP3899A (fr)
CA (1) CA2833665C (fr)
FR (1) FR2974695B1 (fr)
WO (1) WO2012146871A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160023750A (ko) 2016-02-12 2016-03-03 이도훈 보이스 코일을 이용하는 모바일 자기 데이터 전송 시스템 및 그 방법

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9363562B1 (en) * 2014-12-01 2016-06-07 Stingray Digital Group Inc. Method and system for authorizing a user device
US10949841B2 (en) 2015-05-07 2021-03-16 Visa International Service Association Provisioning of access credentials using device codes

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2898238A1 (fr) * 2006-03-02 2007-09-07 Customer Product Relationship Procede de transaction entre deux serveurs comportant une etape prealable de validation mettant en oeuvre deux telephones portables.

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787154A (en) * 1996-07-12 1998-07-28 At&T Corp Universal authentication device for use over telephone lines
US7445146B2 (en) * 1998-04-17 2008-11-04 Diebold, Incorporated Card activated cash dispensing automated banking machine system and method
US6961850B1 (en) * 1999-04-21 2005-11-01 Recording Industry Association Of America Method and system for minimizing pirating and/or unauthorized copying and/or unauthorized access of/to data on/from data media including compact discs and digital versatile discs
US7188080B1 (en) * 2000-05-12 2007-03-06 Walker Digital, Llc Systems and methods wherin a buyer purchases products in a plurality of product categories
FR2811446B1 (fr) * 2000-07-07 2004-01-16 Dixet Procede de securisation utilisant une transmission d'information par voie optique et disque optique pour la mise en oeuvre de ce procede
WO2002043020A2 (fr) 2000-11-22 2002-05-30 Horizonte Venture Management Gmbh Procede et dispositif de transmission de donnees par telephones mobiles dans des operations de paiement par virements electroniques
US7784684B2 (en) 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US7110792B2 (en) * 2003-05-19 2006-09-19 Einar Rosenberg Apparatus and method for increased security of wireless transactions
CN1846263B (zh) * 2003-06-30 2011-09-07 松下电器产业株式会社 一种再现设备以及再现方法
EP1639535A4 (fr) * 2003-06-30 2007-01-03 Selvanathan Narainsamy Systeme de verification de transaction
CN101241735B (zh) * 2003-07-07 2012-07-18 罗威所罗生股份有限公司 重放加密的视听内容的方法
FR2861236B1 (fr) 2003-10-21 2006-02-03 Cprm Procede et dispositif d'authentification dans un reseau de telecommunication utilisant un equipement portable
US7539874B2 (en) * 2004-05-20 2009-05-26 International Business Machines Corporation Secure password entry
GB2427286A (en) 2005-06-11 2006-12-20 Harley Clark Financial transaction method
EP1802155A1 (fr) 2005-12-21 2007-06-27 Cronto Limited Système et procédé pour authentification dynamique basée sur plusieurs facteurs
US8060916B2 (en) * 2006-11-06 2011-11-15 Symantec Corporation System and method for website authentication using a shared secret
US20100106647A1 (en) 2007-02-28 2010-04-29 Raja Raman Method and system for close range communication using audio tones
US8532612B1 (en) * 2007-03-30 2013-09-10 Google Inc. Obtaining mobile information for networked transactions
US20090112767A1 (en) * 2007-10-25 2009-04-30 Ayman Hammad Escrow system and method
FR2927453B1 (fr) * 2008-02-08 2010-04-02 Tagattitude Procede et systeme de distribution de billets de banque a partir d'un distributeur de billets
JP5279379B2 (ja) * 2008-07-16 2013-09-04 株式会社セフティーアングル 認証システム及び認証方法
CA2673030C (fr) 2008-10-23 2014-01-07 Diversinet Corp. Systeme et methode d'autorisation de transactions par dispositifs mobiles
ES2428004T3 (es) * 2009-09-16 2013-11-05 Openways Sas Sistema asegurado de gestión de cerraduras de control digital, adaptado a un funcionamiento mediante acreditaciones acústicas cifradas
CN102971758A (zh) 2010-04-14 2013-03-13 诺基亚公司 用于提供自动化支付的方法和装置
US20120011007A1 (en) * 2010-07-07 2012-01-12 At&T Intellectual Property I, L.P. Mobile Payment Using DTMF Signaling

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2898238A1 (fr) * 2006-03-02 2007-09-07 Customer Product Relationship Procede de transaction entre deux serveurs comportant une etape prealable de validation mettant en oeuvre deux telephones portables.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160023750A (ko) 2016-02-12 2016-03-03 이도훈 보이스 코일을 이용하는 모바일 자기 데이터 전송 시스템 및 그 방법

Also Published As

Publication number Publication date
EP2702523B1 (fr) 2015-12-09
AP3899A (en) 2016-11-17
EP2702523A1 (fr) 2014-03-05
AP2013007196A0 (en) 2013-10-31
CA2833665C (fr) 2020-02-25
US9817962B2 (en) 2017-11-14
FR2974695A1 (fr) 2012-11-02
US20140137209A1 (en) 2014-05-15
CA2833665A1 (fr) 2012-11-01
FR2974695B1 (fr) 2013-06-07

Similar Documents

Publication Publication Date Title
EP3262860B1 (fr) Procédé de reconnaissance automatique entre un appareil mobile et un véhicule automobile aptes à fonctionner selon le protocole ble
EP2306407B1 (fr) Système de gestion sécurisée de serrures à commande numérique, adapté à un fonctionnement par accréditations acoustiques chiffrées
CA2543134C (fr) Procede et dispositif d'authentification dans un reseau de telecommunication utilisant un equipement portable
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
EP2912818B1 (fr) Procede d'authentification mutuelle entre un terminal et un serveur distant par l'intermediaire d'un portail d'un tiers
EP2692122A1 (fr) Authentification forte par presentation du numero
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
EP2702523B1 (fr) Module de gestion d'une transaction entre un terminal et un dispositif electronique
WO2015033061A1 (fr) Procédé d'authentification de transaction
EP2219140B1 (fr) Entite électronique apte à communiquer avec un lecteur et procédé mis en oeuvre au sein d'une telle entité électronique
WO2005069658A1 (fr) Procede de securisation de l’identifiant d’un telephone portable, et telephone portable correspondant
EP3987416A1 (fr) Procede et dispositif d'authentification d'un utilisateur utilisant la conductivité du corps humain
OA16641A (fr) Module de gestion d'une transaction entre un terminal et un dispositif électronique.
CN110781481A (zh) 单点登录方法、客户端、服务器以及存储介质
EP3314921B1 (fr) Procédé d'authentification pour connecter un dispositif compagnon lorsqu'il est déconnecte d'un dispositif souscripteur
CN109902460A (zh) 通话界面的解锁方法、装置、计算机设备及存储介质
EP1280368B1 (fr) Procédé de sécurisation d'échanges entre un terminal informatique et un équipement distant, ainsi que terminal et serveur correspondants
EP1865695B1 (fr) Mémorisation de flux audio d'une conversation
EP4165889A1 (fr) Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant
FR3102635A1 (fr) Procédé de traitement d’un appel sortant émis par un terminal de communication et terminal mettant en œuvre ce procédé.
WO2004036856A1 (fr) Procede de controle d'acces a un reseau de communication, reseau sans fil, dispositif et programmes d'ordinateurs correspondant
FR3053496A1 (fr) Procede de configuration en mode invite d' un terminal de communication d' un utilisateur
CA2315599A1 (fr) Systeme de securite cryptographique a jetons et systeme permettant le fonctionnement de dispositifs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12722470

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2833665

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2012722470

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14114425

Country of ref document: US