FR2835332A1 - Procede et systeme pour generer sans besoin de programmation une application sur un equipement mobile - Google Patents

Abstract

Procédé pour générer une application sur un équipement mobile, ladite application étant prévue pour traiter (i) des informations issues d'une première base de données (X) accessible au sein d'un système d'informations et contenant un ensemble de données structurées, et (ii) des informations saisies à partir dudit équipement mobile. Ce procédé comprend les étapes suivantes :- une étape pour extraire de la première base de données (X) des données cibles destinées à l'application.- une étape pour préparer les données cibles en un sous-ensemble structuré de données enrichies constituant une seconde base de données (Y), - une étape pour transférer tout ou partie du contenu de la seconde base de données (Y) dans des moyens de stockage de données au sein de l'équipement mobile ou connectés à celui-ci, et- une étape pour interpréter les données ainsi transférées de manière à construire dynamiquement l'application sur l'équipement mobile. Utilisation pour la génération automatique d'applications sans besoin de programmation, notamment pour un terminal mobile ou des parcs d'équipements mobiles tels que des assistants personnels électroniques (PDA).

Description

<Desc/Clms Page number 1>

Procédé et système pour générer sans besoin de programmation une application sur un équipement mobile
La présente invention concerne un procédé pour générer sans besoin de programmation une application sur un équipement mobile. La génération des applications mobiles est spontanée au sens où l'application qui va permettre d'exploiter et d'agir sur les données stockées dans le périphérique mobile ne nécessite pas de développement. Elle vise également un système mettant en oeuvre ce procédé, ainsi qu'une plate-forme applicative correspondante.

Le domaine de l'invention est la création, la commercialisation et le support de solutions innovantes, performantes et économiques pour les collaborateurs nomades des entreprises.

Les entreprises ont un besoin croissant de mobilité qu'elles satisfont actuellement en équipant leurs collaborateurs nomades, par exemple leurs commerciaux, avec des équipements mobiles tels que des téléphones portables ou des assistants numériques personnels ou encore des tablettes numériques..

Or, ces entreprises sont confrontées à de réelles difficultés de gestion de l'information entre les informations de leurs systèmes centraux et celles de l'ensemble des équipements mobiles confiés à leurs collaborateurs.

Ces difficultés viennent principalement du fait que dans les solutions actuelles, les terminaux accèdent aux systèmes centraux en mode de connexion permanente et

ne conservent pas les données au delà de la fermeture de la session informatique.

Par ailleurs, les données capturées ne sont pas structurées et ne permettent pas d'agir de manière pertinente et durable sur ces données. Et particulièrement, il n'existe pas à ce jour de processus global dynamique qui génère automatiquement une application côté terminal mobile sans le besoin de programmation du coté terminal.

On observe en fait que les applications mobiles actuelles du marché sont en majorité des applications propriétaires développées spécifiquement sur et pour des assistants mobiles donnés, pour des communautés d'utilisateurs cibles, ou pour être vues comme des applications clientes des progiciels centralisés. Or, ces applications propriétaires ont pour inconvénient majeur de devoir être programmées, inconvénient important au regard du procédé et de l'invention décrite ici. Elles ont aussi pour inconvénient d'être mises à jour sur l'ensemble des assistants électroniques à chaque

<Desc/Clms Page number 2>

fois que la technologie évolue et en réponse à de nouvelles demandes des utilisateurs ou de l'entreprise. Par ailleurs, elles souffrent généralement de la limitation des performances de ces assistants dès l'instant que ces applications sont disponibles ; l'évolution des technologies mobiles n'améliore en rien leur adaptation fonctionnelle puisque le périmètre des applications s'exécutant sur le terminal mobile est invariable dynamiquement. A cela s'ajoute le fait que de telles applications créent de fait un nouvel îlot d'informations très vite isolé et rendant difficile l'intégration de leurs données dans le système de données applicatif de l'entreprise. Leur coût de développement devient alors très élevé.

Le but de la présente invention est de remédier aux inconvénients précités en proposant un procédé permettant de développer et de créer des applications mobiles sans qu'il soit besoin de programmer ces applications du côté terminal.

Cet objectif est atteint avec un procédé pour générer sans besoin de programmation une application sur un équipement mobile, ladite application étant prévue pour traiter (i) des informations issues des bases de données (X) accessibles au sein d'un système d'informations et contenant un ensemble de données structurées, pour enrichir cette base de données et (ii) des informations saisies à partir dudit équipement mobile.

