EP1658561A1 - Procede et dispositif pour l interfacage graphique - Google Patents

Procede et dispositif pour l interfacage graphique

Info

Publication number
EP1658561A1
EP1658561A1 EP04741912A EP04741912A EP1658561A1 EP 1658561 A1 EP1658561 A1 EP 1658561A1 EP 04741912 A EP04741912 A EP 04741912A EP 04741912 A EP04741912 A EP 04741912A EP 1658561 A1 EP1658561 A1 EP 1658561A1
Authority
EP
European Patent Office
Prior art keywords
client station
data
display
model
response
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.)
Ceased
Application number
EP04741912A
Other languages
German (de)
English (en)
Inventor
Jean-François Cabinet Hautier BILLIARD
Bertrand Cabinet Hautier LAPORTE
Pascale Cabinet Hautier CARON
Jérome Cabinet Hautier PETIT
Richard Cabinet Hautier MOLENAAR
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.)
Amadeus SAS
Original Assignee
Amadeus SAS
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 Amadeus SAS filed Critical Amadeus SAS
Priority to EP04741912A priority Critical patent/EP1658561A1/fr
Publication of EP1658561A1 publication Critical patent/EP1658561A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking

Definitions

  • the present invention relates to a method and a device for graphical interfacing between a user and a computer system.
  • the client part of the user interface has significant structural limitations, linked to the HTML language.
  • the occupancy of the transmission network is high, which implies a high response time for customers with a low speed connection.
  • style sheets are stored locally to be reused, merged with dynamic files.
  • these style sheets are predefined and their characteristics are fixed definitively. They offer no flexibility of use. For example, if it is advisable to create a page with a style sheet differing, even in a minimal way, from the sheet present in the local cache, the local sheet is not usable and it is necessary to obtain a new complete style sheet from the server.
  • the present invention is part of this optimization and reduces on the one hand the computation time on the server and on the other hand the traffic on the network between the server and the client, which allows decrease overall response time by the application.
  • the device of the invention retains great flexibility because the server part continues to control the processing of the data to be displayed.
  • the device also makes it possible to modify and create the graphical visualization models to be displayed for the user as well as to provide instructions with regard to the display at the client station.
  • the invention has the advantage of providing the display means with information merged between two data sources. Indeed, on the one hand, the device of the invention generates static objects kept locally at the client station and allowing local availability of multiple graphic objects used for display.
  • the dynamic data corresponding to the client's request are generated after processing in the server part and transmitted to the client station.
  • a dynamic and static data is then merged to produce the visualization in particular in the form of pages in HTML format using a navigation application.
  • the system is easily customizable according to the local requirements of the client workstation (specific graphic objects, specific logical rules to apply, specific local data to be used ).
  • This potential personalization of the client workstation does not affect its original constituents and in particular the browser: it is indeed possible to generate a page in HTML format directly usable by the browser.
  • the present invention relates to a method for the graphical interface between a user and a computer system in which the following actions are carried out: entry of a request by the user at a client station, - Transmission of the request to a server party for processing the request and generation of a response, - Receipt of the response at the client station, Display of the response result for the user,
  • the client station receives a response comprising instruction data and data to be displayed; - At the client station, the instruction data is executed for the construction of a display model to be used; At the client station, said visualization model is created by association of locally available construction elements, - The data to be displayed is merged with the visualization model in order to display the result of the merger.
  • the construction elements include an interface for describing the objects of the visualization model, a presentation layer and logical rules to be applied locally to the visualization model;
  • the visualization model At the client station level, we associate the visualization model with a language resource among the locally available language resources;
  • display personalization filters can be associated with the display model to modify the visual rendering of the default display model;
  • the instruction data include the indication of the type and the characteristic elements of visualization model construction to be created;
  • - We display at the client workstation using a navigation application - We use data to display and construction elements of visualization models in XML format We translate the result of the merger in HTML format in order to display.
  • the response from the server side includes instruction data and data to display;
  • the invention also relates to a graphical interface device between a user and a computer system comprising: • means for inputting a request by the user at a client station, • means communication between the client station and a server part, • Processing means in the server part for generating a response, • Means for displaying the result of the response at the client station.
  • the construction elements include an interface for describing the objects of the visualization model, a presentation layer and logical rules to be applied locally to the visualization model; - It includes a rules engine capable of applying the logical rules of the visualization model; - H includes a navigation application for displaying the result of the merger at the client station.
  • FIG. 1 is a schematic representation of the processing currently carried out between a client and a server when a request is made by a client using an architecture based on the Internet system and the use of a browser of the Internet Explorer type. ®.
  • Figure 2 schematically shows the processing of a request by a client with implementation of the invention.
  • Figure 3 illustrates blocks of constituent elements of the device of the invention and their communication.
  • Figure 4 shows the step of merging data performed.
  • Figure 5 is an example of a component integrated in the display means of the client station.
  • FIG. 1 shows a standard scenario when using the global extension network usually called “World Wide Web”.
  • user requests at the client side correspond to a page request in HTML (Hyper Text Mark-up Language) format with the following instructions: http get or http post.
  • HTML Hyper Text Mark-up Language
  • a first limitation of this mechanism is that the user must specify the window which will display the response before sending the request.
  • the server cannot therefore decide to display the response in a dialog window or on the main window since this has already been defined at the client level.
  • Another drawback that can be raised is that only one window can be refreshed at a time. For example, if the main window had been divided into two sub-windows, it is necessary for the user to send two successive requests to the server to obtain the successive refresh of the two sub-windows. In addition, display changes are only made by refreshing an entire part of the screen when it is possible that the customer's request only responds to a simple request to update certain data. Depending on the current device, it is however necessary to refresh the entire screen for any type of modification requested.
  • the marker 4 in FIG. 1 shows that the response in the form of a web page is addressed to the client. It should be noted that for professional applications the data must be encrypted which implies a processing time and an induced cost. all the more important as the volume of data to be encrypted is high.
  • the user can then have the display of the response as presented in point 5 in FIG. 1.
  • This display is produced by means of a navigation application such as that available under the Internet Explorer ® brand.
  • FIG. 2 presents an example of an operating scenario of a graphic interface device according to the invention.
  • a request in the form of a message containing the information entered by the user is generated in XML (Extensible Mark-up Language) format or under another structured format.
  • XML Extensible Mark-up Language
  • this "event" request is received and processed at the server part.
  • the first phase of processing consists of an analysis of the content of the request, which is done at the level of a user interface layer of the server which will be presented in more detail below. Then, we process the data of the "event" request at an application layer which will also be presented below.
  • the message is transmitted in the form of an XML document (Extensible Mark-up Language) possibly after compression and encryption towards the client workstation.
  • XML document Extensible Mark-up Language
  • This operation is represented in reference 4 by the term instruction which corresponds to the functionality described in the previous paragraph.
  • This instruction message is received at the client station and must be interpreted.
  • the dynamic data included in the response from the server is retrieved and can be merged with a visualization model which corresponds to the static objects required for display.
  • Each visualization model is also created, at the client station level, by association of construction elements. It is the instruction data which determine the construction elements to be associated.
  • the combination of the two types of data allows the creation of complete data to display, in particular in the form of a page in HTML format.
  • the functionality of known and standard navigation means such as the browser distributed under the brand Internet Explorer ®, can be used for viewing.
  • the instructions transmitted by the server correspond to controls (such as a button for displaying a drop-down list)
  • the events to be carried out can be managed by code in the Java Script language format associated with control considered.
  • the events to be operated include interactions between different controls (for example if the A field is filled in, the B field then becomes mandatory) one can operate in different ways.
  • This device comprises a server part implemented with known computer means comprising processing means in the form of a processor and storage means in the form of memory of the RAM (Random Access Memory) or ROM (Read Only Memory) type.
  • the server part is understood to mean a single remote computer server entity or several servers connected to each other by usual means of transmission.
  • the device also includes a part implemented locally at the client station which can, for example, be produced by a personal computer of the PC (Personal Computer) type, visible in FIG. 3.
  • PC Personal Computer
  • the server part and the client station are connected for the transmission of data by means of communication which can, for example, be carried out via a wide area network (R) (WAN: Wide Area Network). .
  • R wide area network
  • WAN Wide Area Network
  • FIG. 3 shows different components of the device of the invention and their relationship in order to implement the interfacing method described here.
  • the server part transmits a response to the request previously formulated by the user, the response comprising instruction data and data to be displayed.
  • the response is received at the level of an instruction manager capable of interpreting the instruction data contained in the response to determine the actions to be carried out.
  • the interpretation includes determining the construction elements to be used for the generation of the display model.
  • the results of the interpretation are transmitted to an association engine capable of recovering the static data constituting the construction elements characteristic of the previously determined display model.
  • an association engine capable of recovering the static data constituting the construction elements characteristic of the previously determined display model.
  • the visualization model combines a description interface describing the high-level components of the visualization model, a presentation layer bringing together the different elements and attributes linked to a graphic presentation and logical rules which correspond to the local logic which must be applied to the visualization model during its processing.
  • the presentation layer can depend on user profiles, but the description interface and the logical rules remain identical.
  • the building elements can therefore be completely independent data and be stored in separate files or in the same file as required.
  • language resource data is associated. These data are also chosen from various resources available locally in cache memory at the client station. It is thus easy to adapt the page to be created to a predetermined language.
  • the indication of the language resource to be used is also present in the instruction data received in the response.
  • filters complete the personalization made possible by the present invention. In fact, they allow the information available on the screen to be adapted to specific parameters for the customer. It is a particularly effective way to modify the visual components of the screen in a non-programmatic way, for example with regard to user controls (ex: deletion of certain screen controls, modification of the compulsory nature of certain fields of capture%)
  • Standard navigation applications in particular Internet Explorer®, use pages in HTML format.
  • a transformation to this HTML format is therefore carried out before the transmission to the navigation application by means of transformation means.
  • the device of the invention also includes a rules engine capable of exploiting the rules contained in a data store. In this way, one can manage simple interactions between the browser and the user. For example, you can locally determine the data to be provided in a drop-down menu according to the client's profile and according to the input previously made by the user. This avoids systematic recourse to a query from the server after entering the client.
  • FIG. 3 also shows a possibility of updating or adding data to the data store. Indeed, it can be useful to refresh or increase the data contained locally in the data store and used for the rules engine. To do this, a response is sent from the server part to the client station containing instruction data and data to be used, here for their storage and not for display.
  • the client station advantageously comprises a cache element constituting a means of data storage available locally and in which a plurality of data can be stored comprising the various construction elements. It is therefore static data which is generally used for HTML-type pages. Any type of memory can be used for such a cache memory and in particular a ROM (Read Only Memory) type memory.
  • ROM Read Only Memory
  • the static data is installed from the start at the client station and used when it is requested to be merged with data from the server.
  • the server does not have to transmit the various elements or objects used for display.
  • the present invention allows the creation of construction elements at the server side and their transmission only once to the client station for storage in the cache and subsequent reuse.
  • FIG. 4 shows the step of merging performed between the data from the server and the data from the local cache after their association.
  • the merger takes place in the part of the client station after reception of the dynamic data from the server in the instructions. of the server response.
  • the instruction manager upon receipt of data from the server, calls the elements of the corresponding visualization model present in the cache. They are combined and the merging is carried out for the production, for example, of a page to be transmitted to the display means.
  • data in XML format are used for the creation of the visualization model and for the data to be displayed.
  • a translation in HTML format can be carried out after the merger by transformation means so as to obtain a result in the form of an HTML page directly usable by a conventional navigation application.
  • the object of the present invention provides great flexibility in the development of graphical user interfaces while limiting the volumes of data transmitted across networks.
  • the client workstation remains a light and easily installed structure and the server part retains a key role in data processing and the management of display elements.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

