FR2924295A1 - HTTP request processing method for accessing web page in e.g. subscriber identity module card, of electronic system, involves decompressing loaded data, forming body of HTTP response with decompressed data, and transmitting HTTP response - Google Patents

HTTP request processing method for accessing web page in e.g. subscriber identity module card, of electronic system, involves decompressing loaded data, forming body of HTTP response with decompressed data, and transmitting HTTP response Download PDF

Info

Publication number
FR2924295A1
FR2924295A1 FR0759289A FR0759289A FR2924295A1 FR 2924295 A1 FR2924295 A1 FR 2924295A1 FR 0759289 A FR0759289 A FR 0759289A FR 0759289 A FR0759289 A FR 0759289A FR 2924295 A1 FR2924295 A1 FR 2924295A1
Authority
FR
France
Prior art keywords
data
web page
compressed
portable electronic
page
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
FR0759289A
Other languages
French (fr)
Other versions
FR2924295B1 (en
Inventor
Nicolas Bousquet
Vincent Guerin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Oberthur Card Systems SA France
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
Application filed by Oberthur Card Systems SA France filed Critical Oberthur Card Systems SA France
Priority to FR0759289A priority Critical patent/FR2924295B1/en
Publication of FR2924295A1 publication Critical patent/FR2924295A1/en
Application granted granted Critical
Publication of FR2924295B1 publication Critical patent/FR2924295B1/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72445—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality for supporting Internet browser applications

Abstract

The method involves loading compressed data (DATA-C) in a web page (135), where the web page contains text data e.g. HTML text data, image data e.g. JPEGimage data, sound data e.g. MPEG-1 audio layer 3data, script data e.g. JavaScript(RTM: scripting programming language) and/or animation data. The loaded data is decompressed to produce decompressed data (DATA-D). A body of a HTTP response (300) with the decompressed data, is formed. The HTTP response is transmitted. Independent claims are also included for the following: (1) a portable electronic device comprising a web server (2) a method for personalization of a portable electronic device.

Description

PROCEDE DE TRAITEMENT DE REQUETES HTTP PAR UN SERVEUR WEB HEBERGE DANS UN DISPOSITIF ELECTRONIQUE PORTABLE. METHOD FOR PROCESSING HTTP REQUESTS BY A WEB SERVER IN A PORTABLE ELECTRONIC DEVICE

La présente invention concerne un dispositif électronique portable, tel qu'une carte à puce, utilisé dans des terminaux fixes ou mobiles pour donner accès à des services ou des données de manière sécurisée, par un processus d'authentification de l'utilisateur/abonné du terminal. The present invention relates to a portable electronic device, such as a smart card, used in fixed or mobile terminals to provide access to services or data in a secure manner, by an authentication process of the user / subscriber of the terminal.

L'invention concerne plus particulièrement un dispositif électronique portable d'authentification hébergeant un serveur web, destiné à être utilisé dans un terminal internet, c'est à dire un terminal qui a les moyens nécessaires pour se connecter à internet, et un procédé de traitement par ce serveur web de requêtes http (Hyper Text Transfer Protocol) émises par le terminal, typiquement par un navigateur, pour transférer des ressources du dispositif électronique portable vers le terminal. Le format de ces requêtes http et de leurs réponses, qui régissent les échanges entre un serveur et un navigateur est décrit dans le document de référence RFC2616, intitulé Hypertext Transfer Protocol -HTTP/1.1, disponible auprès de l'IETF (Internet Engineering Task Force) notamment sur son site http://www.ietf.org. Par ressource, on entend généralement une entité informatique accessible indépendamment. Dans le contexte de l'invention, il s'agit notamment d'une page web, c'est à dire d'un document destiné à être consulté avec un navigateur, qui est constituée typiquement d'un document html (Hyper Text Mark-up Language), xml, xhtml..., c'est à dire du texte, et d'éventuelles ressources liées à ce document : des images (JPEG, PNG, GIF...), des scripts (JavaScript), des sons (MP3, Wav ...), des animations et qui peuvent être automatiquement exécutés ou affichés par le navigateur s'il a les interfaces correspondantes. Par serveur web embarqué sur une entité électronique portable, telle qu'une carte à puce, on entend un logiciel serveur http, c'est à dire un protocole défini par la référence RFC2616, qui permet d'accéder à un site web, c'est à dire un ensemble de pages ou autres ressources (sons, images, ...) embarquées sur la carte. Une session peut ainsi être ouverte entre un client, généralement le navigateur du terminal hôte et le serveur web embarqué, permettant un transport de données http de la carte vers le terminal hôte. En pratique la carte à puce est accessible localement par son terminal. Mais si elle possède une adresse publique (adresse IP routable sur Internet), elle peut être également accessible par un client distant. De manière générale, le dispositif électronique portable contient des informations de sécurité qui permettent d'authentifier l'utilisateur et lui donner accès à des services correspondants, ou de donner accès à des données sécurisées qu'il contient. Il peut contenir en outre des applications diverses. Par exemple, en téléphonie, la carte SIM contient des applications telles que des jeux, une messagerie électronique, des services multimédia... Dans le contexte de l'invention, le dispositif héberge en outre un site web en mémoire non volatile reprogrammable. Les terminaux internet sont devenus d'usage courant, qu'ils soient fixes ou mobiles. Ce sont des ordinateurs de bureau, fixes ou portables, des téléviseurs "multimédia" ou encore des terminaux mobiles type organisateur, 15 téléphone mobile, miniportable, console de jeux ou autres. Ils intègrent les ressources nécessaires à la navigation internet, et notamment un navigateur ("browser"), une pile TCP/IP... Dans ce contexte, un utilisateur peut utiliser différents terminaux internet dont il n'est pas toujours le propriétaire, c'est à dire que c'est la carte 20 qui va l'authentifier comme utilisateur ou abonné : le dispositif électronique portable connecté au terminal utilisé permet d'authentifier cet utilisateur mobile pour autoriser l'accès et/ou l'usage d'un ou plusieurs services par ce terminal. Dans le domaine de la téléphonie mobile par exemple, le dispositif 25 électronique portable est typiquement une carte à puce(s) dite carte USIM (Universal Subscriber Identity Module) ou plus simplement SIM, achetée par l'abonné. L'abonné place cette carte dans le téléphone mobile dans un logement prévu à cet effet. La carte peut alors assurer la gestion sécurisée de l'abonnement téléphonique sur ce téléphone, notamment par une 30 procédure d'authentification par un code (code PIN) propre à l'abonné. Il y a d'autres types d'applications, par exemple, le dossier médical personnalisé, qui utilise une carte à puce propre à un assuré social, contenant des données confidentielles propres à cet assuré : l'accès à tout ou partie des données confidentielles est permis par la carte de manière 35 sécurisée par un terminal d'un médecin, d'un pharmacien, d'un organisme de santé qui ont également leur carte propre qui les authentifie et détermine l'étendue de leurs droits d'accès aux données du dossier médical personnalisé. On assiste à une implémentation généralisée d'applications Web sur les terminaux y compris les terminaux mobiles, même bon marché, avec les ressources matérielles/logicielles propres à la navigation Web (navigateur, piles TCP/IP, ...), liée au développement du web et à l'évolution des technologies matérielles et logicielles, en sorte que l'interface utilisateur la plus largement répandue sur ces terminaux est un navigateur web. Les opérateurs de téléphonie l'ont bien compris, eux qui notamment utilisent cette interface utilisateur pour leur offre de services aux abonnés, par un site web correspondant. Il est apparu intéressant d'implémenter ce site web sur les dispositifs d'authentification eux même, permettant d'une part d'utiliser de manière sécurisée les données propres à l'abonné, et d'autre part de libérer le(s) réseau(x) de communication internet pour des accès à d'autres sites distants. C'est ainsi que l'on trouve sur le marché des cartes à puce(s) hébergeant un site web dans leur espace mémoire non volatile reprogrammable (EEPROM), avec un serveur web embarqué associé. Le site web contient en pratique une ou plusieurs pages web, avec du texte, des images, des sons, des scripts.... Il est consultable par le navigateur internet standard implémenté dans les terminaux internet, par sélection dans un menu déroulant par exemple. L'offre de services apparaît alors sur l'écran de ces terminaux internet, sous forme d'une page web, c'est à dire du texte seul ou avec des liens vers d'autres pages ou avec d'autres ressources : sons, images, scripts.... L'accès à ce site web utilise les ressources matérielles/logicielles prévues en standard sur le terminal internet : écran, clavier, souris, navigateur. The invention more particularly relates to a portable electronic authentication device hosting a web server, intended to be used in an internet terminal, ie a terminal that has the means necessary to connect to the Internet, and a processing method by this web server HTTP requests (Hyper Text Transfer Protocol) issued by the terminal, typically by a browser, to transfer resources of the portable electronic device to the terminal. The format of these http requests and their responses, which govern the exchanges between a server and a browser is described in reference document RFC2616, Hypertext Transfer Protocol -HTTP / 1.1, available from the Internet Engineering Task Force (IETF). ) in particular on its site http://www.ietf.org. By resource is generally meant an independently accessible computing entity. In the context of the invention, it is in particular a web page, that is to say a document intended to be consulted with a browser, which typically consists of a html document (Hyper Text Mark- up Language), xml, xhtml ..., ie text, and any resources related to this document: images (JPEG, PNG, GIF ...), scripts (JavaScript), sounds (MP3, Wav ...), animations and that can be automatically executed or displayed by the browser if it has the corresponding interfaces. By web server embedded on a portable electronic entity, such as a smart card, is meant a http server software, ie a protocol defined by the reference RFC2616, which allows access to a website, it is a set of pages or other resources (sounds, images, ...) embedded on the map. A session can thus be opened between a client, generally the browser of the host terminal and the embedded web server, for transporting http data from the card to the host terminal. In practice, the smart card is accessible locally by its terminal. But if it has a public address (IP address routable on the Internet), it can also be accessible by a remote client. In general, the portable electronic device contains security information that makes it possible to authenticate the user and give him access to corresponding services, or to give access to secure data that it contains. It can also contain various applications. For example, in telephony, the SIM card contains applications such as games, electronic mail, multimedia services ... In the context of the invention, the device also hosts a non-volatile memory reprogrammable web site. Internet terminals have become commonplace, whether fixed or mobile. These are desktops, fixed or portable, "multimedia" televisions or mobile devices such as organizer, mobile phone, netbook, games console or others. They integrate the resources necessary for internet browsing, and in particular a browser ("browser"), a TCP / IP stack ... In this context, a user can use different internet terminals of which he is not always the owner. is to say that it is the card 20 that will authenticate as a user or subscriber: the portable electronic device connected to the terminal used to authenticate this mobile user to allow access and / or use of a or more services through this terminal. In the field of mobile telephony for example, the portable electronic device is typically a smart card (s) called USIM card (Universal Subscriber Identity Module) or SIM simply, purchased by the subscriber. The subscriber places this card in the mobile phone in a slot provided for this purpose. The card can then ensure secure management of the telephone subscription on this phone, including a authentication procedure by a code (PIN) specific to the subscriber. There are other types of applications, for example, the personalized medical file, which uses a smart card specific to a social insured, containing confidential data specific to this insured: access to all or part of the confidential data The card is securely enabled by a terminal of a physician, a pharmacist, a health organization who also have their own card which authenticates them and determines the extent of their access rights to the data. Personalized medical file. We are witnessing a widespread implementation of Web applications on terminals, including mobile terminals, even at a low cost, with hardware / software resources specific to web browsing (browser, TCP / IP stacks, etc.), linked to the development of the web and the evolution of hardware and software technologies, so that the most widely used user interface on these terminals is a web browser. The telephony operators have clearly understood that they, in particular, use this user interface for their subscriber service offering, through a corresponding website. It appeared interesting to implement this website on the authentication devices themselves, allowing on the one hand to use securely the data specific to the subscriber, and on the other hand to release the (s) network (s) (x) internet communication for access to other remote sites. Thus, there are on the market smart cards hosting a website in their non-volatile reprogrammable memory space (EEPROM), with an associated embedded web server. The website contains in practice one or more web pages, with text, images, sounds, scripts .... It is searchable by the standard internet browser implemented in the internet terminals, by selection in a drop-down menu for example . The service offer then appears on the screen of these internet terminals, in the form of a web page, ie text alone or with links to other pages or with other resources: sounds, images, scripts .... Access to this website uses the hardware / software resources provided as standard on the internet terminal: screen, keyboard, mouse, browser.

En pratique le serveur embarqué, connu sous l'acronyme SCWS (pour Smart Card Web Server) n'a pas nécessairement une adresse IP, mais seulement une adresse locale pour le terminal connecté au dispositif électronique portable. L'architecture d'un système applicatif correspondant, c'est à dire le 35 terminal internet et son dispositif électronique portable d'authentification au serveur web, est largement répandue et connue. Cependant les fournisseurs de services rencontrent un problème pour généraliser ou développer ces sites Web implémentés en local sur les dispositifs électroniques portables. In practice the embedded server, known by the acronym SCWS (for Smart Card Web Server) does not necessarily have an IP address, but only a local address for the terminal connected to the portable electronic device. The architecture of a corresponding application system, ie the internet terminal and its portable electronic authentication device to the web server, is widely known and widespread. However, service providers encounter a problem in generalizing or developing these locally implemented Web sites on portable electronic devices.

En effet la mémoire non volatile reprogrammable, généralement une mémoire EEPROM, a une capacité limitée, de l'ordre de 16 à 64 Kilobits. Même en ajoutant de la mémoire flash, on ne résout pas ce problème. Cette mémoire sert déjà à mémoriser des données nécessaires, correspondant à des normalisations (par exemple, norme GSM pour la téléphonie mobile) : données d'authentification, données d'applications ou de services (applets), répertoires, .... L'espace libre pour d'autres données, telles les données d'un site web, est ainsi limité. La capacité de ces mémoires ne peut être augmentée, avec l'évolution de la technologie de ces mémoires, que dans certaines limites imposées par la constitution même de ces cartes : pour ces cartes qui implémentent des applications sécuritaires, c'est à dire avec authentification, on ne peut pas utiliser des puces trop grandes, qui seraient trop fragiles. Une idée, à la base de la solution technique proposée dans l'invention pour résoudre ce problème, est la mémorisation du site web sous forme compressée. Cette idée n'est pas conforme à ce qui se fait habituellement sur les cartes à puce dans l'état de l'art. En effet la compression de données n'est généralement pas utilisée dans les cartes à puce(s), pour des raisons tenant à l'incompatibilité des processus de compression avec la nature des données mémorisées et avec la structure de données des mémoires non volatiles des cartes à puce. En effet, la nature cryptée d'une partie au moins des données mémorisées dans cet espace, implique que le taux de compression appliqué à ces données sera pratiquement nul, rendant par conséquent sans intérêt cette compression, pour ces données au moins. Indeed the non-volatile memory reprogrammable, usually an EEPROM memory, has a limited capacity, of the order of 16 to 64 Kilobits. Even adding flash memory does not solve this problem. This memory is already used to memorize necessary data, corresponding to standardizations (for example, GSM standard for mobile telephony): authentication data, application or service data (applets), directories, .... free space for other data, such as data from a website, is thus limited. The capacity of these memories can be increased, with the evolution of the technology of these memories, only within certain limits imposed by the constitution of these cards: for these cards which implement security applications, ie with authentication we can not use chips that are too big and that are too fragile. An idea underlying the technical solution proposed in the invention to solve this problem is the storage of the web site in compressed form. This idea does not conform to what is usually done on smart cards in the state of the art. Indeed, data compression is generally not used in smart cards, for reasons related to the incompatibility of compression processes with the nature of the stored data and with the data structure of the non-volatile memories of the data. smart cards. Indeed, the encrypted nature of at least a portion of the data stored in this space, implies that the compression ratio applied to these data will be virtually zero, thus making this compression uninteresting, for these data at least.

La structure figée des données en mémoire, c'est à dire sans gestion dynamique de la mémoire (table d'allocation dynamique), opposée à des fichiers applicatifs dont le contenu peut être modifié, rend également la compression inefficace. En effet, dans une structure figée, à chaque fichier ou répertoire doit correspondre une zone mémoire définie une fois pour toute (adresse de début-adresse de fin). Or le taux de compression d'un fichier peut être variable, selon qu'il est modifiable ou non. Dans le contexte des cartes à puce, au moins certains fichiers applicatifs étant généralement modifiables, et la structure des données ne permettant pas de gérer une taille variable de fichier, il faudra allouer à chaque fichier une zone de taille figée, correspondant nécessairement au pire cas (pas de compression). Le taux de compression obtenu sera donc variable, et souvent inefficace à réduire le volume mémoire. Or la compression des données (ou leur décompression nécessaire avant utilisation) est réalisée aux moyens d'algorithmes longs et compliqués, qui mobilisent de la puissance de calcul et de la mémoire temporaire, pendant un temps de calcul non négligeable. Les coûts induits ne se justifient pas au regard des gains variables obtenus (taux ou efficacité de compression). Pour ces différentes raisons au moins, l'utilisation de la compression pour augmenter l'espace mémoire non volatile disponible a été 15 écartée dans les cartes à puce. Dans ce contexte, on a cherché dans l'invention à exploiter une caractéristique des pages web sauvegardées sur le site web : elles sont non susceptibles d'être modifiées : par suite le contenu de chaque page est fixe, invariable. Par conséquent, un algorithme de compression donné appliqué à 20 l'ensemble des données d'une page web du site fournit un ensemble de données de taille connue, invariable, pour lequel on peut réserver une zone mémoire non volatile correspondante dans une structure de données à gestion non dynamique. Cependant, dans le contexte d'une application qui utilise des 25 ressources d'un terminal hôte et d'un dispositif électronique portable d'authentification, un autre aspect est à prendre en compte, à savoir de quelles ressources matérielles/logicielles dispose le terminal hôte auquel un dispositif électronique portable sera attribué. En effet, le marché dans ce domaine a été construit sur la base d'une séparation de la production des 30 terminaux et des dispositifs électroniques portables, pour séparer l'offre commerciale des services/abonnement et des terminaux. Reprenons l'exemple de la téléphonie. Le terminal, c'est le téléphone mobile, qui peut être fourni par une grande variété de fabricants. L'offre des services de téléphonie est fournie par des opérateurs variés. 35 Lorsqu'un utilisateur choisit un opérateur, son abonnement va être géré par le dispositif électronique portable que lui fournit l'opérateur, c'est à dire la carte USim personnalisée par l'opérateur. En mettant cette carte dans le téléphone qu'il a choisi, puis en s'authentifiant, l'abonné peut alors accéder aux services souscrits. The frozen structure of the data in memory, ie without dynamic management of the memory (dynamic allocation table), opposed to application files whose content can be modified, also makes the compression inefficient. Indeed, in a fixed structure, each file or directory must match a memory area defined once and for all (end address-end address). But the compression ratio of a file can be variable, depending on whether it is modifiable or not. In the context of smart cards, at least some application files are generally modifiable, and the data structure does not allow to manage a variable file size, it will allocate to each file a fixed size zone, necessarily corresponding to the worst case (no compression) The compression ratio obtained will therefore be variable, and often inefficient to reduce the memory volume. But the compression of the data (or their decompression necessary before use) is achieved by means of long and complicated algorithms, which mobilize computing power and temporary memory for a non-negligible calculation time. The induced costs are not justified with regard to the variable gains obtained (rate or compression efficiency). For these reasons at least, the use of compression to increase the available nonvolatile memory space has been discarded in smart cards. In this context, we sought in the invention to exploit a characteristic of the web pages saved on the website: they are not likely to be modified: consequently the content of each page is fixed, invariable. Therefore, a given compression algorithm applied to all the data of a web page of the site provides a set of data of known size, invariable, for which a corresponding nonvolatile memory area can be reserved in a data structure. non-dynamic management. However, in the context of an application that uses resources of a host terminal and a portable electronic authentication device, another aspect is to be taken into account, namely what hardware / software resources the terminal has. host to which a portable electronic device will be allocated. Indeed, the market in this area has been built on the basis of a separation of the production of terminals and portable electronic devices, to separate the commercial offer of services / subscription and terminals. Let's take the example of telephony. The terminal is the mobile phone, which can be provided by a wide variety of manufacturers. The offer of telephony services is provided by various operators. When a user chooses an operator, his subscription will be managed by the portable electronic device provided by the operator, ie the USim card customized by the operator. By putting this card in the phone he has chosen, then by authenticating himself, the subscriber can then access the services subscribed.

