FR2970613A1

FR2970613A1 - Procede de fourniture a un observateur de donnees relatives a au moins un utilisateur d'un operateur de telecommunication ou de services internet dans un reseau

Info

Publication number: FR2970613A1
Application number: FR1100123A
Authority: FR
Inventors: Arnaud Ansiaux
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2011-01-13
Filing date: 2011-01-13
Publication date: 2012-07-20
Anticipated expiration: 2031-01-13
Also published as: FR2970613B1; WO2012095522A1; EP2664127A1; US20130297740A1

Abstract

L'invention concerne un procédé de fourniture à un observateur de données relatives à au moins un utilisateur d'un opérateur de télécommunication ou de services Internet dans un réseau (1), ledit procédé prévoyant que ledit observateur envoie une requête (9, 13) audit opérateur afin d'obtenir des données en réponse à ladite requête, ledit procédé prévoyant en outre de : - analyser les données demandées par ledit observateur en réponse à ladite requête ; - construire automatiquement une nouvelle requête (22, 23) à partir de ladite analyse ; - utiliser ladite nouvelle requête afin que ledit opérateur transmette audit observateur de nouvelles données en réponse à ladite nouvelle requête.

Description

1 L'invention concerne un procédé de fourniture à un observateur de données relatives à au moins un utilisateur d'un opérateur de télécommunication ou de services Internet dans un réseau, ainsi qu'une architecture d'un tel opérateur comprenant des moyens techniques pour mettre en ceuvre un tel procédé.

Le monde des communications multimédia se transforme complètement depuis plusieurs années, et la cadence semble aller en s'accélérant. Par conséquent, certains risques et menaces comme la cybercriminalité, la corruption, le trafic de drogues et le terrorisme, à défaut d'être nouveaux, sont plus que jamais d'actualité.

De ce fait, des obligations légales, comme par exemple les deux fonctions d'interception légale (LI, pour Lawful Interception) et de rétention de données (DR, pour Data Retention), apparaissent d'autant plus nécessaires pour assurer activement une sécurité globale aux nations et à leurs citoyens. En particulier, l'interception légale permet à une autorité de surveiller en temps réel les communications entre des utilisateurs donnés dans un réseau et la rétention de données permet le stockage de données techniques relatives à des utilisateurs dans un tel réseau en vue de leur utilisation a posteriori par une autorité.

Par exemple, en France, le nombre d'interceptions légales a presque quadruplé entre 2001 et 2008, selon les chiffres publiés dans l'article disponible sur Internet à l'adresse httpi/www.leidd.fr/Societe/Actualite/Tout-le-monde-surecoute-76854. Toutefois, ces chiffres restent en deçà du nombre d'interceptions légales effectuées en Italie et surtout du nombre d'interceptions légales effectuées aux Etats Unis.

Les interceptions légales et la rétention de données sont des fonctions qui doivent obligatoirement être fournies par les opérateurs et par les fournisseurs d'accès à Internet (ISP, pour Internet Service Provider). En particulier, les opérateurs de télécommunication et de services Internet ont l'obligation de stocker des données techniques sur leurs clients, par exemple si lesdits clients utilisent un téléphone fixe et/ou un téléphone portable et/ou si lesdits clients 2 bénéficient d'une connexion à Internet. Selon les pays, la législation peut varier, notamment en ce qui concerne la durée de stockage, qui peut aller de six mois à trois ans. Par exemple, la loi en France impose un stockage des données pendant un an. D'un point de vue technique, ces deux fonctions ont leurs propres contraintes. En particulier, les contraintes techniques des interceptions légales découlent principalement de leur fonctionnement en temps réel.

10 De même, les contraintes techniques de la rétention de données découlent surtout de la grande quantité de données à stocker ; par conséquent, la durée de réponse aux requêtes peut devenir très importante et constituer un frein à l'efficacité opérationnelle. En outre, le traitement de données de types hétérogènes provenant de différents types de réseaux de communication 15 constitue une difficulté globale.

