EP1630761A1 - Système et procédé d'appel automatique, moteur d'alerte et poste d'activation mis en oeuvre dans le système - Google Patents

Système et procédé d'appel automatique, moteur d'alerte et poste d'activation mis en oeuvre dans le système Download PDF

Info

Publication number
EP1630761A1
EP1630761A1 EP05356139A EP05356139A EP1630761A1 EP 1630761 A1 EP1630761 A1 EP 1630761A1 EP 05356139 A EP05356139 A EP 05356139A EP 05356139 A EP05356139 A EP 05356139A EP 1630761 A1 EP1630761 A1 EP 1630761A1
Authority
EP
European Patent Office
Prior art keywords
alert
procedure
engine
call
transition
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.)
Granted
Application number
EP05356139A
Other languages
German (de)
English (en)
Other versions
EP1630761B1 (fr
Inventor
Ludovic Carlier
Bernard Savina
Samuel Liard
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP1630761A1 publication Critical patent/EP1630761A1/fr
Application granted granted Critical
Publication of EP1630761B1 publication Critical patent/EP1630761B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING SYSTEMS, e.g. PERSONAL CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/005—Alarm destination chosen according to a hierarchy of available destinations, e.g. if hospital does not answer send to police station

Definitions

  • the present invention relates to an automatic calling system and method, an alert engine and an activation station implemented in the system.
  • Known systems comprise an alert engine capable of controlling calls to receivers by following an alert procedure, the alerting procedure defining at least one conditional transition between call stages of a list of receivers.
  • the alert procedure is integrated into the alert engine code and forms with it a single program.
  • the alert engine code must be modified.
  • the known systems are therefore difficult to adapt to the wishes of each user.
  • the invention aims to remedy this drawback by proposing an automatic call system easily adaptable to the wishes of each user.
  • the subject of the invention is therefore an automatic call system in which the alert procedure is recorded in an editable file independently of the alert engine.
  • the alert procedure is saved in an editable file independently of the alert engine. Thus, when only the alert procedure needs to be changed there is no need to change the alert engine code.
  • the invention also relates to an alert engine adapted to be used in the automatic call system above.
  • the subject of the invention is also a method for automatically calling a set of receivers, this method comprising a step of controlling calls to the receivers of said set by following an alert procedure, the alert procedure defining at least a conditional transition between call stages of a list of receivers.
  • the method includes a step of recording an alert procedure in an editable file independently of the alert module.
  • the method may also include a step of writing the alert procedure using a tag content description language derived from SGML (Standard Generalized Markup Language).
  • FIG. 1 represents an automatic calling system designated by the general reference 2.
  • the system 2 comprises an alert engine 4 associated with a calling automaton 6.
  • the engine 4 is able to interpret and execute simultaneously one or more alert procedures.
  • the motor 4 is, for example, made from a conventional programmable computer capable of executing instructions recorded on an information recording medium, when these instructions are executed by the computer.
  • the recording medium comprises instructions for executing the method of FIG. 4.
  • the alert procedures being executed are stored in a database 10 stored in a memory 12.
  • the memory 12 also includes files 14 including pre-recorded alerting procedures, pre-recorded call lists and possibly messages. preregistered.
  • the alert procedures, the call lists and the pre-recorded messages are respectively associated with an alert procedure identifier, a call list identifier and a message identifier.
  • An alert procedure defines conditional transitions between call stages.
  • Calling steps are steps in which a list of receivers, corresponding, for example, to a prerecorded call list, is called by the automatic calling machine 6.
  • the conditional transitions define the condition or conditions for moving from one call step to the next. These transitions between two call stages are executed or not by the engine 4 as a function of tracking information on the execution state of the current call stage.
  • An example of an alert procedure will be described in more detail below with reference to FIGS. 2 and 3.
  • the controller 6 is able to call, via a long distance information transmission network 20, a set 22 of receivers corresponding to a list of calls.
  • the network 20 is, for example, a PSTN telephone network.
  • the assembly 22 comprises, for example, one or more telephones 24, one or more mobile phones 26 and one or more computers 28.
  • the list of calls used by the controller 6 comprises for each of the receivers of the set 22 the coordinates that make it possible to contact it via the network 20.
  • the call list contains the telephone number of each fixed telephone 24 or mobile 26 and the e-mail address of the user of each computer 28.
  • the automaton 6 is able to call one after the other or simultaneously several of the receivers whose coordinates are in the call list.
  • the controller 6 is also able to return to the engine 4 call tracking information representing the progress of the calls to be made. For example, as call tracking information, the controller 6 returns to the engine 4 the call list in which each receiver coordinate is completed by information on the progress of the call to this receiver. For example, the status takes three values: "in progress,”"failure,” and "success.”
  • the value "in progress” means the call is running.
  • the value "failure” means that the receiver could not be reached and the value "success” means that the receiver has been called successfully.
  • a station 30 for activating the execution of an alert procedure by the engine 4 is connected to the engine 4 via the network 20.
  • This station 30 allows a user to select the alert procedure that the Engine 4 must run.
  • the station 30 is, for example, able to transmit an identifier of a pre-recorded alert procedure in one of the files 14 to the engine 4.
  • it is also able to transmit to the engine 4 a procedure of locally registered alert.
  • the station 30 is connected to a memory 32 containing one or more alert procedures 34.
  • Station 30 is also adapted for a user to select a message to be broadcast to all receivers.
  • the station 30 is able to transmit to the engine 4 an identifier of a pre-recorded message in the memory 12 and / or to transmit to the engine 4 the message to be broadcast to the Receivers via the network 20.
  • the message transmitted to the motor 4 is, for example, prerecorded in the memory 32.
  • the station 30 is, for example, made from a conventional computer equipped with an Internet browser to communicate with the engine 4.
  • the system 2 also comprises an Internet server 40, a remote consultation station 42 and an input module 44.
  • the server 40 is adapted to allow remote monitoring of the progress of an alert procedure. For this purpose, it is connected to the automaton 6 so as to receive call tracking information and adapted to make it available for consultation from station 42.
  • station 42 is a computer equipped with an Internet browser.
  • the module 44 is intended for entering and saving in the files 14 new call procedures, call lists or messages.
  • the realization of this module 44 is conventional.
  • the motor 4, the controller 6, the server 40 and the module 44 are located in a single computer server connected to the memory 12.
  • FIG. 2 represents an example of an alert procedure contained in one of the files 14 and FIG. 3 represents in the form of a flowchart the warning procedure of FIG. 2.
  • call procedures are written using a tagged content description language derived from Standard Generalized Markup Language (SGML). More specifically, as an example, the calling procedure was written here using the Extensible Markup Language (XML).
  • SGML Standard Generalized Markup Language
  • XML Extensible Markup Language
  • Each alert procedure is framed between a ⁇ Model> opening tag or marker and a closing ⁇ / Model> tag or marker.
  • ⁇ DiffusionStage> and ⁇ / DiffusionStage> tags placed between the ⁇ Model> and ⁇ / Model> tags respectively define the beginning and end of the definition of a calling step.
  • the ⁇ BroadcastStage> tag can have zero, one, or two attributes.
  • the first "entry” attribute means that this call step is an entry point to the alert procedure when set to "True”. In this case, the engine 4 begins by performing this call step.
  • the second attribute named after "StageName” defines the name of the step. For example, here five call stages are defined in this alert procedure. They are respectively named "TermBoss”, “PersoBoss", “Team member”, “PersoMember” and "Rescue Team". These steps are, in order, the reference numerals 66 to 70 in FIG.
  • the definition of a call step includes at least one ⁇ DiffusionList> tag to identify the call list to use in this step.
  • This ⁇ DiffusionList> tag has for this purpose a "name" attribute to define the name of the call list.
  • ⁇ diffusionlist name «List 1 " / > means that the list of receivers to be called during the calling stage is contained in the file with the name "list1".
  • the definition of a call step may include the definition of one or more conditional transitions or not to another call stage.
  • the alert procedure includes opening tags ⁇ BeforeEndDiffusion> and closing tags ⁇ / BeforeEndDiffusion> between which are defined early transitions to other call stages. More specifically, these ⁇ BeforeEndDiffusion> tags have the particularity of defining an anticipated transition that allows the engine 4 to execute the next step without stopping the execution of the previous step. Such anticipated transitions between two steps are represented by dashed lines in FIG. 3.
  • the alerting procedure includes an anticipated conditional transition 70 between the steps 66 and 68 and an anticipated conditional transition 71 between steps 67 and 68.
  • transition 70 and 71 is placed between an opening ⁇ Transition> tag and a closing ⁇ / Transition> tag.
  • the condition that triggers the crossing of the transition is placed between the ⁇ Transition> and ⁇ / Transition> tags.
  • this condition is framed by an opening ⁇ If> tag and an ⁇ If /> closing tag.
  • the tag placed between the ⁇ If> and ⁇ If /> tags defines the condition for which the conditional transition is enabled.
  • the condition is that at least one call from a call list must have been successfully completed for the transition to the next step to be activated.
  • the transition 70 is crossed when a receiver of the list "List1" has been successfully called and the transition 71 is crossed when a receiver of the list "List2" has been called successfully.
  • Alert procedures also include unconditional transitions that are routinely executed during the execution of the alert procedure.
  • the alert procedure of FIG. 2 comprises a command waiting step 75 defined between ⁇ ControlStage> and ⁇ / ControlStage> tags.
  • the ⁇ ControlStage> tag has the same attributes as the ⁇ BroadcastStage> tag.
  • step 75 is called "In case of pb" and corresponds to a second entry point of the alert procedure.
  • step 75 the engine 4 performs no action and simply waits for the condition associated with the transition 74 to be evaluated to true.
  • This tag means that the transition is made when a received message whose name is specified by the "messageName” attribute takes the value specified by the "value” attribute.
  • the received message In the alert procedure of Figure 2 described here, the received message must be called “messageState” and take the value "Intervention" for the transition to be made. This transition is represented by the line 74 in FIG.
  • an operator of the system 2 writes, during a step 100, using the module 44, the alert procedure of Figure 2 in XML and using the predefined tags. Once the written alert procedure, it is recorded, in a step 102, in a file 14 stored in the memory 12.
  • a step 103 the operator enters and stores in the memory 12 one or more call lists and one or more messages to broadcast.
  • an intervention request is sent during a step 104 by the station 30 to the engine 4.
  • the alert procedure (s) to be executed are selected during the An operation 106. More specifically, the operation 106 is performed either by transmitting from the station 30 to the engine 4 an identifier of a pre-recorded alert procedure or by transmitting to the engine 4 the alert procedure to execute itself.
  • the message to be broadcast to the different receivers is selected during an operation 108.
  • the message to be broadcast is selected either by transmitting an identifier of a pre-recorded message to from station 30 to the engine 4 or by transmitting from the station 30 the message to broadcast.
  • the engine 4 interprets, during a step 110, the contents of the files 14 corresponding to the alert procedures selected during the step 104. operation 112 of recording in the database 10 steps of the selected alert procedures.
  • the call lists referenced by the selected call procedures are also stored in the database 12 during an operation 114.
  • the engine 4 executes in parallel, during a step 120, all the call procedures recorded in the database 10. For example, in the particular case of the alert procedure of FIG. the motor 4 starts by performing steps 66 and 75 simultaneously.
  • step 66 the engine 4 transmits, during an operation 122, the call list "list1" to the controller 6 and command this automaton 6 so that it begins to call the different receivers whose coordinates are contained in this list.
  • the engine 4 interrogates the automaton 6 and the automaton 6 returns the call tracking information to the engine 4.
  • the engine 4 evaluates, during an operation 126, the various conditional transitions taking into account the most recently received tracking information. If the condition associated with one of these conditional transitions is evaluated to "true” then the engine 4 begins to execute the next step in the alert procedure. For example, as soon as the engine 4 is informed by the controller 6 that one of the receivers of the list "list1" has been successfully called, it begins to execute the call step 68 while continuing to execute the calling stage 66.
  • the engine 4 begins to execute, if it exists, the next call step designated by the ⁇ AfterDiffusion> tag. By for example, at the end of step 66, the engine 4 automatically executes the call step 67.
  • the engine 4 also evaluates during an operation 130 the conditional transitions to exit a command waiting step.
  • the engine 4 tests at regular intervals if a message named "messageStatus" has taken the value "Intervention". If so, the engine 4 immediately begins to perform step 70. If not, the engine 4 continues to wait.
  • the value of the message named "messageState" is, for example, modifiable from the station 30.
  • the engine 4 follows step by step the alert procedure defined in a file 14 by regularly testing the conditions associated with the conditional transitions and crossing these transitions only when the associated condition is evaluated to "true".
  • the warning engine simultaneously tests the conditions of the conditional transitions of all the alert procedures currently executed in parallel and also simultaneously controls the execution of all the currently active call stages, irrespective of the procedure of the procedure. alert to which these transitions and / or steps belong.
  • the engine 4 alone is able to perform several alert procedures simultaneously.
  • tags being predefined, the user does not need to know in detail the operation of the engine 4. Furthermore, the use of tags for defining call stages and command waiting steps simplifies the operation of the engine. write alert procedures.
  • the system 2 has been described here in the particular case where it comprises only one alert engine. In a variant, it comprises several identical warning engines located in the same or in respective servers.
  • the receivers may be machines or be incorporated into any machines.
  • the alert message may be accompanied by command instructions from this machine.
  • the system can be used to trigger the start-up of cameras, sensors (for example temperature, pressure, level sensors or even chemical detectors, etc.), or decontamination system.
  • the system can also be used to trigger the shutdown of sensitive machines, to trigger the disconnection of non-vital elements of a network, such as a power distribution network or to trigger the isolation of dangerous objects or sensitive.

Landscapes

  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Alarm Systems (AREA)
  • Stored Programmes (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Ce système d'appel automatique d'un ensemble de récepteurs comporte un moteur d'alerte (4) apte à commander des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs. La procédure d'alerte est enregistrée dans un fichier (14) modifiable indépendamment du moteur d'alerte.

Description

  • La présente invention concerne un système et un procédé d'appel automatique, un moteur d'alerte et un poste d'activation mis en oeuvre dans le système.
  • Des systèmes connus comportent un moteur d'alerte apte à commander des appels vers des récepteurs en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs.
  • Ces systèmes sont particulièrement utiles pour alerter des personnes telles que, par exemple, des sauveteurs en cas d'accident.
  • Dans les systèmes connus, la procédure d'alerte est intégrée au code du moteur d'alerte et forme avec celui-ci un seul et même programme. Ainsi, si un utilisateur souhaite modifier la procédure d'alerte, le code du moteur d'alerte doit être modifié. Les systèmes connus sont donc difficiles à adapter aux souhaits de chaque utilisateur.
  • L'invention vise à remédier à cet inconvénient en proposant un système d'appel automatique facilement adaptable au souhait de chaque utilisateur.
  • L'invention a donc pour objet un système d'appel automatique dans lequel la procédure d'alerte est enregistrée dans un fichier modifiable indépendamment du moteur d'alerte.
  • Dans le système ci-dessus, la procédure d'alerte est enregistrée dans un fichier modifiable indépendamment du moteur d'alerte. Ainsi, lorsque seule la procédure d'alerte doit être changée il n'est pas nécessaire de modifier le code du moteur d'alerte.
  • Les modes de réalisation de ce système peuvent comporter une ou plusieurs des caractéristiques suivantes :
    • le moteur d'alerte est apte à commander l'exécution d'une nouvelle étape d'appel lorsqu'une condition associée à une transition anticipée est évaluée à vraie sans attendre la fin de l'exécution d'une étape d'appel précédente, et le moteur d'appel est également apte, après cette transition anticipée, à exécuter en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente,
    • la transition anticipée est définie dans la procédure d'alerte,
    • il comporte un automate d'appel, sous la commande du moteur d'alerte, apte à appeler chacun des récepteurs d'une liste de récepteurs et à envoyer des informations de suivi de l'état d'avancement des appels au moteur d'alerte, et le moteur d'alerte est apte à évaluer les conditions associées à des transitions définies par la procédure d'alerte en fonction de ces informations de suivi,
    • la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language),
    • le moteur d'alerte est apte à interpréter les balises contenues dans la procédure d'alerte,
    • la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente,
    • la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel,
    • le moteur d'alerte est apte à exécuter simultanément plusieurs étapes d'appel appartenant à des procédures d'alerte différentes,
    • le système comporte :
      • plusieurs procédures d'alerte enregistrées dans des fichiers modifiables indépendamment du moteur d'alerte, et
      • un poste d'activation de l'exécution d'une de ces procédures d'alerte raccordé au moteur par l'intermédiaire d'un réseau grande distance de transmission d'informations, ce poste étant apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte,
    • le poste est apte à transmettre au moteur d'alerte l'ensemble de la procédure d'alerte ou un identifiant d'une procédure d'alerte préenregistrée à exécuter, et, en réponse à la transmission du poste, le moteur d'alerte est apte à déclencher l'exécution de la procédure d'alerte transmise ou la procédure d'alerte préenregistrée correspondant à l'identifiant transmis.
  • L'invention a également pour objet un moteur d'alerte adapté pour être utilisé dans le système d'appel automatique ci-dessus.
  • L'invention a également pour objet un procédé d'appel automatique d'un ensemble de récepteurs, ce procédé comportant une étape de commande des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs. Le procédé comporte une étape d'enregistrement d'une procédure d'alerte dans un fichier modifiable indépendamment du module d'alerte. Le procédé peut également comporter une étape d'écriture de la procédure d'alerte en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language).
  • L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels :
    • la figure 1 est une illustration schématique de l'architecture d'un système d'appel automatique,
    • la figure 2 est une illustration du contenu d'un fichier dans lequel est enregistré une procédure d'alerte,
    • la figure 3 est un organigramme correspondant au contenu du fichier de la figure 2, et
    • la figure 4 est un organigramme d'un procédé d'appel automatique.
  • La figure 1 représente un système d'appel automatique désigné par la référence générale 2. Le système 2 comporte un moteur d'alerte 4 associé à un automate d'appel 6.
  • Le moteur 4 est apte à interpréter puis à exécuter simultanément une ou plusieurs procédures d'alerte. Le moteur 4 est, par exemple, réalisé à partir d'un calculateur programmable conventionnel apte à exécuter des instructions enregistrées sur un support d'enregistrement d'informations, lorsque ces instructions sont exécutées par le calculateur. A cet effet, le support d'enregistrement comporte des instructions pour l'exécution du procédé de la figure 4.
  • Les procédures d'alerte en cours d'exécution sont enregistrées dans une base de données 10 stockée dans une mémoire 12. La mémoire 12 comporte également des fichiers 14 comportant des procédures d'alerte préenregistrées, des listes d'appel préenregistrées et éventuellement des messages préenregistrés. Les procédures d'alerte, les listes d'appel et les messages préenregistrés sont associés respectivement à un identifiant de procédure d'alerte, un identifiant de liste d'appel et un identifiant de message.
  • Une procédure d'alerte définie des transitions conditionnelles entre des étapes d'appel. Les étapes d'appel sont des étapes lors desquelles une liste de récepteurs, correspondant, par exemple, à une liste d'appel préenregistrée, est appelée par l'automate d'appel 6. Les transitions conditionnelles définissent la ou les conditions permettant de passer d'une étape d'appel à la suivante. Ces transitions entre deux étapes d'appel sont exécutées ou non par le moteur 4 en fonction d'informations de suivi sur l'état d'exécution de l'étape d'appel courante. Un exemple de procédure d'alerte sera décrit plus en détail ci-dessous en regard des figures 2 et 3.
  • L'automate 6 est apte à appeler par l'intermédiaire d'un réseau grande distance 20 de transmission d'informations un ensemble 22 de récepteurs correspondant à une liste d'appels. Le réseau 20 est, par exemple, un réseau téléphonique RTC. L'ensemble 22 comporte, par exemple, un ou plusieurs téléphones 24, un ou plusieurs téléphones mobiles 26 et un ou plusieurs ordinateurs 28.
  • La liste d'appels utilisée par l'automate 6 comporte pour chacun des récepteurs de l'ensemble 22 les coordonnées qui permettent de le contacter par l'intermédiaire du réseau 20. Par exemple, la liste d'appel comporte le numéro de téléphone de chaque téléphone fixe 24 ou mobile 26 et l'adresse e-mail de l'utilisateur de chaque ordinateur 28.
  • L'automate 6 est propre à appeler les uns après les autres ou simultanément plusieurs des récepteurs dont les coordonnées sont dans la liste d'appel.
  • L'automate 6 est également propre à retourner au moteur 4 des informations de suivi d'appels représentant l'état d'avancement des appels à effectuer. Par exemple, en tant qu'information de suivi d'appel, l'automate 6 retourne au moteur 4 la liste d'appels dans laquelle chaque coordonnée de récepteurs est complétée par une information sur l'état d'avancement de l'appel vers ce récepteur. L'état d'avancement prend par exemple trois valeurs : « en cours », « échec », et « succès ». La valeur « en cours » signifie que l'appel est en cours d'exécution. La valeur « échec » signifie que le récepteur n'a pas pu être joint et la valeur « succès » signifie que le récepteur a été appelé avec succès.
  • Un poste 30 d'activation de l'exécution d'une procédure d'alerte par le moteur 4 est raccordé au moteur 4 par l'intermédiaire du réseau 20. Ce poste 30 permet à un utilisateur de sélectionner la procédure d'alerte que le moteur 4 doit exécuter. A cet effet, le poste 30 est, par exemple, apte à transmettre un identifiant d'une procédure d'alerte préenregistrée dans l'un des fichiers 14 au moteur 4. Ici, il est également apte à transmettre au moteur 4 une procédure d'alerte enregistrée localement. A cet effet, le poste 30 est raccordé à une mémoire 32 contenant une ou plusieurs procédures d'alerte 34.
  • Le poste 30 est également adapté pour qu'un utilisateur puisse sélectionner un message à diffuser à l'ensemble des récepteurs. De façon similaire à ce qui a été décrit pour la procédure d'alerte, le poste 30 est apte à transmettre au moteur 4 un identifiant d'un message préenregistré dans la mémoire 12 et/ou à transmettre au moteur 4 le message à diffuser aux récepteurs par l'intermédiaire du réseau 20. Le message transmis au moteur 4 est, par exemple, préenregistré dans la mémoire 32.
  • Le poste 30 est, par exemple, réalisé à partir d'un ordinateur conventionnel équipé d'un navigateur Internet pour communiquer avec le moteur 4.
  • Le système 2 comporte aussi un serveur Internet 40, un poste de consultation distant 42 et un module de saisie 44.
  • Le serveur 40 est adapté pour permettre le suivi à distance du déroulement d'une procédure d'alerte. Pour cela, il est raccordé à l'automate 6 de manière à recevoir les informations de suivi d'appel et adapté pour rendre celles-ci consultables à partir du poste 42. Typiquement, le poste 42 est un ordinateur équipé d'un navigateur Internet.
  • Le module 44 est destiné à la saisie et l'enregistrement dans les fichiers 14 de nouvelles procédures d'appel, listes d'appel ou messages. La réalisation de ce module 44 est conventionnelle.
  • A titre d'exemple pour simplifier l'illustration, le moteur 4, l'automate 6, le serveur 40 et le module 44 sont implantés dans un seul et même serveur informatique raccordé à la mémoire 12.
  • La figure 2 représente un exemple de procédure d'alerte contenu dans l'un des fichiers 14 et la figure 3 représente sous la forme d'un organigramme la procédure d'alerte de la figure 2.
  • Pour simplifier la configuration du système 2, les procédures d'appel sont écrites en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language). Plus précisément, a titre d'exemple, la procédure d'appel a été ici écrite en utilisant le langage XML (Extensible Markup Language).
  • Chaque procédure d'alerte est encadrée entre une balise ou marqueur d'ouverture < Model > et une balise ou marqueur de fermeture </Model>.
  • Des balises < DiffusionStage > et < /DiffusionStage > placées entre les balises < Model > et < /Model > définissent respectivement le début et la fin de la définition d'une étape d'appel.
  • La balise < DiffusionStage > peut comporter zéro, un ou deux attributs. Le premier attribut « entry » signifie que cette étape d'appel est un point d'entrée de la procédure d'alerte lorsqu'on lui affecte la valeur « True ». Dans ce cas là, le moteur 4 commence par exécuter cette étape d'appel. Le second attribut qui porte le nom de « StageName » définit le nom de l'étape. Par exemple, ici, cinq étapes d'appel sont définies dans cette procédure d'alerte. Elles sont respectivement nommées « TermBoss », « PersoBoss », « Team member », « PersoMember » et « Rescue Team ». Ces étapes portent, dans l'ordre, les références numériques 66 à 70 dans la figure 3.
  • Ensuite, la définition d'une étape d'appel comporte au moins une balise < DiffusionList > permettant d'identifier la liste d'appel à utiliser lors de cette étape. Cette balise < DiffusionList > comporte à cet effet un attribut « name » permettant de définir le nom de la liste d'appel. Par exemple, la balise suivante : < diffusionlist name = « list 1  » / >
    Figure imgb0001
    signifie que la liste des récepteurs à appeler lors de l'étape d'appel est contenue dans le fichier portant le nom « list1 ».
  • Ensuite, la définition d'une étape d'appel peut comporter la définition d'une ou plusieurs transitions conditionnelles ou non vers une autre étape d'appel. Par exemple ici, la procédure d'alerte comporte des balises d'ouverture < BeforeEndDiffusion > et des balises de fermeture < /BeforeEndDiffusion > entre lesquelles sont définies des transitions anticipées vers d'autres étapes d'appel. Plus précisément, ces balises < BeforeEndDiffusion > présentent la particularité de définir une transition anticipée qui permet au moteur 4 d'exécuter l'étape suivante sans pour autant arrêter l'exécution de l'étape précédente. De telles transitions anticipées entre deux étapes sont représentées par des lignes en pointillés dans la figure 3. A titre d'illustration, la procédure d'alerte comporte une transition conditionnelle anticipée 70 entre les étapes 66 et 68 et une transition conditionnelle anticipée 71 entre les étapes 67 et 68.
  • La définition des transition 70 et 71 est placée entre une balise < Transition > d'ouverture et une balise < /Transition > de fermeture. La balise < Transition > comporte un attribut nommé « StageName » destiné à indiquer vers quelle étape d'appel la transition doit être effectuée si une condition est évaluée à vraie. Par exemple, la balise suivante : < Transition StageName = « Team members » >
    Figure imgb0002
    signifie que la transition s'effectuera vers l'étape d'appel 68.
  • La condition qui déclenche le franchissement de la transition est placée entre les balises < Transition > et < /Transition >. Ici, cette condition est encadrée par une balise d'ouverture < If > et une balise de fermeture < If/ >. La balise placée entre les balises < If > et < If/ > définit la condition pour laquelle la transition conditionnelle est activée. Ici, à titre d'exemple, la condition est que au moins un appel d'une liste d'appels doit avoir été réalisé avec succès pour que la transition vers l'étape suivante soit activée.
  • Cette condition correspond dans la figue 2 à la balise signe < AfLeastOne nbAppel = « 1 » typeAppel = « success » fromList = « List1 » >. Cette balise comporte trois attributs. Le premier attribut nommé « nbAppel » spécifie le nombre d'appel. L'atttribut « typeAppel » spécifie l'état d'avancement de l'appel et l'attribut « fromList » spécifie le nom de la liste d'appel concernée.
  • Plus précisément, ici, la transition 70 est franchie lorsqu'un récepteur de la liste « List1 » a été appelé avec succès et la transition 71 est franchie lorsqu'un récepteur de la liste « List2 » a été appelé avec succès.
  • Les procédures d'alerte comportent aussi des transitions non conditionnelles qui sont systématiquement exécutées lors de l'exécution de la procédure d'alerte.
  • Ces transitions non conditionnelles ne sont pas associées à une condition. Ici, elles sont définies par une balise d'ouverture < AfterDiffusion > et de fermeture < /AfterDiffusion >. Ces transitions correspondent à une transition systématique vers une étape d'appel suivante à la fin de l'exécution de l'étape d'appel précédente. Entre les balises < AfterDiffusion > et < /AfterDiffusion >, la balise < Transition > est utilisée pour définir le nom de l'étape d'appel suivante vers laquelle la transition s'effectue. Ici la procédure d'alerte définit deux de ces transitions non conditionnelles, représentées par des traits pleins 72, 73 sur la figure 3.
  • Enfin, la procédure d'alerte de la figure 2 comporte une étape 75 d'attente de commande définie entre des balises < ContrôleStage > et < /ContrôleStage >. La balise < ContrôleStage > comporte les mêmes attributs que ceux de la balise < DiffusionStage >. Par exemple, dans le cas particulier de la figure 2, l'étape 75 s'appelle « In case of pb » et correspond à un second point d'entrée de la procédure d'alerte.
  • Lors de l'étape 75, le moteur 4 n'effectue aucune action et attend simplement que la condition associée à la transition 74 soit évaluée à vrai.
  • La condition associée à la transition 74 est définie par la balise < MessageEqual messageName = « messageEtat » value = « Intervention »/ >. Cette balise signifie que la transition est franchie lorsqu'un message reçu dont le nom est spécifié par l'attribut « messageName » prend la valeur spécifiée par l'attribut « value ». Dans la procédure d'alerte de la figure 2 décrit ici, le message reçu doit porter le nom de « messageEtat » et prendre la valeur « intervention » pour que la transition soit franchie. Cette transition est représentée par le trait 74 sur la figure 3.
  • Le fonctionnement du système 2 va maintenant être décrit en regard de la figure 4 dans le cas particulier où la procédure d'alerte à exécuter est celle de la figure 2.
  • Initialement, un opérateur du système 2 écrit, lors d'une étape 100, en utilisant le module 44, la procédure d'alerte de la figure 2 en langage XML et en utilisant les balises prédéfinies. Une fois la procédure d'alerte écrite, celle-ci est enregistrée, lors d'une étape 102, dans un fichier 14 stocké dans la mémoire 12.
  • Lors d'une étape 103, l'opérateur saisie et enregistre dans la mémoire 12 une ou plusieurs listes d'appel et un ou plusieurs messages à diffuser.
  • Lorsque cela s'avère nécessaire, une demande d'intervention est envoyée, lors d'une étape 104 par le poste 30 au moteur 4. Lors de cette demande d'intervention, la ou les procédures d'alerte à exécuter sont sélectionnées lors d'une opération 106. Plus précisément, l'opération 106 est réalisée soit en transmettant du poste 30 au moteur 4 un identifiant d'une procédure d'alerte préenregistrée soit en transmettant au moteur 4 la procédure d'alerte à exécuter elle-même. Toujours lors de l'étape 104, le message à diffuser aux différents récepteurs est sélectionné lors d'une opération 108. De façon similaire à l'opération 106, le message à diffuser est sélectionné soit en transmettant un identificateur d'un message préenregistré à partir du poste 30 vers le moteur 4 soit en transmettant à partir du poste 30 le message à diffuser.
  • En réponse à une demande d'intervention, le moteur 4 interprète, lors d'une étape 110, le contenu des fichiers 14 correspondant aux procédures d'alerte sélectionnées lors de l'étape 104. Cette étape comporte notamment une opération 112 d'enregistrement dans la base de données 10 des étapes des procédures d'alerte sélectionnées. Les listes d'appel référencées par les procédures d'appel sélectionnées sont également enregistrées dans la base de données 12 lors d'une opération 114.
  • Ensuite, le moteur 4 exécute en parallèle, lors d'une étape 120, l'ensemble des procédures d'appel enregistrées dans la base de données 10. Par exemple, dans le cas particulier de la procédure d'alerte de la figure 2, le moteur 4 commence par exécuter simultanément les étapes 66 et 75.
  • Plus précisément, lors de l'étape 66, conformément à ce qui est indiqué dans la procédure d'alerte, le moteur 4 transmet, lors d'une opération 122, la liste d'appel « list1 » à l'automate 6 et commande cet automate 6 pour que celui-ci commence à appeler les différents récepteurs dont les coordonnées sont contenues dans cette liste.
  • A intervalles réguliers, lors d'une opération 124, le moteur 4 interroge l'automate 6 et l'automate 6 retourne les informations de suivi d'appel au moteur 4.
  • Le moteur 4 évalue, lors d'une opération 126, les différentes transitions conditionnelles en tenant compte des informations de suivi les plus récemment reçues. Si la condition associée à l'une de ces transitions conditionnelles est évaluée à « vraie » alors le moteur 4 commence à exécuter l'étape suivante dans la procédure d'alerte. Par exemple, dés que le moteur 4 est informé par l'automate 6 que l'un des récepteurs de la liste « list1 » a été appelé avec succès, il commence à exécuter l'étape d'appel 68 tout en continuant d'exécuter l'étape d'appel 66.
  • Lorsqu'une étape d'appel est terminée, le moteur 4 commence à exécuter, si elle existe, l'étape d'appel suivante désignée par la balise < AfterDiffusion >. Par exemple, à la fin de l'étape 66 le moteur 4 procède automatiquement à l'exécution de l'étape d'appel 67.
  • Le moteur 4 évalue aussi lors d'une opération 130 les transitions conditionnelles permettant de sortir d'une étape d'attente de commande.
  • Par exemple, dans le cas de la procédure d'alerte de la figure 2, le moteur 4 teste à intervalles réguliers si un message nommé « messageEtat » a pris la valeur « Intervention ». Dans l'affirmative, le moteur 4 commence immédiatement à exécuter l'étape 70. Dans la négative, le moteur 4 continue d'attendre. La valeur du message nommé « messageEtat » est, par exemple, modifiable à partir du poste 30.
  • Ainsi, le moteur 4 suit pas à pas la procédure d'alerte définie dans un fichier 14 en testant régulièrement les conditions associées aux transitions conditionnelles et en franchissant ces transitions uniquement lorsque la condition associée est évaluée à « vraie ».
  • Plus précisément, le moteur d'alerte teste simultanément les conditions des transitions conditionnelles de toutes les procédures d'alerte actuellement exécutées en parallèle et commande également simultanément l'exécution de toutes les étapes d'appel actuellement actives et ceci indépendamment de la procédure d'alerte auxquelles ces transitions et/ou étapes appartiennent. Ainsi, le moteur 4 à lui seul est apte à exécuter simultanément plusieurs procédures d'alerte.
  • On notera qu'il est possible de modifier une procédure d'alerte sans modifier le fonctionnement du moteur 4. L'adaptation du fonctionnement du moteur 4 aux souhaits des clients est donc facilitée.
  • Grâce aux transitions anticipées, il est possible d'accélérer l'exécution d'une procédure d'alerte puisqu'il est possible de commencer l'exécution d'une nouvelle étape de cette procédure d'alerte sans attendre qu'une étape d'appel précédente soit finie.
  • L'utilisation d'un langage de description de contenu à balises simplifie la configuration du système 2 car ceci évite le recours à des étapes de programmation consistant à écrire puis à compiler un programme. Ces balises étant prédéfinies, l'utilisateur n'a pas besoin de connaître en détail le fonctionnement du moteur 4. Par ailleurs, l'utilisation de balises permettant de définir des étapes d'appel et des étapes d'attente de commande simplifie l'écriture de procédures d'alerte.
  • Le système 2 a été décrit ici dans le cas particulier où il ne comporte qu'un seul moteur d'alerte. En variante, il comporte plusieurs moteurs d'alerte identiques implantés dans le même ou dans des serveurs respectifs.
  • Les récepteurs peuvent être des machines ou être incorporés dans des machines quelconques. Dans ce cas, le message d'alerte peut être accompagné d'instructions de commande de cette machine. Ainsi, par exemple, le système peut être utilisé pour déclencher la mise en marche de caméras, de capteurs (par exemple des capteurs de température, de pression, de niveau ou encore des détecteurs de produits chimiques, etc...), ou de système de décontamination. Le système peut aussi être utilisé pour déclencher l'arrêt de machines sensibles, pour déclencher la déconnection d'éléments non vitaux d'un réseau, tel qu'un réseau de distribution d'électricité ou encore pour déclencher l'isolement d'objets dangereux ou sensibles.

Claims (23)

  1. Système d'appel automatique d'un ensemble de récepteurs, ce système comportant un moteur d'alerte (4) apte à commander des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce que la procédure d'alerte est enregistrée dans un fichier (14) modifiable indépendamment du moteur d'alerte.
  2. Système selon la revendication 1, caractérisé en ce que le moteur d'alerte (4) est apte à commander l'exécution d'une nouvelle étape d'appel lorsqu'une condition associée à une transition anticipée est évaluée à vraie sans attendre la fin de l'exécution d'une étape d'appel précédente, et en ce que le moteur d'appel est également apte, après cette transition anticipée, à exécuter en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente.
  3. Système selon la revendication 2, caractérisé en ce que la transition anticipée (70, 71) est définie dans la procédure d'alerte.
  4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte un automate d'appel (6), sous la commande du moteur d'alerte (4), apte à appeler chacun des récepteurs d'une liste de récepteurs et à envoyer des informations de suivi de l'état d'avancement des appels au moteur d'alerte, et en ce que le moteur d'alerte (4) est apte à évaluer les conditions associées à des transitions définies par la procédure d'alerte en fonction de ces informations de suivi.
  5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language).
  6. Système selon la revendication 5, caractérisé en ce que le moteur d'alerte (4) est apte à interpréter les balises contenues dans la procédure d'alerte.
  7. Système selon la revendication 5 ou 6, caractérisé en ce que la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente.
  8. Système selon l'une quelconque des revendications 5 à 7, caractérisé en ce que la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape (75) d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel.
  9. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le moteur d'alerte est apte à exécuter simultanément plusieurs étapes d'appel appartenant à des procédures d'alerte différentes.
  10. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le système comporte :
    - plusieurs procédures d'alerte enregistrées dans des fichiers modifiables indépendamment du moteur d'alerte, et
    - un poste (30) d'activation de l'exécution d'une de ces procédures d'alerte raccordé au moteur par l'intermédiaire d'un réseau grande distance de transmission d'informations, ce poste étant apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte.
  11. Système selon la revendication 10, caractérisé en ce que le poste (30) est apte à transmettre au moteur d'alerte l'ensemble de la procédure d'alerte ou un identifiant d'une procédure d'alerte préenregistrée à exécuter, et en ce que, en réponse à la transmission du poste (30), le moteur d'alerte est apte à déclencher l'exécution de la procédure d'alerte transmise ou la procédure d'alerte préenregistrée correspondant à l'identifiant transmis.
  12. Moteur d'alerte adapté pour être utilisé dans un système selon l'une quelconque des revendications précédentes, ce moteur d'alerte étant apte à commander des appels vers les récepteurs dudit ensemble, en suivant la procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce que le moteur d' alerte est apte à exécuter une procédure d'alerte enregistrée dans un fichier modifiable indépendamment du moteur d'alerte.
  13. Poste d'activation adapté pour être utilisé dans un système selon la revendication 10 ou 11, caractérisé en ce que :
    - le poste est raccordé au moteur d'alerte par l'intermédiaire d'un réseau grande distance de transmission d'informations, et
    - le poste est apte à sélectionner la procédure d'alerte à exécuter par le moteur d'alerte ainsi qu'a activer l'exécution de la procédure d'alerte sélectionnée.
  14. Procédé d'appel automatique d'un ensemble de récepteurs, ce procédé comportant une étape (122) de commande des appels vers les récepteurs dudit ensemble en suivant une procédure d'alerte, la procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisé en ce qu'il comporte une étape (102) d'enregistrement d'une procédure d'alerte dans un fichier modifiable indépendamment d'un moteur d'alerte propre à exécuter l'étape de commande.
  15. Procédé selon la revendication 14, caractérisé en ce qu'il comporte une étape (100) d'écriture de la procédure d'alerte en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markup Language).
  16. Procédure d'alerte adaptée pour être mise en oeuvre dans un système conforme à l'une quelconque des revendications 1 à 11, cette procédure d'alerte étant exécutable par le moteur d'alerte propre à commander des appels vers des récepteurs, cette procédure d'alerte définissant au moins une transition conditionnelle entre des étapes d'appel d'une liste de récepteurs, caractérisée en ce que la procédure d'alerte est enregistrable dans un fichier (14) modifiable indépendamment du moteur d'alerte.
  17. Procédure selon la revendication 16, caractérisée en ce qu'elle définit une transition anticipée qui, lorsqu'elle est évaluée à vraie permet au moteur d'alerte de commander l'exécution d'une nouvelle étape d'appel sans attendre la fin de l'exécution d'une étape d'appel précédente, de manière à ce que après cette transition anticipée, le moteur d'appel exécute en parallèle l'étape d'appel précédente et la nouvelle étape d'appel sans interrompre l'exécution de cette étape d'appel précédente.
  18. Procédure selon la revendication 16 ou 17, caractérisée en ce que les conditions associées à des transitions définies dans cette procédure d'alerte sont fonction des informations de suivi de l'état d'avancement des appels envoyés au moteur d'alerte par un automate d'appel.
  19. Procédure d'alerte selon l'une quelconque des revendications 16 à 18, caractérisée en ce que la procédure d'alerte est écrite en utilisant un langage de description de contenu à balises dérivé du langage SGML (Standard Generalized Markeup Language).
  20. Procédure d'alerte selon la revendication 19, caractérisée en ce que la procédure d'alerte comporte une balise de transition anticipée marquant le début de la définition d'une transition anticipée permettant le déclenchement d'une nouvelle étape d'appel avant même d'avoir terminé une étape d'appel précédente.
  21. Procédure d'alerte selon la revendication 19 ou 20, caractérisée en ce que la procédure d'alerte comporte une balise d'attente de commande marquant le début de la définition d'une étape (75) d'attente de commande qui, lorsqu'elle est exécutée par le moteur d'alerte, permet au moteur d'alerte d'attendre qu'une condition soit réalisée avant de procéder à une étape d'appel.
  22. Mémoire, caractérisée en ce qu'elle comporte une procédure d'alerte conforme à l'une quelconque des revendications 16 à 21.
  23. Programme d'ordinateur, caractérisé en ce qu'il comporte des instructions pour l'exécution d'une procédure d'alerte conforme à l'une quelconque des revendications 16 à 21, lorsque ces instructions sont exécutées par un calculateur électronique.
