WO2007074119A1 - Systeme et procede pour le deploiement d'applications web personnalisees - Google Patents

Systeme et procede pour le deploiement d'applications web personnalisees Download PDF

Info

Publication number
WO2007074119A1
WO2007074119A1 PCT/EP2006/069966 EP2006069966W WO2007074119A1 WO 2007074119 A1 WO2007074119 A1 WO 2007074119A1 EP 2006069966 W EP2006069966 W EP 2006069966W WO 2007074119 A1 WO2007074119 A1 WO 2007074119A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
server
user
personalization
data
Prior art date
Application number
PCT/EP2006/069966
Other languages
English (en)
Inventor
Jean-Jacques Vandewalle
Original Assignee
Gemplus
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 Gemplus filed Critical Gemplus
Priority to US12/438,693 priority Critical patent/US20100070566A1/en
Priority to EP06830739A priority patent/EP1969461A1/fr
Publication of WO2007074119A1 publication Critical patent/WO2007074119A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms

Definitions

  • the present invention relates to the architecture and deployment of custom web applications.
  • a Web application is typically in the form of HTML (HyperText Markup Language) or XHTML (HTML 4 to XML), from a Web server and running in a browser (English browser). ) on the user terminal of the user.
  • HTML HyperText Markup Language
  • XHTML HTML 4 to XML
  • the user is then able to interact with the application by going from one page to another by clicking on hypertext links or by filling in forms.
  • These actions correspond to a request sent to the web server via the browser according to the protocol of the Web, namely HTTP (acronym for HyperText Transport Protocol).
  • HTTP HTTP (acronym for HyperText Transport Protocol).
  • the server decodes and executes the request, then returns, again via the HTTP protocol, a new HTML page that corresponds to the result of the execution of the request. This page is then displayed by the browser and the user can view it and continue to interact with the application from this new page.
  • the architecture allowing the deployment of such applications is therefore adapted to the request-response model and the HTML presentation format, that is to say that an application from a web server decodes queries, performs processing to compute the response data, format these responses in HTML format, and return the final page to the requestor, the web browser installed at the user's endpoint.
  • a Web application thus consists in the installation of its program on a Web server, which will manage the exchange of messages in HTTP format, and often in the interconnection of this application with databases in which the application will be able to draw the data to present.
  • Customizing a Web application is to make this application the best suited to the needs and characteristics of each user, for example by providing quick access to the functions that it performs most often, allowing it to automate certain suites of treatment, presenting him with a human-machine interface (HMI) that corresponds to his preferences, etc.
  • HMI human-machine interface
  • the known solutions for customizing web applications are the following (not mutually exclusive, they can add up): integration of a customization program in the program of the application itself.
  • This generic customization program is then scheduled to be executed by the program of the application on the Web server during each processing (decoding and execution) HTTP request received from a user via his browser.
  • the effect of such a personalization program on the processing of the request is then to potentially come to modify the nature or adapt the formatting of the results of the execution of the query; use of personalization programs diversified by the program of the application (according to the users or, more generally, the user profiles).
  • These diversified customization programs are then selected to be executed with the application (as described in the previous point) according to the user (or his profile) who issued the request;
  • HTML pages corresponding best to the uses and preferences of the user. For example, if a Web application offers a dozen features (for example, via a list of hypertext links) and the user usually uses only three, the application customization program can consist of ordering access to these ten features most at least used by the user. This can be achieved by registering in the "Users" database a feature-based counter, which is incremented each time the user uses a feature.
  • the customization program which is integrated into the application program on the application's web server, consults the list of counters, sorts it, and integrates it in an orderly way into the results page that is returned by the Web application to the application. user terminal browser. This personalization program must also maintain this list of counters, that is to say, increment the counter corresponding to the functionality that has just been requested by the user.
  • the web server intended to execute, on request, the program of the application must also run the personalization program to achieve the final custom final page required before serving it to the client terminal.
  • program management and personalization data have the same general characteristics, particularly in terms of availability, scalability, adaptability and security, as those related to the management of the application itself. .
  • the architecture of a custom web application as it stands today is essentially monolithic and offers few facilities and guarantees that customization is available anywhere for the user, or that it can be evolve (to enrich or simplify) regardless of the application, or the fact that it can adapt to the content of the application and the environment in which the application runs (for example a station workstation or mobile phone), or the fact that the user's private data needed for personalization is protected.
  • the present invention aims to solve one or more of these disadvantages, by proposing the implementation of custom web applications mainly ensuring the decoupling of programs and personalization data with respect to the application parts from the Web server.
  • the subject of the invention is a method of customizing a Web application, intended to be executed on a terminal of a user via a browser equipping the terminal, on request sent via a telecommunications network from the browser to a remote web server hosting the application, characterized in that it comprises: -hosting at least one personalization program and / or personalization data by a local server specific to the user associated with the terminal and
  • the local server specific to the user is made in the form of a web server embedded in a portable digital device connected to the terminal of the user.
  • the local server specific to the user is installed on the terminal of the user.
  • the step of mixing the data relating to the Web application with the personalization program and / or the personalization data is performed in the browser of the terminal of the user through which executes. the application.
  • the mixing step comprises:
  • the step of mixing the data relating to the Web application with the personalization program and the personalization data is performed in the remote server.
  • the mixing step comprises:
  • access to the program (s) and / or personalization data on the local server is secure.
  • securing access to the local server includes user authentication.
  • the invention also relates to a system for customizing a Web application, comprising a terminal of a user having a browser comprising means for sending a request according to a data transfer protocol to a remote server hosting the application.
  • application and means for receiving and executing on the user's terminal the result of the processing of the request by the remote server said system being characterized in that it comprises a local server specific to the user associated with the terminal, hosting at least one program for personalizing the application and / or personalization data of the application, and means for mixing the web application provided by the remote server with the personalization program and / or the personalization data hosted on the local server specific to the user.
  • the mixing means are integrated in the terminal browser.
  • the mixing means are integrated in the remote server.
  • the local server comprises a web server embedded on a portable digital device connected to the user's terminal.
  • the portable digital device comprises means for securing access to the program (s) and / or data hosted by the embedded server.
  • the portable digital apparatus is a smart card.
  • the invention also relates to a portable digital device comprising an integrated web server designed to communicate with a client according to a data transfer protocol, characterized in that the integrated server hosts at least one program and / or personalization data of a application hosted by a remote application server and includes means for providing access to the program (s) and / or personalization data of the application upon client request.
  • the integrated server communicates with a browser of a terminal of a user acting as a client, through which the application runs on the terminal of the user.
  • the apparatus comprises means for securing access to the program (s) and / or personalization data of the application.
  • FIG. 1 illustrates the architecture of FIG. a system for implementing custom web applications according to the invention.
  • the browser 40 of the user terminal also comprises means for receiving and executing on the terminal, the result of the processing of the request by the remote server, in order to display the corresponding page and thus to allow the user to continue to interact. with the application from the displayed page.
  • the system according to the invention mainly consists in providing means for implementing the customization of the requested Web application, so that it is thus best suited to the specific needs and characteristics specific to the user, by building the custom web application as an application mixing (or aggregating) portions of the application from the remote web server 10 and others, i.e. the program portions and application personalization data from a user-specific local web server associated with the user's terminal.
  • the programs and personalization data specific to each user of the application are deployed and hosted at the level of Web servers specific to each user, rather than in a centralized database present on the server.
  • Web application as is classically the case. This characteristic, as will be seen later, makes it possible to obtain a decoupling in the deployment and implementation of personalized Web applications, in the sense that the processing related to personalization can be advantageously decoupled from the processing carried out by the client.
  • Web server of the application to build on request a page of the application.
  • the web server 20 specific to each user, intended to host the customization program (s) and the personalization data of the application specific to the user is made in the form of a server.
  • Web embedded in a portable digital device 50 such as a smart card, a smart Multimedia Card (MMC), a USB key (“Universal Serial Bus”) smart or a mobile phone for example.
  • MMC smart Multimedia Card
  • USB key Universal Serial Bus
  • This embodiment then imposes on the user, carrying the card 50 integrating the local web server 20 and wishing to implement the customization of an application accessed, to connect his card 50 to the host terminal 30 through which he access, through the browser, to the application provided by the remote web server 10.
  • IP, TCP, HTTP / FTP / ...) these are standard Internet protocols allowing the host terminal 30 to address the card 50 as a ordinary server.
  • the portable device 50 is preferably equipped with means for securing access to data hosted on its integrated server, for example means for authenticating the user carrying the device, in order to authorize access only if the user whose personalization data is hosted on the local server is recognized.
  • the remote web server 10 thus provides the web application, while the portable device 50, via its embedded web server 20, is intended to provide the personalization program (s). as well as the personalization data of the application.
  • the implementation of the customization of the application is then carried out by mixing (or aggregation) of the personalization program and personalization data provided by the onboard local server 20 with the application data provided by the remote server 10 and corresponding to the processing of the request issued by the browser of the user terminal for access to a page of the application.
  • the mixing between the web application and the customization will be described in more detail later in the description.
  • the described architecture makes it possible to decouple the deployment of the programs and personalization data from the deployment of the Web application in its remote server, since the portable device of the user is used here as the local server of the programs and personalization data.
  • This architecture advantageously allows the application to operate even in the absence of customization, and change the customization without necessarily modifying the processing performed by the server.
  • the proposed architecture will allow to be able to evolve and adapt the customization with a lot of flexibility, since the programs and personalization data relating to the application are no longer directly related to the processing performed by the server.
  • the personalization will be able to evolve, to enrich or simplify itself, independently of the application, but also to be able to adapt, being for example more or less rich, to the content of the application on the one hand, and the environment in which the application is running, for example to take into account that it is a workstation or a mobile phone.
  • a first mixing mode is to execute the customization program by the card 50, on request from the remote server 10. More specifically, the remote server 10 serves the pages of the requested Web application, and requires the Web server 20 of the the user's card 50 personalization operations whose results are interpreted by the remote server 10 to be integrated into the final page returned by the remote server.
  • This embodiment where the mixing is performed via the remote server however requires that the card is accessible remotely from the remote server via the telecommunications network and also has the disadvantage of increasing the workload servers application.
  • a preferred embodiment consists in mixing the application parts from the remote application server 10 and the personalization-related parts coming from the local server 20, locally via the browser 40 of the user terminal 30 by the user. through which the application is accessed.
  • the host terminal browser-based mixing mode relies on Web technologies that build richer, more responsive, and more dynamic Web applications. These advanced applications allow the user to have a Web application that no longer presents itself as a succession of HTML pages (for example, consecutive to "clicks" on links) but as real desktop applications with an interface (or a "page" main or even unique) that changes as the actions of the user. Outside server queries
  • JavaScript which is a programming interface (or API) available in JavaScript to execute HTTP requests to a web server synchronously or asynchronously and this in the background, that is to say without the browser loads the results to this query as a new HTML page to display.
  • the results of this query often but not necessarily expressed in XML, can then be manipulated by the JavaScript program;
  • the method of mixing the Web application with the programs and personalization data in the user's browser is therefore based on the one hand, on the use of a Web server specific to each user, embedded in a device portable digital device such as a smart card and hosting the programs and personalization data of the user and, secondly, on the technologies and patterns described above to execute the personalization programs and pass on their results as well as the data of the user. customization on the pages of the application displayed by the browser. This mix allows decoupled custom web applications, whether or not these web applications are advanced.
  • ex-post mixing it is meant that the mixing is performed after the generic data relating to the application is provided to the browser by the remote server. This type of ex-post mixing is thus to put in opposition with the ex-ante mixing, that is to say done before the application is provided to the browser, resulting from the embodiment described above where the mixing is performed via the remote web server of the generic application.
  • the first example concerns the implementation of the personalization of the application via UserScripts provided by the portable device, for example a smart card, and via requests to the card issued by the browser.
  • the programs and personalization data are therefore UserScripts stored at the user's card level and are accessible via the web server integrated in the card.
  • the UserScripts of the card can be installed and saved in the user's browser.
  • a RegisterPersonalUserScript operation is added to GreaseMonkey.
  • the user triggers this operation, which connects to the web server of the user's card, itself connected to the host terminal.
  • the connection to the local server of the card can be performed with user authentication data provided by the latter, so as to allow the connection to the server only if the authentication has been successful.
  • the operation then installs the UserScripts in the browser.
  • the UsersScripts provided by the card are accompanied by the address book diagrams of web pages to which they apply and saved with them to GreasMonkey.
  • the corresponding UserScript is mixed with the application in the browser by being executed and thus realizing the customization of the page of the application according to the operations that are coded within it.
  • This UserScript can also send requests to the web server of the card (for example, via XMLHttpRequest), to dynamically recover personalization data specific to the user, which are used to achieve the customization of the page. Access to this data can also be secured by user authentication or by a diversification of the data access keys specific to the current session.
  • This data can be formatted in XML or any other format that the UserScript code expects to process.
  • the UserScript can not only retrieve data from the user's map but can also retrieve data from other web servers on the network. This UserScript can also download JavaScript programs from the user's map via the "On-demand JavaScript" design pattern.
  • a second embodiment is provided concerning the customization via JavaScript programs provided by the card and / or via requests to the card.
  • the HTML page of the application provided by the remote web server contains requests to load JavaScript programs to the card. Such a request is written on the application page by a standard HTML directive.
  • the application page "appli_l" contains the directive given below as an example, which will request the loading from the local web server of the map of the personal script.
  • this script containing for example the customization program in the form of a single function called customize ().
  • customize A multitude of functions can nevertheless be contained in the personalization script and the personalization program itself can be provided under the form of several scripts each containing functions.
  • the application's page When the application's page is loaded by the user's browser from the remote server, it is interpreted by the browser that executes the requests to load JavaScript programs encountered, from the local server on the card.
  • the personalization programs stored in the map as JavaScript programs are mixed with the application code in the browser.
  • These JavaScript programs are subsequently executed for example by including the following directive in the application page.
  • the JavaScript functions provided as customization programs by the local server integrated in the card can be executed by any other means for executing JavaScript programs within an HTML page, such as the reaction of an event (a click of the user, the mouse of the user passing over an element of the HTML page, etc.).
  • JavaScript programs above can, as in the case of the UserScripts described above, send requests to the web server of the card to dynamically recover personalization data specific to the user, which are used to perform the customization of the page. All operations involving the user's card (downloading JavaScript customization programs, queries to personalization data) can be secured by user authentication.
  • a more limited way to achieve customization in the browser is simply to include in JavaScript programs provided by the application itself queries (eg via XMLHttpRequest) to the web server of the card to dynamically recover personalization data specific to the user, which are used to customize the page.
  • Cross-domain security policy (“Cross-domain security policy”). It should be noted that the UserScripts used in the previous exemplary embodiment are not subject to this cross-domain security policy. This policy states that JavaScript programs on an HTML page can only come from the same server that served the page itself. Similarly, requests
  • XMLHttpRequest can only be at the destination server that served the page.
  • the embodiment as described here for mixing applications and customization must therefore overcome these problems in order to be implemented. Different (combinable) solutions are possible and are listed below.
  • some browsers like Internet Explorer, allow to configure this policy by the user.
  • the configuration can be based on the address of the remote server site, on an explicit request whenever this case arises (with the possibility to authorize until further notice), or on the presentation of certificates.
  • the domain pages corresponding to the remote server site providing the application may be allowed to load JavaScript programs from the user's card and to send XMLHttpRequest requests to the user's card.
  • an evolution of the browsers could allow the card itself to provide or not these JavaScript programs or to answer XMLHttpRequest requests according to the origin of the page, its certificates, or even according to a procedure of authentication between the card and the remote server (via the browser or directly between the card and the remote server via the Internet), to establish or not the trust.
  • This last example of implementation is equivalent to the previous one except that the Web application is this time served by the card itself rather than by a remote server. All other features of the previous exemplary embodiment are unchanged.
  • the advantage of this approach is to make the web application always available, even when the user's browser is not connected to the Internet.
  • the other thing is that there is no more cross-domain security policy problem since all parts of the application, including its customization, are provided by the same server, namely the card.
  • the decoupling between the application and its customization is well preserved, since they are always disjoint programs and data that are mixed in the browser of the host terminal, thus unloading the application server, that is to say the card in this embodiment, of this work, and still allowing to independently evolve the personalization of the application.
  • the entire application is not served by the local server of the user's card, but only a minimal part of it allowing him to work offline (without all the features).
  • additional parts of the application are downloaded from a remote server and mixed in the browser in the same way as in the previous example where the application and the customization were mixed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé de personnalisation d'une application Web, prévue pour être exécutée sur un terminal (30) d'un utilisateur par l'intermédiaire d'un navigateur (40) équipant le terminal, sur requête envoyée via un réseau de télécommunication (60) depuis le navigateur à un serveur Web (10) distant hébergeant l'application, caractérisé en ce qu'il comprend : l'hébergement d'au moins un programme de personnalisation et/ou de données de personnalisation par un serveur (20) local propre à l'utilisateur associé au terminal et la mise en œuvre de la personnalisation de l'application par mixage du programme de personnalisation et/ou des données de personnalisation fournis par le serveur local (20) avec des données relatives à l'application correspondant au traitement de la requête fournies par le serveur distant (10) .

