EP1544824A1 - Procédé de traitement de signaux pour système d'alarme - Google Patents

Procédé de traitement de signaux pour système d'alarme Download PDF

Info

Publication number
EP1544824A1
EP1544824A1 EP04106596A EP04106596A EP1544824A1 EP 1544824 A1 EP1544824 A1 EP 1544824A1 EP 04106596 A EP04106596 A EP 04106596A EP 04106596 A EP04106596 A EP 04106596A EP 1544824 A1 EP1544824 A1 EP 1544824A1
Authority
EP
European Patent Office
Prior art keywords
alarm
message
server
alarm signal
processing method
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.)
Withdrawn
Application number
EP04106596A
Other languages
German (de)
English (en)
Inventor
Constant Van Dooren
Rudy Stamanne
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.)
Anb Securite SA
Original Assignee
Anb Securite 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 Anb Securite SA filed Critical Anb Securite SA
Publication of EP1544824A1 publication Critical patent/EP1544824A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR 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/006—Alarm destination chosen according to type of event, e.g. in case of fire phone the fire service, in case of medical emergency phone the ambulance

Definitions

  • the present invention relates to a method of treatment alarm signals comprising the reception of an alarm signal by a receiver arranged to receive the alarm signals produced by each alarm systems placed at locations to be protected and transmission by a transmitter of an alarm message to the user indicated for receive the alarm message.
  • the systems alarm system protecting the buildings against, for example, intrusion, theft, fire or other are either directly connected to the owner via a means of communication of any kind to inform him of the fact that the alarm system is triggered, either connected to centers of who are responsible for contacting the user of the places to be protected or the competent services for an intervention.
  • the monitoring center depending on the type of alarm, may possibly inform the user of the area affected by the trigger and identify which detector has been triggered (contact detector, detector volumetric, smoke detector).
  • An object of the invention is to overcome these disadvantages, in providing a device for an automated alarm system to obtain information directly on the type of alarm triggered and on the area concerned.
  • the process for processing alarm signals according to the invention comprises a server intended to receive from the receiver and send to said transmitter a information, at predetermined intervals, on the operation of said alarm system, which transmitter communicates the information to said users.
  • the user can therefore be informed continuously about regular intervals that his alarm system is operational or failed.
  • Another major problem of the state of the art is that when the alarm system is faulty, the user often goes account when it is too late, ie after a burglary or after a fire.
  • Some alarm systems operating through a monitoring center perform on demand a line test to check the operation of the alarm system of the place to be protected. Unfortunately, again, this system is cumbersome to implement and the user is not immune to human failure or forgetting.
  • the method according to the invention makes it possible to prevent these inconveniences by getting information directly about how the system works of alarm by tests at regular intervals, the duration of which varies according to desiderata of the user.
  • the connection between the alarm system and the receiver is a classic PSTN line
  • this PSTN line is used by the alarm system to send a signal to the receiver.
  • the server is planned to block the stall after a maximum number of calls for avoid that the user is flooded with message for the same intrusion and that he must bear the costs of a large number of calls.
  • the stall number is limited to five calls from the alarm system to the server.
  • the signal processing method is further characterized in that the server can append the user's number according to the type of alarm, ie depending on the type of alarm, the server can be programmed to send the message to one or more users in particular. For example, in the case of a fire alarm signal, the system will send a message to the user and the fire brigade, in the case of a failure, the system will send a message to the user and to the installer, etc.
  • the device signal processing for an alarm system according to the invention in order to be adaptable to a wide variety of alarm systems, must be able to decode a wide range of alarm signals. It is preferable that the receiver can operate at least according to standard SIA protocols and preferably, it will work according to other existing protocols. from in order to obtain a signal processing device for multi-purpose alarm system, the receiver provided is a multi-protocol receiver.
  • the signal processing device for alarm system is characterized in that the users are informed of said tripping alarm or system operation by SMS, MMS, message voice, e-mail, via an SMS operator-server, or combinations of these.
  • FIG. 1 is a representation of the treatment method alarm signals according to the invention.
  • the method includes receiving an alarm signal generated by an alarm system user (1).
  • the reception is carried out by a receiver preferably multi-protocol (2).
  • the alarm signal received via the connection (10) between the alarm system and receiver, preferably a PSTN line (10) is processed by the server (3) which identifies with a database that is associated with the user number, the type of alarm, the zone of trigger and the detectors that triggered the alarm signal.
  • the server (3) as explained below, composes a message and annex to the message the information of the recipient of the message.
  • the server (3) transmits the message to the transmitter (4) which transmits the message received to the user for example, either by SMS (5), MMS (5), message voice (5), email (6), an SMS operator-server (7), or any other means of communication and combinations thereof.
  • the information corresponding to the user number may include the number of User's GSM (5), that of a third party and for example the number of the installer (8) of the alarm so that he is warned in case system failure or the number of firefighters (9) or any other competent authority (guard service or other) in case of fire or other respectively.
  • FIG. 3 represents a detailed view of the operation of the system governing the receiver.
  • an alarm signal arrives at receiver, it signals to a computer or server that there is a call entering "RING" (31). If the computer or server is ready (authorization from the user or not, breakdown, ...), he sends the command "HANG-UP” (32), the receiver picks up and signals to the alarm system its presence “HANDSHAKE” (33).
  • the alarm system sends the data, the The receiver transfers the data for processing on the computer or server, if the data is correct, the computer or server is sending an "ACK" (34) acceptance to the receiver, if the data is incorrect, the computer or server sends a non-acceptance "NACK” (35) to the receiver.
  • Acceptance may depend on various factors, such as example, the number of signals received from the same user (looking at in the EVENTS database, the system can know how much have been received), the fact that the user has been identified as previously, or during the deviation to another receiver (failure, maintenance, update).
  • the receiver reports its status "KISS OFF" (36) if the data is correct, ie if the receiver has recognized the protocol and "NO KISS OFF" (37) if the data is incorrect.
  • the receiver decides following his condition of the transmission to hang up "END” (35) or do not hang up "CONTINUE" (38). All events are stored in a database table "EVENTS”. New events are stored in a category "NEW EVENT".
  • the alarm system sends messages to regular intervals of signals meaning that the system is operational.
  • the receiver receives the information according to the described protocol in Figure 3 and these data are stored in one of the tables of the database.
  • the line test verification system includes at least one computer (41), preferably three (41, 42, 43) and more preferentially beyond three.
  • the system checks whether a transmission of signals meaning that the system is operational has completed within the prescribed time limit (44). If it is yes (45), a signal is sent to a computer to report that everything is working and / or at the base data (47). If it is no (46), the system checks if it is able send a message (48) to the EVENTS database.
  • the system sends a failure (51) or failure message (51) in the database and sending is supported by the server and the transmitter. If it is not (50), the system means to the computer that can not send the message to the database.
  • the number of computers present in the system verification of the operation of the alarm system is three (41, 42, 43).
  • the whole process is transferred to another computer (42 or 43) that supports all the first computer line tests (41).
  • the whole process is transferred to a third computer (43) which supports all line tests of the first (41) and second computer (42).