Aussi, il ne suffit pas qu'un opérateur mémorise chaque page de son site web sous forme compressée dans les dispositifs électroniques portables qu'il fournit aux clients potentiels, encore faut-il que n'importe quel téléphone choisi par le client puisse accepter cette particularité. Or tous les téléphones mobiles n'ont pas les ressources leur permettant d'accepter tous les formats de codage des algorithmes de compression utilisés, qui peuvent être variés, et de décompresser des données compressées reçues dans des réponses http. Ce problème de connaissance des ressources du terminal hôte est d'ailleurs une des limitations des méthodes de transmission des réponses http de certains serveurs web, comme celle décrite dans la demande TW586066B qui prévoit qu'un serveur web applique une compression au contenu d'une page web qui lui a été demandée, au moment de la transmission de la réponse http vers le navigateur qui en a fait la requête. Ces méthodes de transmission permettent de réduire le temps d'occupation du ou des canaux de communication correspondants entre le serveur et le navigateur client, et donc de libérer le plus rapidement possible le serveur pour lui permettre de traiter d'autres requêtes, mais nécessitent que le navigateur client soit capable d'exploiter les données transmises en réponse, donc de les décompresser, ce qui n'est pas toujours le cas. Also, it is not enough for an operator to memorize each page of his website in compressed form in the portable electronic devices that he provides to potential customers, but any telephone chosen by the customer must accept this. feature. However, not all mobile phones have the resources to accept all the coding formats of the compression algorithms used, which can be varied, and to decompress compressed data received in http responses. This problem of knowledge of the resources of the host terminal is also one of the limitations of the methods of transmission of http responses of some web servers, such as that described in the application TW586066B which provides that a web server applies a compression to the contents of a web page that was requested, at the time of transmission of the http response to the browser that made the request. These transmission methods make it possible to reduce the time of occupation of the corresponding communication channel or channels between the server and the client browser, and thus to release the server as quickly as possible so that it can process other requests, but require that the client browser is able to exploit the data transmitted in response, so to decompress them, which is not always the case.

