Brevet FR2826751A1 — publié le 20030103

Procédé d'échange de données entre un appareil de service et un serveur de gestion selon un protocole de qestion sur IP La présente invention concerne l'échange de données entre un appareil de service et un serveur de gestion selon un protocole de gestion basé sur un protocole de type Internet, appelé encore"IP"pour"Internet Protocol". Plus particulièrement, elle concerne l'échange et/ou transfert de données tels que des fichiers ou des alarmes entre un serveur de gestion et des appareils de service tels que des téléphones d'un réseau de téléphonie public, des terminaux de paiement, des terminaux applicatifs, des horodateurs, des distributeurs automatiques ou analogues. D'une manière générale, un réseau de téléphonie public comporte généralement un (ou plusieurs) ordinateur central ou serveur de gestion, ci-après appelé serveur 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 publics répartis sur un territoire donné du réseau. Le serveur PMS a pour fonction d'échanger des données avec le parc de téléphones publics via le réseau de téléphonie. En pratique, les téléphones publics communiquent au serveur PMS un rapport d'activité détaillant par exemple le nombre et montant des transactions. Les téléphones publics 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 serveur 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 publics et le serveur PMS sont gérés selon un protocole de gestion qui est devenu obsolète, et en décalage avec les exigences de rapidité et d'évolution d'aujourd'hui. De plus, chaque nouvelle fonction ayant un impact sur le protocole actuel engendre des tests complets sur le protocole. De même, une modification protocolaire implique le plus souvent une modification de l'ensemble des sous-systèmes (publiphones, serveurs bancaires). Il en résulte que le protocole actuel n'est pas adapté aux évolutions du marché et/ou des services (messageries électroniques de type e-mail, SMS, ou des services Internet de type e-commerce ou analogue). La présente invention remédie à ces inconvénients. Elle porte sur un procédé d'échange de données entre au moins un appareil de service et au moins un serveur de gestion distant conformément à un protocole de gestion choisi. Selon une définition générale de l'invention, le protocole de gestion est basé sur IP et comprend au moins une règle d'initiation pour initier chaque session d'échange et au moins une règle de reprise pour lancer une éventuelle reprise en cas de non-aboutissement de l'échange. Ainsi, le protocole de gestion selon l'invention, de par son fonctionnement sur IP, permet une étanchéité par rapport au réseau et permet ainsi un dialogue client/serveur sur différents types de réseaux (PSTN, ISDN, Internet). Une connexion est possible à des réseaux divers et variés sans changer ou adapter le protocole de communication entre les appareils de service et le serveur. Une modification sur la structure des données au niveau du protocole est aisée et évite des modifications sur d'autres couches du protocole IP. De plus, un tel protocole permet le pilotage des échanges de données notamment en ce qui concerne l'initiation des sessions et leur éventuelle reprise en cas de non-aboutissement de l'échange. Le protocole permet aussi de travailler en ligne (on-line) ou hors-ligne (off-line). Un tel protocole est avantageusement susceptible d'être mis en oeuvre dans un environnement sans fil de type GSM, CDMA ou TDMA. Selon une autre caractéristique de l'invention, en cas de rupture d'une session d'échange au cours duquel des données sont transférées de l'appareil vers le serveur, la règle de reprise comprend une étape selon laquelle le transfert est repris en totalité en cas de changement de statut de l'appareil. Selon encore une autre caractéristique de l'invention, en cas de rupture d'une session d'échange au cours duquel les données sont transférées du serveur vers l'appareil de service, la règle de reprise comprend une étape selon laquelle la session d'échange est reprise à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture. De préférence, la règle de reprise est adaptée au travail à réaliser par l'appareil de service, à l'importance de la tâche et à son impact. Selon l'invention, la procédure de reprise peut comprendre une étape consistant à répéter la tentative de reprise indéfiniment jusqu'à remettre en fonctionnement l'appareil de service et/ou une étape consistant à différer la reprise d'une période de temps choisie et/ou une étape consistant à reprendre l'échange après un déclenchement de l'appareil de service. En pratique, la règle d'initiation comprend les étapes suivantes : - i) au niveau de l'appareil de service, émettre une requête de connexion"CONNECT"au serveur conformément au protocole ; - ii) au niveau du serveur, recevoir la requête de connexion"CONNECT", analyser les informations contenues dans ladite requête de connexion et émettre une réponse en fonction du résultat de l'analyse ; et - iii) au niveau de l'appareil, recevoir la réponse, et en cas de réponse positive"ACCEPT", synchroniser le terminal et le serveur et établir la session d'échange. En pratique, le protocole de gestion comprend une procédure de terminaison comprenant les étapes suivantes : - iv) au niveau du serveur, à l'issue de la session d'échange, émettre un ordre de déconnexion"DISCONNECT"à destination de l'appareil de service ; et - v) au niveau de l'appareil, recevoir l'ordre de déconnexion"DISCONNECT"et arrêter la session d'échange. Selon un autre aspect de l'invention, les données à échanger entre l'appareil et le serveur sont déterminées par le serveur. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ciaprès et des dessins dans lesquels : - la figure 1 est une vue schématique d'un réseau de téléphonie public utilisé pour la mise en oeuvre du procédé selon l'invention ; - la figure 2 illustre schématiquement l'architecture matérielle des appareils de service et du serveur dans lequel s'insère le protocole de gestion selon l'invention ; - la figure 3 illustre les étapes de l'initiation d'une session selon le protocole sur IP conforme à l'invention ; - la figure 4 illustre les étapes d'un téléchargement d'un fichier statuts sur FTP de l'appareil vers le serveur conformément à l'invention ; - la figure 5 illustre les étapes d'un téléchargement de fichiers sur FTP de l'appareil vers le serveur et d'un télédéchargement de fichiers sur FTP du serveur vers l'appareil conformément à l'invention ; - la figure 6 illustre les étapes d'un téléchargement de fichiers alarmes sur FTP de l'appareil vers le serveur et d'un télédéchargement de fichiers de configuration sur FTP du serveur vers l'appareil conformément à l'invention ; - la figure 7 illustre les étapes d'un téléchargement de fichiers sur FTP de l'appareil vers le serveur conformément à l'invention ; - les figures 8 et 9 illustrent les étapes d'exemples de télédéchargement de fichiers sur FTP du serveur vers l'appareil conformément à l'invention ; - la figure 10 illustre les étapes d'un échange de messages de l'appareil vers le serveur conformément à l'invention ; - les figures 11 à 13 représentent des exemples de terminaison d'une session selon l'invention ; - les figures 14 à 17 représentent d'autres exemples de terminaison d'une session selon l'invention ; - les figures 18 à 23 représentent des exemples de politiques de reprise de session conformément au protocole de l'invention ; - les figures 24 à 28 représentent d'autres exemples de politiques de reprise de session conformément au protocole de l'invention. En référence à la figure 1, on a représenté un réseau 1 de téléphonie public qui comprend un parc de téléphones publics 10 (un même parc peut comprend 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, des halls d'hôtels, des restaurants, des 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 qui peut être de type commuté, analogique, ou de type commuté numérique. Le réseau 2 peut également être constitué par un réseau de radiotéléphonie mobile et ce, quelle que soit sa nature, ou encore par le réseau Internet ou plus généralement par tout réseau de communication apte à transmettre des données 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 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 (liste des médecins de garde 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 à Internet et à des serveurs privés. Ces téléphones publics 10 sont par ailleurs adaptés pour communiquer avec un serveur 5 appelé PMS (Payphone Management System), dédié au fonctionnement et à la gestion du réseau de téléphonie public 1. Le serveur 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 serveur 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 échanges entre les appareils de service 10 et le serveur 5 sont sous la forme requête REQ réponse REQ. Les téléphones publics 10 et le serveur PMS 5 sont munis de moyens appropriés de supervision et de réception/émission d'informations. 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 serveur PMS 5 et un serveur FTP 4 (File Transfert Protocol), c'est-à-dire "protocole de transfert de fichier". Entre autres fonctions, le serveur 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, etc..., des listes d'opposition ou de surveillance de moyens de paiement utilisés. De leur côté, les téléphones publics 10 transmettent des informations relatives à leur utilisation, à savoir un rapport journalier comportant des données relatives aux transactions effectuées, au trafic, un rapport d'alarme qui permet de signaler au serveur PMS 5 la survenue d'incidents ou des atteintes à leur intégrité, comme une panne sur le lecteur de carte ou un combiné arraché, de manière à prévoir l'intervention d'un agent de surveillance, un fichier de statuts caractérisant le contenu du téléphone (telles que les indications des différentes versions de programmes utilisés par le microprocesseur). Pour faciliter les échanges de données, on utilise un serveur FTP 4 spécifiquement conçu et adapté aux transferts de fichiers appelé FTP. A partir de commandes reçues par le serveur PMS 5, chaque téléphone public 10 qui intègre une entité FTP client, va se connecter au serveur FTP 4 et télécharger ou télédécharger des 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 et le serveur PMS 5. En référence à la figure 2, pour permettre la connexion aux différents serveurs et notamment au serveur PROXY 6, au serveur PMS 5 ou au serveur FTP 4, les appareils de service 10 (ici des téléphones) sont équipés de protocoles de communication 12 de type TCP/IP, et 14 UDP/IP conformes aux recommandations techniques de l'IETF (Internet Engineering Task Force). Chaque téléphone public 10 comprend un système d'exploitation 16, une interface standard 18 de type"socket", un protocole 20 de type terminal ou TELNET pour"Network Terminal Protocol"et un protocole 22 de type FTP client. Le protocole de gestion PFSP côté client (pour Payphone session protocol) selon l'invention est logé dans la couche 24. Par exemple, l'appareil de service 10 est dédié à une application 26 de type téléphone public. De son côté, le serveur PMS 5 est équipé de protocoles de communication 32 de type TCP/IP, et 34 UDP/IP conformes aux recommandations techniques de l'IETF (Internet Engineering Task Force). Le serveur PMS 5 comprend en outre un système d'exploitation (non représenté), une interface standard 38 de type"socket", un protocole 40 de type terminal ou TELNET pour"Network Terminal Protocol"et un protocole 42 de type FTP serveur. Le protocole de gestion PFSP côté serveur selon l'invention est logé dans la couche 44. Par exemple, le serveur PMS 5 est dédié à une application 46 de type téléphone public. Le serveur PROXY 6 combine différentes fonctions, notamment orienter les requêtes des téléphones publics 10, suivant la nature de ces requêtes, vers des serveurs correspondants ; le cas échéant traduire les données ou instructions émises par les téléphones 10 au format des serveurs destinataires ; 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 afin de conférer un degré de sécurité supplémentaire. Une autre fonction du serveur PROXY est d'établir des sessions d'échanges d'informations fiables et authentifiées qui consistent par exemple à identifier de façon certaine les téléphones 10 lors d'un échange d'informations avec les serveurs ou encore à chiffrer les données afin de sécuriser la communication en cas de besoin. Une autre fonction du serveur PROXY 6 est de piloter et réguler les échanges d'informations réalisés via les transferts de fichiers standard et conformes au protocole Internet. Le serveur 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 serveur PROXY 6 se trouve inaccessible par suite notamment d'opérations de maintenance, il est alors possible de diriger les compte-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 est alors totalement transparent pour les téléphones publics 10 qui n'ont pas à gérer ainsi eux-mêmes des adresses de secours mais seulement l'adresse du serveur PROXY 6. La redondance du serveur PROXY 6 lui-même est également possible, évitant ainsi des ruptures de communication en cas de pannes constatées. Toute requête de connexion à un serveur parvient sur le port d'entrée de l'ordinateur qui est écouté en permanence par le serveur PROXY 6, puis est re-dirigée vers un port de travail. La requête est ensuite analysée par une application logicielle, par exemple en langage JAVAs 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 mis en oeuvre grâce à la présente invention. Ainsi, le serveur PROXY 6, le serveur PMS 5 et le serveur de fichiers FTP 4, au lieu d'être des machines séparées comme sur la figure 1, peuvent être regroupées dans un seul ordinateur de type PC par exemple, comme en référence à la figure 2. En référence à la figure 3, l'établissement d'une session gérée selon le protocole de gestion PFSP conforme à l'invention est avantageusement une session de type TCP/IP. La session est initiée (ou initialisée) par l'appareil 10 qui envoie un message S-Connect. req au serveur PMS 5 généré grâce à des programmes spécifiques mis en oeuvre par les microprocesseurs équipant l'appareil 10. Ce message S-Connect. req constitue la requête de connexion, appelée encore"CONNECT". Le message S-Connect. req est acheminé au serveur 5 via le réseau 2, et interprété en message S-Connect. ind. Le serveur analyse le message S-Connect. ind. Après analyse, le serveur 5 émet un message S-Connect. res, qui constitue la réponse du serveur à la demande de connexion, appelée encore"ACCEPT", en cas de réponse positive. Le message S-Connect. res est acheminé au téléphone 10 via le réseau 2, et interprété en message S-Connect. cnf, confirmant l'établissement de la session TCP/IP. L'événement déclenchant la connexion du téléphone 10 au serveur 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). L'alarme peut être 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 du signal 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 serveur 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. Le 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 fichiers vers le téléphone, en général il s'agit là d'un ordre préalable donné par le serveur PMS 5), alarme, etc ; - la signature authentifiant ce téléphone 10, cette signature peut être obtenue par le cryptage au moyen d'un algorithme de cryptologie de type DES ou de tout autre type (RSA par exemple). Le téléphone 10 dispose alors d'une liste de sessions types qui définissent a 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 serveur 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, entre autres données, la date et l'heure courante afin de procéder à une re-synchronisation entre les deux appareils, ainsi que l'heure et la date du prochain appel programmé. Le serveur PMS 5 adresse ensuite une première demande de travail à réaliser. Cette demande de travail est principale ment de trois types : - ordre de transfert de fichiers du serveur FTP 4 vers le téléphone 10 (download au format FTP) ; - ordre de transferts de fichiers du téléphone 10 vers le serveur FTP 4 (upload au format FTP) ; et - ordre d'arrêt de la communication au format TCP/IP (disconnect). Le protocole PFST pour"payphone session protocole"permet selon l'invention d'initier un échange (une session de communication) entre un téléphone 10 et un serveur en utilisant un protocole au format TCP/IP. Ce protocole permet l'installation d'une session d'échange de données entre un client et un serveur sur n'importe quel type de réseau. Comme décrit en référence à la figure 3, le message de connexion CONNECT permet l'initialisation de la session. En référence à la figure 4, afin d'initialiser un appareil de service à partir du serveur, le serveur doit récupérer un fichier de configuration dit"STATUTS"de l'appareil de service. Ce fichier de configuration doit toujours être envoyé avant l'ordre de terminaison (disconnect) de la communication à la fin de la session. Si le serveur 5 le souhaite, l'appareil de service peut récupérer un fichier contenant la table de tarifs actifs ou un fichier contenant la table de tarifs passifs. De même, si le serveur le souhaite, l'appareil de service peut récupérer un fichier de paramètres, une liste noire, une liste grise, un fichier contenant des logiciels segmentés et un fichier de configuration objet. Après l'ordre ACCEPT, une session FTP proprement dite peut commencer. Elle peut être soit un chargement de fichiers dit UPLOAD ou bien un télédéchargement de fichiers de type DOWNLOAD. En ce qui concerne l'ordre de téléchargement UPLOAD, le serveur émet une requête S. File. req. Cette requête est acheminée à travers le réseau à destination du téléphone correspondant. Le premier ordre reçu par un téléphone 10 de la part du serveur 5 concerne le transfert d'un fichier encore appelé STATUTS précisant les références de l'ensemble ou des principaux fichiers constituant les ressources logicielles du téléphone. Ce fichier STATUTS permet ultérieurement au serveur PMS 5, en cas de dysfonctionnement, de déterminer les différentes versions de logiciels utilisées par le téléphone 10. Dans les échanges entre le serveur 5 et les téléphones 10, le serveur PMS 5 est toujours décisionnaire quant au fichier transféré, c'est le maître. De par l'architecture décrite, le serveur 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'exploitation du réseau. Une 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 communiquée dynamiquement au téléphone 10 par le serveur 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 serveur PMS qui choisit les fichiers à transférer. Une fois que le fichier STATUTS est acheminé par le réseau vers le serveur, le téléphone 10 émet une réponse de type S. File. res. Cette information est acheminée au serveur via le réseau 2. Une fois reçu, ce message constitue une confirmation du type S. File. Cnf. En référence à la figure 5, l'opération de chargement de fichiers (UPLOAD) est initiée par la requête S. File. Req selon le format décrit ci-avant. Après réception de cette requête, le téléphone 10 interprète cette requête et délivre le message S. FILE. IND. A la suite de cette interprétation, le téléphone peut, sous le format FTP, charger dans le serveur différents fichiers qui peuvent être relatifs aux transactions, aux compteurs d'exploitation, aux alarmes courantes, aux fichiers LOG des alarmes, aux compteurs relatifs aux listes noires. Le chargement de fichiers est terminé par la requête S. File. res émanant de l'appareil de service. Cette réponse est interprétée comme une confirmation après réception par le serveur. Après avoir reçu un ordre de type UPLOAD ou DOWNLOAD, le téléphone 10 ouvre une session FTP avec le serveur FTP 4 dont l'adresse lui a été notifiée. La connexion au serveur FTP 4 en parallèle à la session courante est établie avec le serveur PMS 5 via le serveur PROXY 6. Le téléphone exécute ensuite le transfert de fichier demandé auprès du serveur FTP qui lui a été notifié. Une fois le transfert du ou des fichier (s) achevé, le téléphone adresse un message d'acquittement par lequel il confirme au serveur PMS 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 comme on le décrira plus en détail ci-après. Il est à remarquer que dans la phase de chargement UPLOAD, les fichiers téléchargés comprennent des fichiers de configuration si au moins l'un des paramètres a changé. Ce fichier est toujours envoyé avant l'ordre de terminaison de la communication à la fin de la session. Par exemple, le serveur 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 programmes. 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 serveur PMS peut 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. En référence à la figure 6, la session relative au report d'alarme comprend comme enseigné ci-avant une requête de type UPLOAD à l'issue de laquelle un fichier FTP est téléchargé dans le serveur. Les fichiers téléchargés peuvent être un fichier de configuration, des fichiers d'alarme présente, le fichier dit alarme Log ainsi des transactions. A la suite de ce fichier ainsi téléchargé, un ordre DOWNLOAD peut être suivi et effectué afin de télédécharger un fichier de configuration du serveur vers l'appareil de service. Il est à noter que dans la session de report d'alarme, il est obligatoire de ne pas envoyer, dans le message S. CONNECT. RES la date de report quotidien. En référence à la figure 7, l'invention peut prévoir également une session de télédiagnostic dans laquelle des fichiers sont téléchargés dans le serveur. Ces fichiers téléchargés peuvent comprendre un fichier de configuration, un fichier de transaction, un fichier des compteurs d'exploitation, un fichier d'alarme présente, le Log des alarmes, un fichier de compteur de liste noire et un fichier de compteur de liste grise. En référence aux figures 8 et 9, le serveur peut également initier une session de télédéchargement dans laquelle des fichiers sont télédéchargés du serveur vers l'appareil de service correspondant. Les fichiers télédéchargés sont par exemple des fichiers de table de tarif active, ou passive, un fichier de paramètres, un fichier de liste noire ou grise, un fichier de logiciels segmentés et, le cas échéant, un fichier de configuration objet. La session de téléchargement proprement dite comprend le télédéchargement d'un fichier de configuration, etc... En référence à la figure 10, le protocole permet également de gérer des sessions de requêtes de contenus et de courriels ou e-mail. L'établissement de la session est initié selon le protocole mentionné ci-avant avec les ordres CONNECT et ACCEPT. Après établissement de la connexion, le téléphone émet une requête S. Methodinvoke. req. Cette requête correspond à l'ordre GET/POST en messagerie sous TCP/IP. Le serveur reçoit cette requête via le réseau de téléphonie et il interprète en requête S. Methodinvoke. ind. Le serveur analyse cette requête et émet en réponse le message S. Methodinvoke.res qui constitue une réplique ou réponse du serveur. Le téléphone ou appareil de service confirme cette réponse avec le message S. Methodinvoke. cnf. La session se termine selon le protocole mentionné ci-avant avec l'ordre DISCONNECT. Le transfert de contenu peut contenir une ou plusieurs requête (s) de contenu et de transfert. En cas de session anormale, le protocole prévoit plusieurs règles de traitement. Selon l'invention, le protocole PFSP prévoit plusieurs règles permettant de traiter des sessions anormales. En premier lieu, une session peut être considérée comme anormale lorsque le format de la requête est incorrect. Dans ce cas, un message "DISCONNECT" est envoyé accompagné d'un code de type PROTERR par l'intermédiaire du serveur PROXY à destination du serveur PMS et de l'appareil de service correspondant. En référence à la figure 11, l'établissement de la connexion ou de la session de type TCP/IP peut être refusé par le serveur de communication PROXY, par exemple lorsque le service n'est pas disponible. Dans ce cas, le serveur de communication PROXY émet à la destination de l'appareil de service un message DISCONNECT qui, une fois reçu par l'appareil de service, est interprété en S. DISCONNECT. IND avec le code correspondant CONNECTERR. En référence à la figure 12, l'établissement de la connexion peut être refusé par le serveur PMS. Dans ce cas, après la demande de connexion émanant de l'appareil de service, le serveur émet un message S. DISCONNECT. REQ contenant le code correspondant qui peut avoir la définition REDIAL CONGESTION ou PEERREQ en fonction de l'événement provoquant le refus. Le message DISCONNECT est envoyé à l'appareil de service. En référence à la figure 13, une temporisation par exemple de l'ordre de 30 secondes peut être prévue à la suite d'une première demande de connexion n'ayant pas aboutie. Ainsi, l'appareil de service émet une requête de terminaison S. DISCONNECT. REQ avec le code PEERREQ à destination du serveur, après une temporisation de 30 secondes par rapport à sa première demande de connexion S. CONNECT. REQ. De même, en référence à la figure 14, il est prévu une demande de terminaison émanant du serveur avec le message S. DISCONNECT. REQ et le code PEERREQ lors d'un télédécharge- ment ou d'un téléchargement qui n'aboutit pas à l'issue d'une période choisie. Cette période TX a une valeur qui dépend du nombre de fichiers transférés et de la taille de chacun de ces fichiers. Cette période TX peut être calculée par le serveur. En référence à la figure 15, l'appareil de service peut émettre un message de terminaison de session S. DISCONNECT. REQ avec le code CONGESTION à l'attention du serveur lorsque, par exemple, des erreurs internes sont détectées ou bien lorsque des problèmes de gestion des fichiers en mémoire vive sont détectés au niveau de l'appareil de service. La cohérence du codage, notamment sa syntaxe est vérifiée par le serveur PROXY de communication. Le motif de la demande de terminaison se trouve dans le code correspondant, ici CONGESTION. En référence à la figure 16, une demande de terminaison de session est émise par le serveur avec le code correspondant à DISCONNECT REDIAL dans le cas d'un télédéchargement (DOWNLOAD). De même, en référence à la figure 17, une demande de terminaison requise par l'appareil de service avec le message S. DISCONNECT. REQ et le code PEERREQ après une temporisation par exemple de 30 secondes. Cette demande de terminaison peut avoir lieu à l'issue d'une temporisation dont le départ est formé par le résultat du transfert. La présente invention prévoit également un protocole qui gère les reprises de sessions, après ruptures de celles-ci. Ainsi, en réponse à une rupture d'une session, il est prévu une règle de reprise de la session jusqu'à ce que la connexion soit ré-établie afin d'être correctement traitée. En référence à la figure 18, la gestion de reprise peut intervenir dans le cas d'une transaction PFSP, de type TCP/IP, comme celle décrite en référence à la figure 3. Dans ce cas, la procédure de reprise prévoit de renouveler la demande de connexion S. CONNECT. REQ. En référence à la figure 19, la reprise de la session peut intervenir également après réception de la demande de connexion avec établissement de la connexion au niveau du serveur mais avant la réception du message ACCEPT au niveau de l'appareil de service. En référence à la figure 20, la gestion de la reprise de la session peut intervenir au niveau de l'opération de téléchargement de fichier. Par exemple en cas de difficulté dans le fichier de statut de l'appareil de service, le protocole selon l'invention gère une telle rupture. De même, en référence à la figure 21, la gestion de la reprise peut intervenir au niveau d'un téléchargement d'un fichier du type UPLOAD. Il en est de même en référence à la figure 22 de l'opération de télédéchargement de type DOWNLOAD. Dans ce cas, une politique de reprise est prévue selon l'invention. En référence à la figure 23, la gestion de la reprise peut intervenir également lors de la rupture de la session avant réception du message DISCONNECT au niveau de l'appareil de service. Selon l'invention, les causes qui déclenchent la gestion des reprises peuvent être de différente nature : - coupure de la ligne, expiration de la temporisation ou bien encore des problèmes techniques au niveau du serveur, du modem de l'appareil de service. En référence à la figure 24, aucune gestion des reprises n'est prévue lors d'une initialisation réalisée à la demande de l'opérateur. En référence à la figure 25, une première tentative de reprise R1 de connexion est prévue, par exemple, après 5 minutes de la rupture en cas d'un défaut dans la valeur d'un paramètre. Cette tentative R1 en cas d'échec est recommencée un certain nombre de fois, par exemple 2 (individualisées ici en R2 et R3). Dans le cas d'un échec à l'issue des trois tentatives, la politique de reprise ne prévoit pas ici de nouvelles tentatives et la session est définitivement interrompue. Cette politique de reprise est par exemple mise en oeuvre lors d'une téléinitialisation ou d'un télédiagnostic. En référence à la figure 26, une règle de reprise particulière est prévue dans le cas d'une télécollecte quotidienne. La règle de reprise comprend deux branches d'interventions. Dans la première branche, la rupture C de la télécollecte (par exemple en raison d'un défaut dans la valeur d'un paramètre émanant du serveur), la télécollecte peut être reprise à l'issue d'une procédure qui débute par le réveil de l'appareil (par exemple une demande de communication de la part d'un usager du téléphone public ou encore l'introduction d'une carte de paiement), suivi d'une mise en sommeil et qui se termine par la tentative de la reprise 5 minutes après la mise en sommeil. Cette tentative de reprise est de préférence sans limites, c'est-à-dire jusqu'à l'aboutissement de la télécollecte. Dans la seconde branche, la télécollecte est différée RD d'un laps de temps choisi, par exemple 12 heures. Cette seconde branche est mise en oeuvre lorsqu'il n'y a pas de réveil de l'appareil par un usager tel que décrit ci-avant dans la première branche. En pratique, si la tentative de reprise de la première branche est un succès, la programmation de la reprise différée est supprimée jusqu'à la prochaine télécollecte. En référence à la figure 27, en cas de rupture de communica tion lors de la procédure d'alarme, une tentative de reprise est mise en oeuvre dans les 5 minutes qui suivent la rupture. Par exemple, le nombre de tentatives peut être limité à 3. Par contre, en cas de réveil de l'appareil par une opération manuelle telle que l'introduction d'une carte ou un décroché de l'appareil téléphonique, la règle de reprise prévoit d'initialiser à nouveau la procédure d'alarme jusqu'à ce que la procédure d'alarme fonctionne correctement. En référence à la figure 28, une procédure de reprise est prévue lors du télédéchargements de plusieurs objets ou bien encore lors de la procédure d'initialisation après la session de télédéchargement. Dans cette procédure de reprise, on retrouve le cycle court des reprises (5 minutes) et un cycle long (15 minutes) qui peut être déclenché automatiquement par un horodateur. Dans le cas de l'opération de télédéchargement (DOWNLOADING), l'appareil de service initialise la procédure de reprise et le serveur joue toujours le même scénario après identification correcte de l'appareil de service. Dans ce cas, l'appareil de service retrouve les fichiers manquants après une analyse correcte. En d'autres termes, la reprise s'effectue à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture. Comme vu ci-avant, il n'en est pas de même dans l'opération de téléchargement de fichiers (UPLOADING). En effet, pendant la période de rupture, l'appareil de service peut modifier ou avoir changé ses statuts. Dans ces conditions, une reprise de la session de téléchargement partielle engendre une incorrection au niveau du statut de l'appareil de service. Dans ce cas-là, il convient selon l'invention de prévoir une politique de reprise qui reprend complètement le chargement de l'ensemble des fichiers. En pratique, dans le cas d'une coupure d'une ligne intervenant lors de l'émission du signal S. Disconnect. req, l'appa- reil de service peut tenter d'initialiser une reprise de communication (comme bien sûr, à tout autre instant de rupture). En réponse, le serveur envoie alors les scénarios prévus. Toutefois, parce qu'il a déjà l'ensemble des objets, l'appareil de service envoie à l'attention du serveur uniquement un acquittement correct, signalant la mise en place ultérieure des objets, et attend de la part du serveur uniquement le message de terminaison S. Disconnect, ceci à des fins de gain de temps et d'éviter des répétitions inutiles. Dans les tableaux A et B ci-contre, on a représenté les différentes règles de reprise des sessions en présence d'événements prédéterminés. erreur validation encombre-abandon ou protocole ment échec initiation Gestion pas de Gestion pas de des reprise des reprise reprises reprises télécol-Gestion pas de Gestion pas de lecte des reprise des repri-reprise reprises ses alarme pas de pas de pas de pas de reprise reprise reprise reprise télédé-pas de pas de pas de pas de chargement reprise reprise reprise reprise appel ser-pas de pas de pas de pas de veur PMS reprise reprise reprise reprise tableau A erreur de rappel erreur coupure réseau connexion ligne initiation gestion rappel Gestion gestion des repri-programmé des des reprises reprises ses télécol-gestion rappel Gestion gestion lecte des repri-programmé des des reprises reprises ses alarme gestion rappel pas de gestion des repri-programmé reprise des reprises ses télédé-gestion rappel pas de gestion chargement des repri-programmé reprise des reprises ses appel ser-gestion rappel pas de gestion veur PMS des repri-programmé reprise des reprises ses tableau B Les tableaux A et B font partie intégrante de la présente invention. Ils comprennent des éléments de caractère certain qui peuvent servir à la définition de l'invention le cas échéant. Dans ces tableaux, on distingue 5 types de sessions, à savoir initiation, télécollecte quotidienne, alarme, télédéchargement (download), et appel serveur PMS. Pour ces différentes sessions, on prévoit 8 types d'événements, à savoir erreur de protocole, validation, encombrement, abandon ou échec, erreur de réseau, rappel, erreur de connexion, et coupure de ligne. Par exemple, il n'est pas prévu de reprise dans le cas d'une d'une erreur de protocole en procédure de télédéchargement (download). En revanche, en télédéchargement, une politique de reprise est prévue en cas d'erreur de réseau, comme indiquée ci-avant. Par ailleurs, la gestion des reprises peut distinguer une reprise différée qui intervient de préférence après un cycle immédiat court pour permettre à l'opérateur de rétablir le système avant répétition (évite ainsi les échanges inutiles) et une reprise immédiate qui constitue la reprise de la session initiale. Bien entendu, l'invention n'est pas limitée aux formes de réalisation décrites précédemment à titre d'exemple et s'étend à d'autres variantes. Revendications 1. Procédé d'échange de données entre au moins un appareil de service (10) et au moins un serveur de gestion (5) distant conformément à un protocole de gestion choisi, caractérisé en ce que le protocole de gestion est sur IP et comprend au moins une règle d'initiation de chaque session d'échange et au moins une règle de reprise pour lancer une éventuelle reprise en cas de non-aboutissement de l'échange. 2. Procédé selon la revendication 1, caractérisé en ce qu'en cas de rupture d'une session d'échange au cours duquel les données sont transférées de l'appareil (10) vers le serveur (5) (UPLOAD), la règle de reprise comprend une étape selon laquelle le transfert est repris en totalité en cas de changement de statut de l'appareil. 3. Procédé selon la revendication 1, caractérisé en ce qu'en cas de rupture d'une session d'échange au cours duquel les données sont transférées du serveur (5) vers l'appareil de service (10) (DOWNLOAD), la règle de reprise comprend une étape selon laquelle la session d'échange est reprise à l'endroit de la rupture sans reprendre la partie de l'échange déjà réalisé avant la rupture. 4. Procédé selon la revendication 1, caractérisé en ce que la règle de reprise est adaptée au travail à réaliser par l'appareil de service, à l'importance de la tâche et à son impact. 5. Procédé selon la revendication 4, caractérisé en ce que la procédure de reprise comprend une étape consistant à répéter la tentative de reprise indéfiniment jusqu'à remettre en fonctionnement l'appareil de service. 6. Procédé selon la revendication 4, caractérisé en ce que la règle de reprise comprend une étape consistant à différer la reprise d'une période de temps choisie. 7. Procédé selon la revendication 4, caractérisé en ce que la règle de reprise comprend une étape consistant à reprendre l'échange après un déclenchement de l'appareil de service. 8. Procédé selon la revendication 1, caractérisé en ce que la règle d'initiation comprend les étapes suivantes : - i) au niveau de l'appareil de service, émettre une requête de connexion (CONNECT) au serveur conformément au protocole, - ii) au niveau du serveur, recevoir la requête de connexion (CONNECT), analyser les informations contenues dans la requête et émettre une réponse en fonction du résultat de l'analyse, et - iii) au niveau de l'appareil, recevoir la réponse et en cas de réponse positive (ACCEPT), synchroniser l'appareil et le serveur et établir la session d'échange. 9. Procédé selon la revendication 1, caractérisé en ce que le protocole de gestion comprend en outre une procédure de terminaison sur IP comprenant les étapes suivantes : - iv) au niveau du serveur, à l'issue de la session d'échange, émettre un ordre de déconnexion (DISCONNECT) à la destination de l'appareil de service, et - v) au niveau de l'appareil de service, recevoir l'ordre de déconnexion (DISCONNECT) et arrêter la session d'échange. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit en outre une politique pour le téléchargement de fichiers de l'appareil vers le serveur sur FTP. 11. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit en outre une politique pour le télédéchargement de fichiers du serveur vers l'appareil sur FTP. 12. Procédé selon l'une des revendications précédentes, caractérisé en ce que le protocole de gestion prévoit une politique pour le transfert de message sur IP entre l'appareil et le serveur et réciproquement. 13. Appareil de service pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12. 14. Serveur pour la mise en oeuvre du procédé selon l'une des revendications 1 à 12.