Actuellement, chaque client d'un opérateur de communications multimédia génère environ 14 Kilooctets (Ko) de données de signalisation pour la communication vocale et 100 Ko de données de signalisation pour la 20 communication de données, cette tendance étant en constante évolution. Ainsi, chaque opérateur doit, pour dix millions de clients, stocker environ 400 Téraoctets (To) de données pendant un an, ce qui équivaut à stocker 80000 DVD et représente cent milliards de registres dans la base de données dudit opérateur. En outre, les opérateurs de communications multimédia actuels ont 25 pour la plupart largement dépassé les dix millions de clients, comme c'est notamment le cas pour France Telecom®, d'après l'article disponible à l'adresse httpi/www.journaldunet. com/ebusiness/breve/france/47671/francetelecom-souhaite-atteindre-300-mill ions-de-clients.shtml.

30 Par conséquent, il y a une très grande quantité de données à stocker, et c'est un grand défi pour les opérateurs de télécommunication et de services Internet de garantir la disponibilité, l'intégrité et la confidentialité desdites données.5 3 En outre, toutes ces données et informations stockées doivent pouvoir servir aux autorités pour assurer la sécurité de l'Etat, et doivent pour cela être traitées et analysées. De plus, sachant que la contrainte de temps est l'un des aspects les plus importants à gérer lors des enquêtes judiciaires et des activités de renseignement, il est essentiel de minimiser les temps de réponse aux requêtes venant de ces autorités.

Pour gérer correctement la diminution du temps de réponse aux requêtes des autorités, les architectures d'interceptions légales et de rétention de données doivent obligatoirement être bâties sur des supports techniques informatiques (matériels et logiciels) qui sont suffisamment puissants en termes de capacité de traitement mais aussi en termes de capacité de stockage. En outre, une bonne organisation interne des services des fonctions d'obligation légale doit être aussi assurée et maintenue en permanence.

Sans les deux conditions précitées, aucune coordination efficace n'est possible entre les autorités et les opérateurs de télécommunication et de services Internet. Cependant, ces deux conditions ne suffisent pas toujours à elles seules, en ce que le volume de données que les autorités doivent traiter ne cesse d'augmenter. De plus, les requêtes des autorités sont complexes et les données à traiter sont hétérogènes.