Suivant l'invention, ce procédé comprend les étapes suivantes : - une étape pour extraire des bases de données (X) des données cibles destinées à ladite application et préparer lesdites données cibles en un sous-ensemble structuré constituant une seconde base de données (Y), - une étape facultative pour sélectionner, depuis un poste de travail relié audit système d'informations, des données prévues pour être transférées sur ledit équipement mobile, de façon à constituer un troisième ensemble de données (Z) par utilisateur, - une étape pour transférer le contenu dudit troisième ensemble de données (Z) dans des moyens de stockage de données au sein dudit équipement mobile ou connectés audit équipement mobile, et pour synchroniser les contenus respectifs desdits moyens de stockage et dudit ensemble de données (Z), et - une étape pour interpréter les données ainsi transférées de manière à construire dynamiquement l'application sur l'équipement mobile.

<Desc/Clms Page number 3>

Si l'étape de sélection précitée n'est pas effectuée, ce sont les données de la base de données (Y) qui seront transférées dans les moyens de stockage de données au sein dudit équipement mobile.

Suivant un autre aspect de l'invention, il est proposé un système pour générer sans besoin de programmation une application sur un équipement mobile, ladite application étant prévue pour traiter (i) des informations issues des bases de données (X) accessibles au sein d'un système d'informations et contenant un ensemble de données structurées, pour enrichir cette base de données et (ii) des informations saisies à partir dudit équipement mobile, ce système mettant en oeuvre le procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend : des moyens pour extraire de la première base de données (X) des données cibles destinées à ladite application, des moyens pour préparer lesdites données cibles en un sous-ensemble structuré de données enrichies constituant une seconde base de données (Y), des moyens pour transférer tout ou partie du contenu de ladite seconde base de données (Y) dans des moyens de stockage de données au sein dudit équipement mobile ou connectés audit équipement mobile, et des moyens pour interpréter les données ainsi transférées de manière à construire dynamiquement l'application sur l'équipement mobile.

Le système de génération dynamique d'applications selon l'invention peut être avantageusement appliqué pour la génération d'applications sur un terminal mobile ou un parc d'équipements mobiles, pour la mise à jour ou l'enrichissement des données des progiciels et des logiciels existants dans le système d'informations diffusés sur un ensemble de terminaux, mobiles ou légers, à partir d'une plate-forme unique-ou encore pour délivrer des contenus personnalisés à des détenteurs d'équipements mobiles Il est à noter que les applications mobiles générées dynamiquement sont dotées d'une dimension polymorphe au sens où elles s'adaptent aux données et à leur volume, voire à l'enrichissement fonctionnel des sources de données sans changer pour autant de nature.

On peut ainsi interfacer un progiciel ou logiciel existant pour publier des données vers des assistants légers dotés d'une mémoire centrale, afin d'agir de manière indépendante sur ces données. Ce progiciel peut être par exemple un progiciel spécialisé de relation client.

<Desc/Clms Page number 4>

Le procédé selon l'invention permet une génération spontanée des applications mobiles sans programmation.

On peut aussi appliquer le procédé selon l'invention dans d'autres configurations logicielles pour répondre à la demande de métiers différents et pour un public plus large que des communautés professionnelles.

Un client utilisateur du procédé selon l'invention bénéficie ainsi d'une solution unique permettant de générer plusieurs applications distinctes pour des assistants mobiles. L'acquisition de la plate-forme mettant en oeuvre le procédé selon l'invention ne nécessite pas de formation particulière, ce qui réduit considérablement les coûts d'appropriation et d'implémentation.

Les avantages procurés par le procédé selon l'invention sont : une dispense de programmation des applications mobiles ; une grande simplicité de l'utilisation de la plate-forme ; une administration centralisée ; une adaptation du contenu et de son volume selon le profil des utilisateurs ; - une meilleure exploitation des données centrales de l'entreprise ; - la faculté pour l'application mobile de s'adapter très rapidement aux changements des processus globaux de l'entreprise ; - l'indépendance quasi totale par rapport au système d'informations existant, pourvu qu'il réponde aux normes et aux standards de l'industrie et du marché ; un déploiement rapide et personnalisé ; une réduction importante des coûts globaux d'acquisition.

Par ailleurs, le procédé selon l'invention va permettre de proposer à des entreprises clients une plate-forme capable d'évoluer avec la montée en puissance de leur système d'informations sans limitation en nombre d'applications mobiles : en effet, une seule et même plate-forme a la capacité de générer autant d'applications mobiles'métiers'que celles souhaitées.

Une plate-forme technologique implémentant le procédé selon l'invention comprend deux modules exploitables par des collaborateurs de l'entreprise, simplifiés et dynamiques, et un module terminal.

On comprendra mieux l'invention à la lumière de la description qui suit, en référence aux figures suivantes :

