Brevet FR2828611A1 — publié le 20030214

PROCEDE POUR TRANSFERER DES DONNEES PERSONNALISEES DANS UN APPAREIL DE SERVICE La présente invention concerne un procédé de transfert de données personnalisées dans un appareil de service au moyen d'un serveur de gestion à distance. La présente invention concerne plus particulièrement un procédé pour transférer des fichiers personnalisés dans un téléphone d'un réseau de téléphonie publique. De tels fichiers personnalisés sont plus particulièrement destinés à faire fonctionner des modules propriétaires, tel qu'un module sécurisé pour cartes de paiement (SAM), un microprocesseur équipant un validateur pour pièces de monnaies ou encore tout autre organe présent dans un téléphone public et requérant des données spécifiques pour fonctionner. Un réseau de téléphonie publique se compose de téléphones publics répartis sur un territoire donné. Les téléphones publics sont connectés à un réseau de communication, constitué par exemple par le réseau téléphonique commuté PSTN (acronyme anglo-saxon pour Public Switching Telephone Network), avec lequel ils communiquent au moyen d'un modem. Ce réseau bien entendu pourrait être d'un autre type (ISDN, GSM, Internet,...). Un réseau de téléphonie publique, comporte généralement un (ou plusieurs) ordinateur central ou serveur de gestion, ci-après appelé PMS (acronyme du terme anglo-saxon Payphone Management System"), permettant à l'opérateur du réseau d'opérer la supervision des différents téléphones de son réseau. Ce PMS, qui est connecté au réseau téléphonique commuté, a notamment pour fonction d'échanger avec le parc de téléphones publics des données. Les téléphones publics communiquent périodiquement au PMS un rapport d'activité détaillant le nombre et montant des transactions, etc. Ils communiquent également sous forme d'alarmes, l'éventuelle survenue d'un événement (panne, acte de vandalisme, etc.) nécessitant l'intervention d'un agent de maintenance. Le PMS a, quant à lui, pour fonction de transférer vers les téléphones publics des fichiers, des tables de tarifs ou encore des mises à jour de programmes faisant fonctionner les microprocesseurs des téléphones, mises à jour améliorant les programmes déjà en place ou bien encore introduisant de nouvelles prestations pour les usagers. Aujourd'hui, les transferts de fichiers entre les téléphones 10 et le PMS sont des opérations rigides, lourdes en temps et donc coûteuses. Ainsi, un téléphone public qui télécharge des fichiers doit être basculé en mode hors service et ne peut être utilisé par les usagers, tout le temps d'une opération qui peut durer plusieurs heures compte tenu de la taille actuelle des programmes et des données à charger. De plus, chaque nouvelle campagne de téléchargement nécessite une programmation complexe du PMS prenant en compte la nature et taille des fichiers à transférer. Par ailleurs, si pendant longtemps les téléphones publics étaient tous identiques quant à leur programmation de sorte que le PMS se limitait à télécharger les mêmes données vers tous les téléphones, cela tend aujourd'hui à évoluer. Ainsi les téléphones publics intègrent de plus en plus de modules rapportés qui nécessitent des programmations personnalisées. A ce titre on peut citer les modules SAM (Secure Access Module). Ces modules consistent dans des cartes à puce miniatures satisfaisant au standard GSM 11. 11. Ces cartes SAM ont un contacteur entrées/sorties (I/O pad) répondant à la norme ISO (Cnet) des cartes à puces. L'utilisation de telles cartes SAM dans les téléphones à pour objet d'exécuter des tâches spécifiques telles que des opérations d'identification, de vérification de mot de passe, de gestion d'application financières de porte-monnaie électronique mettant en oeuvre des algorithmes et des données confidentielles que les organismes gestionnaires propriétaires ne souhaitent pas diffuser et donc incorporer directement au circuit électronique du téléphone. Ces cartes SAM contiennent donc des informations confidentielles et sont délivrées par les opérateurs (bancaires, etc. ) aux opérateurs des réseaux de téléphonie publique ou au fabricants de téléphones publics, à charge pour ces derniers de les introduire dans les téléphones pour pouvoir exécuter sur ces appareils des applications spécifiques tel que le débit/crédit d'un porte-monnaie électronique. Chaque carte SAM est distincte et comporte notamment des codes secrets qui lui sont spécifiques. On peut encore citer les dispositifs validateurs de pièces de monnaie qui comportent des données de programmation spécifiques définies par leur constructeurs selon des caractéristiques de fabrication de chaque appareil. Les calculateurs de ces différents modules peuvent avoir besoin de recevoir de nouvelles données de programmation, telles que de nouvelles cartographies de paramètres ou des mises à-jour de programmes, comme par exemple celles nécessaires pour le passage à la monnaie unique européenne l'Euro de validateurs initialement programmés dans une monnaie différente. Ces nouvelles données à transférer dans les modules des téléphones sont généralement individualisées et doivent donc être chargées téléphone par téléphone, ce qui représente un travail très conséquent dès lors que le parc d'appareils est important. Par ailleurs ces données sont généralement élaborées par les fabricants des modules et les transferts successifs de ces données vers le gestionnaire du parc de téléphonie publique puis vers les téléphones publics sont des opérations complexes. La présente invention vise donc à remédier à ces inconvénients en simplifiant et en rationalisant le transfert de données personnalisées vers des appareils de service tels que des téléphones publics. Le procédé selon l'invention concerne le transfert des données d'un appareil de service, tel qu'un téléphone public, à un ordinateur central à distance, tel qu'un serveur de gestion, l'appareil de service étant apte à communiquer les données à l'ordinateur par l'intermédiaire de moyens de transmission appropriés. Le procédé selon l'invention concerne le transfert de données personnalisées dans un appareil de service depuis un ordinateur central à distance, l'appareil de service étant apte à communiquer avec l'ordinateur central par l'intermédiaire de moyens de transmission appropriés. Selon l'invention, le procédé est caractérisé en ce que le transfert des données personnalisées est commandé par l'ordinateur central à la réception d'un identifiant correspondant communiqué par l'appareil de service à l'ordinateur à distance. Selon une autre caractéristique du procédé objet de la présente invention, les données personnalisées sont destinées à faire fonctionner le microprocesseur d'un module personnalisé équipant l'appareil de service tel qu'un module SAM ou encore un validateur de monnaie, ces données personnalisées comprenant des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans ledit microprocesseur. Selon une autre caractéristique du procédé objet de la présente invention, il comporte les étapes suivantes : l'appareil de service ouvre une session de communication avec l'ordinateur à distance ; l'appareil de service fournit alors l'identifiant nécessaire à identifier le module personnalisé ; l'ordinateur extrait l'identifiant et l'associe dynamiquement à une extension unique connue de lui-même, afin de créer un nom de fichier (fichier préalablement créé par exemple par le fabricant du module et placé sur un serveur FTP propriété du fabricant du module) l'ordinateur transmet alors à l'appareil de service des instructions (localisation, nom de fichier...) quant aux données personnalisées devant être transférées et chargées dans le module. Selon une autre caractéristique du procédé objet de la présente invention, les communications entre l'ordinateur et l'appareil de service se font en utilisant le protocole de communication TCP/IP. Selon une autre caractéristique du procédé objet de la présente invention, les données personnelles transitent entre l'appareil de service et un serveur FTP où sont préalablement stockées les informations confidentielles devant être téléchargées dans l'appareil de service. Selon une autre caractéristique du procédé objet de la présente invention, l'adresse du serveur FTP est communiquée à l'appareil de service par l'ordinateur lors de chaque transfert. Selon une autre caractéristique du procédé objet de la présente invention, les informations personnelles à transférer sont stockées dans le serveur FTP sous la forme d'un fichier dont le nom est constitué de l'association dudit identifiant et d'un code ou extension approprié. Selon une autre caractéristique du procédé objet de la présente invention, lesdites instructions données par l'ordinateur central à l'appareil de service quant aux données personnalisées devant être transférées et chargées dans le module, consiste à l'ordre de télécharger depuis un serveur FTP approprié le fichier formé de l'association dudit identifiant et d'une extension prédéterminée. Selon une autre caractéristique du procédé objet de la présente invention, l'appareil de service est un téléphone public et l'ordinateur central un serveur de gestion. Selon une autre caractéristique du procédé objet de la présente invention, le serveur FTP est directement géré et mise à jour par le fabricant du module personnalisé. On comprendra mieux les buts, aspects et avantages de la présente invention, d'après la description donnée ci-après d'un mode de réalisation de l'invention, présenté à titre d'exemple non limitatif, en se référant au dessin annexé, dans lequel : la figure 1 est une vue schématique d'un réseau de téléphonie publique utilisé pour la mise en oeuvre du procédé selon l'invention. Seuls ont été figurés les éléments du réseau de téléphonie publique et de son environnement qui sont nécessaires à la compréhension de l'invention. Sur la figure 1, on a représenté un réseau 1 de téléphonie publique. Ce réseau comprend un parc de téléphones publics 10 (un même parc peut comprendre de plusieurs dizaines à plusieurs milliers de téléphones, voire plusieurs dizaines de milliers, suivant la couverture territoriale du réseau). Les téléphones 10 permettent aux usagers d'effectuer des communications téléphoniques, en utilisant un réseau téléphonique approprié référencé 2. Ce réseau téléphonique 2 est de type commuté analogique PSTN (Public Switching Telephone Network) ou de type commuté numérique ISDN (Integrated Services Digital Network). Ce réseau 2 peut également être constitué par un réseau de radiotéléphonie mobile et ce, quelle que soit sa nature : GSM, CDMA, TDMA, AMPS, D-AMPS, ou encore par le réseau Internet ou plus généralement par tout réseau de communication apte à transmettre des données (X25, Ethernet,..) ainsi que par toute combinaison de tels réseaux. Ces téléphones publics 10 peuvent être également adaptés pour accéder à des serveurs d'informations ou de fourniture de services du Web et de l'Internet, ainsi qu'à des serveurs d'informations ou de fourniture de services résidant sur des réseaux privés. De tels accès permettent à l'opérateur exploitant le réseau 1, de proposer aux usagers une large palette de services, allant par exemple et à titre non limitatif, de la lecture de leurs courriers électroniques à la consultation d'informations locales (listes des médecins de gardes de la zone du téléphone public, etc.). Bien évidemment l'invention n'est pas limitée aux téléphones publics offrant de tels accès à l'Internet et à des serveurs privés. Les téléphones publics 10 sont, de façon connue, des terminaux conçus spécialement pour leur utilisation en site public ou semipublic, tels que la rue, ou semi-publics, tels que des centres commerciaux, des aéroports, halls d'hôtels, restaurants, magasins, etc. Ils présentent donc des spécificités en terme d'éléments constitutifs et de logiciels, de consommation énergétique, d'ergonomie, d'utilisation, etc., qui sont bien connus en eux-mêmes et ne seront pas détaillés plus avant. Ainsi de façon classique chaque téléphone public 10 comprend donc, un certain nombre d'éléments particuliers, inhérents à un téléphone public, en particulier pour l'ergonomie. On trouve notamment des organes de visualisation et de saisie de données, comme un écran 11 et un clavier 12 à touches. Chaque téléphone public 10 comporte un microprocesseur principal gérant le fonctionnement du téléphone ainsi que des microprocesseurs secondaires faisant fonctionner des modules électroniques spécifiques tel qu'un validateur de pièces de monnaie ou encore un module SAM destiné à gérer une carte de paiement électronique de type porte-monnaie électronique. Certains de ces microprocesseurs secondaires tels ceux du SAM ou du validateur nécessitent des données personnalisées pour fonctionner. Comme données personnalisées, on pourra citer à titre d'exemple non limitatif, pour le module SAM, des clés secrètes de sécurisation ou un algorithme de calcul, pour le validateur, la mise à jour de paramètres permettant d'accepter une nouvelle pièce de monnaie ou la mise à jour d'un algorithme interne. Le microprocesseur principal du téléphone public 10 met notamment en oeuvre des logiciels permettant d'échanger et de représenter les informations selon des formats spécifiques mieux adaptés à son ergonomie, bien que fonctionnant selon les principes des liens hypermédia. Chaque téléphone public 10 est en effet, adapté pour communiquer avec un serveur 5 encore appelé PMS (acronyme anglosaxon de Payphone Management System") dédié au fonctionnement et à la gestion du réseau de téléphonie publique 1. Le PMS 5 a pour fonction d'échanger avec le parc de téléphones publics 10 des informations concernant leur fonctionnement et plus généralement le fonctionnement du système de téléphonie publique. En particulier, le PMS 5 gère les sessions d'initialisation des téléphones publics et établit des données statistiques à partir des informations reçues des téléphones publics 10 (alarmes, compteurs d'exploitation...). Les téléphones publics 10 et le PMS 5 sont munis de moyens appropriés de supervision et de réception/émission d'informations, ces moyens qui sont en eux-mêmes connus ne seront pas décrits plus en détail. Ces moyens de supervision et de réception/émission sont chargés d'organiser les échanges d'informations entre les téléphones publics 10, le PMS 5 et des serveurs FTP 41,42, 43 dont les rôles seront détaillés ci-dessous, et en particulier de contrôler des transferts de données ou logiciels, entre les téléphones publics 10 et les serveurs FTP. Entre autres fonctions, le PMS 5 transfère vers les téléphones publics 10, les fichiers nécessaires au fonctionnement de leurs microprocesseurs principaux et secondaires, tels que des tables de tarifs, des paramètres de configuration (comme le type de numérotation, les caractéristiques de la ligne...), des listes d'opposition ou de surveillance des moyens de paiement utilisés, un logiciel, des algorithmes de sécurisation, des clés de calcul secrètes, des caractéristiques physiques ou magnétiques de pièces de monnaie... Les téléphones publics 10 transmettent de leur côté, des informations relatives à leur utilisation, à savoir un rapport journalier comportant des données relatives aux transactions effectuées, au trafic, un rapport d'alarmes qui permet de signaler au PMS 5 la survenue d'incidents ou des atteintes à leur intégrité, comme une panne sur le lecteur de cartes ou un combiné arraché, de manière à prévoir l'intervention d'un agent de surveillance, un fichier de statut caractérisant le contenu du téléphone (telles que les indications des différentes versions de programmes utilisées par le microprocesseur), etc. Pour faciliter les échanges de données, on utilise des serveurs 41,42, 43 spécifiquement conçus et adaptés au transfert de fichiers, appelé FTP (pour File Transfer Protocol). A partir de commandes reçues par le PMS 5, chaque téléphone public 10, qui intègre une entité FTP client, va se connecter au FTP requis et télécharger ou télédécharger les fichiers appropriés. De préférence, les téléphones publics 10 se connectent à un serveur PROXY 6, servant d'interface de communication entre les téléphones publics 10 et le PMS 5. Les fonctions du PROXY 6 seront plus précisément détaillées ci-après. Par ailleurs, pour permettre la connexion aux différents serveurs et notamment au PROXY 6, au PMS 5 ou aux FTP, les téléphones 10 sont équipés de protocoles de communication TCP/IP conformes aux recommandations techniques de l'IETF ( Internet Engineering Task Force ). Le PROXY 6 combine plusieurs fonctions. Une première fonction consiste à orienter les requêtes des téléphones publics 10, suivant la nature de ces requêtes, vers les serveurs correspondants. Il s'agit là d'une fonction de re-routage qui permet de ne stocker et de ne mettre à jour la liste des adresses des serveurs susceptibles d'être appelés par les téléphones 10 que dans le PROXY 6 et non dans chacun des terminaux téléphoniques 10, ces derniers n'ayant alors besoin que de connaître la seule adresse du PROXY 6. Cette disposition facilite considérablement les opérations de maintenance du réseau de téléphonie 1. Ainsi, pour communiquer avec le PMS 5, il suffit à un téléphone d'adresser un message au PROXY 6, message dont le contenu, par exemple téléphone public numéro N demandant une connexion pour initialisation , suffit à être interprété par le PROXY 6 comme un message destiné au PMS 5. A charge alors pour le PROXY 6 de trouver dans ses mémoires, l'adresse IP du PMS 5 et de lui transmettre le message. Une seconde fonction consiste, quand cela est nécessaire, à traduire les données ou instructions émises par les téléphones 10 au format des serveurs destinataires. Ainsi en cas de connexions à l'Internet et au Web, il s'agit de traduire le protocole utilisé par les téléphones publics 10 dans le protocole approprié (http, RMI, pop3...), et inversement pour transférer les informations du Web et de l'Internet vers les téléphones 10. Une autre fonction du PROXY 6 est de contrôler la syntaxe des requêtes émises par les téléphones 10 avant retransmission et autoriser ainsi des accès authentifiés au réseau plus en arrière (sécurité). Une autre fonction est d'établir des sessions d'échange d'informations fiables et authentifiées qui consiste par exemple à identifier de façon certaine les téléphones 10 lors d'un échange d'informations avec les serveurs, ou encore à encrypter les données afin de sécuriser la communication en cas de besoin. Une autre fonction du PROXY 6 est de piloter et réguler les échanges d'informations réalisés via des transferts de fichiers standards et conformes aux protocoles Internet. Le PROXY 6 a également pour fonction de diriger les requêtes des téléphones publics vers des serveurs de secours notamment en cas d'indisponibilité d'un serveur et assurer ainsi une redondance d'architecture. Ainsi, dans l'hypothèse où le PROXY 6 se trouve inaccessible par suite notamment d'opérations de maintenance, il est alors possible de diriger les comptes-rendus journaliers des téléphones publics 10 correspondants vers un autre serveur de gestion alors disponible. Ce basculement d'un serveur vers un autre étant alors totalement transparent pour les téléphones publics 10 qui n'ont pas ainsi à gérer eux-mêmes des adresses de secours mais seulement l'adresse du PROXY 6. La redondance du PROXY 6 lui-même est également possible évitant des ruptures de communication en cas de panne constatée. De façon pratique, le PROXY 6, peut être constitué d'un ordinateur de type PC fonctionnant sur Windows NT (marque déposée) ou encore Linux, etc. Toute requête de connexion à un serveur parvient sur le port d'entrée de l'ordinateur qui est écouté en permanence par le PROXY 6, puis est redirigé vers un port de travail. La requête est ensuite analysée par une application logicielle, par exemple en langage Java (marque déposée) permettant le contrôle et l'établissement d'une session au sens protocolaire du terme. Une interface standard ( socket ) est alors ouverte et la requête est émise vers le serveur de destination, et inversement. Bien évidemment, le mode de réalisation illustré n'a été donné qu'à titre d'exemple et n'est absolument pas limitatif de l'ensemble des solutions pouvant être mise en oeuvre grâce à la présente invention. Ainsi, le PROXY 6, le PMS 5 et tout ou partie des serveurs FTP, au lieu d'être des machines séparées comme sur la figure 1, peuvent être regroupés dans un seul ordinateur de type PC par exemple. Le réseau de téléphonie publique 1 et les différents éléments qui le composent ayant été présenté. Nous allons maintenant détailler la méthode utilisée pour transférer des données entre le PMS 5, les serveurs FTP et les téléphones 10. Chaque téléphone 10 initie la connexion au PMS 5 par un message de type CONNECT généré grâce à des programmes spécifiques mis en oeuvre par les microprocesseurs équipant le téléphone 10. Le processus de connexion d'un téléphone au PMS 5, ainsi que celui utilisé pour transférer des données ou encore les protocoles de communication utilisés sont connus en eux-mêmes (et normalisés) et ne seront pas détaillés plus avant. L'événement déclenchant la connexion du téléphone 10 au PMS 5 peut être de différents types. La connexion peut être initiée manuellement par un agent de maintenance par exemple lors de l'installation d'un nouveau téléphone 10 dans le réseau 1. La connexion peut être déclenchée automatiquement suite par exemple à la survenue d'une alarme (monnayeur plein, panne, vandalisme, etc.), alarme générée par des programmes de surveillance appropriés. La connexion peut également être déclenchée automatiquement pour des rapports d'activité générés par des programmes de supervision appropriés rapports fournissant des statistiques sur l'activité du téléphone 10 et destinés à l'exploitant du réseau 1 afin d'améliorer le fonctionnement de ce dernier. Ces programmes de supervision peuvent éditer leur rapport d'activité à des dates et des heures prédéterminées ou bien encore à des instants définis par le PMS 5. Le téléphone peut également se connecter au PMS 5 suite à la demande expresse de ce dernier qui a donné l'ordre lors d'un appel précédent au téléphone 10 de se connecter pour un motif donné : par exemple pour le téléchargement de fichiers. Ce message de connexion CONNECT N comporte essentiellement les informations suivantes : - l'identifiant du téléphone 10, par exemple son numéro d'appel, ; - le type du téléphone 10, c'est-à-dire son code produit ; - le type de session, c'est-à-dire le contexte de l'appel : télécollecte (rapport d'activité), téléchargement (transfert de fichier vers le téléphone, en général il s'agit là d'un ordre préalable donné par le PMS 5), alarmes, etc. ; - une signature authentifiant ce téléphone 10, cette signature peut par exemple être obtenue par cryptage au moyen d'un algorithme de cryptologie de type DES (Data Encryption Standard) ou de tout autre type (RSA, etc.). - le ou les identifiant (s) des microprocesseurs secondaires dans la mesure où ces derniers sont personnalisés et bien sûr présents : SAM, validateur,... ; ces identifiants sont récupéré (s) juste avant l'établissement de la connexion par des moyens appropriés Le téléphone 10 comporte des moyens appropriés lui permettant de récupérer automatique les identifiants des différents microprocesseurs secondaires afin d'inclure ces informations dans son message de connexion au PMS 5. Ceci se fera par le biais de programmes appropriés permettant l'intérogation de ces différents microprocesseurs de manière à récupérer leur identifiant respectif. Le téléphone 10 dispose ainsi d'une liste de cessions types qui définissent à priori la raison de l'appel du téléphone 10. En général et à l'exception des alarmes, cet appel a été programmé lors d'une session précédente Le PMS 5 qui reçoit cet appel CONNECT , procède tout d'abord à son analyse et entre autres l'extraction des données d'identification puis vérifie l'authenticité de cet appel et si tel est bien le cas, renvoie un message d'acceptation ACCEPT qui comprend en autres données : la date et l'heure courante afin de procéder à une resynchronisation entre les deux appareils ainsi que l'heure et la date du prochain appel programmé. Le PMS 5 adresse ensuite une première demande de travail à réaliser. Cette demande de travail est principalement de trois types : ordre DOWNLOAD de transfert de fichiers d'un FTP vers le téléphone 10, ordre UPLOAD de transfert de fichiers du téléphone 10 vers un FTP et ordre DISCONNECT d'arrêt de la communication. De préférence les ordres de transfert de fichier sont formulés en utilisant le protocole suivant : Pour le chargement de fichiers : ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. cess avec : ftp//demande d'ouverture de cession FTP, ici à titre d'exemple ; - uu : nom de l'utilisateur ; - pw : mot de passe, le nom et le mot de passe servent à opérer la connexion sur le FTP ; @163. 285.6. 45 : adresse IP du FTP où télécharger les fichiers ; - ? 21 : le numéro du port TCP du service requis (ici FTP) ; - upload : indique le répertoire destinataire (localisation) associé à un nom de fichier comme suit : 123456 : identifiant du téléphone 10 récupéré dans le CONNECT" (dynamique) ; 05 : type du téléphone 10 récupéré dans le CONNECT (dynamique) ; time (HH : MM : SS) : heure courante permettant d'identifier de manière unique un fichier, évitant ainsi des conflits liés à l'éventuelle allocation d'un même identifiant à plusieurs téléphones, cess : identifiant unique du fichier à transférer (par exemple 02 pour un fichier comportant des transactions). upload/123456-OS-time. cess"définit donc à la fois le répertoire où doit être copié le fichier cess et le nom du fichier attribué. Pour le déchargement de fichiers : ftp ://uu : pw@163. 285.6. 45 ? 21/download/work/aa-bbb-ccc- ddd. ee avec : ftp//demande d'ouverture de cession FTP, ici à titre d'exemple ; uu : nom de l'utilisateur ; pw : mot de passe, le nom et le mot de passe servent à opérer la connexion sur le serveur FTP ; @163. 285.6. 45 : adresse IP du serveur FTP où télédécharger les fichiers ; - ? 21 : le numéro du port TCP du service requis (ici FTP) ; - download : indique le répertoire racine source (localisation) dans lequel on trouvera des sous- répertoires associés aux objets logiciels (paramètres, table de tarif, publicité...) : - work : sous-repertoire en clair (pour améliorer la lisibilité des fichiers) contenant un type d'objet précis (table de tarif, publicité, paramètres) ; aa-bbb-ccc-ddd. ee : nom du fichier à transférer Chaque fichier, dédié au fonctions propres du téléphone public, à transférer du FTP choisi vers le téléphone 10 reçoit un nom selon une syntaxe déterminée. Par exemple, chaque fichier peut recevoir un nom du type suivant"aa-bbb-ccc-ddd. ee" où : "aa"est un numéro à deux chiffres désignant le type de téléphone w o considéré ; "bbb"est un numéro à trois chiffres désignant la version du fichier ; "ccc"est un numéro à trois chiffres désignant la révision du fichier ; "ddd"est un numéro à trois chiffres désignant l'extension du fichier ; "ee"est une suite de deux caractères alphanumériques désignant le fichier proprement dit identifié par type ( 21 pour une table de paramètres). downioad/work/aa-bbb-ccc-ddd. ee définit ainsi le répertoire, le sous-répertoire et le nom du fichier à rapatrier. Chaque fichier aa-bbb-ccc-ddd. ee concerne un élément particulier de l'ensemble des ressources logicielles des téléphones 10. En effet, à l'intérieur des mémoires du microcontrôleur équipant les circuits électroniques (ou hardware) de chaque téléphone 10, sont donc stockés l'ensemble des données et des programmes formant l'ensemble des ressources logicielles (ou software) nécessaires au bon fonctionnement du téléphone 10. Selon le mode de réalisation décrit, ces données et programmes sont répartis en au moins trois groupes distincts d'objets : les logiciels, les tables de paramètres et les tables de tarifs. Cette liste est bien évidemment non limitative et peut être augmentée selon les fonctionnalités des téléphones (publicité, média...). Un tel découpage en trois types d'objets qui vise à simplifier le fonctionnement du réseau par l'opérateur et notamment le maniement du PMS 5, n'est bien entendu nullement limitatif de la présente invention laquelle s'applique encore même si les données et programmes ne sont pas différentiées selon des groupes distincts. Bien évidemment, chaque groupe distinct d'objet est formé d'un certain nombre de fichiers. Chaque fichier correspond à un découpage modulaire c'est-à-dire qu'il ne traite que d'une fonctionnalité donnée ou que d'un nombre limité de fonctionnalités. Ainsi, les logiciels se décomposent en plusieurs dizaines de modules logiciels parmi lesquels on peut citer à titre d'exemple : un module de sécurisation de ligne téléphonique, un module de gestion des pièces de monnaie (si le téléphone accepte les pièces), un module de gestion des cartes de paiement, un module de gestion du combiné, un module de gestion de l'écran, un module de gestion des taxations reçues de la ligne, un module de gestion de l'énergie, un module de gestion du modem, etc. Ainsi, parmi les tables de paramètres figurent les caractérisations du réseau téléphonique auquel est raccordé le téléphone 10, les autorisations d'accès à certains services, les différentes polices de langue utilisées pour l'affichage du téléphone : français, anglais, allemand, espagnol ou encore arabe, chinois, russe, etc. Cette modularité des fichiers vise à permettre des interventions les plus précises et plus rapides, notamment pour les opérations de téléchargement. Ainsi, lorsqu'une nouvelle version d'un logiciel est mise à jour, il est plus facile de ne charger dans les centaines voire les milliers de téléphones concernés que cette nouvelle version plutôt que de relancer le téléchargement de l'ensemble des logiciels y compris de ceux qui n'ont pas évolué. Bien entendu les fichiers à transférer du téléphone 10 vers le FTP correspondant peuvent si nécessaires adopter la même syntaxe. En général les fichiers à transférer du téléphone 10 vers le FTP sont des fichiers de résultats (status, rapport d'activité, alarme, etc. ), ils peuvent donc toutefois adopter une syntaxe différente de celle des fichiers à charger dans les téléphones 10. Les ordres de transfert de fichier émis par le PMS 5 à destination des téléphones 10 peuvent comporter une seule instruction et se succéder séquentiellement selon la séquence suivante : UPLOAD 1 ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. 01 UPLOAD 2 ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. 02 UPLOAD 3 ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. 03 Un ordre peu également comporter plusieurs instructions : UPLOAD ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. 01 ftp ://uu : pw@163. 285.6. 45 ? 21/upload/123456-05-time. 02 ftp ://uu : pw@163. 285. 6. 45 ? 21/upload/123456-05-time. 03 ......... En outre, d'autres fichiers, dédiés aux fonctionnements propres des microprocesseurs secondaires (SAM, validateur de monnaie...), à transférer d'un FTP donné vers le téléphone 10, reçoivent un nom selon une syntaxe appropriée. Par exemple, chaque fichier peut recevoir un nom du type suivant"IdentifiantModule. ee" où : e"Identifiant~Module"est l'identifiant du microprocesseur secondaire, communiqué par le téléphone 10 au PMS 5 lors de la connexion (numéro de série, nom,...) ; e"ee"est un code ou extension formée d'une suite de deux caractères alphanumériques désignant le fichier proprement dit identifié par type ( 21 pour une table de paramètres). Après avoir reçu un ordre de type UPLOAD ou DOWNLOAD , le téléphone 10 ouvre une cession FTP avec le FTP dont l'adresse lui a été notifiée (ici le FTP serveur dédié à la mise à jour des microprocesseurs/mémoires secondaires propriété du fabricant du module). La connexion au FTP en parallèle à la cession courante établie avec le PMS 5 via le PROXY 6. Le téléphone exécute ensuite le transfert de fichier (s) demandé auprès du (ou des) serveur (s) FTP qui lui a été notifié. Une fois le transfert du ou des fichiers achevé (s), le téléphone adresse un message d'acquittement par lequel il confirme au PMS 5 que le travail a été bien ou mal fait. Puis il se met en attente d'un nouvel ordre. En cas de non-réception d'un nouvel ordre après un laps de temps prédéterminé, le téléphone coupe la communication. Cette mise à jour des microprocesseurs/mémoires secondaires sera bien sûr désirée par l'opérateur et une fonction permettant l'activation du téléchargement ou téléchargement sera prévue sur le PMS 5. Une telle stratégie de communication entre le PMS 5 et les téléphones 10, de type maître esclave : le PMS 5 ordonne les téléphones exécutent, offre une très grande souplesse en matière de transferts de fichiers, puisque rien n'est figé. Les sessions de communication entre les téléphones 10 et le PMS 5 sont ainsi adaptables au gré des besoins. Par exemple, le PMS 5 peut profiter de l'appel de chaque téléphone 10 pour son rapport d'activité quotidien (encore appelé télécollecte) pour opérer le téléchargement d'une mise à jour de programme... Par exemple, lors de l'initialisation d'un nouveau téléphone 10 au réseau de téléphonie publique 1, l'agent de mise en service va demander systématiquement certaines informations liées à la configuration du téléphone 10 (par exemple un fichier de configuration) et ce à travers le lancement d'une session dédiée. En retour, le PMS pourra non seulement transférer le fichier demandé (ou organiser son transfert) mais également obtenir d'autres fichiers en retour de type table de tarif active, une table de tarif passive, une table de paramètres, une liste noire, une liste grise, un logiciel, etc. De même, lors d'une session de télécollecte du rapport journalier d'activité, le PMS 5 pourra non seulement récupérer les fichiers des transactions, les compteurs d'exploitation et les alarmes mais également il pourra télécharger en retour une table de tarif active, une table de tarif passive, une table de paramètres, une liste noire, une liste grise, un logiciel, un fichier personnalisé à destination d'un microprocesseur secondaire (SAM, validateur de monnaie, etc.) récupéré auprès d'un serveur FTP propriété du fabricant du module correspondant, etc. Il est important de noter que les différents serveurs 41,42, 43,5 et 6 peuvent être sur des réseaux de communication différents. La présente invention permet donc de s'affranchir de manière aisée des réseaux et de distribuer au mieux les serveurs. Selon un mode particulier de réalisation de l'invention, le premier ordre reçu par un téléphone 10 de la part du PMS 5 concerne le transfert d'un fichier encore appelé STATUS précisant les références de l'ensemble ou des principaux fichiers constituant ses ressources logicielles. Cela permet ultérieurement au PMS 5, en cas d'éventuel dysfonctionnement de déterminer les différentes versions de logiciels utilisés par le téléphone 10. Dans les échanges entre le PMS 5 et les téléphones 10, le PMS 5 est toujours décisionnaire quant aux fichiers transférés, c'est le maître. De part l'architecture décrite, le PMS 5 est à même sur analyse du contexte précis d'appel de chaque téléphone 10, de demander à ce dernier un travail donné, modifiable et adaptable librement et facilement notamment en fonction des souhaits de l'exploitant du réseau 1. Un telle souplesse est par ailleurs sans incidence sur les téléphones 10 qui fonctionnent en mode esclave". La liste des fichiers à transférer dans un sens ou dans un autre se trouve donc communiquer dynamiquement aux téléphones 10 par le PMS 5 et ce après identification de la connexion, au travers de requêtes précises : CONNECT, ACCEPT, UPLOAD, DOWNLOAD, DISCONNECT. Les téléphones ne connaissent donc pas à l'avance les fichiers à transférer, c'est uniquement le PMS 5 qui choisit les fichiers à transférer. Pour ce qui concerne le fonctionnement des serveurs FTP qui va maintenant être plus particulièrement détaillé, on distinguera deux situations distinctes : le serveur FTP 41 qui est sous le contrôle directe de l'opérateur du réseau de téléphonie publique et les serveurs 42 et 43 qui appartiennent aux fabricants des modules personnalisés équipant chaque téléphone 10 tel que le SAM ou encore le validateur de monnaie. Pour ce qui est de l'utilisation du FTP 41 et notamment du chargement sur le FTP 41 des fichiers à transférer ensuite vers les téléphones 10, différentes solutions sont possibles. On peut par exemple choisir la solution suivante. Ces fichiers, qu'il s'agisse de tables de paramètres, de tables de tarifs ou encore de logiciels ou de tout autre objet dédié au téléphone public lui-même, ont été préparés par le biais d'outils spécifiques sont chargés dans le PMS 5 par exemple au moyen d'un CD ROM, d'une disquette ou de tout autre support lisible par le PMS ou bien encore au moyen d'un réseau de communication adapté qu'il soit de type privé ou encore public comme l'Internet ou le Web. Les fichiers à charger dans les téléphones et dédiés au téléphone public lui-même, sont accompagnés d'au moins un script correspondant. Un script est un fichier textuel comprenant une série de lignes d'instructions destinées à être exécutées par le PMS 5. Un script comprend notamment l'arborescence ou répertoire où seront localisés les fichiers, la liste de ces fichiers ainsi que des instructions comme des interruptions ou déconnexions. Par choix, on peut regrouper l'ensemble des fichiers à transférer sur un seul script ou bien encore utiliser plusieurs scripts si nécessaire, par exemple en regroupant les fichiers selon leur type. Dans ce dernier cas, on peut alors avoir un script"tables de tarifs", un script"tables de paramètres", un script"logiciels". Considérons, le cas d'un script spécifique par nature d'objet. Chaque script est alors identifié par un nom de type xxxx. yyy où : "xxxx"est le nom du script et". yyy" le type de fichiers considérés : par exemple". cli" pour les logiciels,". tt" pour les tables de tarifs,". tp" pour les tables de paramètres, etc. Un script contient par exemple des lignes de codes du type : groupl. dir = soft/v02rOOe02/groupl (groupl nom du répertoire de destination d'un premier lot de fichiers) group l. file 1 = 03-002-000-001. 40 (fichier à charger) ; S-disconnect here group2. dir = soft/v02rOOe02/group2 (group2 : répertoire de destination d'un second lot de fichiers) group2. filel = 03-002-000-001. 74 (fichier à charger) ll Ce script et les éventuels autres scripts concernant d'autres types de fichiers, sont donc copiés dans le PMS 5 en même temps que les fichiers listés. Une fois les scripts et les fichiers implantés dans le PMS 5, on déclenche le processus de téléchargement des fichiers dans les téléphones et ce, non sans avoir préalablement sélectionné les téléphones concernés. En effet, il se peut que seule une partie des téléphones gérés par le PMS 5 nécessitent le chargement des fichiers. Ce processus de chargement comporte trois étapes : le téléchargement des fichiers dans le FTP 41, la programmation des différents téléphones concernés et le chargement des fichiers dans les téléphones à partir du FTP 41. Plusieurs méthodes peuvent être adoptées pour la réalisation de ces trois étapes. Soit les étapes du processus de téléchargement sont clairement séparées : les fichiers sont d'abord chargés par le PMS 5 dans le FTP 41 sitôt le lancement du processus de téléchargement, les téléphones 10 sont ensuite programmés par le PMS 5 les uns après les autres au fur et à mesure de leur connexion pour récupérer les fichiers dans le FTP 41, enfin les téléphones 10 transfèrent les fichiers du FTP 41 dans leurs microprocesseurs. Soit les étapes du processus de téléchargement sont liées et les fichiers sont chargés dans le FTP 41 en même temps que s'exécute le traitement du premier téléphone de la liste (lancement de la session de téléchargement courante). Quel que soit le processus adopté, le déroulement de ces différentes étapes s'appuie au niveau du PMS 5 sur les scripts. A notre que pour opérer la programmation d'un téléphone, le PMS 5 exécute non pas le script original mais une copie faite spécifiquement pour ce téléphone. Ainsi, il est possible d'agir sur le script original, par exemple en modifiant le nom d'un fichier à transférer, sans perturber les opérations de téléchargement en cours. Ainsi, puisque tous les fichiers à transférer sont stockés dans un répertoire clairement identifié d'un serveur FTP, il est possible de transférer vers les téléphones 10 seulement le nom de ce répertoire sans les noms de fichiers, les téléphones transférant alors l'ensemble des fichiers du répertoire. Pour ce qui est des serveurs FTP 42 et 43, les fichiers dédiés à un module personnalisé (SAM, validateur de monnaie, etc.), préparés euxaussi par le biais d'outils spécifiques, restent stockés sur les serveurs FTP 42,43 des fabricants, sous la responsabilité de ces derniers. Considérons par exemple les validateurs de monnaie, chaque validateur comporte des données spécifiques de fabrication qui sont déterminées par le fabricant et gérées par ce dernier dans ses bases de données. Lors de la mise en oeuvre d'un nouveau programme comme par exemple lors du passage à l'Euro, le fabricant élabore donc pour chaque validateur le programme adapté tenant compte des données de fabrication. Ce programme est alors stocké dans le FTP 43 du fabricant en utilisant la syntaxe précitée à savoir IdentifiantModule. ee Lors du chargement de ces programmes dans les téléphones publics associés, il suffit alors au PMS lors de la campagne de téléchargement d'indiquer l'adresse du serveur 43 pour que les téléphones 10 aillent chercher les fichiers dans ce serveur. Ainsi, il n'est nullement besoin de transférer au préalable ces fichiers du fabricant de validateur vers le gestionnaire du parc de téléphonie publique. Les fichiers Identifiant-Module. es à charger dans les serveurs FTP 42,43 appartenant à des tiers, quant à eux ne se trouvent aucunement liés à un script préalablement construit qui nécessiterait la saisie d'un grand nombre de références à savoir l'ensemble des fichiers Identifiant-Module. ee . Au contraire, l'ordre de chargement des fichiers contenus dans les FTP 42,43 se fait de façon dynamique téléphone par téléphone directement après analyse du contenu transmis dans la demande CONNECT . Cette façon de procéder permet la mise à jour automatique et souple d'un très grand nombre de données personnalisées, sans alourdir pour autant le système ou imposer une action pénible à l'opérateur qui souhaite faire la mise à jour de l'ensemble. Considérons, à titre d'exemple non limitatif, le cas d'un parc de 5000 téléphones publics équipés de 5000 modules SAM (Security Access Module) destinés à l'utilisation de porte-monnaie électronique de type Moneo ou autre. L'établissement financier gestionnaire de ces modules SAM décide de mettre à jour les clés sécuritaires spécifiques à chaque module qui sont destinées au chiffrement des données échangées entre les cartes porte-monnaie et le module SAM. L'établissement financier élabore donc pour chacun des 5000 SAM un fichier spécifique contenant le nouveau jeu de clés. Chaque fichier est stocké dans un serveur FTP 42 appartenant à l'organisme financier selon la syntaxe"XXXXXXX. OC"où XXXXXXX"est le code d'identification de chacun des SAM ou identifiant, et où OC est le code correspondant au fait qu'il s'agit d'un fichier relatif aux clés sécuritaires. Le PMS est alors programmé pour lors de la connexion des téléphones ces derniers reçoivent l'ordre de charger les nouvelles clés. Cela se traduit par l'enchaînement des étapes suivantes : . Lors de l'appel de chaque téléphone 10, le PMS 5 extraie de la demande CONNECT", les éléments permettant l'identification du SAM à savoir le code XXXXXXX w que lui a communiqué le téléphone 10 ; e puis, le PMS 5, au travers d'une simple commande de traitement inscrit dans son programme, construit alors l'association d'une part du nom du fichier à récupérer à savoir l'identifiant du SAM XXXXXXX auquel il a joint la terminaison". OC", d'autre part un ordre DOWNLOAD précisant notamment la localisation du serveur FTP 42 où est stocké le fichier XXXXXXX. OC)) et ce, pour permettre la récupération effective de l'objet : DOWNLOAD ftp ://uu : pw@163. 285.6. 45 ? 21/download/keys/ XXXXXXX. OC.. avec : ftp//demande d'ouverture de cession FTP, ici à titre d'exemple ; uu : nom de l'utilisateur ; pw : mot de passe, le nom et le mot de passe servent à opérer la connexion sur le serveur FTP du serveur tiers ; @163. 285.6. 45 : adresse IP du serveur FTP 42 où télédécharger les fichiers ; ? 21 : le numéro du port TCP du service requis (ici FTP) ; download : indique le répertoire racine source (localisation) dans lequel on trouvera des sous-répertoires associés aux fichiers : keys : sous-repertoire en clair (pour améliorer la lisibilité des fichiers) contenant un type d'objet précis (clés sécuritaires) ; - XXXXXXX. OC nom du fichier à transférer (préalablement placé sur le c) * le ou les fichiers une fois récupérés, un ordre DISCONNECT est généré de manière à interrompre la session courante. Bien sûr la réciproque peut-être vraie et l'on pourrait aisément imaginer le dépôt (et non la récupération) de fichiers spécifiques à chaque microprocesseurs secondaires à des fins d'analyse et ce vers le FTP serveur FTP42, propriété du fabricant du module. Le fichier récupéré, celui-ci est ensuite transféré par des moyens appropriés du téléphone 10 dans le module SAM correspondant. Ainsi donc, et à titre d'exemple, le PMS peut mettre à jour 5000 téléphones publics en téléchargeant des données spécifiques au module SAM de chacun et ce, de manière extrêmement rapide et simple. Les données à transférer demeurent chez l'établissement financier lequel peut se trouver sur un autre continent par rapport au réseau téléphonique publique et n'ont donc pas à être acheminées d'abord vers le gestionnaire du réseau. L'établissement financier n'a qu'à indiquer l'adresse du serveur FTP sur lesquels ont été stocké les programmes. Ensuite la programmation du PMS 5 se limite à reprendre l'identifiant du module SAM que lui communique chaque téléphone, d'y ajouter la terminaison OC et de répondre d'aller charger le fichier ainsi nommé dans le serveur FTP42. Le PMS 5 en particulier n'a pas à gérer de table référençant pour chaque numéro de téléphone 10, les identifiants des microprocesseurs secondaires nécessitant des données personnelles. La méthode selon l'invention offre par ailleurs une grande souplesse dans le transfert de fichier, puisque ce transfert peut se faire module par module voire fonctionnalités par fonctionnalités, ce qui supprime les contraintes de l'art antérieur, où les fichiers étaient uniques et globaux. Cette méthode permet de standardiser le transfert des fichiers en proposant un mode de gestion unique et général pour l'ensemble des objets à transférer quelle que soit leur nature ou leur nombre. Ce mode de gestion dynamique par lequel les téléphones exécutent des transferts selon des instructions émises par le PMS 5 et décrivant le travail est donc sans impact ni sur les téléphones ni sur le PMS 5, alors que selon l'art antérieur une procédure de traitement devait être développée spécifiquement pour chaque transfert. Bien évidemment, le mode de réalisation illustré n'a été donné qu'à titre d'exemple et n'est absolument pas limitatif de l'ensemble des solutions pouvant être mise en oeuvre grâce à la présente invention. Ainsi le réseau des téléphones publics décrit précédemment peut être remplacé par n'importe quel réseau d'appareils de service ayant un besoin de transmettre des informations notamment à un serveur de gestion, par exemple des horodateurs, des distributeurs automatiques ou encore des terminaux bancaires. Ainsi, si dans les modes de réalisation décrits ci-dessus, le téléphone 10 initie la communication pendant laquelle va s'opérer le transfert de fichiers, cela ne saurait être limitatif de la présente invention. Une telle communication peut donc être également initiée par le PMS 5. Dans ce cas, lors de la connexion le PMS 5 informe le téléphone 10 qu'une cession d'un type donné de transfert de fichier va débuter. En réponse à cet ordre, le téléphone 10, répond par un message CONNECT du type précité et la suite de la cession se déroule selon le déroulement que décrit ci-dessus ( ACCEPT puis échange d'ordres UPLOAD , DOWNLOAD"ou DISCONNECT"et d'acquittements). REVENDICATIONS 1/Procédé pour transférer des données personnalisées dans un appareil de service (10) depuis un ordinateur central à distance (5), l'appareil de service (10) étant apte à communiquer avec ledit ordinateur central (5) par l'intermédiaire de moyens de transmission (2,41, 42,43, 6) appropriés, caractérisé en ce que le transfert desdites données personnalisées est commandé par ledit ordinateur central à la réception d'un identifiant correspondant communiqué par ledit appareil de service (10) à l'ordinateur à distance (5). 2/Procédé pour transférer des données selon la revendication 1, caractérisé en ce que lesdites données personnalisées sont destinées à faire fonctionner le microprocesseur d'un module personnalisé équipant l'appareil de service (10) tel qu'un module SAM ou encore un validateur de monnaie, ces données comprenant des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans ledit microprocesseur. 3/Procédé pour transférer des données selon la revendication 2, caractérisé en ce qu'il comporte les étapes suivantes : - ledit appareil de service (10) ouvre une cession de communication avec ledit ordinateur à distance (5) ; - ledit appareil de service (10) fournit alors l'identifiant nécessaire à identifier ledit module ; ledit ordinateur (5) transmet alors audit appareil de service (10) des instructions quant aux données personnalisées devant être transférées et chargées dans ledit module. 4/Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que les communications entre ledit ordinateur (5) et ledit appareil de service (10) se font en utilisant le protocole de communication TCP/IP. 5/Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites données transitent entre un serveur FTP (42,43) où sont préalablement stockées les informations confidentielles devant être téléchargées dans l'appareil de service, et ledit appareil de service (10). 6/Procédé pour transférer des données selon la revendication 5, caractérisé en ce que l'adresse dudit serveur FTP (42,43) est communiquée audit appareil de service (10) par ledit ordinateur (5) lors de chaque transfert. 7/Procédé pour transférer des données selon l'une quelconque des revendications 5 à 6, caractérisé en ce que lesdites informations sont stockées dans le serveur FTP (42,43) sous la forme d'un fichier dont le nom est constitué de l'association dudit identifiant et d'une extension prédéterminée. 8/Procédé pour transférer des données selon les revendications 3 et 7, caractérisé en ce que lesdites instructions quant aux données personnalisées devant être transférées et chargées dans ledit module consiste à l'ordre de télécharger depuis un serveur FTP approprié le fichier formé de l'association dudit identifiant et d'une extension prédéterminée. 9/Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit appareil de service est un téléphone public (10) et en ce que ledit ordinateur central est un serveur de gestion (5). 10/Procédé pour transférer des données selon la combinaison des revendications 2 et 5, caractérisé en ce que ledit serveur FTP est directement géré et mise à jour par le fabricant dudit module personnalisé.