En particulier, les autorités ont de plus en plus besoin de moyens aptes à traiter des données de types structurés et/ou non structurés, par exemple des données informatiques, des données vidéos, des données images ou des données vocales. De plus, les capacités de stockage des opérateurs de télécommunication et de services Internet doivent non seulement être suffisamment importantes, mais doivent aussi être adaptées à différents contenus multimédia pour faciliter le travail de corrélation et de fusion de l'information. En effet, les opérateurs de télécommunication et de services Internet projettent d'orienter leurs services vers le multimédia, comme par exemple la visiophonie et/ou les conversations par cybercaméras (pour l'anglais webcam) interposées. 4 De ce fait, la plupart des bases de données actuelles ont atteint leurs limites dans les domaines de l'interception légale et de la rétention de données, et plus généralement dans le domaine de la gestion de données. En outre, de nouvelles technologies de stockage apparaissent sur le marché, comme par exemple les nouvelles solutions de référence telles que GreenplumO, NetezzaO, XedixO ou TerradataO, qui sont utilisées par Alcatel-LucentO dans ses solutions globales.

Même si ces nouvelles technologies présentent des capacités efficaces et permettent de pallier à de nombreuses contraintes, il est encore possible d'augmenter de façon significative l'efficacité globale des procédés d'interceptions légales et de rétention de données en tenant compte, et ce directement dans le système, du travail et des compétences des autorités afin de pouvoir anticiper les actions récurrentes menées par lesdites autorités.

Un tel aspect nécessite une interaction plus forte et des relations plus profondes entre les architectures respectives d'interceptions légales et de rétention de données que ce qui est actuellement observable. En effet, les architectures standards, notamment celles conformes à la norme ETSI (pour European Telecommunications Standards Institute), sont relativement compartimentées et leurs fonctions de médiation respectives agissent de manière totalement indépendante, même si par exemple leurs sujets sont traités dans le même groupe au niveau de l'ETSI.

L'invention vise à perfectionner l'art antérieur en proposant un procédé permettant d'améliorer de façon significative la vitesse et l'efficacité des échanges entre les opérateurs de télécommunication, de services Internet et les autorités en facilitant la corrélation et la fusion des informations obtenues par lesdites autorités, notamment grâce à une meilleure interaction entre les fonctions d'interceptions légales et de rétention de données et à une anticipation des demandes desdites autorités.

A cet effet, selon un premier aspect, l'invention propose un procédé de fourniture à un observateur de données relatives à au moins un utilisateur d'un opérateur de télécommunication ou de services Internet dans un réseau, ledit procédé prévoyant que ledit observateur envoie une requête audit opérateur 5 afin d'obtenir des données en réponse à ladite requête, ledit procédé prévoyant en outre de : analyser les données demandées par ledit observateur en réponse à ladite requête ; construire automatiquement une nouvelle requête à partir de ladite analyse ; utiliser ladite nouvelle requête afin que ledit opérateur transmette audit observateur de nouvelles données en réponse à ladite nouvelle requête.

Selon un deuxième aspect, l'invention propose une architecture d'un opérateur de télécommunication ou de services Internet dans un réseau, ladite architecture comprenant au moins une base de données dans laquelle sont stockées des données relatives à au moins un utilisateur dudit opérateur, ladite architecture comprenant des moyens pour recevoir une requête envoyée par un observateur audit opérateur afin d'obtenir des données en réponse à ladite requête, ladite architecture comprenant en outre : au moins un module d'analyse des données demandées par l'observateur en réponse à ladite requête ; au moins un module de construction automatique d'une nouvelle requête à partir de l'analyse effectuée par ledit module d'analyse ; au moins un module d'utilisation de ladite nouvelle requête afin que ledit opérateur transmette audit observateur de nouvelles données en réponse à ladite nouvelle requête ; au moins un module d'administration comprenant des moyens pour faire interagir entre eux les modules d'analyse, de construction et d'utilisation afin de transmettre audit observateur de nouvelles données en réponse à ladite nouvelle requête. 6 D'autres particularités et avantages de l'invention apparaîtront dans la description qui suit, faite en référence aux figures annexées dans lesquelles : la figure 1 représente de façon schématique une architecture d'un opérateur de télécommunication intégrant deux applications aptes à mettre en oeuvre un procédé de fourniture selon l'invention ; la figure 2 représente de façon schématique une application de la figure 1.

En relation avec ces figures, on décrit ci-dessous une architecture d'un opérateur de télécommunication dans un réseau 1. L'opérateur peut être en particulier un opérateur de communications fixe, mobile, voix et/ou data, par exemple un opérateur de télécommunications comme Orange® ou Bouygues Télécom®, ou un opérateur de téléphonie sur Internet (VoIP, pour Voice over Internet Protocol) et/ou de visiophonie et/ou un fournisseur de services Internet.

L'architecture comprend des moyens pour mettre en oeuvre un procédé de fourniture à un observateur de données relatives à au moins un utilisateur de l'opérateur dans le réseau 1. L'observateur, non représenté sur les figures, est une autorité légale (LEA, pour Law Enforcement Agency), par exemple la Police Nationale ou la Gendarmerie Nationale, ou encore un ministère, comme le Ministère de la Défense ou le Ministère de la Justice.

L'architecture comprend au moins une base de données dans laquelle sont stockées des données relatives à au moins un utilisateur de l'opérateur.

En relation avec la figure 1, l'architecture intègre une sous-architecture 2 de rétention de données comprenant au moins une base 3 dans laquelle sont stockées des données techniques relatives aux utilisateurs clients de l'opérateur, par exemple des données relatives aux identifiants des utilisateurs de l'opérateur, au type de communications multimédia établies par les utilisateurs, à l'historique desdites communications ou aux identifiants des contacts desdits utilisateurs participant auxdites communications. 7 En particulier, les identifiants des utilisateurs et/ou de leurs contacts peuvent être des numéros de téléphone, des adresses IP (pour Internet Protocol), des adresses de blogues ou des adresses de sites de discussion en temps réel (pour l'anglais chat). En outre, pour des utilisateurs de l'opérateur, l'identifiant peut également être le nom desdits utilisateurs.

Ces données sont envoyées à la base de données 3 par un système d'information 4 (SI, pour System Information) de l'opérateur, afin d'être regroupées et stockées dans ladite base de données.

En outre, l'architecture intègre une sous-architecture 5 d'interceptions légales comprenant au moins une plateforme 6 pour l'opérateur de télécommunication, ladite plateforme comprenant au moins une interface 7 pour un réseau de l'opérateur, par exemple un réseau de téléphonie fixe, de téléphonie mobile, ou encore un réseau de fourniture d'Internet, ladite interface donnant accès à des données relatives aux communications en temps réel entre des utilisateurs dans le réseau 1, au moins un desdits utilisateurs étant un utilisateur de l'opérateur considéré.

En particulier, les données accessibles par l'intermédiaire d'une interface 7 peuvent être relatives aux identifiants des utilisateurs de l'opérateur et/ou aux identifiants des contacts desdits utilisateurs participant à une communication en temps réel avec lesdits utilisateurs, ou au type et/ou au contenu desdites communications en temps réel.

En outre, de façon préférentielle, les données stockées dans la base de données 3 et les données accessibles par l'intermédiaire d'une interface 7 comprennent au moins un numéro de téléphone d'un utilisateur et/ou au moins un numéro de téléphone d'un contact dudit utilisateur dans le réseau 1, l'observateur envoyant une requête pour obtenir au moins un desdits numéros en tant que donnée, afin de mettre en place un procédé d'interception légale à partir dudit numéro et/ou d'obtenir des données techniques sur ledit numéro. 8 Le procédé prévoit que l'observateur envoie une requête à l'opérateur afin d'obtenir des données en réponse à ladite requête. L'architecture comprend donc des moyens pour recevoir une requête envoyée via le réseau 1 par l'observateur à l'opérateur afin d'obtenir des données en réponse à ladite requête ou de poser une interception en temps réel.

Sur la figure 1, la sous-architecture 2 de rétention de données comprend au moins un module 8 de médiation qui comprend des moyens pour recevoir une requête 9 envoyée par l'observateur afin d'obtenir des données stockées dans la base de données 3, lesdites données étant relatives à un utilisateur de l'opérateur.

Le module 8 peut être en particulier un module d'interface multimédia haute définition (HDMI, pour High Definition Multimedia Interface) et la requête 9 peut être envoyée par l'observateur audit module par l'intermédiaire d'une interface de transmission administrative HIA (HI, pour Handover Interface).

En outre, la sous-architecture 2 comprend un module 10 d'interface apte à faire interagir le module 8 avec la base de données 3, afin d'extraire de ladite base les données requises et de transmettre à l'observateur une notification 11 en réponse à la requête 9, ladite notification comprenant lesdites données.

Pour ce faire, le module 10 peut envoyer des instructions au module 8 par l'intermédiaire d'une interface de transmission administrative HIA, la notification 11 pouvant alors être transmise à l'observateur par l'intermédiaire d'une interface de transmission de données HIB.

De même, la sous-architecture 5 d'interceptions légales comprend au moins un module 12 de médiation qui comprend des moyens pour recevoir une requête 13 envoyée par un observateur afin d'obtenir des données par l'intermédiaire d'une interface 7, lesdites données étant relatives à un utilisateur de l'opérateur. 9 En particulier, l'observateur peut envoyer une requête 13 au module 12 par l'intermédiaire d'une interface de transmission H11 de gestion des fonctions d'interceptions légales.

En outre, la sous-architecture 5 comprend un module 14 d'interface apte à faire interagir le module 12 avec la plateforme 6, afin d'obtenir par l'intermédiaire d'au moins une interface 7 les données requises et de transmettre à l'observateur une notification 15 en réponse à la requête 13, ladite notification comprenant lesdites données. En particulier, les données accessibles par l'intermédiaire d'une interface 7 sont transmises en temps réel à un observateur dans des notifications 15 sans qu'il y ait de véritable stockage desdites données au sein de la sous-architecture 5 d'interceptions légales.

Le module 14 peut envoyer des instructions au module 12 par l'intermédiaire d'une interface de transmission H11 de gestion des fonctions d'interceptions légales, la notification 15 pouvant alors être transmise à l'observateur par l'intermédiaire d'une interface de transmission H12 si elle comprend des données techniques relatives à une communication en temps réel de l'utilisateur dans le réseau 1, ou par l'intermédiaire d'une interface de transmission H13 si elle comprend des données relatives au contenu d'une telle communication.

Le procédé prévoit d'analyser les données demandées par l'observateur en réponse à la requête 9, 13, notamment avant l'obtention desdites données par ledit observateur. Pour ce faire, l'architecture comprend au moins un module 16 d'analyse des données demandées par l'observateur en réponse à la requête 9, 13.

En particulier, les données demandées peuvent être analysées au moyen de règles de filtrage. Ces règles de filtrage peuvent être notamment générées à partir d'une analyse d'un historique des précédentes requêtes 9, 13 envoyées par l'observateur et des données obtenues en réponse auxdites précédentes 10 requêtes. Ces règles de filtrage peuvent également être construites par un administrateur de l'architecture avec des recommandations de l'observateur.

Pour ce faire, l'architecture comprend au moins un module 17 de génération de règles de filtrage comprenant des moyens d'analyse d'un historique des précédentes requêtes 9, 13 envoyées par l'observateur et des données obtenues en réponse auxdites précédentes requêtes, ainsi que des moyens de génération de règles de filtrage à partir de ladite analyse. En outre, le module 16 est apte à analyser les données demandées par l'observateur au moyen des règles de filtrage générées par le module 17.

En particulier, les règles de filtrage dépendent de la nature de l'activité de l'observateur et de ses méthodes de travail et peuvent notamment se rapporter aux requêtes que l'observateur a l'habitude d'envoyer à l'opérateur après avoir reçu un certain type de donnée.

Par exemple, si l'observateur a l'habitude, après avoir reçu une donnée comprenant un numéro de téléphone d'un utilisateur et/ou un numéro de téléphone d'un contact dudit utilisateur, d'envoyer à la sous-architecture 2 une requête 9 afin d'obtenir les numéros de téléphone des sept contacts de l'utilisateur ayant appelé le plus souvent ledit utilisateur ou ayant été le plus joints par ledit utilisateur, les moyens d'analyse du module 17 peuvent être aptes à identifier cette habitude et les moyens de génération dudit module peuvent être aptes à générer une règle de filtrage se rapportant à ladite habitude identifiée.

Une fois que les données demandées par l'observateur ont été analysées par le module 16, le procédé prévoit de construire automatiquement une nouvelle requête à partir de ladite analyse. Pour ce faire, l'architecture comprend au moins un module 18 de construction automatique d'une nouvelle requête à partir de l'analyse effectuée et transmise par le module 16. La nouvelle requête construite correspond en particulier à la requête qu'aurait émise l'observateur Il après avoir obtenu et analysé les données qu'il a demandées et anticipe donc le comportement dudit observateur.

Le procédé prévoit d'utiliser la nouvelle requête construite afin que l'opérateur transmette à l'observateur de nouvelles données en réponse à ladite nouvelle requête. Pour ce faire, l'architecture comprend au moins un module 19 d'utilisation de la nouvelle et au moins un module 20 d'administration comprenant des moyens pour faire interagir entre eux les modules d'analyse 16, de construction 18 et d'utilisation 19 afin de transmettre à l'observateur de nouvelles données en réponse à ladite nouvelle requête.

En particulier, le module 20 d'administration peut comprendre des moyens pour permettre à l'observateur de générer manuellement des règles de filtrage et des moyens pour envoyer lesdites règles générées au module 17 de génération.

De façon préférentielle, les nouvelles données obtenues en réponse aux nouvelles requêtes construites sont stockées localement, par exemple dans une base (non représentée) de la sous-architecture 2, 5 correspondante, avant d'être transmises à l'observateur, afin d'éviter toute perte de données entre l'opérateur et l'observateur.

Le module 19 d'utilisation peut comprendre des moyens pour sécuriser l'utilisation de la nouvelle requête, notamment en assurant l'intégrité et la confidentialité de ladite utilisation au moyen d'un code de cryptage et/ou de certificats de confidentialité.

En relation avec la figure 2, les modules d'analyse 16, de génération de règles 17, de construction 18, d'utilisation 19 et d'administration 20 sont regroupés dans une application 21, ladite application étant implantée dans l'architecture d'un opérateur de télécommunication ou de services Internet pour mettre en oeuvre le procédé, notamment dans au moins l'une des sous-architectures 2, 5. 12 En particulier, les sous-architectures de rétention de données 2 et d'interceptions légales 5 comprennent respectivement une application 21, chacune desdites applications comprenant les modules décrits ci-dessus, notamment un module 19 d'utilisation des nouvelles requêtes.

Les résultats des nouvelles requêtes construites peuvent être indexés dans une base de données. En particulier, le module 18 de la sous-architecture 2 peut comprendre des moyens pour indexer dans une base de données de rétention de données les nouvelles requêtes qu'il a construites, par exemple en créant des liens logiques pour lesdites nouvelles requêtes, le module 19 étant apte à faire interagir le module 8 de médiation avec cette base de données en utilisant lesdits liens logiques afin que le module 8 extraie de la base 3 de nouvelles données en réponse auxdites nouvelles requêtes.

Par ailleurs, le module 18 de la sous-architecture 5 peut comprendre des moyens pour préparer, à partir des nouvelles requêtes construites, des tables de routage, une configuration de réseau privé virtuel (VPN, pour Virtual Private Network), ou d'autres techniques, afin que le module 12 de médiation interagisse avec au moins une interface 7 de la plateforme 6 pour obtenir de nouvelles données en réponse auxdites nouvelles requêtes.

Le procédé peut prévoir que, si la requête envoyée par l'observateur est une requête 9 de rétention de données - respectivement une requête 13 d'interception légale -, la nouvelle requête construite est également une requête de rétention de données - respectivement une requête d'interception légale.

Ainsi, si la sous-architecture 2, 5 destinataire de la requête 9, 13 envoyée par l'observateur est également destinataire de la nouvelle requête construite, le module 19 de l'application 21 implantée dans ladite sous-architecture transmet localement ladite nouvelle requête au module 8, 12 de médiation de ladite sous-architecture. 13 Par exemple, si l'observateur a envoyé précédemment une requête 9 à la sous-architecture 2 pour obtenir le nom d'un utilisateur et si ledit observateur a ensuite l'habitude d'envoyer une requête pour obtenir l'historique des communications dudit utilisateur, le module 16 de l'application 21 implantée dans ladite sous-architecture peut, en collaboration avec le module 17 de ladite application, appliquer les règles de filtrage correspondant à cette habitude pour que le module 18 construise une nouvelle requête et que le module 19 transmette localement ladite nouvelle requête au module 8.

De même, si l'observateur a envoyé précédemment une requête 13 à la sous-architecture 5 pour surveiller une communication en temps réel d'un utilisateur dans le réseau 1 et si ledit observateur a ensuite l'habitude d'envoyer une requête pour obtenir le numéro de téléphone du contact dudit utilisateur participant à ladite communication, le module 16 de l'application 21 implantée dans ladite sous-architecture peut, en collaboration avec le module 17 de ladite application, appliquer les règles de filtrage correspondant à cette habitude pour que le module 18 construise une nouvelle requête et que le module 19 transmette localement ladite nouvelle requête au module 12.

Le procédé peut également prévoir que, si la requête envoyée par l'observateur est une requête 9 de rétention de données - respectivement une requête 13 d'interception légale -, la nouvelle requête construite est une requête d'interception légale - respectivement une requête de rétention de données.

Ainsi, si la sous-architecture 2, 5 destinataire de la requête 9, 13 envoyée par l'observateur n'est pas destinataire de la nouvelle requête construite, le module 19 de l'application 21 intégrée dans ladite sous-architecture transmet de façon sécurisée ladite nouvelle requête au module 8, 12 de médiation de l'autre sous-architecture 2, 5.

Par exemple, si l'observateur a envoyé précédemment à la sous-architecture 2 une requête 9 pour obtenir les numéros de téléphone des sept contacts ayant le plus appelé un utilisateur de l'opérateur et si ledit observateur a ensuite 14 l'habitude de demander une interception légale pour ces sept contacts, le module 16 de l'application 21 implantée dans ladite sous-architecture peut, en collaboration avec le module 17 de ladite application, appliquer les règles de filtrage correspondant à cette habitude afin que le module 18 construise automatiquement une nouvelle requête 22 d'interception légale.

La nouvelle requête 22 est alors transmise par le module 19 de l'application 21 implantée dans la sous-architecture 2 de rétention de données au module 12 de médiation de l'architecture 5 d'interceptions légales, afin que le module 12 interagisse avec la plateforme 6 pour mettre en oeuvre l'interception légale pour les sept contacts.

De même, si l'observateur a envoyé précédemment une requête 13 à la sous-architecture 5 pour surveiller les communications en temps réel d'un utilisateur de l'opérateur dans le réseau 1 et si ledit observateur a ensuite l'habitude de demander le numéro de téléphone du contact avec lequel ledit utilisateur a une communication en temps réel, le module 16 de l'application 21 implantée dans ladite sous-architecture peut, en collaboration avec le module 17 de ladite application, appliquer les règles de filtrage correspondant à cette habitude afin que le module 18 construise une nouvelle requête 23 de rétention de données.

La nouvelle requête 23 est alors transmise par le module 19 de l'application 21 implantée dans la sous-architecture 5 d'interceptions légales au module 8 de médiation de l'architecture 2 de rétention de données, afin que le module 8 extraie de la base 3 le numéro de téléphone dudit contact.

Ainsi, une interaction entre les sous-architectures de rétention de données 2 et d'interceptions légales 5 est établie et permet d'améliorer de façon significative l'efficacité et la rapidité de ces deux sous-architectures 2, 5 en construisant automatiquement de nouvelles requêtes anticipant les demandes de l'observateur, faisant desdites sous-architectures de véritables outils d'investigation et d'aide à la prise de décision pour les autorités.

Claims

REVENDICATIONS1. Procédé de fourniture à un observateur de données relatives à au moins un utilisateur d'un opérateur de télécommunication ou de services Internet dans un réseau (1), ledit procédé prévoyant que ledit observateur envoie une requête (9, 13) audit opérateur afin d'obtenir des données en réponse à ladite requête, ledit procédé prévoyant en outre de : - analyser les données demandées par ledit observateur en réponse à ladite requête ; construire automatiquement une nouvelle requête (22, 23) à partir de ladite analyse ; utiliser ladite nouvelle requête afin que ledit opérateur transmette audit observateur de nouvelles données en réponse à ladite nouvelle requête.
2. Procédé de fourniture selon la revendication 1, caractérisé en ce que les données demandées sont analysées au moyen de règles de filtrage.
3. Procédé de fourniture selon la revendication 2, caractérisé en ce que les règles de filtrage sont générées à partir d'une analyse d'un historique des précédentes requêtes (9, 13) envoyées par l'observateur et des données obtenues en réponse auxdites précédentes requêtes.
4. Procédé de fourniture selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les données demandées par l'observateur comprennent au moins un numéro de téléphone de l'utilisateur et/ou au moins un numéro de téléphone d'un contact dudit utilisateur dans le réseau (1).
5. Procédé de fourniture selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les nouvelles requêtes (22, 23) construites sont indexées dans une base de données.
6. Procédé de fourniture selon l'une quelconque des revendications 1 à 5, caractérisé en ce que les nouvelles données obtenues en réponse aux 16 nouvelles requêtes (22, 23) construites sont stockées localement avant d'être transmises à l'observateur.
7. Procédé de fourniture selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la requête envoyée par l'observateur est une requête (9) de rétention de données - respectivement une requête (13) d'interception légale -, la nouvelle requête construite étant une requête (22) d'interception légale - respectivement une requête (23) de rétention de données.
8. Procédé de fourniture selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la requête envoyée par l'observateur est une requête (9) de rétention de données - respectivement une requête (13) d'interception légale -, la nouvelle requête construite étant une requête de rétention de données - respectivement une requête d'interception légale.
9. Architecture d'un opérateur de télécommunication ou de services Internet dans un réseau (1), ladite architecture comprenant au moins une base de données (3) dans laquelle sont stockées des données relatives à au moins un utilisateur dudit opérateur, ladite architecture comprenant des moyens pour recevoir une requête (9, 13) envoyée par un observateur audit opérateur afin d'obtenir des données en réponse à ladite requête, ladite architecture comprenant en outre : au moins un module (16) d'analyse des données demandées par l'observateur en réponse à ladite requête ; au moins un module (18) de construction automatique d'une nouvelle requête (22, 23) à partir de l'analyse effectuée par ledit module d'analyse ; au moins un module (19) d'utilisation de ladite nouvelle requête afin que ledit opérateur transmette audit observateur de nouvelles données en 30 réponse à ladite nouvelle requête ; au moins un module (20) d'administration comprenant des moyens pour faire interagir entre eux les modules d'analyse (16), de construction (18) 17 et d'utilisation (19) afin de transmettre audit observateur de nouvelles données en réponse à ladite nouvelle requête.
10. Architecture selon la revendication 9, caractérisée en ce qu'elle comprend en outre au moins un module (17) de génération de règles de filtrage, le module d'analyse (16) étant apte à analyser les données au moyen desdites règles, ledit module de génération comprenant des moyens d'analyse d'un historique des précédentes requêtes envoyées par l'observateur et des données obtenues en réponse auxdites précédentes requêtes, ainsi que des moyens de génération de règles à partir de ladite analyse.
11. Architecture selon la revendication 9 ou 10, caractérisée en ce que le module (20) d'administration comprend des moyens pour permettre à un observateur de générer manuellement des règles de filtrage et des moyens pour envoyer lesdites règles générées au module de génération (17).
12. Architecture selon l'une quelconque des revendications 9 à 11, caractérisée en ce que le module d'utilisation (19) comprend des moyens pour sécuriser l'utilisation de la nouvelle requête (22, 23).
13. Architecture selon l'une quelconque des revendications 9 à 12, caractérisée en ce qu'elle comprend une sous-architecture (2) de rétention de données et une sous architecture (5) d'interceptions légales, lesdites sous-architectures comprenant au moins une base de données (3) dans laquelle sont stockées des données relatives à au moins un utilisateur dudit opérateur et/ou un module (8, 12) comprenant des moyens pour recevoir une requête (9, 13) envoyée par un observateur, chacune desdites sous-architectures comprenant en outre une application (21) comprenant un module (16) d'analyse, un module (18) de construction, un module (19) d'utilisation et un module (20) d'administration.