EP2664127A1 - Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete - Google Patents

Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete

Info

Publication number
EP2664127A1
EP2664127A1 EP12701328.2A EP12701328A EP2664127A1 EP 2664127 A1 EP2664127 A1 EP 2664127A1 EP 12701328 A EP12701328 A EP 12701328A EP 2664127 A1 EP2664127 A1 EP 2664127A1
Authority
EP
European Patent Office
Prior art keywords
request
data
observer
module
new
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
EP12701328.2A
Other languages
German (de)
English (en)
Inventor
Arnaud Ansiaux
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of EP2664127A1 publication Critical patent/EP2664127A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/30—Aspects of automatic or semi-automatic exchanges related to audio recordings in general
    • H04M2203/301—Management of recordings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42136—Administration or customisation of services
    • H04M3/42144—Administration or customisation of services by service provider
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the invention relates to a method of providing an observer with data relating to at least one user of a telecommunication operator or of Internet services in a network, and an architecture of such an operator comprising technical means for implementing such a process.
  • legal interception allows an authority to monitor in real time the communications between specific users in a network and the data retention allows the storage of technical data relating to users in such a network for their use in a network. posteriori by an authority.
  • the technical constraints of data retention arise mainly from the large amount of data to be stored; therefore, the query response time can become very important and can be a hindrance to operational efficiency.
  • the processing of heterogeneous type data from different types of communication networks is a global difficulty.
  • the object of the invention is to improve the prior art by proposing a method making it possible to significantly improve the speed and efficiency of exchanges between telecommunication operators, Internet service providers and the authorities by facilitating the correlation and the merging of information. obtained by those authorities, in particular through better interaction between the functions of legal interception and data retention and anticipation of requests from those authorities.
  • the invention proposes a method of providing an observer with data relating to at least one user of a telecommunication operator or of Internet services in a network, said method providing that said observer sends a querying said operator to obtain data in response to said request, said method further comprising:
  • the invention proposes an architecture of a telecommunication operator or of Internet services in a network, said architecture comprising at least one database in which data relating to at least one user of said operator is stored.
  • architecture comprising means for receiving a request sent by an observer to said operator to obtain data in response to said request, said architecture further comprising:
  • At least one data analysis module requested by the observer in response to said request
  • At least one automatic construction module for a new request based on the analysis performed by said analysis module; at least one module for using said new request so that said operator transmits to said observer new data in response to said new request;
  • At least one administration module comprising means for making the analysis, construction and utilization modules interact with one another so as to transmit to said observer new data in response to said new request.
  • FIG. 1 schematically represents an architecture of a telecommunication operator integrating two applications capable of implementing a supply method according to the invention
  • Figure 2 schematically shows an application of Figure 1.
  • the operator may be in particular a fixed, mobile, voice and / or data communications operator, for example a telecommunications operator such as Orange® or Bouygues Telecom®, or an Internet telephony operator (VoIP). ) and / or videophone and / or an Internet Service Provider.
  • a telecommunications operator such as Orange® or Bouygues Telecom®
  • VoIP Internet telephony operator
  • videophone and / or an Internet Service Provider.
  • the architecture comprises means for implementing a method of providing an observer with data relating to at least one user of the operator in the network 1.
  • the observer is a legal authority (LEA, for Law Enforcement Agency), for example the National Police or the Gendarmerie Nationale, or a ministry, such as the Ministry of Defense or the Ministry of Justice .
  • the architecture includes at least one database in which data relating to at least one user of the operator is stored.
  • the architecture integrates a data retention sub-architecture 2 comprising at least a base 3 in which technical data relating to the operator's client users are stored, for example data relating to the identifiers of the data carriers. users of the operator, the type of multimedia communications established by the users, the history of said communications or the contact identifiers of said users participating in said communications.
  • the identifiers of the users and / or their contacts may be telephone numbers, Internet protocol (IP) addresses, blog addresses or real-time chat room addresses (for English chat).
  • IP Internet protocol
  • the identifier can also be the name of said users.
  • This data is sent to the database 3 by an information system 4 (SI, for System Information) of the operator, in order to be grouped and stored in said database.
  • SI System Information
  • the architecture integrates a legal interception sub-architecture 5 comprising at least one platform 6 for the telecommunication operator, said platform comprising at least one interface 7 for an operator network, for example a network of operators. fixed telephony, mobile telephony, or an Internet supply network, said interface giving access to data relating to real-time communications between users in the network 1, at least one of said users being a user of the operator considered.
  • a legal interception sub-architecture 5 comprising at least one platform 6 for the telecommunication operator, said platform comprising at least one interface 7 for an operator network, for example a network of operators. fixed telephony, mobile telephony, or an Internet supply network, said interface giving access to data relating to real-time communications between users in the network 1, at least one of said users being a user of the operator considered.
  • the data accessible via an interface 7 can be relative to the identifiers of the operator's users and / or to the identifiers of the contacts of said users participating in a real-time communication with said users, or to the type and or the content of said communications in real time.
  • the data stored in the database 3 and the data accessible via an interface 7 comprise at least one telephone number of a user and / or at least one telephone number of a contact of said user in the network 1, the observer sending a request to obtain at least one of said numbers as data, in order to set up a legal intercepting method from said number and / or to obtain technical data on said number.
  • the method provides that the observer sends a request to the operator to obtain data in response to said request.
  • the architecture therefore comprises means for receiving a request sent via the network 1 by the observer to the operator in order to obtain data in response to said request or to make an interception in real time.
  • the data retention sub-architecture 2 comprises at least one mediation module 8 which comprises means for receiving a request 9 sent by the observer in order to obtain data stored in the database 3, said data being relative to a user of the operator.
  • the module 8 may be in particular a high definition multimedia interface module (HDMI, for High Definition Multimedia Interface) and the request 9 may be sent by the observer to said module via an administrative transmission interface HIA ( Hl, for Handover Interface).
  • HDMI high definition multimedia interface module
  • HIA Hl, for Handover Interface
  • the sub-architecture 2 comprises an interface module 10 capable of making the module 8 interact with the database 3, in order to extract from said database the required data and to transmit to the observer a notification 1 1 in response to the request 9, said notification comprising said data.
  • the module 10 can send instructions to the module 8 via an administrative transmission interface HIA, the notification 1 1 can then be transmitted to the observer via an HIB data transmission interface.
  • the legal interception sub-architecture 5 comprises at least one mediation module 12 which comprises means for receiving a request 13 sent by an observer in order to obtain data via an interface 7. data being relative to a user of the operator.
  • the observer can send a request 13 to the module 12 via a transmission interface HI1 for managing the legal interception functions.
  • the sub-architecture 5 comprises an interface module 14 able to make the module 12 interact with the platform 6, in order to obtain, via at least one interface 7, the required data and to transmit to the observer 15 in response to the request 13, said notification comprising said data.
  • the data accessible via an interface 7 are transmitted in real time to an observer in notifications without there being any real storage of said data within the sub-architecture 5 of legal interceptions. .
  • the module 14 can send instructions to the module 12 via a transmission interface HI1 for managing the legal interception functions, the notification 15 can then be transmitted to the observer via a user interface.
  • HI2 transmission if it includes technical data relating to a real-time communication of the user in the network 1, or via a transmission interface HI3 if it includes data relating to the content of such a communication.
  • the method provides for analyzing the data requested by the observer in response to the request 9, 13, in particular before obtaining said data by said observer.
  • the architecture comprises at least one module 16 analysis of the data requested by the observer in response to the request 9, 13.
  • the requested data can be analyzed by means of filtering rules.
  • filtering rules can in particular be generated from an analysis of a history of the previous requests 9, 13 sent by the observer and data obtained in response to said previous requests.
  • These filtering rules can also be built by an architecture administrator with recommendations from the observer.
  • the architecture comprises at least one filter rule generation module 17 comprising means for analyzing a history of the previous requests 9, 13 sent by the observer and data obtained in response to said previous requests, and means for generating filtering rules from said analysis.
  • the module 16 is able to analyze the data requested by the observer by means of the filtering rules generated by the module 17.
  • the filtering rules depend on the nature of the observer's activity and his working methods and can in particular relate to the requests that the observer usually sends to the operator after having received a certain type of data.
  • the analysis means of the module 17 may be able to identify this habit and the means for generating said module may be able to generate a filtering rule relating to said identified habit.
  • the new query constructed corresponds in particular to the request that would have been issued by the user. observer after having obtained and analyzed the data he has requested and thus anticipates the behavior of said observer.
  • the method provides for using the newly constructed query so that the operator transmits new data to the observer in response to said new request.
  • the architecture comprises at least one module 19 for using the new one and at least one administration module 20 comprising means for making the analysis modules 16, the construction module 18 and the use modules interact with one another. 19 to transmit to the observer new data in response to said new request.
  • the administration module 20 may comprise means for enabling the observer to manually generate filtering rules and means for sending said generated rules to the generation module 17.
  • the new data obtained in response to the new queries constructed are stored locally, for example in a base (not shown) of the corresponding sub-architecture 2, 5, before being transmitted to the observer, in order to avoid any loss of data between the operator and the observer.
  • the user module 19 may include means for securing the use of the new request, in particular by ensuring the integrity and confidentiality of said use by means of an encryption code and / or confidentiality certificates.
  • the analysis modules 16, generation of rules 17, construction 18, use 19 and administration 20 are grouped together in an application 21, said application being implemented in the architecture of FIG. a telecommunication or Internet service operator for implementing the method, in particular in at least one of the sub-architectures 2, 5.
  • the data retention 2 and legal interception architectures 5 respectively comprise an application 21, each of said applications comprising the modules described above, in particular a module 19 for using the new requests.
  • the results of new queries built can be indexed in a database.
  • the module 18 of the sub-architecture 2 can comprise means for indexing in a data retention database the new requests that it has constructed, for example by creating logical links for said new requests, the module 19 being able to make the mediation module 8 interact with this database by using said logical links so that the module 8 extracts from the database 3 new data in response to said new requests.
  • the module 18 of the sub-architecture 5 can comprise means for preparing, from the new queries built, routing tables, a virtual private network (VPN) configuration, or other techniques, so that the mediation module 12 interact with at least one interface 7 of the platform 6 to obtain new data in response to said new requests.
  • VPN virtual private network
  • the method may provide that, if the request sent by the observer is a data retention request 9 - respectively a legal interception request 13 -, the new constructed request is also a data retention request - respectively a request for data retention. legal interception.
  • the module 19 of the application 21 implemented in said sub-architecture locally transmits said new request module 8, 12 mediation of said sub-architecture.
  • the module 16 of the application 21 implemented in said sub-architecture can, in collaboration with the module 17 of said application, apply the filtering rules corresponding to this habit for the module 18 to build a new request and the module 19 transmits locally said new request to module 8.
  • the module 16 of the application 21 implanted in said sub-architecture can, in collaboration with the module 17 of said application, apply the filtering rules corresponding to this habit so that the module 18 builds a new request and the module 19 locally transmits said new request to the module 12.
  • the method may also provide that, if the request sent by the observer is a data retention request 9 - respectively a lawful interception request 13 -, the newly constructed request is a lawful interception request - respectively a request for data intercept. data retention.
  • the module 19 of the application 21 integrated in said sub-architecture transmits so secure said new request to the module 8, 12 of mediation of the other sub-architecture 2, 5.
  • the module 16 of the application 21 implanted in said sub-architecture can, in collaboration with the module 17 of said application, apply the filtering rules corresponding to this habit so that the module 18 automatically builds a new request for legal interception.
  • the new request 22 is then transmitted by the module 19 of the application 21 implemented in the data retention sub-architecture 2 to the mediation module 12 of the legal interception architecture 5, so that the module 12 interacts with the platform 6 to implement the legal interception for the seven contacts.
  • the module 16 of the application 21 implanted in said sub-architecture can, in collaboration with the module 17 of said application, apply the filtering rules corresponding to this usual so that the module 18 build a new request 23 for data retention.
  • the new request 23 is then transmitted by the module 19 of the application 21 implanted in the legal interception sub-architecture 5 to the mediation module 8 of the data retention architecture 2, so that the module 8 extracted from the base 3 the telephone number of the said contact.
  • an interaction between the data retention 2 and legal interception architectures 5 is established and makes it possible to significantly improve the efficiency and the speed of these two sub-architectures 2, 5 by automatically building new ones. requests anticipating the requests of the observer, making said sub-architectures real tools of investigation and decision-making aid for the authorities.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

