FR2826751A1 - METHOD FOR EXCHANGE OF DATA BETWEEN A SERVICE DEVICE AND A MANAGEMENT SERVER ACCORDING TO A MANAGEMENT PROTOCOL OVER IP - Google Patents

Abstract

The invention relates to a method of exchanging data between at least one service apparatus (10) and at least one remote management server (5) in compliance with a selected management protocol. The management protocol is IP and comprises at least one initiation rule for each exchange session and at least one recovery rule for launching a possible recovery in the event of an unsuccessful exchange.

Description

<Desc / Clms Page number 1>

The present invention relates to the exchange of data between a service apparatus and a management server according to a management protocol based on a data management protocol. Internet type protocol, still called "IP" for "Internet Protocol".

More particularly, it relates to the exchange and / or transfer of data such as files or alarms between a management server and service devices such as telephones of a public telephone network, payment terminals, terminals applications, time stamps, vending machines or the like.

In general, a public telephone network generally comprises one (or more) central computer or management server, hereinafter called PMS server ("Payphone Management System"), allowing the operator network to operate the supervision of different public telephones spread over a given territory of the network. The purpose of the PMS server is to exchange data with the public telephone pool via the telephony network.

In practice, the public telephones communicate to the server PMS an activity report detailing for example the number and amount of transactions. The public telephones also communicate in the form of alarm the eventual occurrence of an event (breakdown, vandalism, etc ...) requiring the intervention of a maintenance agent.

The PMS server, meanwhile, transfers to the public telephones files, tariff tables or updates of programs running the microprocessors of the phones, updates improving the programs already in operation.

<Desc / Clms Page number 2>

 place, or introducing new services for users.

Today, file transfers between public phones and the PMS server are managed according to a management protocol that has become obsolete, and out of sync with today's requirements of speed and evolution. In addition, each new function that impacts the current protocol generates comprehensive protocol tests. Similarly, a protocol modification usually involves a modification of all subsystems (payphones, bank servers). As a result, the current protocol is not adapted to changes in the market and / or services (electronic messaging type e-mail, SMS, or e-commerce type Internet services or the like).

The present invention overcomes these disadvantages.

It relates to a method for exchanging data between at least one service device and at least one remote management server in accordance with a selected management protocol.

According to a general definition of the invention, the management protocol is IP-based and comprises at least one initiation rule for initiating each exchange session and at least one recovery rule for initiating a possible recovery in case of non-compliance. completion of the exchange.

Thus, the management protocol according to the invention, by its operation over IP, provides a seal with respect to the network and thus allows a client / server dialogue on different types of networks (PSTN, ISDN, Internet). A connection is possible to various and varied networks without changing or adapting the communication protocol between the service devices and the server. A change in the protocol level data structure is easy and avoids changes to other layers of the IP protocol.

<Desc / Clms Page number 3>

In addition, such a protocol allows the management of data exchanges, particularly with regard to the initiation of sessions and their possible recovery in case of non-completion of the exchange. The protocol also allows you to work online (on-line) or off-line (off-line). Such a protocol is advantageously capable of being implemented in a wireless environment of the GSM, CDMA or TDMA type.

According to another characteristic of the invention, in the event of the interruption of an exchange session during which data is transferred from the apparatus to the server, the recovery rule comprises a step in which the transfer is resumed in full. if the device status changes.

According to yet another characteristic of the invention, in the event of the interruption of an exchange session during which the data is transferred from the server to the service apparatus, the recovery rule comprises a step according to which the session of exchange is resumed at the place of rupture without taking up the part of the exchange already made before the break.

Preferably, the recovery rule is adapted to the work to be performed by the service device, the importance of the task and its impact.

According to the invention, the recovery procedure may comprise a step of repeating the retry attempt indefinitely until the service apparatus is put back into operation and / or a step of deferring the resumption of a chosen period of time and or a step of resuming the exchange after a triggering of the service apparatus.

In practice, the initiation rule includes the following steps:

<Desc / Clms Page number 4>

- ii) au niveau du serveur, recevoir la requête de connexion"CONNECT", analyser les informations contenues dans ladite requête de connexion et émettre une réponse en fonction du résultat de l'analyse ; et