La présente invention concerne un procédé et un dispositif pour l'interfaçage graphique entre un utilisateur et un système informatique. On effectue les actions suivantes : entrée d'une demande par l'utilisateur au niveau d'un poste client, transmission de la demande à une partie serveur, traitement de la demande et génération d'une réponse, transmission de la réponse au poste client, affichage du résultat de la réponse pour l'utilisateur. Selon l'invention : on génère une réponse comprenant des données d'instruction et des données à afficher ; au niveau du poste client, on interprète les données d'instruction déterminant un modèle de visualisation à exploiter ; au niveau du poste client, on crée ledit modèle de visualisation par association d'éléments de construction disponibles localement, on fusionne les données à afficher avec le modèle de visualisation en vue de l'affichage du résultat de la fusion. Application à la réalisation d'interface utilisateur graphique.

Description

Description Procédé et dispositif pour l'interfaçage graphique
[001] La présente invention concerne un procédé ainsi qu'un dispositif pour l' interfaçage graphique entre un utilisateur et un système informatique.
[002] Elle trouvera en particulier son application dans le domaine de la réalisation d'interface graphique pour utilisateur, notamment dans le domaine des systèmes de réservation par ordinateur.
[003] D'une façon générale, les interfaces utilisateurs ont connu une grande évolution depuis l'important succès des réseaux de large extension et en particulier de l'Internet.
[004] Les solutions d'interfaçage graphique dans le cadre d'Internet ont permis d'importantes économies en matière de développement.
[005] Cependant, pour des applications complexes, telles que des applications professionnelles de systèmes de réservation par ordinateur, les interfaces d'utilisateurs basées sur ces techniques nécessitent le transfert de grandes pages volumineuses dans un format de balisage du type HTML (pour Hyper Text Mark-up Language).
[006] Des inconvénients liés à ce type de transmission de pages intégrales formées uniquement dans la partie serveur et transmises au navigateur du poste client posent plusieurs problèmes. En particulier, la partie client de l'interface d'utilisation présente d'importantes limitations structurelles, liées au langage HTML. En outre, compte-tenu du volume des transferts à opérer entre le serveur et le poste client, l'occupation du réseau de transmission est forte, ce qui implique un temps de réponse élevé pour les clients disposants d'une connexion à faible débit.
[007] Ce type de construction de pages HTML ressort du document US-A-2002116455.
[008] Suivant des techniques un peu différentes, des feuilles de style (stylesheets) sont stockées localement pour être réutilisées, en fusion avec des dossiers dynamiques. Cependant, ces feuilles de style sont prédéfinies et leurs caractéristiques sont fixées définitivement. Elles n'offrent aucune souplesse d'utilisation. Par exemple, s'il convient de créer une page avec une feuille de style différant, même de façon minime, de la feuille présente dans le cache local, la feuille locale n'est pas exploitable et il faut obtenir une nouvelle feuille de style complète depuis le serveur.
[009] Il existe un besoin concernant des interfaces utilisateur disposant des atouts de richesse, de flexibilité et de performance des traitements opérés dans la partie serveur tout en assurant une réduction de l'occupation du réseau pour fournir l'affichage au client.
[010] La présente invention s'inscrit dans le cadre de cette optimisation et permet de réduire d'une part le temps de calcul sur le serveur et d'autre part le trafic sur le réseau entre le serveur et le client, ce qui permet de diminuer le temps de réponse global de l'application. En outre, le dispositif de l'invention conserve une grande flexibilité car la partie serveur continue de contrôler le traitement des données à afficher. Le dispositif permet également de modifier et de créer les modèles de visualisation graphique à afficher pour l'utilisateur ainsi que de fournir des instructions en ce qui concerne l'affichage au poste client.
[011] Plus précisément, l'invention a l'avantage de fournir aux moyens de visualisation des informations fusionnées entre deux sources de données. En effet, d'une part, le dispositif de l'invention génère des objets statiques conservés localement au niveau du poste client et permettant une disponibilité locale de multiples objets graphiques utilisés pour l'affichage.
[012] D'autre part, les données dynamiques correspondant à la demande du client sont générées après traitement dans la partie serveur et transmises au poste client. Une fusion des données dynamiques et statiques est ensuite opérée pour produire la visualisation en particulier sous forme de pages au format HTML en utilisant une application de navigation.
[013] En implémentant un équipement spécifique au niveau du poste client, on peut générer localement le modèle de visualisation à exploiter pour l'affichage. Cela est opéré par l'association de différents éléments de constructions du modèle qui seront détaillés plus loin dans la description.
[014] Il s'ensuit que les données de construction des modèles de visualisation ne transitent plus par le réseau. En outre, le système est aisément personnalisable selon les exigences locales du poste client (objets graphiques spécifiques, règles logiques particulières à appliquer, données locales particulières à employer...).
[015] Cette personnalisation potentielle du poste client n'affecte pas ses constituants d'origine et en particulier le navigateur : on peut en effet générer une page au format HTML directement exploitable par le navigateur.
[016] On notera également que, les modèles de visualisation étant créés à partir d'objets de faibles tailles, leur mise à jour ne nécessite que peu de ressources réseau.
[017] On réduit ainsi considérablement le volume des données à transmettre entre la partie serveur et le poste crient. C'est ainsi que l'on bénéficie de la richesse des standards de langage de balisage (tel HTML) tout en diminuant considérablement le temps de réponse et les besoins en réseau.
[018] D'autres buts et avantages apparaîtront au cours de la description qui suit d'un mode préféré de réalisation de l'invention qui n'est cependant pas limitatif.
[019] La présente invention concerne un procédé pour l'interface graphique entre un utilisateur et un système informatique dans lequel on effectue les actions suivantes : entrée d'une demande par l'utilisateur au niveau d'un poste client, - Transmission de la demande vers une partie serveur en vue du traitement de la demande et de la génération d'une réponse, - Réception de la réponse au niveau du poste client, Affichage du résultat de la réponse pour l' utilisateur,
[020] Selon l'invention : Le poste client reçoit une réponse comprenant des données d'instruction et des données à afficher ; - Au niveau du poste client, on exécute les données d'instruction pour la construction d'un modèle de visualisation à exploiter ; Au niveau du poste client, on crée ledit modèle de visualisation par association d'éléments de construction disponibles localement, - On fusionne les données à afficher avec le modèle de visualisation en vue de l'affichage du résultat de la fusion.
[021] Suivant des possibilités avantageuses mais non limitatives : - Les éléments de construction comprennent une interface de description des objets du modèle de visualisation, une couche de présentation et des règles logiques à appliquer localement au modèle de visualisation ; Au niveau du poste client, on associe au modèle de visualisation crée un ressource de langage parmi les ressources de langage disponibles localement ;
- Au niveau du poste client, on peut associer au modèle de visualisation des filtres de personnalisation d'affichage pour modifier le rendu visuel du modèle de visualisation par défaut; Les données d'instruction comportent l'indication du type et les éléments caractéristiques de construction de modèle de visualisation à créer ; - On met à jour les données disponibles localement au niveau du poste client par les étapes suivantes : • On génère, au niveau du serveur, un message de stockage comprenant des données d'instruction de stockage et les données à stocker, • On transmet le message de stockage au poste client, • Au niveau du poste client, on interprète les données d'instruction pour exécuter le stockage et on stocke les données à stocker dans une mémoire locale. - On effectue l'affichage au niveau du poste client par une application de navigation, - On utilise des données à afficher et des éléments de construction des modèles de visualisation au format XML On traduit le résultat de la fusion au format HTML en vue de l'affichage. La réponse de la partie serveur comprend des données d'instruction et des données à afficher ; [022] L'invention est aussi relative à un dispositif d'interfaçage graphique entre un utilisateur et un système informatique comprenant : • Des moyens d'entrée d'une demande par l'utilisateur au niveau d'un poste client, • Des moyens de communication entre le poste client et une partie serveur, • Des moyens de traitement dans la partie serveur pour la génération d'une réponse, • Des moyens d'affichage du résultat de la réponse au niveau du poste client. Il comporte au niveau du poste client un gestionnaire d'instructions apte à interpréter les données d'instruction pour la construction d'un modèle de visualisation à exploiter ; Il comporte un moteur d'association au niveau du poste client apte à créer ledit modèle de visualisation par association d'éléments de construction ; - Il comporte des moyens de stockage des éléments de constructions au niveau du poste client ; Il comporte au niveau du poste client des moyens pour fusionner le modèle de visualisation et les données à afficher, en vue de l'affichage du résultat de la fusion. [023] A titre préféré : - Les éléments de construction comprennent une interface de description des objets du modèle de visualisation, une couche de présentation et des règles logiques à appliquer localement au modèle de visualisation ; - Il comporte un moteur de règles apte à appliquer les règles logiques du modèle de visualisation ; - H comporte une application de navigation pour l'affichage du résultat de la fusion au niveau du poste client.
[024] Les dessins ci-joints sont donnés à titre d'exemples et ne sont pas limitatifs de l'invention. Us représentent seulement un mode de réalisation de l'invention et permettront de la comprendre aisément. [025] La figure 1 est une représentation schématique du traitement opéré actuellement entre un client et un serveur lorsqu'une requête est formulée par un client en utilisant une architecture basée sur le système Internet et l'usage d'un navigateur du type Internet Explorer ®. [026] La figure 2 présente schématiquement le traitement d'une demande par un client avec mise en œuvre de l'invention. [027] La figure 3 illustre des blocs d'éléments constitutifs du dispositif de l'invention et leur communication. [028] La figure 4 montre 'étape de fusion de données réalisées.
[029] La figure 5 est un exemple de composant intégré dans les moyens de visualisation du poste client.
[030] On a représenté en figure 1 un scénario standard lors de l'utilisation du réseau d'extension mondial usuellement dénommé « World Wide Web ». Dans ce cadre, les requêtes de l' utilisateur au niveau de la partie client correspondent à une demande de page au format HTML (Hyper Text Mark-up Language) avec les instructions suivantes : http get ou http post.
[031] Une première limitation de ce mécanisme est que l'utilisateur doit préciser la fenêtre qui va réaliser l'affichage de la réponse et ce avant d'envoyer la requête. Le serveur ne peut donc pas décider d'afficher la réponse dans une fenêtre de dialogue ou sur la fenêtre principale puisque cela a déjà été défini au niveau du client.
[032] Un autre inconvénient que l'on peut soulever est qu'une seule fenêtre peut être rafraîchie à la fois. Par exemple, si la fenêtre principale avait été divisée en deux sous- fenêtres, il est nécessaire à l'utilisateur d'adresser deux requêtes successives au serveur pour obtenir le rafraîchissement successif des deux sous fenêtres. Par ailleurs, les modifications d'affichage se font uniquement par rafraîchissement de l'intégralité d'une partie de l'écran alors qu'il est possible que la demande du client ne réponde qu'à une simple demande de mise à jour de certaines données. Suivant le dispositif actuel, il est cependant nécessaire de rafraîchir l'intégralité de l'écran pour n'importe quel type de modification demandée.
[033] Il n'y a pas de moyen efficace pour stocker des informations au niveau du poste client si ce n'est le recours à des « cookies » (témoins) qui sont cependant de petite taille et qui nécessite un transit par le réseau à chaque requête.
[034] Une fois que l'utilisateur a saisi sa requête celle-ci est transmise par le biais du réseau Internet avec le support de protocoles de communication du type http (Hyper Text Transfer Protocol). Cette étape est représentée au repère 1 à la figure 1. Le traitement de la requête est opéré au niveau du serveur et est présenté au repère 2. Une réponse est ensuite générée comme présentée au repère 3, ici sous forme de page au format html qui implique la combinaison dans une même réponse des éléments de données et des éléments de présentation de ce qui doit être affiché à l'utilisateur. A chaque fois que l'on souhaite accéder à une page, il faut ainsi télécharger depuis la partie serveur l'intégralité de la page HTML contenant les données à afficher (données variables et données « statiques » de formatage - ex : textes d'aide, couleurs, polices de caractères...). Ainsi le volume des pages transmises sur le réseau s'avère important.
[035] Le repère 4 de la figure 1 montre que la réponse sous forme de page Web est adressée au client. Il faut noter que pour des applications professionnelles les données doivent être encryptées ce qui implique un temps de traitement et un coût induit d'autant plus important que le volume des données à crypter est élevé.
[036] Au niveau du poste client, l'utilisateur peut ensuite disposer de l'affichage de la réponse comme présenté au point 5 en figure 1. Cet affichage est réalisé par le biais d'une application de navigation telle que celle disponible sous la marque Internet Explorer ®.
[037] Au niveau local, certaines actions peuvent alors avoir lieu pour éviter de recourir systématiquement au serveur. Ainsi certaines applications par exemple éditées en Java Script peuvent être implémentées au niveau du poste client pour produire certains outils. Un autre inconvénient des dispositifs actuels est donc qu'il nécessite de recourir à des outils additionnels à programmer au langage Java Script au niveau du poste client.
[038] La figure 2 présente au contraire un exemple de scénario de fonctionnement d'un dispositif d'interfaçage graphique selon l'invention.
[039] Comme indiqué précédemment, l' architecture actuelle utilisée dans le cadre du réseau Internet (World Wide Web) pose des problèmes dans la mesure où l'intégralité de pages au format HTML sont téléchargées vers le poste client.
[040] Comme visible en figure 2, tel n'est pas le cas de la présente invention.
[041] Plus particulièrement, lorsque l'utilisateur entre une requête à destination de la partie serveur, une demande sous forme d'un message contenant les informations saisies par l'utilisateur est générée au format XML (Extensible Mark-up Language) ou sous un autre format structuré. Dans la mesure où la demande du client ainsi générée reflète l'action de l'utilisateur, elle a été dénommée « événement » à la référence 1 de la figure 2.
[042] Après transmission, cette demande « événement » est reçue et traitée au niveau de la partie serveur. La première phase du traitement consiste en une analyse du contenu de la demande ce qui est fait au niveau d'une couche d'interface utilisateur du serveur qui sera présenté plus en détail ci-après. Ensuite, on procède au traitement des données de la demande « événement » au niveau d'une couche d'application qui sera également présentée plus loin.
[043] Ces phases sont présentées au repère 2 « traitement » de la figure 2. Une fois que la demande a été traitée, la partie serveur génère la réponse appropriée à l'attention du client. Dans ce cadre, au lieu de construire une page au format HTML complète, on génère selon l'invention une suite d'instructions qui sera à interpréter par le client. Cela donne en particulier une grande flexibilité en ce qui concerne le comportement du poste client. Par exemple, un seul message peut permettre d'opérer des opérations de rafraîchissement d'une partie de l'écran, d'ouvrir une boîte de dialogue, d'afficher une boîte de message etc... et ce de façon simultanée.
[044] Une fois créé, le message est transmis sous forme d'un document XML (Extensible Mark-up Language) éventuellement après compression et cryptage en direction du poste client. Cette opération est représentée au repère 4 par le terme instruction qui correspond à la fonctionnalité décrite au paragraphe précédent.
[045] Ce message d'instruction est reçu au niveau du poste client et doit être interprété.
[046] En particulier, les données dynamiques comprises dans la réponse du serveur sont récupérées et pourront être fusionnées avec un modèle de visualisation qui correspond aux objets statiques nécessaires à l'affichage. Chaque modèle de visualisation est par ailleurs créé, au niveau du poste client, par association d'éléments de construction. Ce sont les données d'instruction qui déterminent les éléments de construction à associer. La combinaison par fusion des deux types de données (couche de présentation et données dynamiques issues du serveur) permet la création de données complètes à afficher, en particulier sous forme d'une page au format HTML. On peut dans ce cadre utiliser pour la visualisation les fonctionnalités de moyens de navigation connus et standard, tels que le navigateur diffusé sous la marque Internet Explorer ®.
[047] Les avantages de l'opération de fusion ainsi réalisée dans la partie client sont multiples. En premier lieu, une fois que les modèles de visualisation et leurs éléments de dépendance (images, scripts, etc.. auxquels font appel les modèles) ont été récupérés et sont disponibles au niveau du poste client, seules les données dynamiques sont à adresser par le biais du réseau de communication. On abaisse donc fortement la consommation du réseau.
[048] La mise à jour des données statiques est de plus très économe en ressources de transmission car il s'agit d'éléments de petite dimension. Par exemple, si un objet graphique est à changer, il n'est pas nécessaire de charger tout le modèle de visualisation qui l'utilise.
[049] En outre, seul le canal de transmission des données a besoin d'être sécurisé dans les moyens de communication ce qui permet de limiter les capacités d'encryptage nécessaires lorsque l'on souhaite sécuriser les communications.
[050] Une fois que la fusion est opérée, son résultat peut être affiché au niveau du poste client tel que présenté à l'étape 5 de la figure 2.
[051] Une interaction locale avec l'utilisateur est ensuite possible tel que présenté au point 6 et met en œuvre un moteur de règles apte à appliquer des règles logiques associées au modèle de visualisation exploité et disponible localement, tel que cela sera précisé plus loin. Elle peut inclure différents fonctionnements.
[052] En particulier, si les instructions transmises par le serveur correspondent à des contrôles (tels un bouton pour l'affichage d'une liste déroulante), les événements à réaliser peuvent être gérés par un code au format de langage Java Script associé au contrôle considéré.
[053] Si les événements à opérer comportent des interactions entre différents contrôles (par exemple si le champ A est renseigné, le champ B devient alors obligatoire) on peut opérer de différentes façons.
[054] Ainsi, si l'interaction est complexe mais rarement utilisée, elle peut être gérée au niveau du serveur et demandée sous forme d'une requête formulée par le poste client au poste serveur.
[055] Si l'interaction est simple et peut être facilement implémentée, elle est gérée au niveau du poste client par le moteur de règle local.
[056] Enfin, si aucune des éventualités précédentes ne semble opportune, il est possible de réaliser des courts éléments de codage au format Java Script à lier à la page pour réaliser une fonctionnalité telle qu'actuellement connue dans le domaine des pages HTML utilisées pour le World Wide Web.
[057] On décrit ci-après plus précisément une structure possible du dispositif de l'invention. Ce dispositif comprend une partie serveur implémentée avec des moyens informatiques connus comprenant des moyens de traitement sous forme de processeur et des moyens de stockage sous forme de mémoire du type RAM (Random Access Memory) ou ROM (Read Only Memory). La partie serveur s'entend d'une seule entité de serveur informatique distant ou de plusieurs serveurs connectés entre eux par des moyens de transmission usuels.
[058] Le dispositif comprend également une partie implémentée localement au niveau du poste client pouvant par exemple être réalisée par un ordinateur personnel du type PC (Personal Computer), visible en figure 3.
[059] La partie serveur et le poste client sont reliés pour la transmission de données par le biais de moyens de communication pouvant par exemple être réalisés par l'intermédiaire d'un réseau (R) de large extension (WAN : Wide Area Network).
[060] On a représenté en figure 3 différents constituants du dispositif de l'invention et leur relation afin de mettre en œuvre le procédé d'interfaçage ici décrit.
[061] Par l'intermédiaire du réseau représenté R, la partie serveur transmet une réponse à la demande formulée antérieurement par l'utilisateur, la réponse comprenant des données d'instructions et des données à afficher.
[062] On pourra notamment utiliser le standard XML comme format de langage de balisage. La réponse est reçue au niveau d'un gestionnaire d'instructions apte à interpréter les données d'instruction contenues dans la réponse pour déterminer les actions à mener. Dans le cas d'un affichage à réaliser, l'interprétation comprend la détermination des éléments de construction à utiliser pour la génération du modèle de visualisation.
[063] Les résultats de l'interprétation sont transmis à un moteur d'association apte à récupérer les données statiques constituant les éléments de construction caractéristiques du modèle de visualisation précédemment déterminé. On a représenté en figure 3 différents éléments de construction utilisés pour la création du modèle de visualisation. En particulier, le modèle de visualisation associe une interface de description décrivant les composants de haut niveau du modèle de visualisation, une couche de présentation rassemblant les différents éléments et attributs liés à une présentation graphique et des règles logiques qui correspondent à la logique locale qui doit être appliquée au modèle de visualisation durant son traitement.
[064] A titre préféré, la couche de présentation peut dépendre des profils d'utilisateur, mais l'interface de description et les règles logiques demeurent identiques. Les éléments de construction peuvent par conséquent être des données totalement indépendantes et être stockés dans des fichiers séparés ou dans un même fichier selon les besoins.
[065] D'autres éléments sont par ailleurs avantageusement associés aux modèles de visualisation ainsi crées. En particulier, des données de ressources de langage sont associées. Ces données sont également choisies parmi différentes ressources disponibles localement en mémoire cache au niveau du poste client. On peut ainsi facilement adapter la page à créer à une langue prédéterminée. L'indication de la ressource de langage à utiliser est également présente dans les données d'instructions reçues dans la réponse.
[066] On peut aussi associer au modèle de visualisation un ou plusieurs filtres. Ces filtres complètent la personnalisation rendue possible par la présente invention. En effet, ils permettent d'adapter l'information disponible à l'écran à des paramètres particuliers au client. C'est un moyen particulièrement efficace de modifier les composants visuels de l'écran de façon non programmatique, par exemple en ce qui concerne les contrôles utilisateur (ex : suppression de certains contrôles de l'écran, modification du caractère obligatoire de certains champs de saisie...)
[067] Au final, l'association du modèle de visualisation, du ou des filtres, des ressources de langage et des données dynamiques reçues dans la réponse du serveur permet de former une page.
[068] Cette association est présentée plus particulièrement à la figure 5.
[069] En revenant à la figure 3, on a représenté que la fusion entre les données statiques ainsi associées et les données dynamiques contenues dans la réponse s'opère au niveau d'un moyen de fusion. Par le biais de la fusion on peut par exemple, créer des données au format XML.
[070] Les applications de navigation standards, en particulier Internet Explorer ®, exploitent des pages au format HTML. On effectue donc avant la transmission à l'application de navigation une transformation vers ce format HTML par le biais de moyens de transformation.
[071] Les étapes débouchant à la visualisation pour l'utilisateur sont alors celles im- plémentées conventionnellement avec les navigateurs existants. Cependant, pour permettre une interaction améliorée avec l'utilisateur sans un recours systématique à l'activité de la partie serveur, le dispositif de l'invention comporte également un moteur de règles apte à exploiter les règles contenues dans un magasin de données. De cette façon, on peut gérer des interactions simples entre le navigateur et l'utilisateur. Par exemple, on peut déterminer localement les données à prévoir dans un menu déroulant suivant le profil du client et suivant la saisie précédemment opérée par l'utilisateur. On évite ainsi un recours systématique à une interrogation du serveur après une saisie du client.
[072] On a également représenté en figure 3 une possibilité de mise à jour ou d'ajout de données dans le magasin de données. En effet, il peut être utile de rafraîchir ou d'augmenter les données contenues localement dans le magasin de données et servant au moteur de règles. Pour ce faire, on adresse depuis la partie serveur jusqu'au poste client une réponse contenant des données d'instructions et des données à exploiter, ici en vue de leur stockage et non en vue de l'affichage.
[073] A réception, l'instruction de stockage est interprétée ce qui résulte en une action de stockage des données contenues dans la réponse dans le magasin de données. Cette étape est également représentée en figure 3.
[074] Par ailleurs, le poste client comporte avantageusement un élément de cache constituant un moyen de stockage de données disponible au niveau local et dans lequel peut être stockée une pluralité de données comprenant les différents éléments de construction. Il s'agit donc de données statiques qui sont généralement utilisées pour des pages de type HTML. Tout type de mémoire peut être utilisé pour une telle mémoire cache et en particulier une mémoire morte de type ROM (Read Only Memory).
[075] Suivant une première possibilité, les données statiques sont installés dès le départ au niveau du poste client et utilisés lorsqu'ils sont demandés pour être fusionnés avec des données issues du serveur. Ainsi, le serveur n'a pas à transmettre les différents éléments ou objets utilisés pour l'affichage.
[076] H peut également arriver que des éléments nécessaires à l'affichage mais non présents initialement au niveau du poste client doivent être utilisés.
[077] Dans ce cadre, la présente invention permet la création des éléments de construction au niveau de la partie serveur et leur transmission une seule fois au poste client pour stockage dans le cache et réutilisation ultérieure.
[078] On a représenté en figure 4 l'étape de fusion opérée entre les données issues du serveur et les données issues du cache local après leur association.
[079] Dans ce cadre, il est représenté que la fusion s'effectue dans la partie du poste client après réception des données dynamiques issues du serveur dans les instructions constitutives de la réponse du serveur. Le gestionnaire d'instructions, à réception des données du serveur, appelle les éléments du modèle de visualisation correspondant présents dans le cache. On les associe et on opère la fusion pour la réalisation par exemple d'une page à transmettre aux moyens de visualisation.
[080] Si un élément de construction nécessaire n'est pas présent initialement dans le cache, l'opération décrite précédemment concernant sa transmission depuis la partie serveur au poste client est réalisée auparavant.
[081] Avantageusement, on exploite des données au format XML pour la création du modèle de visualisation et pour les données à afficher. Une traduction au format HTML peut être opérée après la fusion par des moyens de transformation de façon à obtenir un résultat sous forme de page HTML directement exploitable par une application de navigation conventionnelle.
[082] On notera que l'objet de la présente invention assure une grande souplesse dans le développement des interfaces utilisateur graphique tout en limitant les volumes des données transmises au travers des réseaux. Par ailleurs, le poste client reste une structure légère et facilement installée et la partie serveur conserve un rôle primordial dans le traitement des données et la gestion des éléments de visualisation.