CONSTRUCTION D'UNE REQUETE DE RETENTION DE DONNEES OU D'INTERCEPTION LEGALE A PARTIR D'UNE AUTRE REQUETE
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 œuvre 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 (Ll, pour Lawful Interception) et de rétention de données (DR, pour Data Rétention), 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 http://www.leidd.fr/Societe/Actualite/Tout-le-monde-sur- ecoute-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 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.
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 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 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 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 http://www.iournaldunet.com/ebusiness/breve/france/47671/france- telecom-souhaite-atteindre-300-millions-de-clients. shtml.
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.
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.
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 Greenplum®, Netezza®, Xedix® ou Terradata®, qui sont utilisées par Alcatel-Lucent® 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 Télécommunications 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 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.
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 œuvre 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 œuvre 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.
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.
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 Définition 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 (Hl, 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 1 1 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 1 1 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.
En particulier, l'observateur peut envoyer une requête 13 au module 12 par l'intermédiaire d'une interface de transmission HI1 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 HI1 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 HI2 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 HI3 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 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 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 œuvre le procédé, notamment dans au moins l'une des sous-architectures 2, 5.
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.
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 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 œuvre 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

REVENDICATIONS
1 . 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 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 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) 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.
1 1 . 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 à 1 1 , 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.
EP12701328.2A 2011-01-13 2012-01-13 Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete Withdrawn EP2664127A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1100123A FR2970613B1 (fr) 2011-01-13 2011-01-13 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
PCT/EP2012/050500 WO2012095522A1 (fr) 2011-01-13 2012-01-13 Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete

Publications (1)

Publication Number Publication Date
EP2664127A1 true EP2664127A1 (fr) 2013-11-20

Family

ID=44310860

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12701328.2A Withdrawn EP2664127A1 (fr) 2011-01-13 2012-01-13 Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete

Country Status (4)

Country Link
US (1) US20130297740A1 (fr)
EP (1) EP2664127A1 (fr)
FR (1) FR2970613B1 (fr)
WO (1) WO2012095522A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993256A1 (fr) * 2007-05-18 2008-11-19 Alcatel Lucent Module logiciel pour supporter l'interception légale du protocole Internet

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007042624A1 (fr) * 2005-10-14 2007-04-19 Nokia Corporation Interception legale
CN101390338B (zh) * 2006-02-27 2011-10-05 艾利森电话股份有限公司 合法访问及储存数据切换增强架构
JP5069884B2 (ja) * 2006-09-14 2012-11-07 株式会社日立製作所 最新データ及び履歴データを管理するセンサネットワークシステム
US7983179B2 (en) * 2007-07-27 2011-07-19 At&T Intellectual Property I, L.P. Network monitoring by customer premises equipment
RU2502214C2 (ru) * 2008-09-30 2013-12-20 Панасоник Корпорэйшн Носитель записи, устройство воспроизведения, системная бис, способ воспроизведения, очки и устройство отображения для трехмерных изображений
WO2010048989A1 (fr) * 2008-10-28 2010-05-06 Telefonaktiebolaget Lm Ericsson (Publ) Rétention de données d'utilisateur et de trafic dans une interception légale
FR2940569B1 (fr) * 2008-12-18 2011-08-26 Alcatel Lucent Systeme d'adaptation pour interception legale dans differents reseaux de telecommunications.
US8667385B1 (en) * 2009-12-07 2014-03-04 Google Inc. Method and system for generating and sharing analytics annotations
US9958280B2 (en) * 2011-08-16 2018-05-01 Inrix, Inc. Assessing inter-modal passenger travel options

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1993256A1 (fr) * 2007-05-18 2008-11-19 Alcatel Lucent Module logiciel pour supporter l'interception légale du protocole Internet

