FR3045185A1 - Procede d'envoi de message, en particulier de messages sms dans un contexte medical - Google Patents

Procede d'envoi de message, en particulier de messages sms dans un contexte medical Download PDF

Info

Publication number
FR3045185A1
FR3045185A1 FR1562051A FR1562051A FR3045185A1 FR 3045185 A1 FR3045185 A1 FR 3045185A1 FR 1562051 A FR1562051 A FR 1562051A FR 1562051 A FR1562051 A FR 1562051A FR 3045185 A1 FR3045185 A1 FR 3045185A1
Authority
FR
France
Prior art keywords
server
user
message
identifier
sending
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
FR1562051A
Other languages
English (en)
Other versions
FR3045185B1 (fr
Inventor
Alexis Hernot
Corinne Segalen
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.)
Calmedica
Original Assignee
Calmedica
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 Calmedica filed Critical Calmedica
Priority to FR1562051A priority Critical patent/FR3045185B1/fr
Publication of FR3045185A1 publication Critical patent/FR3045185A1/fr
Application granted granted Critical
Publication of FR3045185B1 publication Critical patent/FR3045185B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Procédé d'envoi de message par au moins un premier serveur (100) dans lequel sont enregistrés au sein d'une mémoire non-volatile (101), pour chaque utilisateur, un identifiant chiffré (IDC) de l'utilisateur et une information de contact (INCO), le procédé comportant : - une réception par ledit premier serveur (100) d'une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré (ID), - un enregistrement dans une mémoire volatile (104) du premier serveur de ladite requête d'envoi de message, - une émission par ledit premier serveur à un système de chiffrement (300) d'une requête de chiffrement dudit identifiant non-chiffré, - une réception par ledit premier serveur d'un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - un envoi du message. L'invention concerne également un serveur d'envoi de message et un système comprenant ce serveur.

Description

Arrière-plan de l'invention L'invention se rapporte au domaine général de l'envoi de messages par un serveur vers un utilisateur. L'invention concerne tout particulièrement l'envoi de messages SMS à des utilisateurs dans un contexte médical.
Dans un contexte médical, les messages échangés avec des utilisateurs comportent des informations confidentielles car propres à chaque utilisateur, et chaque utilisateur peut souhaiter que ces informations ne soient pas divulguées à des tiers autres que les professionnels de la santé.
Ces informations peuvent être relatives à un traitement ou à un suivi de données médicales. Les informations échangées dans un contexte médical sont en fait, de manière générale, des informations échangées entre un patient ou utilisateur et un professionnel de la santé.
Du fait de leur confidentialité, il est parfois délicat d'utiliser des moyens de communication électronique entre les professionnels de la santé et les utilisateurs.
Des solutions existantes ne permettent pas d'éviter de manière satisfaisante qu'un tiers obtienne de manière frauduleuse des informations médicales sur un utilisateur.
Tel est notamment le cas dans les systèmes où les identités des patients sont stockées en regard d'informations médicales. L'invention vise notamment à pallier ces inconvénients, et elle vise en particulier à permettre l'échange d'informations de manière sécurisé dans un contexte médical.
Objet et résumé de l'invention
La présente invention répond à ce besoin en proposant un procédé d'envoi de message.
Selon une caractéristique générale, ce procédé est mis en œuvre par au moins un premier serveur dans lequel sont enregistrés au sein d'une mémoire non-volatile, pour chaque utilisateur d'une pluralité d'utilisateurs, un identifiant chiffré de l'utilisateur et une information de contact utilisable pour l'envoi à l'utilisateur d'un message, le procédé comportant : - une réception par ledit premier serveur d'une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré, la requête d'envoi de message étant émise par un deuxième serveur distinct du premier serveur, - un enregistrement dans une mémoire volatile du premier serveur de ladite requête d'envoi de message, - une émission par ledit premier serveur à un système de chiffrement d'une requête de chiffrement dudit identifiant non-chiffré, le système de chiffrement étant distinct dudit premier serveur, - une réception par ledit premier serveur d'un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - un envoi dudit message à envoyer à un utilisateur à partir des informations de contact stockées dans ladite mémoire non-volatile et associées audit identifiant chiffré.
Il convient de noter que dans la présente demande de brevet, on entend par « enregistrement dans une mémoire volatile », un enregistrement uniquement dans cette mémoire volatile, de sorte que l'information n'est conservée que pendant qu'elle est toujours utile, c'est-à-dire jusqu'à l'envoi dudit message. Un enregistrement dans une mémoire volatile permet de faire disparaître les informations qui y sont enregistrées dès lors que la mémoire volatile n'est plus alimentée. Aussi, si le procédé tel que défini-ci-avant est mis en œuvre au moyen d'un programme d'ordinateur exécuté par le serveur, alors dès que ce programme a fini d'être exécuté, le système d'exploitation du serveur peut réutiliser les parties de la mémoire volatile pour y inscrire d'autres données, cette zone étant affectée à d'autres tâches.
Le procédé tel que défini ci-avant ne comporte aucune exécution d'une instruction visant à écrire dans une mémoire non-volatile.
Cela rend particulièrement difficile la possibilité de lier tous les identifiants chiffrés stockés dans le premier serveur et tous les identifiants non-chiffrés qui sont stockés dans le deuxième serveur. Il en découle qu'il est particulièrement difficile de lier les informations contenues dans les messages qui proviennent du deuxième serveur aux informations de contact contenues dans le deuxième serveur et qui permettent de retrouver l'identité d'un utilisateur.
Aussi, en utilisant un système de chiffrement distinct des premier et deuxième serveurs, on rend encore plus difficile cette liaison entre les informations contenues dans les messages et les informations de contact : la prise de contrôle du premier serveur n'est ainsi pas suffisante.
Le procédé tel que défini ci-avant permet donc d'obtenir un bon niveau de sécurité, et il est particulièrement bien adapté à un contexte médical.
En d'autres termes, ledit message peut comporter des informations médicales propres à l'utilisateur.
Selon un mode particulier de mise en œuvre, le procédé comprend une inscription préalable dudit utilisateur de ladite pluralité d'utilisateur, ladite inscription comportant : - une réception par ledit premier serveur d'une requête d'inscription dudit utilisateur comportant ladite information de contact, - une élaboration dudit identifiant non-chiffré par ledit premier serveur et un enregistrement dans ladite mémoire volatile du premier serveur dudit identifiant non-chiffré, - une émission par ledit premier serveur audit système de chiffrement d'une requête de chiffrement dudit identifiant non-chiffré, - une réception par ledit premier serveur de l'identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - un enregistrement de ladite information de contact et dudit identifiant chiffré dans ladite mémoire non-volatile du premier serveur.
Ainsi, même lors de l'inscription préalable d'un utilisateur, un bon niveau de sécurité est obtenu.
Selon un mode particulier de mise en œuvre, le procédé comporte en outre postérieurement à l'envoi dudit message, une émission d'une confirmation d'envoi par ledit premier serveur audit deuxième serveur.
Selon un mode particulier de mise en œuvre, l'envoi dudit message comporte l'envoi d'un message de type SMS (« Short Message Service » en langue anglaise), ladite information de contact comportant un numéro de téléphone.
Ce mode particulier de mise en œuvre est particulièrement avantageux car les SMS ne requièrent par l'utilisation de données internet, et ces messages peuvent être reçus facilement dès lors que le terminal destinataire est connecté à un réseau de communication mobile.
Selon un mode particulier de mise en œuvre, le procédé comporte en outre : - une réception par ledit premier serveur, d'un message supplémentaire émis par ledit utilisateur et comportant une réponse de l'utilisateur et ladite information de contact, - une détermination par ledit premier serveur de l'identifiant chiffré associé aux informations de contact de l'utilisateur à partir dudit message supplémentaire, - une émission par ledit premier serveur audit système de chiffrement d'une requête de déchiffrement dudit identifiant chiffré, - une réception par ledit premier serveur de l'identifiant non-chiffré émis par le système de chiffrement, et un enregistrement dans ladite mémoire volatile dudit identifiant non-chiffré, - une émission par ledit premier serveur audit deuxième serveur de ladite réponse de l'utilisateur et dudit identifiant non-chiffré.
Ce mode particulier de mise en œuvre permet de traiter de manière sécurisée une réponse envoyée par un utilisateur.
Ainsi, l'invention est particulièrement bien adaptée à l'échange de message entre un ou des serveurs (le deuxième ou le premier et le deuxième serveur) et un utilisateur, par exemple par SMS.
On peut noter que dans ce mode de réalisation, on utilise la mémoire volatile du premier serveur pour stocker l'identifiant non-chiffré, de ce fait, l'identifiant non-chiffré n'est enregistré que temporairement dans le premier serveur.
Selon un mode particulier de mise en œuvre, la réponse de l'utilisateur comporte au moins un code associé à au moins un message reçu par ledit utilisateur.
Par code, on entend une combinaison de symboles, par exemple des lettres.
Ce mode particulier de mise en œuvre permet de traiter automatiquement les réponses par le deuxième serveur, les codes pouvant permettre de déterminer automatiquement à quels messages ou questions antérieures la réponse se rapporte.
Selon un mode particulier de mise en œuvre, le procédé comprend en outre un envoi d'un message d'alerte après une détection d'une anomalie par ledit deuxième serveur.
Ce mode de mise en œuvre convient au contexte médical dans lequel une anomalie peut être liée à un problème de santé et est donc préférentiellement traitée sous la forme d'une alerte.
Selon un mode particulier de mise en œuvre, ladite anomalie est choisie dans le groupe formé par : une anomalie dans la distribution dudit message audit utilisateur, une anomalie dans la réception de ladite réponse de l'utilisateur, et une anomalie dans la réponse de l'utilisateur.
Selon un mode particulier de mise en œuvre, ledit deuxième serveur envoie ladite requête d'envoi de message audit premier serveur après vérification d'une condition par ledit deuxième serveur.
En d'autres termes, c'est le deuxième serveur qui prend la décision d'envoyer un message. L'invention propose également un serveur d'envoi de messages comprenant : une mémoire non-volatile dans laquelle est enregistré, pour chaque utilisateur d'une pluralité d'utilisateurs, un identifiant chiffré de l'utilisateur et une information de contact utilisable pour l'envoi à l'utilisateur d'un message, une mémoire volatile, un module configuré pour : - recevoir une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré, la requête d'envoi de message étant émise par un deuxième serveur distinct du serveur d'envoi de messages, - enregistrer dans ladite mémoire volatile du premier serveur ladite requête d'envoi de message, - émettre à un système de chiffrement une requête de chiffrement dudit identifiant non-chiffré, le système de chiffrement étant distinct dudit serveur d'envoi de message, - recevoir un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - envoyer ledit message à envoyer à un utilisateur à partir des informations de contact stockées dans ladite mémoire non-volatile et associées audit identifiant chiffré.
Ce serveur peut être configuré pour mettre en œuvre les différents modes de mise en œuvre du procédé tel que défini ci-avant en agissant en tant que premier serveur. L'invention propose également un système comportant : un serveur d'envoi de messages tel que défini ci-avant, un deuxième serveur dans lequel est enregistré, pour chaque utilisateur de la pluralité d'utilisateurs, un identifiant non-chiffré de l'utilisateur, le deuxième serveur étant apte à communiquer avec ledit serveur d'envoi de message, et un système de chiffrement apte à communiquer avec ledit serveur d'envoi de messages.
Ce système peut être configuré pour mettre en œuvre les différents modes de mise en œuvre du procédé tel que défini ci-avant. L'invention propose également un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé tel que défini ci-avant, lorsque ledit programme est exécuté par un processeur du premier serveur. L'invention propose également un support d'enregistrement lisible par un processeur, sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé tel que défini ci-avant.
On peut noter que les programme d'ordinateur mentionnés dans le présent exposé peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
De plus, les supports d'enregistrement (ou d'information) mentionnés dans le présent exposé peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente de façon schématique un système selon un mode de réalisation de l'invention, - la figure 2 représente les différentes étapes d'une inscription d'utilisateur selon un mode de mise en oeuvre de l'invention, - la figure 3 représente les différentes étapes d'un envoi de message selon un mode de mise en oeuvre de l'invention, et - la figure 4 représente les différentes étapes d'une réception de réponse selon un mode de mise en œuvre de l'invention.
Description détaillée d'un mode de réalisation
Nous allons maintenant décrire un système et un procédé d'envoi de messages, conformément à un mode particulier de réalisation et de mise en œuvre de l'invention. Dans ce qui suit, l'invention est appliquée au domaine médical, toutefois, cela n'est nullement limitatif et l'invention peut concerner d'autres domaines.
Sur la figure 1, on a représenté un système comportant un premier serveur 100, un deuxième serveur 200, et un système de chiffrement 300 distincts les uns des autres.
Le premier serveur 100 et le deuxième serveur 200 communiquent (flèches Cl et C2 sur la figure) en utilisant un protocole de transfert de données sécurisé de type HTTPS (« HyperText Transfer Protocol Secure » en langue anglaise). Les anciens protocoles bien connus de l'homme du métier sous l'acronyme anglo-saxon « SSL : Secure Sockets Layer » versions 2 et 3 ont été désactivés.
Le premier serveur 100 et le système de chiffrement 300 communiquent (flèches C3 et C4 sur la figure) de la même manière.
Le premier serveur 100 est un serveur d'envoi de messages à des utilisateurs. Ce serveur comprend une mémoire non-volatile 101 (par exemple un disque dur) qui comporte une liste 102 dans laquelle sont inscrits, pour chaque utilisateur d'une pluralité d'utilisateurs, une paire de données 103 comprenant un identifiant chiffré IDC et une information de contact INCO utilisable pour l'envoi à l'utilisateur d'un message. Dans les exemples de la présente description détaillée, l'information de contact est un numéro de téléphone portable et les messages sont des messages de type SMS (« Short Message Service » en langue anglaise).
Le premier serveur 100 comprend également une mémoire volatile 104 qui est utilisée lors de l'envoi de messages aux utilisateurs pour stocker des identifiants non-chiffrés et les messages MSG (105 sur la figure). En fait, le premier serveur 100 selon l'invention ne prévoit pas d'enregistrement d'un identifiant non-chiffré dans la mémoire non-volatile 101. Le serveur 100 comporte en outre un module 106, ici un processeur, configuré pour l'exécution d'instructions 107 (c'est-à-dire un programme d'ordinateur) enregistrées dans la mémoire non-volatile 101 pour : - recevoir une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré, la requête d'envoi de message étant émise par le deuxième serveur 200, - enregistrer dans ladite mémoire volatile 104 du premier serveur ladite requête d'envoi de message, - émettre audit système de chiffrement 300 une requête de chiffrement dudit identifiant non-chiffré, - recevoir un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - envoyer ledit message à envoyer à un utilisateur à partir des informations de contact INCO stockées dans ladite mémoire non-volatile 101 et associées audit identifiant chiffré IDC.
Les instructions 107 ne comportent aucune instruction pour enregistrer dans la mémoire non-volatile 101 un identifiant non-chiffré. De ce fait, lors de l'exécution des instructions 107, le système d'exploitation du serveur 100 qui exécute les instructions 107 sur le module 106, il n'y a qu'une utilisation de la mémoire volatile 104 pour enregistrer des identifiants non-chiffrés.
Le premier serveur 100 comporte également un module de communication 108 pour la communication avec le deuxième serveur 200 et avec le système de chiffrement 300.
Le premier serveur 100 comporte en outre un module de communication 109 pour communiquer avec les utilisateurs. Le module de communication 109 peut être une passerelle SMS. Alternativement, la passerelle SMS peut être extérieure au premier serveur 100. Aussi, plusieurs passerelles SMS peuvent être utilisées pour obtenir une bonne redondance et un meilleur niveau de fiabilité. L'invention n'est néanmoins pas limitée aux envois par SMS et le module de communication peut être, dans des alternatives non représentées ici, un module d'envoi de courriels (dans cette alternative, les informations de contact sont des adresses de courriel). Alternativement, tout moyen de communication électronique pour communiquer avec un utilisateur peut être utilisé dès lors que ce moyen utilise une information de contact.
On peut noter que le système de chiffrement 300 est ici un Module Matériel de Sécurité, plus connu de l'homme du métier sous l'acronyme anglo-saxon « HSM :Hardware Security Module ».
Le deuxième serveur 200 est un serveur qui comporte des informations médicales, et avec lequel on décide de l'envoi de messages à des utilisateurs. Le deuxième serveur 200 présente donc des interfaces classiques pour que d'autres utilisateurs (des utilisateurs autres que ceux visés par les identifiants chiffrés et non-chiffrés définis ci-avant) puissent interagir avec ce deuxième serveur 200.
Le deuxième serveur 200 comporte une mémoire non-volatile 201 comprenant une liste 202 dans laquelle sont inscrits, pour chaque utilisateur de ladite pluralité d'utilisateurs, une paire de données 203 comprenant un identifiant non-chiffré ID et des informations médicales INM.
Le deuxième serveur comporte également un module tel qu'un processeur pour exécuter des instructions 205 (c'est-à-dire un programme d'ordinateur) stockées dans la mémoire non-volatile 201. L'exécution de ces instructions peut notamment : - déclencher l'envoi d'un message si une condition est vérifiée (par exemple une condition relative à des informations médicales INM), - envoyer un message d'alerte après détection d'une anomalie, - demander l'ajout d'un utilisateur au premier serveur 100.
On peut noter que l'envoi d'un message d'alerte peut être fait par tout moyen de communication connu, par exemple par courriel ou par SMS.
Sur la figure 2, on a représenté de manière schématique différentes étapes de l'inscription d'un utilisateur. Ces étapes sont mises en œuvre préalablement à l'envoi d'un message à l'utilisateur, et elles sont mises en œuvre par le premier serveur 100, le deuxième serveur 200, et le système de chiffrement 300 décrits en se référant à la figure 1.
Dans une première étape Al, par une interface du deuxième serveur l'ajout d'un utilisateur est demandé et il est saisi dans le deuxième serveur les informations de contact de l'utilisateur ainsi que des informations médicales.
Les informations de contact de l'utilisateur ne sont enregistrées que dans une mémoire volatile du deuxième serveur, non représentée sur la figure 1 pour des raisons de simplicité.
Dans une étape A2, une requête d'ajout ou d'inscription d'utilisateur est envoyée au premier serveur. Le premier serveur reçoit ensuite cette requête (étape B2).
Le premier serveur élabore ou génère au cours de l'étape B3 un identifiant non-chiffré (par exemple un nombre aléatoire), puis il enregistre cet identifiant non-chiffré dans sa mémoire volatile (étape B4). Il n'y a pas d'enregistrement dans la mémoire non-volatile de l'identifiant non-chiffré.
Une requête de chiffrement de l'identifiant non-chiffré obtenu à l'étape B3 est ensuite émise au système de chiffrement à l'étape B5.
Le système de chiffrement reçoit cette requête (étape C5), puis il chiffre l'identifiant non-chiffré (étape C6) et l'envoi au premier serveur (étape C7). A titre indicatif, le système de chiffrement peut utiliser un algorithme de chiffrement choisi dans le groupe comprenant : DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 128 bits, DESX, AES 128 bits, AES 196 bits, et AES 256 bits.
Le premier serveur reçoit l'identifiant chiffré émis par le système de chiffrement à l'étape B7, puis il enregistre à l'étape B8 l'identifiant chiffré ainsi que les informations de contact dans sa mémoire non volatile à l'étape B8. On obtient ainsi la paire formée par l'identifiant chiffré IDC et l'information de contact INCO décrite en référence à la figure 1.
Ensuite, le premier serveur émet au deuxième serveur l'identifiant non-chiffré qui était mémorisé dans la mémoire volatile du premier serveur (étape B9).
Le deuxième serveur reçoit l'identifiant non-chiffré (étape A9), puis il l'enregistre dans sa mémoire non-volatile de sorte que les informations médicales saisies lors de l'étape Al soient associées à cet identifiant non-chiffré. On obtient ainsi la paire formée par l'identifiant non-chiffré ID et les informations médicales INM décrites en se référant à la figure 1.
La figure 3 illustre différentes étapes de l'envoi d'un message à un utilisateur.
Dans une première étape A20, le deuxième serveur détecte qu'une condition est vérifiée.
Cette condition peut être choisie dans le groupe suivant : - un délai défini à compter d'une date saisie antérieurement à expiré (par exemple une date saisie dans des informations médicales INM), - un délai défini à compter d'un évènement tel qu'un envoi antérieur de message a expiré (par exemple un envoi répété toutes les 30 minutes tant qu'il n'y a pas de réponse), - une réponse a été reçue par un utilisateur et cette réponse nécessite l'envoi d'un nouveau message (par exemple pour obtenir une confirmation d'une réponse déjà envoyée par l'utilisateur, ou encore si la réponse de l'utilisateur n'est pas interprétable).
Une requête d'envoi de message est ensuite envoyée à l'étape A21, avec dans cette requête l'identifiant non chiffré enregistré dans le deuxième serveur et également le message en tant que tel.
Cette requête d'envoi de message est reçue par le premier serveur à l'étape B21, qui enregistre (étape B22) dans sa mémoire volatile l'identifiant non chiffré ainsi que le message.
Ce message peut être une question à l'utilisateur, mais d'autres messages peuvent être envoyés à l'utilisateur, par exemple pour fournir des informations à l'utilisateur.
Une requête de chiffrement de l'identifiant non-chiffré reçu à l'étape B21 est ensuite émise vers le système de chiffrement (étape B23).
Le système de chiffrement reçoit cette requête (étape C23), chiffre l'identifiant non-chiffré (étape C24), et envoi l'identifiant non chiffré (étape C25).
Le premier serveur reçoit l'identifiant chiffré (B25) et il utilise cet identifiant chiffré pour récupérer les informations de contact qui correspondent à cet identifiant chiffré (étape B26) : les identifiants chiffrés et les informations de contact sont enregistrées dans la mémoire non-volatile du premier serveur. A l'étape B27, le premier serveur émet le message au terminal d'un utilisateur, au moyen d'une passerelle SMS, ou alternativement de deux passerelles SMS redondantes.
Une confirmation d'envoi est ensuite émise à l'étape B28. Cette confirmation d'envoi peut n'être émise qu'après réception d'une confirmation de réception émise par l'utilisateur.
Le deuxième serveur reçoit à l'étape A28 la confirmation d'envoi.
La figure 4 concerne les différentes étapes liées au traitement d'une réponse émise par un utilisateur. Les étapes de cette figure peuvent être mises en œuvre postérieurement à celles décrites en se référant aux figures 2 et 3. C'est donc dans une étape ultérieure D40 par rapport à la réception du message D27 décrite en référence à la figure 3 que l'utilisateur saisit une réponse sur son terminal (par exemple un ordiphone). A titre indicatif, la réponse peut être un code associé à un message reçu par l'utilisateur. Par exemple, un message antérieur peut être formulé sous la forme d'une question invitant l'utilisateur à répondre un code à trois lettres en fonction de la réponse que l'utilisateur souhaite apporter.
Par exemple, des questions Q1 et Q2 peuvent être formulées ainsi : - Q1 :« Si la condition X est vérifiée, alors répondez ABC », avec X une condition qu'un utilisateur peut vérifier lui-même et ABC un code à trois lettres, - Q2 :« Mesurez Y, répondez avec une valeur mesurée comprise entre 1 et 100 », avec Y un paramètre mesurable par un utilisateur.
La réponse est envoyée au premier serveur à l'étape D41 qui reçoit cette réponse à l'étape B41.
La réponse comporte les informations de contact de l'utilisateur, comme cela est classique dans l'échange de messages SMS. A l'étape B42, on détermine l'identifiant chiffré enregistré dans la mémoire non-volatile du premier serveur et qui est associé aux informations de contact de la réponse reçue. A l'étape B43, le premier serveur émet une requête de déchiffrement au système de chiffrement.
Le système de chiffrement reçoit cette requête de déchiffrement à l'étape C43 et il déchiffre à l'étape C44 l'identifiant pour obtenir un identifiant non-chiffré. A l'étape C45, l'identifiant non-chiffré est envoyé par le système de chiffrement au premier serveur qui le reçoit à l'étape B45. L'identifiant non-chiffré est enregistré uniquement dans la mémoire volatile à l'étape B46 (sans être enregistré dans la mémoire non-volatile du premier serveur). L'identifiant non-chiffré et la réponse de l'utilisateur sont ensuite émis au deuxième serveur (étape B47).
Le deuxième serveur reçoit la réponse ainsi que l'identifiant non-chiffré à l'étape A47, et il peut ensuite traiter cette réponse (étape A48).
Une réponse sous la forme d'un code associé au message reçu par l'utilisateur permettra de lier automatiquement les messages envoyés et les réponses de l'utilisateur. A titre indicatif, si lesdites deux questions Q1 et Q2 sont envoyés successivement et que ces questions invitent l'utilisateur à répondre à Q1 avec une réponse attendue ABC, et à répondre à Q2 avec une réponse chiffrée entre 1 et 100, dès lors que l'utilisateur répond le code à trois lettres ABC et un nombre entre 1 et 100, dans n'importe quel ordre et même dans le même SMS, le deuxième serveur peut associer RI à ABC et R2 au nombre. Cela est rendu possible par le format utilisé par les deux réponses, une avec des lettres, et une avec un nombre compris entre 1 et 100.
Il est possible d'associer des questions à leurs réponses respectives dès lors que ces réponses sont suffisamment distinctes les unes par rapport aux autres, et qu'il n'y a pas de chevauchement entre les réponses. A titre indicatif, deux questions envoyées successivement peuvent attendre des réponses chiffrées dès lors que les gammes correspondant à chaque réponse sont distinctes. Deux questions envoyées successivement peuvent attendre des réponses en lettres dès lors que les codes des deux réponses ne comportent pas de lettre en commun, ou encore pas de paires de lettres en commun.
Ceci peut permettre d'obtenir plus de liberté dans l'envoi des messages et leur traitement par l'utilisateur : ce dernier peut répondre facilement aux messages dans l'ordre qu'il souhaite.
Dans l'exemple illustré sur la figure 4, le traitement de la réponse à l'étape 48 conduit le deuxième serveur à considérer qu'une alerte doit être émise (étape A49), car une anomalie a été détectée dans la réponse de l'utilisateur.
Cette anomalie peut être par exemple une réponse qui ne peut pas être interprétée, ou encore une réponse qui indique expressément une anomalie. Tel peut être le cas si la question est formulée ainsi « si une anomalie X est détectée, répondez OUI », tel sera également le cas si la question demande une valeur numérique, et que cette valeur numérique dépasse un seuil.
Alternativement, l'alerte peut être émise si plusieurs conditions sont vérifiées pour plusieurs messages de l'utilisateur. C'est donc une combinaison de conditions qui déclenche l'émission d'une alerte.
Dans une variante non représentée sur la figure 4, une erreur dans la distribution du message à l'utilisateur est apparue. Cette erreur peut être liée à un numéro de téléphone erroné, une passerelle SMS indisponible, une absence d'accusé d'envoi émis par une passerelle SMS, ou encore un SMS non délivré.
Dans une autre variante, c'est l'absence de réponse d'un utilisateur qui déclenche une alerte. L'alerte pourra par exemple être faite sous la forme d'un courriel envoyé à un professionnel de la santé en relation avec l'utilisateur. L'invention est donc particulièrement bien adaptée au traitement de messages dans le domaine médical, puisqu'elle permet d'obtenir un bon niveau de confidentialité et de sécurité.
On peut noter que l'invention est particulièrement bien adaptée au suivi d'un utilisateur après une opération chirurgicale.