L'invention a ainsi pour objet de résoudre un problème d'espace mémoire non volatile sur des dispositifs électroniques portables pour mémoriser une page web au moins, sans dépendre des ressources de traitement d'un navigateur d'un terminal hôte, en sorte que la solution technique apportée puissent être universellement appliquée à tout terminal hôte. Selon l'invention, le serveur du dispositif électronique portable est configuré pour qu'en réponse à une requête http, il applique une décompression préalable de la page Web requise, mémorisée sur le dispositif électronique portable, de manière à la transmettre dans le corps de la réponse, sous forme décompressée. The object of the invention is thus to solve a problem of non-volatile memory space on portable electronic devices for storing at least one web page, without depending on the processing resources of a browser of a host terminal, so that the technical solution provided can be universally applied to any host terminal. According to the invention, the server of the portable electronic device is configured so that in response to an http request, it applies a preliminary decompression of the required web page, stored on the portable electronic device, so as to transmit it in the body of the answer, in uncompressed form.

L'invention propose ainsi une utilisation inhabituelle dans le domaine concerné, d'algorithmes de compression de pages web appliqués à la mémorisation des données correspondantes en espace mémoire reprogrammable d'un dispositif électronique portable d'authentification hébergeant un serveur web, combinée à une décompression préalable de ces données par le serveur avant émission de la réponse à une requête http, en sorte que ces dispositifs électroniques portables permettent d'élargir le champ des possibilités de réalisation de sites web locaux, indépendamment des configurations des navigateurs des terminaux hôtes dans lesquelles ces dispositifs sont susceptibles d'être utilisés. L'invention concerne donc un procédé de traitement par un serveur web embarqué dans un dispositif électronique portable d'authentification, d'une requête http transmise par un terminal hôte du dispositif, d'accès à une page web mémorisée dans le dispositif électronique, caractérisé en ce qu'il est appliqué à une page mémorisée sous une forme compressée, et en ce qu'il comprend une étape de chargement de données compressées de ladite page, une étape de décompression desdites données chargées, produisant des données décompressées, une étape de formation d'un corps d'une réponse http correspondante avec lesdites données décompressées, et une étape d'émission de ladite réponse. Le procédé de traitement comprend avantageusement, une étape de compression de ladite page dans un format de codage compatible d'au moins un format de codage implémenté dans ledit serveur, produisant des données compressées de la page et au moins une donnée supplémentaire indicative du format de codage appliqué, et l'étape de décompression des données chargées est précédée d'une étape de lecture de ladite donnée supplémentaire, pour appliquer un algorithme de décompression correspondant. Dans un mode de réalisation de l'invention, l'étape de décompression est activée pour former la réponse de toute requête http d'accès à une page web mémorisée sous forme compressée dans ledit dispositif. Dans un autre mode de réalisation de l'invention, le serveur implémentant un format de codage identique ou compatible du format de codage de la page, pour l'émission de données compressées, l'étape de décompression n'est activée que si ladite requête contient une information de codage de contenu en entête excluant l'émission dans le corps de réponse desdites données compressées dans ledit format de codage du serveur. L'invention concerne aussi un dispositif électronique portable implémentant un serveur web et un procédé de personnalisation d'un tel dispositif. The invention thus proposes an unusual use in the field concerned of Web page compression algorithms applied to the storage of the corresponding data in reprogrammable memory space of a portable electronic authentication device hosting a web server, combined with a decompression the server before sending the response to an http request, such that these portable electronic devices make it possible to widen the scope of possibilities for producing local web sites, independently of the browser configurations of the host terminals in which these requests are made. devices are likely to be used. The invention therefore relates to a method of processing by a web server embedded in a portable electronic authentication device, an http request transmitted by a device's host terminal, access to a web page stored in the electronic device, characterized in that it is applied to a page stored in compressed form, and in that it includes a step of loading compressed data of said page, a step of decompressing said loaded data, producing decompressed data, a step of forming a body of a corresponding http response with said decompressed data, and a step of transmitting said response. The processing method advantageously comprises a step of compressing said page in a coding format compatible with at least one encoding format implemented in said server, producing compressed data of the page and at least one additional piece of data indicative of the format of the page. encoding applied, and the step of decompressing the loaded data is preceded by a step of reading said additional data, to apply a corresponding decompression algorithm. In one embodiment of the invention, the decompression step is activated to form the response of any http request to access a web page stored in compressed form in said device. In another embodiment of the invention, the server implementing a coding format that is identical or compatible with the coding format of the page, for the transmission of compressed data, the decompression step is activated only if said request contains header content encoding information excluding the transmission in the response body of said compressed data in said server encoding format. The invention also relates to a portable electronic device implementing a web server and a method of personalizing such a device.

D'autres avantages et caractéristiques de l'invention sont détaillés dans la description suivante en référence aux dessins illustrés d'un mode de ~o réalisation de l'invention, donné à titre d'exemple non limitatif. Dans ces dessins : -la figure 1 illustre une architecture d'un terminal hôte ayant un lien de communication avec un dispositif électronique portable à laquelle peut être appliqué un procédé de traitement de requêtes http selon l'invention; 15 -la figure 2 illustre un procédé de traitement de requêtes http selon l'invention; -la figure 3 représente les structures d'une requête http émise par un terminal hôte et de la réponse http fournie par le dispositif électronique portable selon l'invention; et 20 -la figure 4 illustre un système de personnalisation d'un dispositif électronique portable permettant la mise en oeuvre d'un procédé suivant l'invention. La figure 1 illustre une architecture d'un système électronique auquel on peut avantageusement appliquer l'invention. Le système 25 comprend un terminal internet 100, et un dispositif électronique portable 130 d'authentification, comprenant un serveur web embarqué 139, et hébergeant une page web 135. En pratique, plusieurs pages peuvent être hébergées dans le dispositif. Le procédé de traitement selon l'invention de requêtes http pour 30 accéder à ces pages s'applique de la même façon pour chaque page. Le terminal internet 100 comprend de manière classique un microprocesseur (CPU) 140, un. écran 110 et un clavier 120 (ou d'autres boutons, roues de sélection...), et une mémoire non volatile 150. Le navigateur internet ou browser 150 est de manière classique implémenté en 35 mémoire non volatile. Other advantages and features of the invention are detailed in the following description with reference to the illustrated drawings of a ~ o embodiment of the invention, given by way of non-limiting example. In these drawings: FIG. 1 illustrates an architecture of a host terminal having a communication link with a portable electronic device to which a method for processing http requests according to the invention can be applied; FIG. 2 illustrates a process for processing http requests according to the invention; FIG. 3 represents the structures of an http request issued by a host terminal and of the http response provided by the portable electronic device according to the invention; and FIG. 4 illustrates a personalization system of a portable electronic device allowing the implementation of a method according to the invention. FIG. 1 illustrates an architecture of an electronic system to which the invention can advantageously be applied. The system 25 comprises an internet terminal 100, and a portable electronic authentication device 130, comprising an embedded web server 139, and hosting a web page 135. In practice, several pages can be hosted in the device. The invention processing method of http requests to access these pages applies the same for each page. The internet terminal 100 conventionally comprises a microprocessor (CPU) 140, a. screen 110 and a keyboard 120 (or other buttons, selection wheels ...), and a non-volatile memory 150. The browser or browser 150 is conventionally implemented in non-volatile memory.

Le terminal a par ailleurs un lien de communication 137, typiquement une interface série, filaire, ou non, avec le dispositif électronique portable d'authentification 130. Dans l'exemple plus particulièrement illustré, le terminal 100 est 5 un téléphone mobile dont on a symboliquement représenté une antenne d'émission/réception correspondante 101. Le dispositif électronique portable 130, comprend de manière classique un microprocesseur (CPU) 131, une mémoire programme (ROM) 133 contenant typiquement le système d'exploitation, les différents 10 programmes d'authentification, signature, chiffrement et les clefs associées, le serveur web embarqué SCWS 139, et un programme de décompression DEC, une mémoire RAM de travail 132, et une mémoire non volatile reprogrammable 134, typiquement une mémoire EEPROM ou flash, qui contient des données de personnalisation sécurisée, comme une clef 15 d'authentification 136, des données de programmes applicatifs, et au moins une page web 135. Le lien de communication 137 avec le terminal hôte utilise un connecteur 138 connecté au microprocesseur 131. Le dispositif électronique portable est par exemple une carte SIM ou USIM, avec une interface de communication notamment conforme à la 20 norme ISO 7816. Les mécanismes qui lient le terminal hôte et le dispositif portable et notamment les mécanismes d'authentification sont bien connus, et ne concernent pas en soi l'invention. Il n'y a donc pas lieu de les décrire de manière plus détaillée. On rappellera juste que le dispositif électronique 25 portable d'authentification 130 fournit au terminal 100 les droits d'accès aux services souscrits par un abonné, par une procédure d'authentification qui utilise de manière classique un code d'authentification que doit taper l'utilisateur abonné, typiquement sur le clavier 120 du terminal, sur invite affichée sur l'écran 110. 30 Selon l'invention, la page web 135 est mémorisée dans la mémoire non volatile 134, sous une forme compressée. Cette compression est réalisée par un dispositif externe qui dans une phase de personnalisation du dispositif 130, programme dans la mémoire 134, les données compressées de la page 135. The terminal also has a communication link 137, typically a serial interface, wired, or not, with the portable electronic authentication device 130. In the example more particularly illustrated, the terminal 100 is a mobile phone which has been symbolically represented a corresponding transmitting / receiving antenna 101. The portable electronic device 130, typically comprises a microprocessor (CPU) 131, a program memory (ROM) 133 typically containing the operating system, the various programs of authentication, signature, encryption and the associated keys, the SCWS web server 139, and a DEC decompression program, a working RAM 132, and a reprogrammable non-volatile memory 134, typically an EEPROM or flash memory, which contains data secure personalization, such as an authentication key 136, application program data, and at least one p The communication link 137 with the host terminal uses a connector 138 connected to the microprocessor 131. The portable electronic device is for example a SIM or USIM card, with a communication interface in particular in accordance with the ISO 7816 standard. The mechanisms that bind the host terminal and the portable device and in particular the authentication mechanisms are well known and do not concern the invention per se. There is therefore no need to describe them in more detail. It will be recalled just that the portable electronic authentication device 130 provides the terminal 100 with the access rights to the services subscribed by a subscriber, by an authentication procedure which conventionally uses an authentication code which must be typed by the subscriber. Subscriber user, typically on the keypad 120 of the terminal, on prompt displayed on the screen 110. According to the invention, the web page 135 is stored in the nonvolatile memory 134, in a compressed form. This compression is performed by an external device which, in a customization phase of the device 130, programs in the memory 134, the compressed data of the page 135.

En pratique, la compression appliquée à la page web répond à un format de codage de contenu du type avec compression, compatible avec un format de codage avec compression reconnu par le protocole http. Le protocole http définit en effet les formats de codage de contenu (ou plus simplement formats de codage) reconnus (chapitre 3.5 de RFC2616), utilisables par les serveurs et navigateurs, pour l'échange de données. A l'heure actuelle, les formats de codage avec compression supportés par le protocole http sont les formats Gzip (RFC1952), "compress", le format "deflate" (RFC 1951), ou le format "deflate" englobé dans le format "Zlib" (RFC1950). Le format "deflate" seul, produit des données compressées. Les autres formats sont des conteneurs basés sur un algorithme de compression (deflate ou compress), qui encapsulent des données compressées par d'autres informations supplémentaires, qui peuvent être notamment un nom de fichier, des codes permettant la détection d'erreur (CRC) ou autres. Par exemple Gzip est basé par défaut sur l'algorithme "deflate" (RFC 1951), (mais pourrait être utilisé avec d'autres algorithmes) ; Zlib est exclusivement associé à l'algorithme deflate ; "compress" est basé sur un algorithme Lempel Ziv Welch adaptatif. In practice, the compression applied to the web page responds to a content encoding format of the type with compression, compatible with a coding format with compression recognized by the http protocol. The http protocol defines indeed the content encoding formats (or more simply coding formats) recognized (chapter 3.5 of RFC2616), usable by the servers and browsers, for the exchange of data. Currently, compression encoding formats supported by the http protocol are Gzip (RFC1952), "compress", "deflate" (RFC 1951), or "deflate" format included in the format " Zlib "(RFC1950). The "deflate" format alone produces compressed data. The other formats are containers based on a compression algorithm (deflate or compress), which encapsulate data compressed by other additional information, which can be including a file name, codes allowing the detection of error (CRC) or others. For example Gzip is based by default on the "deflate" algorithm (RFC 1951), (but could be used with other algorithms); Zlib is exclusively associated with the deflate algorithm; "compress" is based on an adaptive Lempel Ziv Welch algorithm.