Claims

Revendications
[001] Procédé pour l'interface graphique entre un utilisateur et un système informatique dans lequel on effectue les actions suivantes : entrée d'une demande par l'utilisateur au niveau d'un poste client, transmission de la demande vers une partie serveur en vue du traitement de la demande et de la génération d'une réponse, réception de la réponse au niveau du poste client, affichage du résultat de la réponse pour l'utilisateur, caractérisé par le fait que le poste client reçoit une réponse comprenant des données d'instruction et des données à afficher ; au niveau du poste client, on exécute les données d'instruction pour la construction d'un modèle de visualisation à exploiter ; au niveau du poste client, on crée ledit modèle de visualisation par association d'éléments de construction disponibles localement, on fusionne les données à afficher avec le modèle de visualisation en vue de l'affichage du résultat de la fusion.
[002] Procédé selon la revendication 1, caractérisé par le fait que les éléments de construction comprennent une interface de description des objets du modèle de visualisation, une couche de présentation et des règles logiques à appliquer localement au modèle de visualisation.
[003] Procédé selon la revendication 1 ou 2 dans lequel, caractérisé par le fait que au niveau du poste client, on associe au modèle de visualisation créé une ressource de langage parmi les ressources de langage disponibles localement ou téléchargeables de la partie serveur.
[004] Procédé selon l'une quelconque des revendications 1 ou 3, caractérisé par le fait que au niveau du poste client, on associe au modèle de visualisation des filtres de personnalisation d'affichage pour modifier le rendu visuel du modèle de visualisation.
[005] Procédé selon l'une quelconque des revendications 1 à 4, caractérisé par le fait que, les données d'instruction comportent l'indication du type et des éléments de construction caractéristiques de modèle de visualisation à créer.
[006] Procédé selon l'une quelconque des revendications 1 à 5, caractérisé par le fait qu'on met à jour les données disponibles localement au niveau du poste client par les étapes suivantes : on génère, au niveau du serveur, un message de stockage comprenant des données d'instruction de stockage et les données à stocker, on transmet le message de stockage au poste client, au niveau du poste client, on interprète les données d'instruction pour exécuter le stockage et on stocke les données à stocker dans une mémoire locale.
[007] Procédé selon l'une quelconque des revendications 1 à 6, caractérisé par le fait qu'on effectue l'affichage au niveau du poste client par une application de navigation.
[008] Procédé selon l'une quelconque des revendications 1 à 7, caractérisé par le fait qu'on utilise des données à afficher et des éléments de construction des modèles de visualisation au format XML, on traduit le résultat de la fusion au format HTML en vue de l'affichage.
[009] Dispositif d' interfaçage graphique entre un utilisateur et un système informatique, comprenant : des moyens d'entrée d'une demande par l'utilisateur au niveau d'un poste client, des moyens de communication entre le poste client et une partie serveur, des moyens de traitement dans la partie serveur pour la génération d'une réponse, des moyens d'affichage du résultat de la réponse au niveau du poste client, caractérisé par le fait que, la réponse de la partie serveur comprend des données d'instruction et des données à afficher ; il comporte, au niveau du poste client, un gestionnaire d'instructions apte à interpréter les données d'instruction pour la construction d'un modèle de visualisation à exploiter ; il comporte un moteur d'association au niveau du poste client apte à créer ledit modèle de visualisation par association d'éléments de construction ; il comporte des moyens de stockage des éléments de construction au niveau du poste client ; il comporte, au niveau du poste client, des moyens pour fusionner le modèle de visualisation et les données à afficher, en vue de l'affichage du résultat de la fusion.
[010] Dispositif selon la revendication 9, caractérisé par le fait que, les éléments de construction comprennent une interface de description des objets du modèle de visualisation, une couche de présentation et des règles logiques à appliquer localement au modèle de visualisation.
[011] Dispositif selon la revendication 10, caractérisé par le fait qu'il comporte un moteur de règles apte à appliquer les règles logiques du modèle de visualisation.
[012] Dispositif selon l'une quelconque des revendications 9 à 11, caractérisé par le fait qu'il comporte une application de navigation pour l'affichage du résultat de la fusion au niveau du poste client.
EP04741912A 2003-07-01 2004-06-28 Procede et dispositif pour l interfacage graphique Ceased EP1658561A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04741912A EP1658561A1 (fr) 2003-07-01 2004-06-28 Procede et dispositif pour l interfacage graphique

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP03014928A EP1494116A1 (fr) 2003-07-01 2003-07-01 Procédé et dispositif pour l'interfaçage graphique
PCT/EP2004/051276 WO2005003966A1 (fr) 2003-07-01 2004-06-28 Procede et dispositif pour l'interfacage graphique
EP04741912A EP1658561A1 (fr) 2003-07-01 2004-06-28 Procede et dispositif pour l interfacage graphique

