FR2945175A1 - Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur - Google Patents

Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur Download PDF

Info

Publication number
FR2945175A1
FR2945175A1 FR0952827A FR0952827A FR2945175A1 FR 2945175 A1 FR2945175 A1 FR 2945175A1 FR 0952827 A FR0952827 A FR 0952827A FR 0952827 A FR0952827 A FR 0952827A FR 2945175 A1 FR2945175 A1 FR 2945175A1
Authority
FR
France
Prior art keywords
user
call
terminal
cryptographic key
transmitted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0952827A
Other languages
English (en)
Other versions
FR2945175B1 (fr
Inventor
Ahmed Serhrouchni
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.)
GROUPE ECOLES TELECOMM
Original Assignee
GROUPE ECOLES TELECOMM
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 GROUPE ECOLES TELECOMM filed Critical GROUPE ECOLES TELECOMM
Priority to FR0952827A priority Critical patent/FR2945175B1/fr
Publication of FR2945175A1 publication Critical patent/FR2945175A1/fr
Application granted granted Critical
Publication of FR2945175B1 publication Critical patent/FR2945175B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé permettant à un usager de vérifier les factures téléphoniques émises par un opérateur. Elle concerne également les factures téléphoniques découlant dudit procédé ainsi que les terminaux IP permettant la mise en oeuvre dudit procédé. Le procédé de la présente invention est remarquable en ce qu'il comprend sur lesdites factures dudit usager l'apposition d'un numéro propre émis et transmis à chaque appel dudit usager par le terminal de cet usager, ledit numéro étant obtenu par l'application d'une clé cryptographique prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique étant uniquement connue et gérée par le terminal dudit usager. L'architecture de téléphonie ciblée par la présente invention est préférentiellement celle qui est basée sur le protocole SIP mais le procédé de la présente invention peut être transposé sur d'autres architectures de téléphonie telles que GSM, H323.

Description