<Desc/Clms Page number 5>

- la figure 1 est un schéma synoptique illustrant une architecture logique des principaux flux de données mis en oeuvre dans le procédé selon l'invention ; - la figure 2 illustre schématiquement un exemple de mise en oeuvre du procédé selon l'invention au sein d'une entreprise, dans une utilisation de type
UML ; - la figure 3 illustre schématiquement les fonctions d'un premier module, appelé poste de contrôle, mis en oeuvre dans l'invention ; - la figure 4 illustre schématiquement les fonctions d'un second module, appelé poste de sélection, mis en oeuvre dans l'invention ; - la figure 5 illustre schématiquement les fonctions d'un troisième module, appelé module terminal, mis en oeuvre dans l'invention ; - la figure 6 illustre un exemple d'architecture logicielle d'un terminal mobile, correspondant à l'implémentation du procédé selon l'invention ; la figure 7 représente les étapes successives exécutées pour la création d'une application mobile à partir d'un fichier Excel ; et, - la figure 8 illustre un exemple d'architecture système et de réseau d'un système d'informations mobile incluant un système selon l'invention.

Le procédé de génération selon l'invention met en oeuvre des flux de données entre plusieurs bases de données, des postes respectivement de contrôle, de sélection et de synchronisation, et un module terminal. Ainsi, en référence à la figure 1, un poste de contrôle permet une capture de données à partir d'une base de données X. A partir d'un poste de sélection, on sélectionne parmi les données capturées un ensemble de données qui sont stockées dans une seconde base de données Y. A partir d'un poste de synchronisation, des données en provenance de la seconde base de données Y sont transférées et synchronisées dans une troisième base de données Z stockée dans un terminal et traitées par un module terminal. Les protocoles de connexion entre les différentes composants et postes constituant le système selon l'invention sont de préférence des protocoles standards, par exemple de type ODBC ( Open Data Base Connectivity ).

Dans un exemple d'utilisation du procédé selon l'invention, du type UML, illustré par la figure 2, un responsable des ventes d'une entreprise définit les informations pertinentes qui devront être transférées et traitées sur les terminaux mobiles des commerciaux mobiles ou nomades de l'entreprise. Sur la base de ces informations pertinentes, un administrateur de base de données identifie les

<Desc/Clms Page number 6>

informations centrales et un informaticien opérant un serveur de synchronisation prépare les règles de synchronisation. Un informaticien opérant un poste de contrôle règle les droits attribués aux différents utilisateurs de terminaux, sélectionne les données, enrichit ces données et prépare la seconde base de données Y (X). Lorsque l'opération de capture des données provenant de la première base de données X a été effectuée pour constituer le contenu de la seconde base de données, un commercial opérant un poste d'utilisation peut effectuer des opérations de sélection, de gestion de performances, et de filtrage, préparer la troisième base de données Z (Y) et commander les opérations de synchronisation ou de transfert dans un ou plusieurs terminaux mobiles.

Un commercial mobile peut, à partir de son terminal mobile ainsi préparé, exploiter la base de données Z et agir sur cette base de données, et éventuellement exploiter et agir sur une base de données Z égale à Y. Il peut aussi effectuer des opérations de synchronisation des données Z entre la base de données résidant dans son terminal mobile et la base de données Y. Une extension possible de ces opérations est le transfert de certaines données de Z acquises à partir du terminal mobile en matière d'applications formulaires de type bon de commande, fax, enquête,
Un premier module 1 d'administration appelé poste de contrôle a pour première fonction de charger les structures et les données centrales tout en faisant varier le volume d'informations. Ce module est doté de règles de gestion des utilisateurs, de règles de gestion et de gestion de contenu et peut être personnalisé selon les besoins de l'entreprise. Le poste de contrôle 1 a cinq fonctions principales, en référence à la figure 3 : une fonction d'administration pour gérer l'accès et la capture dynamiques des structures et des données, mettant en oeuvre des techniques d'accès
ODBC, pour gérer l'autorisation d'accès aux données ; une fonction d'enrichissement, pour enrichir les sources de données principales avec de nouvelles informations ; une fonction de typage, pour typer toutes les données et retrouver des règles de gestion de données de base ; une fonction d'organisation, pour organiser les écrans ou les fiches, les sections ou les onglets, pour ordonner et exclure les champs de l'application ;

<Desc/Clms Page number 7>

une fonction d'ergonomie, pour améliorer la qualité visuelle des applications mobiles et insérer des données graphiques.