EP05356139A 2004-08-25 2005-08-24 Système et procédé d'appel automatique, moteur d'alerte et poste d'activation mis en oeuvre dans le système Expired - Lifetime EP1630761B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0409088 2004-08-25

Publications (2)

Publication Number Publication Date
EP1630761A1 true EP1630761A1 (fr) 2006-03-01
EP1630761B1 EP1630761B1 (fr) 2010-10-13

Family

ID=34947763

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05356139A Expired - Lifetime EP1630761B1 (fr) 2004-08-25 2005-08-24 Système et procédé d'appel automatique, moteur d'alerte et poste d'activation mis en oeuvre dans le système

Country Status (6)

Country Link
US (1) US20060068770A1 (fr)
EP (1) EP1630761B1 (fr)
JP (1) JP2006067589A (fr)
AT (1) ATE484812T1 (fr)
DE (1) DE602005024091D1 (fr)
ES (1) ES2354362T3 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1847973A3 (fr) * 2006-04-21 2007-11-07 Ad Koemans Système de sécurité

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114067526A (zh) * 2021-11-12 2022-02-18 武昌理工学院 一种危化品安全存储监控装置及方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020190857A1 (en) * 2001-05-24 2002-12-19 Public Safety Corporation System and methods for automated alarm tracking and billing
US20040006694A1 (en) * 2002-03-04 2004-01-08 Jake Heelan Emergency information management system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5905902A (en) * 1995-09-28 1999-05-18 Intel Corporation Programmable state machine employing a cache-like arrangement
JPH11261624A (ja) * 1998-03-06 1999-09-24 Fujitsu Ltd 情報配信装置
US6151385A (en) * 1998-07-07 2000-11-21 911 Notify.Com, L.L.C. System for the automatic notification that a 9-1-1 call has occurred
US6463273B1 (en) * 1999-05-11 2002-10-08 J. Cameron Day Wireless warning system
US6442241B1 (en) * 1999-07-15 2002-08-27 William J. Tsumpes Automated parallel and redundant subscriber contact and event notification system
US6631363B1 (en) * 1999-10-11 2003-10-07 I2 Technologies Us, Inc. Rules-based notification system
US6745021B1 (en) * 2000-11-21 2004-06-01 Alcatel System, controller and method for alerting mobile subscribers about emergency situations
US7552057B2 (en) * 2001-03-02 2009-06-23 Mcgwin Jr James E Method and apparatus for using process exceptions to provide instant notifications for distributed processes
US20020178077A1 (en) * 2001-05-25 2002-11-28 Katz Steven Bruce Method for automatically invoking a software module in response to an internal or external event affecting the procurement of an item
JP2003163760A (ja) * 2001-11-28 2003-06-06 Alpha Tsushin:Kk 救護要請通報装置及び方法
JP4003591B2 (ja) * 2002-07-11 2007-11-07 ソニー株式会社 モニタリングシステム、モニタリング方法およびプログラム
US7013483B2 (en) * 2003-01-03 2006-03-14 Aladdin Knowledge Systems Ltd. Method for emulating an executable code in order to detect maliciousness

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020190857A1 (en) * 2001-05-24 2002-12-19 Public Safety Corporation System and methods for automated alarm tracking and billing
US20040006694A1 (en) * 2002-03-04 2004-01-08 Jake Heelan Emergency information management system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1847973A3 (fr) * 2006-04-21 2007-11-07 Ad Koemans Système de sécurité

