Brevet FR2968494A1 — publié le 20120608

Arrière-plan de l'invention L'invention scrapporte oudomaine informatique. La pre6ænh2 invention concerne en particulier l'échange dedonnées entre un premier serveur hébergé dans une entité électronique reliée à un appareil programmable et un deuxième serveur distant, par l'intermédiaire d'un 10 navigateur exécuté par l'appareil programmable. Le document FR 2 923 337 décrit un procédé d'échange de données dans lequel un serveur embarqué dans une carte SIM insérée dans un téléphone mobile communique avec un serveur bancaire distant, par !'intermédiaire d'un navigateur exécuté par le téléphone mobile. Concrètement, !e navigateur peut obtenir du serveur embarqué une page HTML qui 15 contient, dans une balise HTML, une instruction de ncdivection vers une URL qui contient l'adresse du serveur distant et des donnéesà transmettre au serveur distant. L'interprétation de !a page HTML par le navigateur implique l'exécution de cette instruction de redirection et provoque donc l'envoi d'une requête http vers le serveur distant, incluant les données. Inversement, !e navigateur peut obtenir du serveur distant une page HTML qui 20 contient, dans une balise HTML, une instruction de redirec±ion vers une URL qui contient l'adresse du serveur embarqué et des données à transmettre au serveur embarqué. L'interprétation de la page HTMLpar le navigateur implique l'exécution de cette instruction de redirection et provoque donc l'envoi d'une requête http vers le serveur embarqué, incluant les données. Ainsi, le navigateur permet un échange de données entre le serveur embarqué et le 25 serveur distant. Toutefois, ce procédé d'échange de données présente plusieurs inconvénients. Comme chaque instruction de nedinaction est contenue dans une page HTML respective, chaque envoi de données vers !e serveur embarqué ou /e serveur distant implique l'affichage d'une page HTMLpar le navigateur, ce qui no/ænb l'échange de données. De plus, les données échangées peuvent être visualisée par l'utilisateur du téléphone mobile 30 D'autre part, si un des serveurs ne répond pas, le seul mécanisme prévu est l'affichage d'un message d'erreur par le navigateur. Enfin, une adresse URL présente une taille maximale normalisée, ce qui !imite )a quantité de donnêes qui peut être envoyée. ~ Le document FK 2923337 ~/ccité mentionne également qu'une com/na'/de peutêtre cmnpw~dqme ! nonds est 1'tn8tnuctis» incluse dans un sc aScnpt en variante à l'in HTML Ce mode nn on ne ~nn! mciiun Cr' 'uJ , qui peut être e. dans une balise 2 Il existe donc un besoin pour un procédé de communication permettant un échange de données plus efficace entre deux serveurs par l'intermédiaire d'un navigateur. Objet et résumé de l'invention L'invention propose un procédé de communication mis en oeuvre par un appareil programmable pour effectuer un échange de données entre un premier serveur hébergé dans une entité électronique reliée audit appareil programmable et un deuxième serveur distant, par l'intermédiaire d'un programme hôte exécuté par ledit appareil programmable, !e procédé de communication comprenant : - une étape d'obtention, de !a po/f du premier serveur, d'un fichier incluant des instructions interprétables par ledit programme hôte, et - une étape d'interprétation des instructions dudit fichier par !e programme hôte, caractérisé en ce que ladite étape d'interprétation des instructions comprend : - une étape d'envoi d'un premier message vers le deuxième serveur, - une étape de réception d'un deuxième message de !a part du deuxième serveur en réponseà !'envoi du premier message, le deuxième message incluant des données, et - une étape d'envoi d'un troisième message vers le premier serveur, incluant lesdites données. Corrélativement, l'invention fournit une entité électronique comprenant une mémoire dans laquelle sont mémorisés un fichier incluant des instructions interprétables par un programme hôte et un programme demise enoeuvre d'un premier serveur hébergé dans l'entité électronique, et des moyens de transmission dudit fichier à un appareil programmable incluant un programme hôte, caractérisé en ce que ledit fichier comprend : - des instructions d'envoi d'un premier message vers un deuxième serveur distant, - des instructions de réception d'un deuxième message de !a part du deuxième serveur (40) en réponseà !'envoi du premier message, le deuxième message incluant des données, et des instructions d'envoi d'un troisième massage vers !e premier serveur, incluant lesdites données. Autrement dit selon l'invention, un un/que fichier comprend des instructions pour envoyer un premier message vers !a serveur distant, recevoir une réponse, et transmettre des données contenues dans !a réponse au pncmiersen/eurr Il n'est pas nécessaire d'afficher plusieurs pages HTMLetl'échange de données peut donc être plus ta;.;, r De plus, il n'est pas nécessaire d'afficher !eadonn~usrCÇ ues. Lc p~og/amhüi~ !;cu~ co/npre:d/- Li rnvigaL~ur!8fichicr r, t comprendre un script ]ava~cnpt inicrp/~iob!u pnr !a 'mvign~cu/Dons cc cas, !~ script JavaSc~~~ peut inclure des En variante, !e programme hôte peut comprendre un module apte à interpréter un programme Flash ou un programme Java, !e fichier incluant un programme Flash ou un programme Java. Le fichier peut comprendre des instructions d'envoi du premier message et du deuxième message, lesdites instructions d'envoi incluant des instructions d'envoi d'une requête hLtp de type GET ou de type POST. L'utilisation de ce type de requête permet de transmettre une quantité de données importante. Selon un mode de réalisation, !'étape d'interprétation des instructions comprend une 10 étape de vérification de !a réception d'une réponse à un message envoyé vers !e deuxième serveur. Dans Cecas, l'étape d'interprétation des instructions peut également comprendre, en l'absence de réception d'une réponse au premier message, une étape d'envoi du premier message vers un troisième serveur. En variante, l'étape d'interprétation des instructions peut comprendre, 15 en !'absence de réception d'une réponse au premier message, une étape de renvoi du premier message vers le deuxième serveur. Selon un mode de réalisation, ladite étape d'interprétation des instructions comprend une étape de test concernant lesdites données. Les différentes caractéristiques précitées permettent au programme hôte d'adapter le 20 déroulement de ('échange de données aux circonstances, par exemple à l'impossibilité de communiquer avec le serveur distant. Selon un mode de réalisation, l'entité électronique est reliée de manière amovible audit appareil programmable, ladite étape d'obtention et ladite étape d'interprétation étant effectuées en répons8à la détection de la connexion de l'entité électronique à l'appareil programmable. 25 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation - /a figure 1 représente une entité électronique selon un mode de réalisation de l'invention, dans son environnement, la figure 2 représente les principales étapes d'un procédé de communication selon un mode de réalisation de l'invention, présent ~ [cLopc cVinterpi ia(dc~ instructions de /8 figure 2, selon variante, t 'étape d'intei p!6xaoodes instructions de la figure 2, selon 30 35 tofigu/ une , - la figure une seCoArc vo/i 4 description détaillée de modes de réalisation La figure 1 représente une entité électronique 1O reliée de manière amovible à un appareil programmable 20, et un serveur 4Odistant. Ci-après, on décrit un échange de données entre un serveur hébergé dans l'entité électronique 10 st !e serveur 40 distant, par l'intermédiaire 5 d'un navigateur exécuté par l'appareil programmable 20. L'entité électronique 10 est un dispositif électronique portable qui présente l'architecture matérielle d'un ordinateur. Ainsi, l'entité électronique 10 comprend une mémoire non volatile 11, un microprocesseur 12, un mémoire volatile 13 et une interface 14. Le microprocesseur 12 permet l'exécution de programmes d'ordinateur mémorisés dans !a mémoire non volatile 11, en 10 utilisant !a mémoire volatile 13. L'interface 14 permet de communiquer, par une liaison 30, avec l'appareil programmable 20. Dans une première variante, l'entité électronique 10 se présente sous /a forme d'un dispositif portable autonome qui peut être relié de manière amovible à l'appareil programmable 20, en restant situé à l'extérieur de l'appareil programmable 20. 15 Par exemple, l'entité électronique 10 est un lecteur multimédia portable ou un dispositif de stockage couramment appelé «c/é U3B». Dans ce cas, la mémoire non-volatile 11 peut comprendre un support mémoire logé de manière amovible dans l'entité électronique 10, par exemple une carte 6IM 0u une carte microSD. Dans ce cas également, !a liaison 30 peut comprendre un connecteur USB. La liaison 30 peut aussi être une liaison sans fil, par exemple une 20 liaison sans fil courte portée du type NFC(pour « /&sa//ield Communication ») OU une liaison sans fil de moyenne portée (portée inférieuneà 100 mètres, préférentiellement inférieure à 5O mètres, vo/ne 30 mètres), par exemple une liaison conforme à !a norme Zigbee ou 8!uetooth. Dans une autre variante, l'entité électronique 10 se présente sous /a forme d'une carte à puce (par exemple une carte 5IM) ou d'une carte mémoire (par exemple une carte microSD) 25 logée de manière amovible dans !'æppareil programmable 20. Dans ce cas, la liaison 30 peut comprendre un connecteur normalisé correspondant au format de l'entité électronique 10. Dans sa mémoire non volatile 11, l'entité électronique 10 comprend notamment un programme d'ordinateur 15 qui, !ocsqu'il est exécuté par !e microprocesseur 12, constitue un sen/eurvveb hébergé dans l'entité électronique 10. Ci-après, la référence 15 est utilisée également 30 pour désigner le serveur correspondant au programme d'ordinateur 15. La mémoire non volatile Il comprend également une page web 16, par exemple au fornnn HTML ou ohp, un fichier 17 COn',11ilnt des instructions interprétables, une clé 18, et un prn7mo\m8 19 comprenant, ncdan-nIenf' nier fonction d'authentification. L8 fichier 17 est par u/script ]av3G[hptouUn p/og'n/n//e P ou Java. 35 Le programme 19 pot ne -eu'i par le 12, 1 Olcciron~~oc ~S ou Uc ynppasi/ pr0gmn)mahl, 30. Le progænnne 1Q momorüe alors, dan.. ; mémoire volatile 13, une information I qui indique que l'utilisateur de l'entité électronique 10 a été identifié. L'appareil programmable 20 présente l'architecture matérielle d'un ordinateur. Ainsi, l'appareil programmable 20 comprend une mémoire non volatile 21, un microprocesseur 22, une 5 mémoire volatile 23, une première interface 24 et une deuxième interface 25. Le microprocesseur 22 permet l'exécution de programmes d'ordinateur mémorisés dans la mémoire non volatile 21, en utilisant }a mémoire volatile 23. L'interface 24 permet de communiquer, par !a liaison 30, avec /'entité électronique 10. L'interface ZS permet de communiquer, par une liaison 50, avec le serveur distant 40. 10 L'æppaneil programmable 20 se présente par exemple sous la forme d'un ordinateur personne! (PC) ou d'un téléphone mobile. La liaison 50 est par exemple une liaison utilisant le réseau Inhsrnetou un réseau de téléphonie mobile Dans sa mémoire non volatile 21, l'appareil programmable 20 comprend notamment un programme d'ordinateur appelé programme hôte 26. 15 Dans une variante, !e fichier 17 de l'entité électronique 10 comprend un script JavaScript et !e programme hôte 26 est un navigateur apte à interpréter !e script, par exemple le navigateur Internet Explorer ou !e navigateur Firofox. Dans une autre variante, /e fichier 17 comprend un programme, par exemple un programme Flash ou un programme Java, et le programme hâte 26 comprend un navigateur associé à un module complémentaire apte à ZU interpréter le programme du fichier 17, par exemple un p!ugin Rash ou une machine virtuelle Java. Enfin, le serveur 40 distant, qui peut communiquer avec l'appareil programmable 20 par la liaison 50, est un serveur d'un fournisseur de service. Par exemple, le serveur 40 est un serveur bancaire. En référence à !æ figure 2, on décrit !es principales étapes d'un procédé de 25 communication mis en oeuvre par l'appareil programmable 20, permettant un échange de données entre /e serveur 15 et !e serveur 40. La figure Z concerne !a variante dans laquelle l'entité électronique 10 se présente sous !a forme d'un dispositif portable autonome qui peut être relié de manière amovible à !\yppæreil programmable 28, en restant situé à !'extérieur de l'appareil programmable 20. 30 L'appaneil programmable 20 est programmé pour détecter !a connexion de l'entité électronique 10 et pour obtenir et exécuter un fichier prédéterminé (par exemple un fichier w autorun.inf», non rep/ësenté) mémorisé dans la mémoire non volatile Il en réponse à la proc~~~ d~cor:muOic8tiondi~e~ cou -' ;1 l'appareil 35 po~/n~b!: ~ . ct~ ~u,n uQi .- 8[z/~ !~xUi /oni_,ue 10 par!o to/so/~ 3O,et 6 Ensuite à l'étape 61, !'appanjl programmable 20 exécute !æfichier «autorun.inf". Ce dernier comporte !'app2l du navigateur du programme hôte 26 avec en panamètre !'adresse URL de !a paye web 16. Ainsi, à l'étape 61, le navigateur démarre, puis obtient et traite la page web 16. La page web 16 contient une commande d'appel du fichier 17. Par exemple, dans /e 5 cas ou !e fichier 17 est un gcrip1JavæScript, !a page web 16 comprend une commande du type : Ainsi, à l'étape 62, l'appareil programmable 62 obtient le fichier 17. Ensuite, à l'étape 63, !e programme hôte 26 interprète !es instructions contenues dans le fichier 17. Les instructions du fichier 17gèrent l'ensemble de !'échange de données entre le 10 serveur 15 et le serveur 40 par l'intermédiaire du programme hôte 26. Plus précisément, en interprétant ces instructions, /e programme h8k* 26 commande !'envoi de requêtes vers les serveurs 15 et 40 et l'obtention et le traitement des réponses reçues. La figure 3 représente un premier exemple de déroulement de l'étape 63. Les étapes 70 à 76 de !a figure 3 sont effectuées par !e programme hôte 26 lorsqu'il interprète les instructions 15 du fichier 17. Par exemple, dans !e cas ou !e fichier 17 est un script 3avaScript et le programme hôte 26 est un navigateur, !es étapes 70 à 76 correspondent à des instructions respectives du script interpréter par le navigateur. A l'étape 70, /e programme hôte 26 envoie une requête de vérification de l'authentification de l'utilisateur au serveur 15. Le serveur 15 vérifie que !'information I est présente 20 dans !o mémoire volatile 13, et dans ce cas répond positivement. Ainsi, si à l'étape 70 !e programme hôte 26 reçoit une réponse positive du serveur 15, il passe à l'étape 71. A l'étape 71, !e programme hôte 2ôenvoi un message M1 au serveur 40 distant. Le message M1 contient une requête d'obtention d'un challenge. Lorsqu'il reçoit le message M1, le serveur 40 détermine un nombre aléatoire, appelé 25 challenge A, et l'envoie au programme hôte 26. Ainsi à l'étape 72, !e programme hôte 26 reçoit un massage M2 de !o part du serveur 40. Le message M2 contient comme données le challenge A' Ensuite, à l'étape 73, le programme hôte 26 envoie un message M3 au serveur 15. Le message M3 contient comme données le challenge A. 30 En réponse à !a réception du message M3, le serveur 15 calcule !a réponse R au challenge A 8n utilisant !a dé 18 et un algorithme cryptographique, et envoie la réponse R au programme hôte 26. Ainsi, à l'étape 74, !e prog'om/ne hôte 26 reçoit un message M4 de la part du serveur 1~. contient comr-é (;cu,n ,.1=) 35 Ensui o !étapc75, !ep'ogonmic un n' ~ au serveur 40. Le 5 cor comme données la y-no ~ ninn/ Parexcmpi\ !e sen/ ur40comp@/ b /c!`oo 7 même en fonction du challenge Ae{d'une dé symétrique à ka dé 18. Si la réponse R est correcte, le serveur 40 répond positivement au programme hôte 26. Ainsi, à !'étape 76, !e programme hôte 26 reçoit un message M6 de !a part du serveur 40, qui indique une authentification correcte de l'entité électronique 10 auprès du serveur 40. Dans 5 ce cas, le programme hôte 26affiche un message d'authentification sur l'interface homme/machine de l'appareil programmable 20. On donne ci-après un exemple d'instructions pouvant être contenues dans !e fichier 17, dans !e cas d'un schptJavaScript utilisant !a bcchniqueA]AX (pour «Asv7(h/VnouxJauæn7ipt And XML ») et le cadre d'application jQuery (ht-tp://www.jquery.com), et correspondant aux étapes 10 71à73 : /* Commentaires : Envoie une requête au serveur distant et obtient en réponse un challenge */ /ünotiom / 15 aism'/ type: 'CET; /*définition dutype de requête http enGfrTvy data Type: )sono,/* A j'ovdde l'option /sznx/ors oèl'appel à un domaine externe */ /snp{2ll2axk: br/lbanck|/*nmm oè/bfonction de réponse à l'appel jsonp*/ unl: 'heps://vvww.mybarik.com/HomeSanking.cgi; /*ur/ du sen/eur distant */ ZO smzess answerChallenge(response) /* traitement de /a réponse dans la fonction */ 0/' ' /* Commentaires .. 25 Ehwx6e 6e challenge à l'entité électronique pour Ull calcul d'authentification et obtient en réponse une donnée chiffrée fonction answerChallenge(response)( jQuery,ajax« 30 type: 'POST; /* définit/on du type de requête httpen POST pour l'envoi de données*/ obta.' /l4 /xæspxnrne. /* Ajout du paramètre A contenant le challenge fournit précédemment */ 'authenticate; /* un' de /a z calcul du cryptogramme sur l'entité 35 dans la fonction 8 ()n constate donc quil suffit au navigateur du programme hôte 26 d'obtenir et de traiter une unique page web 16 pour pznne1ve )'échange des donnéesA et R entre les serveurs 15 et 40. Les étapes 70 à 76, effectuées lors de l'interprétation des instructions du fichier 17, ne nécessitent pas l'affichage de pages web supplémentaires. 5 De plus, dans l'exemple donné, !'envoi des messages M1 et M3 correspond à des requêtes ht1p de type GET ou de type POST. La réception du message M2 correspond à une réponse ht1p reçue en réponse à une requête de ce type. La taille des données transmises, notamment (a taille du challenge Aet de !a réponse R, n'est donc pas limitée par la taille maximale d'une adresse ur!. Par exemple, !a taille des données transmises peut être de l'ordre de 1 10 mégaoctet. De plus, avec une requête de type POST, les données transmises ne doivent pas être affichées et ne sont donc pas visibles pour l'utilisateur. On sait que JavæScript impose des restrictions sécuritaires qui interdisent d'atteindre des domaines web extérieurs ou différents de celui sur !equel on charge le fichier JavaScript, qui est le domaine auquel appartient !e serveur 15 dans cet exemple. Dans cet exemple, les messages 15 envoyés vers !e serveur 40 distant devraient donc être bloquées par le navigateur du programme hôte 36. Dans l'exemple d'instructions donné ci-dessus, pour s'affranchir de cette limitation, on formate !es requêtes selon !a technique]SONP /pour« JavaScript Obvect /&7ù»bbn wv/h Padding »>. La figure 4 représente un deuxième exemple de déroulement de l'étape 63. Les étapes 70 et 71 sont idenhquesà celles décrites précédemment en référence à la 20 figure 3. Après l'étape 71, le programme hôte 26 passe à l'étape 82 où il vérifie si un message M2 a été reçu de !a part du serveur 40. Par exemple, !e programme hôte 26 vérifie que le message M2 a été reçu dans un délai déterminé. Si !e message M2 a été reçu dans !e dé/ai déterminé, !e programme hôte 36 passe alors à !'étape 73 identique à ce/!e décrite en référence à !a figure 3, et la communication se 25 poursuit comme décrit précédemment. Par contre, si aucun message M2 n'est reçu dans le délai déterminé, !e programme hôte 26 passe à l'étape 83. A !'étape 83, !e programme hôte 26 renvoie !e message M1 vers un serveur alternatif, noté 40'. Puis à !'étape 84, /e programme hÜha 26 reçoit un message M2 de la part du serveur alternatif 40'. Le message M2 contient comme données !e challenge A. Ensuite, !e programme hôte 30 26 passe à l'étape 73 et la communication se poursuit comme décrit précédemment. Dans l'exemple de /a figure ], /es instructions du fichier 17 conduisent le programme hôte 26 à agir comme simple intermédiaire changé d'envoyer des requêtes et de recevoir des réponses. A titre de comparaison, dans l'exemple de !a figure 4, !ex instructions du fichier 17 conduisent le programme hôte 26 à prendre un 35 évolues Plus c!ren~,"r [bn5 !'e#e"`"le ~gon= 4, grâce 32 de \, Dans urx \ /hanf2 non /cp/~sw'Lec, !u pp:Umxnn~2 ._w0 !e ,,...stion de l'échange de données plus - 26 9 serveur 4Opour une nouvelle tentative. Dans une variante non représentée, le programme hôte 26 pourrait egalen)ent effecteur une étape de test concernant les données transmises, par exemple concernant le chaUengeA et/ou !a réponse R, et adapter le déroulement de la communication au résultai de ce bsst^ Ainsi, les instructions du fichier 17, lorsqu'elles Sont interprétées par le 5 programme hôte 26, permettent d'adapter !æ déroulement de !'échange de données entre /e serveur 15 et un serveur distant aux circonstances, notamment à l'impossibilité de joindre un serveur distant. On a décrit un exemple dans lequel /e programme hôte 26 obtient une page web 16 qui appelle un fichier 17 contenant des instructions. Dans une variante, les instructions 10 correspondant à l'étape 63 décrite précédemment sont contenues directement dans la page web 16. On ædécrit un exemple dans lequel !e programme hôte 26 obtient le fichier 17 (étape 62)etinterprète !esinstructions qu'il contient (étape 63)enréponse à la détection de la connexion de l'entité électronique 10 (étape 60). Dans une variante, notamment dans le cas où l'entité 15 électronique 10 est logée dans l'appareil programmable 20, les étapes 62 et 63 sont exécutées en réponse à une instruction de l'utilisateur de l'appareil programmable 20, par exemple une instruction d'accès à la page web 16. L'entité électronique 10 permet à un utilisateur de transporter ses données personnelles (données multimédia, documents,...) et constitue en que/que sorte /e «noni virtuel ^ 20 de l'utilisateur.