Description

SYSTEME ET PROCEDE POUR LE DEPLOIEMENT D'APPLICATIONS WEB
PERSONNALISEES
La présente invention concerne l'architecture et le déploiement d'applications Web personnalisées.
Une application Web se présente typiquement sous la forme de pages HTML (acronyme anglo-saxon pour HyperText Markup Language) ou XHTML (reformulation de HTML 4 en XML), provenant d'un serveur Web et s 'exécutant dans un navigateur (browser en anglais) sur le terminal client de l'utilisateur.
L'utilisateur est alors à même d' interagir avec l'application en passant d'une page à l'autre en cliquant sur des liens hypertextes ou en remplissant des formulaires. Ces actions correspondent à une requête envoyée au serveur Web via le navigateur selon le protocole du Web, à savoir HTTP (acronyme anglo- saxon pour HyperText Transport Protocol) . Le serveur décode et exécute la requête, puis renvoie, toujours via le protocole HTTP, une nouvelle page HTML qui correspond au résultat de l'exécution de la requête. Cette page est alors affichée par le navigateur et l'utilisateur peut la consulter et continuer d' interagir avec l'application à partir de cette nouvelle page.
L'architecture permettant le déploiement de telles applications est donc adaptée au modèle requête-réponse et au format de présentation HTML, c'est-à-dire qu'une application provenant d'un serveur Web décode des requêtes, exécute des traitements pour calculer les données de la réponse, met en forme ces réponses dans le format HTML, et renvoie la page finale au requérant, soit le navigateur Web installé au niveau du terminal client de l'utilisateur.
Le déploiement d'une application Web consiste ainsi en l'installation de son programme sur un serveur Web, qui va gérer les échanges de messages selon le format HTTP, et bien souvent en l'interconnexion de cette application avec des bases de données dans lesquelles l'application va pouvoir puiser les données à présenter. La personnalisation d'une application Web consiste à rendre cette application la mieux adaptée aux besoins et caractéristiques de chaque utilisateur, par exemple en lui proposant un accès rapide aux fonctions qu'il réalise le plus souvent, en lui permettant d'automatiser certaines suites de traitement, en lui présentant une interface homme-machine (IHM) qui corresponde à ses préférences, etc.
Dans ce contexte, les solutions connues pour la personnalisation d'applications Web sont les suivantes (n'étant pas mutuellement exclusives, elles peuvent s'additionner) : intégration d'un programme de personnalisation dans le programme de l'application elle-même. Ce programme de personnalisation générique est alors prévu pour être exécuté par le programme de l'application sur le serveur Web lors de chaque traitement (décodage et exécution) de requête HTTP reçue d'un utilisateur via son navigateur. L'effet d'un tel programme de personnalisation sur le traitement de la requête est alors de venir potentiellement modifier la nature ou adapter la mise en forme des résultats de l'exécution de la requête ; utilisation de programmes de personnalisation diversifiée par le programme de l'application (selon les utilisateurs ou, plus généralement, les profils d'utilisateurs) . Ces programmes de personnalisation diversifiés sont alors sélectionnés pour être exécutés avec l'application (comme décrit au point précédent) en fonction de l'utilisateur (ou de son profil) ayant émis la requête ;
- stockage de données de personnalisation dans une base de données « Utilisateurs », qui est consultée par le programme de personnalisation pour effectuer ses traitements propres, c'est-à-dire ceux qui vont potentiellement modifier la nature ou adapter la mise en forme des résultats. Cette base de données peut être déployée sur le même serveur que l'application Web ou sur un serveur distant accessible via le protocole HTTP ou tout autre protocole ; - récupération de données de personnalisation sous forme de fichiers de témoins (« cookies » en anglais) , stockés et fournis par le navigateur Web du terminal client ou encore via des « données de session », fournies par l'application Web et stockées sous forme de paramètres, qui sont répétés dans chaque requête du navigateur .
Ces solutions de personnalisation permettent donc de formater, au niveau du serveur Web de l'application, des pages HTML correspondant le mieux aux usages et préférences de l'utilisateur. A titre d'exemple, si une application Web offre une dizaine de fonctionnalités (par exemple, via une liste de liens hypertextes) et que l'utilisateur n'en n'utilise généralement que trois, le programme de personnalisation de l'application peut consister à ordonner l'accès à ces dix fonctionnalités des plus au moins usitées par l'utilisateur. Cela peut être réalisé en enregistrant dans la base de données « Utilisateurs » un compteur par fonctionnalité, qui est incrémenté chaque fois que l'utilisateur utilise une fonctionnalité. Le programme de personnalisation, intégré au programme de l'application sur le serveur Web de l'application, consulte cette liste de compteurs, la trie et l'intègre de manière ordonnée dans la page de résultats qui est renvoyée par l'application Web au navigateur du terminal utilisateur. Ce programme de personnalisation doit aussi maintenir cette liste de compteurs, c'est-à-dire incrémenter le compteur correspondant à la fonctionnalité qui vient d'être requise par l' utilisateur.
L'architecture qui vient d'être décrite permettant la construction d'une application Web personnalisée est donc caractérisée par un fort couplage avec les moyens techniques permettant la construction de l'application elle-même .
Son déploiement est en effet totalement intégré à celui de l'application lorsque le programme de personnalisation est générique. Il peut simplement être nécessaire de requérir la gestion d'une base de données « utilisateurs » comme vu précédemment. Si les programmes de personnalisation sont diversifiés, il est alors nécessaire de déployer ces programmes par exemple dans la base de données « Utilisateurs », ce qui implique néanmoins de modifier l'architecture de l'application Web, notamment pour gérer la disponibilité de ces programmes.
De plus, le serveur Web prévu pour exécuter, sur requête, le programme de l'application, doit également exécuter le programme de personnalisation pour réaliser la page finale personnalisée requise avant de la servir au terminal client.
Il résulte de ce qui précède que la gestion des programmes et données de personnalisation présente les mêmes caractéristiques générales notamment en termes de disponibilité, d' évolutivité, d' adaptabilité et de sécurité, que celles liées a la gestion de l'application elle-même.
L'architecture d'une application web personnalisée telle qu'elle se présente aujourd'hui est essentiellement monolithique et offre peu de facilités et de garanties quant au fait que la personnalisation soit partout disponible pour l'utilisateur, ni au fait qu'elle puisse évoluer (pour s'enrichir ou se simplifier) indépendamment de l'application, ni au fait qu'elle puisse s'adapter au contenu de l'application et à l'environnement dans lequel s'exécute l'application (par exemple une station de travail ou un téléphone mobile) , ni encore au fait que les données privées de l'utilisateur nécessaires à la personnalisation soient protégées . La présente invention vise à résoudre un ou plusieurs de ces inconvénients, en proposant la mise en œuvre d'applications web personnalisée assurant principalement le découplage des programmes et données de personnalisation par rapport aux parties d'application provenant du serveur Web.
Avec cet objectif en vue, l'invention a pour objet un procédé de personnalisation d'une application Web, prévue pour être exécutée sur un terminal d'un utilisateur par l'intermédiaire d'un navigateur équipant le terminal, sur requête envoyée via un réseau de télécommunication depuis le navigateur à un serveur Web distant hébergeant l'application, caractérisé en ce qu' il comprend : -l'hébergement d'au moins un programme de personnalisation et/ou de données de personnalisation par un serveur local propre à l'utilisateur associé au terminal et
-la mise en œuvre de la personnalisation de l'application par mixage du programme de personnalisation et/ou des données de personnalisation fournis par le serveur local avec des données relatives à l'application correspondant au traitement de la requête fournies par le serveur distant. Selon un mode de réalisation, le serveur local propre à l'utilisateur est réalisé sous forme d'un serveur Web embarqué dans un appareil numérique portatif connecté au terminal de l'utilisateur. Selon un autre mode de réalisation, le serveur local propre à l'utilisateur est installé sur le terminal de l'utilisateur.
Selon un mode de réalisation, l'étape de mixage des données relatives à l'application Web avec le programme de personnalisation et/ou les données de personnalisation est effectuée dans le navigateur du terminal de l'utilisateur par l'intermédiaire duquel s'exécute l'application. Selon ce mode de réalisation, l'étape de mixage comprend :
-la récupération préalable par le navigateur des données relatives à l'application correspondant au traitement de la requête envoyée au serveur distant, -l'exécution par le navigateur d'opérations de personnalisation correspondant au programme de personnalisation et/ou aux données de personnalisation accèdes sur requête auprès du serveur local propre à l'utilisateur et -l'interprétation par le navigateur des résultats des opérations de personnalisation pour leur intégration aux données relatives à l'application.
Selon un autre mode de réalisation, l'étape de mixage des données relatives à l'application Web avec le programme de personnalisation et les données de personnalisation est effectué dans le serveur distant.
Selon cet autre mode de réalisation, l'étape de mixage comprend :
-la fourniture par le serveur distant au serveur local des données relatives à l'application correspondant au traitement de la requête envoyée par le navigateur au serveur distant,
-l'exécution par le serveur local d'opérations de personnalisation sur requête du serveur distant et -l'interprétation par serveur des résultats des opérations de personnalisation pour leur intégration aux données relatives à l'application à fournir au navigateur du terminal de l'utilisateur.
Avantageusement, l'accès au (x) programme et/ou données de personnalisation sur le serveur local est sécurisé .
De préférence, la sécurisation de l'accès au serveur local comprend une authentification de l ' utilisateur. L' invention concerne également un système de personnalisation d'une application Web, comprenant un terminal d'un utilisateur doté d'un navigateur comprenant des moyens d'envoi d'une requête selon un protocole de transfert de données à un serveur distant hébergeant l'application et des moyens pour recevoir et exécuter sur le terminal de l'utilisateur le résultat du traitement de la requête par le serveur distant, ledit système étant caractérisé en ce qu' il comprend un serveur local propre à l'utilisateur associé au terminal, hébergeant au moins un programme de personnalisation de l'application et/ou des données de personnalisation de l'application, et des moyens de mixage de l'application Web fourni par le serveur distant avec le programme de personnalisation et/ou les données de personnalisation hébergés sur le serveur local propre à l'utilisateur. Selon un mode de réalisation, les moyens de mixage sont intégrés dans le navigateur du terminal .
Selon un autre mode de réalisation, les moyens de mixage sont intégrés dans le serveur distant.
De préférence, le serveur local comprend un serveur Web embarqué sur un appareil numérique portatif connecté au terminal de l'utilisateur.
Avantageusement, l'appareil numérique portatif comprend des moyens de sécurisation de l'accès au(x) programme et/ou données hébergées par le serveur embarqué .
De préférence, l'appareil numérique portatif est une carte à puce. L'invention concerne encore un appareil numérique portatif comprenant un serveur Web intégré prévu pour communiquer avec un client selon un protocole de transfert de données, caractérisé en ce que le serveur intégré héberge au moins un programme et/ou des données de personnalisation d'une application hébergée par un serveur d'applications distant et comprend des moyens pour fournir un accès au (x) programme et/ou données de personnalisation de l'application sur requête du client . Avantageusement, le serveur intégré communique avec un navigateur d'un terminal d'un utilisateur agissant en tant que client, par l'intermédiaire duquel l'application s'exécute sur le terminal de l ' utilisateur . De préférence, l'appareil comprend des moyens pour sécuriser l'accès au (x) programme et/ou données de personnalisation de l'application.
De préférence, l'appareil est une carte à puce. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence au dessin annexé dans lequel : -la figure 1 illustre l'architecture d'un système permettant la mise en œuvre d'applications web personnalisées selon l'invention.
Comme illustré a la figure 1, le système selon l'invention permettant le déploiement d'applications Web personnalisées comprend le terminal 30 de l'utilisateur (type téléphone mobile, PDA, PC, etc.), équipé d'un navigateur 40 pour l'envoi d'une requête, typiquement selon le protocole http à travers le réseau Internet 60, à destination d'un serveur Web distant 10 hébergeant l'application. Le navigateur 40 du terminal utilisateur comprend également des moyens pour recevoir et exécuter sur le terminal, le résultat du traitement de la requête par le serveur distant, afin d'afficher la page correspondante et ainsi de permettre à l'utilisateur de continuer d' interagir avec l'application à partir de la page affichée.
Le système selon l'invention consiste principalement à prévoir des moyens permettant de mettre en œuvre la personnalisation de l'application Web demandée, de façon à ce qu'elle soit ainsi la mieux adaptée aux besoins et caractéristiques spécifiques propres à l'utilisateur, en construisant l'application Web personnalisée comme une application mixant (ou agrégeant) des parties de l'application provenant du serveur Web distant 10 et d'autres, c'est-à-dire les parties relatives aux programmes et données de personnalisation de l'application, provenant d'un serveur Web local 20 propre à l'utilisateur, associé au terminal de l'utilisateur.
Ainsi, grâce au système de l'invention, les programmes et données de personnalisation propres à chaque utilisateur de l'application sont déployés et hébergés au niveau de serveurs Web propres à chaque utilisateur, plutôt que dans une base de donnée centralisée présente sur le serveur Web de l'application, comme c'est classiquement le cas. Cette caractéristique, comme on le verra par la suite, permet d'obtenir un découplage dans le déploiement et la mise en œuvre d'applications Web personnalisées, en ce sens que les traitements liés à la personnalisation peuvent être avantageusement découplés des traitements réalisés par le serveur Web de l'application pour construire sur requête une page de l'application.
Selon un mode de réalisation préféré, le serveur Web 20 propre à chaque utilisateur, prévu pour héberger le ou les programmes de personnalisation ainsi que les données de personnalisation de l'application spécifiques de l'utilisateur, est réalisé sous la forme d'un serveur Web embarqué dans un appareil numérique portatif 50, telle qu'une carte à puce, une carte MMC (« Multimedia Card ») intelligente, une clé USB (« Universal Sériai Bus ») intelligente ou un téléphone mobile par exemple.
Ce mode de réalisation impose alors à l'utilisateur, porteur de la carte 50 intégrant le serveur Web local 20 et souhaitant mettre en œuvre la personnalisation d'une application accédée, de connecter sa carte 50 au terminal hôte 30 par l'intermédiaire duquel il accède, au travers du navigateur, à l'application fournie par le serveur Web distant 10. De façon connue en soit, le protocole de transfert de données de bas niveau (type T=O, T=I, USB, MMC.) entre le terminal et la carte à puce intégrant le serveur local est spécifique à ce type de liaison entre un terminal et une carte et le terminal est pourvu d'un outil de communication spécifique au protocole. Pour toutes les autres couches du protocole de transfert (IP, TCP, HTTP/FTP/...), il s'agit de protocoles standards de l'Internet permettant au terminal hôte 30 de s'adresser à la carte 50 comme à un serveur ordinaire.
L'appareil portatif 50 est de préférence équipé de moyens de sécurisation de l'accès aux données hébergées sur son serveur intégré, par exemple des moyens d' authentification de l'utilisateur porteur de l'appareil, afin de n'autoriser l'accès que si l'utilisateur dont les données de personnalisation sont hébergées sur le serveur local est reconnu.
Dans cette architecture, le serveur Web distant 10 fournit donc l'application Web, tandis que l'appareil portatif 50, via son serveur Web 20 embarqué, est prévu pour fournir le ou les programmes de personnalisation ainsi que les données de personnalisation de 1 ' application.
La mise en œuvre de la personnalisation de l'application est alors réalisée par mixage (ou agrégation) du programme de personnalisation et des données de personnalisation fournis par le serveur local 20 embarqué avec les données relatives à l'application fournies par le serveur distant 10 et correspondant au traitement de la requête émise par le navigateur du terminal utilisateur pour l'accès à une page de l'application. La réalisation du mixage entre l'application Web et la personnalisation sera décrite plus en détail plus loin dans la description.
A ce stade, on peut déjà noter que les avantages qui découlent de l'architecture précédemment décrite répondent aux objectifs visés par la présente invention. Notamment, l'architecture décrite permet de découpler le déploiement des programmes et données de personnalisation du déploiement de l'application Web dans son serveur distant, puisqu'on utilise ici l'appareil portatif de l'utilisateur en tant que serveur local des programmes et données de personnalisation. Cette architecture permet avantageusement à l'application de fonctionner même en l'absence de personnalisation, et de faire évoluer la personnalisation sans forcément modifier les traitements réalisés par le serveur.
Par ailleurs, en terme de disponibilité, le fait de répartir et déployer les programmes et données de personnalisation dans des appareils numériques portatifs propres à chaque utilisateur permet de rendre la personnalisation partout disponible pour l'utilisateur, voire que l'application personnalisée soit partout disponible.
Pour les mêmes raisons, l'architecture proposée va permettre de pouvoir faire évoluer et adapter la personnalisation avec beaucoup de souplesse, puisque les programmes et données de personnalisation relatives à l'application ne sont plus directement liés aux traitements réalisés par le serveur. Notamment, la personnalisation va pouvoir évoluer, pour s'enrichir ou se simplifier, indépendamment de l'application, mais aussi pouvoir s'adapter, en étant par exemple plus ou moins riche, au contenu de l'application d'une part, et à l'environnement dans lequel s'exécute l'application d'autre part, par exemple pour tenir compte qu'il s'agit d'une station de travail ou d'un téléphone mobile .
L'utilisation d'un serveur Web propre à l'utilisateur embarqué sur un appareil numérique portatif permet également de s'assurer, en prévoyant des moyens de sécurisation spécifiques sur l'appareil, que les données privées de l'utilisateur nécessaires à la personnalisation sont protégées.
Comme avantages supplémentaires, on peut également citer l'indépendance par rapport au terminal hôte utilisé par l'utilisateur (téléphone, PDA, PC,...) .
Selon une variante, on pourrait envisager d'installer le serveur Web propre à l'utilisateur hébergeant les données de personnalisation associées à l'utilisateur, directement sur le terminal hôte de l'utilisateur, au détriment toutefois du dernier avantage cité.
La réalisation du mixage entre l'application Web provenant du serveur Web distant et la personnalisation provenant du serveur local propre à l'utilisateur va maintenant être décrite plus en détail .
Un premier mode de mixage est de faire exécuter le programme de personnalisation par la carte 50, sur requête du serveur distant 10. Plus précisément, le serveur distant 10 sert les pages de l'application Web demandées, et requiert au serveur Web 20 de la carte 50 de l'utilisateur des opérations de personnalisation dont les résultats sont interprétés par le serveur distant 10 pour être intégrés à la page finale renvoyée par le serveur distant. Ce mode de réalisation où le mixage est réalisé via le serveur distant nécessite cependant que la carte soit accessible à distance depuis le serveur distant par l'intermédiaire du réseau de télécommunication et présente en outre l'inconvénient d'alourdir la charge de travail des serveurs d'application.
Aussi, un mode de réalisation préférentiel consiste à effectuer le mixage des parties d'application provenant du serveur d'application distant 10 et des parties relatives à la personnalisation provenant du serveur local 20, en local via le navigateur 40 du terminal utilisateur 30 par l'intermédiaire duquel l'application est accédée .
Les avantages découlant de ce mode de mixage via le navigateur sont que les programmes et données de personnalisation, sont toujours accessibles depuis le navigateur de l'utilisateur et n'ont donc pas besoin d'être accessibles à distance par le serveur de 1 ' application.
Par ailleurs, en déchargeant complètement le serveur Web distant de la fonction de personnalisation de l'application en réalisant en local les opérations de mixage via le navigateur de chaque utilisateur, on allège avantageusement la charge de travail du serveur distant fournissant l'application. Plus précisément, le mode de mixage via le navigateur du terminal hôte s'appuie sur les technologies du Web qui permettent de construire des applications Web plus riches, plus réactives et plus dynamiques. Ces applications évoluées permettent à l'usager de disposer d'une application Web qui ne se présente plus comme une succession de pages HTML (par exemples, consécutives à des « clicks » sur des liens) mais comme de véritables applications de bureau présentant une interface (ou une « page » principale, voire unique) qui se modifie au fur et à mesure des actions de l'usager. En dehors des requêtes au serveur
Web distant aboutissant à une nouvelle page HTML, dans le contexte des applications Web évoluées, les actions de l'utilisateur auront pour conséquences possibles : -de faire exécuter en local (c'est-à-dire dans le navigateur) un programme inclus dans la page principale de l'application qui peut lui-même mettre à jour des éléments de cette page sans nécessiter qu'une nouvelle page complète soit fournie par le serveur et rechargée par le navigateur ; -de requérir, de façon possiblement asynchrone (c'est-à-dire en arrière plan et sans bloquer la suite des opérations de l'utilisateur), auprès du serveur distant de l'application des données (et non pas une nouvelle page complète) qui pourront être exploitées par un programme JavaScript de la page pour mettre à jour à nouveau des éléments de cette page.
L'ensemble des technologies utilisé pour réaliser ces applications Web plus évoluées et qui permettent notamment de réaliser les opérations décrites ci- dessous est souvent regroupé sous la dénomination AJAX
Ces technologies sont principalement les suivantes :
-JavaScript, comme langage pour le programme inclus dans les pages HTML qui est exécuté par le navigateur;
-DOM pour « Document Object Model » et CSS pour
« Cascading Style Sheet », qui définissent respectivement les éléments structurants de la page
(les balises définissant la sémantique de portions de texte ainsi que ces portions elles-mêmes) et les styles par lesquels les éléments de la page sont mis en forme
(les règles de présentations) . DOM et CSS sont tous deux manipulables par les programmes écrits en
JavaScript ; -XMLHttpRequest, qui est une interface de programmation (ou API) disponible en JavaScript permettant d'exécuter des requêtes HTTP vers un serveur Web de manière synchrone ou asynchrone et ceci en arrière-plan, c'est-à-dire sans que le navigateur charge les résultats à cette requête comme une nouvelle page HTML à afficher. Les résultats de cette requête, souvent mais pas nécessairement exprimés en XML, sont ensuite manipulables par le programme JavaScript ;
-GreaseMonkey UserScript, qui sont des programmes en JavaScript étendu installés dans les navigateurs Web supportant l'extension GreaseMonkey (tels que Mozilla ou Firefox par exemple) , ces programmes se déclenchant lors du chargement de pages HTML prédéfinies et réalisent des modifications sur le contenu ou la présentation de cette page par le navigateur. Ces différents procédés de mises en œuvre sont appelés « patrons de conception » et sont pour la plupart décrits sur le site « AJAX Patterns ».
Le mode de mixage de l'application Web avec les programmes et données de personnalisation dans le navigateur de l'utilisateur s'appuie donc d'une part, sur l'utilisation d'un serveur Web propre à chaque utilisateur, embarqué dans un appareil numérique portatif tel qu'une carte à puce et hébergeant les programmes et données de personnalisation de l'utilisateur et, d'autre part, sur les technologies et patrons précédemment décrits pour exécuter les programmes de personnalisation et répercuter leurs résultats ainsi que les données de personnalisation sur les pages de l'application affichées par le navigateur. Ce mixage permet de réaliser de manière découplée des applications Web personnalisées, que ces applications Web soient évoluées ou non.
Le découplage obtenu permet donc, avec le bénéfice des avantages précédemment évoqués, de mixer ex-post dans le navigateur, l'application Web générique fournie par le serveur d'application distant avec les spécificités de la personnalisation propre à l'utilisateur fournies par le serveur local. Par mixage ex-post, on entend que le mixage est réalisé après que les données génériques relatives à l'application soient fournies au navigateur par le serveur distant . Ce type de mixage ex-post est ainsi a mettre en opposition avec le mixage ex-ante, c'est-à-dire réalisé avant que l'application soit fournie au navigateur, découlant du mode de réalisation précédemment décrit où le mixage est réalisé via le serveur Web distant de l'application générique .
Différentes réalisations du mixage dans le navigateur sont possibles selon les technologies AJAX mises en œuvre. Il est important de noter que ces technologies peuvent être combinées de différentes manières, selon les types d'applications, les résultats voulus ou les caractéristiques et performances souhaitées. Dans le contexte de la personnalisation d'applications Web via un mixage dans le navigateur et l'utilisation d'un appareil portatif intégrant un serveur Web hébergeant les programmes et données de personnalisation, trois exemples de réalisation, nullement limitatifs, sont fournis ci-après.
Le premier exemple concerne la mise en œuvre de la personnalisation de l'application via des UserScripts fournis par l'appareil portatif, par exemple une carte à puce, et via des requêtes à la carte émise par le navigateur.
Dans cet exemple de réalisation, les programmes et données de personnalisation sont donc des UserScripts stockés au niveau de la carte de l'utilisateur et sont accessibles via le server Web intégrés à la carte. Selon l'exemple, via une modification de l'extension GreaseMonkey, les UserScripts de la carte peuvent être installés et enregistrés dans le navigateur de l'utilisateur. Par exemple une opération RegisterPersonalUserScript est ajoutée à GreaseMonkey. L'utilisateur déclenche cette opération, celle-ci se connecte au serveur Web de la carte de l'utilisateur, elle-même connectée au terminal hôte. Pour renforcer la sécurité, la connexion au serveur local de la carte peut être effectuée avec des données d' authentification de l'utilisateur fournies par ce dernier, de sorte à n'autoriser la connexion au serveur que si l ' authentification a réussi. L'opération installe alors les UserScripts dans le navigateur. Les UsersScripts fournis par la carte sont accompagnés des schémas d'adresses de pages Web sur lesquels ils s'appliquent et enregistrés avec ceux-ci auprès de GreasMonkey.
Dorénavant, lorsque l'utilisateur accède à une page Web dont l'adresse correspond à un schéma d'adresse enregistré, le UserScript correspondant est mixé à l'application dans le navigateur en étant exécuté et réalisant ainsi la personnalisation de la page de l'application selon les opérations qui sont codées en son sein. Ce UserScript peut de plus envoyer des requêtes au serveur Web de la carte (par exemple, via XMLHttpRequest) , pour dynamiquement récupérer des données de personnalisation propre à l'utilisateur, qui sont utilisées pour réaliser la personnalisation de la page. L'accès à ces données peut également être sécurisé par une authentification de l'utilisateur ou par une diversification des clés d'accès aux données propre à la session en cours. Ces données peuvent être formatées en XML ou tout autre format que le code du UserScript s'attend à traiter. Le UserScript peut non seulement retrouver des données à partir de la carte de l'utilisateur mais peut aussi retrouver des données à partir d'autres serveurs Web sur le réseau. Ce UserScript peut aussi télécharger depuis la carte de l'utilisateur des programmes JavaScript via le patron de conception « On-demand JavaScript » .
Un deuxième exemple de réalisation est fourni concernant la personnalisation via des programmes JavaScript fournis par la carte et/ou via des requêtes à la carte.
Dans cet exemple de réalisation, la page HTML de l'application fournie par le serveur Web distant, contient des demandes de chargement de programmes JavaScript à la carte. Une telle demande est écrite dans la page de l'application par une directive standard du langage HTML. Par exemple, la page de l'application « appli_l » contient la directive ci- dessous donnée à titre d'exemple, qui va demander le chargement auprès du serveur Web local de la carte du script perso. j s, ce script contenant par exemple le programme de personnalisation sous la forme d'une unique fonction appelée personnalize () . Une multitude de fonctions peuvent néanmoins être contenu dans le script de personnalisation et le programme de personnalisation lui-même peut être fourni sous la forme de plusieurs scripts contenant chacun des fonctions .
<head>
<script type = " text/javascript " src "http : //card/appli_l/perso . j s" ></script>
</head>
Lorsque la page de l'application est chargée par le navigateur de l'utilisateur à partir du serveur distant, elle est interprétée par le navigateur qui exécute les demandes de chargement de programmes JavaScript rencontrées, à partir du serveur local sur la carte. Ainsi les programmes de personnalisation stockés dans la carte sous forme de programmes JavaScript sont-ils mixés au code de l'application dans le navigateur. Ces programmes JavaScript sont par la suite exécutés par exemple en incluant la directive suivante dans la page de l'application. A noter que les fonctions JavaScript fournies comme programmes de personnalisation par le serveur local intégré à la carte peuvent être exécutés par tout autre moyen permettant d'exécuter des programmes JavaScript au sein d'une page HTML, tel 'qu'à la réaction d'un événement (un click de l'utilisateur, la souris de l'utilisateur passant au dessus d'un élément de la page HTML, etc.) .
<body ... onload≈"personalize () " ... > A noter que les programmes JavaScript ci -dessus peuvent, comme dans le cas des UserScripts décrits précédemment, envoyer des requêtes au serveur Web de la carte pour dynamiquement récupérer des données de personnalisation propre à l'utilisateur, qui sont utilisées pour réaliser la personnalisation de la page. Toutes les opérations impliquant la carte de l'utilisateur (téléchargement des programmes de personnalisation JavaScript, requêtes aux données de personnalisation) peuvent être sécurisées par une authentification de l'utilisateur.
Une façon plus limitée de réaliser la personnalisation dans le navigateur consiste simplement à inclure dans les programmes JavaScript fournis par l'application elle-même des requêtes (par exemple via XMLHttpRequest) au serveur Web de la carte pour dynamiquement récupérer des données de personnalisation propre à l'utilisateur, qui sont utilisées pour réaliser la personnalisation de la page.
Dans l'exemple de réalisation ici décrit, il y a néanmoins une difficulté à lever concernant la politique de sécurité inter-domaines des navigateurs
(« cross-domain security policy ») . Il convient de noter que les UserScripts utilisés dans l'exemple de réalisation précédent ne sont pas soumis a cette politique de sécurité inter-domaines. Cette politique établit que les programmes JavaScript d'une page HTML ne peuvent provenir que du même serveur que celui qui a servi la page elle-même. De même, des requêtes
XMLHttpRequest ne peuvent être qu'à destination du serveur qui a servi la page. Le mode de réalisation tel que décrit ici pour le mixage des applications et de la personnalisation doit donc passer outre ces problêmes pour pouvoir être implémenté. Différentes solutions (combinables) sont envisageables et sont énumérées ci- dessous .
Ainsi, certains navigateurs, comme Internet Explorer, autorisent de configurer cette politique par l'utilisateur. La configuration peut être basée sur l'adresse du site serveur distant, sur une demande explicite chaque fois que ce cas de figure se présente (avec possibilité d'autoriser jusqu'à nouvel ordre), ou sur la présentation de certificats. Par exemple, les pages du domaine correspondant à l'adresse du site serveur distant fournissant l'application peuvent être autorisées à charger des programmes JavaScript de la carte de l'utilisateur et à envoyer des requêtes XMLHttpRequest à la carte de l'utilisateur.
Par ailleurs, une évolution des navigateurs pourraient autoriser la carte elle-même à fournir ou non ces programmes JavaScript ou à répondre aux requêtes XMLHttpRequest en fonction de l'origine de la page, ses certificats, voire même en fonction d'une procédure d' authentification entre la carte et le serveur distant (via le navigateur ou directement entre la carte et le serveur distant via Internet) , pour établir ou non la confiance.
La politique de sécurité inter-domaines n'étant pas aujourd'hui standardisée, toutes ces solutions sont envisageables, chaque navigateur pouvant choisir d'implanter la politique qu'il souhaite. De plus, la carte de l'utilisateur pourrait être considérée comme un domaine spécifique par le navigateur, qui, vis-à-vis de celle-ci, n'aurait pas une telle politique prohibitive. Enfin, des navigateurs « sur mesure » fournis par exemple par un opérateur de téléphonie mobile dans ses téléphones, pourraient être conçus spécifiquement pour autoriser le mixage entre des applications provenant du site de l'opérateur (et ses affiliés) et des programmes de personnalisation provenant de la carte SIM de l'utilisateur (qui par ailleurs est elle aussi fournie par l'opérateur). Enfin, une autre solution à ce problème est de faire servir à la fois l'application Web et la personnalisation par le serveur local intégré à la carte de l'utilisateur, comme il va être décrit ci- après .
Ce dernier exemple de réalisation est équivalent au précédent à la différence que l'application Web est cette fois-ci servie par la carte elle-même plutôt que par un serveur distant . Toutes les autres caractéristiques de l'exemple de réalisation précédent sont inchangées. L'intérêt de cette approche est de rendre ainsi l'application Web toujours disponible, même lorsque le navigateur de l'utilisateur n'est pas connecté à Internet. L'autre intérêt c'est qu'il n'y a plus de problème de politique de sécurité interdomaines puisque toutes les parties de l'application, y compris sa personnalisation, sont fournies par le même serveur, à savoir la carte. On conserve bien le découplage entre l'application et sa personnalisation, puisque ce sont toujours des programmes et données disjoints qui sont mixés dans le navigateur du terminal hôte, déchargeant ainsi le serveur d'application, c'est-à-dire la carte dans cet exemple de réalisation, de ce travail, et permettant toujours de faire évoluer indépendamment la personnalisation de l'application.
Finalement, dans ce dernier exemple de réalisation, on pourrait envisager que toute l'application ne soit pas servie par le serveur local de la carte de l'utilisateur, mais seulement une partie minimale de celle-ci lui permettant de travailler hors connexion (sans toutes les fonctionnalités) . Lorsque la connexion est établie, des parties additionnelles de l'application (enrichissant celle-ci) sont téléchargées depuis un serveur distant et mixée dans le navigateur de la même manière que dans l'exemple précédent où étaient mixées l'application et la personnalisation
(avec les mêmes problèmes de sécurité inter-domaines et des solutions similaires) .

Claims

REVENDICATIONS
1. Procédé de personnalisation d'une application Web, prévue pour être exécutée sur un terminal (30) d'un utilisateur par l'intermédiaire d'un navigateur
(40) équipant le terminal, sur requête envoyée via un réseau de télécommunication (60) depuis le navigateur à un serveur Web (10) distant hébergeant l'application, caractérisé en ce qu'il comprend :
-l'hébergement d'au moins un programme de personnalisation et/ou de données de personnalisation par un serveur (20) local propre à l'utilisateur associé au terminal et
-la mise en œuvre de la personnalisation de l'application par mixage du programme de personnalisation et/ou des données de personnalisation fournis par le serveur local (20) avec des données relatives à l'application correspondant au traitement de la requête fournies par le serveur distant (10) .
2. Procédé selon la revendication 1, caractérisé en ce que le serveur (20) local propre à l'utilisateur est réalisé sous forme d'un serveur Web embarqué dans un appareil numérique portatif (50) connecté au terminal de l'utilisateur.
3. Procédé selon la revendication 1, caractérisé en ce que le serveur (20) local propre à l'utilisateur est installé sur le terminal de l'utilisateur.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de mixage des données relatives à l'application Web avec le programme de personnalisation et/ou les données de personnalisation est effectuée dans le navigateur (40) du terminal de l'utilisateur par l'intermédiaire duquel s'exécute l'application.
5. Procédé selon la revendication 4, caractérisé en ce que l'étape de mixage comprend :
-la récupération préalable par le navigateur (40) des données relatives à l'application correspondant au traitement de la requête envoyée au serveur distant (10),
-l'exécution par le navigateur (40) d'opérations de personnalisation correspondant au programme de personnalisation et/ou aux données de personnalisation accèdes sur requête auprès du serveur local (10) propre à l'utilisateur et
-l'interprétation par le navigateur des résultats des opérations de personnalisation pour leur intégration aux données relatives à l'application.
6. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de mixage des données relatives à l'application Web avec le programme de personnalisation et les données de personnalisation est effectué dans le serveur distant (10) .
7. Procédé selon la revendication 6, caractérisé en ce que l'étape de mixage comprend :
-la fourniture par le serveur distant (10) au serveur local (20) des données relatives à l'application correspondant au traitement de la requête envoyée par le navigateur au serveur distant (10),
-l'exécution par le serveur local (20) d'opérations de personnalisation sur requête du serveur distant (10) et -l'interprétation par serveur (10) des résultats des opérations de personnalisation pour leur intégration aux données relatives à l'application à fournir au navigateur du terminal de l'utilisateur.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'accès au(x) programme et/ou données de personnalisation sur le serveur local (20) est sécurisé .
9. Procédé selon la revendication 8, caractérisé en ce que la sécurisation de l'accès au serveur local comprend une authentification de l'utilisateur.
10. Système de personnalisation d'une application Web, comprenant un terminal (30) d'un utilisateur doté d'un navigateur (40) comprenant des moyens d'envoi d'une requête selon un protocole de transfert de données à un serveur distant (10) hébergeant l'application et des moyens pour recevoir et exécuter sur le terminal de l'utilisateur le résultat du traitement de la requête par le serveur distant, ledit système étant caractérisé en ce qu' il comprend un serveur local propre à l'utilisateur associé au terminal, hébergeant au moins un programme de personnalisation de l'application et/ou des données de personnalisation de l'application, et des moyens de mixage de l'application Web fourni par le serveur distant avec le programme de personnalisation et/ou les données de personnalisation hébergés sur le serveur local (20) propre à l'utilisateur.
11. Système selon la revendication 10, caractérisé en ce que les moyens de mixage sont intégrés dans le navigateur (40) du terminal.
12. Système selon la revendication 10, caractérisé en ce que les moyens de mixage sont intégrés dans le serveur distant (10) .
13. Système selon l'une quelconque des revendications 10 à 12, caractérisé en ce que le serveur local (20) comprend un serveur Web embarqué sur un appareil numérique portatif (50) connecté au terminal de l'utilisateur.
14. Système selon la revendication 13, caractérisé en ce que l'appareil numérique portatif (50) comprend des moyens de sécurisation de l'accès au(x) programme et/ou données hébergées par le serveur embarqué.
15. Système selon la revendication 14, caractérisé en ce que l'appareil numérique portatif est une carte à puce .
16. Appareil numérique portatif (50) comprenant un serveur (20) Web intégré prévu pour communiquer avec un client selon un protocole de transfert de données, caractérisé en ce que le serveur intégré héberge au moins un programme et/ou des données de personnalisation d'une application hébergée par un serveur (10) d'applications distant et comprend des moyens pour fournir un accès au (x) programme et/ou données de personnalisation de l'application sur requête du client.
17. Appareil selon la revendication 16, caractérisé en ce que le serveur (20) intégré communique avec un navigateur (40) d'un terminal (20) d'un utilisateur agissant en tant que client, par l'intermédiaire duquel l'application s'exécute sur le terminal de l'utilisateur.
18. Appareil selon les revendications 16 ou 17, caractérisé en ce qu'il comprend des moyens pour sécuriser l'accès au (x) programme et/ou données de personnalisation de l'application.
19. Appareil selon l'une quelconque des revendications 16 à 18, caractérisé en ce qu'il s'agit d'une carte à puce.
PCT/EP2006/069966 2005-12-29 2006-12-20 Systeme et procede pour le deploiement d'applications web personnalisees WO2007074119A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/438,693 US20100070566A1 (en) 2005-12-29 2006-12-20 System and Method for Deploying Customised Web Applications
EP06830739A EP1969461A1 (fr) 2005-12-29 2006-12-20 Systeme et procede pour le deploiement d'applications web personnalisees

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0513467 2005-12-29
FR0513467 2005-12-29

Publications (1)

Publication Number Publication Date
WO2007074119A1 true WO2007074119A1 (fr) 2007-07-05

Family

ID=36599088

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/069966 WO2007074119A1 (fr) 2005-12-29 2006-12-20 Systeme et procede pour le deploiement d'applications web personnalisees

Country Status (4)

Country Link
US (1) US20100070566A1 (fr)
EP (1) EP1969461A1 (fr)
KR (1) KR100966665B1 (fr)
WO (1) WO2007074119A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010041901A2 (fr) * 2008-10-10 2010-04-15 에스케이 텔레콤주식회사 Système et procédé pour installer un applet pour carte intelligente
CN103139644A (zh) * 2013-01-31 2013-06-05 南通同洲电子有限责任公司 一种序列号匹配的方法和数字电视终端

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8914774B1 (en) 2007-11-15 2014-12-16 Appcelerator, Inc. System and method for tagging code to determine where the code runs
US8954989B1 (en) 2007-11-19 2015-02-10 Appcelerator, Inc. Flexible, event-driven JavaScript server architecture
US8260845B1 (en) 2007-11-21 2012-09-04 Appcelerator, Inc. System and method for auto-generating JavaScript proxies and meta-proxies
US8719451B1 (en) 2007-11-23 2014-05-06 Appcelerator, Inc. System and method for on-the-fly, post-processing document object model manipulation
US8566807B1 (en) 2007-11-23 2013-10-22 Appcelerator, Inc. System and method for accessibility of document object model and JavaScript by other platforms
US8806431B1 (en) 2007-12-03 2014-08-12 Appecelerator, Inc. Aspect oriented programming
US8756579B1 (en) 2007-12-03 2014-06-17 Appcelerator, Inc. Client-side and server-side unified validation
US8819539B1 (en) 2007-12-03 2014-08-26 Appcelerator, Inc. On-the-fly rewriting of uniform resource locators in a web-page
US8527860B1 (en) * 2007-12-04 2013-09-03 Appcelerator, Inc. System and method for exposing the dynamic web server-side
US8938491B1 (en) 2007-12-04 2015-01-20 Appcelerator, Inc. System and method for secure binding of client calls and server functions
US8285813B1 (en) 2007-12-05 2012-10-09 Appcelerator, Inc. System and method for emulating different user agents on a server
US8639743B1 (en) 2007-12-05 2014-01-28 Appcelerator, Inc. System and method for on-the-fly rewriting of JavaScript
US8335982B1 (en) 2007-12-05 2012-12-18 Appcelerator, Inc. System and method for binding a document object model through JavaScript callbacks
JP5236352B2 (ja) * 2008-05-15 2013-07-17 株式会社日立製作所 アプリケーション配信制御システム、アプリケーション配信制御方法、情報処理装置、およびクライアント端末
US8291079B1 (en) 2008-06-04 2012-10-16 Appcelerator, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
US8880678B1 (en) 2008-06-05 2014-11-04 Appcelerator, Inc. System and method for managing and monitoring a web application using multiple cloud providers
US7596620B1 (en) 2008-11-04 2009-09-29 Aptana, Inc. System and method for developing, deploying, managing and monitoring a web application in a single environment
AU2010201495B2 (en) 2009-04-16 2012-04-12 Accenture Global Services Limited Touchpoint customization system
KR101166797B1 (ko) * 2009-09-22 2012-07-26 에스케이플래닛 주식회사 스마트카드 기반 브라우징 시스템 및 그 방법, 그리고 이에 적용되는 스마트카드
US8413052B2 (en) 2010-02-17 2013-04-02 Yahoo! Inc. Bidded marketplace for applications
US8537990B2 (en) * 2010-11-19 2013-09-17 Frederic Rudman Communications device and method and method of use
FI20106336A0 (fi) 2010-12-17 2010-12-17 Pocketsoft Oy Räätälöidyn sovelluksen tuottaminen käyttäjän päätelaitteelle
US9026903B1 (en) 2011-01-11 2015-05-05 Google Inc. Abstract syntax tree interpreter for generating a valid HTML document
US9021348B1 (en) 2011-01-11 2015-04-28 Google Inc. Composition of templates using transclusion that guarantee a valid HTML document
US8745027B1 (en) 2011-04-11 2014-06-03 Google Inc. Jslayout cascading style sheets optimization
US9501465B2 (en) 2011-09-26 2016-11-22 Google Inc. Use of templates as message pruning schemas
US20140237589A1 (en) * 2011-09-29 2014-08-21 Bradley Neal Suggs Personalization Data of an Active Application
US20150347374A1 (en) * 2012-12-21 2015-12-03 Intellipocket Oy Generating a customized application
US10255063B2 (en) * 2013-03-15 2019-04-09 Microsoft Technology Licensing, Llc Providing source control of custom code for a user without providing source control of host code for the user
RU2013158632A (ru) * 2013-12-30 2015-07-10 Общество С Ограниченной Ответственностью "Яндекс" Способ предоставления данных об устройстве (варианты), способ установления сеанса связи между устройством и веб-сервером и сервер для предоставления данных
US9823826B2 (en) 2014-10-16 2017-11-21 International Business Machines Corporation User interface module sharing
US10817272B2 (en) * 2016-12-12 2020-10-27 Sap Se Generation and usage of language-converted script

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032763A1 (en) * 1998-12-14 2002-03-14 Cox David E. Methods, systems and computer program products for distribution of application programs to a target station on a network
WO2003013100A2 (fr) * 2001-08-02 2003-02-13 Gemplus Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur carte a puce
US20040095382A1 (en) * 2002-11-19 2004-05-20 Fisher Ken Scott Portable memory drive retaining personalized interface on multiple host computers
US20040144838A1 (en) * 2001-04-10 2004-07-29 Laurent Lagosanto Method and system for managing data designed to be stored in a programmable smart card
US20050050159A1 (en) * 2003-09-03 2005-03-03 Zeev Suraski Remote debugging of web applications
US20050080882A1 (en) * 1998-09-11 2005-04-14 Philyaw Jeffry Jovan Digital ID for selecting web browser and use preferences of a user during use of a web application

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510486B1 (en) * 1996-03-25 2003-01-21 Cypress Semiconductor Corp. Clocking scheme for independently reading and writing multiple width words from a memory array
US6196459B1 (en) * 1998-05-11 2001-03-06 Ubiq Incorporated Smart card personalization in a multistation environment
FR2782435B1 (fr) * 1998-08-13 2000-09-15 Bull Cp8 Procede de communication entre une station d'utilisateur et un reseau, notamment de type internet, et architecture de mise en oeuvre
WO2005064889A1 (fr) * 2003-12-23 2005-07-14 Axalto Sa Carte a puce comportant un reseau local virtuel
US20050259673A1 (en) * 2004-05-18 2005-11-24 Axalto Inc. Method and system for end-to-end communication between a universal integrated circuit card and a remote entity over an IP-based wireless wide area network and the internet
US20050289178A1 (en) * 2004-06-29 2005-12-29 Angus Ian G Combining data and presentation from multiple sources into a single web page
US7624452B2 (en) * 2004-10-20 2009-11-24 Digi International Automatic device configuration using removable storage
DE112005003597T8 (de) * 2005-06-03 2008-07-24 Elektrobit Wireless Communications Oy Bedienung eines Mobilgeräts
US20060282678A1 (en) * 2005-06-09 2006-12-14 Axalto Sa System and method for using a secure storage device to provide login credentials to a remote service over a network
US20060294023A1 (en) * 2005-06-25 2006-12-28 Lu Hongqian K System and method for secure online transactions using portable secure network devices
WO2007007017A1 (fr) * 2005-07-08 2007-01-18 Corizon Limited Procede et dispositif de modification de l'interface-utilisateur
US7962896B2 (en) * 2005-10-31 2011-06-14 Eazypaper Inc. Method and system for automatically configuring software

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080882A1 (en) * 1998-09-11 2005-04-14 Philyaw Jeffry Jovan Digital ID for selecting web browser and use preferences of a user during use of a web application
US20020032763A1 (en) * 1998-12-14 2002-03-14 Cox David E. Methods, systems and computer program products for distribution of application programs to a target station on a network
US6510466B1 (en) * 1998-12-14 2003-01-21 International Business Machines Corporation Methods, systems and computer program products for centralized management of application programs on a network
US20040144838A1 (en) * 2001-04-10 2004-07-29 Laurent Lagosanto Method and system for managing data designed to be stored in a programmable smart card
WO2003013100A2 (fr) * 2001-08-02 2003-02-13 Gemplus Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur carte a puce
US20040095382A1 (en) * 2002-11-19 2004-05-20 Fisher Ken Scott Portable memory drive retaining personalized interface on multiple host computers
US20050050159A1 (en) * 2003-09-03 2005-03-03 Zeev Suraski Remote debugging of web applications

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
R. MARVIE, M-C. PELLEGRINI, O. POTONNIEE: "Smart Cards: A system support for service accessibility from heterogeneous devices", RESEARCH LAB, GEMPLUS LABS, 2000, France, XP002388371, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/cache/papers/cs/14447/http:zSzzSzwww.lifl.frzSz~marviezSzResearchzSzdocszSzsigops_ew2000.pdf/marvie00smart.pdf> [retrieved on 20060630] *
See also references of EP1969461A1 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010041901A2 (fr) * 2008-10-10 2010-04-15 에스케이 텔레콤주식회사 Système et procédé pour installer un applet pour carte intelligente
WO2010041901A3 (fr) * 2008-10-10 2010-07-29 에스케이 텔레콤주식회사 Système et procédé pour installer un applet pour carte intelligente
CN101965581A (zh) * 2008-10-10 2011-02-02 Sk电信有限公司 安装智能卡小应用程序的系统及方法
US8745187B2 (en) 2008-10-10 2014-06-03 Sk Planet Co., Ltd. System and method for installing smart card applet
CN103139644A (zh) * 2013-01-31 2013-06-05 南通同洲电子有限责任公司 一种序列号匹配的方法和数字电视终端
CN103139644B (zh) * 2013-01-31 2016-01-20 南通同洲电子有限责任公司 一种序列号匹配的方法和数字电视终端

Also Published As

Publication number Publication date
KR100966665B1 (ko) 2010-06-29
EP1969461A1 (fr) 2008-09-17
US20100070566A1 (en) 2010-03-18
KR20080087876A (ko) 2008-10-01

Similar Documents

Publication Publication Date Title
WO2007074119A1 (fr) Systeme et procede pour le deploiement d&#39;applications web personnalisees
EP1193947B1 (fr) Système de communication basé sur le langage WSDL
EP1590931B1 (fr) Procede de presentation d&#39;etat d&#39;un utilisateur utilisant plusieurs equipements de communication
Rellermeyer et al. AlfredO: an architecture for flexible interaction with electronic devices
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d&#39;un service électronique
EP2643961B1 (fr) Communication entre deux applications web
EP1395962B1 (fr) Deploiement d&#39;application depuis une carte a puce
CA2786095A1 (fr) Systeme et methode permettant a un utilisateur de faire une mise a jour dynamique d&#39;une application mobile a partir d&#39;une application generique ou premiere d&#39;une classe d&#39;applications pour creer une application specifique ou secondaire avec ladite classe d&#39;applications
WO2015121418A2 (fr) Procédé de déploiement d&#39;un ensemble d&#39;application(s) logicielle(s)
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
EP1444848A2 (fr) Reconfiguration de composants programmables dans un appareil electronique
WO2001024475A2 (fr) Procede et architecture de pilotage a distance d&#39;une station d&#39;utilisateur via un reseau de type internet
EP2102768A1 (fr) Procédé et dispositif de gestion de données dans un environnement distribué
CN106209992A (zh) 一种路由器支持rss订阅任务下载的方法及路由器
WO2013017442A1 (fr) Procédé de gestion de l&#39;accès à un ensemble de ressources délivrées par un dispositif électronique
EP2674860A1 (fr) Procédé de traitement de données par un module de navigation
WO2007141215A1 (fr) Procede de commande d &#39; un module electronique de radiocommunication
EP2223215A1 (fr) Procédé de contrôle d&#39;au moins un processus applicatif et produit programme d&#39;ordinateur correspondant
FR3053199A1 (fr) Serveur de statistiques pour optimisation de requetes client-serveur
FR2883685A1 (fr) Procede et systeme de partage d&#39;attributs personnels, module de partage/d&#39;insertion/de terminal, fournisseur d&#39;acces internet, serveur proxy, fournisseur de services et programme d&#39;ordinateur pour ce procede
WO2023118770A1 (fr) Système de distribution de contenu internet personnalisé
Mendes et al. A review of the widget landscape and incompatibilities between widget engines
EP1494419A1 (fr) Système de transmission de paramètres caractéristiques d&#39;une session de communication d&#39;un terminal vers un serveur distant
EP1818822A1 (fr) Procédé et serveur de distribution de composants logiciels, et procédé de mise à jour et terminal et produits programme d&#39;ordinateur correspondants
FR2947934A1 (fr) Procede de tracabilite et d&#39;imputabilite dynamiques des echanges dans un environnement ouvert de type internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006830739

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 1020087018596

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2006830739

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12438693

Country of ref document: US