Brevet FR2914524A1 — publié le 20081003

Système de télécommunication pour applications déployées La présente invention concerne un système de télécommunication hétérogène dans lequel des applications sont déployées. Le système de télécommunication peut comprendre des matériels hétérogènes aussi divers que des plateformes dédiées à des applications, des serveurs, des terminaux et des cartes à puce, dans lesquels des composants logiciels d'une application sont dispersés. Actuellement une application est souvent déployée de la manière suivante. Le composant coeur de l'application est installé dans une plateforme ou serveur dédié et des composants logiciels de l'application sont dispersés par exemple dans un terminal spécifique, appelée borne électronique de lecture accessible au public, et dans un terminal et/ou carte à puce d'usager. Par exemple, un serveur de gestion de cartes de crédit est en communication avec des terminaux bancaires dédiés à des opérations bancaires et n'accueillant que des cartes de crédit. Selon un autre exemple, un serveur de gestion de cartes de fidélité pour des achats dans un réseau de magasins ou de boutiques est en communication avec des bornes d'actualisation de points de fidélité et n'accueillant que des cartes de fidélité. Les applications dédiées précédentes ont été déployées respectivement pour des parcs de bornes spécialisées homogènes le plus souvent monoapplicatives et à travers des architectures de système de télécommunication particulières sans se soucier de la portabilité des applications et de la mobilité des usagers. Les composants logiciels de ces applications installées dans les bornes ne sont adaptés qu'à l'interface graphique et plus généralement qu'à l'interface homme-machine du terminal d'usager et qu'à la connexion de dispositifs périphériques particuliers. Ces inconvénients font obstacle à une installation en masse de bornes électroniques sur un territoire donné. Par ailleurs les usagers utilisent de plus en plus de cartes à puce pour diverses applications de service. Ils doivent alors conserver ces nombreuses cartes à puce et recourir à différentes bornes de lecture correspondant respectivement à différentes applications. Pour pallier les inconvénients ci-dessus, un système de télécommunication comprenant une plateforme et une entité d'usager communicante dans chacune desquelles est installé au moins un composant respectif d'une application déployée, ainsi qu'au moins une borne électronique apte à communiquer avec une entité d'usager, est caractérisé en ce qu'il comprend un serveur qui pilote ladite au moins une borne pour qu'elle soit apte à interconnecter le serveur à l'entité d'usager, ledit serveur supportant un composant de l'application apte à interagir avec ledit au moins un composant d'application installé dans la plateforme et à interagir avec ledit au moins un composant d'application installé dans l'entité d'usager à travers une borne. Le système de télécommunication de l'invention présente une architecte satisfaisant le déploiement de nombreuses applications dont des composants peuvent être chargés dans les entités d'usager. Les applications sont déployées dans un parc de bornes électroniques homogènes et à travers une architecture de système de télécommunication favorisant la portabilité des applications et la mobilité des usagers. Les bornes sont banalisées et donc transparentes à l'intelligence des applications implémentées dans le serveur pilotant les bornes, dit serveur pilote. Quels que soient les composants des applications dans une entité d'usager communicante, tel le qu'un terminal mobile de réseau cellulaire ou une carte à puce, l'entité d'usager est adaptée à communiquer avec toutes les plateformes dédiées aux applications grâce au serveur pilote qui s'adapte aux diverses applications qui sont susceptibles d'être sollicitées dans l'entité d'usager, une borne n'étant utilisée que pour relayer des messages relatifs aux applications entre le serveur et l'entité d'usager. Grâce à la banalisation des bornes, l'invention incite chaque application à être utilisée par un nombre croissant d'entités d'usager conformément à l'intérêt des fournisseurs des applications et à disséminer les bornes sur tout un territoire. La mobilité des usagers est facilitée pour accéder aux divers services offerts par les applications sur tout le territoire. L'invention est ainsi orientée à l'encontre du développement de bornes spécifiques de lecture connues qui supportent des composants logiciels propriétaires, en conférant un caractère universel aux bornes. Selon une réalisation particulière de l'invention, afin de permettre à l'usager d'une entité d'acquérir des droits sur une application depuis n'importe où avant d'utiliser le service dispensé par l'application, le système comprend un autre serveur supportant ledit au moins un composant de l'application apte à interagir avec le composant d'application dans la plateforme et le composant d'application dans une entité d'usager pour acquérir des droits sur l'application. Ledit autre serveur est par exemple relié par internet aux entités d'usager sans recourir aux bornes électroniques situées dans les lieux où des services d'applications peuvent être utilisés. Ledit autre serveur et le serveur pilotant les bornes peuvent être connectés pour que ledit autre serveur transmette des droits sur une application acquis par l'entité d'usager vers le serveur pilotant les bornes. L'invention a aussi pour objet le serveur, dit serveur pilote, dans un système de télécommunication comprenant une plateforme et une entité d'usager communicante dans chacune desquelles est installé au moins un composant respectif d'une application déployée, ainsi qu'au moins une borne électronique apte à communiquer avec une entité d'usager. Le serveur pilote est caractérisé en ce qu'il comprend: - un moyen pour piloter ladite au moins une borne (BO) pour qu'elle soit apte à interconnecter le serveur à l'entité d'usager, et - un moyen d'exécution supportant au moins un composant de l'application apte à interagir avec ledit au moins un composant d'application installé sur la plateforme et à interagir avec ledit au moins un composant d'application installé dans l'entité d'usager à travers une borne. De manière à ce que l'entité d'usager accède à plusieurs applications déployées depuis n'importe quelle borne électronique, le moyen d'exécution peut supporter plusieurs composants de plusieurs applications déployées chacune en outre en au moins un composant supporté par une plateforme et au moins un composant supporté par l'entité d'usager. Les composants de deux applications ou plus supportés par le moyen d'exécution peuvent avoir en commun au moins un sous-composant applicatif. Le serveur pilote assemble ainsi des sous-composants logiciels communs à des applications avec au moins un autre sous-composant logiciel spécifique à une application en un composant de l'application. Le serveur pilote centralise tous les composants d'application pour traiter les requêtes et réponses échangées entre les plateformes et les entités d'usager. Les sous-composants logiciels communs aux applications dans le serveur favorisent le développement et l'implémentation de nouvelles applications et réduisent les coûts de construction de composants d'application dans le serveur. Les composants logiciels communs améliorent l'adaptabilité des applications aux divers supports d'exécution dans les entités d'usager notamment en ce qui concerne l'interface graphique d'usager. L'invention concerne aussi une borne électronique apte à communiquer avec une entité d'usager communicante dans un système de télécommunication comprenant une plateforme, au moins un composant d'une application déployée étant apte à être installé dans la plateforme et au moins un composant de l'application déployée étant apte à être installé dans l'entité d'usager. La borne électronique est caractérisée en ce qu'elle est comprend: - un moyen pour piloter ladite au moins une borne pour qu'elle soit apte à interconnecter le serveur à l'entité d'usager, et - un moyen d'exécution supportant au moins un composant de l'application apte à interagir avec ledit au moins un composant d'application installé sur la plateforme et à interagir avec ledit au moins un composant d'application installé dans l'entité d'usager à travers une borne. Aucune intervention n'est nécessaire sur le terrain où sont implantées les bornes. Les bornes selon l'invention pilotées par le serveur pilote sont identiques ou sensiblement aussi bien en matériel et en logiciel et réduites au minimum ce qui conduit à des économies considérables tant du point de vue de la fabrication que de l'exploitation et la maintenance des bornes électroniques subissant les manipulations des usagers. Selon une réalisation particulière de la borne électronique, elle comprend une interface sans contact pour couplage avec l'entité d'usager. L'interface sans contact permet l'utilisation en champ proche d'une entité d'usager aussi bien du type terminal mobile que du type carte à puce. Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre dans le serveur pilote de l'invention pilotant au moins une borne électronique, et à un programme d'ordinateur apte à être mis en oeuvre dans une borne électronique selon l'invention. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations de l'invention données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique d'un système de télécommunication dans lequel des applications sont déployées, selon une première réalisation de l'invention ; - la figure 2 est un bloc-diagramme schématique d'un serveur pilote dans le système de télécommunication ; - la figure 3 est un bloc-diagramme d'une borne électronique de lecture dans le système de télécommunication ; - la figure 4 est un bloc-diagramme schématique d'un système de télécommunication dans lequel des applications sont déployées, selon une deuxième réalisation de l'invention ; - la figure 5 est un bloc-diagramme schématique d'un serveur applicatif dans le système de télécommunication de la figure 4 ou 6 ; et - la figure 6 est un bloc-diagramme schématique d'un système de télécommunication dans lequel des applications sont déployées, selon une troisième réalisation de l'invention. Selon une première réalisation de l'invention, un système de télécommunication montré à la figure 1 comprend au moins une entité d'usager communicante personnelle portable TU, une plateforme de téléchargement PTC, au moins une plateforme d'application PA, un serveur pilote de borne SP et au moins une borne électronique de lecture BO. Selon un exemple auquel on se référera dans la suite de la description, une entité d'usager communicante est un terminal mobile d'usager TU desservi par un réseau d'accès cellulaire par exemple de type GSM ("Global System for Mobile communications" en anglais) avec un service GPRS ("General Packet Radio Service" en anglais), ou de type UMTS ("Universal Mobile Telecommunications System" en anglais). Le terminal mobile d'usager peut être un assistant numérique personnel communicant PDA ou un "Smartphone". L'entité d'usager communicante peut être aussi une carte universelle à circuit intégré UICC (Universal Integrated Circuit(s) Card) avec ou sans contact dans un terminal mobile d'usager, comme une carte dotée d'une application SIM (Subscriber Identity Module) lorsque le terminal est un mobile du type GSM ou GPRS, ou comme une carte dotée d'une application USIM (Universal Subscriber Identity Module) lorsque le terminal est un mobile fonctionnant en accès multiple à répartition par codes CDMA (Coded Division Multiple Access) par exemple du type UMTS (Universal Mobile Telecommunications System). Selon d'autres variantes, l'entité d'usager communicante est une carte à puce comme une carte de paiement, une carte de porte-monnaie électronique, une carte de santé, un passeport électronique, ou toute autre carte à microprocesseur pouvant communiquer avec un terminal fixe ou mobile. L'entité d'usager communicante peut être tout dispositif électronique personnel pouvant communiquer avec un serveur tel que le serveur pilote. En variante, l'entité d'usager communicante est l'ensemble constitué par une carte à puce, comme une carte UICC ou une carte additionnelle, et un mobile de réseau cellulaire associé à la carte à puce et offrant une interface homme-machine. La plateforme de téléchargement PTC de fournisseur de service, également appelée plateforme d'administration de terminaux mobiles d'usager OTA ("Over The Air"), gère le cycle de vie d'applications de service et la personnalisation des applications dans des terminaux mobiles d'usager. La plateforme PTC est destinée à échanger des requêtes et des réponses avec plusieurs des terminaux mobiles à travers un réseau de communication RC. Par exemple, le réseau RC peut comprendre un centre de messages courts ("Short Message Service Center" en anglais) et le réseau d'accès cellulaire des terminaux mobiles pour échanger avec celui-ci des messages courts, ou bien l'internet et le réseau d'accès cellulaire. La plateforme de téléchargement PTC est destinée à télécharger des composants applicatifs client CUAP1, comme des applets, relatifs à des applications API gérées par des fournisseurs de services et installées dans des plateformes d'application PA, sous le contrôle d'une plateforme PO gérée par l'opérateur du réseau d'accès des terminaux mobiles d'usager. Une application API selon l'invention est en général une application transactionnelle et composée de composants logiciels applicatifs qui sont répartis sur des sites différents. L'application API déployée selon l'invention comprend un composant applicatif COAP1 constituant le coeur de l'application et supporté par une plateforme d'application PA dédiée au moins à l'application, un composant applicatif C1AP1 supporté par l'unité centrale de traitement du serveur pilote SP et éventuellement dupliqué dans plusieurs serveurs pilotes s'ils existent, assurant des fonctions de base de l'application, et un composant applicatif CUAP1 supporté par chacun de terminaux mobiles associés à des usagers autorisés à utiliser l'application ou ayant décidé librement d'utiliser l'application. Le composant applicatif C1AP1 interagit avec les composants COAP1 et CUAP1 de l'application API. Un composant applicatif est une unité de traitement logiciel encapsulant des fonctionnalités propres quel que soit le contexte et pouvant être installé séparément. Le composant possède également des propriétés non-fonctionnelles qui représentent des aspects systèmes liés à l'implantation du composant, tels que transaction, sécurité, persistance, tolérance aux fautes, et qui sont variables en fonction du contexte et de l'application. La séparation entre propriétés fonctionnelles invariables et non-fonctionnelles variables permet d'exécuter le composant de manière différente sur des supports d'exécution. Le composant est également doté d'une interface de communication pour qu'il puisse coopérer avec d'autres composants internes ou externes au support d'exécution du composant. Dans la variante selon laquelle l'entité d'usager communicante est constituée par une carte à puce et un mobile de réseau cellulaire associé à la carte à puce du type carte UICC ou carte additionnelle, le mobile ou la carte à puce ne supporte qu'un composant applicatif CUAP1 de l'application, ou bien le composant applicatif CUAP1 est remplacé par deux composants applicatifs de l'application supportés respectivement par le mobile et la carte à puce. Selon la première réalisation de l'invention, le système de télécommunication comprend des plateformes d'application PA qui hébergent les composants logiciels COAP1 des premières applications de service API assurant les fonctions principales spécifiques des applications. Une plateforme d'application PA héberge une ou plusieurs applications de service API d'un fournisseur de service respectif. Comme montré à la figure 2, le serveur pilote SP comprend des interfaces de communication ISP PA et ISP BO et une unité centrale de traitement UCSP faisant office de support d'exécution d'un premier niveau applicatif des applications déployées API sous la forme des composants logiciels applicatifs ClAP1. Le serveur pilote SP pilote les bornes BO et joue le rôle de serveur applicatif par rapport aux terminaux mobiles d'usager TU et de client applicatif par rapport aux plateformes AP. Dans le serveur pilote SP montré à la figure 2 et également dans une borne de lecture BO montré à la figure 3 et un serveur applicatif SA montré à la figure 5 et décrit plus loin sont seulement représentés des blocs fonctionnels dont la plupart assurent des fonctions ayant un lien avec l'invention et peuvent correspondre à des modules logiciels et/ou matériels. L'interface de communication ISP BO est reliée à la borne de lecture BO et plus généralement à plusieurs bornes de lecture pour les piloter et ainsi les activer et désactiver à travers un réseau de télécommunication RT comprenant par exemple l'internet et des réseaux d'accès des bornes au l'internet, tels qu'un réseau de liaisons ADSL ("Asymmetric Digital Subscriber fine" en anglais) et/ou un ou plusieurs réseaux de liaisons de faible portée satisfaisant le label de certification WiFi ("Wireless Fidelity" en anglais). L'interface de communication ISP PA du serveur pilote SP et les plateformes d'application PA sont par exemple reliées par des liaisons sécurisées à travers l'internet. Le serveur pilote SP comprend également une base de données BDSP et une unité de routage URSP. Le serveur pilote SP n'établit des communications qu'avec des terminaux mobiles d'usager TU connectés préalablement à des bornes électroniques BO qui ont accepté de manière transparente une communication entre un terminal mobile d'usager et le serveur pilote. La base de données BDSP gère des assemblages de sous-composants pour former les composants applicatifs ClAP1. La base de données BDSP commande dans l'unité de routage URSP des interconnexions des composants applicatifs C1AP1 et des composants applicatifs CUAP1 sélectionnés dans les terminaux d'usager à travers l'interface ISP BO et les bornes BO et des interconnexions des composants C1AP1 et des composants COAP1 dans les plateformes PA à travers l'interface ISP PA. La base de données BDSP enregistre en association des adresses des bornes activées BO et de terminaux TU mis en communication et des identificateurs d'applications API sélectionnées dans les terminaux. Par exemple en dépendance du composant d'application activé CUAP1 dans un terminal d'usager, la base de données BDSP peut assembler des sous-composants logiciels applicatifs en un composant applicatif assemblé C1AP1 selon des règles prédéterminées de composition et configuration de l'application API correspondant au composant CUAP1. Une règle peut dépendre éventuellement du profil d'usager transmis par le terminal d'usager au début d'une connexion avec le serveur pilote et modifiant ainsi certains paramètres de l'application. Pour une application sélectionnée dans un terminal d'usager, c'est-à-dire pour le composant CUAP1 correspondant à cette application sélectionnée, la base de données BDSP assemble les fonctionnalités des sous-composants applicatifs en le composant C1AP1 pour être exécuté sur l'unité centrale UCSP, et contrôle notamment les descripteurs de ces sous-composants et les liens entre ces sous-composants. La base de données BDSP commande l'unité de routage URSP via les interfaces de communication des sous-composants applicatifs pour que des messages puissent être traités sélectivement par ces sous-composants applicatifs et acheminés depuis et vers la borne électronique en communication avec le terminal d'usager. Selon l'invention, un composant C1AP1 n'est pas installé notamment dans des bornes de diverses natures, mais est implémenté et centralisé dans l'unité centrale de traitement USCP du serveur pilote SP ce qui facilite le développement et l'implémentation de nouvelles applications. Dans le serveur pilote SP sont implémentés un ou plusieurs sous-composants utilisés en commun par les composants applicatifs C1AP1 d'au moins deux applications API ou plus. Par exemple, un sous-composant applicatif commun est destiné à adapter les interfaces homme-machine, appelées également interfaces d'usager, dans les terminaux d'usager a priori de types différents notamment pour la présentation de pages, aux applications déployées API respectivement sélectionnées par les usagers. Selon d'autres exemples, des sous-composants applicatifs communs à des composants applicatifs C1AP1 concernent notamment une identification d'usager, une gestion et une transmission de ticket, un paiement sécurisé par signature et certificat, une vérification de signature de données, et une procédure de sécurité selon des algorithmes de chiffrement et déchiffrement. Plus généralement, un ou plusieurs composants applicatifs communs et au moins un composant applicatif spécifique à une application API sélectionnée sont assemblées dans le serveur SP pour mettre en oeuvre l'application sélectionnée. Un composant applicatif désigne dans les réalisations décrites ci-après indifféremment un composant applicatif a priori indissociable dans une application déployée, ou un assemblage de sous-composants applicatifs dont certains peuvent être communs à plusieurs applications déployées et dont au moins un autre est spécifique à une application. Comme montré à la figure 3, une borne électronique BO comprend une interface sans contact ISC, une interface de réseau IR et une unité centrale de traitement UCBO équipée par exemple d'un microprocesseur et interconnectée aux interfaces. L'interface sans contact ISC et une interface sans contact similaire incluse dans un terminal d'usager TU assurent des communications en champ proche CCP lorsque le terminal est placé à quelques centimètres de la borne BO. Les interfaces sans contact similaires dans la borne BO et le terminal TU sont couplées par radiofréquence de l'ordre de la dizaine de mégahertz par exemple selon la technologie de marqueurs NFC ("Near Field Communication" en anglais) ou RFID ("Radio Frequency Identification" en anglais). La borne électronique BO est "simple" dans le sens qu'elle comprend un minimum de composants matériels et logiciels pour établir et maintenir une communication entre un terminal d'usager et le serveur pilote SP, et "universelle" dans le sens qu'elle n'est pas spécifique à une seule application et est indépendante de toute application déployée selon l'invention. Elle est ainsi transparente au contenu spécifique aux applications dans les messages échangés entre le serveur pilote et le terminal d'usager et fait office de passerelle entre ces derniers. La borne électronique BO est capable de communiquer à travers des sorties logiques SL avec des dispositifs périphériques Dl, D2 et D3 spécifiques à des applications API, AP2 et AP3, par exemple comme des caisses électroniques et des actionneurs de commande d'ouverture- fermeture de barrières et/ou portes d'accès de parking ou de portillons automatiques d'accès de salle. Optionnellement la borne de lecture BO comprend une interface homme-machine IHM mise à la disposition d'un usager dont l'entité communicante personnelle portable, comme une carte à puce, n'est pas un terminal doté d'une interface homme-machine incluant notamment un clavier et un écran. Selon la première réalisation montrée à la figure 1, une application déployée API hébergée principalement dans une plateforme d'application de fournisseur de service PA est relative par exemple à la fidélité d'usagers-clients à un réseau de magasins. Dans chaque magasin est installée au moins une borne électronique BO à proximité d'une ou plusieurs caisses électroniques constituant des dispositifs périphériques Dl pouvant être connectés à une sortie logique SL de la borne BO. Un terminal mobile d'usager TU a préalablement téléchargé le composant applicatif (applet) CUAP1 de l'application de fidélité déployée API auprès de la plateforme PIC. Pour comptabiliser des points de fidélité, l'utilisation de l'application de fidélité API déployée selon l'invention comprend des étapes E10 à E16. A l'étape E10, l'usager-client présente des produits à une caisse électronique Dl qui additionne les prix des produits en un total TT à payer. L'adresse ABO de la borne BO à proximité de la caisse électronique Dl, l'identificateur IAP1 de l'application de fidélité API et le total TT sont transmis via la borne BO au serveur pilote SP qui les mémorise. La base de données BDSP reconnait l'identificateur IAP1 et réveille le composant applicatif C1AP1 de l'application de fidélité déployée API dans le serveur SP. Le serveur SP active la borne BO désignée par l'adresse ABO pour être prête à communiquer avec un terminal d'usager TU, à l'étape E11. L'usager place le terminal TU à proximité de la borne activée BO afin que le terminal communique avec l'interface sans contact ISC pour établir une liaison en champ proche entre eux, à l'étape E12. Les interfaces IR et ISC dans la borne BO sont mises en relation de façon transparente au dialogue d'application entre le serveur pilote et le terminal pendant les étapes suivantes. L'usager sélectionne le composant CUAP1 de l'application de fidélité API dans un menu d'applications affiché sur le terminal TU, ou lorsque le terminal TU est notamment une carte à puce, le composant d'application de fidélité CUAP1 est réveillé par une requête transmise par le serveur SP et relayée par la borne activée BO. Le terminal TU transmet des données d'identification IDU de l'usager au serveur SP, à l'étape E13. La base de données BDSP mémorise les données d'identification IDU en les associant à l'adresse ABO de la borne BO et au total TT précédemment mémorisés. Le serveur SP élabore un message incluant les données d'identification IDU et le total TT précédemment mémorisé et les transfère vers la plateforme PA hébergeant l'application de fidélité API désignée par l'identificateur IAP1, à l'étape E14. Un canal logique est ainsi ouvert entre le terminal TU et la plateforme PA. A l'étape E15, l'application de fidélité API identifiée dans la plateforme PA vérifie que les données d'identification IDU correspondent à un usager-client ayant souscrit un contrat de fidélité et détermine un nombre de point de fidélité NPF en fonction du total TT. Un total de points de fidélité cumulé TPF associé aux données d'identification IDU est augmenté du nombre NPF. Le nombre de point de fidélité NPF et le total cumulé actualisé TPF associé aux données d'identification IDU sont transmis dans un message de réponse au serveur pilote suivant l'autre direction du canal logique. En fonction de l'adresse ABO associée aux données d'identification IDU, la base de données BDSP du serveur pilote dirige le nombre de points de fidélité NPF et le total cumulé TPF vers la borne BO qui les transmet au terminal TU dans lequel le composant CUAP1 reconnaît l'identificateur d'application IAP1 et les affiche, à l'étape E16. Selon une deuxième réalisation de l'invention illustrée à la figure 4, le système de télécommunication comprend des plateformes d'application PA qui hébergent des composants applicatifs COAP2 de deuxièmes applications deservice AP2 et en outre un serveur applicatif SA. Une deuxième application AP2 comprend également un composant applicatif C1AP2 dans le serveur pilote, un composant applicatif CUAP2 dans les terminaux d'usager TU et un composant applicatif C2AP2 dans le serveur applicatif SA. Le serveur applicatif SA gère l'interaction entre les composants applicatifs CUAP2 et C2AP2 et l'interaction entre les composants applicatifs C2AP2 et COAP2 pour acquérir des droits sur des services correspondant aux applications AP2 sollicitées par les usagers préalablement à leur utilisation. Le serveur SA joue le rôle de serveur applicatif par rapport aux terminaux mobiles d'usager TU et de client applicatif par rapport aux plateformes AP. Comme montré à la figure 5, le serveur applicatif SA peut présenter une architecture similaire à celle du serveur pilote SP et comprend une unité centrale de traitement UCSA faisant office de support d'exécution d'un premier niveau applicatif des applications déployées AP2 sous la forme des composants logiciels applicatifs C2AP2. Le serveur SA comprend également des interfaces de communication ISA PA et ISA TU, une base de données BDSA et une unité de routage URSA. L'interface de communication ISA PA est reliée aux plateformes d'application PA par exemple par des liaisons sécurisées à travers l'internet. Comme la plateforme de téléchargement PIC, l'interface de communication ISA TU du serveur applicatif SA peut communiquer avec les terminaux d'usager par exemple par le réseau de communication RC, comme l'internet et le réseau d'accès cellulaire des terminaux mobiles d'usager. Les applications AP2 sont déployées en outre premièrement sous la forme de composants applicatifs C2AP2 installés dans le serveur SA pour que les terminaux d'usager acquièrent au moins des droits sur des services dispensés par des applications sélectionnées, et deuxièmement sous la forme de composants applicatifs C1AP2 installés dans le serveur pilote SP pour que les droits acquis autorisent l'accès aux services sélectionnés par l'intermédiaire des terminaux d'usager. Pour certaines applications, plusieurs sous-composants applicatifs sont assemblés en un composant applicatif C2AP2 au moyen de la base de données BDSA dans le serveur SA. L'unité de routage URSA assure sous la commande de la base de données BDSP des interconnexions des composants applicatifs C2AP2 et des composants applicatifs CUAP2 sélectionnés dans les terminaux d'usager à travers l'interface ISA TU et des interconnexions des composants C2AP2 et des composants COAP2 dans les plateformes PA à travers l'interface ISA PA. Par exemple dans le serveur SA, un composant applicatif C2AP2 résulte de l'assemblage notamment d'un sous-composant de délivrance de ticket, d'un sous-composant d'adaptation d'interface homme-machine et d'un sous-composant de vérification de signature électronique. Les assemblages des sous- composants sont gérés par la base de données BDSA selon des règles prédéterminées de composition et configuration de l'application AP2. De manière similaire au serveur SP, un ou plusieurs sous-composants applicatifs peuvent être utilisés en commun par des composants C2AP2 d'applications sélectionnées par un usager. Par exemple, chaque fois qu'un terminal d'usager sollicite une application AP2, un sous-composant applicatif relatif à la présentation de pages adaptées au terminal d'usager et plus généralement à l'interface homme-machine dans le terminal d'usager est assemblé à d'autres sous-composants applicatifs relatifs à l'application sollicitée. Pour la deuxième réalisation, une application prédéterminée AP2 déployée selon l'invention est par exemple relative au stationnement d'un véhicule conduit par l'usager du terminal mobile TU dans un parking par acquisition d'une information, comme par exemple un ticket de parking. L'application AP2 est déployée sous forme de composants applicatif s C1AP2 et C2AP2 dans les serveurs SP et SA et d'un composant applicatif CUAP2 dans les terminaux d'usager. L'utilisation de l'application déployée AP2 comprend des étapes E20 à E25. A l'étape E20, l'usager connecte le terminal TU au serveur applicatif SA à travers le réseau RC en fonction de l'adresse saisie ou prémémorisée du serveur SA et sélectionne l'application de ticket de parking AP2 dans un menu d'applications ce qui active le composant applicatif CUAP2 qui requiert une communication avec le composant C2AP2 dans le serveur applicatif SA en lui transmettant l'identificateur IAP2 de l'application de ticket de parking AP2. L'interface homme-machine principalement graphique dans le terminal TU est adaptée à l'application sélectionnée AP2 par le sous-composant applicatif commun pour présentation de pages dans le serveur SA. Puis à l'étape E21, l'usager du terminal TU dialogue par le composant CUAP2 avec le composant applicatif C2AP2 de l'application de ticket de parking sélectionnée pour indiquer notamment des données de l'usager et/ou de son véhicule et d'identification IDP du parking et éventuellement du jour et de la durée de stationnement prévus. Si le parking est celui d'une entreprise, le serveur applicatif SA peut requérir un code d'accès personnel ou collectif à l'entreprise que l'usager doit saisir sur le terminal TU ou extraire de la mémoire du terminal TU pour le transmettre au serveur SA. Le composant C2AP2 dans le serveur applicatif SA établit un canal logique entre le terminal TU et la plateforme concernée PA pour que le composant COAP2 de la plateforme d'application concernée PA établisse un ticket de parking électronique TP et le transmette au terminal TU qui l'affiche à l'étape E22 via le serveur SA. Le terminal TU et la plateforme concernée PA mémorisent le ticket TP. Le serveur applicatif SA ne possédant aucun secret n'est pas capable de continuer la transaction entre le terminal TU et le serveur concerné PA pour autoriser l'entrée dans le parking. A l'étape ultérieure E23, en se présentant dans le véhicule devant une barrière d'entrée D2 du parking, l'usager positionne le terminal TU devant une borne BO qui est située à proximité de la barrière. Le terminal TU communique avec l'interface sans contact ISC de la borne pour établir une liaison en champ proche et la borne passe d'un état de veille à un état activé après signalement de la présence du terminal au serveur pilote SP. L'usager sélectionne dans le terminal l'application de ticket de parking et donc l'identificateur IAP2. Le composant CUAP2 communique à travers l'interface sans contact en champ proche ISC de la borne avec le composant C1AP2 dans le serveur pilote SP, comme aux étapes E12 et E13. A l'étape E24, le composant applicatif C1AP2 dans le serveur pilote SP commande la lecture du ticket de parking TP mémorisé dans le terminal TU et établi un canal logique entre le composant d'application ticket de parking COAP2 dans la plateforme AP2 et le composant d'application ticket de parking CUAP2 dans le terminal. A la réception du ticket de parking TP à l'étape E25, le composant COAP2 compare le ticket reçu et le ticket qui a été mémorisé à l'étape E22. Si les tickets comparés sont identiques, le composant COAP2 de la plateforme transmet une autorisation de levée de barrière d'entrée à travers le canal logique établi afin que le serveur SL commande par une sortie logique SL de la borne BO l'actionneur de la barrière d'entrée D2 et le véhicule de l'usager pénètre dans le parking, à l'étape E26. En variante, la transmission du ticket à l'étape E24 peut être agrémentée d'une signature électronique du ticket résultant de l'exécution d'un algorithme cryptographique par le composant CUAP2 dans le terminal et d'une vérification de cette signature par le composant COAP2 dans la plateforme. Ultérieurement à la sortie du véhicule du parking, des étapes analogues aux précédentes sont exécutées pour lever une barrière de sortie du parking. La levée de la barrière n'est autorisée qu'après des étapes de paiement du stationnement ou de validation d'un code d'abonnement en recourant au terminal TU et à une communication de celui-ci avec les composants C1AP2 et COAP2 via un couplage sans contact avec une borne BO à proximité de la barrière de sortie. Selon une troisième réalisation de l'invention montrée à la figure 6, pour mettre en oeuvre le procédé de déploiement de services, le système de télécommunication comprend les serveurs et plateformes selon la deuxième réalisation et des interfaces de communication ISP SA et ISA SP montrées aux figures 2 et 5 dans les serveurs SP et SA de manière à les connecter entre eux à travers l'internet par exemple. Pour la troisième réalisation, une application prédéterminée AP3 déployée selon l'invention est par exemple relative à la réservation de place de spectacle. L'application AP3 est déployée sous forme de composants applicatifs COAP3, C1AP3, C2AP3 et CUAP3 respectivement dans une plateforme PA, les serveurs SP et SA et les terminaux d'usager TU. L'utilisation de l'application déployée AP3 comprend des étapes E30 à E35. A l'étape E30, l'usager connecte le terminal TU au serveur applicatif SA à travers le réseau RC en fonction de l'adresse saisie ou prémémorisée du serveur SA et sélectionne l'identificateur IAP3 de l'application de réservation de place de spectacle AP3 dans un menu d'applications et ainsi active le composant applicatif CUAP3. Le composant applicatif CUAP3 requiert une communication avec le composant C2AP3 dans le serveur applicatif SA et lui transmet l'identificateur IAP2 de l'application de ticket de parking AP2. L'interface homme-machine principalement graphique dans le terminal TU est adaptée à l'application sélectionnée AP3 par le sous-composant applicatif commun pour présentation de pages dans le serveur SA. Puis à l'étape E31, l'usager du terminal TU dialogue par le composant CUAP3 avec le composant applicatif C2AP3 de l'application de réservation de place de spectacle sélectionnée pour que l'usager choisisse un spectacle déterminé et retienne des places pour celui-ci en renseignant des paramètres de réservation PR comme une date et une heure, un nombre de place et éventuellement des identificateurs de places disponibles. Le serveur applicatif SA requiert à travers le terminal TU également des paramètres PU de l'usager tels que nom, prénom et numéro de carte de crédit saisis sur le terminal. Le composant C2AP3 dans le serveur applicatif SA établit un canal logique entre le terminal TU et la plateforme concernée PA. Les paramètres de réservation PR constituant des droits acquis sur le service constitué par le spectacle et les paramètres d'usager PU sont transmis par le serveur applicatif SA à la plateforme d'application de réservation de place de spectacle concernée PA. Le composant COAP3 dans cette plateforme élabore un ticket de réservation de spectacle électronique TR en fonction des paramètres transmis et le transmet via le serveur applicatif SA au serveur pilote SP et au terminal TU qui mémorisent le ticket de spectacle, à l'étape E32. Puis ultérieurement, à une étape E33, l'usager présente le terminal TU devant une borne BO qui est par exemple située devant l'entrée de la salle du spectacle. Le terminal TU communique avec l'interface sans contact ISC de la borne pour établir une liaison en champ proche et la borne passe d'un état de veille à un état activé après signalement de la présence du terminal au serveur pilote SP. L'usager sélectionne dans le terminal le service de réservation de place de spectacle et ainsi l'identificateur IAP3 et le composant applicatif CUAP3. Le composant CUAP2 requiert une connexion avec le composant C1AP3 de l'application de réservation de place de spectacle électronique AP3 installé dans le serveur pilote SP à travers la borne activée BO. A l'étape E34, le composant applicatif C1AP3 commande la lecture du ticket de réservation TR mémorisé dans le terminal TU. Le composant applicatif C1AP3 compare le ticket de réservation lu dans le terminal TU et le ticket de réservation communiqué parle serveur SA et mémorisé dans le serveur pilote SP à l'étape précédente E32. Si les tickets de réservation comparés TR sont identiques, le composant applicatif P3AP3 télécommande par une sortie logique SL du serveur SP par exemple un actionneur d'ouverture-fermeture D3 d'un portillon automatique pour accéder à la salle de spectacle. Concomitamment, le serveur pilote SP transmet le ticket de réservation TR ainsi validé et consommé au composant COAP3 de la plateforme concernée PA pour débiter le compte bancaire de l'usager, à l'étape E35. En variante, la fin de l'étape E35 est supprimée et par suite le serveur pilote SP n'est pas mis en communication avec des plateformes d'application PA. L'opération de paiement est enregistrée dans le serveur SP et transmise en différée à un serveur bancaire. En variante des deuxième et troisième réalisations, les serveurs SP et SA sont réunis en un unique serveur de manière à réduire le coût du système de télécommunication selon l'invention. L'invention décrite ici concerne un système de télécommunication, un serveur pilotant des bornes électroniques et une borne électronique. Elle concerne aussi un programme d'ordinateur implémenté dans le serveur de l'invention pilotant au moins une borne électronique, et composé d'instructions qui, lorsque ledit programme est exécuté dans un processeur du serveur dont le fonctionnement est alors commandé par l'exécution du programme, réalisent une étape de pilotage de ladite au moins une borne pour qu'elle soit apte à interconnecter le serveur à l'entité d'usager, et une étape d'interaction pendant laquelle au moins un composant de l'application installée dans le serveur interagit à la fois avec ledit au moins un composant d'application installé dans la plateforme et avec ledit au moins un composant d'application installé dans l'entité d'usager à travers une borne. L'invention concerne aussi un programme d'ordinateur implémenté dans une borne électronique de l'invention apte à communiquer avec une entité d'usager communicante et composé d'instructions qui, lorsque ledit programme est exécuté dans un processeur de la borne électronique dont le fonctionnement est alors commandé par l'exécution du programme, réalisent une étape d'interconnexion une étape d'interconnexion apte à interconnecter un serveur apte à piloter au moins ladite borne à l'entité d'usager, cette interconnexion permettant des interactions entre au moins un composant de l'application installé dans le serveur et ledit au moins un composant d'application installé dans l'entité d'usager, ledit au moins un composant de l'application installé dans le serveur étant apte à interagir avec ledit au moins un composant d'application installé dans la plateforme. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur enregistré sur ou dans un support d'enregistrement lisible par un ordinateur et tout dispositif de traitements de données, adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention. Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon l'invention. REVENDICATIONS 1 - Système de télécommunication comprenant une plateforme (PA) et une entité d'usager communicante (TU) dans chacune desquelles est installé au moins un composant respectif (COAP1, CUAP1) d'une application déployée, ainsi qu'au moins une borne électronique (BO) apte à communiquer avec une entité d'usager (TU), caractérisé en ce qu'il comprend un serveur (SP) qui pilote ladite au moins une borne (BO) pour qu'elle soit apte à interconnecter le serveur (SP) à l'entité d'usager (TU), ledit serveur supportant un composant (ClAP1) de l'application apte à interagir avec ledit au moins un composant d'application (COAP1) installé dans la plateforme (AP) et à interagir avec ledit au moins un composant d'application (CUAP1) installé dans l'entité d'usager (TU) à travers une borne. 2 - Système conforme à la revendication 1, comprenant un autre serveur (SA) supportant au moins un composant (C2AP2) de l'application apte à interagir avec ledit au moins un composant d'application (COAP2) dans la plateforme (AP) et le composant d'application (CUAP1) dans l'entité d'usager (TU) pour acquérir des droits sur l'application. 3 - Système conforme à la revendication 2, dans lequel ledit autre serveur (SA) et le serveur (SP) pilotant les bornes (BO) sont connectés pour que ledit autre serveur transmette des droits sur l'application acquis par l'entité d'usager (TU) vers le serveur pilotant les bornes.35 4 - Serveur (SP) apte à être mis en oeuvre dans un système de télécommunication comprenant une plateforme (PA) et une entité d'usager communicante (TU) dans chacune desquelles est installé au moins un composant respectif (COAP1, CUAP1) d'une application déployée, ainsi qu'au moins une borne électronique (BO) apte à communiquer avec une entité d'usager (TU), caractérisé en ce qu'il comprend: - un moyen (ISP BO) pour piloter ladite au moins une borne (BO) pour qu'elle soit apte à interconnecter le serveur à l'entité d'usager (TU), et - un moyen d'exécution (UCSP) supportant au moins un composant (ClAP1) de l'application apte à interagir avec ledit au moins un composant d'application (COAP1) installé sur la plateforme et à interagir avec ledit au moins un composant d'application (CUAP1) installé dans l'entité d'usager à travers une borne. 5 - Serveur conforme à la revendication 4, dans lequel le moyen d'exécution (UCSP) supporte plusieurs composants (ClAP1) de plusieurs applications déployées chacune en outre en au moins un composant (COAP1) supporté par une plateforme (AP) et au moins un composant (CUAP1) supporté par l'entité d'usager (TU). 6 - Serveur conforme à la revendication 5, dans lequel les composants (ClAP1) de deux applications (API) supportés par le moyen d'exécution (UCSP) ont en commun au moins un sous-composant applicatif.35 7 - Borne électronique (BO) apte à communiquer avec une enti té d'usager communicante (TU) dans un système de télécommunication comprenant une plateforme (PA), au moins un composant (COAP1) d'une application déployée étant apte à être installé dans la plateforme et au moins un composant (CUAP1) de l'application déployée étant apte à être installé dans l'entité d'usager, caractérisée en ce qu'elle comprend des moyens aptes à interconnecter un serveur (SP) apte à piloter au moins ladite borne (BO) à l'entité d'usager (TU), cette interconnexion permettant des interactions entre au moins un composant (ClAP1) de l'application installée dans le serveur (SP) et ledit au moins un composant d'application (CUAP1) installé dans l'entité d'usager (TU), ledit au moins un composant (ClAP1) de l'application installé dans le serveur (SP) étant apte à interagir avec ledit au moins un composant d'application (COAP1) installé dans la plateforme (AP). 8 - Programme d'ordinateur apte à être mis en oeuvre dans un serveur (SP) apte à être mis en oeuvre dans un système de télécommunication comprenant une plateforme (PA) et une entité d'usager communicante (TU) dans chacune desquelles est installé au moins un composant respectif (COAP1, CUAP1) d'une application déployée, ainsi qu'au moins une borne électronique (BO) apte à communiquer avec une entité d'usager (TU), ledit programme comprenant des instructions de code qui lorsque le programme est exécuté, réalisent: une étape de pilotage de ladite au moins une borne (BO) pour qu'elle soit apte à interconnecter le serveur (SP) à l'entité d'usager (TU), et - une étape d'interaction pendant laquelle au moins un composant (ClAP1) de l'application installée dans le serveur interagit à la fois avec ledit au moins un composant d'application (COAP1) installé dans la plateforme (AP) et avec ledit au moins un composant d'application (CUAP1) installé dans l'entité d'usager à travers une borne. 9 - Programme apte à être mis en oeuvre dans une borne électronique (BO) apte à communiquer avec une entité d'usager communicante (TU) dans un système de télécommunication comprenant une plateforme (PA), au moins un composant (COAP1) d'une application déployée étant apte à être installé dans la plateforme et au moins un composant (CUAP1) de l'application déployée étant apte à être installé dans l'entité d'usager, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté, réalisent une étape d'interconnexion apte à interconnecter un serveur (SP) apte à piloter au moins ladite borne (BO) à l'entité d'usager (TU), cette interconnexion permettant des interactions entre au moins un composant (ClAP1) de l'application installé dans le serveur (SP) et ledit au moins un composant d'application (CUAP1) installé dans l'entité d'usager (TU), ledit au moins un composant (ClAP1) de l'application installé dans le serveur (SP) étant apte à interagir avec ledit au moins un composant d'application (COAP1) installé dans la plateforme (AP).