WO2002062017A1 - Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance - Google Patents

Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance Download PDF

Info

Publication number
WO2002062017A1
WO2002062017A1 PCT/IB2002/000284 IB0200284W WO02062017A1 WO 2002062017 A1 WO2002062017 A1 WO 2002062017A1 IB 0200284 W IB0200284 W IB 0200284W WO 02062017 A1 WO02062017 A1 WO 02062017A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
data
service device
files
transferring data
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.)
Ceased
Application number
PCT/IB2002/000284
Other languages
English (en)
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
Axalto Inc
Original Assignee
Schlumberger Systemes SA
Schlumberger Malco Inc
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 Schlumberger Systemes SA, Schlumberger Malco Inc filed Critical Schlumberger Systemes SA
Priority to CA002436718A priority Critical patent/CA2436718A1/fr
Priority to EP02701469A priority patent/EP1366602A1/fr
Publication of WO2002062017A1 publication Critical patent/WO2002062017A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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

Definitions

  • the present invention relates to a method for transferring data between service apparatuses and a remote management server.
  • the present invention relates more particularly to a file transfer method between a management server and the telephones of a public telephone network.
  • a public telephone network consists of public telephones distributed over a given territory. Public telephones are connected to a communication network, constituted for example by the switched telephone network PSTN (acronym for Public Switching Telephone Network), with which they communicate
  • PSTN switched telephone network
  • This network could be of another type (ISDN, GSM, Internet, .
  • a public telephone network generally includes one (or more) central computer or management server, hereinafter called PMS (acronym of the Anglo-Saxon term “Payphone Management”
  • This PMS which is connected to the switched telephone network, has the function of exchanging data with the public telephone fleet.
  • 25 activity report detailing the number and amount of transactions, etc. They also communicate in the form of an alarm the eventual occurrence of an event (breakdown, act of vandalism, etc.) requiring the intervention of a maintenance agent.
  • the PMS transfers files to public telephones
  • the present invention therefore aims to remedy these drawbacks by simplifying and rationalizing the transfer of data between a remote management server 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 remote central computer, such as a management server, the service device being able to communicate the data to the computer through appropriate means of transmission.
  • a service device such as a public telephone
  • a remote central computer such as a management server
  • the method for transferring data is characterized in that the data to be transferred from the service device to the remote computer is determined by the computer alone.
  • the data are produced by appropriate software and hardware means and correspond to functions of supervision and control of the operation of the service apparatus, each data having to be transferred to said central computer. at a given rate specific to the nature of the function to which it corresponds.
  • it comprises the following steps:
  • the service device opens a communication transfer with said remote computer; - the service device provides a session code specifying to said computer the nature of the data it wishes to transfer;
  • the computer having ensured the authenticity of the call from the service device (syntax check, by checking a secret code, by checking the range of products, etc.), then transmits instructions to the device as to what data should actually be transferred. - the service device then transfers the data requested by the computer back.
  • the computer can also transmit instructions for transferring data to the service apparatus.
  • the data to be transferred from the computer to the service device includes software means replacing or supplementing software means already installed in the service device.
  • the data are transferred in the form of computer files.
  • the files to be transferred from the service device to the computer include activity reports describing the transactions carried out by the service device during a given period or even reports alarms describing malfunctions affecting said service appliance.
  • the file transfers between the computer and the service device are carried out using the TCP / IP communication protocol thus allowing the transfer through the Internet network.
  • the data passes between the service appliance and the remote central computer by an FTP server.
  • Figure 1 is a schematic view of a public telephone network used for the implementation of the method according to the invention. Only the elements of the public telephone network and its environment have been shown which are necessary for understanding the invention.
  • FIG 1 there is shown a public telephone network 1.
  • This network includes a fleet of public telephones 10 (the same fleet may include several tens to several thousand telephones, or even several tens of thousands, depending on the territorial coverage of the network).
  • the telephones 10 are intended for use by self-service users and are therefore installed for this purpose in public places, such as the street, or semi-public places, such as shopping centers, airports, hotel lobbies, restaurants, shops, etc.
  • This telephone network 2 is of analog switched type PSTN (Public Switching Telephone Network) or of digital switched type ISDN (Integrated Services Digital Network) .
  • This network 2 can also be constituted by a mobile radiotelephony network, whatever its nature: GSM, CDMA, TDMA, AMPS, D-AMPS, or even by the Internet network or more generally by any communication network capable of transmit data (X25, Ethernet, etc.) as well as by any combination of such networks.
  • These public telephones 10 can also be adapted to access information or service servers for the Web and the Internet, as well as information or service servers residing on private networks. Such access allows the operator, operating the network 1, to offer users a wide range of services, ranging for example and without limitation, from reading their e-mails to consulting local information (lists of doctors on duty in the public telephone area, etc.).
  • the invention is not limited to public telephones offering such access to the Internet and to private servers.
  • These public telephones 10 are moreover adapted to communicate with a server 5 also called PMS (acronym English- Saxon "Payphone Management System”) dedicated to the operation and management of the public telephone network 1.
  • PMS cronym English- Saxon "Payphone Management System”
  • the function of the PMS 5 is to exchange information with the fleet of public telephones 10 concerning their operation and more generally the operation of the public telephone system.
  • the PMS 5 manages the initialization sessions of public telephones and establishes statistical data from information received from public telephones 10 (alarms, operating counters, etc.).
  • the public telephones 10 and the PMS 5 are provided with appropriate means of supervision and of reception / transmission of information, these means which are in themselves known will not be described in more detail.
  • These supervision and reception / transmission means are responsible for organizing the exchange of information between the public telephones 10, the PMS 5 and an FTP server 4 whose role will be detailed below, and in particular to control transfers of data or software, between public telephones 10 and FTP 4.
  • the PMS 5 transfers to the public telephones 10 the files necessary for their operation, such as rate tables, configuration parameters (such as the type of dialing, the characteristics of the line, etc.), lists. opposition or monitoring of the means of payment used.
  • the public telephones 10 transmit, for their part, information relating to their use, namely a daily report comprising data relating to the transactions carried out, to the traffic, an alarm report which makes it possible to report to the PMS 5 the occurrence of incidents or damage to their integrity, such as a breakdown in the card reader or a handset that has been torn off, so as to provide for the intervention of a surveillance agent, a status file characterizing the content of the telephone (such as the indications of the different versions of programs used by the microprocessor), etc.
  • a server 4 is specifically designed and adapted to the transfer of files 4, called FTP (for File Transfer Protocol). From orders received by the PMS 5, each public telephone 10, which integrates a client FTP entity, will connect to FTP 4 and download or download the appropriate files.
  • FTP File Transfer Protocol
  • the public telephones 10 can connect to a PROXY 6 server, serving as a communication interface between the public telephones 10 and the PMS 5.
  • a PROXY 6 server serving as a communication interface between the public telephones 10 and the PMS 5.
  • the functions of the PROXY 6 will be described in more detail below.
  • Each public telephone 10 therefore includes a certain number of particular elements inherent in a public telephone, in particular for ergonomics.
  • display and data entry devices such as a screen 11 and a keyboard 12 with keys.
  • the public telephone 10 implements software making it possible to exchange and represent information according to specific formats better adapted to its ergonomics, although operating according to the principles of hypermedia links.
  • the telephones 10 are equipped with TCP / IP communication protocols in accordance with the technical recommendations of 1TETF ("Internet Engineering Task Force") .
  • the PROXY 6 combines different functions.
  • a first function consists in directing the requests from public telephones 10, according to the nature of these requests, to the corresponding servers. This is a re-routing function which makes it possible to store and update the list of addresses of the servers likely to be called by the telephones 10 only in the PROXY 6 and not in each of the terminals. 10, they only need to know the PROXY 6 address alone. This arrangement considerably facilitates maintenance operations for the telephone network 1.
  • to communicate with the PMS 5 it suffices for a telephone to send a message to the PROXY 6, a message the content of which, for example "connection", is sufficient to be interpreted by the PROXY 6 as a message intended for the PMS 5. It is then up to the PROXY 6 to find the IP address of the PMS 5 in its memories and to transmit the message to it.
  • a second function consists, when necessary, in translating the data or instructions transmitted by the telephones 10 into the format of the destination servers. So in the case of connections to the Internet and the Web, it is a question of translating the protocol used by public telephones 10 into the appropriate protocol (http, RMI, pop3 %), and vice versa to transfer information from the Web and from the Internet to phones 10.
  • PROXY 6 Another function of the PROXY 6 is to control the syntax of the requests sent by the telephones 10 before retransmission and thus authorize authenticated accesses to the network further back (security). Another function is to establish reliable and authenticated information exchange sessions which consists, for example, in certain identification of the telephones 10 during an exchange of information with the servers, or even in encrypting the data in order to secure communication if necessary.
  • PROXY 6 Another function of PROXY 6 is to control and regulate the exchange of information carried out via standard file transfers and in accordance with Internet protocols.
  • the PROXY 6 also has the function of directing requests from public telephones to backup servers, in particular in the event of the unavailability of a server, thereby ensuring architecture redundancy.
  • the PROXY 6 is inaccessible as a result in particular of maintenance operations, it is then possible to direct the daily reports of the corresponding public telephones 10 to another management server then available. This switching from one server to another is then completely transparent for public telephones 10 which do not have to manage emergency addresses themselves but only the address of PROXY 6.
  • the redundancy of PROXY 6 itself East also possible avoiding communication breakdowns in the event of a breakdown.
  • the PROXY 6 can consist of a PC-type computer running Windows NT (registered trademark) or even Linux, etc.
  • Any request to connect to a server reaches the input port of the computer, which is listened to permanently by the PROXY 6, then is redirected to a working port.
  • the request is then analyzed by a software application, for example in Java language (registered trademark) allowing the control and the 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 destination server, and vice versa.
  • PROXY 6, the PMS 5 and the FTP 4 instead of being separate machines as in FIG. 1, can be grouped together in a single PC type computer for example.
  • the public telephone network 1 and the various elements which compose it having been presented, we will now detail the method used to transfer data between the PMS 5 and the telephones 10.
  • Each telephone 10 initiates the connection to the PMS 5 by a “CONNECT” type message generated by means of specific programs implemented by the microprocessors equipping the telephone 10.
  • CONNECT type message generated by means of specific programs implemented by the microprocessors equipping the telephone 10.
  • the process of connecting a telephone to the PMS 5, as well as that used to transfer data or the communication protocols used are known in themselves (and standardized) and will not be detailed further.
  • the event triggering the connection of the telephone 10 to the PMS 5 can be of different types.
  • the 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 (coin operated full, breakdown , vandalism, etc.), alarm generated by appropriate monitoring programs.
  • the connection can also be triggered automatically for activity reports generated by appropriate supervision programs, reports providing statistics on the activity of the telephone 10 and intended for the operator of the network 1 in order to improve the functioning of the latter. .
  • These supervision programs can publish their activity report at predetermined dates and times or even at times defined by the PMS 5.
  • the telephone can also connect to the PMS 5 following the express request 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 the telephone 10, for example its telephone number;
  • the type of session that is to say the context of the call: telecollection (activity report), download (file transfer to the phone, in general this is a given prior order by PMS 5), alarms, etc. ;
  • this signature can for example be obtained by encryption by means of a cryptology algorithm of DES type (Data Encryption Standard) or of any other type (RSA, etc.).
  • the telephone 10 thus has a list of standard sessions which a priori define the reason for the call to the telephone 10. In general and with the exception of the alarms, this call was programmed during a previous session.
  • the PMS 5 then sends a first request for work to be carried out.
  • This work request is mainly of three types: "DOWNLOAD” order to transfer files from FTP 4 to phone 10, "UPLOAD” order to transfer files from phone 10 to FTP 4 and "DISCONNECT” order to stop Communication.
  • file transfer orders are formulated using the following protocol:
  • ftp // uu: pw@163.285.6.45/u ⁇ load/ 123456-05-time.cess with: ftp / / request to open an FTP session, here as an example; uu: user name; - pw: password, name and password are used to operate the connection on the FTP;
  • 05 type of telephone 10 retrieved from "CONNECT” (dynamic); - time (HH: MM: SS): current time to uniquely identify a file, thus avoiding conflicts related to the possible allocation of the same identifier to several phones, cess: unique identifier of the file to be transferred (for example 02 for a file containing transactions).
  • IP address of the FTP server where to download the files indicates the source root directory (location) in which there are sub-directories associated with software objects (parameters, price table, advertising ...): work: plain sub-directory (to improve the readability of files) containing a specific type of object (price table, advertising, parameters); - aa-bbb-ccc-ddd.ee: name of the file to transfer.
  • Each file to be transferred from FTP 4 to telephone 10 is given a name according to a determined syntax.
  • each file can be given a name like "aa-bbb-ccc-ddd.ee" where:
  • ccc is a three-digit number designating the revision of the file
  • ddd is a three-digit number designating the file extension
  • Each aa-bbb-ccc-ddd.ee file concerns a particular element of the set of software resources of the telephones 10.
  • this data and programs are divided into three distinct groups of objects: software, parameter tables and rate tables.
  • This list is obviously not exhaustive and can be increased depending on the functionality of the telephones (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 of course in no way limitative of the present invention, which still applies even if the data and programs are not differentiated according to separate groups.
  • each separate group of objects is made up of a number of files.
  • Each file corresponds to a modular division, that is to say it only deals with a given functionality or only a limited number of functionalities.
  • a telephone line security module a coin management module (if the phone accepts coins), a module payment card management, a handset management module, a screen management module, a management module for charges received from the line, an energy management module, a modem management module, etc.
  • the parameter tables are the characterizations of the telephone network to which the telephone 10 is connected, the authorizations for access to certain services, the different language fonts used for displaying the telephone: French, English, German, Spanish or still Arabic, Chinese, Russian, etc.
  • This modularity of the files aims to allow the most precise and quickest interventions, especially for download operations.
  • the files to be transferred from the telephone 10 to the FTP 4 can if necessary adopt the same syntax.
  • the files to be transferred from the telephone 10 to the FTP are results files (status, activity report, alarm, etc.), they can therefore however adopt a different syntax than that of the files to be loaded into the telephones 10.
  • the file transfer orders issued by the PMS 5 to the telephones 10 can comprise a single instruction and follow one another sequentially according to the following sequence: UPLOAD 1 ftp: / /uu:pw@163.285.6.45/upload/ 123456-05- time.01
  • An order can also include several instructions UPLOAD ftp: / /uu:pw@163.285.6.45/upload/ 123456-05-time.01 ft ⁇ : // uu: pw@163.285.6.45/upload/ 123456-05-time.02 ftp: // uu: pw@163.285.6.45/u ⁇ load/ 123456-05-time.03
  • the telephone 10 After receiving an “UPLOAD” or “DOWNLOAD” type order, the telephone 10 opens an FTP session with the FTP 4 whose address has been notified to it. The connection to FTP 4 in parallel to the current session is established with PMS 5 via PROXY 6. The phone then performs the transfer of file (s) requested from the FTP server (s) which has been notified to it. . Once the transfer of the file (s) is complete, the phone sends an acknowledgment message by which it confirms to the PMS 5 that the work has been done well or badly. Then he waits for a new order. If a new order is not received after a predetermined period of time, the phone disconnects the call.
  • the PMS 5 can take advantage of the call from each telephone 10 for its daily activity report (also called telecollect) to operate the downloading of a program update ...
  • the commissioning agent will systematically request certain information related to the configuration of the telephone 10 (for example a configuration file) and this through the launch of a dedicated session.
  • the PMS will not only be able to transfer the requested file but also obtain other files in return, such as an active tariff table, a passive tariff table, a parameter table, a black list, a gray list, software, etc.
  • the PMS 5 will not only be able to recover transaction files, operating counters and alarms, but also it will be able to download in return an active tariff table , a passive tariff table, a parameter table, a black list, a gray list, software, etc.
  • the present invention therefore makes it possible to easily overcome networks and distribute servers as best as possible.
  • the first order received by a telephone 10 from the PMS 5 relates to the transfer of a file also called STATUS specifying the references of the set or of the main files constituting its software resources . This subsequently allows the PMS 5, in the event of a possible malfunction, to determine the different versions of software used by the telephone 10.
  • the PMS 5 In the exchanges between the PMS 5 and the telephones 10, the PMS 5 is always the decision maker as to the files transferred, it is the master. Due to the architecture described, the PMS 5 is able, on analysis of the precise call context of each telephone 10, to ask the latter for a given job, which can be freely and easily modified and adapted, in particular according to the wishes of the network operator 1.
  • a script is a text file comprising a series of lines of instructions intended to be executed by the PMS 5.
  • a script includes in particular the tree structure or directory where the files will be located, the list of these files as well as instructions such as interrupts or disconnections.
  • file7 03-002-000-001.4A (file to load) groupl.
  • file ⁇ 03-002-000-002.4B (file to load);
  • S-disconnect hère group2.dir soft / v02r00e02 / group2 (group2: destination directory for a second batch of files) group2.
  • file5 03-002 -000-001.7B (file to load) group2.
  • This loading process has three stages: downloading the files to FTP 4, programming the various phones concerned and loading the files into the telephones from FTP 4.
  • Several methods can be adopted for carrying out these three steps.
  • the files are first loaded by the PMS 5 in FTP 4 as soon as the download process is started, the telephones 10 are then programmed by the PMS 5 one after the other at as and when they are connected to retrieve the files from the FTP 4, finally the telephones 10 transfer the files from the FTP 4 to their microprocessors.
  • 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 telephone in the list is executed (launch of the current download session).
  • the PMS 5 waits for the telephones concerned to appear.
  • each telephone 10 on the network 1 connects regularly to the PMS 5 to send it a telecollection (or more irregularly for specific reports such as the occurrence of an anomaly).
  • the PMS 5 identifies, in the telephone calling it, one of the telephones concerned by the file download operation which has been launched, it inserts into the various "UPLOAD" orders relating to the remote collection, an order " DOWNLOAD »specific.
  • This order consists of asking the phone to download the files listed in the script.
  • the PMS 5 can scan the instruction lines one after the other and execute the instructions, addressing itself alternately to FTP 4 and to phone 10 (DOWNLOAD 1, DOWNLOAD 2, DOWNLOAD 3, DOWNLOAD 4 , etc.).
  • the script sequence can be done at once or in several times. If run in several times, the script includes intermediate instructions for disconnection. Upon receipt of this order, the telephone 10 interrupts the current session and calls back at a new predetermined time.
  • This method offers great flexibility in file transfer, since this transfer can be done module by module or even functionalities by functionalities, which removes the constraints of the 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 mode for all of the objects to be transferred regardless of their nature or their number.
  • This dynamic management mode by which phones execute transfers according to instructions issued by the PMS 5 and describing the work is therefore without impact either on the telephones or on the PMS 5, whereas according to the prior art a treatment procedure had to be developed specifically for each transfer.
  • the illustrated embodiment has been given by way of example and is in no way limitative of all the solutions that can be implemented thanks to the present invention.
  • the network of public telephones described above can be replaced by any network of service apparatuses having a need to transmit information in particular to a management server, for example parking meters, automatic distributors or even bank terminals.
  • the PMS 5 can execute not the original script but a copy made specifically for this telephone.
  • FTP 4 may not be part of the same machine or even the same network but could be located in other places (geographic distribution).
  • the telephone 10 initiates the communication during which the file transfer will take place, this cannot be limiting of the present invention.
  • Such communication can therefore also be initiated by the PMS 5.
  • the PMS 5 informs the telephone 10 that a session of a given type of file transfer will start.
  • the telephone 10 responds with a “CONNECT” message of the aforementioned type and the rest of the session takes place according to the procedure described above (“ACCEPT” then exchange of orders “UPLOAD”, “DOWNLOAD "Or” DISCONNECT "and acknowledgments).

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'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).

Description

(54) Titre : PROCEDE DE TRANSFERT DE DONNEES ENTRE UN APPAREIL DE SERVICE ET UN SERVEUR DE GES- TIONA DISTANCE
PROCEDE DE TRANSFERT DE DONNEES ENTRE UN APPAREIL DE SERVICE ET UN SERVEUR DE GESTION A DISTANCE.
5 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.
10 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 Téléphone Network), avec lequel ils communiquent
15 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
20 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
25 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,
30 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
35 le PMS sont des opérations rigides, lourdes en temps et donc coûteuses. Ainsi, un téléphone public qui télécharge des fichiers doit être basculé en mode hors service et ne peut être utilisé par les usagers tout le temps d'une opération, qui peut durer plusieurs heures compte tenu de la taille actuelle des programmes et des données à charger. 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. - 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 œuvre du procédé selon l'invention. Seuls ont été figurés les éléments du réseau de téléphonie publique et de son environnement qui sont nécessaires à la compréhension de l'invention.
Sur la figure 1, on a représenté un réseau 1 de téléphonie publique. Ce réseau comprend un parc de téléphones publics 10 (un même parc peut comprendre de plusieurs dizaines à plusieurs milliers de téléphones, voire plusieurs dizaines de milliers, suivant la couverture territoriale du réseau).
Les téléphones 10 sont destinés à être utilisés par les usagers en libre service et sont donc installés à cette fin dans des lieux publics, tels que la rue, ou semi-publics, tels que des centres commerciaux, des aéroports, halls d'hôtels, restaurants, magasins, etc.
Ces téléphones 10 permettent aux usagers d'effectuer des communications téléphoniques, en utilisant un réseau téléphonique approprié référencé 2. Ce réseau téléphonique 2 est de type commuté analogique PSTN (Public Switching Téléphone Network) ou de type commuté numérique ISDN (Integrated Services Digital Network). Ce réseau 2 peut également être constitué par un réseau de radiotéléphonie mobile et ce, quelle que soit sa nature : GSM, CDMA, TDMA, AMPS, D-AMPS, ou encore par le réseau Internet ou plus généralement par tout réseau de communication apte à transmettre des données (X25, Ethernet,..) ainsi que par toute combinaison de tels réseaux.
Ces téléphones publics 10 peuvent être également adaptés pour accéder à des serveurs d'informations ou de fourniture de services du Web et de l'Internet, ainsi qu'à des serveurs d'informations ou de fourniture de services résidant sur des réseaux privés. De tels accès permettent à l'opérateur, exploitant le réseau 1, de proposer aux usagers une large palette de services, allant par exemple et à titre non limitatif, de la lecture de leurs courriers électroniques à la consultation d'informations locales (listes des médecins de gardes de la zone du téléphone public, etc.).
Bien évidemment l'invention n'est pas limitée aux téléphones publics offrant de tels accès à l'Internet et à des serveurs privés. Ces téléphones publics 10 sont par ailleurs adaptés pour communiquer avec un serveur 5 encore appelé PMS (acronyme anglo- saxon de « Payphone Management System ») dédié au fonctionnement et à la gestion du réseau de téléphonie publique 1.
Le PMS 5 a pour fonction d'échanger avec le parc de téléphones publics 10 des informations concernant leur fonctionnement et plus généralement le fonctionnement du système de téléphonie publique. En particulier, le PMS 5 gère les sessions d'initialisation des téléphones publics et établit des données statistiques à partir des informations reçues des téléphones publics 10 (alarmes, compteurs d'exploitation...) . Les téléphones publics 10 et le PMS 5 sont munis de moyens appropriés de supervision et de réception/ émission d'informations, ces moyens qui sont en eux-mêmes connus ne seront pas décrits plus en détail. Ces moyens de supervision et de réception/ émission sont chargés d'organiser les échanges d'informations entre les téléphones publics 10, le PMS 5 et 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, 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 œuvre 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 1TETF (« 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 correspondants. Il s'agit là d'une fonction de re-routage qui permet de ne stocker et de ne mettre à jour la liste des adresses des serveurs susceptibles d'être appelés par les téléphones 10 que dans le PROXY 6 et non dans chacun des terminaux téléphoniques 10, ces derniers n'ayant alors besoin que de connaître la seule adresse du PROXY 6. Cette disposition facilite considérablement les opérations de maintenance du réseau de téléphonie 1. Ainsi, pour communiquer avec le PMS 5, il suffit à un téléphone d'adresser un message au PROXY 6, message dont le contenu, par exemple «connexion», suffit à être interprété par le PROXY 6 comme un message destiné au PMS 5. A charge alors pour le PROXY 6 de trouver dans ses mémoires l'adresse IP du PMS 5 et de lui transmettre le message.
Une seconde fonction consiste, quand cela est nécessaire, à traduire les données ou instructions émises par les téléphones 10 au format des serveurs destinataires. Ainsi en cas de connexions à l'Internet et au Web, il s'agit de traduire le protocole utilisé par les téléphones publics 10 dans le protocole approprié (http, RMI, pop3...), et inversement pour transférer les informations du Web et de l'Internet vers les téléphones 10.
Une autre fonction du PROXY 6 est de contrôler la syntaxe des requêtes émises par les téléphones 10 avant retransmission et autoriser ainsi des accès authentifiés au réseau plus en arrière (sécurité). Une autre fonction est d'établir des sessions d'échange d'informations fiables et authentifiées qui consiste par exemple à identifier de façon certaine les téléphones 10 lors d'un échange d'informations avec les serveurs, ou encore à encrypter les données afin de sécuriser la communication en cas de besoin.
Une autre fonction du PROXY 6 est de piloter et réguler les échanges d'informations réalisés via des transferts de fichiers standards et conformes aux protocoles Internet. Le PROXY 6 a également pour fonction de diriger les requêtes des téléphones publics vers des serveurs de secours notamment en cas d'indisponibilité d'un serveur et assurer ainsi une redondance d'architecture. Ainsi, dans l'hypothèse où le PROXY 6 se trouve inaccessible par suite notamment d'opérations de maintenance, il est alors possible de diriger les comptes-rendus journaliers des téléphones publics 10 correspondants vers un autre serveur de gestion alors disponible. Ce basculement d'un serveur vers un autre 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 œuvre 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 œuvre 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 FTP 4 vers le téléphone 10, ordre « UPLOAD » de transfert de fichiers du téléphone 10 vers le FTP 4 et ordre « DISCONNECT » d'arrêt de la communication.
De préférence les ordres de transfert de fichiers sont formulés en utilisant le protocole suivant :
Pour le chargement de fichiers : ftp://uu:pw@163.285.6.45/uρload/ 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-repertoire en clair (pour améliorer la lisibilité des fichiers) contenant un type d'objet précis (table de tarif, publicité, paramètres); - aa-bbb-ccc-ddd.ee : nom du fichier à transférer.
Chaque fichier à transférer du FTP 4 vers le téléphone 10 reçoit un nom selon une syntaxe déterminée. Par exemple, chaque fichier peut recevoir un nom du type suivant "aa-bbb-ccc-ddd.ee" où :
"aa" est un numéro à deux chiffres désignant le type de téléphone considéré;
"bbb" est un numéro à trois chiffres désignant la version du fichier;
"ccc" est un numéro à trois chiffres désignant la révision du fichier; "ddd" est un numéro à trois chiffres désignant l'extension du fichier;
"ee" est une suite de deux caractères alphanumériques désignant le fichier proprement dit identifié par type (« 21» pour une table de paramètres). « download/work/ aa-bbb-ccc-ddd.ee » définit ainsi le répertoire, le sous-répertoire et le nom du fichier à rapatrier.
Chaque fichier aa-bbb-ccc-ddd.ee concerne un élément particulier de l'ensemble des ressources logicielles des téléphones 10.
En effet, à l'intérieur des mémoires du microcontrôleur équipant les circuits électroniques (ou hardware) de chaque téléphone 10, sont donc stockés l'ensemble des données et des programmes formant 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 FTP sont des fichiers de résultats (status, rapport d'activité, alarme, etc.), ils peuvent donc toutefois adopter une syntaxe différente de celle des fichiers à charger dans les téléphones 10.
Les ordres de transfert de fichier émis par le PMS 5 à destination des téléphones 10 peuvent comporter une seule instruction et se succéder séquentiellement selon la séquence suivante : UPLOAD 1 ftp:/ /uu:pw@163.285.6.45/upload/ 123456-05-time.01
UPLOAD 2 ftp:/ /uu:pw@163.285.6.45/upload/ 123456-05-time.02
UPLOAD 3 ftp:/ /uu:pw@163.285.6.45/upload/ 123456-05-time.03
Un ordre peut également comporter plusieurs instructions UPLOAD ftp:/ /uu:pw@163.285.6.45/upload/ 123456-05-time.01 ftρ://uu:pw@163.285.6.45/upload/ 123456-05-time.02 ftp://uu:pw@163.285.6.45/uρload/ 123456-05-time.03
Après avoir reçu un ordre de type « UPLOAD » ou « 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 fichier(s) demandé auprès du (ou des) serveur(s) FTP qui lui a été notifié. Une fois le transfert du ou des fichiers achevé(s), le téléphone adresse un message d'acquittement par lequel il confirme au PMS 5 que le travail a été bien ou mal fait. Puis il se met en attente d'un nouvel ordre. En cas de non-réception d'un nouvel ordre après un laps de temps prédéterminé, le téléphone coupe la communication.
Une telle stratégie de communication entre le PMS 5 et les téléphones 10, de type maître esclave : le PMS 5 ordonne les téléphones exécutent, offre une très grande souplesse en matière de transferts de fichiers, puisque rien n'est figé. Les sessions de 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. Cela permet ultérieurement au PMS 5, en cas d'éventuel dysfonctionnement, de déterminer les différentes versions de logiciels utilisés par le téléphone 10.
Dans les échanges entre le PMS 5 et les téléphones 10, le PMS 5 est toujours décisionnaire quant aux fichiers transférés, c'est le maître. De part l'architecture décrite, le PMS 5 est à même, sur analyse du contexte précis d'appel de chaque téléphone 10, de demander à ce dernier un travail donné, modifiable et adaptable librement et facilement, notamment en fonction des souhaits de l'exploitant du réseau 1.
Un telle souplesse est par ailleurs sans incidence sur les téléphones 10 qui fonctionnent en mode « esclave ». La liste des fichiers à transférer dans un sens ou dans un autre se trouve donc communiquer dynamiquement aux téléphones 10 par le PMS 5 et ce après identification de la connexion, au travers de requêtes précises : CONNECT, ACCEPT, UPLOAD, DOWNLOAD, DISCONNECT. Les téléphones ne connaissent donc pas à l'avance les fichiers à transférer, c'est uniquement le PMS 5 qui choisit les fichiers à transférer.
Pour ce qui 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 l'Internet ou le Web.
Les fichiers à charger dans les téléphones sont accompagnés d'au moins un script correspondant. Un script est un fichier textuel comprenant une série de lignes d'instructions destinées à être exécutées par le PMS 5. Un script comprend notamment l'arborescence ou répertoire où seront localisés les fichiers, la liste de ces fichiers ainsi que des instructions comme des interruptions ou déconnexions.
Par choix, on peut regrouper l'ensemble des fichiers à transférer sur un seul script ou bien encore utiliser plusieurs scripts si nécessaire, par exemple en regroupant les fichiers selon leur type. Dans ce dernier cas, on peut alors avoir un script "tables de tarifs", un script "tables de paramètres", un script "logiciels".
Considérons le cas d'un script spécifique par nature d'objet. Chaque script est alors identifié par un nom de type xxxx.yyy où : "xxxx" 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 = sofi/v02r00e02/groupl (groupl nom du répertoire de destination d'un premier lot de fichiers) groupl.filel = 03-002-000-001.40 (fichier à charger) groupl.file2 = 03-002-000-001.41 (fichier à charger) groupl.file3 = 03-002-000-001.42 (fichier à charger) groupl.file4 = 03-002-000-001.43 (fichier à charger) groupl. fiîeδ = 03-002-000-001.70 (fichier à charger) groupl. fileβ = 03-002-000-001.71 (fichier à charger) groupl. file7 = 03-002-000-001.4A (fichier à charger) groupl. fileδ = 03-002-000-002.4B (fichier à charger) ; S-disconnect hère group2.dir = soft/ v02r00e02/ group2 (group2 : répertoire de destination d'un second lot de fichiers) group2.filel = 03-002-000-001.74 (fichier à charger) group2.fιle2 = 03-002-000-001.75 (fichier à charger) group2.file3 = 03-002-000-001.76 (fichier à charger) group2.fi.le4 = 03-002-000-001.79 (fichier à charger) group2.file5 = 03-002-000-001.7B (fichier à charger) group2. fileβ = 03-002-000-001.7E (fichier à charger) group2.fιle7 = 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 œuvre 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) .

Claims

REVENDICATIONS
1/ Procédé pour transférer des données d'un appareil de service (10) à un ordinateur central à distance (5), l'appareil de service (10) étant apte à communiquer lesdites données audit ordinateur (5) par l'intermédiaire de moyens de transmission (2,4,6) appropriés, caractérisé en ce que les données à transférer dudit appareil de service (10) vers ledit ordinateur à distance (5) sont déterminées par ledit ordinateur (5).
2/ Procédé pour transférer des données selon la revendication 1, caractérisé en ce que lesdites données sont produites par des moyens logiciels et matériels appropriés et correspondent à des fonctions de supervision et de contrôle du fonctionnement dudit appareil de service (10), chaque donnée devant être transférée audit ordinateur central à un rythme donné spécifique à la nature de la fonction à laquelle elle correspond.
3/ Procédé pour transférer des données selon la revendication 2, caractérisé en ce qu'il comporte les étapes suivantes : ledit appareil de service (10) ouvre une 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).
4/ Procédé pour transférer des données selon la revendication 3, caractérisé en ce que lors de ladite communication, ledit ordinateur (5) transmet également des instructions pour transférer des données vers ledit appareil de service (10).
5/ Procédé pour transférer des données selon la revendication 4, caractérisé en ce que lesdites données à transférer vers ledit appareil de service (10) comprennent des moyens logiciels remplaçant ou complétant des moyens logiciels déjà installés dans ledit appareil de service (10).
6/ Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites données sont transférées sous la forme de fichiers informatiques.
7/ Procédé pour transférer des données selon la revendication 6, caractérisé en ce que lesdits fichiers transférés de l'appareil de service (10) vers l'ordinateur (5) comprennent des rapports d'activité décrivant les transactions opérées par ledit appareil de service (10) pendant une période donnée ou encore des rapports d'alarmes décrivant des dysfonctionnements affectant ledit appareil de service (10).
8/ Procédé pour transférer des données selon l'une quelconque des revendications précédentes, caractérisé en ce que les transferts de fichiers entre ledit ordinateur (5) et ledit appareil de service (10) se font en utilisant le protocole de communication TCP/IP.
9/ Procédé pour transférer des données selon la revendication 8, caractérisé en ce que lesdites données transitent entre ledit appareil de service (10) et l'ordinateur central à distance (5) par un serveur FTP (4).
10/ Procédé pour transférer des données selon la revendication 9, caractérisé en ce que l'adresse dudit serveur FTP (4) est communiquée audit appareil de service (10) par ledit ordinateur (5) lors de chaque transfert.
PCT/IB2002/000284 2001-01-30 2002-01-29 Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance Ceased WO2002062017A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA002436718A CA2436718A1 (fr) 2001-01-30 2002-01-29 Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance
EP02701469A EP1366602A1 (fr) 2001-01-30 2002-01-29 Procede de transfert de donnees entre un appareil de service et un serveur de gestion a distance

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/01343 2001-01-30
FR0101343A FR2820261B1 (fr) 2001-01-30 2001-01-30 Procede de transfert de donnees entre un appareil de service et un serveur de gestion a distance

Publications (1)

Publication Number Publication Date
WO2002062017A1 true WO2002062017A1 (fr) 2002-08-08

Family

ID=8859489

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2002/000284 Ceased WO2002062017A1 (fr) 2001-01-30 2002-01-29 Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance

Country Status (4)

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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2847403B1 (fr) * 2002-11-19 2005-02-25 Schlumberger Systems & Service Procede et dispositif de traitement de donnees echangees entre une pluralite de terminaux de service et un serveur de supervision
FR2857186B1 (fr) * 2003-07-03 2005-10-14 Schlumberger Systems & Service Procede de routage d'appels d'un appareil de service vers un serveur de gestion

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2796233A1 (fr) * 1999-07-09 2001-01-12 Schlumberger Systems & Service Systeme de telephonie a architecture ouverte

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2796233A1 (fr) * 1999-07-09 2001-01-12 Schlumberger Systems & Service Systeme de telephonie a architecture ouverte

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WILLIAMS L D L: "PAYPHONE REMOTE MANAGEMENT SYSTEMS", BRITISH TELECOMMUNICATIONS ENGINEERING, BRITISH TELECOMMUNICATIONS ENGINEERING. LONDON, GB, VOL. 11, NR. PART 2, PAGE(S) 85-89, ISSN: 0262-401X, XP000297298 *

Also Published As

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

Similar Documents

Publication Publication Date Title
EP1590931B1 (fr) Procede de presentation d'etat d'un utilisateur utilisant plusieurs equipements de communication
EP0647052B1 (fr) Système de gestion de la consommation de consultations de données sur un réseau de télécommunications
EP1145522B1 (fr) Procede et architecture de pilotage a distance d'une station d'utilisateur via un reseau de type internet
FR2823932A1 (fr) Systeme et procede pour la distribution dynamique de donnees et/ou de services
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
EP1192797B1 (fr) Gestion de telephones publics
WO2002062017A1 (fr) Procede de transfert de donnees entre un appareil de service et un serveur de gestiona distance
FR2816784A1 (fr) Procede de transfert de fichiers entre des appareils de service et un serveur de gestion a distance
EP1415491A1 (fr) Procede pour transferer des donnees personnalisees dans un appareil de service
FR2541014A1 (fr) Procede de protection d'un logiciel enregistre par un fournisseur sur un support magnetique portatif
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
EP1518390A1 (fr) Procede d individualisation d un terminal relie a au mo ins un serveur a travers un reseau
EP1933531B1 (fr) Dispositif de contrôle de communications sur IP entre des équipements de communication IP, avec prise de contrôle automatisée de leurs flux de média(s)
EP1279298A1 (fr) Dispositif de supervision de terminaux
EP2347367A1 (fr) Plate-forme de reseau informatique
FR2826751A1 (fr) Procede d'echange de donnees entre un appareil de service et un serveur de gestion selon un protocole de gestion sur ip
FR2890217A1 (fr) Systeme d'affranchissement en reseau a maintenance facilitee
EP1284086A1 (fr) Procede de gestion d'un reseau de telephonie publique permettant d'acceder a internet, telephone public et serveur de gestion pour sa mise en oeuvre
EP2423811A1 (fr) Procédé et dispositif de test non perturbatif de fonctionnement d'une application de fourniture d'informations accessibles à certaines dates
EP0730767A1 (fr) Systeme et procede de traitement de l'information, et systemes de telecollecte de donnees incluant ce systeme
EP1512301A1 (fr) Procede d envoi de messages courts par un reseau de telephonie publique
FR2824214A1 (fr) Serveur perfectionne de gestion de donnees entre un reseau et des terminaux d'utilisateur, et dispositif et procede de traitement de donnees associes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2436718

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 03065366

Country of ref document: CO

WWE Wipo information: entry into national phase

Ref document number: 2002701469

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002701469

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2002701469

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP