EP1900179A2 - Verfahren zum erhalten von konfigurationsdaten für ein endgerät durch verwendung des dhcp-protokolls - Google Patents

Verfahren zum erhalten von konfigurationsdaten für ein endgerät durch verwendung des dhcp-protokolls

Info

Publication number
EP1900179A2
EP1900179A2 EP06778966A EP06778966A EP1900179A2 EP 1900179 A2 EP1900179 A2 EP 1900179A2 EP 06778966 A EP06778966 A EP 06778966A EP 06778966 A EP06778966 A EP 06778966A EP 1900179 A2 EP1900179 A2 EP 1900179A2
Authority
EP
European Patent Office
Prior art keywords
dhcp
user
terminal
identifier
data
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.)
Ceased
Application number
EP06778966A
Other languages
English (en)
French (fr)
Inventor
Stéphane TUFFIN
François BOURDAIS
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.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1900179A2 publication Critical patent/EP1900179A2/de
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the invention relates to a method for obtaining configuration data for a terminal by using the DHCP protocol. More specifically, the subject of the invention is a method for obtaining configuration data of a terminal as well as a method for processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data from said terminal.
  • Dynamic Host Configuration Protocol DHCP
  • IP Internet Protocol
  • This protocol defines a set of requests for establishing a dialogue between, on the one hand, a client module implemented in the terminal and, on the other hand, a server module implemented in the server. These requests are sent either directly from the client module to the server module and vice versa, or through a DHCP relay.
  • the DHCP protocol can be used for different types of terminals: PC, router, IP phones, SetTopBox, videophones, video camera, etc., as such a terminal includes a DHCP client module able to communicate with a DHCP server module.
  • Such terminals are hereinafter referred to simply as IP terminals.
  • DHCP specifies that DHCP requests issued from a given terminal must contain the MAC address of the terminal. This MAC address uniquely identifies the network interface of the terminal, but it is insufficient to determine the nature of the terminal.
  • the DHCP protocol furthermore provides that the DHCP requests may contain optional data making it possible to manage the diversity of the terminals or the diversity of the needs of the users of these terminals.
  • These optional data are inserted into an option field of the query and include for example:
  • Some users may therefore need a static IP address - not a dynamic IP address - that allows them to access a particular service, for example a database that performs user identification. from its IP address and determines the access rights to the database data accordingly.
  • a known solution to this type of problem is to manually assign a static IP address to the terminal.
  • the disadvantage is that this solution involves the intervention of computer maintenance personnel for each case. In addition, it only works if the need is for a static IP address.
  • One of the aims of the invention is to provide a method for obtaining configuration data of a terminal by means of DHCP requests as well as a method for processing such requests, which do not have the drawbacks mentioned above for the previous solutions, which are compatible with the DHCP protocol and allow in particular a configuration data management of different terminals of a network that is fully automated and adaptable to the specific needs of certain users.
  • the subject of the invention is a method for obtaining configuration data of a terminal, the terminal comprising a DHCP client module able to communicate via a network with at least one DHCP server module according to the DHCP protocol, the method comprising the following steps:
  • DHCP client module generating by said DHCP client module one or more DHCP requests for obtaining configuration data from said terminal, transmission of said one or more DHCP requests via said network by said DHCP client module to said at least one DHCP server module,
  • the method further comprising a step of inserting into a predefined option field at least one of the requests DHCP, optional data comprising an associated identifier, directly or indirectly, to a single user of said terminal, the received configuration data being customized for said user.
  • the insertion in one of the requests of an identifier, associated with one and only one user of the terminal allows the generation of a response to this request which is personalized for a given user, identified, indirectly or indirectly by the identifier inserted. . In this way, the configuration data can be generated to meet the specific needs of a given user.
  • the method makes it possible to envisage a control over the generation of configuration data, and in particular to carry out an identification of the user as soon as he is connected to the network, or even to refuse the assignment of configuration data so as to prevent a user from accessing the network. Securing access to the network therefore occurs at the request of configuration, and is thus reinforced.
  • the method additionally provides a practical answer to situations of nomadism in which the same user can connect to a network using each time a different terminal, for example by using a terminal among a plurality of terminals accessible self-service.
  • the method is further compatible with DHCP and does not require modification of the basic principles of this protocol.
  • the method comprises a step of reading all or part of the optional data in a personal recording medium accessible from the terminal.
  • a recording medium is typically a smart card.
  • the personal recording medium is a medium whose access is secured by an identification code. This makes it possible to secure access to this identifier and its introduction in the request and reduces the chances of successful fraudulent use of personal recording media.
  • the personal recording medium is of the removable media type.
  • a user in a situation of mobility can thus bring his removable support to find a suitable and personalized configuration whatever the terminal he uses.
  • the personal recording medium is integrated in a mobile terminal and is accessible from said terminal by a local communication link established between said terminal and said mobile terminal.
  • This variant avoids the user of a mobile terminal, for example a mobile phone, to provide additional support for the storage of the identifier.
  • the identifier can be for example:
  • a user profile identifier associated with said user Any type of identifier can thus be used to implement the method according to the invention, it is not necessary to have an identifier of the user himself.
  • a registration identifier of a personal recording medium as identifier facilitates the implementation of the method, since such an identifier is pre-existing and databases are available. known mechanisms for processing such identifiers, and if necessary, to determine the identity of the user from such identifiers.
  • all or part of the optional data are inserted into the request in encrypted form. This increases the confidentiality of exchanges and limits the chances of successful fraudulent login attempts.
  • the invention also relates to a terminal comprising a DHCP client module, suitable for implementing the method according to the invention and comprising
  • the subject of the invention is also a method of processing by a server one or more DHCP requests issued by a DHCP client module of a terminal for obtaining configuration data of said terminal, the server comprising a DHCP server module capable of communicating with the DHCP client module via a network according to the DHCP protocol, at least one of said one or more received DHCP requests comprising, in a predefined option field, optional data including an associated identifier, directly or indirectly to a single user of said terminal, the method comprising the steps of
  • the configuration data being personalized for said user
  • the generated configuration data comprise an IP address whose static or dynamic type is a function of said identifier.
  • the method comprises a step of recording for each request comprising said predefined option field tracking data including date and / or time of receipt of said request.
  • said predefined option field tracking data including date and / or time of receipt of said request.
  • the method comprises steps of determining the identity of said user from said identifier, generating the requested configuration data according to the identity of said user in case of identification of the user, to refuse the generation of the requested configuration data in the case where said user is not identified.
  • the invention also relates to a server comprising a DHCP server module, suitable for implementing the processing method according to the invention, and comprising a module for generating said requested configuration data according to said identifier.
  • the server comprises a database comprising a list of identifiers, and for each identifier of the data corresponding to a description of the configuration requirements of the user associated with this identifier.
  • FIG. 1 is a simplified representation of the invention. architecture of a system for implementing the invention
  • FIG. 2 schematically illustrates different phases of the method according to the invention as well as data exchanges between the entities concerned by these different phases.
  • the invention is described in the context of its application to a situation in which a customer of a service provider wishes to access services made available through terminals accessing a network.
  • the terminals are, in this example, self-service terminals.
  • the customer begins by registering with the service provider for certain predefined services.
  • the service provider gives him a smart card.
  • This smart card contains information about the customer himself (ID
  • This terminal has a standard configuration, which is for example a configuration allowing only local use, without a network connection, of this terminal. To allow access to the services subscribed by a given user, it must be configured appropriately, and in particular have a DHCP address to access the services implemented via the network. Thanks to the invention, this terminal can be configured each time according to the identity of the user who connects to the network via this terminal, and this as soon as the connection to the network of the terminal is restored.
  • Figure 1 shows in a simplified manner the main elements cooperating in a system of such a terminal.
  • the terminal 100 is in communicating via a communication network 50 with a data processing server 200 accessing a database 300.
  • the terminal 100 is a microcomputer.
  • this terminal can be any type of terminal including a DHCP client module allowing access to the network 50.
  • the terminal 100 comprises a network card 1 15 compatible with the communication network 50. It also includes a 125 smart card reader. As a variant, the smart card reader 125 can be, not integrated in the terminal
  • the terminal 100 includes various software modules:
  • a DHCP client module 1 a driver 140 adapted to the smart card reader, a read module 150 accessing via the driver 140 to the data of the smart card, a data insertion module 170 used in combination with the DHCP client module 1 10,
  • the DHCP client module 1 10 of the terminal is adapted to interface with the data insertion module 170.
  • Either the DHCP client module 1 10 includes a software interface for communicating or interfacing with the insertion module 170, or it fully integrates the data insertion module 170.
  • the smart card acts as a personal recording medium.
  • Any other form of personal recording medium capable of storing data can also be envisaged: a USB electronic key connected via a USB port, a SIM card of a mobile phone accessible via a Bluetooth link between the terminal and the telephone, etc.
  • the means of access to the recording medium are each adapted to the recording medium used.
  • the access to the recording medium is secure so as to prevent fraudulent access to the data it contains or identity theft. This access security usually consists in allowing access to the data of the smart card only after provision of a confidential code.
  • the recording medium is a removable chip card type medium so that a given user can easily, even when is in frequent motion, connect from any terminal while finding a configuration appropriate to its needs.
  • the data processing server 200 comprises a network interface card 215 compatible with the communication network 50. It also includes a software module called DHCP 210 server module.
  • the DHCP client module and the DHCP server module are designed to interact with each other according to the DHCP protocol as defined by the IETF ("Internet Engineering Task Force") in the RFC 2131 standard.
  • This protocol defines in particular how a client terminal comprising a DHCP client module obtains its network configuration (its IP address, in general) from a DHCP server including a DHCP server module.
  • the requests sent by the client module to the server module are for example:
  • DHCP DISCOVER a "DHCP DISCOVER" request by which the client module tests the presence of one or more DHCP servers on the network and requests the establishment of a dialogue with one of these servers;
  • DHCP REQUEST a "DHCP REQUEST” request by which the client module requests configuration data from the server that has responded to its previous "DHCP DISCOVER” request; a "DHCP REQUEST RENEWAL” request by which the client module renews its previous “DHCP REQUEST” request.
  • DHCP requests issued by a DHCP client module may contain optional data. This data is identified in a DHCP request by an option code. For example, an option code 60 indicates the presence of data identifying the type of terminal.
  • an option field provided in the DHCP protocol is used to insert, in the DHCP request sent by the DHCP client module, an option code and data associated with this option code.
  • the inserted DHCP option complies with RFC 2489 standard. It is defined by: - an option code, for example code 180,
  • a parameter indicating the quantity of data associated with the option for example in the form of a number of characters.
  • an option will be named "option 180" or "user option”.
  • This predefined option code identifies the option field in which the identifier is inserted and is indicative that the configuration data requested by the client module is to be generated according to said identifier, and more specifically, that they are to be personalized. for the user associated with this identifier.
  • the data associated with the option code 180 includes an identifier associated, directly or indirectly, with one and only one user of the terminal 1, 10. Such an identifier makes it possible to determine without ambiguity the identity of the associated user. to this identifier.
  • Such an identifier can be, at choice: - an identifier of the user himself, for example his surname, first name;
  • an identifier of the user himself in coded form which is attributed to this user and makes it possible to identify him among other users within a given organization; it may be for example an employee identifier assigned to the user in the company for which he works or a customer identifier assigned to the user by a service provider organization of which this user is a customer;
  • a smart card registration identifier from which the identity of the user can be determined, the user associated with this identifier being in this case the owner of the smart card; an identifier of the type of telephone number from which the identity of the user can be determined, the user associated with this identifier being in this case the subscriber to the telephone line identified by this number,
  • an identifier of an abstract entity associated with a single user for example a user profile identifier associated with this user, etc.
  • a predefined option code identifying said option field is preferably used to indicate the presence of such an identifier and to indicate to the request processing module that the requested configuration data are to be customized for the user associated with the request. this identifier.
  • Other data can also be inserted into the query. These may or may not be extracted from the smart card. In particular, it may be useful to insert data identifying or describing a user profile. It can indeed be envisaged that a user needs to connect with different types of profiles to the terminal. For example, a user profile includes identification information of the services accessible from the terminal to which this user has subscribed. A User profile can also include information on the conditions of access to these services: time slot, number of access, etc.
  • the profile identifier may be the only data item integrated into the option field 180 because it can be used to identify the terminal user if this profile identifier is associated with a user. and only one.
  • the database preferably comprises a list of identifiers, and for each identifier of the corresponding data, either information relating to the services subscribed by the user associated with this identifier, or to a description of the configuration requirements of the the user associated with this identifier (type of address, access rights, etc.), or the configuration data themselves (in the case of a static address, it is necessary to memorize it). In this way, the server is thus able, without even knowing the identity of the user, to generate custom configuration data.
  • the data inserted in the request and associated with the option code 180 are preferably extracted from the smart card.
  • data from different sources for example non-confidential data, can also be inserted into the request.
  • Some or all of the data associated with option 180 may be encrypted.
  • the encryption of these data can be done, either before insertion of the data in the request, or before recording of the data on the smart card.
  • the risks of identity theft are very low, especially if access to the information medium is moreover secure.
  • FIG. 2 illustrates the different phases of the method according to the invention as well as the data exchanges carried out during these different phases between the terminal
  • this data notably comprises an identifier associated with a user of the terminal 100;
  • the reader 120 reads the data requested in the smart card 130 and sends them back to the terminal;
  • the server 200 processes the request "DHCP DISCOVER" by accessing S75 if necessary to the database 300; this processing is carried out taking into account all or part of the data read in the card and inserted in the request; the server 200 generates a response that preferably depends on the identifier inserted in the request;
  • the terminal 100 generates a request "DHCP REQUEST" and insert all or part of the previously read data in the card;
  • the server 200 processes the request "DHCP REQUEST" by accessing S135 if necessary to the database 300;
  • the server 200 sends a response to the request "DHCP REQUEST" in the form of a "DHCP ACK" request including an IP address intended for the configuration of the terminal 100;
  • the terminal 100 receives the response "DHCP ACK";
  • the terminal 100 proceeds to its IP configuration from the IP address returned by the server 200.
  • the constitution of a DHCP request by the terminal 100 itself comprises the following steps:
  • the DHCP client module 1 10 creates a DHCP request; the DHCP client module 1 10 transfers this request to the insertion module 170;
  • the insertion module 170 sends a request to the reading module 150 via the middleware 160 for the extraction of the data from the smart card; the reading module 150 obtains the requested data from the driver 140 of the card reader 120; the reading module 150 sends the requested data to the insertion module 170 via the middleware 160; the insertion module 170 inserts the data in the created DHCP request and the transfer to the DHCP client module 1; the DHCP client module sends the DHCP request to the DHCP server module 210 and waits for its response.
  • each generated DHCP request may include an option 180 and associated data.
  • the "DHCP DISCOVER” and “DHCP REQUEST” requests contain information on the identity of the user of the terminal. All requests issued by the DHCP client module ("DHCP REQUEST RENEWAL”, “DHCP INFORM” and “DHCP RELEASE”) may contain this information as needed.
  • DHCP REQUEST RENEWAL "DHCP INFORM”
  • DHCP RELEASE DHCP RELEASE
  • step S100 of generating a "DHCP REQUEST” request may require substeps S102 and S103 for access to the smart card and for reading data in the smart card.
  • the DHCP server is configured to use the information set in the chosen DHCP option in different ways:
  • the service provider can implement billing by user, for example depending on the number of connections or the duration of each connection, the tracking data being crossed with the information linking a customer to a smart card ; - to emit a response that is personalized according to the identity of the user or according to the services this user has subscribed to; for example by generating configuration data according to the identifier and / or the identity of the user.
  • the operation considered is a simple record of tracking data, it can optionally be executed after sending the response to the client request.
  • the processing by the server 200 of the DHCP request sent by the terminal 100 is performed according to the data of the optional data field. These data comprise an identifier, uniquely associated with the user of the terminal 100. This is in particular an identifier for a unique identification of the user of the terminal 100.
  • the DHCP server determines, prior to the processing of the DHCP request, the identity of the user of the terminal 100 and processes the request according to the identity of the user.
  • operations such as the recording of tracking data, the processing of the data associated with the request, the access control from the data associated with the request or the generation of the response to the request, can be performed according to the identity of the current user of the terminal 100.
  • the step of determining the identity of the user of the terminal can be avoided, if the server is designed to respond to the request solely on the basis of the identifier, especially if the server comprises a database registering the user configuration requirements in association with the identifier.
  • the DHCP server identifies from the identifier associated with the user the services subscribed by this user and returns a response (configuration data) that is adapted to the services subscribed.
  • the DHCP configuration returned by the server in response to a request "DHCP REQUEST" may be a function of the identifier, and therefore of the identity of this user. It is thus possible to ensure that the type, static or dynamic, of the returned address is also a function of the identity of this user. In the case of example where the user needs a static address, the server will always return a predefined static address tailored to that user's needs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
