CA2436718A1 - Method for transferring data between a service apparatus and a remote management server - Google Patents

Method for transferring data between a service apparatus and a remote management server Download PDF

Info

Publication number
CA2436718A1
CA2436718A1 CA002436718A CA2436718A CA2436718A1 CA 2436718 A1 CA2436718 A1 CA 2436718A1 CA 002436718 A CA002436718 A CA 002436718A CA 2436718 A CA2436718 A CA 2436718A CA 2436718 A1 CA2436718 A1 CA 2436718A1
Authority
CA
Canada
Prior art keywords
computer
data
files
service device
pms
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002436718A
Other languages
French (fr)
Inventor
Rodolphe Grunenwald
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Axalto SA
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CA2436718A1 publication Critical patent/CA2436718A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé pour transférer des données d.prime.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).Method for transferring d.prime data from a service device (10) to a remote central computer (5), the service device (10) being capable of communicating said data to said computer (5) via suitable transmission means (2, 4, 6), characterized in that the data to be transferred from said service device (10) to said remote computer (5) is determined by said computer (5).

Description

(54) Titre : PROCÉDÉ DE TRANSFERT DE DONNÉES ENTRE UN APPAREIL DE SERVICE ET
UN SERVEUR DE GES-TIONA DISTANCE
PROCÉDÉ DE TRANSFERT DE DONNÉES ENTRE UN
APPAREIL DE SERVICE ET UN SERVEUR 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
(54) Title: METHOD FOR TRANSFERRING DATA BETWEEN A SERVICE APPARATUS AND
A GHG SERVER-TIONA DISTANCE
METHOD FOR TRANSFERRING DATA BETWEEN A
SERVICE APPARATUS AND A MANAGEMENT SERVER
DISTANCE.
The present invention relates to a method for transferring data between service devices and a management server to distance. The present invention relates more particularly to a process for transferring files between a management server and telephones from a public telephone network.
A public telephone network consists of telephones public distributed over a given territory. Public telephones are connected to a communication network, constituted for example by the PSTN switched telephone network (acronym for Public Switching Telephone Network), with which they communicate using a modem. This network of course could be of a other type (ISDN, GSM, Internet, ...).
A public telephone network generally includes a (or several) central computer or management server, hereinafter called PMS (acronym of the Anglo-Saxon term "Payphone Management System ”), allowing the network operator to operate supervision of the different phones in its network. This PMS, which is connected to the switched telephone network, has the function of exchanging with the park of public data telephones.
Public telephones regularly communicate to the PMS a activity report detailing the number and amount of transactions, etc. They also communicate in the form of an alarm the possible occurrence of an event (breakdown, act of vandalism, etc.) requiring the intervention of a maintenance agent.
The PMS transfers files to public telephones, rate tables or even updates to programs doing operate phone microprocessors, updates improving the programs already in place or even introducing new services for users.
Today, file transfers between phones 10 and PMS are rigid operations, time-consuming and therefore costly. So a pay phone that downloads files must

-2-ê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.
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'étant 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.
-2-be switched to out of service mode and cannot be used by users all the time of an operation, which can last several hours given the current size of programs and data to load.
In addition, each new download campaign requires complex programming of the PMS taking into account the nature and size of the files to be transferred.
The present invention therefore aims to remedy these drawbacks by simplifying and streamlining the transfer of data between a server remote management and service devices such as public telephones.
The method according to the invention relates to the transfer of data from a service device, such as a public telephone, to a computer remote central, such as a management server, service appliance being able to communicate the data to the computer by through appropriate means of transmission.
According to the invention, the method for transferring data is characterized in that the data to be transferred from the service device to the remote computer are determined by the computer alone.
According to another characteristic of the process which is the subject of the present invention the data is produced by software means and appropriate materials and correspond to supervisory functions and checking the operation of the service appliance, each data to be transferred to said central computer at a rate given specific to the nature of the function to which it corresponds.
According to another characteristic of the process which is the subject of the present invention it includes the following steps - the service device opens a communication transfer with said remote computer;
- the service device provides a session code specifying audit computer the nature of the data it wishes to transfer;
- the computer, having verified the authenticity of the call from the service device (syntax check, by checking a code secret, by checking the product range, etc.), then transmits â
the device instructions as to the data to be actually transferred.

-3-- 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.
-3-- the service device then transfers the data back requested by the computer.
According to another characteristic of the process which is the subject of the present invention, during communication, the computer can transmit also instructions for transferring data to the device on duty.
According to another characteristic of the process which is the subject of the present invention, the data to be transferred from the computer to the service include software means replacing or supplementing software means already installed in the service device.
According to another characteristic of the process which is the subject of the present invention, data is transferred in the form of files computer.
According to another characteristic of the process which is the subject of the present invention, the files to be transferred from the service device to computer include activity reports describing the transactions made by the service device during a period data or alarm reports describing malfunctions affecting said service appliance.
According to another characteristic of the process which is the subject of the present invention, file transfers between computer and device service are done using the TCP / IP communication protocol thus allowing transfer through the Internet network.
According to another characteristic of the process which is the subject of the present invention, data flows between the service device and the central computer remotely via an FTP server.
According to another characteristic of the process which is the subject of the present invention, the FTP server address is communicated to the computer service during each transfer.
We will better understand the goals, aspects and advantages of present invention, from the description given below of a mode embodiment of the invention, presented by way of nonlimiting example, with reference to the accompanying drawing, in which Figure 1 is a schematic view of a telephone network public body used for implementing the method according to the invention.

-4-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 Internat 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'Internat, 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'Internat 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-
-4-Only the elements of the telephone network have been figured and its environment which are necessary for the understanding of the invention.
In FIG. 1, a telephony network 1 has been represented.
Public. This network includes a fleet of public telephones 10 (one same park can include tens to thousands of telephones, or even tens of thousands, depending on the territorial coverage of the network).
The telephones 10 are intended to be used by users in self-service and are therefore installed for this purpose in public places, such as street, or semi-public, such as shopping malls, airports, hotel halls, restaurants, shops, etc.
These phones 10 allow users to perform telephone communications, using a telephone network suitable referenced 2. This telephone network 2 is of switched type analog PSTN (Public Switching Telephone Network) or type ISDN (Integrated Services Digital Network) digital dial-up. This network 2 can also be constituted by a network of mobile radiotelephony, whatever its nature: GSM, CDMA, TDMA, AMPS, D-AMPS, or by the Internat network or more generally by any communication network capable of transmitting data (X25, Ethernet, ..) as well as by any combination of such networks.
These public telephones 10 can also be adapted for access information or service servers Web and Internship, as well as information or provision of services residing on private networks. Such access allow the operator, operating network 1, to offer users a wide range of services, ranging for example and not limiting, from reading their emails to the consultation of local information (lists of on-call doctors public telephone area, etc.).
Obviously the invention is not limited to telephones public offering such access to the Boarding School and private servers.
These public telephones 10 are moreover adapted for communicate with a server 5 also called PMS (acronym

-5-saxon 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 1.0 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é ci-dessous, 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,
-5-"Payphone Management System") dedicated to operation and the management of the public telephone network 1.
The PMS 5 has the function of exchanging with the fleet of telephones 1.0 public information about their operation and more generally the operation of the public telephone system.
In particular, the PMS 5 manages the initialization sessions of the public telephones and compiles statistical data from information received from public telephones 10 (alarms, counters operating. . . ).
Public telephones 10 and PMS 5 are provided with means supervision and reception / transmission of information, these means which are in themselves known will not be described further in detail. These means of supervision and reception / transmission are responsible for organizing the exchange of information between telephones public 10, the PMS 5 and an FTP server 4 whose role will be detailed below below, and in particular to control data transfers or software, between payphones 10 and FTP 4.
Among other functions, the PMS 5 transfers to the telephones public 10 files necessary for their operation, such as price tables, configuration parameters (such as the type of numbering, line characteristics ...), lists opposition or monitoring of the means of payment used.
Public telephones 10 for their part transmit information relating to their use, namely a daily report containing data relating to the transactions carried out, the traffic, an alarm report which signals the PMS 5 incidents or breaches of their integrity, such as failure on the card reader or a torn handset, so that provide for the intervention of a surveillance officer, a status file characterizing the contents of the telephone (such as indications of different versions of programs used by the microprocessor), etc.
To facilitate data exchange, we use a server 4 specifically designed and adapted for file transfer 4, called FTP
(for File Transfer Protocol). From orders received by the PMS 5, each public telephone 10, which integrates a client FTP entity,

-6-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 semi-public. 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 (« Internet Engineering Task Force »).
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 corréspondants. 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.

WO 02/06201
-6-will connect to FTP 4 and download or download files appropriate.
Furthermore, public telephones 10 can connect to a PROXY 6 server, serving as a communication interface between public telephones 10 and PMS 5. The functions of PROXY 6 will be more detailed below.
These public telephones 10 are, in known manner, terminals specially designed for their use on public or semi-public sites public. They therefore have specificities in terms of elements components and software, energy consumption, ergonomics, of use, etc., which are well known in themselves and will not be not detailed further.
Each public telephone 10 therefore comprises a certain number of particular elements inherent in a public telephone, in particular for ergonomics. There are in particular display devices and data entry, such as a screen 11 and a keyboard 12 to keys. On the other hand, the public telephone 10 implements software for exchanging and representing information according to specific formats better suited to its ergonomics, that operating according to the principles of hypermedia links.
In addition, to allow connection to different servers and in particular to PROXY 6, PMS 5 or FTP 4, phones 10 are equipped with TCP / IP communication protocols in accordance with technical recommendations of the Internet Engineering Task (IETF) Strength ").
The PROXY 6 combines different functions. A first function consists in directing requests from public telephones 10, according to the nature of these requests, to the corresponding servers. This is there a rerouting function which does not store or put update the list of addresses of servers likely to be called by phones 10 only in PROXY 6 and not in each of telephone terminals 10, the latter then only needing know the only address of the PROXY 6. This provision facilitates considerably the network maintenance operations of telephony 1.

WO 02/06201

7 PCT/IB02/00284 _7_ 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 â
fInternet 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 est 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ée 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 mises 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 composent ayant été présentés, 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 sessions 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 à
réaliser.
Cette demande de travail est principalement de trois types : ordre « DOWNLOAD » de transfert de fichiers du F'TP 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 fichiers sont formulés en utilisant le protocole suivant Pour le chargement de fichiers ftp://uu:pw@163.285.6.45/upload/123456-05-time.cess avec - ftp/ / demande d'ouverture de session 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 ;
- 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-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 ftp/ / demande d'ouverture de session 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-repertoïre 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 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 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és 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
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 F'TP 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 ftp: / /uu:pw@163.285.6.45/upload/ 123456-05-time.01 ftp:/ /uu:pw@163.285.6.45/upload/ 123456-05-time.02 ftp://uu:pw@163.285.6.45/upload/123456-05-time.03 Un ordre peut également comporter plusieurs instructions UPLOAD
ftp: / /uu:pw@ 163.285.6.45/upload/ 123456-05-time.01 ftp://uu:pw@163.285.6.45/upload/123456-05-time.02 ftp: / /uu:pw@ 163.285.6.45/upload/ 123456-05-time.03 Après avoir reçu un ordre de type « UPLOAD » ou a DOWNLOAD », le téléphone 10 ouvre une session FTP avec le FTP 4 dont l'adresse lui a été notifiëe. La connexion au FTP 4 en parallèle à la session courante est établie avec le PMS 5 via le PROXY 6. Le téléphone exécute ensuite le transfert de fichiers) demandé auprès du (ou des) serveurs) 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 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é
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. Gela 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 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 qui 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 fInternet 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" 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/v02r00e02/groupl (groupl nom du répertoire de destination d'un premier lot de fichiers) groupl.filel = 03-002-000-001.40 fichier à charger) group I .~1e2 = 03-002-000-001. 41 fichier à charger) group 1, file3 = 03-002-000-001. 42 ~chieY à charger) group 1. file4 = 03-002-000-001. 43 fichier à charger) group 1. files = 03-002-000-001. 70 (fichier à charger) groupl.file6 = 03-002-000-001.71 (fichier à charger) groupl ~1e7 = 03-002-000-001.4A fichier à charger) groupl.file8 = 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.filel = 03-002-000-001.?4 fichier à chargeY) group2. filet = 03-002-000-001. ?5 fichier à charger) group2. file3 = 03-002-000-001. 76 (fichier à charger) group2. file4 = 03-002-000-001. 79 fichier à charger) group2. files = 03-002-000-001. 7B (chier à eharger) 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 téléphones à 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 « UPLOAD » relatifs â la télécollecte, un ordre « DOWNLOAD » spécifique.
Cet ordre consiste à demander au téléphone de télécharger les fichiers listés dans le script.
Pour un script donné, le PMS 5 pourra balayer les unes après les autres les lignes d'instructions et 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 10 interrompt la session 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 ».
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érée par le PMS
5, seul 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 mises 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 session 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 session se déroule selon le déroulement que décrit ci-dessus (« ACCEPT » puis échange d'ordres « UPLOAD », « DOWNLOAD » ou « DISCONNECT » et d'acquittements) .
7 PCT / IB02 / 00284 _7_ To communicate with the PMS 5, all you need is a telephone to send a message to PROXY 6, message whose content, for example "connection" is enough to be interpreted by PROXY 6 as a message intended for PMS 5. It is then up to PROXY 6 to find in its memories the IP address of the PMS 5 and to transmit the message.
A second function consists, when necessary, in translate the data or instructions sent by the phones 10 to format of recipient servers. So in case of connections â
fInternet and the Web, this involves translating the protocol used by public telephones 10 in the appropriate protocol (http, RMI, pop3 ...), and vice versa to transfer information from the Web and the Internet to phones 10.
Another function of PROXY 6 is to control the syntax of requests made by the telephones 10 before retransmission and thus allow authenticated backward network access (security). Another function is to establish exchange sessions reliable and authenticated information which consists for example in to identify with certainty the 10 telephones during an exchange information with servers, or to encrypt data in order to secure the communication in case of need.
Another function of PROXY 6 is to control and regulate the exchange of information via file transfers standards and compliant with Internet protocols.
The PROXY 6 also has the function of directing requests from public telephones to emergency servers, particularly in the event of server downtime and thus provide redundancy architecture. Thus, in the hypothesis where the PROXY 6 is found inaccessible due in particular to maintenance operations, it is then possible to direct the daily reports of the telephones public 10 correspondents to another management server then available. This failover from one server to another is then completely transparent for public telephones 10 which do not have thus manage emergency addresses themselves but only the address of PROXY 6. The redundancy of PROXY 6 itself is _ $ _ also possible avoiding communication breakdowns in the event of failure noted.
In practical terms, PROXY 6 can consist of a PC type computer running Windows NT (registered trademark) or Linux, etc.
Any request to connect to a server arrives on the port input of the computer which is constantly listened to by the PROXY 6, then is redirected to a work port. The request is then analyzed by a software application, for example in Java language (registered trademark) allowing the control and establishment of a session in the protocol sense of the term. A standard interface ("Socket") is then opened and the request is sent to the server destination, and vice versa.
Obviously, the illustrated embodiment has not been given as an example and is absolutely not limitative of all of the solutions that can be implemented thanks to the present invention.
PROXY 6, PMS 5 and FTP 4, instead of being separate machines as in figure 1, can be grouped in a single PC type computer for example.
The public telephone network 1 and the various elements which make it up having been presented, we will now detail the method used to transfer data between PMS 5 and phones 10.
Each telephone 10 initiates the connection to the PMS 5 by a "CONNECT" type message generated through programs specific implemented by the microprocessors equipping the telephone 10. The process of connecting a telephone to the PMS 5, as well as the one used to transfer data or even communication protocols used are known in themselves (and standardized) and will not be detailed further.
The event triggering the connection of phone 10 to PMS 5 can be of different types. Connection can be initiated manually by a maintenance agent for example during the installation of a new telephone 10 in the network 1. The connection can be triggered automatically following for example the occurrence of an alarm (full coin mechanism, breakdown, vandalism, etc.), alarm generated by appropriate monitoring programs. The connection can also be automatically triggered for activity reports generated by supervision programs appropriate, reports providing statistics on the activity of the telephone 10 and intended for the operator of network 1 in order to improve the operation of the latter. These supervision programs can edit their activity report at dates and times predetermined or even at times defined by the PMS 5. The phone can also connect to PMS 5 upon request express of the latter who gave the order during a previous call to phone 10 to connect for a given reason: for example for downloading files.
This “CONNECT” connection message essentially comprises the following information - the identifier of telephone 10, for example its number call;
- the type of telephone 10, that is to say its product code;
- the type of session, that is to say the context of the call:
remote collection (activity report), download (transfer of file to phone, usually this is an order given by the PMS 5), alarms, etc. ;
a signature authenticating this telephone 10, this signature can for example be obtained by encryption using a DES (Data Encryption) type cryptology algorithm Standard) or any other type (RSA, etc.).
Telephone 10 thus has a list of standard sessions which define a priori the reason for calling the phone 10. In general and with the exception of alarms, this call was programmed during a previous session.
The PMS 5, which receives this “CONNECT” call, first proceeds to its analysis and in particular to the verification of the authenticity of this call then returns an acceptance message "ACCEPT" which includes in other data: the current date and time in order to carry out a resynchronization between the two devices as well as the time and date of the next scheduled call.