Procédé permettant aux usagers de vérifier les factures téléphoniques les concernant émises par un opérateur.
La présente invention concerne un procédé permettant à un usager de vérifier les factures téléphoniques émises par un opérateur. Elle concerne également les factures téléphoniques découlant dudit procédé ainsi que les terminaux IP permettant la mise en oeuvre dudit procédé. L'architecture de téléphonie ciblée par la présente invention est préférentiellement celle qui est basée sur le protocole SIP mais le procédé de la présente invention peut être transposé sur d'autres architectures de téléphonie telles que GSM, H323.
Les réclamations des consommateurs concernant leurs factures téléphoniques émises par différents opérateurs sont un sujet récurrent. La multiplication des opérateurs qui, jusque dans un passé récent, représentaient l'autorité publique, associée au développement de la téléphonie sur IP (VoIP), contribuent à amplifier ces problèmes. En effet, les consommateurs ne disposent pas de réel instrument pour la vérification de leur facture. Ainsi, les architectures et protocoles de téléphonie sont basés sur des approches où l'opérateur détient l'ensemble des éléments qui caractérisent l'utilisation des ressources téléphoniques, ne permettant pas aux usagers consommateurs de vérifier la facture produite par leurs opérateurs.
Le protocole de téléphonie Session Initiation Protocol (SIP) est un protocole standard ouvert de gestion de sessions qui est souvent utilisé dans les télécommunications multimédia et, depuis 2007, le protocole le plus courant pour la téléphonie par internet (VoIP). Ce protocole, décrit dans le standard RFC3261 de l'IETF (Internet Engineering Task Force), semble devenir le standard de la téléphonie et connaît de nombreuses applications telles que la visiophonie ou la messagerie instantanée. SIP est un protocole normalisé et standardisé qui a été conçu pour établir, modifier et terminer des sessions multimédia. SIP se charge de l'authentification et de la localisation des multiples participants. Il partage de nombreuses similitudes avec le protocole http comme le codage en ASCII et les codes de réponses. Le protocole SIP est de type requête/réponse. Un usager qu'on appelle User Agent (UA) peut établir un appel vers un serveur qu'on appelle le Proxy ou User Agent Server (UAS).
Une requête peut être ainsi transmise par un UA ou un UAS et une ou plusieurs réponses peuvent être retournées à l'émetteur de la requête. Une requête est composée d'une méthode ; parmi les méthodes de base figurent les méthodes suivantes reconnues par leurs appellations communément utilisées : INVITE qui permet à un UA ou UAS de demander une nouvelle session, ACK qui confirme l'établissement d'une session, CANCEL qui annule une demande INVITE en suspens, BYE qui termine une session en cours. D'autres méthodes sont définies dans SIP dont les appellations sont les suivantes : ACK, BYE, CANCEL, OPTIONS, REGISTER, SUSCRIBE, INFO, NOTIFY, PRACK, 10 PREFER, UPDATE, MESSAGES, PUBLISH. Une réponse contient un code numérique sur trois digits suivis de plusieurs en-têtes d'un type similaire à ceux des codes http. Parmi ceux-ci figurent par exemple : 100 Trying, 200 OK, 404 Not Found ; des codes supérieurs à x80 sont spécifiques de SIP tels que : 180 Ringing, 486 Busy, etc... 15 Dans les tableaux ci-dessous, à titre d'illustration, sont représentées la requête (Tableau 1) et la réponse associée (Tableau 2) à une demande d'appel selon le protocole SIP:
Tableau 1 : Requête :
INVITE sip:dest@domain.org SIP/2.0 Via: SIP/2.0/UDP oeni.domain.org:5060 From: SRC <sip:src@domain.org>;tag=123456795 To: <sip: dest@domain.org> Contact: <sip: src@oeni.domain.org:5060> Call-ID: 1231B49C6F5E634Z954C1234560BCBD99ABCE5EE4231 CSeq: 43557 INVITE Content-Type: application/sdp User-Agent: X-yyy build 1112 Content-Length: 198 v=0 o=src 6543217 6543217 IN IP4 133.194.192.133 s=X-yyy c=IN IP4 133.194.192.133 t=0 0 m=audio 8000 RTP/AVP 8 101 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 20 25 30 35 40 Tableau 2 : Réponse:
SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP oeni.domain.org:5060; received= oeni.domain.org From: Src <sip: src@domain.org >;tag=123456795 To: <sip: dest@domain.org>;tag=jd555ab2fc CallùID: 1231B49C6F5E634Z954C1234560BCBD99ABCE5EE4231 CSeq: 43557 INVITE UserùAgent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY MaxùForwards: 70 Contact: <sip: src@oeni.domain.org > ProxyùAuthenticate: Digest realm="asterisk", nonce="3bddb6da" ContentùLength: 0 Les en-têtes Via, From, To, Call-ID, CSEQ et Max-Forwards sont présents dans toutes les requêtes et réponses formant l'en-tête général. L'en-tête Call-ID contient un 25 identificateur unique pour un appel. L'ensemble des requêtes et réponses pour un appel donné sont reliées entre elles par une valeur identique associée à cet en-tête Call-ID. A chaque appel une valeur globale unique est associée à cet en-tête. Plusieurs attaques existent sur la base de la prédiction de la valeur de ce champ. En effet, l'émission par un attaquant d'une terminaison d'une session nécessite l'envoi d'une 30 requête de type Cancel ou Bye avec une valeur du Call-ID semblable à celle de l'appel en cours qui met fin à la session. D'autres en-têtes sont définies pour SIP mais leur présence dans les messages SIP n'est pas obligatoire, on peut citer les en-têtes suivantes : Date, Accept,, Accept-Contact, Accept-Encoding, Accept-Language , Accept-Resource-Priority, Alert-Info, Allow, Allow-Events, 35 Authentication-Info, Authorization, Call-Info, Contact, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Encryption, Error-Info, Event, Expires, Hide, etc. Certains en-têtes garantissent une valeur unique pour un appel tel que l'en-tête Date pris comme exemple non limitatif. 40 Dans le paragraphe 8.1.1.4 du RFC3261 qui décrit le protocole SIP, il est préconisé d'utiliser une fonction cryptographique pour générer la valeur du Call-ID sans décrire de 3 10 15 20 méthode particulière pour le faire, notamment quant à la gestion des clés associées à cet algorithme cryptographique.
Un premier objet de la présente invention est de proposer un procédé permettant aux usagers d'un opérateur téléphonique de vérifier les factures téléphoniques le concernant. Le procédé de la présente invention est remarquable en ce qu'il comprend sur lesdites factures dudit usager l'apposition d'un numéro propre émis et transmis à chaque appel dudit usager par le terminal de cet usager, ledit numéro étant obtenu par l'application d'une clé cryptographique prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique étant uniquement connue et gérée par le terminal dudit usager. Cette clé cryptographique est de type f (K, n) = N°Id dans laquelle : - K représente ladite clé cryptographique, - n représente tout ou partie des données des champs de l'en-tête pris en compte par ladite clé cryptographique pour calculer le numéro propre à chaque appel, N°Id représente le numéro calculé propre à chaque appel associé à l'en-tête du Call-ID. Cette clé est archivée, stockée et protégée du côté de l'usager, principalement dans le terminal de celui-ci. Elle est ainsi secrète et connue par lui seul. Le procédé de la présente invention permet donc le calcul d'une valeur unique à chaque appel émis dont le déchiffrement sera seulement permis à l'usager qui est seul en possession de la clé qui a permis de chiffrer cette valeur, lui permettant ainsi de reconstituer l'en-tête de l'appel qu'il a initié et vérifier que cet appel lui est facturé à juste titre. Par N°Id est entendu le numéro calculé propre à chaque appel c'est à dire la valeur qui sera associée à l'en-tête Call-ID dans le procédé de la présente invention.
Dans le mode de réalisation principal, les champs de l'en-tête définissant un appel dans un protocole standard de téléphonie pris en compte sont au moins un des champs parmi Via, From, To, Call-ID et Cseq.
Dans le mode de réalisation principal, N°Id qui représente le numéro calculé propre à chaque appel est transcrit en un codage permettant sa lecture et son impression.
Dans un mode de réalisation particulier, dans le cas où les valeurs associées aux données des champs de l'en-tête sont identiques pour deux appels ou sessions distincts, un nombre aléatoire est rajouté à n afin d'assurer un résultat unique pour le calcul cryptographique du N°Id représentant la valeur qui sera associée à l'en-tête Call-ID. Dans un mode particulier de ce mode de réalisation, ce nombre aléatoire n est concaténé à N°Id.
Dans un autre mode de réalisation particulier, dans le cas où l'en-tête Date est présent ou tout autre en-tête garantissant une valeur unique pour un appel, la valeur associée à cette en-tête peut faire partie de n.
Un des avantages du procédé de la présente invention est que le calcul cryptographique par 10 une clé uniquement connue de l'usager empêche toute prédiction du Call-ID et attaques inhérentes à cette prédiction.
Un second objet de l'invention concerne les factures d'un opérateur de téléphonie obtenues à l'aide du procédé précédent, remarquables en ce qu'elles contiennent un numéro propre à 15 chaque appel émis et transmis par le terminal dudit usager, ledit numéro étant obtenu par l'application d'une clé cryptographique prenant en compte des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique étant uniquement connue et gérée par ledit usager, les données des champs de l'en-tête ayant été considérés pour ledit numéro étant obtenues par l'application 20 d'une clé cryptographique. Le déchiffrement de cette valeur contenue dans lesdites factures téléphoniques sera seulement possible par l'usager seul en possession de la clé qui a permis de chiffrer cette valeur et lui permettra de reconstituer l'en-tête de l'appel qu'il a initié et vérifier que cet appel lui est facturé à juste titre. 25 Un troisième objet de la présente invention concerne les terminaux IP qui permettent la mise en oeuvre du procédé de la présente invention. Par terminaux IP, on entend l'ensemble des types de terminaux IP qui initient ou reçoivent les requêtes tels que téléphones, hardphone, softphone, boîtier ATA, etc... Les exemples suivants accompagnés des dessins ci-annexés, le tout donné à titre d'exemple non limitatif, permettront de bien comprendre comment l'invention peut être réalisée. Dans les dessins : 30 - La figure 1 schématise une session d'appel classique entre deux UA (UA1, UA2) dans l'environnement SIP et une facture émise par l'opérateur qui en découle. - La figure 2 schématise une session d'appel entre deux UA (UA1, UA2) dans l'environnement SIP mettant en oeuvre le procédé de la présente invention permettant l'obtention et la transmission par le terminal de l'UA1 émettant l'appel, d'un numéro propre à l'appel obtenu par l'application d'une clé cryptographique ainsi que la facture découlant dudit procédé de l'invention sur laquelle figure le numéro N°Id propre à cet appel. - La figure 3 compare un type de facture classique (partie supérieure de la figure) avec une facture présentant des N°Id propres à chaque appel, émise lors de la mise en oeuvre du procédé de l'invention (partie inférieure de la figure).
Dans les figures 1 et 2 commentées ci-après, les requêtes et réponses dans les étapes ST1 à ST3 constituent la transaction INVITE ; L'étape ST3 est l'étape à partir de laquelle il y a création du dialogue entre les deux usagers UA1 et UA2. L'étape ST5 est l'étape qui marque l'arrêt du dialogue ; les requêtes et réponses des étapes ST5 et ST6 constituent la transaction BYE. L'étape ST7 représente l'étape de facturation émise par l'opérateur 3.
La figure 1 schématise une session d'appel avec différentes requêtes et réponses 4 entre deux UA 1 et 2 (UA1, UA2) dans l'environnement SIP, UA1 1 étant l'usager qui émet l'appel et une facture 5 émise par l'opérateur 3 en rapport avec cet appel.
La figure 2 schématise la même hypothétique session d'appel dans l'environnement SIP avec différentes requêtes et réponses 4 mettant en oeuvre le procédé de l'invention. Dans cette session d'appel entre deux UA 1 et 2 (UA1, UA2), l'UA1 1 est l'usager qui émet l'appel. Par le procédé de la présente invention, une clé cryptographique 6 de type f (K, n) = N°Id prenant en compte dans cet exemple les différents champs de l'en-tête, Via = n1, From = n2, To = n3, Call-ID = n4 et CSeq = n5, permet au terminal de l'UA1 1 d'émettre et de transmettre un numéro N°Id 7 propre à cet appel. La clé cryptographique 6 est stockée et protégée dans le terminal de UA1 1. Le N°Id 7 est apposé par l'opérateur 3 sur la facture 5 concernant l'appel émis. Le N°Id 7 présent sur la facture reçue par l'UA1 1 permet à celui-ci, via son terminal 1, de retrouver l'en-tête général de son appel en décryptant N°Id 7 par la clé cryptographique 6 et vérifier ainsi que cet appel lui a été facturé à juste titre.
Le champ supplémentaire correspondant à l'apposition des N°Id 7 dans les factures 5 5 émises lors de la mise en oeuvre du procédé de l'invention sont mis en évidence dans la figure 3.
Le procédé de la présente invention préserve totalement les architectures et protocoles associés à l'environnement du protocole SIP. Cette solution a pour avantage de préserver 10 l'interopérabilité avec l'ensemble des implantations courantes de SIP et ne nécessite aucune modification des protocoles associés à l'architecture SIP. Le procédé de la présente invention s'applique à SIP mais peut être transposé sur d'autres architectures de téléphonie (GSM, H323,...).
15 20