Landscapes

  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Alarm Systems (AREA)

Abstract

La présente invention se rapporte à un procédé de traitement de signaux d'alarme comprenant la réception d'un signal d'alarme et la transmission d'un message d'alarme à l'utilisateur indiqué pour recevoir le message d'alarme. Le traitement du signal d'alarme comporte différentes étapes dont notamment l'identification de l'utilisateur, du type d'alarme, d'au moins un détecteur qui a déclenché le signal d'alarme et l'envoi à l'utilisateur d'un message SMS indiquant le type d'alarme, la zone et le détecteur qui a déclenché le signal d'alarme.

Description

La présente invention se rapporte à un procédé de traitement de signaux d'alarme comprenant la réception d'un signal d'alarme par un récepteur agencé pour recevoir les signaux d'alarme produits par chacun des systèmes d'alarmes placés à des endroits à protéger et la transmission par un transmetteur d'un message d'alarme à l'utilisateur indiqué pour recevoir le message d'alarme.
Généralement, dans l'état de la technique, les systèmes d'alarme protégeant les immeubles contre par exemple l'intrusion, le vol, l'incendie ou autre sont soit directement connectés au propriétaire via un moyen de communication quelconque pour l'informer uniquement du fait que le système d'alarme est déclenché, soit connectés à des centres de surveillance qui se chargent de contacter l'utilisateur des endroits à protéger ou les services compétents pour une intervention. Dans ce dernier cas, le centre de surveillance, en fonction du type d'alarme, peut éventuellement informer l'utilisateur de la zone touchée par le déclenchement et identifier quel détecteur a été déclenché (détecteur de contact, détecteur volumétrique, détecteur de fumée).
Un problème récemment apparu consiste en l'apparition d'une législation belge qui stipule que lorsqu'une alarme anti-vol se déclenche, les utilisateurs ne peuvent plus directement appeler la police sans avoir la confirmation que le système d'alarme s'est déclenché pour une raison valable. Jusqu'à présent, avec les systèmes d'alarme qui contactent directement l'utilisateur, l'utilisateur prend connaissance, s'il est joignable, que le système s'est déclenché et il doit réagir sans savoir exactement ce qui se passe. Il faut donc qu'il aille constater lui-même la situation ou la fasse constater par une connaissance, mais il ne peut contacter directement la police pour une intervention puisqu'il n'a pas eu de confirmation. Le système impliquant un centre de surveillance ne pose pas ce problème mais il coûte cher pour l'utilisateur et présente une mise en oeuvre fastidieuse. En outre, ce dispositif n'est pas à l'abri de la défaillance humaine, ni de celle du système d'alarme.
Un objectif de l'invention est de pallier ces inconvénients, en procurant un dispositif pour système d'alarme automatisé permettant d'obtenir une information directement sur le type d'alarme déclenché et sur la zone concernée.
En effet, l'invention procure un dispositif de traitement de signaux pour système d'alarme caractérisé en ce que le signal d'alarme reçu comporte une première partie d'identification de l'utilisateur, une deuxième partie indiquant le type d'alarme, et une troisième partie indiquant au moins un détecteur qui a déclenché le signal d'alarme, le signal reçu étant transmis pour traitement au serveur qui est associé à une base de données et relié audit transmetteur, lequel traitement comporte les étapes suivantes:
  • (a) identification par ledit serveur, sur base du contenu de la première partie dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler,
  • (b) identification par ledit serveur, sur base du contenu de la deuxième partie du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme,
  • (c) identification par ledit serveur, sur base du contenu de la troisième partie du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s),
  • (d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
  • (e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données,
  • (f) annexion au message d'alarme d'au moins un numéro d'utilisateur, prélevé à la première adresse, et envoi dudit message composé par ledit serveur au transmetteur
    • Dès lors, un message détaillé est automatiquement produit et envoyé à l'utilisateur et une fois que l'utilisateur est informé du déclenchement du système d'alarme, il peut savoir quel type d'alarme s'est produite (vol, incendie, défaillance,...) et la zone où cette dernière s'est produite. L'invention informant l'utilisateur de manière automatique, le coût est relativement faible (le prix fixé de la communication) et la mise en oeuvre est particulièrement simple.
    Dans le cas où plusieurs détecteurs ont déclenché l'alarme (cambrioleur qui se déplace d'un endroit à un autre, feu qui gagne plusieurs pièces,...) l'utilisateur reçoit plusieurs message d'alarme. Le fait de recevoir plusieurs messages écarte généralement la défaillance d'un système d'alarme et permet d'apporter une confirmation de la pertinence de l'alarme.
    Selon une réalisation préférentielle de l'invention, le procédé de traitement de signaux d'alarme selon l'invention comprend un serveur prévu pour recevoir du récepteur et envoyer audit transmetteur une information, à intervalles prédéterminés, sur le fonctionnement dudit système d'alarme, lequel transmetteur communique l'information auxdits utilisateurs. L'utilisateur peut être dès lors informé en permanence à intervalles réguliers que son système d'alarme est opérationnel ou défaillant. En effet, un autre problème majeur de l'état de la technique est que lorsque le système d'alarme est défaillant, l'utilisateur s'en rend souvent compte lorsqu'il est trop tard, c'est à dire après un cambriolage ou après un incendie. Certains systèmes d'alarme fonctionnant par l'intermédiaire d'un centre de surveillance réalisent sur demande un test de ligne pour vérifier le fonctionnement du système d'alarme de l'endroit à protéger. Malheureusement, à nouveau, ce système est lourd à mettre en oeuvre et l'utilisateur n'est pas à l'abri d'une défaillance humaine ou d'un oubli. Le procédé selon l'invention permet de prévenir ces désagréments en obtenant une information directement sur le fonctionnement du système d'alarme par des tests à intervalles réguliers dont la durée varie selon les desiderata de l'utilisateur.
    Généralement, la connexion entre le système d'alarme et le récepteur est une ligne classique PSTN, cette ligne PSTN est utilisée par le système d'alarme pour envoyer un signal au récepteur. Dans le cas d'une alarme telle qu'un cambriolage pendant lequel le voleur déclenche plusieurs détecteurs de mouvement et/ou de contact, le serveur est prévu pour bloquer le décrochage après un nombre maximum d'appel pour éviter que l'utilisateur soit inondé de message pour la même intrusion et qu'il doive assumer les frais d'un grand nombre d'appel. De préférence, le nombre de décrochage est limité à cinq appels du système d'alarme vers le serveur.
    Le procédé de traitement de signaux est, en outre, caractérisé en ce que le serveur peut annexer le numéro de l'utilisateur en fonction du type d'alarme, c'est à dire qu'en fonction du type d'alarme, le serveur peut être programmé pour envoyer le message à un ou plusieurs utilisateurs en particulier. Par exemple, dans le cas d'un signal d'alarme incendie, le système enverra un message à l'utilisateur et aux pompiers, dans le cas d'une défaillance , le système enverra un message à l'utilisateur et à l'installateur, etc.
    Les systèmes d'alarmes existant fonctionnent selon des protocoles propres, en fonction de leur programmation et de leur fabrication qui peuvent être plus ou moins différents selon les cas. Le dispositif de traitement de signaux pour système d'alarme selon l'invention, pour pouvoir être adaptable sur une grande variété de système d'alarme, doit pouvoir décoder une grande gamme de signaux d'alarmes. Il est préférable que le récepteur puisse fonctionner au moins selon les protocoles standards SIA et de préférence, il fonctionnera selon d'autres protocoles existants. Dès lors, dans le but d'obtenir un dispositif de traitement de signaux pour système d'alarme polyvalent, le récepteur procuré est un récepteur multi-protocole.
    Le dispositif de traitement de signaux pour système d'alarme est caractérisé en ce que les utilisateurs sont informés dudit déclenchement de l'alarme ou dudit fonctionnement du système par SMS, MMS, message vocal, courrier électronique, via un opérateur-serveur SMS, ou des combinaisons de ceux-ci.
    D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture du mémoire descriptif fait en référence aux dessins annexés donnés à titre d'exemples non limitatifs et dans lesquels:
  • la figure 1 est une représentation générale du procédé de traitement de signaux d'alarme selon l'invention,
  • la figure 2 est une représentation détaillée du fonctionnement du serveur,
  • la figure 3 est une vue détaillée du fonctionnement du système régissant le récepteur,
  • la figure 4 est une vue détaillée du fonctionnement du système de vérification des tests de ligne.
    • La figure 1 est une représentation du procédé de traitement de signaux d'alarme selon l'invention. Le procédé comprend la réception d'un signal d'alarme généré par un système d'alarme existant chez un utilisateur (1). La réception est réalisée par un récepteur de préférence multi-protocole (2). Le signal d'alarme reçu via la connexion (10) entre le système d'alarme et le récepteur, de préférence, une ligne PSTN (10) est traité par le serveur (3) qui identifie grâce à une base de donnée qui lui est associée le numéro de l'utilisateur, le type d'alarme, la zone de déclenchement et les détecteurs ayant déclenché le signal d'alarme. Le serveur (3), comme expliqué ci-dessous, compose un message et annexe au message l'information du destinataire du message. Le serveur (3) transmet le message au transmetteur (4) qui transmet le message reçu à l'utilisateur par exemple, soit par SMS (5), MMS (5), message vocal (5) , courrier électronique (6), un opérateur-serveur SMS (7), ou tout autre moyen de communication et combinaisons de ceux-ci. Selon le mode de réalisation, dans la base de données, l'information correspondant au numéro d'utilisateur peut comprendre le numéro de GSM de l'utilisateur (5), celui d'une tierce personne et par exemple le numéro de l'installateur (8) de l'alarme pour qu'il soit prévenu en cas d'une défaillance du système ou le numéro des pompiers (9) ou de toute autre autorité compétente (service de gardiennage ou autre) en cas d'incendie ou autre respectivement.
    La figure 2 est une représentation détaillée du fonctionnement du serveur (3), le serveur reçoit un signal provenant du récepteur multi-protocole qui comporte trois parties (P1, P2, et P3), la base de données associée au serveur comporte au moins trois tables (p1, p2, p3) dans lesquelles les informations correspondant aux adresses des trois parties du signal se trouvent. Le serveur traite le signal reçu en trois parties du récepteur selon les étapes suivantes
  • (a) identification par ledit serveur, sur base du contenu de la première partie (P1) dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse (A1) indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler (21),
  • (b) identification par ledit serveur, sur base du contenu de la deuxième partie (P2) du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse (A2) indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme (22),
  • (c) identification par ledit serveur, sur base du contenu de la troisième partie (P3) du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse (A3) indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s) (23),
  • (d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
  • (e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses (A1, A2, A3) et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données ( 22 et 23),
  • (f) annexion au message d'alarme d'au moins un numéro d'utilisateur (21), prélevé à la première adresse (A1), et envoi dudit message composé par ledit serveur au transmetteur
    • La figure 3 représente une vue détaillée du fonctionnement du système régissant le récepteur. Lorsqu'un signal d'alarme arrive au récepteur, celui-ci signale à un ordinateur ou au serveur qu'il y a un appel entrant "RING" (31). Si l'ordinateur ou le serveur est prêt (autorisation de l'utilisateur ou pas, panne, ...), il envoie la commande "HANG-UP" (32), le récepteur décroche et signale au système d'alarme sa présence "HANDSHAKE" (33). Le système d'alarme envoie les données, le récepteur transfère les données pour leur traitement à l'ordinateur ou au serveur, si les données sont correctes, l'ordinateur ou le serveur envoient une acceptation "ACK" (34) au récepteur, si les données sont incorrectes, l'ordinateur ou le serveur envoient une non acceptation "NACK" (35) au récepteur. L'acceptation peut dépendre de divers facteurs, tels que par exemple, le nombre de signaux reçus du même utilisateur (en regardant dans la base de données EVENTS, le système peut savoir combien d'appel ont été reçus), le fait que l'utilisateur ait été identifié en tant que tel auparavant, ou lors de la déviation vers un autre récepteur (panne, entretien, mise à jour). Le récepteur signale son état "KISS OFF" (36) si les données sont correctes, c'est à dire si le récepteur a reconnu le protocole et "NO KISS OFF" (37) si les données sont incorrectes. Le récepteur décide alors suivant son état de la transmission de raccrocher "END" (35) ou de ne pas raccrocher "CONTINUE" (38) . Tous les événements sont stockés dans une table de la base de données "EVENTS". Les nouveaux événements sont stockés dans une catégorie "NEW EVENT". Dès lors, que ce soit pour un test de ligne ou pour une alarme réelle qu'un signal du système d'alarme est envoyé, il est traité par le récepteur de la même manière. Seul le traitement par le serveur et l'information de l'utilisateur sont différents. Dans le cas d'un signal d'alarme réel, le traitement du signal a été décrit ci-dessus lors de la description de la figure 2. Dans le cas d'un test de ligne, le signal est traité comme illustré à la figure 4.
    Dans le but de pouvoir assurer à l'utilisateur que le système d'alarme est bien fonctionnel, le système d'alarme envoie à des intervalles réguliers des signaux signifiant que le système est opérationnel. Le récepteur reçoit les informations selon le protocole décrit à la figure 3 et ces données sont stockées dans une des tables de la base de données. Le système de vérification des tests de ligne comprend au moins un ordinateur (41), de préférence trois (41, 42, 43) et de manière plus préférentielle au delà de trois. Le système vérifie si une transmission de signaux signifiant que le système est opérationnel a bien été effectué endéans le délais imparti (44). Si c'est oui (45), un signal est envoyé à un ordinateur pour signaler que tout fonctionne et/ou à la base de données (47). Si c'est non (46), le système vérifie s'il est capable d'envoyer un message (48) dans la base de données EVENTS. Si c'est oui, (49), le système envoie un message de panne (51) ou de défaillance (51) dans la base de données et l'envoi est pris en charge par le serveur et le transmetteur. Si c'est non (50), le système signifie à l'ordinateur qu'il ne peut pas envoyer le message à la base de données. Dans cette réalisation préférentielle, le nombre d'ordinateur présent dans le système de vérification du fonctionnement du système d'alarme est de trois (41, 42, 43). Dans le cas où un ordinateur tombe en panne ou est éteint (par exemple 41 ), tout le procédé est transféré vers un autre ordinateur (42 ou 43) qui prend en charge tous les tests de ligne du premier ordinateur (41). Dans le cas ou le premier (41) et le second ordinateur (43) sont défaillants, tout le procédé est transféré vers un troisième ordinateur (43) qui prend en charge tous les tests de ligne du premier (41) et du second ordinateur (42).
    Néanmoins, le procédé selon l'invention exposé ci-dessus est donné à titre d'exemple non limitatifs, par exemple, dans une réalisation préférentielle, il existera plusieurs serveurs selon la technologie maítre-esclave qui peuvent être délocalisés pour des raisons de sécurité notamment et tous les ordinateurs utilisés dans le procédé pourront être au moins dédoublés, de même que le récepteur et le transmetteur.
    Traduction des commandes et des légendes dans les figures.
    SMA REC Récepteur du procédé de traitement de signaux d'alarme selon l'invention
    GROUP X Groupe X
    JOB X Tâche X
    Line Ringing Appel entrant
    Receiver OK? Récepteur prêt?
    Transfert line to other receiver Transfert de la ligne vers un autre récepteur
    Handshakes connexion
    no non
    yes oui
    Protocol frame OK? Données correctes?
    NO-KISS-OFF non acceptation
    KISS OFF acceptation
    STORE TO EVENTS TABLE enregistre dans la table des événements de la base de données
    Line test Job 1 Test de ligne, tâche 1
    Line test Job 2 Test de ligne, tâche 2
    Line test Job 3 Test de ligne, tâche 3
    HANG-UP Commande décrocher
    RING Commande appel entrant

    Claims (13)

    1. Procédé de traitement de signaux d'alarme comprenant la réception d'un signal d'alarme par un récepteur agencé pour recevoir les signaux d'alarme produits par chacun des systèmes d'alarmes en communication avec le récepteur et placés à des endroits à protéger et la transmission par un transmetteur d'un message d'alarme à l'utilisateur indiqué pour recevoir le message d'alarme, caractérisé en ce que le signal d'alarme reçu comporte une première partie d'identification de l'utilisateur, une deuxième partie indiquant le type d'alarme, et une troisième partie indiquant au moins un détecteur qui a déclenché le signal d'alarme, le signal reçu étant transmis pour traitement au serveur qui est associé à une base de données et relié audit transmetteur, lequel traitement comporte les étapes suivantes:
      (a) identification par ledit serveur, sur base du contenu de la première partie dudit signal d'alarme, de l'endroit d'où provient l'alarme reçue et production d'une première adresse indiquant dans la base de données l'endroit où est stocké au moins un numéro de l'utilisateur à appeler,
      (b) identification par ledit serveur, sur base du contenu de la deuxième partie du signal d'alarme, du type d'alarme reçue et production d'une deuxième adresse indiquant dans la base de données l'endroit où est stocké une première donnée décrivant le type d'alarme,
      (c) identification par ledit serveur, sur base du contenu de la troisième partie du signal d'alarme, d'au moins une zone en alarme et d'au moins un détecteur qui a déclenché le signal d'alarme reçu et production d'au moins une troisième adresse indiquant dans la base de données l'endroit où est stocké une seconde donnée décrivant la ou les zone(s) en alarme et le ou les détecteur(s) activé(s),
      (d) interrogation par ledit serveur de la base de données aux endroits indiqués par la première, deuxième et troisième adresse
      (e) prélèvement par ledit serveur dans ladite base de données des données stockées aux adresses et composition du message d'alarme par ledit serveur en utilisant les première et deuxième données,
      (f) annexion au message d'alarme d'au moins un numéro d'utilisateur, prélevé à la première adresse, et envoi dudit message composé par ledit serveur au transmetteur
    2. Procédé de traitement de signaux d'alarme selon la revendication 1 caractérisé en ce que ledit serveur est procuré pour apporter une confirmation de la pertinence de l'alarme en composant plusieurs messages consécutifs en fonction de la séquence de déclenchement des détecteurs, lesdits messages étant envoyés par le transmetteur à l'utilisateur.
    3. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 ou 2, caractérisé en ce que ledit serveur est prévu pour recevoir, à intervalles prédéterminés, du récepteur et envoyer audit transmetteur une information, sur le fonctionnement dudit système d'alarme, lequel transmetteur communique l'information auxdits utilisateurs.
    4. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 3, caractérisé en ce que le signal d'alarme est envoyé par l'intermédiaire d'une ligne PSTN.
    5. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 4, caractérisé en ce que le serveur bloque le nombre de décrochage à un nombre maximum lorsque qu'un grand nombre de signaux d'alarme sont reçus.
    6. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 5 caractérisé en ce que ledit récepteur reçoit des signaux d'alarme selon divers protocoles.
    7. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 6 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement par SMS
    8. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 6 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement par MMS.
    9. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 6 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement par message vocal.
    10. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 6 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement par courrier électronique.
    11. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 6 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement via un opérateur - serveur SMS.
    12. Procédé de traitement de signaux d'alarme l'une des revendications 7 à 11 caractérisé en ce que lesdits utilisateurs reçoivent le message d'alarme ou le message stipulant l'état de fonctionnement par une combinaison des moyens de transmissions susmentionnés.
    13. Procédé de traitement de signaux d'alarme selon l'une des revendications 1 à 12, caractérisé en ce que, lors de ladite annexion au message d'alarme d'au moins un numéro d'utilisateur, d'autres numéro d'utilisateurs sont annexés au message d'alarme, lesquels numéros d'utilisateurs varient en fonction du type d'alarme déclenchée.
    EP04106596A 2003-12-15 2004-12-15 Procédé de traitement de signaux pour système d'alarme Withdrawn EP1544824A1 (fr)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    BE2003/0659A BE1015330A6 (fr) 2003-12-15 2003-12-15 Dispositif de traitement de signaux pour systeme d'alarme.
    BE200300659 2003-12-15

    Publications (1)

    Publication Number Publication Date
    EP1544824A1 true EP1544824A1 (fr) 2005-06-22

    Family

    ID=33545842

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP04106596A Withdrawn EP1544824A1 (fr) 2003-12-15 2004-12-15 Procédé de traitement de signaux pour système d'alarme

    Country Status (2)

    Country Link
    EP (1) EP1544824A1 (fr)
    BE (1) BE1015330A6 (fr)

    Cited By (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1847973A2 (fr) * 2006-04-21 2007-10-24 Ad Koemans Système de sécurité
    DE102007009492A1 (de) 2007-02-27 2008-08-28 Niels Oliver Hanke Gefahrenmeldesystem für Brand, Wasser, Gas oder Einbruch mit Übermittlung von aktualisierbarer detaillierter Infomation über Meldungstyp, -ort und Objekt

    Citations (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO2001037589A1 (fr) * 1999-11-19 2001-05-25 Triguard Group Llc Systeme d'alarme sans fil et telephone combines relies a un reseau de gestion de l'information permettant l'emission automatique d'alertes et d'autres informations
    WO2002061706A1 (fr) * 2001-01-30 2002-08-08 Mygard Plc Procede et systeme de controle d'evenements

    Patent Citations (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO2001037589A1 (fr) * 1999-11-19 2001-05-25 Triguard Group Llc Systeme d'alarme sans fil et telephone combines relies a un reseau de gestion de l'information permettant l'emission automatique d'alertes et d'autres informations
    WO2002061706A1 (fr) * 2001-01-30 2002-08-08 Mygard Plc Procede et systeme de controle d'evenements

    Cited By (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1847973A2 (fr) * 2006-04-21 2007-10-24 Ad Koemans Système de sécurité
    EP1847973A3 (fr) * 2006-04-21 2007-11-07 Ad Koemans Système de sécurité
    DE102007009492A1 (de) 2007-02-27 2008-08-28 Niels Oliver Hanke Gefahrenmeldesystem für Brand, Wasser, Gas oder Einbruch mit Übermittlung von aktualisierbarer detaillierter Infomation über Meldungstyp, -ort und Objekt

    Also Published As

    Publication number Publication date
    BE1015330A6 (fr) 2005-01-11

    Similar Documents

    Publication Publication Date Title
    US11276299B2 (en) DIT monitoring apparatus and method
    US7262690B2 (en) Method and system for monitoring events
    US9094325B2 (en) Reputation based message analysis
    US8755500B2 (en) Biometric identification in communication
    US6442241B1 (en) Automated parallel and redundant subscriber contact and event notification system
    US7461378B2 (en) Methods and apparatus for processing an instant message
    EP1969444B1 (fr) Procede et dispositif d'utilisation de messagerie sms pour faciliter la transmission de mise a jour d'etat pour un systeme de securite
    US20150310714A1 (en) Recognizable local alert for stolen or lost mobile devices
    US7265658B2 (en) Notifying system, information providing apparatus and method, electronic device and method, and computer readable medium
    US20100190474A1 (en) Systems and methods for managing mobile communications
    US20020177428A1 (en) Remote notification of monitored condition
    US20040151282A1 (en) Condition detection and notification systems and methods
    NO336942B1 (no) Anordning av enheter for å danne et overvåkningssystem.
    US20090189758A1 (en) Systems and methods for managing site security through a communication device
    BE1015330A6 (fr) Dispositif de traitement de signaux pour systeme d'alarme.
    WO2009145371A1 (fr) Procédé pour fournir un service de sécurité par internet
    US10178188B2 (en) System for a monitored and reconstructible personal rendezvous session
    KR100863181B1 (ko) 인터넷을 이용한 보안 서비스 제공 방법
    EP3769504B1 (fr) Methode de gestion de l'assistance a une personne en reponse a l'emission d'une alerte
    US20090051525A1 (en) Security system and services
    Furtado et al. SMS-Based Offline Mobile Device Security System
    EP1418503A1 (fr) Système de sécurité pour un réseau d'ordinateurs
    FR3000270A1 (fr) Dispositif et procede de signalisation d'alarme
    FR3106920A1 (fr) Procede de gestion d’un mode de fonctionnement d’une centrale d’alarme et dispositif associe
    KR20060000024A (ko) 이벤트 발생시의 영상 정보 저장 및 알림 서비스 방법

    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 MC NL PL PT RO SE SI SK TR

    AX Request for extension of the european patent

    Extension state: AL BA HR LV MK YU

    AKX Designation fees paid
    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: 8566

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

    Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

    18D Application deemed to be withdrawn

    Effective date: 20051223