PMS 5 then sends a first work request to achieve.
This work demand is mainly of three types: order "DOWNLOAD" of file transfer from F'TP 4 to phone 10, “UPLOAD” order to transfer files from phone 10 to FTP
4 and “DISCONNECT” order to stop communication.
Preferably the files transfer orders are formulated in using the following protocol For loading files ftp: // uu: pw@163.285.6.45/upload/123456-05-time.cess with - ftp / / FTP session opening request, here as example;
- uu: user name;
- pw: password, name and password are used to operate the connection on the FTP;
- @ 163.285.6.45: IP address of the FTP where to download the files;
- upload: indicates the recipient directory (location) associated with a file name as follows - 123456: identifier of telephone 10 retrieved from the "CONNECT"(dynamic);
- 05: type of telephone 10 recovered in the "CONNECT"(dynamic);
- time (HH: MM: SS): current time allowing uniquely identify a file, thus avoiding conflicts related to the possible allocation of the same identifier to multiple phones, - cess: unique identifier of the file to be transferred (by example 02 for a file containing transactions).
"Upload / 123456-05-time.cess" therefore defines both the directory where the “.cess” file should be copied and the name of the file assigned.
For downloading files ftp: / / uu: pw @ 163.285.6.45/ download / work / aa-bbb-ccc-ddd.ee with ftp / / request to open FTP session, here as example;
- uu: user name;
- pw: password, name and password are used to operate the connection on the FTP server;
- @ 163.285.6.45: IP address of the FTP server where download files;
- download: indicates the source root directory (location) in which one will find sub directories associated with software objects (parameters, table of price, advertising ...) - work: plain sub-directory (to improve readability files) containing a specific type of object (price table, advertising, settings);
- aa-bbb-ccc-ddd.ee: name of the file to transfer.
Each file to be transferred from FTP 4 to phone 10 receives a name according to a specific syntax. For example, each file can be given a name like "aa-bbb-ccc-ddd.ee" where "aa" is a two-digit number denoting the type of telephone considered;
"bbb" is a three-digit number denoting the version of the file;
"ccc" is a three-digit number denoting the revision of the file;
"ddd" is a three-digit number designating the extension of the file;
"ee" is a sequence of two alphanumeric characters designating the file proper identified by type ("21" for a table of settings).
"Download / work / aa-bbb-ccc-ddd.ee" thus defines the directory, the sub-directory and the name of the file to retrieve.
Each aa-bbb-ccc-ddd.ee file concerns an element particular of all the software resources of the telephones 10.
Indeed, inside the memories of the microcontroller equipping the electronic circuits (or hardware) of each telephone 10, are therefore stored all the data and programs forming all software resources (or software) necessary for the good phone operation 10.
According to the embodiment described, these data and programs are divided into three distinct groups of objects: software, parameter tables and tariff tables. This list is good obviously non-limiting and can be increased according to the telephone functionality (advertising, media, etc.). Such a division into three types of objects which aims to simplify the operation of the network by the operator, and in particular the handling of the PMS 5, is not of course in no way limit the present invention, which still applies even if the data and programs are not differentiated according to distinct groups. Obviously, each A separate group of objects is made up of a number of files.
Each file corresponds to a modular breakdown, i.e.
that it only deals with a given functionality or that a number limited functionality.
Thus, software is broken down into several tens of software modules among which we can cite by way of example: a telephone line security module, a management module coins (if the phone accepts coins), a module payment card management, a handset management module, a screen management module, a tax management module received from the line, an energy management module, a modem management, etc.
Thus, among the parameter tables are the characterizations of the telephone network to which telephone 10 is connected, the authorizations to access certain services, the various language used to display the phone: French, English, German, Spanish or Arabic, Chinese, Russian, etc.
This modularity of the files aims to allow interventions the most precise and quickest, especially for operations download. So when a new version of software is update it's easier to only load in the hundreds if not the thousands of phones affected than this new version rather than restart the download of all software including those who have not evolved.