- iii) au niveau de l'appareil, recevoir la réponse, et en cas de réponse positive"ACCEPT", synchroniser le terminal et le serveur et établir la session d'échange. - i) at the service device, issue a connection request "CONNECT" to the server according to the protocol;

ii) at the server, receiving the connection request "CONNECT", analyzing the information contained in said connection request and issuing a response according to the result of the analysis; and

- iii) at the device level, receive the response, and in case of positive response "ACCEPT", synchronize the terminal and the server and establish the exchange session.

- iv) au niveau du serveur, à l'issue de la session d'échange, émettre un ordre de déconnexion"DISCONNECT"à destination de l'appareil de service ; et - v) au niveau de l'appareil, recevoir l'ordre de déconnexion"DISCONNECT"et arrêter la session d'échange. In practice, the management protocol includes a termination procedure comprising the following steps:

- iv) at the server level, at the end of the exchange session, issue a disconnect command "DISCONNECT" to the service apparatus; and - v) at the device, receive the disconnect command "DISCONNECT" and stop the exchange session.

According to another aspect of the invention, the data to be exchanged between the device and the server are determined by the server.

Other features and advantages of the invention will emerge in the light of the detailed description below and the drawings in which: FIG. 1 is a schematic view of a public telephone network used for carrying out the method according to FIG. invention; FIG. 2 diagrammatically illustrates the hardware architecture of the service apparatus and the server in which the management protocol according to the invention is inserted;

<Desc / Clms Page number 5>

 FIG. 3 illustrates the steps of initiating a session according to the IP protocol according to the invention; FIG. 4 illustrates the steps of downloading an FTP status file from the device to the server according to the invention; FIG. 5 illustrates the steps of downloading files on FTP from the device to the server and uploading files on FTP from the server to the device according to the invention; FIG. 6 illustrates the steps of downloading alarm files on FTP from the device to the server and downloading configuration files on FTP from the server to the device according to the invention; FIG. 7 illustrates the steps of downloading files on FTP from the device to the server according to the invention; FIGS. 8 and 9 illustrate the steps of examples of downloading files on FTP from the server to the apparatus according to the invention; FIG. 10 illustrates the steps of an exchange of messages from the apparatus to the server according to the invention; FIGS. 11 to 13 show examples of termination of a session according to the invention; FIGS. 14 to 17 show other examples of termination of a session according to the invention; FIGS. 18 to 23 show examples of session resumption policies according to the protocol of the invention;

<Desc / Clms Page number 6>

 FIGS. 24 to 28 show other examples of session recovery policies according to the protocol of the invention.