De manière générale, les données de la page web compressée et mémorisée sur la carte sont obtenues par application d'un format de codage correspondant ou compatible avec l'un de ces formats. Ainsi la page web compressée 135 comprend les données compressées elles-même, notées DATA-C, qui résultent de l'algorithme de compression utilisé (deflate, compress...), et des données Dl et D2, qui encapsulent les données compressées, et qui résultent du format de codage appliqué. En pratique, on prévoit de ne mémoriser sur la carte que les données utiles, c'est à dire essentiellement les données compressées DATA- C et au moins un indicateur de-la compression appliquée, typiquement en entête Dl. D'autres informations, telles que la taille de la page décompressée, et un code de détection d'erreur peuvent être aussi mémorisées (dans Dl et/ou D2 ; cf. figure 1). Dans un exemple pratique, une page web sera compressée en utilisant le format ZIP bien connu, associé à l'algorithme de compression "deflate", et des données produites par ce format, on ne conservera que les données utiles comme indiqué ci-dessus, qui seront les données mémorisées sur la carte, formant la page web compressée 135. Dans cet exemple, cette page web compressée est notamment compatible du format Gzip, qui est un format couramment employé dans les serveurs embarqués dans les dispositifs portables d'authentification. Le serveur embarqué dans la carte est prévu pour mettre en oeuvre un format de codage compatible de celui utilisé pour compresser les pages web, en sorte qu'il sait aller chercher les données compressées DATA-C en mémoire, et les décompresser. Pour cela, il appelle un algorithme de décompression DEC correspondant, implémenté en mémoire ROM 133. Comme illustré symboliquement sur la figure 2, un procédé de traitement selon l'invention par le serveur embarqué 139 d'une requête 200 émise par le navigateur 150, comprend une étape de chargement 10.1 de 15 données compressées DATA-C de la page web 135, une étape de décompression 10.2 de ces données chargées, pour produire des données décompressées DATA-D, et une étape d'émission 10.4 de la réponse 300 avec les données décompressées. De manière plus détaillée, des données de la page web sont 20 chargées en mémoire de travail 132 et décompressées à la volée, au fur et à mesure de leur chargement. On a vu qu'en pratique les données compressées DATA-C mémorisées sont accompagnées (encapsulées) d'autres informations D1, D2 correspondant au format de codage appliqué à la page web, dont une 25 information qui identifie l'algorithme de compression appliqué. Cette information permet au serveur embarqué d'appeler l'algorithme de décompression correspondant en mémoire ROM. Le procédé qui vient d'être décrit permet à un fournisseur de services de réaliser un site web plus riche avec une ou des pages web 30 comprenant non seulement du texte html mais aussi d'autres ressources (images, script,...) dans l'espace libre de la mémoire 134, chaque page pouvant être compressée avant d'être mémorisée, sans que cela nuise à l'accès du site web par un navigateur d'un terminal quelconque, les données de chaque page pouvant être décompressées temporairement avant 35 émission de la réponse. In general, the data of the web page compressed and stored on the card are obtained by applying a coding format corresponding to or compatible with one of these formats. Thus the compressed web page 135 comprises the compressed data themselves, denoted DATA-C, which result from the compression algorithm used (deflate, compress ...), and data D1 and D2, which encapsulate the compressed data, and which result from the encoding format applied. In practice, it is planned to store on the card only the useful data, ie essentially compressed data DATAC and at least one indicator of the compression applied, typically D1 header. Other information, such as the size of the decompressed page, and an error detection code can also be stored (in D1 and / or D2, see Figure 1). In a practical example, a web page will be compressed using the well-known ZIP format, associated with the "deflate" compression algorithm, and data produced by this format, only the useful data will be kept as indicated above, which will be the data stored on the card, forming the compressed web page 135. In this example, this compressed web page is notably compatible Gzip format, which is a format commonly used in embedded servers in portable authentication devices. The server embedded in the card is designed to implement a coding format compatible with the one used to compress the web pages, so that it knows how to get the compressed data DATA-C in memory, and decompress them. For this, it calls a corresponding DEC decompression algorithm, implemented in ROM 133. As illustrated symbolically in FIG. 2, a processing method according to the invention by the embedded server 139 of a request 200 sent by the browser 150, comprises a loading step 10.1 of DATA-C compressed data of the web page 135, a decompression step 10.2 of these loaded data, to produce DATA-D decompressed data, and a transmission step 10.4 of the response 300 with the uncompressed data. In more detail, data from the web page is loaded into working memory 132 and decompressed on the fly, as it is loaded. It has been seen that in practice the stored DATA-C compressed data is accompanied (encapsulated) by other information D1, D2 corresponding to the coding format applied to the web page, including information which identifies the compression algorithm applied. This information allows the embedded server to call the corresponding decompression algorithm in ROM. The method just described enables a service provider to create a richer web site with one or more web pages comprising not only html text but also other resources (images, script, etc.) in the free space of the memory 134, each page can be compressed before being stored, without affecting the access of the website by a browser of any terminal, the data of each page can be decompressed temporarily before 35 issue of the answer.