Of course the files to transfer from phone 10 to FTP
4 can if necessary adopt the same syntax. In general, files to transfer from phone 10 to F'TP are files from results (status, activity report, alarm, etc.), they can therefore however, adopt a syntax different from that of the files to be loaded in telephones 10.
File transfer orders issued by the PMS 5 to destination phones 10 can have a single instruction and are succeed sequentially according to the following sequence ftp: / /uu:pw@163.285.6.45/upload/ 123456-05-time.01 ftp: / /uu:pw@163.285.6.45/upload/ 123456-05-time.02 ftp: // uu: pw@163.285.6.45/upload/123456-05-time.03 An order can also contain several instructions UPLOAD
ftp: / / uu: pw @ 163.285.6.45/upload/ 123456-05-time.01 ftp: // uu: pw@163.285.6.45/upload/123456-05-time.02 ftp: / / uu: pw @ 163.285.6.45/upload/ 123456-05-time.03 After receiving an order of type "UPLOAD" or a DOWNLOAD ", telephone 10 opens an FTP session with FTP 4 whose address has been notified. Connection to FTP 4 in parallel to the current session is established with PMS 5 via PROXY 6. The phone then executes file transfer) requested from the FTP server (s) which has been notified to him. Once the transfer of the file (s) is complete, the phone sends an acknowledgment message by which it confirms at PMS 5 that the work has been done well or badly. Then he puts himself on hold of a new order. If a new order is not received after the phone cuts off communication for a predetermined period of time.
Such a communication strategy between PMS 5 and telephones 10, of the master slave type: the PMS 5 orders the phones run, provides very great flexibility in file transfers, since nothing is frozen. The sessions of communication between phones 10 and PMS 5 are as well adaptable as needed.
For example, the PMS 5 can benefit from the call of each phone 10 for its daily activity report (also called telecollect) to download an update from program.. .
For example, when initializing a new phone 10 to public telephone network 1, the commissioning agent will systematically request certain information related to phone 10 configuration (for example a file of configuration) and this through the launch of a dedicated session. In return, the PMS will not only be able to transfer the requested file but also get other table type files in return active tariff, a passive tariff table, a parameter table, a blacklist, gray list, software, etc.
Similarly, during a daily report telecollection session PMS 5 will not only be able to recover files from transactions, operating counters and alarms but also he will be able to download in return an active tariff table, a passive tariff table, a parameter table, a black list, a greylist, software, etc.
It is important to note that the different servers 4, 5 and 6 can be on different communication networks. The present invention therefore makes it possible to easily overcome networks and distribute servers as best as possible.
According to a particular embodiment of the invention, the first order received by telephone 10 from PMS 5 concerns the transfer of a file also called STATUS specifying the references of all or the main files constituting its resources software. This allows PMS 5 later, in case of possible malfunction, determine different versions of software used by phone 10.
In the exchanges between the PMS 5 and the telephones 10, the PMS 5 is always responsible for the files transferred, this is the master. Due to the architecture described, the PMS 5 is able, on analysis of the precise call context of each telephone 10, of ask the latter for a given work, which can be modified and adapted freely and easily, in particular according to the wishes of network operator 1.
Such flexibility also has no impact on 10 telephones which operate in "slave" mode. The list of files to be transferred one way or another is therefore found dynamically communicate to phones 10 through PMS 5 and this after identification of the connection, through specific requests CONNECT, ACCEPT, UPLOAD, DOWNLOAD, DISCONNECT. The phones do not know in advance which files to transfer, only the PMS 5 chooses the files to transfer.
Regarding the upload of files to FTP 4 transfer to phones 10, different solutions are possible.
We can for example choose the following solution.
These files, whether they are parameter tables, prices or software or any other object, have been prepared through specific tools which are loaded into PMS 5 by example by means of a CD ROM, a floppy disk or any other support readable by the PMS or even by means of a network of adapted communication, whether private or public, such as fInternet or the Web.
The files to be loaded in the phones are accompanied by minus a corresponding script. A script is a text file comprising a series of instruction lines intended to be executed by the PMS 5. A script includes in particular the tree or directory where the files will be located, the list of these files as well as instructions like interrupts or disconnections.
By choice, we can group all the files to transfer on a single script or even use several scripts if necessary, for example by grouping files according to their type.
In the latter case, we can then have a script "rate tables", a script "parameter tables", a script "software".
Consider the case of a specific script by object type.
Each script is then identified by a name like xxxx.yyy where "xxxx" is the name of the script and ".yyy" the type of files considered for example ".cli" for software, ".tt" for rate tables, ".tp"
for parameter tables, etc.
A script contains for example lines of code of the type groupl.dir - soft / v02r00e02 / groupl (groupl name of destination directory of a first batch of files) groupl.filel = 03-002-000-001.40 file to load) group I. ~ 1e2 = 03-002-000-001. 41 file to load) group 1, file3 = 03-002-000-001. 42 ~ chieY to load) group 1. file4 = 03-002-000-001. 43 file to load) group 1. files = 03-002-000-001. 70 (file to load) groupl.file6 = 03-002-000-001.71 (file to load) groupl ~ 1e7 = 03-002-000-001.4A file to load) groupl.file8 = 03-002-000-002.4B (file to load) ; S-disconnect here group2.dir = soft / v02r00e02 / group2 (group2: directory destination of a second batch of files) group2.filel = 03-002-000-001.?4 file dependent)) group2. net = 03-002-000-001. ? 5 file to upload) group2. file3 = 03-002-000-001. 76 (file to load) group2. file4 = 03-002-000-001. 79 file to upload) group2. files = 03-002-000-001. 7B (file to download) group2 file6 = 03-002-000-001.7E (file to load) group2.file7 = 03-002-000-001.7F file to load) ..... "
This script and any other scripts concerning other types files are therefore copied to the PMS 5 together with the listed files. Once the scripts and files are installed in the PMS
5, the file download process is triggered in the phones, not without having previously selected the affected phones. Indeed, it may be that only part of the phones managed by PMS 5 require file loading.
This loading process has three stages. the uploading files to FTP 4, programming different affected phones and uploading files to them phones from FTP 4. Several methods can be adopted for the realization of these three stages.
Either the steps in the download process are clearly separate: files are first loaded by PMS 5 into FTP 4 as soon as the download process starts, the phones 10 are then programmed by PMS 5 one after the other as and as they connect to retrieve the files from the FTP
4, finally the phones 10 transfer the files from the FTP 4 to their microprocessors.
Either the stages of the download process are linked and the files are loaded into FTP 4 at the same time as the processing of the first phone on the list (launch of the current download).
Whatever the process adopted, the course of these different steps are based on the PMS 5 on the scripts.
Consider the solution that the different stages are linked. Once the order has been given to download the files to a predetermined batch of telephones, the PMS 5 waiting for the affected phones to show up. Indeed, each telephone 10 of network 1 regularly connects to PMS 5 to send him a telecollection (or more irregularly for specific reports such as the occurrence of an anomaly). When the PMS 5 identifies, in the telephone which calls it, one of the telephones affected by the file upload operation that was launched, it inserts into the different "UPLOAD" orders relating to the remote collection, a specific DOWNLOAD order.
This order consists of asking the phone to download the files listed in the script.
For a given script, the PMS 5 can scan one after the other others the instruction lines and execute the instructions in alternately addressing FTP 4 and telephone 10 (DOWNLOAD 1, DOWNLOAD 2, DOWNLOAD 3, DOWNLOAD 4, etc.).
Depending on the size of the files to download, the progress of the script can be done all at once or several times. In case of unfolding in several times, the script includes instructions disconnect intermediaries. Upon receipt of this order, the phone 10 interrupts the current session and reminds a new one predetermined schedule.
At the end of the current execution of the script, all of the files are loaded into FTP 4 and then into phone 10.
When the first script is finished, we then go to following (if there are several scripts) after installing beforehand working memory (flash) of the received file (identification, decompression, writing, integrity ...) and we start the process again supra.
When all the scripts have been executed, the last file of the last script that was copied to phone 10, and to the since this was the last file transfer order in the from PMS 5, communication stops by sending the order "DISCONNECT".
Throughout these operations, the phone was able to simultaneously access FTP 4 and PMS 5 thanks to the use of the TCP / IP communication protocol.
Obviously, when a second phone and then every connect to PMS 5 to download the files, copying files to FTP 4 is no longer performed by the PMS
5, only the transfer of the instructions to the telephones remains know how to provide the list of files to copy and their location.
The method described above for transferring files between the PMS 5 and 10 phones via FTP 4 were given as an example and admits many variations. So when the call of the first phone on the list to download, we can transfer a file to FTP 4 then ask the phone to copy and so on file by file.
This method offers great flexibility in the transfer of file, since this transfer can be done module by module or even functionalities by functionalities, which removes the constraints of prior art, where the files were unique and global. This method makes it possible to standardize the transfer of files by proposing a single and general management method for all the objects to transfer whatever their nature or number. This mode of dynamic management by which the telephones carry out transfers according to instructions issued by PMS 5 and describing the work is therefore without impact either on the phones or on the PMS 5, while according to the prior art a treatment procedure had to be developed specifically for each transfer.
Obviously, the illustrated embodiment has not been given as an example and is absolutely not limitative of all of the solutions that can be implemented thanks to the present invention.
Thus the network of public telephones described above can be replaced by any network of service devices having a need to transmit information in particular to a server management, for example parking meters, distributors ATMs or bank terminals.
To operate the programming of a telephone, the PMS 5 can execute not the original script but a copy made specifically for this phone. Thus, it is possible to act on the original script, for example by changing the name of a file to transfer, without disturbing the download operations in progress.
So since all the files to be transferred are stored in one clearly identified directory of FTP 4, it is possible to transfer to phones 10 only the name of this directory without them file names, the phones then transferring all of the directory files.
FTP 4 may not be part of the same machine even from the same network but could be in other places (geographical distribution).
Thus, if in the embodiments described above, the telephone 10 initiates the communication during which the file transfer, this cannot be limited to the present invention. Such communication can therefore also be initiated by the PMS 5. In this case, during the connection, the PMS 5 informs the phone 10 that a session of a given type of file transfer is going start. In response to this command, telephone 10 responds with a "CONNECT" message of the above type and the rest of the session takes place according to the process described above ("ACCEPT" then exchange of “UPLOAD”, “DOWNLOAD” or “DISCONNECT” orders and of acquittals).

Claims (10)

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). 1/ Method for transferring data from a service device (10) to a remote central computer (5), the service device (10) being capable of communicating said data to said computer (5) by through appropriate transmission means (2,4,6), characterized in that the data to be transferred from said service apparatus (10) to said remote computer (5) are determined by said computer (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.
2 / A method for transferring data according to claim 1, characterized in that said data is produced by means appropriate software and hardware and correspond to functions of supervision and control of the operation of said service device (10), each data having to be transferred to said central computer at a given rhythm specific to the nature of the function to which it matches.
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 session de communication avec ledit ordinateur à distance (5) ;
- ledit appareil de service (10) fournit un code de session 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).
3 / A method for transferring data according to claim 2, characterized in that it comprises the following steps:
- said service device (10) opens a communication session with said remote computer (5);
- said service device (10) provides a session code specifying said computer the nature of the data it wishes to transfer;
- said computer (5) then transmits instructions to said device as to the data to be actually transferred;
- said service device (10) then transfers back the data requested by said computer (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). 4 / A method for transferring data according to claim 3, characterized in that during said communication, said computer (5) also transmits instructions to transfer data to said service device (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 (10) comprennent des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans ledit appareil de service (10). 5 / A method for transferring data according to claim 4, characterized in that said data to be transferred to said apparatus service (10) include software means replacing or supplementing software means already installed in said device for department (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. 6/ Process for transferring data according to any of the preceding claims, characterized in that said data are transferred in the form of computer files. 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). 7 / A method for transferring data according to claim 6, characterized in that said files transferred from the service apparatus (10) to the computer (5) include activity reports describing the transactions carried out by said service device (10) during a given period or even alarm reports describing malfunctions affecting said service device (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. 8/ Process for transferring data according to any of the preceding claims, characterized in that the transfers of files between said computer (5) and said service device (10) are using the TCP/IP communication protocol. 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).
9 / A method for transferring data according to claim 8, characterized in that said data passes between said device (10) and the remote central computer (5) by an FTP server (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. 10 / A method for transferring data according to claim 9, characterized in that the address of said FTP server (4) is communicated said service device (10) by said computer (5) during each transfer.
CA002436718A 2001-01-30 2002-01-29 Method for transferring data between a service apparatus and a remote management server Abandoned CA2436718A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0101343A FR2820261B1 (en) 2001-01-30 2001-01-30 METHOD FOR TRANSFERRING DATA BETWEEN A SERVICE APPARATUS AND A REMOTE MANAGEMENT SERVER
FR01/01343 2001-01-30
PCT/IB2002/000284 WO2002062017A1 (en) 2001-01-30 2002-01-29 Method for transferring data between a service apparatus and a remote management server

Publications (1)

Publication Number Publication Date
CA2436718A1 true CA2436718A1 (en) 2002-08-08

Family

ID=8859489

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002436718A Abandoned CA2436718A1 (en) 2001-01-30 2002-01-29 Method for transferring data between a service apparatus and a remote management server

Country Status (4)

Country Link
EP (1) EP1366602A1 (en)
CA (1) CA2436718A1 (en)
FR (1) FR2820261B1 (en)
WO (1) WO2002062017A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2847403B1 (en) * 2002-11-19 2005-02-25 Schlumberger Systems & Service METHOD AND DEVICE FOR PROCESSING DATA EXCHANGED BETWEEN A PLURALITY OF SERVICE TERMINALS AND A SUPERVISION SERVER
FR2857186B1 (en) * 2003-07-03 2005-10-14 Schlumberger Systems & Service METHOD FOR ROUTING CALLS FROM A SERVICE DEVICE TO A MANAGEMENT SERVER

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2796233B1 (en) * 1999-07-09 2001-08-31 Schlumberger Systems & Service OPEN ARCHITECTURE TELEPHONY SYSTEM

Also Published As

Publication number Publication date
WO2002062017A1 (en) 2002-08-08
FR2820261A1 (en) 2002-08-02
EP1366602A1 (en) 2003-12-03
FR2820261B1 (en) 2003-05-02

Similar Documents

Publication Publication Date Title
US8522313B2 (en) Method and apparatus for data file transfer using destination linked directories
FR2711026A1 (en) System for managing the consumption of data consultations over a telecommunications network.
EP1145522B1 (en) Method and architecture for remote monitoring of a user station via an internet-type network and application thereof to a smart card demonstrator
FR2823932A1 (en) Application/services distribution over distributed architecture network having agent user terminal resident IRC server communicating user communications layer/protocol interactive link allowing XML message communications.
EP3812945B1 (en) Open and secure system for processing electronic signature request and associated method
EP2169569A1 (en) Method and system for communication between distinct web applications
EP1192796B1 (en) Payphone management system
CA2436718A1 (en) Method for transferring data between a service apparatus and a remote management server
EP0755001A1 (en) Architecture for wrapping applications running on a data processing platform
EP1334598A1 (en) Method for transferring files between service appliances and a remote management server
WO2003015433A1 (en) Method of transferring customised data in a service apparatus
FR2541014A1 (en) METHOD FOR PROTECTING A SOFTWARE RECORDED BY A SUPPLIER ON A PORTABLE MAGNETIC MEDIUM
WO2018029564A1 (en) System and method for authentication of a user of an application system by a central server, without using a password
FR2860318A1 (en) ELECTRONIC INVESTIGATION METHOD
FR2890217A1 (en) Mail franking system, has franking machine comprising web server, and personal computers and portable digital terminal each including web navigator for accessing franking management application disposed at server
WO2010034928A1 (en) Platform for a computer network
FR2826751A1 (en) METHOD FOR EXCHANGE OF DATA BETWEEN A SERVICE DEVICE AND A MANAGEMENT SERVER ACCORDING TO A MANAGEMENT PROTOCOL OVER IP
OA20002A (en) Open and secure electronic signature request processing system and associated method.
WO2004004294A1 (en) Method for individualizing a terminal connected to at least one server through a network
EP2423811A1 (en) Method and device for non-disruptive testing of the operation of an application for supplying information accessible on certain dates
EP0730767A1 (en) Data processing system and method and remote acquisition systems comprising said system
WO2001091432A1 (en) Method for managing a public telephone network providing access to internet, public telephone and management server therefor
FR2776874A1 (en) Automatic electronic information transmission
WO2002089446A2 (en) Improved server for data management between a network and user terminals, and related data processing device and method
WO2003103307A1 (en) Method for sending short messages by means of a public telephone network

Legal Events

Date Code Title Description
FZDE Discontinued