With reference to FIG. 1, there is shown a public telephone network 1 which comprises a park of public telephones 10 (the same park may comprise from 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 to be used by the users, self-service and are therefore installed for this purpose in public places, such as the street, or semi-public such as shopping centers, airports, hotel lobbies , restaurants, shops, etc ...

These telephones 10 allow users to make telephone calls, using a suitable telephone network referenced 2 which can be switched type, analog, or digital switched type. The network 2 can also be constituted by a mobile radio network and this, whatever its nature, or by the Internet or more generally by any communication network capable of transmitting data and any combination of such networks.

These public telephones 10 can also be adapted to access servers for information or for providing web services and the Internet as well as information servers or service providers residing on private networks. Such access allow the operator operating the network 1, to offer users a wide range of services ranging from, for example, and not limited to, reading their emails to the local information consultation (list of doctors guard of the area of the public telephone, etc ...).

<Desc / Clms Page number 7>

Obviously, the invention is not limited to public telephones offering such access to the Internet and private servers.

These public telephones 10 are also adapted to communicate with a server 5 called PMS (Payphone Management System), dedicated to the operation and management of the public telephony network 1. The PMS server 5 has the function of exchanging with the park of public telephones 10 information concerning their operation and more generally the operation of the public telephone system. In particular, the PMS server 5 manages the initialization sessions of the public telephones and establishes statistical data from the information received from the public telephones 10 (alarms, operating counters, etc.). The exchanges between the service devices 10 and the server 5 are in the form REQ request REQ response.

The public telephones 10 and the PMS server 5 are provided with appropriate means of supervision and reception / transmission of information. These supervision and reception / transmission means are responsible for organizing the exchange of information between the public telephones 10, the PMS server 5 and an FTP server 4 (File Transfer Protocol), that is to say "protocol of file transfer ".

Among other functions, the PMS server 5 transfers to public telephones the files necessary for their operation such as tariff tables, configuration parameters, such as the type of numbering, the characteristics of the line, etc. lists of opposition or surveillance of the means of payment used.

For their part, the public telephones 10 transmit information relating to their use, namely a daily report comprising data relating to the transactions carried out, the traffic, an alarm report which makes it possible to signal the PMS server 5 the occurrence of incidents. or damage to their integrity, such as a breakdown on the

<Desc / Clms Page number 8>

 card reader or a handset ripped, so as to provide for the intervention of a monitoring agent, a status file characterizing the contents of the phone (such as the indications of the different versions of programs used by the microprocessor).

To facilitate the exchange of data, an FTP server 4 is specifically designed and adapted to file transfers called FTP. From commands received by the PMS server 5, each public telephone 10 which integrates a client FTP entity, will connect to the FTP server 4 and download or download appropriate files.

In addition, the public telephones 10 can connect to a PROXY server 6 serving as a communication interface between the public telephones and the PMS server 5.

With reference to FIG. 2, to enable the connection to the various servers, and in particular to the PROXY server 6, the PMS server 5 or the FTP server 4, the service devices 10 (in this case telephones) are equipped with communication protocols 12 of the type TCP / IP, and 14 UDP / IP compliant with the technical recommendations of the Internet Engineering Task Force (IETF).

Each public telephone 10 comprises an operating system 16, a standard interface 18 of the "socket" type, a protocol 20 of the terminal or TELNET type for "Network Terminal Protocol" and a protocol 22 of the FTP client type.

The client-side PFSP management protocol (for the Payphone session protocol) according to the invention is housed in the layer 24.

For example, the service apparatus 10 is dedicated to an application 26 of the public telephone type.

For its part, the PMS server 5 is equipped with 32 TCP / IP type communication protocols and 34 UDP / IP

<Desc / Clms Page number 9>

 technical recommendations from the Internet Engineering Task Force (IETF).

The PMS server 5 further comprises an operating system (not shown), a standard interface 38 of the "socket" type, a protocol 40 of terminal type or TELNET for "Network Terminal Protocol" and a protocol 42 of FTP server type.

The server-side PFSP management protocol according to the invention is housed in the layer 44.

For example, the PMS server 5 is dedicated to an application 46 of the public telephone type.

The server PROXY 6 combines various functions, including directing requests from public telephones 10, depending on the nature of these requests, to corresponding servers; where appropriate translate the data or instructions issued by the telephones 10 to the format of the destination servers; control the syntax of the requests sent by the telephones 10 before retransmission and thus allow authenticated access to the network to confer an additional degree of security.

Another function of the PROXY server is to establish reliable and authenticated information exchange sessions which consist, for example, in identifying the phones 10 in an information exchange with the servers or in encrypting the data. to secure communication when needed.

Another function of the PROXY 6 server is to control and regulate the exchange of information made via standard file transfers and compliant with the Internet protocol.

The PROXY 6 server also has the function of directing the requests of the public telephones to backup servers, in particular in case of unavailability of a server and ensuring

<Desc / Clms Page number 10>

 thus a redundancy of architecture. Thus, in the event that the server PROXY 6 is inaccessible as a result notably 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 switch from one server to another is then completely transparent for the public telephones 10 which do not have to manage thus themselves backup addresses but only the address of the server PROXY 6. The redundancy of the server PROXY 6 him -Even is also possible, thus avoiding breaks in communication in case of faults. Any request to connect to a server arrives at the input port of the computer that is constantly listened to by the PROXY 6 server, and is redirected to a working port.

The request is then analyzed by a software application, for example in JAVAs language 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.

Of course, the illustrated embodiment has been given by way of example and is not exhaustive of all the solutions that can be implemented by virtue of the present invention.

Thus, the PROXY server 6, the PMS server 5 and the FTP file server 4, instead of being separate machines as in FIG. 1, can be grouped together in a single computer of the PC type for example, as with reference to FIG. Figure 2.

With reference to FIG. 3, the establishment of a session managed according to the PFSP management protocol according to the invention is advantageously a TCP / IP type session.

<Desc / Clms Page number 11>

The session is initiated (or initialized) by the apparatus 10 which sends an S-Connect message. req PMS server 5 generated through specific programs implemented by the microprocessors equipping the device 10. This message S-Connect. req is the connection request, still called "CONNECT".

The S-Connect message. req is routed to the server 5 via the network 2, and interpreted into an S-Connect message. ind. The server analyzes the S-Connect message. ind. After analysis, the server 5 sends an S-Connect message. res, which is the response of the server to the connection request, also called "ACCEPT", in case of a positive response.

The S-Connect message. res is routed to the telephone 10 via the network 2, and interpreted into S-Connect message. cnf, confirming the establishment of the TCP / IP session.

The event triggering the connection of the telephone 10 to the PMS server 5 may 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 (full coin, failure , vandalism, etc.). The alarm can be 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 the network operator signal 1 in order to improve the operation 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 server 5 following the express request of the latter who has given the order, during a previous call to the phone 10 to connect for a given reason: for example for downloading files.

<Desc / Clms Page number 12>

The CONNECT connection message essentially comprises the following information: the identifier of the telephone 10, for example its call number; - the type of telephone 10, ie its product code - the type of session, that is to say the context of the call: remote collection (activity report), download (file transfer to the phone, usually this is a prior order given by the PMS server 5), alarm, etc; the signature authenticating this telephone 10, this signature can be obtained by encryption by means of a cryptology algorithm of the DES type or of any other type (RSA for example).

The telephone 10 then has a list of typical sessions which define a priori the reason for the call of the telephone 10.

In general, and with the exception of alarms, this call has been programmed in a previous session.

The PMS server 5 which receives this CONNECT call proceeds first of all with its analysis and in particular with the verification of the authenticity of this call and then returns an acceptance message ACCEPT which includes, among other data, the date and the time. to re-synchronize between the two devices, as well as the time and date of the next scheduled call.

The PMS server 5 then sends a first job request to be made. This work request is mainly of three types: - file transfer order from the FTP server 4 to the telephone 10 (download in FTP format);

<Desc / Clms Page number 13>

 - Order of file transfers from the phone 10 to the FTP server 4 (upload in FTP format); and - stopping communication in TCP / IP (disconnect) format.

The protocol PFST for "payphone session protocol" allows according to the invention to initiate an exchange (a communication session) between a telephone 10 and a server using a TCP / IP format protocol.

This protocol allows the installation of a data exchange session between a client and a server on any type of network.

As described with reference to FIG. 3, the CONNECT connection message enables the initialization of the session.

Referring to Figure 4, in order to initialize a service device from the server, the server must retrieve a configuration file called "STATUS" of the service device. This configuration file must always be sent before the disconnect at the end of the session.

If the server 5 wishes, the service device can recover a file containing the active tariff table or a file containing the passive tariff table. Similarly, if the server wishes, the service apparatus can retrieve a parameter file, a blacklist, a gray list, a file containing segmented software and an object configuration file.

After the ACCEPT command, an actual FTP session can begin. It can be either a loading of UPLOAD files or a downloading of DOWNLOAD type files.

Regarding the UPLOAD download order, the server issues a S. File request. req. This request is

<Desc / Clms Page number 14>

 routed through the network to the corresponding phone.

The first order received by a telephone 10 from the server 5 concerns the transfer of a file still called STATUS specifying the references of all or the main files constituting the software resources of the phone. This STATUS file later allows the PMS server 5, in the event of a malfunction, to determine the different software versions used by the telephone 10. In the exchanges between the server 5 and the telephones 10, the PMS server 5 is still decision-maker as to the file. transferred, it's the master. By the architecture described, the PMS server 5 is able, on analysis of the specific call context of each telephone 10, to ask the latter a given work, modifiable and adaptable freely and easily, particularly according to the wishes of the customer. network operation. Such flexibility also has no effect on the phones 10 which operate in slave mode. The list of files to be transferred in one direction or another is therefore communicated dynamically to the telephone 10 by the PMS server 5 and after identification of the connection, through specific requests: CONNECT, ACCEPT, UPLOAD, DOWNLOAD, DISCONNECT.

The phones do not know in advance the files to transfer, it is only the PMS server that chooses the files to transfer.

Once the STATUTS file is routed through the network to the server, the telephone 10 issues a S. File response. res. This information is sent to the server via the network 2. Once received, this message constitutes a confirmation of the S. File type. Cnf.

With reference to FIG. 5, the file loading operation (UPLOAD) is initiated by the request S. File. Req according to the format described above. After receiving this request, the telephone 10 interprets this request and delivers the

<Desc / Clms Page number 15>

 S. FILE message. IND. Following this interpretation, the phone can, in the FTP format, load into the server various files that can be related to transactions, operating counters, common alarms, LOG files of alarms, counters relating to lists. black.

The loading of files is finished by the request S. File. res emanating from the service apparatus. This response is interpreted as a confirmation after receipt by the server.

After receiving a UPLOAD or DOWNLOAD type order, the telephone 10 opens an FTP session with the FTP server 4 whose address has been notified to it. The connection to the FTP server 4 in parallel with the current session is established with the PMS server 5 via the server PROXY 6. The phone then executes the requested file transfer from the FTP server that has been notified. Once the file (s) transfer (s) completed, the phone sends an acknowledgment message by which it confirms to the PMS server that the work was well or badly done. Then he waits for a new order. In case of non-receipt of a new order after a predetermined period of time, the phone cuts the communication as will be described in more detail below.

It should be noted that in the UPLOAD loading phase, the downloaded files include configuration files if at least one of the parameters has changed. This file is always sent before the termination order of the communication at the end of the session. For example, the PMS server 5 can take advantage of the call of each telephone 10 for its daily activity report (also called telecollect) to operate the download of a program update.

For example, during the initialization of a new telephone 10 to the public telephone network 1, the commissioning agent will systematically request certain information.

<Desc / Clms Page number 16>

 related to the configuration of the phone 10 (for example a configuration file) and this through the launch of a dedicated session. In return, the PMS server can not only transfer the requested file but also obtain other files in return active tariff table type, a passive tariff table, a parameter table, a blacklist, a gray list, a software , etc ...

Likewise, during a telecollection session of the daily activity report, the PMS 5 will not only be able to retrieve transaction files, operating counters and alarms, but will also be able to download an active tariff table in return. a passive tariff table, a parameter table, a blacklist, a gray list, a software.

With reference to FIG. 6, the session relating to the alarm report includes, as taught above, a request of the UPLOAD type at the end of which an FTP file is downloaded into the server.

The downloaded files can be a configuration file, alarm files present, log alarm file as well as transactions.

Following this downloaded file, a DOWNLOAD command can be followed and performed in order to download a configuration file from the server to the service device.

It should be noted that in the alarm report session, it is mandatory not to send in the S. CONNECT message. RES the daily postponement date.

Referring to Figure 7, the invention may also provide a remote diagnostic session in which files are downloaded to the server. These downloaded files may include a configuration file, a transaction file, an operating counter file, an alarm file, the Alarm Log, a file of

<Desc / Clms Page number 17>

 blacklist counter and a gray list counter file.

Referring to Figures 8 and 9, the server may also initiate a download session in which files are downloaded from the server to the corresponding service device. The downloaded files are, for example, active or passive tariff table files, a parameter file, a black or gray list file, a segmented software file and, where appropriate, an object configuration file.

The actual download session includes downloading a configuration file, etc.

With reference to FIG. 10, the protocol also makes it possible to manage requests for content and e-mail or e-mail sessions. The establishment of the session is initiated according to the protocol mentioned above with the orders CONNECT and ACCEPT. After establishing the connection, the phone issues a S. Methodinvoke request. req. This request corresponds to the GET / POST command in messaging under TCP / IP. The server receives this request via the telephony network and interprets in a request S. Methodinvoke. ind. The server analyzes this request and in response sends the message S. Methodinvoke.res which constitutes a replica or response of the server. The phone or service device confirms this response with the message S. Methodinvoke. cnf.

The session ends according to the protocol mentioned above with the order DISCONNECT.

The content transfer may contain one or more request (s) for content and transfer.

In case of abnormal session, the protocol provides several rules of treatment.

<Desc / Clms Page number 18>

According to the invention, the PFSP protocol provides several rules for dealing with abnormal sessions.

First, a session may be considered abnormal when the format of the request is incorrect. In this case, a "DISCONNECT" message is sent together with a PROTERR type code via the PROXY server to the PMS server and the corresponding service device.

With reference to FIG. 11, the establishment of the TCP / IP type connection or session may be refused by the communication server PROXY, for example when the service is not available. In this case, the communication server PROXY sends to the destination of the service device a message DISCONNECT which, once received by the service device, is interpreted in S. DISCONNECT. IND with the corresponding code CONNECTERR.

With reference to FIG. 12, the establishment of the connection may be refused by the PMS server. In this case, after the connection request from the service device, the server issues an S. DISCONNECT message. REQ containing the corresponding code that can have the definition REDIAL CONGESTION or PEERREQ depending on the event causing the refusal.

The DISCONNECT message is sent to the service unit.

With reference to FIG. 13, a delay, for example of the order of 30 seconds, may be provided after a first unsuccessful connection request. Thus, the service apparatus issues a termination request S. DISCONNECT. REQ with the PEERREQ code to the server, after a delay of 30 seconds with respect to its first connection request S. CONNECT. REQ.

Similarly, with reference to FIG. 14, a termination request from the server with the S. DISCONNECT message is provided. REQ and the PEERREQ code during a download

<Desc / Clms Page number 19>

 or a download that does not succeed at the end of a chosen period. This TX period has a value that depends on the number of files transferred and the size of each of these files. This TX period can be calculated by the server.

Referring to Figure 15, the service apparatus may issue a S. DISCONNECT session termination message. REQ with the CONGESTION code for the server when, for example, internal errors are detected or when RAM file management problems are detected at the service device. The coherence of the coding, notably its syntax, is verified by the communication server PROXY. The reason for the termination request is in the corresponding code, here CONGESTION.

Referring to Figure 16, a request for termination of session is issued by the server with the code corresponding to DISCONNECT REDIAL in the case of a download (DOWNLOAD).

Similarly, with reference to FIG. 17, a termination request required by the service apparatus with the S. DISCONNECT message. REQ and the PEERREQ code after a delay for example of 30 seconds.

This termination request can take place after a delay whose departure is formed by the result of the transfer.

The present invention also provides a protocol that manages the resumption of sessions, after breaks thereof. Thus, in response to a break in a session, there is provided a rule for resuming the session until the connection is re-established in order to be properly processed.

With reference to FIG. 18, the recovery management can take place in the case of a PFSP transaction, of the TCP / IP type, such as that described with reference to FIG.

<Desc / Clms Page number 20>

In this case, the recovery procedure is to renew the connection request S. CONNECT. REQ.

Referring to Figure 19, the resumption of the session can also occur after receiving the connection request with establishment of the connection at the server but before receiving the ACCEPT message at the service device.

Referring to Figure 20, the management of the recovery of the session can occur at the file download operation. For example, in case of difficulty in the status file of the service apparatus, the protocol according to the invention manages such a break.

Similarly, with reference to FIG. 21, the management of the recovery can take place at the level of a download of a file of the UPLOAD type.

The same is true with reference to FIG. 22 of the downloading operation of the DOWNLOAD type. In this case, a recovery policy is provided according to the invention.

With reference to FIG. 23, the management of the recovery can also take place during the break of the session before receiving the DISCONNECT message at the service apparatus.

According to the invention, the causes that trigger the management of the recoveries can be of different nature: - cut of the line, expiration of the delay or even technical problems at the level of the server, the modem of the service apparatus.

With reference to FIG. 24, no recovery management is provided during an initialization performed at the request of the operator.

<Desc / Clms Page number 21>

 With reference to FIG. 25, a first connection recovery attempt R1 is provided, for example, after 5 minutes of the break in the event of a fault in the value of a parameter. This attempt R1 in case of failure is repeated a number of times, for example 2 (individualized here in R2 and R3). In the case of a failure after the three attempts, the recovery policy does not provide for new attempts and the session is permanently interrupted. This recovery policy is for example implemented during a remote initialization or remote diagnosis.

With reference to FIG. 26, a particular recovery rule is provided in the case of a daily telecollection.

The recovery rule includes two branches of intervention.

In the first branch, the break C of the remote collection (for example due to a defect in the value of a parameter emanating from the server), the telecollect can be resumed at the end of a procedure which starts with the awakening the device (for example a request for communication from a public telephone user or the introduction of a payment card), followed by a sleeping and ending with the attempt of the resume 5 minutes after sleep. This attempt of recovery is preferably without limits, that is to say until the completion of the telecollection.

In the second branch, the remote collection is deferred RD of a chosen period of time, for example 12 hours. This second branch is implemented when there is no awakening of the device by a user as described above in the first branch.

In practice, if the attempted recovery of the first branch is successful, the programming delayed recovery is suppressed until the next telecollection.

<Desc / Clms Page number 22>

With reference to FIG. 27, in the event of a break in communication during the alarm procedure, a restart attempt is made within 5 minutes after the break.

For example, the number of attempts can be limited to 3. On the other hand, if the device is woken up by a manual operation such as the introduction of a card or a hook-up of the telephone, the resumption rule plans to reset the alarm procedure again until the alarm procedure is working properly.

Referring to Figure 28, a recovery procedure is provided during the download of several objects or even during the initialization procedure after the download session. In this procedure of recovery, one finds the short cycle of the recoveries (5 minutes) and a long cycle (15 minutes) which can be triggered automatically by a timestamp.

In the case of the download operation (DOWNLOADING), the service device initiates the recovery procedure and the server always plays the same scenario after correct identification of the service device. In this case, the service device finds the missing files after a correct analysis. In other words, the recovery takes place at the location of the break without taking over the part of the exchange already made before the break.

As seen above, it is not the same in the file download operation (UPLOADING). Indeed, during the break period, the service device can modify or have changed its status. Under these conditions, a resumption of the partial download session causes an error in the status of the service device. In this case, it is appropriate according to the invention to provide a recovery policy that completely resumes the loading of all files.

In practice, in the case of a cut of a line involved in the emission of S. Disconnect signal. req, the appa-

<Desc / Clms Page number 23>

 Service reil may attempt to initiate a call recovery (as of course, at any other time of break). In response, the server then sends the expected scenarios. However, because it already has all the objects, the service device sends to the attention of the server only a correct acknowledgment, signaling the subsequent installation of the objects, and expects from the server only the message S. Disconnect termination, this is to save time and avoid unnecessary repetition.

In tables A and B opposite, the different rules for resuming sessions in the presence of predetermined events are shown.

<Tb>
<tb> error <SEP> validation <SEP> congestion-abort <SEP> or
<tb> protocol <SEP> ment <SEP> failure
<tb> initiation <SEP> Management <SEP> not <SEP> of <SEP> Management <SEP> not <SEP> of
<tb><SEP> recovery <SEP> of <SEP> recovery
<tb> times <SEP> times
<tb> Telecom Management <SEP> not <SEP> of <SEP> Management <SEP> not <SEP> of
<tb><SEP>SEP><SEP> recovery of SEP> repri-recovery
<tb> times <SEP> its
<tb> alarm <SEP> not <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of
<tb> recovery <SEP> recovery <SEP> recovery <SEP> recovery
<tb> remote-step <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of
<tb> loading <SEP> recovery <SEP> recovery <SEP> recovery <SEP> recovery
<tb> call <SEP> is not <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of <SEP> not <SEP> of
<tb> veur <SEP> PMS <SEP> recovery <SEP> recovery <SEP> recovery <SEP> recovery
<tb> table <SEP> A
<tb>SEP><SEP> Reminder <SEP> Error <SEP> Break
<tb> network <SEP> connection <SEP> line
<tb> initiation <SEP> management <SEP> reminder <SEP> Management <SEP> management
<tb> of <SEP> repri-programmed <SEP> of <SEP> of <SEP> times <SEP> times <SEP>
<Tb>

<Desc / Clms Page number 24>

<Tb>
<tb> telecom-management <SEP> reminder <SEP> Management <SEP> management
<tb> read <SEP> of <SEP> repri-programmed <SEP> of <SEP> of <SEP> times <SEP> times <SEP>
<tb> alarm <SEP> management <SEP> reminder <SEP> not <SEP> of <SEP> management
<tb> of <SEP> repri-programmed <SEP> recovery <SEP> of <SEP> times <SEP> its
<tb> remote-management <SEP> reminder <SEP> not <SEP> from <SEP> management
<tb> loading <SEP> of <SEP> repri-programmed <SEP> recovery <SEP> of <SEP> times <SEP> its
<tb> call <SEP> ser-management <SEP> reminder <SEP> not <SEP> from <SEP> management
<tb> veur <SEP> PMS <SEP> of <SEP> repri-programmed <SEP> recovery <SEP> of <SEP> times <SEP> its
<Tb>
Table B Tables A and B form an integral part of the present invention. They include certain elements of character that can be used for the definition of the invention if necessary.

In these tables, there are 5 types of sessions, namely initiation, daily telecollect, alarm, download, and PMS server call. For these different sessions, there are 8 types of events, namely protocol error, validation, congestion, abandonment or failure, network error, callback, connection error, and line break.

For example, there is no provision for recovery in the case of a protocol error during the download procedure. On the other hand, in downloading, a recovery policy is provided in case of network error, as indicated above.

Moreover, the management of the recoveries can distinguish a delayed recovery which intervenes preferably after a short immediate cycle to allow the operator to restore the system before repetition (thus avoids the unnecessary exchanges)

<Desc / Clms Page number 25>

 and an immediate resumption which constitutes the resumption of the initial session.

Of course, the invention is not limited to the embodiments described above by way of example and extends to other variants.

Claims (14)

Claims 1. A method for exchanging data between at least one service apparatus (10) and at least one remote management server (5) in accordance with a selected management protocol, characterized in that the management protocol is over IP and includes at least one initiation rule of each exchange session and at least one recovery rule for initiating a possible recovery in case of non-completion of the exchange. 2. Method according to claim 1, characterized in that in case of rupture of an exchange session in which the data are transferred from the apparatus (10) to the server (5) (UPLOAD), the rule recovery includes a step in which the transfer is resumed in full in case of change of status of the device. 3. Method according to claim 1, characterized in that in case of break of an exchange session in which the data is transferred from the server (5) to the service apparatus (10) (DOWNLOAD), the Resume rule includes a step in which the exchange session is resumed at the location of the break without resuming the part of the exchange already made before the break. 4. Method according to claim 1, characterized in that the recovery rule is adapted to the work to be performed by the service apparatus, the importance of the task and its impact. 5. Method according to claim 4, characterized in that the recovery procedure comprises a step of repeating the retry attempt indefinitely until the service apparatus is put back into operation. 6. Method according to claim 4, characterized in that the recovery rule comprises a step of deferring the resumption of a chosen period of time. <Desc / Clms Page number 27> 7. The method of claim 4, characterized in that the recovery rule comprises a step of resuming the exchange after a trigger of the service device. 8. Method according to claim 1, characterized in that the initiation rule comprises the following steps: i) at the level of the service apparatus, issue a connection request (CONNECT) to the server according to the protocol, ii ) at the server level, receive the connection request (CONNECT), analyze the information contained in the request and issue a response based on the result of the analysis, and - iii) at the device, receive the response and in case of positive response (ACCEPT), synchronize the device and the server and establish the exchange session. 9. Method according to claim 1, characterized in that the management protocol further comprises an IP termination procedure comprising the following steps: iv) at the server level, at the end of the exchange session, transmit a disconnect order (DISCONNECT) at the destination of the service apparatus, and - v) at the service unit, receive the disconnect command (DISCONNECT) and stop the exchange session. 10. Method according to one of the preceding claims, characterized in that the management protocol further provides a policy for downloading files from the device to the server on FTP. 11. Method according to one of the preceding claims, characterized in that the management protocol further provides a policy for downloading files from the server to the device on FTP. 12. Method according to one of the preceding claims, characterized in that the management protocol provides a policy for the transfer of message over IP between the device and the server and vice versa. <Desc / Clms Page number 28> 13. Service apparatus for carrying out the method according to one of claims 1 to 12. 14. Server for carrying out the method according to one of claims 1 to 12.