Claims (14)

  1. REVENDICATIONS
    1. Procédé d'envoi de message caractérisé en ce que le procédé est mis en œuvre par au moins un premier serveur (100) dans lequel sont enregistrés au sein d'une mémoire non-volatile (101), pour chaque utilisateur d'une pluralité d'utilisateurs, un identifiant chiffré (IDC) de l'utilisateur et une information de contact (INCO) utilisable pour l'envoi à l'utilisateur d'un message, le procédé comportant : - une réception par ledit premier serveur (100) d'une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré (ID), la requête d'envoi de message étant émise par un deuxième serveur (200) distinct du premier serveur, - un enregistrement dans une mémoire volatile (104) du premier serveur de ladite requête d'envoi de message, - une émission par ledit premier serveur à un système de chiffrement (300) d'une requête de chiffrement dudit identifiant non-chiffré, le système de chiffrement étant distinct dudit premier serveur, - une réception par ledit premier serveur d'un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - un envoi dudit message à envoyer à un utilisateur à partir des informations de contact stockées dans ladite mémoire non-volatile et associées audit identifiant chiffré.
  2. 2. Procédé selon la revendication 1, comprenant une inscription préalable dudit utilisateur de ladite pluralité d'utilisateur, ladite inscription comportant : - une réception par ledit premier serveur (100) d'une requête d'inscription dudit utilisateur comportant ladite information de contact (INCO), - une élaboration dudit identifiant non-chiffré (ID) par ledit premier serveur et un enregistrement dans ladite mémoire volatile (104) du premier serveur dudit identifiant non-chiffré, - une émission par ledit premier serveur audit système de chiffrement (300) d'une requête de chiffrement dudit identifiant non-chiffré, - une réception par ledit premier serveur de l'identifiant chiffré (IDC) associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - un enregistrement de ladite information de contact (INCO) et dudit identifiant chiffré (IDC) dans ladite mémoire non-volatile du premier serveur.
  3. 3. Procédé selon la revendication 1 ou 2, comportant en outre postérieurement à l'envoi dudit message, une émission d'une confirmation d'envoi par ledit premier serveur audit deuxième serveur.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel l'envoi dudit message comporte l'envoi d'un message de type SMS, ladite information de contact comportant un numéro de téléphone.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4, comportant en outre : - une réception par ledit premier serveur (100), d'un message supplémentaire émis par ledit utilisateur et comportant une réponse de l'utilisateur et ladite information de contact (INCO), - une détermination par ledit premier serveur de l'identifiant chiffré (IDC) associé aux informations de contact de l'utilisateur à partir dudit message supplémentaire, - une émission par ledit premier serveur audit système de chiffrement (300) d'une requête de déchiffrement dudit identifiant chiffré, - une réception par ledit premier serveur de l'identifiant non-chiffré émis par le système de chiffrement, et un enregistrement dans ladite mémoire volatile (104) dudit identifiant non-chiffré, - une émission par ledit premier serveur audit deuxième serveur de ladite réponse de l'utilisateur et dudit identifiant non-chiffré.
  6. 6. Procédé selon la revendication 5, dans lequel la réponse de l'utilisateur comporte au moins un code associé à au moins un message reçu par ledit utilisateur.
  7. 7. Procédé selon la revendication 5 ou 6, comprenant en outre un envoi d'un message d'alerte après une détection d'une anomalie par ledit deuxième serveur.
  8. 8. Procédé selon la revendication 7, dans lequel ladite anomalie est choisie dans le groupe formé par : une anomalie dans la distribution dudit message audit utilisateur, une anomalie dans la réception de ladite réponse de l'utilisateur, et une anomalie dans la réponse de l'utilisateur.
  9. 9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel ledit deuxième serveur envoie ladite requête d'envoi de message audit premier serveur après vérification d'une condition par ledit deuxième serveur.
  10. 10. Procédé selon l'une quelconque des revendications 1 à 9, dans lequel ledit message comporte des informations médicales propres à l'utilisateur.
  11. 11. Serveur d'envoi de messages comprenant : une mémoire non-volatile (101) dans laquelle est enregistré, pour chaque utilisateur d'une pluralité d'utilisateurs, un identifiant chiffré (ICD) de l'utilisateur et une information de contact (INCO) utilisable pour l'envoi à l'utilisateur d'un message, une mémoire volatile (104), un module (106, 107) configuré pour : - recevoir une requête d'envoi de message comportant un message à envoyer et un identifiant non-chiffré, la requête d'envoi de message étant émise par un deuxième serveur distinct du serveur d'envoi de messages, - enregistrer dans ladite mémoire volatile du premier serveur ladite requête d'envoi de message, - émettre à un système de chiffrement une requête de chiffrement dudit identifiant non-chiffré, le système de chiffrement étant distinct dudit serveur d'envoi de message, - recevoir un identifiant chiffré associé audit identifiant non-chiffré et émis par ledit système de chiffrement, - envoyer ledit message à envoyer à un utilisateur à partir des informations de contact stockées dans ladite mémoire non-volatile et associées audit identifiant chiffré.
  12. 12. Système comportant : un serveur d'envoi de messages (100) selon la revendication 11, un deuxième serveur (200) dans lequel est enregistré, pour chaque utilisateur de la pluralité d'utilisateurs, un identifiant non-chiffré de l'utilisateur, le deuxième serveur étant apte à communiquer avec ledit serveur d'envoi de message, et un système de chiffrement (300) apte à communiquer avec ledit serveur d'envoi de messages.
  13. 13. Programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté par un processeur du premier serveur.
  14. 14. Support d'enregistrement lisible par un processeur, sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 6.