Also Published As

Publication number Publication date
FR2970613B1 (fr) 2013-01-18
US20130297740A1 (en) 2013-11-07
FR2970613A1 (fr) 2012-07-20
WO2012095522A1 (fr) 2012-07-19

Similar Documents

Publication Publication Date Title
EP1507384B1 (fr) Procédé de masquage des traitements applicatifs d'une requete d'accès à un serveur et système de masquage correspondant
US8024785B2 (en) Method and data processing system for intercepting communication between a client and a service
US8380872B2 (en) Peer-to-peer telephony recording
EP1921819A1 (fr) Marqueur pour systèmes de communication composés d'une pluralité de serveurs SIP
US20140317061A1 (en) System and method for distributed interaction media storage and retrieval
FR2940569A1 (fr) Systeme d'adaptation pour interception legale dans differents reseaux de telecommunications.
EP2053783A1 (fr) Procédé et système pour l'identification de trafic VoIP dans des réseaux
Nicoletti et al. Forensic analysis of Microsoft Skype for business
EP2517139A1 (fr) Procédé de détection d'un détournement de ressources informatiques
EP2080345A2 (fr) Procede et gestion d'identites publiques dans un reseau de transmission d'informations, serveur de gestion d'enregistrements d'identites publiques, equipement de gestion d'une identite publique de groupe et programmes d'ordinateur correspondants
EP2361466A1 (fr) Procède pour optimiser la détection de contournements d'un réseau de télécommunications
EP3104585A1 (fr) Dispositif et procédé de traitement d'une communication
EP2664127A1 (fr) Construction d'une requete de retention de donnees ou d'interception legale a partir d'une autre requete
EP3754956B1 (fr) Méthode, dispositif et programme d'ordinateur pour déterminer l'usurpation de l'identifiant de l'appelant
EP3469785A1 (fr) Procédé d'enrichissement d'une signalisation d'une communication et dispositif
EP2630765B1 (fr) Procede d'optimisation du transfert de flux de donnees securises via un reseau autonomique
FR3037465A1 (fr) Dispositif et procede de traitement d'une communication
EP2171966B1 (fr) Gestion de sessions multi-flux entre un terminal et un serveur
WO2016097534A1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
FR3103921A1 (fr) Procédé de coordination de la mitigation d’une attaque informatique, dispositif et système associés.
EP3337208B1 (fr) Procédé et dispositif de transmission d'un message
US11363136B2 (en) Lawful interception manifesto
Slay12 et al. Voice over IP and forensics: A review of recent Australian work
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
Da-Yu et al. Extracting Suspicious IP Addresses from WhatsApp Network Traffic in Cybercrime Investigations

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

17P Request for examination filed

Effective date: 20130813

AK Designated contracting states

Kind code of ref document: A1

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

111Z Information provided on other rights and legal means of execution

Free format text: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

Effective date: 20140303

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

D11X Information provided on other rights and legal means of execution (deleted)
17Q First examination report despatched

Effective date: 20170213

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: 20170624