Claims (2)

  1. Revendications: 1. Procédé permettant de vérifier les factures téléphoniques (5) émises par un opérateur concernant les appels facturés à un usager dans un protocole standard de téléphonie, caractérisé en ce qu'il comprend sur lesdites factures (5) dudit usager l'apposition d'un numéro propre (7) émis et transmis à chaque appel dudit usager par le terminal (1) dudit usager, ledit numéro (7) étant obtenu par l'application d'une clé cryptographique (6) prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique (6) étant uniquement connue et gérée par le terminal (1) dudit usager.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que la clé cryptographique (6) est de type f (K, n) = N°Id dans laquelle : - K représente ladite clé cryptographique (6), - n représente tout ou partie des données des champs de l'en-tête prises en compte par ladite clé cryptographique (6) pour calculer le numéro propre à chaque appel, - N°Id représente le numéro calculé propre à chaque appel (7) associé à l'en-tête du Call-ID. 5. Procédé selon la revendication 2, caractérisé en ce que la clé cryptographique (6) est connue seulement par l'usager, archivée et protégée dans le terminal de l'usager (1). 6. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les champs de l'en-tête définissant un appel dans un protocole standard de téléphonie pris en compte sont au moins un des champs parmi Via, From, To, Call-ID et Cseq. 7. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le numéro calculé propre N°Id (7) est transcrit en un codage permettant sa lecture et son impression. 830 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'un nombre aléatoire est rajouté à n afin d'assurer un résultat unique pour le calcul cryptographique de N°Id. 7. Procédé selon la revendication 6, caractérisé en ce que le nombre aléatoire n est concaténé à N°Id. 8. Procédé selon la revendication 1, caractérisé en ce que le protocole standard de téléphonie est le protocole SIP. 9. Facture téléphonique (5) concernant les appels facturés à un usager dans un protocole standard de téléphonie, caractérisée en ce qu'elle contient un numéro propre à chaque appel (7) émis et transmis par le terminal (1) dudit usager, ledit numéro (7) étant obtenu par l'application d'une clé cryptographique (6) prenant en compte tout ou partie des données des champs de l'en-tête définissant un appel dans un protocole standard de téléphonie, ladite clé cryptographique (6) étant uniquement connue et gérée par ledit usager, les données des champs de l'en-tête ayant été considérés pour ledit numéro (7) étant obtenues par l'application d'une clé cryptographique (6). 10. Terminal client IP (1) caractérisé en ce qu'il permet la mise en oeuvre du procédé selon les revendications 1 à 8.
