FR 2820261 A1 20020802 FR 0101343 A 20010130 PROCEDE DE TRANSFERT DE DONNEES ENTRE UN APPAREIL DE SERVICE ET UN DE GESTION A DISTANCE. La présente invention concerne un procédé de transfert de données entre des appareils de service et un serveur de gestion à distance. La présente invention concerne plus particulièrement un procédé de transfert de fichiers entre un serveur de gestion et les téléphones d'un réseau de téléphonie publique. 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 pour fonction d'échanger avec le parc de téléphones publics des données. Les téléphones publics communiquent régulièrement au PMS un rapport d'activité détaillant le nombre et montant des transactions, etc. Ils communiquent également sous forme d'alarme l'éventuelle survenue d'un événement (panne, acte de vandalisme, etc.) nécessitant l'intervention d'un agent de maintenance. Le PMS quant à lui transfère aux 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 bascule 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. Par ailleurs, 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. La présente invention vise donc à remédier à ces inconvénients en simplifiant et en rationalisant le transfert de données entre un serveur de gestion à distance et 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. Selon l'invention, le procédé pour transférer des données est caractérisé en ce que les données à transférer de l'appareil de service vers l'ordinateur à distance sont déterminées par l'ordinateur seul. Selon une autre caractéristique du procédé objet de la présente invention, les données sont produites par des moyens logiciels et matériels appropriés et correspondent à des fonctions de supervision et de contrôle du fonctionnement de l'appareil de service, chaque donnée devant être transférée audit ordinateur central à un rythme donné spécifique à la nature de la fonction à laquelle elle correspond. 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 cession de communication avec ledit ordinateur à distance ; - l'appareil de service fournit un code de session précisant audit ordinateur la nature des données qu'il souhaite transférer ; - l'ordinateur, s'étend assuré de l'authenticité de l'appel de l'appareil de service (contrôle syntaxique, par contrôle d'un code de secret, par contrôle de la gamme de produits, etc. ), transmet alors à l'appareil des instructions quant aux données devant être effectivement transférées. - l'appareil de service transfert alors en retour les données demandées par l'ordinateur. Selon une autre caractéristique du procédé objet de la présente invention, lors de la communication, l'ordinateur peut transmettre également des instructions pour transférer des données vers l'appareil de service. Selon une autre caractéristique du procédé objet de la présente invention, les données à transférer de l'ordinateur vers l'appareil de service comprennent des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans l'appareil de service. Selon une autre caractéristique du procédé objet de la présente invention, les données sont transférées sous la forme de fichiers informatiques. Selon une autre caractéristique du procédé objet de la présente invention, les fichiers à transférer de l'appareil de service vers l'ordinateur comprennent des rapports d'activité décrivant les transactions opérées par l'appareil de service pendant une période donnée ou encore des rapports d'alarmes décrivant des dysfonctionnements affectant ledit appareil de service. Selon une autre caractéristique du procédé objet de la présente invention, les transferts de fichiers entre l'ordinateur et l'appareil de service se font en utilisant le protocole de communication TCP/IP permettant ainsi le transfert au travers du réseau Internet. Selon une autre caractéristique du procédé objet de la présente invention, les données transitent entre l'appareil de service et l'ordinateur central à distance par un serveur FTP. 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. 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 sont destinés à être utilisés par les usagers en libre service et sont donc installés à cette fin dans des lieux publics, tels que la rue, ou semi-publics, tels que des centres commerciaux, des aéroports, halls d'hôtels, restaurants, magasins, etc. Ces 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. Ces téléphones publics 10 sont par ailleurs adaptés pour communiquer avec un serveur 5 encore appelé PMS (acronyme anglo- saxon de Pavphone 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 un serveur FTP 4 dont le rôle sera détaillé cidessous, et en particulier de contrôler des transferts de données ou logiciels, entre les téléphones publics 10 et le FTP 4. Entre autres fonctions, le PMS 5 transfère vers les téléphones publics 10, les fichiers nécessaires à leur fonctionnement, 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. 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 un serveur 4 spécifiquement conçu et adapté au transfert de fichiers 4, 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 4 et télécharger ou télédécharger les fichiers appropriés. Par ailleurs, les téléphones publics 10 peuvent se connecter à 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. Ces téléphones publics 10 sont, de façon connue, des terminaux conçus spécialement pour leur utilisation en site public ou semipublic. 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. 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. D'autre part, le téléphone public 10 met 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. Par ailleurs, pour permettre la connexion aux différents serveurs et notamment au PROXY 6, au PMS 5 ou au FTP 4, les téléphones 10 sont équipés de protocoles de communication TCP/IP conformes aux recommandations techniques de l'IETF (' Le PROXY 6 combine différentes 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 connexion", 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 nossible é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 le FTP 4, 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 compose ayant été présenté. Nous allons maintenant détailler la méthode utilisée pour transférer des données entre le PMS 5 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 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 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 notamment à la vérification de l'authenticité de cet appel puis 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 a réaliser. Cette demande de travail est principalement de trois types : ordre DOWNLOAD de transfert de fichiers du FTP 4 vers le téléphone 10, ordre UPLOAD de transfert de fichiers du téléphone 10 vers le FTP 4 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 : paw@163.285.6.45/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 ; - &commat;163.285.6.45 : adresse IP du FTP où télécharger les fichiers ; - 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, ce s s : identifiant unique du fichier à transférer (par exemple 02 pour un fichier comportant des transactions). upload/123456-05-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/download/work/aa-bbb-ccc-ddd. ee avec : ftr//demnnde 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 ; - 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 à transférer du FTP 4 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 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). download/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 FIJI bori fonctionnement du téléphone 10. fonctionnement du téléphone 10. Selon le mode de réalisation décrit, ces données et programmes sont répartis en 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é. "Rien entendu les fichiers a transférer du téléphone 10 vers le FTP 4 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 : paw@163. 285.6. 45/upload/123456-05-time. 01 UPLOAD 2 ftp ://uu : pew@163. 285.6. 45/upload/123456-05-time. 02 UPLOAD 3 ftp ://uu : pw@163. 285.6. 45/upload/123456-05-time. 03 ......... Un ordre peu également comporter plusieurs instructions : UPLOAD ftp ://uu : paw@163. 285.6. 45/upload/123456-05-time. 01 ftp ://uu : paw@163. 285.6. 45/upload/123456-05-time. 02 ftp ://uu : paw@163. 285.6. 45/upload/123456-05-time. 03 ......... Après avoir reçu un ordre de type UPLOAD"ou DOWNLOAD", le téléphone 10 ouvre une cession FTP avec le FTP 4 dont l'adresse lui a été notifiée. La connexion au FTP 4 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. 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 cmT'lunmcti'rm entre es téléDhones 10 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é 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, etc. Il est important de noter que les différents serveurs 4,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 derrier 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 est du chargement sur le FTP 4 des fichiers à transférer 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, 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 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"ept le nom d ! scnt "v\"le tvne 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 : groupe, dir = soft/v02rOOe02/groupl (groupl nom du répertoire de destination d'un premier lot de fichiers) group. 1.file1 = 03-002-000-001. 40 (fichier à charger) group 1.file2 = 03-002-000-001. 41 (fichier à charger) group 1.file3 = 03-002-000-001. 42 (fichier à charger) group 1. file4 = 03-002-000-001. 43 (fichier à charger) groups. files = 03-002-000-001. 70 (fichier à charger) group l. file6 = 03-002-000-001. 71 (fichier à charger) group 1. file7 = 03-002-000-00 4A (fichier à charger) groups. files = 03-002-000-002. 4B (fichier à charger) ; S-disconnect here group2. dir = soft/v02r00e02/group2 (group2 : répertoire de destination d'un second lot de fichiers) group2. file 1 = 03-002-000-001. 74 (fichier à charger) group2. file2 = 03-002-000-001. 75 (fichier à charger) group2. file3 = 03-002-000-001. 76 (fichier à charger) group2. file4 = 03-002-000-001. 79 (fichier à charger) group2. file5 = 03-002-000-001. 7B (fichier à charger) group2. file6 = 03-002-000-001. 7E (fichier à charger) group2. file7 = 03-002-000-001. 7F (fichier à charger) " 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 4, la programmation des différents téléphones concernés et le chargement des fichiers dans les tc1 prennes a partir du FTP 4. 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 4 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 4, enfin les téléphones 10 transfèrent les fichiers du FTP 4 dans leurs microprocesseurs. Soit les étapes du processus de téléchargement sont liées et les fichiers sont chargés dans le FTP 4 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. Considérons la solution selon laquelle les différentes étapes sont liées. Une fois, l'ordre donné de procéder au téléchargement des fichiers vers un lot prédéterminé de téléphones, le PMS 5 se met dans l'attente que les téléphones concernés se manifestent. En effet, chaque téléphone 10 du réseau 1 se connecte régulièrement au PMS 5 pour lui adresser une télécollecte (ou plus irrégulièrement pour des rapports spécifiques comme la survenue d'une anomalie). Lorsque le PMS 5 identifie dans le téléphone qui l'appelle, l'un des téléphones concernés par l'opération de téléchargement de fichiers qui a été lancé, il insert dans les différents ordres Cet ordre consiste à demander au téléphone de télécharger les fichier lister dans le script. Pour un script donné, le PMS 5 pourra balayer les unes après les autres les lignes d'instructions et s'exécute les instructions en s'adressant alternativement vers le FTP 4 et vers le téléphone 10 (DOWNLOAD 1, DOWNLOAD 2, DOWNLOAD 3, DOWNLOAD 4, etc..). Suivant la taille des fichiers à télécharger, le déroulement du script peut se faire en une fois ou en plusieurs fois. En cas de déroulement en plusieurs fois le script comporte des instructions intermédiaires de déconnexion. A la réception de cette commande le téléphone 1 0 interrompt la cession en cours et rappelle à un nouvel horaire prédéterminé. A la fin de l'exécution courante du script, l'ensemble des fichiers sont chargés dans le FTP 4 puis dans le téléphone 10. Lorsque le premier script est terminé, on passe ensuite au suivant (s'il y a plusieurs scripts) après au préalable l'installation en mémoire de travail (flash) du fichier reçu (identification, décompression, écriture, intégrité...) et on recommence le processus précité. Lorsque l'ensemble des scripts ont été exécutés, le dernier fichier du dernier script ayant été copié dans le téléphone 10, et dans la mesure où il s'agissait du dernier ordre de transfert de fichier de la part du PMS 5, la communication s'arrête par envoi de l'ordre DISCONNECT DISCONNECT... Pendant toute la durée de ces opérations, le téléphone a pu simultanément accéder au FTP 4 et au PMS 5 grâce à l'utilisation du protocole de communication TCP/IP. Bien évidemment, lorsqu'un deuxième téléphone puis tous les suivants se connectent au PMS 5 pour opérer le téléchargement des fichiers, la copie des fichiers vers le FTP 4 n'est plus opérer par le PMS 5, seule demeure le transfert des instructions vers les téléphones, à savoir fournir la liste des fichiers à copier et leur localisation. La méthode décrite ci-dessus pour transférer les fichiers entre le PMS 5 et les téléphones 10 en passant par le FTP 4 n'a été donnée qu'à titre d'exemple et admet de nombreuses variantes. Ainsi, lors de l'appel du premier téléphone de la liste à télécharger, on peut transférer un fichier vers le FTP 4 puis demander au téléphone de le copier et ainsi de suite fichier par fichier. Cette méthode offre 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, pour opérer la programmation d'un téléphone, le PMS 5 peut exécuter 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é du FTP 4, 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. Ainsi, le FTP 4 pourrait ne pas faire partie de la même machine voire du même réseau mais pourrait se trouver dans d'autres endroits (répartition géographique). 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 d'un appareil de service (10) à un ordinateur central à distance (5), l'appareil de service (10) étant apte à communiquer lesdites données audit ordinateur (5) par l'intermédiaire de moyens de transmission (2,4, 6) appropriés, caractérisé en ce que les données à transférer dudit appareil de service (10) vers ledit ordinateur à distance (5) sont déterminées par ledit ordinateur (5). 2/Procédé pour transférer des données selon la revendication 1, caractérisé en ce que lesdites données sont produites par des moyens logiciels et matériels appropriés et correspondent à des fonctions de supervision et de contrôle du fonctionnement dudit appareil de service (10), chaque donnée devant être transférée audit ordinateur central à un rythme donné spécifique à la nature de la fonction à laquelle elle correspond. 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 un code de cession précisant audit ordinateur la nature des données qu'il souhaite transférer ; ledit ordinateur (5) transmet alors audit appareil des instructions quant aux données devant être effectivement transférées. ledit appareil de service (10) transfert alors en retour les données demandées par ledit ordinateur (5). 4/Procédé pour transférer des données selon la revendication 3, caractérisé en ce que lors de ladite communication, ledit ordinateur (5) transmet également des instructions pour transférer des données vers ledit appareil de service (10). 5/Procédé pour transférer des données selon la revendication 4, caractérisé en ce que lesdites données à transférer vers ledit appareil de service CtO) comprennent des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans ledit appareil de service (10). 6/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 sont transférées sous la forme de fichiers informatiques. 7/Procédé pour transférer des données selon la revendication 6, caractérisé en ce que lesdits fichiers transférés de l'appareil de service (10) vers l'ordinateur (5) comprennent des rapports d'activité décrivant les transactions opérées par ledit appareil de service (10) pendant une période donnée ou encore des rapports d'alarmes décrivant des dysfonctionnements affectant ledit appareil de service (10). 8/Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que les transferts de fichiers entre ledit ordinateur (5) et ledit appareil de service (10) se font en utilisant le protocole de communication TCP/IP. 9/Procédé pour transférer des données selon la revendication 8, caractérisé en ce que lesdites données transitent entre ledit appareil de service (10) et l'ordinateur central à distance (5) par un serveur FTP (4). 10/Procédé pour transférer des données selon la revendication 9, caractérisé en ce que l'adresse dudit serveur FTP (4) est communiquée audit appareil de service (10) par ledit ordinateur (5) lors de chaque transfert.