Also Published As

Publication number Publication date
US20060068770A1 (en) 2006-03-30
JP2006067589A (ja) 2006-03-09
ES2354362T3 (es) 2011-03-14
EP1630761B1 (fr) 2010-10-13
DE602005024091D1 (de) 2010-11-25
ATE484812T1 (de) 2010-10-15

Similar Documents

Publication Publication Date Title
FR2913556A1 (fr) Terminal de telecommunications mobile et procede de lecture d&#39;une image en mouvement sur une page web a l&#39;aide de celui-ci
WO2009124955A2 (fr) Systeme et procede de communication distribue et modulaire comprenant au moins un serveur, au moins un terminal distant, et au moins un terminal mobile capable de communiquer avec le terminal distant relie en reseau audit serveur
EP1630761B1 (fr) Système et procédé d&#39;appel automatique, moteur d&#39;alerte et poste d&#39;activation mis en oeuvre dans le système
EP3542497B1 (fr) Procédé d&#39;organisation d&#39;une pluralité de messages échangés avec un agent conversationnel
EP2454640A1 (fr) Dispositif de diagnostic a distance pour vehicule automobile
EP3632063B1 (fr) Mise a jour de messages echangés avec un agent conversationnel
FR2863811A1 (fr) Systeme de communication entre un terminal mobile et un serveur de communication et les procedes de communications associes.
KR101768212B1 (ko) 차주 호출 및 광고 서비스 시스템
FR2911751A1 (fr) Procede et installation de telecommunication pour la fourniture d&#39;un service a l&#39;utilisateur d&#39;un equipement personnel, support de donnees correspondant
FR3080943A1 (fr) Procede d’assistance d’une personne equipee d’un telephone cellulaire
FR2696256A1 (fr) Utilisation de &#34;tubes&#34; pour le transfert d&#39;états entre différents systèmes distants.
FR2811779A1 (fr) Dispositif et procede de commande des deroulements de fonctionnement
EP1208519B1 (fr) Systeme et procede de chargement de commandes dans une carte a circuit integre
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP2820821B1 (fr) Procede et dispositif de mise a disposition d&#39;au moins une donnee de communication
EP2351340B1 (fr) Procede de communication utilisant une image numerique et procede de transmission de donnees
FR2917256A1 (fr) Systeme de communication internet avec verification de liaison integree et procede correspondant
EP2274882B1 (fr) Procede de transmission de message, dispositif et produit programme d&#39;ordinateur correspondants
EP2073468A1 (fr) Objet portable pour filtrer un message entrant non voulu, terminal et procédé correspondants
FR3135372A1 (fr) Procédés et dispositifs permettant une interaction enrichie entre un véhicule connecté et un agent conversationnel.
EP3465476B1 (fr) Procédé d&#39;invocation d&#39;un service applicatif par un navigateur
EP1613031A1 (fr) Procèdè et terminal de communication pour la saisie et la transmission d&#39;un message mot par mot
WO2008056039A2 (fr) Procede et dispositif de communication
FR2979446A1 (fr) Dispositif de creation d&#39;un service utilisant une camera ip et procede de creation d&#39;un tel service
CA2262829A1 (fr) Procede de controle d&#39;un afficheur a cristaux liquides

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CARLIER, LUDOVIC

Inventor name: SAVINA, BERNARD

Inventor name: LIARD, SAMUEL

17P Request for examination filed

Effective date: 20060731

17Q First examination report despatched

Effective date: 20060901

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REF Corresponds to:

Ref document number: 602005024091

Country of ref document: DE

Date of ref document: 20101125

Kind code of ref document: P

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20101013

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Effective date: 20110302

LTIE Lt: invalidation of european patent or patent extension

Effective date: 20101013

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110213

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110214

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110113

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110114

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

26N No opposition filed

Effective date: 20110714

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602005024091

Country of ref document: DE

Effective date: 20110714

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

BERE Be: lapsed

Owner name: FRANCE TELECOM

Effective date: 20110831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110831

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602005024091

Country of ref document: DE

Effective date: 20120301

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20101013

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110824

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120301

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101013

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240723

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240723

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20240902

Year of fee payment: 20

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20250829

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20250823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20250825