FR0952827A 2009-04-29 2009-04-29 Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur Expired - Fee Related FR2945175B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0952827A FR2945175B1 (fr) 2009-04-29 2009-04-29 Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0952827A FR2945175B1 (fr) 2009-04-29 2009-04-29 Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur

Publications (2)

Publication Number Publication Date
FR2945175A1 true FR2945175A1 (fr) 2010-11-05
FR2945175B1 FR2945175B1 (fr) 2011-05-27

Family

ID=41381894

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0952827A Expired - Fee Related FR2945175B1 (fr) 2009-04-29 2009-04-29 Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur

Country Status (1)

Country Link
FR (1) FR2945175B1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008003337A1 (fr) * 2006-07-04 2008-01-10 Telefonaktiebolaget L M Ericsson (Publ) Facturation de trafic gprs pour portables itinérants en effectuant le décompte du trafic au niveau du terminal utilisateur
US20080215489A1 (en) * 2005-02-25 2008-09-04 Marcus Maxwell Lawson Method And Apparatus For Authentication Of Invoices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080215489A1 (en) * 2005-02-25 2008-09-04 Marcus Maxwell Lawson Method And Apparatus For Authentication Of Invoices
WO2008003337A1 (fr) * 2006-07-04 2008-01-10 Telefonaktiebolaget L M Ericsson (Publ) Facturation de trafic gprs pour portables itinérants en effectuant le décompte du trafic au niveau du terminal utilisateur