EP06778966A 2005-06-28 2006-06-22 Verfahren zum erhalten von konfigurationsdaten für ein endgerät durch verwendung des dhcp-protokolls Ceased EP1900179A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506572A FR2887723A1 (fr) 2005-06-28 2005-06-28 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp
PCT/FR2006/050621 WO2007000552A2 (fr) 2005-06-28 2006-06-22 Procede d'obtention de donnees de configuration pour un terminal par utilisation du protocole dhcp

Publications (1)

Publication Number Publication Date
EP1900179A2 true EP1900179A2 (de) 2008-03-19

Family

ID=35825368

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06778966A Ceased EP1900179A2 (de) 2005-06-28 2006-06-22 Verfahren zum erhalten von konfigurationsdaten für ein endgerät durch verwendung des dhcp-protokolls

Country Status (4)

Country Link
US (1) US20080279116A1 (de)
EP (1) EP1900179A2 (de)
FR (1) FR2887723A1 (de)
WO (1) WO2007000552A2 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8681779B2 (en) * 2006-09-01 2014-03-25 Alcatel Lucent Triple play subscriber and policy management system and method of providing same
US20080259941A1 (en) * 2007-04-19 2008-10-23 At&T Knowledge Ventures, L.P. System and apparatus for managing ip addresses
US9106714B2 (en) * 2009-07-23 2015-08-11 Cisco Technology, Inc. Plug and play provisioning of voice over IP network devices
WO2012109867A1 (zh) * 2011-07-30 2012-08-23 华为技术有限公司 用于路由协议配置的方法、装置及系统
FR3046012A1 (fr) * 2015-12-17 2017-06-23 Orange Procede et dispositif de fourniture d'une information de localisation a un equipement connecte a un point d'acces reseau
FR3057423A1 (fr) * 2016-10-11 2018-04-13 Orange Procede de negociation d'une qualite de service offerte par une passerelle a des terminaux
US10805292B2 (en) * 2018-02-19 2020-10-13 Fmr Llc Secure authentication and network access management for mobile computing devices
JPWO2021182025A1 (de) * 2020-03-13 2021-09-16

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU4603100A (en) * 1999-05-03 2000-11-17 Nokia Corporation Sim based authentication mechanism for dhcrv4/v6 messages
US7096273B1 (en) * 2001-04-25 2006-08-22 Cisco Technology, Inc. DHCP over mobile IP
US7720044B1 (en) * 2002-04-19 2010-05-18 Nokia Corporation System and method for terminal configuration
US20040059844A1 (en) * 2002-09-20 2004-03-25 Woodhead Industries, Inc. Network active I/O module with removable memory unit
US7640430B2 (en) * 2005-04-04 2009-12-29 Cisco Technology, Inc. System and method for achieving machine authentication without maintaining additional credentials

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DROMS BUCKNELL UNIVERSITY R: "Dynamic Host Configuration Protocol; rfc2131.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 March 1997 (1997-03-01), XP015007915, ISSN: 0000-0003 *