Le caractère dynamique de la capture se traduit par le fait que lorsque une base X évolue, les changements sont pris en compte directement à partir du poste de contrôle 1. Il est à noter qu'il serait également possible d'accéder aux données via des connecteurs applicatifs spécifiques pour des progiciels du marché (citons en exemple SAP"'ou SiebeD.

Avec la fonction dite ici de typage, il est très simple de définir le format des champs de saisie comme une case à cocher, une liste déroulante, une combo box, une zone d'édition,....

Il est important de noter que le poste de contrôle peut être agencé pour produire plusieurs ensembles de données structurées Y1, Y2,..., Yn.

Le poste de contrôle 1 dispose d'un tableau de bord unique à partir duquel on prépare les structures et les données et on administre les utilisateurs. Les fonctions assurées par le poste de contrôle incluent par exemple : - la gestion syntaxique, pour modifier la propriété d'un champ tels que l'intitulé, l'affichage permanent, pour typer les données (date, nombre, graphique, alphanumérique,...) ; - la gestion des droits, pour définir le mode d'accès aux champs (lecture/écriture), le droit de transfert distinctif ; - la gestion d'écran, pour structurer des pages et des onglets ainsi que de les intituler, et de définir l'emplacement des champs dans une page ; - la gestion des formats, pour définir le format des champs de données tels que la police, le style, la taille ou la couleur ; - la gestion des cellules, pour attribuer aux cellules une forme telle qu'une liste, boîte, case à cocher, bouton poussoir, slide , éléments graphiques dynamiques, la couleur, ou modifier la bordure et la trame ; - la gestion graphique, pour insérer des éléments graphiques d'une charte graphique allégée ; - la gestion des utilisateurs, pour définir la communauté des utilisateurs de la base de données Y.

Un second module appelé poste de sélection, installé sur des postes clients, permet à des collaborateurs mobiles de sélectionner parmi les données structurées Y1, Y2,.., Yn (X) préparées par l'administrateur un ensemble de données Z1,

<Desc/Clms Page number 8>

Z2,..., Zn qu'ils utiliseront directement sur leurs assistants personnels. Ce poste de sélection peut aussi être utilisé par un collaborateur non mobile d'une entreprise pour la préparation de terminaux qui seront utilisés par des collaborateurs mobiles de cette entreprise.

Ce poste de sélection permet de filtrer les données et de n'en choisir que les plus utiles. Le poste de sélection 2 a plusieurs fonctions, en référence à la figure 2 : une fonction de capture, selon un processus entièrement dynamique utilisant aussi les mécanismes connus d'accès aux bases de données ODBC ; - un ensemble de fonctions de sélection, d'administration, de filtration et de sauvegarde, la fonction de sélection permettant au collaborateur mobile de sélectionner les données qui lui sont utiles par un simple clic en parcourant un arbre représentant les données ; et une fonction de création d'un ensemble de données structurées Z1, Z2, Zn, cet ensemble étant prévu pour être transféré dans une base de données Zn (Y).

Il est à noter que la fonction de sélection correspond en fait à ce qui est appelé généralement la campagne de publication . Cette campagne de publication peut être effectuée autant de fois que nécessaire. Par ailleurs, il est possible de limiter le nombre de données dans l'arbre grâce à une méthode de tri (par exemple, tous les clients dont le nom commence par un A, ou les fournisseurs de la région Nord,...), car le volume de données devra être adapté à la mémoire disponible des assistants légers.

Un troisième module 3, appelé module terminal en référence à la figure 5, est fourni pour traiter les données structurées Z1, Z2,.., Zn au sein d'un terminal mobile, et pour transférer et synchroniser ces données structurées avec les données structurées Y1, Y2,.., Yn contenues dans la seconde base de données Y (Zn). Le module terminal 3 est agencé pour réaliser les fonctions suivantes : - exploiter les données structurées Z1, Z2,..., Zn et agir sur des fonctions du terminal mobile, notamment des fonctions de navigation, de modification et d'ajout ou de recherche, et - synchroniser et transférer des données traitées au sein du terminal mobile vers la seconde base de données Y (Zn).

La fonction de navigation permet à l'utilisateur de naviguer dans une fiche comme sur un écran conventionnel et d'utiliser des onglets virtuels pour éviter de parcourir toute la fiche. La fonction de modification/ajout met en oeuvre des

<Desc/Clms Page number 9>

fonctions de saisie disponibles sur le système d'exploitation de l'assistant, tels que la reconnaissance d'écriture, le clavier. La fonction de recherche est réalisée au moyen d'un moteur de recherche multi-champs qui autorise une identification rapide des informations. La fonction de synchronisation et de transfert permet d'invoquer directement un agent de synchronisation ou un service de transfert.

Le module terminal 3 inclut, en référence à la figure 6 illustrant un exemple d'architecture logicielle d'un terminal mobile, un module d'interprétation dynamique PPDC ( Plus petit Dénominateur Commun ), un ensemble de librairies allouées dynamiquement correspondant à un ensemble de règles de gestion 1,2,... n, et un ensemble de fonctions et de services (navigation, ajout, modification,...). Le module terminal 3 coopère avec le système d'exploitation mobile du terminal, des modules de services sécurisés, un module agent de synchronisation, et une base de données standard.

L'évolution du périmètre fonctionnel du module PPDC est basée sur la logique suivante : les règles de gestion communes à plusieurs clients seront implémentées au niveau du module PPDC, les règles distinctes et uniques seront développées sous la forme de librairies, des librairies demandées par plusieurs clients deviennent communes. Outre son architecture intrinsèque, le module terminal s'appuie sur des fonctions et des services externes comme les systèmes de sécurité, les bases de données ou les agents de synchronisation.

Les modules qui viennent d'être décrits : poste de contrôle 1, poste de sélection 2, et module terminal 3 constituent, un système de génération spontanée d'applications mobiles selon l'invention, appelé aussi plate-forme d'intégration d'applications mobiles d'entreprises.

Le protocole de transport retenu est basé sur des mécanismes ODBC ; il l'est de bout en bout grâce au choix d'outils le supportant. Cependant l'utilisation d'ODBC n'est pas rédhibitoire pour utiliser la plate-forme selon l'invention dans un système d'informations car l'architecture selon l'invention ne fait que s'appuyer sur eux et peut par conséquent supporter d'autres protocoles inter-applications. Le format des données n'est pas non plus unique. Toute technologie qui permet d'établir un dialogue entre des applications d'une nature différente et tous les formats de données s'inscrivent dans le périmètre technique du procédé selon l'invention. Pour exemple, le protocole entre une application centrale et le poste de contrôle peut être différent des mécanismes ODBC, il peut être celui utilisé par l'application centrale (connecteur

<Desc/Clms Page number 10>

applicatif spécifique). Dans ce cas, la plate-forme applicative selon l'invention sera vue comme un client de l'application centrale et bénéficiera des fonctions et des services de l'application centrale, particulièrement l'accès aux données sources. Le format des données comme XML, les protocoles iPv6, les formats de compression, l'UMTS et WiFi sont source d'usage de la plate-forme. Donc, ce système utilise les protocoles ODBC à chaque étape de transfert et on utilisera de préférence un moteur de synchronisation proche des standards SyncML.