Publications (1)

Publication Number Publication Date
EP1658561A1 true EP1658561A1 (fr) 2006-05-24

Family

ID=33427086

Family Applications (2)

Application Number Title Priority Date Filing Date
EP03014928A Withdrawn EP1494116A1 (fr) 2003-07-01 2003-07-01 Procédé et dispositif pour l'interfaçage graphique
EP04741912A Ceased EP1658561A1 (fr) 2003-07-01 2004-06-28 Procede et dispositif pour l interfacage graphique

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP03014928A Withdrawn EP1494116A1 (fr) 2003-07-01 2003-07-01 Procédé et dispositif pour l'interfaçage graphique

Country Status (3)

Country Link
US (1) US8261194B2 (fr)
EP (2) EP1494116A1 (fr)
WO (1) WO2005003966A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3074633C (fr) 2005-07-15 2022-11-08 Indxit Systems, Inc. Systemes et procedes d'indexation et de traitement de donnees
US9202297B1 (en) 2011-07-12 2015-12-01 Domo, Inc. Dynamic expansion of data visualizations
US10001898B1 (en) 2011-07-12 2018-06-19 Domo, Inc. Automated provisioning of relational information for a summary data visualization
US9792017B1 (en) 2011-07-12 2017-10-17 Domo, Inc. Automatic creation of drill paths
TWI505178B (zh) * 2012-03-23 2015-10-21 Seiko Epson Corp Printing systems and printers
US9430548B1 (en) * 2012-09-25 2016-08-30 Emc Corporation Generating context tree data based on a tailored data model
WO2014182280A1 (fr) * 2013-05-07 2014-11-13 Empire Technology Development Llc Gestion de données en ligne

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5327529A (en) * 1990-09-24 1994-07-05 Geoworks Process of designing user's interfaces for application programs
US5119475A (en) * 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
EP0602263A1 (fr) * 1992-12-15 1994-06-22 International Business Machines Corporation Générateur de programme pour interface utilisateur
ATE190149T1 (de) * 1993-04-30 2000-03-15 Ibm Bereich-layout in einer sicht auf einem grafischen anzeigeschirm
US6356933B2 (en) * 1999-09-07 2002-03-12 Citrix Systems, Inc. Methods and apparatus for efficiently transmitting interactive application data between a client and a server using markup language
US7013340B1 (en) * 2000-05-18 2006-03-14 Microsoft Corporation Postback input handling by server-side control objects
WO2002023336A1 (fr) * 2000-09-14 2002-03-21 Bea Systems, Inc. Boite a outils logiciels de mise au point d'interface graphique utilisateur articulee autour du langage xml
WO2002044897A1 (fr) * 2000-11-29 2002-06-06 Fourbit Group, Inc. Creation d'une interface utilisateur declarative
US6963930B2 (en) * 2001-02-15 2005-11-08 Centric Software, Inc. Automatic transfer and expansion of application-specific data for display at a website
US20020130900A1 (en) * 2001-03-16 2002-09-19 Tomorrowsoft Corporation System for generating an interface for software applications in a client-server environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005003966A1 *