Also Published As

Publication number Publication date
WO2007000552A3 (fr) 2007-05-03
FR2887723A1 (fr) 2006-12-29
US20080279116A1 (en) 2008-11-13
WO2007000552A2 (fr) 2007-01-04

Similar Documents

Publication Publication Date Title
US8015253B1 (en) System and method for controlling inter-device media exchanges
EP2294776B1 (de) Verfahren und system für benutzerzugang zu mindestens einem von mindestens einem anderen benutzer angebotenen dienst
EP1900179A2 (de) Verfahren zum erhalten von konfigurationsdaten für ein endgerät durch verwendung des dhcp-protokolls
JP2003527672A (ja) インターネットホストサーバを介してポータブルデバイスの安全な認証を提供するための方法および装置
EP3298812B1 (de) Laden eines teilnehmerprofils in eine eingebettete sim-karte
WO2008085205A2 (en) System and method for providing network support services and premises gateway support infrastructure
FR2977418A1 (fr) Systeme d'authentification via deux dispositifs de communication
WO2009055182A1 (en) System and method for automatic transfer of data from one device to another
EP2795870B1 (de) Verfahren zur ermöglichung des zugriffs eines telekommunikationsendgeräts auf eine von einer über ein telekommunikationsnetz zugängliche dienstplattform gehostete datenbank
WO2006087438A1 (fr) Procede et dispositif d'acces a une carte sim logee dans un terminal mobile par l'intermediaire d'une passerelle domestique
EP1537718B1 (de) Automatischer authentifikationsauswahlserver
EP1704700B1 (de) Verfahren und system zum betreiben eines computernetzwerks, das für inhaltsveröffentlichungen bestimmt ist
WO2006010810A2 (fr) Procede et systeme de certification de l’identite d’un utilisateur
EP1637989A1 (de) Verfahren und Vorrichtung zur Aufteilung von Konten mit persönlichen Daten
WO2004043093A1 (fr) Systeme et procede de gestion d'acces d'un reseau de communication a un terminal mobile
EP1905217B1 (de) Verfahren zum konfigurieren eines endgeräts über ein zugangsnetzwerk
WO2018211180A1 (fr) Procede pour connecter des equipements au reseau internet
WO2013110884A1 (fr) Systeme et procede de controle d'une requête dns
FR2844949A1 (fr) Procede de gestion d'une configuration d'une passerelle par un utilisateur de la passerelle
FR2813151A1 (fr) Communication securisee dans un equipement d'automatisme
EP1705868A2 (de) Verfahren und System zur gemeinsamlichen Nutzung von persönlichen Attributen
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
WO2018211179A1 (fr) Procede pour la creation de comptes d'acces au reseau internet
FR2922402A1 (fr) Procede d'acces a un contenu a partir d'un terminal mobile
FR2893208A1 (fr) Procede et dispositif de fourniture d'un alias de federation d'identite reseau a un fournisseur de service

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

AK Designated contracting states

Kind code of ref document: A2

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

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080331

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BOURDAIS, FRANCOIS

Inventor name: TUFFIN, STEPHANE

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20111022