Dans un exemple d'implémentation du procédé selon l'invention, pour la création d'une application de saisie de commande relative à une clientèle, illustré par la figure 7, on considère par exemple dans une première étape, un utilisateur d'une entreprise cliente créant un fichier Excel de suivi des ventes, constitué, à titre d'exemple non limitatif, de 6 feuilles pour 70 champs, 100 enregistrements clients et un catalogue produit de 300 articles correspondant à un volume potentiel de 11 000 données. Le temps passé à cette première phase peut, à titre d'exemple non limitatif, être évalué à environ deux heures.

Une seconde étape consiste à typer les structures et les données en utilisant le poste de contrôle 1, pour générer des données structurées Y, correspondant dans le cas présent au suivi des ventes. Cette étape de typage peut être réalisée sans difficulté par un utilisateur simple.

Dans un troisième étape, des fichiers de synchronisation sont préparés par un administrateur du système en utilisant par exemple l'outil XTND de XTND System.

Une quatrième étape, qui peut être réalisée par un collaborateur mobile, consiste à sélectionner des données, dans le cas présent un extrait du suivi des ventes, depuis le poste de sélection 2. Cette tâche de sélection est très rapide et ne prend en pratique que quelques secondes.

L'ensemble de l'opération de création d'une application de saisie de commande client n'aura demandé globalement qu'environ trois heures, ce qui est très court en regard des temps observés avec les solutions actuelles du marché.

Il est à noter que les opérations de transfert de données entre le système central de la plate-forme et les terminaux mobiles peuvent être réalisées au moyen de l'une quelconque des technologies actuelles ou futures, qu'il s'agisse en matière de transport de transmission par voie filaire ou non filaire, mettant par exemple en oeuvre des transmissions infrarouges, radio ou autres, selon le serveur de synchronisation choisi.

<Desc/Clms Page number 11>

On peut envisager plusieurs modes d'utilisation du procédé selon l'invention correspondant à différentes situations caractéristiques rencontrées dans la gestion d'un parc d'équipements communicants mobiles.

Un premier mode d'utilisation concerne la structuration sous forme mobile de tout ou partie des applications existantes au sein d'un système central d'une entreprise.