Un perfectionnement de l'invention va maintenant être décrit, en relation avec les figures 2 et 3. Ce perfectionnement de l'invention permet en outre d'optimiser le temps de transmission de la réponse via l'interface de communication 137 entre le dispositif 130 et le terminal 100, ce qui est intéressant notamment lorsque cette interface est lente, ce qui est le cas avec certaines cartes à puce notamment. Dans ce perfectionnement, le procédé de traitement de l'invention utilise les possibilités de négociation de codage de contenu prévues dans le protocole http (RFC2616), pour élaborer une réponse http appropriée au 10 navigateur client qui a émis la requête, avec des données dans leur forme compressée ou des données décompressées, selon que le navigateur client est capable ou non de traiter les données compressées DATA-C, ou non. Avant de décrire le procédé de manière plus détaillée, quelques rappels succincts concernant les formats de codage de contenu, et les 15 formats des requêtes et réponses http, sont effectués ci-après. On a rappelé précédemment les formats de codage avec compression définis à l'heure actuelle dans le protocole http (RFC2616). Ces formats de codage prévoient des données supplémentaires en plus des données compressées. Ces données supplémentaires contiennent 20 notamment un champ dédié généralement dans un entête, dont la valeur identifie l'algorithme de compression utilisé le cas échéant. Un autre format de codage défini dans ce protocole est un format par défaut, sans transformation, c'est à dire sans compression : c'est le format "identity" (pour identité) supportés par tous (serveur/navigateur http). 25 A chacun des différents formats de codage de contenu admis dans le protocole http, correspond une valeur de code ou "jeton" attribuée par une autorité compétente (IANA Internet Assigned Numbers Authority). Ce sont ces valeurs, disponibles au public, qui permettent l'interopérabilité client-serveur comme spécifié dans le protocole http au moyen d'un attribut 30 de codage de contenu prévu dans les entêtes de requêtes et réponses, qui permet aux navigateurs de spécifier s'il y a lieu les formats qu'ils acceptent ou qu'ils n'acceptent pas, et aux serveurs de préciser le format qu'ils utilisent pour la réponse. De manière plus détaillée, une requête http 200 a typiquement le 35 format normalisé suivant : -une ligne de commande 201 contenant la commande (GET, HEAD, ...), l'URL (identifiant de la ressource demandée), et la version de protocole; -un entête de requête 202 -une ligne vide 203 (indiquant la fin de l'entête) -un corps de requête. Notamment, comme spécifié dans la référence RFC2616, l'entête 202 comprend notamment un attribut AE appelé "ACCEPT-ENCODING". Dans cet attribut, le navigateur client 150 qui fait la requête peut indiquer le format ou les différents formats de codage qu'il supporte, en utilisant la valeur ou les valeurs de code correspondante(s). S'il accepte plusieurs formats, l'ordre de préférence se déduit soit en fonction de leur position dans la liste, soit en indiquant un ordre de préférence, en assortissant chaque valeur de code d'un degré, noté q, qui prend une valeur réelle comprise entre 0 et 1, 0 signifiant littéralement, je ne veux pas, et 1 signifiant littéralement je préfère. Notamment, si le navigateur supporte un format de codage donné, par exemple Gzip, il est capable de décoder ce format quelles que soient les options retenues. Notamment, le format Gzip pouvant évoluer vers d'autres algorithmes de compression que l'algorithme deflate (RFC1950), le navigateur sera à même de décoder les données en appelant le mécanisme de décompression approprié, indiqué dans les données transmises. Avec les valeurs de codage de contenu, indiquées dans l'attribut AE en entête d'une requête, le navigateur peut signifier s'il a ou non les moyens de traiter un format de codage avec compression donné. Le navigateur peut aussi forcer un serveur à lui transmettre des données sous forme décompressée, c'est à dire au format identité, en indiquant dans cet attribut la valeur de code correspondante assortie d'un degré de préférence q égal à 1, ou plus classiquement avec un attribut AE présent mais vide, comme prévu dans le document RFC2616. On ajoutera que lorsque l'attribut AE n'est pas présent dans l'entête, cela signifie par défaut que le navigateur accepte tous les formats de codage de contenu. Dans l'invention, la présence et le contenu de l'attribut AE, 35 lorsqu'il est complété par le navigateur, sont utilisés par le serveur pour savoir si le navigateur qui émet la requête a les ressources nécessaires pour supporter le format de codage de contenu avec compression utilisé dans la carte. Une réponse http 300 à une telle requête à un format similaire : -une ligne de statut 301 contenant la version, un code de réponse, et un texte de réponse; -un entête de réponse 302; - une ligne vide 303 (signifiant la fin de l'entête); - un corps de réponse 304. Notamment, comme spécifié dans la référence RFC2616, l'entête 302 comprend notamment un attribut CE appelé "CONTENT-ENCODING" qui permet au serveur qui fournit la réponse (le serveur SCWS) de spécifier le format de codage de contenu appliqué aux données qu'il fournit dans le corps de réponse 304, au moyen de la valeur de code (ou jeton) 15 correspondante, ce qui va permettre le cas échéant au navigateur de connaître le mécanisme de décodage qu'il doit mettre en oeuvre. Le décodage en question, devra éventuellement décompresser les données. Ainsi, l'invention met avantageusement en oeuvre une décompression par le serveur embarqué des données mémorisées sur le 20 dispositif électronique portable, d'une façon qui est conditionnelle, au moyen de l'attribut AE de codage de contenu des requêtes http. Notamment, si la requête 200 contient un attribut AE de codage de contenu listant le ou les formats de codage acceptés, n'est pas compatible avec le format de codage des données 135 mémorisées sur la 25 carte (ce qui sera par exemple le cas si le navigateur n'accepte que le format "compress" et que le format de codage des données mémorisées DATA-C est "deflate"), ou exclut tout format avec compression (ce qui est par exemple le cas lorsque le navigateur envoie une liste vide pour le Accept-Encoding), le serveur embarqué décompresse temporairement les données 30 mémorisées DATA-C de la page web 135, à la volée, au fur et à mesure de leur chargement, pour les transmettre de manière décompressée dans le corps 304 de la réponse. Si au contraire, la requête 200 contient un attribut AE de codage de contenu listant les formats de codage acceptés, contient le format de 35 codage des données mémorisées 135, ou si cet attribut n'est pas présent, le serveur embarqué SWCS charge et transmet les données de la page web telles que mémorisées, dans le corps 304 de la réponse en précisant le format de codage correspondant dans l'attribut CE de codage de contenu dans l'entête 301 : le navigateur 150 qui reçoit la réponse sait alors quel mécanisme de décodage il doit appliquer aux données transmises dans le corps de la réponse, pour les exploiter sans pertes d'information, et notamment quel mécanisme de décompression appliquer aux données compressées. Ainsi, un procédé de traitement par le serveur embarqué SWCS d'une requête 200 émise par le navigateur 150, va principalement comprendre une étape de chargement 10.0 du format de codage de la page web 135 par lequel les données compressées DATA-C ont été obtenues, une étape de chargement 10.1 des données compressées DATA-C de la page web mémorisé 135, une étape d'analyse 10.2 de l'attribut AE de codage de contenu dans l'entête 202 de la requête, pour déterminer si le navigateur client qui a fait la requête 200, accepte le format de codage de la page web 135. Si oui, une réponse 300 est formée avec les données chargées (compressées) DATA-C dans le corps 304 de la réponse. Sinon, une étape de décompression 10.2 des données compressées DATA-C est activée pour fournir des données décompressées, et une réponse 300 est formée avec les données décompressées DATA-D dans le corps 304 de la réponse. L'invention sera mieux comprise au moyen de deux exemples de mise en oeuvre. An improvement of the invention will now be described, in relation to FIGS. 2 and 3. This improvement of the invention also makes it possible to optimize the transmission time of the response via the communication interface 137 between the device 130. and the terminal 100, which is interesting especially when this interface is slow, which is the case with some smart cards in particular. In this refinement, the processing method of the invention uses the content coding negotiation capabilities provided in the http protocol (RFC2616), to develop an appropriate http response to the client browser that issued the request, with data in their compressed form or uncompressed data, depending on whether or not the client browser is able to process DATA-C compressed data. Before describing the method in more detail, some brief reminders of the content coding formats, and the http request and response formats, are made hereinafter. The compression encoding formats defined at present in the http protocol (RFC2616) were recalled earlier. These encoding formats provide additional data in addition to the compressed data. This additional data contains in particular a dedicated field generally in a header, the value of which identifies the compression algorithm used where appropriate. Another encoding format defined in this protocol is a default format, without transformation, that is to say without compression: it is the format "identity" (for identity) supported by all (http server / browser). Each of the different content coding formats allowed in the http protocol corresponds to a code value or "token" assigned by a competent authority (IANA Internet Assigned Numbers Authority). It is these publicly available values that enable client-server interoperability as specified in the http protocol by means of a content coding attribute provided in the request and response headers, which allows the browsers to specify the formats they accept or do not accept, and the servers to specify the format they use for the response. In more detail, a request http 200 typically has the following standardized format: a command line 201 containing the command (GET, HEAD, ...), the URL (identifier of the requested resource), and the version protocol; a request header 202 -a blank line 203 (indicating the end of the header) -a request body. In particular, as specified in the reference RFC2616, the header 202 includes an AE attribute called "ACCEPT-ENCODING". In this attribute, the requesting client browser 150 may indicate the format or the different encoding formats that it supports, using the corresponding value or code values. If it accepts several formats, the order of preference is deduced either according to their position in the list, or by indicating an order of preference, by matching each code value with a degree, denoted q, which takes a value actual between 0 and 1, 0 meaning literally, I do not want, and 1 meaning literally I prefer. In particular, if the browser supports a given encoding format, for example Gzip, it is able to decode this format regardless of the options selected. Notably, since the Gzip format can evolve to other compression algorithms than the deflate algorithm (RFC1950), the browser will be able to decode the data by calling the appropriate decompression mechanism, indicated in the transmitted data. With the content encoding values, indicated in the AE attribute in the header of a request, the browser can mean whether or not it has the means to process a given compression encoding format. The browser can also force a server to transmit data to it in uncompressed form, that is to say in the identity format, indicating in this attribute the corresponding code value with a degree of preference q equal to 1, or more conventionally with an AE attribute present but empty, as provided in RFC2616. It will be added that when the AE attribute is not present in the header, it means by default that the browser accepts all content encoding formats. In the present invention, the presence and content of the AE attribute, when supplemented by the browser, are used by the server to determine whether the requesting browser has the necessary resources to support the encoding format. content with compression used in the map. An http 300 response to such a request in a similar format: a status line 301 containing the version, a response code, and a response text; a response header 302; an empty line 303 (meaning the end of the header); a response body 304. In particular, as specified in the reference RFC2616, the header 302 includes in particular a CE attribute called "CONTENT-ENCODING" which allows the server that provides the response (the SCWS server) to specify the encoding format. of content applied to the data it provides in the response body 304, by means of the corresponding code value (or token), which will enable the browser, if necessary, to know the decoding mechanism that it must set. implemented. The decoding in question will eventually have to decompress the data. Thus, the invention advantageously implements decompression by the embedded server of the data stored on the portable electronic device, in a manner that is conditional, by means of the attribute AE content coding requests http. In particular, if the request 200 contains a content coding AE attribute listing the accepted coding format or formats, it is not compatible with the coding format of the data 135 stored on the card (which will be the case, for example, if the browser accepts only the "compress" format and the coding format of the DATA-C data stored is "deflate"), or excludes any format with compression (which is for example the case when the browser sends an empty list for the Accept-Encoding), the embedded server temporarily decompresses the stored data DATA-C of the web page 135, on the fly, as and when they are loaded, for uncompressed transmission in the body 304 of the reply. If, on the other hand, the request 200 contains a content encoding AE attribute listing the accepted encoding formats, contains the encoding format of the stored data 135, or if this attribute is not present, the embedded server SWCS loads and transmits the data of the web page as stored in the body 304 of the response by specifying the corresponding coding format in the content coding attribute CE in the header 301: the browser 150 which receives the response then knows what mechanism it must apply to the data transmitted in the body of the response, to exploit them without loss of information, and in particular what decompression mechanism to apply to the compressed data. Thus, a method of processing by the on-board server SWCS of a request 200 sent by the browser 150, will mainly comprise a loading step 10.0 of the coding format of the web page 135 by which the DATA-C compressed data has been obtained. , a loading step 10.1 of the compressed data DATA-C of the stored web page 135, an analysis step 10.2 of the attribute AE of content coding in the header 202 of the request, to determine if the client browser which made the request 200, accepts the coding format of the web page 135. If so, a response 300 is formed with the data loaded (compressed) DATA-C in the body 304 of the response. Otherwise, a decompression step 10.2 of the DATA-C compressed data is enabled to provide decompressed data, and a response 300 is formed with the DATA-D decompressed data in the body 304 of the response. The invention will be better understood by means of two exemplary embodiments.

Dans un premier exemple, on aura par exemple la séquence d'étapes suivante, dans le cas où le navigateur ne supporte pas de format de codage avec compression : L'utilisateur du terminal 100 lance le navigateur 150 à l'aide du clavier 120 et de l'écran 110, et le navigateur 150 affiche une interface 30 correspondante sur l'écran 110. A l'aide du clavier 120 et de l'écran 110, l'utilisateur peut alors demander au navigateur 150 d'envoyer une requête http à la carte. Le navigateur 150 forme cette requête 200 en incluant : -dans l'entête 202, l'attribut AE avec une liste vide, signifiant que 35 le navigateur n'est pas apte à la décompression, -dans le corps 204 de la requête, l'adresse de la page web demandée, et envoie cette requête à la carte 130 via le microprocesseur 140 du terminal, qui reconnaît qu'il s'agit d'une requête http pour le serveur local, et la transmet à la carte 130 via l'interface série 137. In a first example, there will be for example the following sequence of steps, in the case where the browser does not support compression coding format: The user of the terminal 100 launches the browser 150 using the keyboard 120 and of the screen 110, and the browser 150 displays a corresponding interface 30 on the screen 110. Using the keyboard 120 and the screen 110, the user can then ask the browser 150 to send a request http à la carte. The browser 150 forms this request 200 by including: in the header 202, the attribute AE with an empty list, meaning that the browser is not capable of decompression, in the body 204 of the request, the address of the requested web page, and sends this request to the card 130 via the microprocessor 140 of the terminal, which recognizes that it is an http request for the local server, and transmits it to the card 130 via the serial interface 137.

Le microprocesseur 131 de la carte 130 reçoit la requête 200, et reconnaît qu'il s'agit d'une requête http. Il lance l'exécution du serveur web 139, et stocke la requête 200 en mémoire de travail RAM 132. Le serveur 139 analyse le contenu de la requête 200 mémorisée en mémoire de travail 132, et notamment de l'entête 210. Il lit dans cet entête, que l'attribut AE est présent mais vide. Le serveur embarqué sait alors que le navigateur qui a fait la requête ne supporte pas la compression. Par la suite, il charge les données compressées DATA-C de la page web (ou d'une partie de la page web) demandée, et les décompresse à la volée, en activant l'algorithme de 15 décompression (mémorisé en mémoire ROM), correspondant au format de codage de la page web compressée 135. Les données compressées DATA-C sont décompressées à la volée, au fur et à mesure de leur chargement en mémoire de travail 132. Le serveur forme une réponse http 300 avec les données 20 décompressées DATA-D obtenues placées dans le corps de réponse 304, et envoie cette réponse vers le navigateur 150 par l'interface 137. Le microprocesseur du terminal 100 reçoit la réponse 300, reconnaît qu'il s'agit d'une réponse http, et la transmet au navigateur 150. Le navigateur 150 analyse le contenu de la réponse 300, récupère 25 le corps de la réponse 304 qui contient la page web décompressée (ou une partie de cette page), et l'affiche sur l'écran 110. On notera ici que la mise en oeuvre du procédé de l'invention suppose que le format de codage avec compression utilisé par le serveur embarqué est le même que celui utilisé pour compresser la page web 135 30 hébergée dans le dispositif électronique portable, ou qu'il est compatible. On entend par compatibilité des formats de codage, des formats basés sur le même algorithme de compression. Notamment les formats de codage Gzip basé sur l'algorithme de compression "deflate" et le format de codage "deflate" sont compatibles. Le format de codage Gzip se différencie 35 principalement en ce qu'il comporte dans les données supplémentaires ajoutées, encapsulant les données compressées DATA-C proprement dites, des données additionnelles telles qu'un nom de fichier ou des informations pour la détection d'erreur de transmission. Ainsi, dans l'exemple précité, si la page web 135 est au format "deflate", et que le serveur embarqué met en oeuvre le format Gzip, le serveur embarqué" est capable d'extraire de la page web mémorisée, les données compressées DATA-C correspondant à la page web demandée, de leur appliquer l'algorithme de décompression correspondant pour obtenir les données décompressées, à transmettre dans le corps de la réponse. ~o Dans un deuxième exemple, l'attribut AE dans l'entête 202 contient une liste d'un ou de plusieurs formats de codage acceptés, dont l'un au moins est basé sur l'algorithme de compression qui a fourni les données de la page web 135 mémorisée en mémoire non volatile 133. Un tel exemple peut correspondre à la situation pratique suivante : 15 -la page web 135 est compressée au format de codage "deflate"; - le serveur 139 implémente le format de codage Gzip, compatible du format de codage "deflate". - le navigateur indique dans l'attribut AE qu'il accepte le format de codage Gzip. 20 Dans ce cas, le serveur embarqué 139 détecte que l'émetteur de la requête accepte les données compressées au format de codage Gzip. Il forme une réponse http 300 pour le navigateur 150 par l'interface 137. Dans cette réponse : - le corps de réponse 304 contient des données compressées 25 DATA-C, correspondant à la page web (ou une partie de la page) demandée, telles que chargées depuis la mémoire non volatile 134, et des données supplémentaires Dl', D2' correspondant au format de codage du serveur (figure 3); - l'attribut CE dans l'entête 302 de la réponse, est rempli avec la 30 valeur de code correspondant au format de codage utilisé par le serveur. Le microprocesseur 140 du terminal reçoit cette réponse 300, détecte qu'il s'agit d'une réponse http, et la transmet au navigateur 150 qui va l'analyser. Le navigateur 150 détecte en analysant l'attribut dans l'entête 302 35 de la réponse, le format de codage du corps 304 de la réponse. Il fait une demande correspondante au microprocesseur 140. Notamment le microprocesseur applique l'algorithme de décompression correspondant aux données compressées DATA-C transmises, et retourne les données décompressées au navigateur 150, qui va commander leur affichage en 110. The microprocessor 131 of the card 130 receives the request 200, and recognizes that it is an http request. It starts the execution of the web server 139, and stores the request 200 in working memory RAM 132. The server 139 analyzes the contents of the request 200 stored in working memory 132, and in particular the header 210. It reads in this header, that the AE attribute is present but empty. The embedded server then knows that the browser that made the request does not support compression. Subsequently, it loads the DATA-C compressed data from the requested web page (or part of the web page), and decompresses them on the fly, activating the decompression algorithm (stored in ROM). corresponding to the encoding format of the compressed web page 135. The compressed data DATA-C is decompressed on the fly, as it is loaded into working memory 132. The server forms a response http 300 with the data 20 obtained DATA-D decompressed placed in the response body 304, and sends this response to the browser 150 through the interface 137. The microprocessor of the terminal 100 receives the response 300, recognizes that it is an http response, and transmits it to the browser 150. The browser 150 analyzes the contents of the response 300, retrieves the body of the response 304 that contains the uncompressed web page (or part of that page), and displays it on the screen 110 We note here that the implementation The method of the invention assumes that the compressed encoding format used by the embedded server is the same as that used to compress the web page 135 hosted in the portable electronic device, or that it is compatible. Compatibility of encoding formats means formats based on the same compression algorithm. In particular, the Gzip encoding formats based on the "deflate" compression algorithm and the "deflate" encoding format are compatible. The Gzip encoding format differs mainly in that it includes in additional data added, encapsulating the compressed DATA-C data itself, additional data such as a file name or information for error detection. of transmission. Thus, in the above example, if the web page 135 is in "deflate" format, and the embedded server implements the Gzip format, the embedded server "is able to extract from the stored web page, the compressed data DATA-C corresponding to the requested web page, to apply to them the corresponding decompression algorithm to obtain the decompressed data, to be transmitted in the body of the response. ~ O In a second example, the attribute AE in the header 202 contains a list of one or more accepted encoding formats, at least one of which is based on the compression algorithm that provided the data of web page 135 stored in nonvolatile memory 133. Such an example may correspond to in the following practical situation: the web page 135 is compressed to the "deflate" encoding format, the server 139 implements the Gzip encoding format, compatible with the "deflate" encoding format, the browser indicates in the attribute AE he accepts e the Gzip encoding format. In this case, the embedded server 139 detects that the sender of the request accepts the compressed data in the Gzip encoding format. It forms a response http 300 for the browser 150 through the interface 137. In this response: the response body 304 contains data compressed DATA-C, corresponding to the requested web page (or part of the page), as loaded from non-volatile memory 134, and additional data D1 ', D2' corresponding to the server's coding format (Fig. 3); the attribute CE in the header 302 of the response is filled with the code value corresponding to the coding format used by the server. The microprocessor 140 of the terminal receives this response 300, detects that it is an http response, and transmits it to the browser 150 which will analyze it. The browser 150 detects by analyzing the attribute in the header 302 of the response the coding format of the body 304 of the response. It makes a corresponding request to the microprocessor 140. In particular, the microprocessor applies the decompression algorithm corresponding to the compressed DATA-C data transmitted, and returns the decompressed data to the browser 150, which will control their display at 110.

Le procédé de traitement qui vient d'être décrit avec une décompression sous condition des données de la page web, avant leur émission par le serveur embarqué vers le navigateur, permet avantageusement d'optimiser l'occupation du lien de communication entre le terminal et le dispositif électronique portable chaque fois que c'est possible, ~o c'est à dire chaque fois que le navigateur du terminal est apte à accepter des données dans le format de codage (avec compression) implémenté par le serveur, et qui est égal ou compatible à celui utilisé pour compresser la page web hébergée par le dispositif électronique portable. En particulier, si la page web 135 est au format "deflate", et que le 15 serveur embarqué met en oeuvre le format Gzip, le serveur embarqué extrait les données compressées DATA-C de la page web mémorisée, et forme le corps de la réponse au format Gzip avec les données compressées DATA-C chargées, et des données supplémentaires propres Dl', D2' au format Gzip encapsulant ces données compressées (figure 3). Dans une variante, qui 20 pourrait correspondre à la situation pratique suivante : -la page web 135 est compressée au format de codage "deflate"; -le serveur 139 implémente le format de codage Gzip, compatible du format de codage "deflate". -le navigateur indique dans l'attribut AE qu'il accepte le format de codage 25 "deflate". Alors le serveur prépare une réponse correspondante avec uniquement la partie "deflate" du gzip, c'est à dire seulement les données DATA-C sans les données Dl et D2 propres au format deflate (figure 1). En d'autres termes, le serveur peut le cas échéant envoyer les données DATA- 30 C (format "deflate"), sans encapsulation. La mise en oeuvre de ce procédé par le serveur 139 peut nécessiter le codage en mémoire programme 133 du dispositif électronique portable 130, de différents algorithmes de décompression DEC susceptibles d'être appelés par le serveur 139 selon le format de codage de la page 135, 35 et d'un programme de traitement des requêtes http correspondant, compte tenu des possibilités prévues notamment dans le format Gzip d'utiliser différents algorithmes de compression. Dans ce cas, le serveur saura aller chercher dans les données supplémentaires (Dl, D2), l'identification de l'algorithme de compression utilisé et appeler l'algorithme de décompression correspondant. Le dispositif électronique portable 130 comprend par ailleurs des moyens pour recevoir et programmer en mémoire non volatile les données compressées correspondant à la compression de la page ou des pages d'un site web élaboré par le fournisseur des services. Cette compression de chaque page du site web et la mémorisation de la page compressée résultante en mémoire non volatile du dispositif électronique portable sont des étapes réalisées dans une des phases de personnalisation du dispositif électronique. La phase de personnalisation du dispositif électronique portable comprendra pour chaque page web, une étape de compression des données de la page selon un format de codage déterminé, pour fournir un flot de données compressées correspondantes dans ce format de codage, et une étape de programmation de ce flot de données dans la mémoire non volatile du dispositif électronique programmable. Comme ce dispositif portable sert à une authentification de l'utilisateur d'un terminal, pour un ou des services d'un fournisseur, cette phase comprend une première étape d'authentification qui vérifie les droits du fournisseur à procéder à cette personnalisation. De préférence, et comme illustré de manière schématique sur la figure 4, la phase de personnalisation est une phase de personnalisation électrique dudit dispositif portable qui utilise un équipement de personnalisation 400, typiquement un ordinateur auquel le dispositif portable 130 est connecté par une interface 420, typiquement une liaison série suivant la norme ISO 7816 des cartes à puce, et avantageusement, une liaison USB. Elle comprend une phase d'authentification 20.1 de cet équipement 400 par le dispositif électronique portable, avant une étape 20.3 de programmation des données du site web sous forme compressée en mémoire non volatile reprogrammable 135, avec l'envoi d'une ou plusieurs instructions de mémorisation 11, 12 des données compressées, chaque instruction contenant une partie au moins de ces données. The processing method which has just been described with a decompression under condition of the data of the web page, before being transmitted by the embedded server to the browser, advantageously makes it possible to optimize the occupation of the communication link between the terminal and the terminal. portable electronic device whenever possible, ~ o ie whenever the terminal browser is able to accept data in the encoding format (with compression) implemented by the server, and which is equal or compatible with the one used to compress the web page hosted by the portable electronic device. In particular, if the web page 135 is in "deflate" format, and the embedded server implements the Gzip format, the embedded server extracts the compressed DATA-C data from the stored web page, and forms the body of the response in Gzip format with the compressed data DATA-C loaded, and additional data own Dl ', D2' Gzip format encapsulating these compressed data (Figure 3). In a variant, which could correspond to the following practical situation: the web page 135 is compressed in the "deflate" encoding format; the server 139 implements the Gzip coding format, compatible with the "deflate" coding format. the browser indicates in the attribute AE that it accepts the encoding format 25 "deflate". Then the server prepares a corresponding response with only the "deflate" part of the gzip, ie only the DATA-C data without the data Dl and D2 specific to the deflate format (Figure 1). In other words, the server may optionally send DATA-C data ("deflate" format) without encapsulation. The implementation of this method by the server 139 may require the coding in the program memory 133 of the portable electronic device 130, different decompression algorithms DEC may be called by the server 139 according to the coding format on page 135, 35 and a corresponding http request processing program, given the possibilities provided in particular in the Gzip format to use different compression algorithms. In this case, the server will be able to search in the additional data (D1, D2) for identification of the compression algorithm used and to call the corresponding decompression algorithm. The portable electronic device 130 also comprises means for receiving and programming in non-volatile memory the compressed data corresponding to the compression of the page or pages of a website developed by the service provider. This compression of each page of the web site and the storage of the resulting compressed page in non-volatile memory of the portable electronic device are steps performed in one of the personalization phases of the electronic device. The personalization phase of the portable electronic device will comprise, for each web page, a step of compressing the data of the page according to a determined coding format, to provide a stream of corresponding compressed data in this coding format, and a programming step of this stream of data in the non-volatile memory of the programmable electronic device. As this portable device is used to authenticate the user of a terminal for one or services of a provider, this phase includes a first authentication step which verifies the rights of the provider to carry out this customization. Preferably, and as schematically illustrated in FIG. 4, the personalization phase is a phase of electrical customization of said portable device which uses personalization equipment 400, typically a computer to which the portable device 130 is connected by an interface 420, typically a serial link according to the ISO 7816 standard of smart cards, and advantageously, a USB link. It includes an authentication phase 20.1 of this equipment 400 by the portable electronic device, before a step 20.3 of programming the data of the web site in compressed form in non-volatile memory reprogrammable 135, with the sending of one or more instructions of storage 11, 12 compressed data, each instruction containing at least a portion of these data.

En pratique, l'équipement de personnalisation 400 comprend un microprocesseur 410, avec en mémoire non volatile (disque dur) : -un module cryptographique 430 et une clé d'authentification 440; -le site web 450 comprenant une ou plusieurs pages 450a, 450b 5 par exemple; -un programme de compression 460. Une phase de personnalisation électrique sera alors typiquement réalisée suivant la séquence suivante : Dans une étape 20.1, le microprocesseur 410 s'authentifie auprès 10 de 130 en utilisant la clef 440 et le module cryptographique 430 (étape 20.1). Le dispositif électronique portable 130 authentifie l'équipement 400 à l'aide de la clef 136 et de ses moyens cryptographiques (non représentés). La programmation du site web comprend alors les phases 15 suivantes, pour chaque page : -Dans une étape 20.2, le microprocesseur 410 compresse les données d'une page du site web, par exemple la page 450a, en utilisant le programme de compression 460, fournissant un flot de données compressées 500. 20 -Puis dans une étape de programmation électrique, le microprocesseur 410 envoie une ou plusieurs instructions 11, 12 de programmation au dispositif électronique portable 130 avec le flot de données compressées 500, en mémoire non volatile 134, typiquement une mémoire non volatile.In practice, the personalization equipment 400 comprises a microprocessor 410, with nonvolatile memory (hard disk): a cryptographic module 430 and an authentication key 440; the website 450 comprising one or more pages 450a, 450b for example; a compression program 460. An electrical customization phase will then typically be performed according to the following sequence: In a step 20.1, the microprocessor 410 authenticates with 130 by using the key 440 and the cryptographic module 430 (step 20.1) . The portable electronic device 130 authenticates the equipment 400 using the key 136 and its cryptographic means (not shown). The programming of the website then comprises the following phases for each page: In a step 20.2, the microprocessor 410 compresses the data of a page of the website, for example page 450a, using the compression program 460, providing a flow of compressed data 500. -Then in an electrical programming step, the microprocessor 410 sends one or more programming instructions 11, 12 to the portable electronic device 130 with the compressed data stream 500, in nonvolatile memory 134, typically a non-volatile memory.

25 Le format de codage utilisé pour compresser les pages du site web est compatible au ou à un format de codage implémenté par le serveur embarqué SCWS. Dans un exemple pratique, le serveur SCWS implémente le format de codage Gzip, et le dispositif de personnalisation qui assure la 30 compression des pages utilise le format Zip, avec une compression de type "deflate". L'invention qui vient d'être décrite s'applique notamment aux cartes à puce, notamment aux cartes SIM ou (U)SIM, et facilite le développement de sites web hébergés en local sur ces cartes. 35 The encoding format used to compress the pages of the web site is compatible with the or an encoding format implemented by the SCWS embedded server. In a practical example, the SCWS server implements the Gzip encoding format, and the personalization device that provides the page compression uses the Zip format, with "deflate" type compression. The invention that has just been described applies particularly to smart cards, including SIM cards or (U) SIM, and facilitates the development of websites hosted locally on these cards. 35

Claims (19)

REVENDICATIONS 1. Procédé de traitement par un serveur web (139) embarqué dans un dispositif électronique portable d'authentification (130), d'une requête http (200) transmise par un terminal hôte (100) du dispositif, d'accès à une page web (135) mémorisée dans le dispositif électronique, caractérisé en ce qu'il est appliqué à une page (135) mémorisée sous une forme compressée, et en ce qu'il comprend une étape de chargement (10.1) de données compressées (DATA-C) de ladite page, une étape de décompression (10.2) desdites données chargées, produisant des données décompressées (DATA-D), une étape de formation d'un corps (304) d'une réponse http correspondante (300) ~o avec lesdites données décompressées, et une étape d'émission de ladite réponse. A method of processing by a web server (139) embedded in a portable electronic authentication device (130), an http request (200) transmitted by a host terminal (100) of the device, access to a page web (135) stored in the electronic device, characterized in that it is applied to a page (135) stored in a compressed form, and in that it comprises a step of loading (10.1) compressed data (DATA- C) of said page, a step of decompressing (10.2) said loaded data, producing decompressed data (DATA-D), a step of forming a body (304) of a corresponding http response (300) ~ o with said decompressed data, and a step of transmitting said response. 2. Procédé de traitement selon la revendication 1, caractérisé en ce qu'il comprend une étape de compression de ladite page dans un format de codage compatible d'au moins un format de codage implémenté dans ledit 15 serveur SCWS, produisant des données compressées de la page (DATA-C) et au moins une donnée supplémentaire indicative dudit format de codage appliqué, et en ce que l'étape de décompression des données chargées (DATA-C) est précédée d'une étape de lecture (10.0) de ladite donnée supplémentaire, pour appliquer un algorithme de décompression 20 correspondant. 2. Processing method according to claim 1, characterized in that it comprises a step of compressing said page in a coding format compatible with at least one coding format implemented in said SCWS server, producing compressed data of the page (DATA-C) and at least one additional piece of data indicative of said coding format applied, and in that the step of decompressing the loaded data (DATA-C) is preceded by a reading step (10.0) of said additional data, to apply a corresponding decompression algorithm. 3. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que ladite étape de décompression est activée pour former la réponse de toute requête http d'accès à une page web mémorisée sous forme compressée dans ledit dispositif. 25 3. Processing method according to claim 1 or 2, characterized in that said decompression step is activated to form the response of any http request for access to a web page stored in compressed form in said device. 25 4. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que le serveur implémente un format de codage identique ou compatible du format de codage de la page, pour l'émission de données compressées, et en ce que l'étape de décompression n'est activée que si ladite requête contient une information de codage de contenu en entête excluant l'émission 30 dans le corps de réponse de données compressées dans ledit format de codage du serveur. 4. Processing method according to claim 1 or 2, characterized in that the server implements an identical or compatible encoding format of the coding format of the page, for the transmission of compressed data, and in that the step of decompression is enabled only if said request contains header content encoding information excluding transmission in the response body of compressed data in said server encoding format. 5. Procédé de traitement selon l'une quelconque des revendications précédentes, caractérisé en ce que les données sont chargées et/oudécompressées à la volée, en mémoire de travail dudit dispositif électronique. 5. Processing method according to any one of the preceding claims, characterized in that the data are loaded and / or decompressed on the fly, working memory of said electronic device. 6. Procédé de traitement selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est appliqué à une page web contenant des données de type texte, et/ou image, et/ou son, et/ou scripts. 6. Processing method according to any one of the preceding claims, characterized in that it is applied to a web page containing text type data, and / or image, and / or sound, and / or scripts. 7. Procédé de traitement selon l'une quelconque des revendications précédentes, de requêtes http (300) émises par un navigateur (150) implémenté dans ledit terminal hôte (100). A method of processing as claimed in any one of the preceding claims, of http requests (300) issued by a browser (150) implemented in said host terminal (100). 8. Procédé de traitement selon la revendication 7 en combinaison avec la revendication 4, caractérisé en ce qu'une étape d'émission d'une requête par ledit navigateur (150) comprend le remplissage de ladite information de codage de contenu (AE) de l'entête (202), en fonction des formats de codage qu'il peut traiter. 8. Processing method according to claim 7 in combination with claim 4, characterized in that a step of issuing a request by said browser (150) comprises filling said content coding information (AE) of the header (202), depending on the encoding formats that it can handle. 9. Procédé de traitement selon l'une quelconque des revendications 15 précédentes, caractérisé en ce qu'il comprend une étape de réception et de mémorisation d'une page web au moins dans ledit dispositif électronique portable, ladite étape de réception et mémorisation étant préalable à l'étape de réception d'une requête. 9. Processing method according to any one of the preceding claims, characterized in that it comprises a step of receiving and storing a web page at least in said portable electronic device, said receiving and storing step being prior at the step of receiving a request. 10. Procédé de traitement selon la revendication 9, caractérisé en ce que 20 ladite étape de réception et mémorisation est une étape activée par une étape de programmation d'un processus de personnalisation du dispositif électronique portable (130) par programmation de données dans une mémoire non volatile (134) dudit dispositif, ledit processus comprenant une étape de compression d'une page web (450a), pour fournir des données 25 compressées correspondantes (500), et l'étape de programmation desdites données compressées en mémoire non volatile (134). 10. The processing method as claimed in claim 9, characterized in that said step of receiving and storing is a step activated by a step of programming a personalization process of the portable electronic device (130) by programming data in a memory nonvolatile (134) of said device, said process comprising a step of compressing a web page (450a), to provide corresponding compressed data (500), and the step of programming said compressed data in nonvolatile memory (134); ). 11. Dispositif électronique portable (130) à serveur embarqué (139) apte à donner accès à au moins une page web mémorisée dans ledit dispositif, caractérisé en ce que ladite page web (135) est mémorisée sous une forme 30 compressée, et en ce que ledit serveur (139) est configuré pour charger, sur réception d'une requête http (300) d'accès à ladite page, des données compressées (DATA-C) de ladite page (135), décompresser (DEC) lesdites données chargées, (DATA-D) et former une réponse (300) à la requête http, avec lesdites données décompressées (DATA-D). 35 11. A portable electronic device (130) with an embedded server (139) capable of giving access to at least one web page stored in said device, characterized in that said web page (135) is stored in a compressed form, and in that said server (139) is configured to load, upon receipt of an http (300) request to access said page, compressed data (DATA-C) of said page (135), decompress (DEC) said loaded data , (DATA-D) and form a response (300) to the request http, with said data decompressed (DATA-D). 35 12. Dispositif selon la revendication 11, caractérisé en ce que la ou les pages web mémorisées comprennent du texte et/ou des images, et/ou du son. 12. Device according to claim 11, characterized in that the stored web page or pages comprise text and / or images, and / or sound. 13. Dispositif électronique portable selon la revendication 11 ou 12, caractérisé en ce qu'il comprend une mémoire non volatile (134), contenant la ou les pages web compressées. 13. Portable electronic device according to claim 11 or 12, characterized in that it comprises a non-volatile memory (134) containing the compressed web page or pages. 14. Dispositif selon la revendication 13, caractérisé en ce que ladite mémoire non volatile (134) est du type électriquement programmable. 14. Device according to claim 13, characterized in that said non-volatile memory (134) is of the electrically programmable type. 15. Dispositif électronique portable selon l'une quelconque des revendications 11 à 14, caractérisé en ce que ledit serveur implémente un format de codage égal ou compatible du format de codage de la page, pour transmettre des données compressées dans une réponse, et en ce qu'il comprend des moyens pour analyser dans chaque requête http qu'il reçoit, une information de codage de contenu (AE) dans un entête (202) de la requête, pour déterminer si l'émetteur de la requête accepte de recevoir lesdites données compressées (DATA-C) dans le format de codage du serveur, et des moyens de formation d'un corps (304) de réponse (300) à ladite requête, à partir des données telles que chargées de la mémoire, sous forme compressée (DATA-C), ou après décompression, en fonction du résultat de ladite analyse. Portable electronic device according to any one of claims 11 to 14, characterized in that said server implements a coding format equal to or compatible with the coding format of the page, for transmitting compressed data in a response, and in that it comprises means for analyzing in each http request it receives, Content Encoding Information (AE) in a header (202) of the request, to determine if the sender of the request accepts to receive said data compressed (DATA-C) in the encoding format of the server, and means for forming a response body (304) (300) to said request, from the data as loaded from the memory, in compressed form ( DATA-C), or after decompression, depending on the result of said analysis. 16. Dispositif électronique portable selon l'une quelconque des revendications 11 à 15, connecté à un terminal hôte (100) comprenant un navigateur (150), caractérisé en ce que des requêtes reçues sont des requêtes dudit navigateur. 16. Portable electronic device according to any one of claims 11 to 15, connected to a host terminal (100) comprising a browser (150), characterized in that received requests are requests from said browser. 17. Dispositif électronique portable selon l'une quelconque des revendications 11 à 16, caractérisé en ce qu'il comprend des moyens pour recevoir et programmer au moins une page web sous forme compressée (135) en mémoire non volatile (134), d'un dispositif de personnalisation, ledit dispositif de personnalisation comprenant des moyens de chargement d'au moins une page web (450a), des moyens de compression, aptes à fournir des données compressées (500) de ladite page web (450a), et des moyens de programmation desdites données compressées (500) en mémoire non volatile (134) dudit dispositif électronique portable. 17. A portable electronic device according to any one of claims 11 to 16, characterized in that it comprises means for receiving and programming at least one web page in compressed form (135) in non-volatile memory (134), a personalization device, said personalization device comprising means for loading at least one web page (450a), compression means, able to provide compressed data (500) of said web page (450a), and means programming said compressed data (500) in nonvolatile memory (134) of said portable electronic device. 18. Procédé de personnalisation d'un dispositif électronique portable (130) par programmation de données dans une mémoire non volatile (134) dudit dispositif, caractérisé en ce qu'il comprend une étape de chargement d'au moins une page web (450a), une étape de compression de données d'une page web (450a) pour fournir dès données compressées correspondantes (500), et une étape de programmation desdites données compressées en mémoire non volatile. 18. A method of personalizing a portable electronic device (130) by programming data in a non-volatile memory (134) of said device, characterized in that it comprises a step of loading at least one web page (450a) , a data compression step of a web page (450a) for providing corresponding compressed data (500), and a step of programming said compressed data in non-volatile memory. 19. Procédé de personnalisation selon la revendication 18, pour une mémoire non volatile (134) électriquement programmable, caractérisé en ce qu'il est mis en oeuvre dans un procédé de personnalisation électrique dudit dispositif comprenant une étape d'authentification du dispositif préalable à ladite étape de compression, et l'étape de programmation comprenant une étape d'envoi (20.3) au dit dispositif d'une ou plusieurs instructions (11, 12) de mémorisation desdites données compressées (500) en mémoire non volatile reprogrammable, chaque instruction contenant une partie au moins desdites données.10 19. Personalization method according to claim 18, for a non-volatile memory (134) electrically programmable, characterized in that it is implemented in a method of electrical personalization of said device comprising a step of authenticating the device prior to said compression step, and the programming step comprising a step of sending (20.3) to said device one or more instructions (11, 12) for storing said compressed data (500) in non-volatile memory reprogrammable, each instruction containing at least a part of said data.
FR0759289A 2007-11-26 2007-11-26 METHOD FOR PROCESSING HTTP REQUESTS BY A WEB SERVER IN A PORTABLE ELECTRONIC DEVICE Expired - Fee Related FR2924295B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0759289A FR2924295B1 (en) 2007-11-26 2007-11-26 METHOD FOR PROCESSING HTTP REQUESTS BY A WEB SERVER IN A PORTABLE ELECTRONIC DEVICE

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0759289A FR2924295B1 (en) 2007-11-26 2007-11-26 METHOD FOR PROCESSING HTTP REQUESTS BY A WEB SERVER IN A PORTABLE ELECTRONIC DEVICE

Publications (2)

Publication Number Publication Date
FR2924295A1 true FR2924295A1 (en) 2009-05-29
FR2924295B1 FR2924295B1 (en) 2017-08-18

Family

ID=39719056

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0759289A Expired - Fee Related FR2924295B1 (en) 2007-11-26 2007-11-26 METHOD FOR PROCESSING HTTP REQUESTS BY A WEB SERVER IN A PORTABLE ELECTRONIC DEVICE

Country Status (1)

Country Link
FR (1) FR2924295B1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0935193A2 (en) * 1998-02-06 1999-08-11 Hewlett-Packard Company World wide web agent
WO2002010889A2 (en) * 2000-07-28 2002-02-07 Sun Microsystems, Inc. Adding secure external virtual memory to smart cards
EP1691536A1 (en) * 2005-02-14 2006-08-16 Axalto SA Smart phones with web based interfaces

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0935193A2 (en) * 1998-02-06 1999-08-11 Hewlett-Packard Company World wide web agent
WO2002010889A2 (en) * 2000-07-28 2002-02-07 Sun Microsystems, Inc. Adding secure external virtual memory to smart cards
EP1691536A1 (en) * 2005-02-14 2006-08-16 Axalto SA Smart phones with web based interfaces

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MI-JOUNG CHOI ET AL: "An Efficient Embedded Web Server for Web-based Network Element Management", 20000410; 20000410 - 20000414, 10 April 2000 (2000-04-10), pages 187 - 200, XP010376683 *
OPEN MOBILE ALLIANCE: "Smartcard-Web-Server - Draft Version 1.0 ? 01 Feb 2006 - OMA-TS-Smartcard-Web-Server-V1_0-20060201-D", OPEN MOBILE ALLIANCE STANDARD, 1 February 2006 (2006-02-01), XP002494693, Retrieved from the Internet <URL:http://member.openmobilealliance.org/ftp/Public_documents/SEC/SCT/2006/OMA-SCT-2006-0009R02-SCWS-spec-initial.zip> [retrieved on 20080905] *

Also Published As

Publication number Publication date
FR2924295B1 (en) 2017-08-18

Similar Documents

Publication Publication Date Title
EP1909462B1 (en) Method of compartmentalised provision of an electronic service
EP1208684B1 (en) Method for high rate data flow transmission on an internet-type network between a server and a smart card terminal, in particular a multimedia data flow
EP2795878B1 (en) Method for sharing multimedia contents between users.
US20150026477A1 (en) System and method for delivering application content
US20120246476A1 (en) Multi-application smart card, and system and method for multi-application management of smart card
CN111744174A (en) Account management method and device of cloud game, account login method and device and electronic equipment
FR3013541A1 (en) METHOD AND DEVICE FOR CONNECTING TO A REMOTE SERVICE
FR3025377A1 (en) MANAGEMENT OF ELECTRONIC TICKETS
WO2010006914A1 (en) Method of authenticating a user of a service on a mobile terminal
EP1983722A2 (en) Method and system for securing internet access from a mobile telephone, corresponding mobile telephone and terminal
EP0996300B1 (en) Method for accessing server services from a mobile station subscriber identity module and terminal for carrying out the method
WO2009007653A1 (en) Method for protecting applications installed on a secured module, and related terminal, security module and communication equipment
FR2924295A1 (en) HTTP request processing method for accessing web page in e.g. subscriber identity module card, of electronic system, involves decompressing loaded data, forming body of HTTP response with decompressed data, and transmitting HTTP response
EP2159763B1 (en) System and method for delivering a good or a service to a user
EP1413158B1 (en) Method of accessing a specific service offered by a virtual operator and the chip card for a corresponding device
EP1326399B1 (en) Method for securing the download of active data to a terminal
EP1894407B1 (en) Method and device for making secure access to multimedia contents
FR2923041A1 (en) METHOD OF OPENING SECURED TO THIRDS OF A MICROCIRCUIT CARD.
EP4078922B1 (en) Method for obtaining a command relating to a network access profile of an euicc security module
WO2019129941A1 (en) Method for authentication by means of a mobile terminal using a key and a certificate stored on an external medium
EP2710779A1 (en) Method for securing an authentication platform, and corresponding hardware and software
WO2021191546A1 (en) Method and device for supplying a terminal of a first user with a biometric signature of a second user
WO2020148492A1 (en) Authorization for the loading of an application onto a security element
FR3110262A1 (en) Method and system for authenticating a user to an authentication server
FR3113801A1 (en) Method for providing a third-party communication terminal with an authorization to use a customer account, associated methods and associated devices

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

PLFP Fee payment

Year of fee payment: 12

PLFP Fee payment

Year of fee payment: 13

ST Notification of lapse

Effective date: 20210706