Also Published As

Publication number Publication date
WO2005003966A1 (fr) 2005-01-13
US8261194B2 (en) 2012-09-04
EP1494116A1 (fr) 2005-01-05
US20060168249A1 (en) 2006-07-27

Similar Documents

Publication Publication Date Title
US9170701B2 (en) Suggesting contextually-relevant content objects
US20130007111A1 (en) Method for distributing computing between server and client
CN101488087A (zh) 用于启动用于访问用户界面元素的层的配置条
WO2005003966A1 (fr) Procede et dispositif pour l'interfacage graphique
WO2011067531A1 (fr) Procede de modification dynamique du rendu d'une page web
WO2008095800A1 (fr) Procede de transmission d'au moins un contenu representatif d'un service, depuis un serveur vers un terminal, dispositif et produit programme d'ordinateur correspondants
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
EP2187321B1 (fr) Procédé et dispositif d'édition d'un objet représenté dans une page web
FR3021769A1 (fr) Dispositif et procede de generation d'au moins un fichier informatique pour la realisation d'une interface graphique d'un equipement electronique, et produit programme d'ordinateur associe
US20080040371A1 (en) Generic architecture for providing data to flash model
Díaz et al. Turning web applications into portlets: Raising the issues
EP1710715A1 (fr) Méthode dynamique de rendu visuel de fenetres d'affichage et de saisie de données sur un écran d'ordinateur
US20150067157A1 (en) Optimize data exchange for mvc-based web applications
FR2797336A1 (fr) Procede et systeme de creation, de gestion et de consultation de sites web
Lama Providing native experiences in mobile with PWA
WO2007012653A1 (fr) Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme
FR2913276A1 (fr) Procede et dispositif de communication.
Luqun et al. The study on web gis architecture based on jnlp
WO2005031620A2 (fr) Procede d’enquete electronique
EP3343410A1 (fr) Dispositif de traitement de flux de données à grande échelle
FR2830398A1 (fr) Procede et dispositif d'execution d'une fonction avec selection et envoi de resultats multiples dans un environnement client-serveur
WO2020099118A1 (fr) Procédé de génération d'un contenu de manière extensible
FR2931270A1 (fr) Procede et systeme de configuration de documents
WO2001095102A1 (fr) Procede de structuration, de transfert et d'interpretation d'un ensemble d'informations destinees a la conception d'interfaces graphiques
FR2830349A1 (fr) Procede et dispositif d'execution d'une fonction dans un serveur informatique, ladite fonction retournant des resultats multiples selectionnables

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060201

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100305

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150730