FR1562051A 2015-12-09 2015-12-09 Procede d'envoi de message, en particulier de messages sms dans un contexte medical Expired - Fee Related FR3045185B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1562051A FR3045185B1 (fr) 2015-12-09 2015-12-09 Procede d'envoi de message, en particulier de messages sms dans un contexte medical

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562051 2015-12-09
FR1562051A FR3045185B1 (fr) 2015-12-09 2015-12-09 Procede d'envoi de message, en particulier de messages sms dans un contexte medical

Publications (2)

Publication Number Publication Date
FR3045185A1 true FR3045185A1 (fr) 2017-06-16
FR3045185B1 FR3045185B1 (fr) 2018-02-09

Family

ID=55486802

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1562051A Expired - Fee Related FR3045185B1 (fr) 2015-12-09 2015-12-09 Procede d'envoi de message, en particulier de messages sms dans un contexte medical

Country Status (1)

Country Link
FR (1) FR3045185B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050165623A1 (en) * 2003-03-12 2005-07-28 Landi William A. Systems and methods for encryption-based de-identification of protected health information
US20080021834A1 (en) * 2006-07-19 2008-01-24 Mdatalink, Llc Medical Data Encryption For Communication Over A Vulnerable System
US20140303989A1 (en) * 2005-03-16 2014-10-09 Alexander Ferguson Automated medication management system and method for use
US8948793B1 (en) * 2010-02-12 2015-02-03 Bruce R. Birkhold System and method for automated remote messaging to wireless mobile devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050165623A1 (en) * 2003-03-12 2005-07-28 Landi William A. Systems and methods for encryption-based de-identification of protected health information
US20140303989A1 (en) * 2005-03-16 2014-10-09 Alexander Ferguson Automated medication management system and method for use
US20080021834A1 (en) * 2006-07-19 2008-01-24 Mdatalink, Llc Medical Data Encryption For Communication Over A Vulnerable System
US8948793B1 (en) * 2010-02-12 2015-02-03 Bruce R. Birkhold System and method for automated remote messaging to wireless mobile devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CATHERINE QUANTIN ET AL: "Medical record search engines, using pseudonymised patient identity: An alternative to centralised medical records", INTERNATIONAL JOURNAL OF MEDICAL INFORMATICS, ELSEVIER SCIENTIFIC PUBLISHERS, SHANNON, IR, 1 January 2010 (2010-01-01), pages 1 - 6, XP007915698, ISSN: 1386-5056, DOI: 10.1016/J.IJMEDINF.2010.10.003 *