Un second mode d'utilisation correspond à une évolution du périmètre fonctionnel des applications, tel que l'ajout de tables constituées de champs et de données ou de règles de gestion (traitement de données).

Un troisième mode d'utilisation correspond à la création de nouvelles applications mobiles.

Le système d'informations implémentant le procédé et la plate-forme selon l'invention peut être réalisé à partir de technologies standards du marché, notamment en ce qui concerne les systèmes de gestion de base de données SGBD/R, les protocoles de synchronisation (SyncML), les protocoles de connexion de données structurées ODBC ou d'annuaires LDAP, les protocoles de requête tels que SQL ou de format tels que XML ou des formats plats textes, autres.

Bien entendu, le procédé selon l'invention peut être mis en oeuvre en coopération avec d'autres offres logicielles présentant un niveau de structuration plus élevé telles que des produits SAP" ou Siebel, ainsi qu'avec des systèmes de gestion de base de données relationnelles tels que ceux des sociétés Oracle, Sybase ou IBM.

Il est en outre à noter que les formats de données peuvent évoluer dans le cadre du procédé selon l'invention. On peut aussi prévoir d'autres moteurs de synchronisation que celui proposé dans la description qui vient d'être faite.

Avec le procédé selon l'invention, on permet à un collaborateur nomade, en tout lieu d'embarquer des données issues du système central, de pouvoir agir sur ces données, et d'accéder aux applications et aux services de l'entreprise depuis son équipement mobile à partir du terrain. Il est tout à fait possible de greffer la plateforme d'intégration d'applications mobiles d'entreprise selon l'invention autour d'applications techniques ou métiers.

On va maintenant décrire le fonctionnement d'une plate-forme applicative implémentant le procédé selon l'invention, en termes d'échanges, via un réseau de communication TCP/IP, entre un serveur matériel S1, un ensemble d'ordinateur de bureau V1,... Vn et un ensemble d'assistants électroniques personnels P1,... Pn, en

<Desc/Clms Page number 12>

vue de la génération d'une application mobile, en référence à la figure 8. Sur le serveur S1, une interface capture dynamiquement la structure d'une application qui réside sur le système central et les données qu'elle contient sans que ces dernières soient modifiées.

Un serveur SY de synchronisation et de gestion des assistants P1,..., Pn également installé sur le serveur S ou sur un autre serveur, inventorie les performances et la mémoire des terminaux et autorise la publication des données ciblées. La remontée de données vers le serveur S 1, et donc vers une base de données intermédiaire (Y), est géré de la même façon pour des données embarquées modifiées à partir d'un terminal mobile.

Chaque collaborateur mobile peut mettre en oeuvre, à partir d'un ordinateur de bureau dédié ou générique V1,.... Vn, les fonctions de préparation qui lui sont accessibles au sein de la plate-forme applicative, pour générer sur son équipement mobile, par exemple son assistant personnel P1,.... Pn, la ou les applications métiers dont il a besoin dans son activité professionnelle, sans nécessiter de programmation générale. On peut aussi prévoir une préparation d'un équipement mobile P2 à partir d'un ordinateur V2 relié à un réseau de communication, filaire ou non filaire, via un module RAS de connexion au système d'informations de l'entreprise, ou encore une communication directe entre un équipement mobile P3 et le système d'informations par liaison radio on infrarouge et via un réseau de communication filaire ou non filaire.

De manière générale dans les disciplines des entreprises et en particulier dans le métier de la vente, la mise en oeuvre du procédé selon l'invention permet de respecter l'organisation des processus de vente de l'entreprise, leur rapide évolution et les droits d'accès aux données. Ainsi, chaque collaborateur organise le contenu de son équipement mobile dans le cadre d'une campagne de publication, et peut autoriser la diffusion de ce contenu grâce à une interface dynamique invoquée depuis un ordinateur de bureau, en fonction des performances de son équipement mobile.

Le procédé selon l'invention et la plate-forme applicative pour sa mise en oeuvre peuvent être avantageusement utilisés par des entreprises employant des collaborateurs mobiles ou nomades, mais aussi par des éditeurs de logiciels ou de progiciels qui souhaitent apporter à leurs clients la possibilité d'enrichir leurs applications existantes à partir d'une seule plate-forme. Le terminal mobile peut être commercialisé et fourni avec une application autonome que la société détentrice de l'invention ou celle qui l'exploite a créé. L'utilisateur pourra lui demander ses services

<Desc/Clms Page number 13>

pour modifier cette application ou acquérir la plate-forme. Les fournisseurs de contenu et portails peuvent aussi avantageusement utiliser une plate-forme applicative selon l'invention, afin de délivrer du contenu personnalisé à tout détenteur d'assistant électronique personnel.