Also Published As

Publication number Publication date
FR2945175B1 (fr) 2011-05-27

Similar Documents

Publication Publication Date Title
US8990569B2 (en) Secure communication session setup
Mazurczyk et al. Covert Channels in SIP for VoIP signalling
US10917256B2 (en) Guest user access in the IP multimedia subsystem IMS
US9019869B2 (en) System and method to suppress voice prompts in SIP calls
Sparks SIP: Basics and Beyond: More than just a simple telephony application protocol, SIP is a framework for developing communications systems.
Rosenberg A hitchhiker's guide to the session initiation protocol (sip)
FR2945175A1 (fr) Procede permettant aux usagers de verifier les factures telephoniques les concernant emises par un operateur
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
Camarillo The early session disposition type for the Session Initiation Protocol (SIP)
US9002748B2 (en) Method for securing IP connections for network operator combinatory connections
KR100608907B1 (ko) ３ｇｐｐ ｉｍｓ망에서 화상 통화 내용 기록 방법 및 시스템
EP3701697A1 (fr) Procédé et entité de gestion d&#39;une session multimédia entre un terminal appelant et au moins un terminal appelé, terminal et programme d&#39;ordinateur correspondants
WO2012085429A2 (fr) Procédé de localisation et d&#39;identification d&#39;un abonné connecté à un réseau émulant le rtc/rnis
Boulton et al. Media Resource Brokering
EP3391615A1 (fr) Procede de communication entre un terminal appelant et une pluralite de terminaux appeles
Portman et al. Session recording protocol
Lee et al. A Study on methods of MCID (Multimedia Caller IDentification) supplementary service based on SIP
Portman et al. RFC 7866: Session Recording Protocol
Portman et al. Session recording protocol–draft-ietf-siprec-protocol-16
Hilt et al. A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies
Kaji et al. TLS handshake method based on SIP
Camarillo The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
Bertin Integrating IMS with web services to enable IP Multimedia Service Oriented Architectures
Camarillo RFC 3959: The Early Session Disposition Type for the Session Initiation Protocol (SIP)
EP2262196A1 (fr) Procédé et dispositif de gestion de communications électroniques sécurisées en milieu hétérogène

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 7

ST Notification of lapse

Effective date: 20161230