Also Published As

Publication number Publication date
FR3045185B1 (fr) 2018-02-09

Similar Documents

Publication Publication Date Title
EP2415294B1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
US20180176157A1 (en) Conveying instant messages via http
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
WO2018130796A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
EP3560163A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
WO2013178909A1 (fr) Procédé et entité de traitement d'un message
FR3045185A1 (fr) Procede d'envoi de message, en particulier de messages sms dans un contexte medical
EP3682661A1 (fr) Accès à un service avec authentification basée sur un terminal mobile
WO2011051268A1 (fr) Procédé d'établissement d'une session applicative, dispositif et notification correspondante
EP3021273A1 (fr) Procédé de sécurisation d'une transaction entre un terminal mobile et un serveur d'un fournisseur de service par l'intermédiaire d'une plateforme
WO2019239029A1 (fr) Procédé de traitement de messages par un dispositif d'un réseau de voix sur ip
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP3714588A1 (fr) Procede de gestion a distance d'un dispositif connecte a une passerelle residentielle
WO2018234662A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
WO2023083770A1 (fr) Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés
US20240104525A1 (en) Methods and systems for pre-verification of cryptocurrency transfers using test transactions
WO2009125145A1 (fr) Procede d'obtention de donnees relatives a la configuration d'un equipement terminal et serveur
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
WO2021234250A1 (fr) Procede de notification d'un terminal mobile
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
WO2021105617A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
EP3840312A1 (fr) Transfert de données vers des dispositifs de stockage
EP3804253A1 (fr) Procédé de mise à jour d'une base de données d'un réseau de voix sur ip
US10623360B2 (en) Automatic configuration of email client
FR3074394A1 (fr) Acces a un service avec authentification basee sur un terminal mobile

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20170616

PLFP Fee payment

Year of fee payment: 3

ST Notification of lapse

Effective date: 20190906