Dans cette application particulière, un utilisateur établit sa demande via le Web ou tout autre réseau de communication, qui est traité par le fournisseur sur sa plateforme applicative en vue de préparer pour cet utilisateur un contenu spécialisé.

L'utilisateur connecte alors son assistant électronique personnel à son ordinateur ou à son téléphone portable par exemple pour transférer les données sur son assistant.

L'application est générée automatiquement et l'utilisateur peut ainsi embarquer des informations qu'il pourra lui-même ultérieurement enrichir.

Il est à noter qu'il est possible dans le cadre de la présente invention de stocker plusieurs bases sur un même terminal mobile, permettant d'exécuter des applications distinctes accédant à leurs propres données. Ces applications multiples peuvent, soit présenter la même ergonomie, soit être d'ergonomie différente, et correspondre à des utilisations professionnelles différentes telles que : - extension des progiciels de gestion intégrée (ERP) ou des logiciels spécialisés ; - glossaire professionnel (santé, état de stock, nomenclature, dictionnaire, catalogue,...) ; - application de ressources humaines (curriculum Vitae, compétences, disponibilité) ; - nouvelles applications mobiles ;
Le serveur de synchronisation SY peut être distinct du serveur principal de la plate-forme applicative. Les règles de sécurité mises en oeuvre sur ce serveur de synchronisation peuvent être par exemple celles du système installées derrière les coupe-feu du système informatique de l'entreprise et peuvent être intégrées aux systèmes de sécurité de l'entreprise.

En particulier, avec l'outil de synchronisation XTND, sur chaque équipement mobile, l'accès est contrôlé par la saisie d'un nom et d'un mot de passe. Le transfert de flux entre chaque élément de la chaîne de synchronisation est sécurisé au moyen de protocoles de cryptage de données, par exemple du type Certicom 128 bits. De plus, la sécurité des données locales peut être obtenue via des produits du marché en utilisant des librairies de cryptage de données.

<Desc/Clms Page number 14>

L'utilisateur de l'assistant électronique navigue dans l'application avec son stylet comme on la fait dans une application classique avec son clavier. L'application locale générée dynamiquement se compose de pages, d'onglets, d'échelles montantes et descendantes, de fenêtres, de cases à cocher, de listes déroulantes ou de curseurs de navigation. Il est à noter que l'on peut quitter l'application sans passer par les menus du système d'exploitation local. L'application mobile exploite toutes les capacités du système local et a en outre la possibilité de bénéficier, comme pour les applications classiques, de tout type de traitement, service ou fonction, pourvu qu'il soit pris en compte dans le procédé et la plate-forme applicative selon l'invention.

L'ergonomie de l'application peut reposer sur une charte graphique allégée ou peut être améliorée grâce au chargement d'images légères (capacités actuelles).

Cependant, l'architecture de l'application est construite de manière à donner la priorité aux données de la base de données Z, en tenant compte de la taille des écrans et des performances des assistants électroniques personnels.

L'application offre une fonction de recherche évoluée permettant de trouver dans la base de données Z les informations en fonction des attributs d'un champ ; la sélection peut être effectuée par fiche et par champ, auquel on donne une caractéristique. Des sélections multiples sont possibles. Lorsque la recherche est terminée, l'utilisateur peut naviguer dans la fiche des éléments trouvés en les sélectionnant.

Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. On peut en particulier utiliser d'autres outils logiciels que ceux qui ont été cités à titre d'exemples non limitatifs dans la présente description. Par ailleurs, les équipements mobiles concernés ne sont pas limités aux seuls assistants personnels et peuvent présenter toutes formes et caractéristiques permettant de recevoir et d'exploiter des applications mobiles.

Claims (23)

1. REVENDICATIONS 1. Procédé pour générer une application sur un équipement mobile, ladite application étant prévue pour traiter (i) des informations issues d'une première base de données (X) accessible au sein d'un système d'informations et contenant un ensemble de données structurées, et (ii) des informations saisies à partir dudit équipement mobile, caractérisé en ce qu'il comprend les étapes suivantes : une étape pour extraire de la première base de données (X) des données cibles destinées à ladite application. une étape pour préparer lesdites données cibles en un sous-ensemble structuré de données enrichies constituant une seconde base de données (Y), une étape pour transférer tout ou partie du contenu de ladite seconde base de données (Y) dans des moyens de stockage de données au sein dudit équipement mobile ou connectés audit équipement mobile, et une étape pour interpréter les données ainsi transférées de manière à construire dynamiquement l'application sur l'équipement mobile.
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de préparation comprend un enrichissement des données en les dotant de nouveaux attributs.
3. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que l'étape de préparation comprend un enrichissement fonctionnel de la seconde base de données
4. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la première base de données (X) est préexistante
5. 5. Procédé selon l'une des revendications de 1 à 3, caractérisé en ce qu'il comprend en outre une étape préalable pour créer la première base de données (X).
6. 6. Procédé selon l'une des revendications de 1 à 3, caractérisé en ce que la première base de données (X) résulte de la fusion d'une base préexistante et d'au moins une base créée à cet effet.

   <Desc/Clms Page number 16>
7. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une étape pour sélectionner au sein de la seconde base de données (Y) un ensemble de données prévues pour être transféré sur l'équipement mobile et constituer une troisième base de données (Z).
8. 8. Procédé selon la revendication 7, caractérisé en ce que l'étape de transfert est également agencée pour synchroniser les contenus respectifs de la seconde base de données (Y) et de la troisième base de données (Z).
9. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une interprétation dynamique de la structure de la première base de données X résidant dans le système d'informations et des données qu'elle contient.
10. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce que les données soient transférées et traitées depuis l'une des bases de données (X, Y, Z) selon les protocoles de communication ODBC.
11. 11. Procédé selon la revendication 10, caractérisé en ce que l'étape de sélection comprend en outre une interprétation dynamique de la structure de la base de données Y selon les protocoles de communication ODBC.
12. 12. Procédé selon l'une des revendications précédentes, mis en oeuvre pour générer des applications sur un ensemble d'équipements mobiles à partir d'un système d'informations central.
13. 13. Système pour générer une application sur un équipement mobile, ladite application étant prévue pour traiter (i) des informations issues des bases de données (X) accessibles au sein d'un système d'informations et contenant un ensemble de données structurées, et (ii) des informations saisies à partir dudit équipement mobile, ce système mettant en oeuvre le procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend : - des moyens pour extraire de la première base de données (X) des données cibles destinées à ladite application,

    <Desc/Clms Page number 17>

    des moyens pour préparer lesdites données cibles en un sous-ensemble structuré de données enrichies constituant une seconde base de données (Y), des moyens pour transférer tout ou partie du contenu de ladite seconde base de données (Y) dans des moyens de stockage de données au sein dudit équipement mobile ou connectés audit équipement mobile, et des moyens pour interpréter les données ainsi transférées de manière à construire dynamiquement l'application sur Il équipement mobile.
14. 14. Système selon la revendication 13, caractérisé en ce qu'il comprend en outre des moyens pour sélectionner au sein de la seconde base de données (Y), un ensemble de données prévues pour être transférées sur ledit équipement mobile, de façon à constituer une troisième base de données (Z).
15. 15. Système selon la revendication 14, caractérisé en ce qu'il comprend en outre des moyens pour synchroniser les contenus de la seconde base de données Y et de la troisième base de données (Z).
16. 16. Système selon l'une des revendications 13 à 15, caractérisé en ce que les moyens d'extraction et de préparation sont fournis sous la forme d'un poste de contrôle connecté au système d'informations et accessible par un utilisateur dudit système.
17. 17. Système selon l'une des revendications 14 à 15, caractérisé en ce que les moyens de sélection sont fournis sous la forme d'un poste de sélection connecté au système d'informations.
18. 18. Système selon l'une quelconque des revendications 13 à 17, caractérisé en ce que les données transférées dans des moyens de mémoire au sein de l'équipement mobile ou connectés audit équipement mobile comprennent un module terminal coopérant avec des moyens logiciels résidants dans ledit équipement mobile et des données de la seconde base de données (Y).
19. 19. Système selon la revendication 18, caractérisé en ce que le module terminal comprend les moyens d'interprétation dynamique.

    <Desc/Clms Page number 18>
20. 20. Système selon l'une des revendications 18 ou 19, caractérisé en ce que le module terminal comprend en outre une ou plusieurs librairies allouées dynamiquement pour répondre à des règles fonctionnelles spécifiques des utilisateurs.
21. 21. Application d'un système selon l'une quelconque des revendications 13 à 20, pour la génération dynamique d'applications sur un terminal mobile ou un parc d'équipements mobiles.
22. 22. Application d'un système selon l'une quelconque des revendications 13 à 20, pour la mise à jour ou l'enrichissement de produits logiciels diffusés sur un ensemble de terminaux, mobiles ou fixes, à partir d'une plate-forme unique.
23. 23. Application d'un système selon l'une quelconque des revendications 13 à 20, pour délivrer des contenus personnalisés à des détenteurs d'équipements mobiles.