EP3539272A1 - Procédé de gestion d'autorisation dans une communauté d'objets connectes - Google Patents
Procédé de gestion d'autorisation dans une communauté d'objets connectesInfo
- Publication number
- EP3539272A1 EP3539272A1 EP17808543.7A EP17808543A EP3539272A1 EP 3539272 A1 EP3539272 A1 EP 3539272A1 EP 17808543 A EP17808543 A EP 17808543A EP 3539272 A1 EP3539272 A1 EP 3539272A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- community
- message
- action
- master
- requesting
- 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.)
- Pending
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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Definitions
- the present invention relates to the field of authorization management, in particular for connected objects.
- the Internet of Things (or loT) is a technological trend to connect a large number of everyday objects via the Internet to provide services.
- These objects can be objects of the domestic environment (boiler, refrigerator, door, lamp, alarm, car %), of the professional environment, or related to specific sectors of activity (health and medicine, well-being be and sport, factory and production tools, smart cities, energy and transport, etc.).
- These objects are usually called “connected objects” or “smart objects” (“smart objects” (“smart objects” in English). They can be objects of the physical world (eg a watch), but also virtual resources (eg an email account).
- ACL Access Control List
- RBAC Role Based Access Control
- IBAC Identity Based Access Control
- ABAC Attribute Based Access Control
- Capability Based Access Control where each object will accept or not the connection with other objects according to their capacity.
- a capability is a unique key (or token) that is associated only with a requesting object to enable it to perform certain actions on the requested object.
- This token is typically issued by a centralized entity in a complex manner where the actions authorized by the token and the validity period of the token and other conditions must be manually specified using a certain interface to generate and send this token.
- the present invention improves the situation.
- the present invention thus aims at a method of authorization management method in a community of connected objects, a master object being determined in said community, the method comprising:
- an internal object of the community being distinct from the master object
- a community is a coherent set of connected objects. This community can be automatic (eg all objects related to music, all objects related to home security, etc.). The community can also be manually defined by the user. In addition, belonging to a community does not exclude membership in another distinct community. To be part of a community, it is often necessary to have been authorized. In any case, a community in the sense of connected objects is a set of objects whose list is defined, this list being stored for example in a local or distributed database (ie it is not only a conceptual set objects). Most of the time, community objects have a special relationship of trust between them.
- the request for realization of an action targeting the community of connected objects can be in particular the fact of joining the community.
- the request for carrying out an action aimed at an internal object of the community can be in particular the fact of interacting with this internal object or of accessing one of the services it proposes.
- Attribute a feature associated with the object. This characteristic is often intrinsic to the object or its situation (eg telephone number, GPS position of the object, type of terminal, etc.). Attributes should not be confused with simple identifiers or roles that would be assigned to the object (see above).
- a "certified attribute” is an attribute whose accuracy has been certified by a trusted third party, most often called a certification authority. Certification is most often done by affixing a digital signature (eg asymmetrical cryptographic signature).
- An object's "capacity” is a set of permissions (possibly only one) describing the different actions / rights that this object has in a given context. For example, a given capacity can allow an object: - to broadcast music on a predetermined radio station between 7 am and 8 pm each day, or
- this ability takes the form of a token (or "token” in English) describing, in the form of bytes, the various actions / rights.
- This token is usually signed by a trusted authority (eg an attribute management server or more generally an authentication server or AS for “authentication server”).
- the authentication server can verify the certification of attributes and determine from a set of rules which capability to attribute based on the attributes. These capabilities can be predefined from defined and associated rules.
- the architecture proposed by the invention allows flexible rights management without excessive centralization.
- the authority having certified the attributes may be distinct from the authentication server. This thus allows a wide choice of certification authorities (or even the use of a plurality of certification authorities, each authority certifying a subset of the list of attributes transmitted to the authentication server).
- the invention proposes to avoid direct communication between the authentication server and the requesting object for security reasons. Indeed, it may be useful for a requesting object, third party to the network, not to be able to discover the address of the authentication server by conventional network discovery mechanisms.
- the method may further comprise:
- This new reception may occur after the transfer of said authentication token by the master object mentioned above.
- the requesting object instead of interacting directly with the internal object, the requesting object must address the master object. This is particularly useful if the internal object does not have the cryptographic capability to verify said authentication token containing the capability (eg, the internal object is a low-power door-opening sensor, without a dedicated processor and / or efficient).
- the "transmission of a message allowing said action in case of positive verification” can be a message sent directly to the internal object (ie activating the service) or a message sent to the requesting object specifying a secret or a code temporary / permanent authorization.
- This secret authorization code can be used (in a particular embodiment) only to access the internal object requested by the requestor, directly without intervention of the master object.
- the request for carrying out an action may be directed at joining the community, and the transmission of said message enabling said action may include transmission by the master object of a community token relating to said community.
- This community token can be used to allow the requesting object to join the community.
- the method may further comprise:
- update of a database stored on the master object upon reception of said community token by the master object, update of a database stored on the master object in order to add a new member to said community.
- This update can also update an attribute database that lists the attributes of the objects in the community.
- the community token can allow the requester access to internal objects that are public in the community. Some internal objects in the community may also be private: it may be necessary to specify a secret or a temporary / permanent authorization code.
- the request to perform an action may be to communicate with an internal object of the community and separate from the master object, and the transmission of said message allowing said action may include a transmission by the user. master object of an object token relative to said internal object.
- the receipt of the request may be from the requesting object.
- the transmission of said message allowing said action may further comprise an address of the internal object.
- the requesting object can directly address the internal object after receiving permission to interact with it.
- the receipt of the list of certified attributes can be done via the master object.
- receipt of the list of certified attributes can be done via at least one certification server, said certification server having certified at least one attribute of the list of attributes.
- the method may further comprise:
- This negotiation can be done via the master object.
- the method may further comprise:
- the invention also aims at an authorization management system in a community of connected objects, said system comprising
- an internal object of the community the internal object being distinct from the master object; in which the master object comprises:
- the authentication server comprises:
- the invention also relates to a device able to be connected and to be part of a community of connected objects.
- the device comprises:
- the processor is further adapted for:
- the invention also provides a method for executing an action relating to a device, said device being connected and forming part of a community of connected objects, wherein the method comprises:
- the invention also relates to a device that can be connected, in which the device comprises: an interface for receiving, from a master object of a community of connected objects, a first message, said first message containing a token of authentication having a capacity of said device determined according to a list of certified attributes;
- the invention also provides a method for executing an action, wherein the method comprises the following steps implemented by a requesting object:
- FIGS. 1a, 1b and 1c illustrate three embodiments of the determination of a capacity of a connected object
- FIGS. 2a, 2b and 2c illustrate three embodiments for using the capacity of a connected object.
- Figure 1a illustrates a first embodiment of determining a capacity of a connected object.
- a requesting object 1 01 wishes to interact with:
- the interaction of the requesting object with the community is typically the fact, for the requesting object, of asking to join the community thus formed.
- the interaction of the requesting object with another internal object of the community is typically the fact of requesting a content from the internal object (eg recovery of a status) or to access a service proposed by this internal object (eg music broadcast, request the opening of a door, etc.).
- the requesting object may be outside the community or internal to the community. this.
- the requesting object When the requesting object wishes to initiate this interaction, it sends a request 1 10 towards a so-called "master" object among the objects of the community 106.
- This master object has been previously defined either by a user or automatically (ex randomly, depending on availability, as a function of computing power, etc.).
- the requesting object does not know the master object of the community, it can send a broadcast request to obtain it, or randomly address a community member it already knows to get this information. This query is not represented here.
- multiple master objects can be defined per community to distribute the network / computing load.
- the master object 102 can transfer (message 11) the request to an authentication server 107.
- This authentication server 107 is most often located on the Internet. and can be shared between several communities. Thus, there is no reason, a priori, that this authentication server is formally part of the community 106.
- the authentication server can provide a list of authorization authorities. certification it accepts or are recognized (message 1 12) to the master object 102. The master object transfers (message 1 13) then this message to the requesting object.
- the requesting object can thus choose from this list of certification authority an authority which corresponds to it or with which it is already in contact. This choice is concretized by sending the message 1 14 containing the certification authority chosen to the master object.
- the master object transfers this choice (message 1 15) to the authentication server.
- the messages 1 1 1 to 1 1 5 (describing the negotiation of the certification authority) are optional here and can also be used in the other embodiments, in particular in those described in FIGS. 1b and 1c.
- the negotiation of the certification authority between the requesting object and the authentication server can be done directly without passing through the master object. If this choice of implementation makes it possible to avoid overloading the master object, it does not make it possible to preserve the identity of the authentication server.
- this choice may have been made directly in the message 1 10 in which the requesting object immediately proposes a certification authority without prior negotiation - if this proposal is suitable, the negotiation 1 12, 1 13, 1 14, 1 1 5 may not occur.
- the choice of the certification authority may consist in choosing a plurality certification authority 108 (eg the authentication server may choose from this plurality, or the authentication server may use each authority among this plurality to certify several different attributes).
- the authentication server may send a certification request (message 1 16) to the selected certification authority 108 requesting it to certify an attribute (the latter being determinable or indeterminate - that is, indicated in the certification request message or left free, the appropriate attribute then being chosen by the certification authority) relating to the requesting object.
- This attribute can be, for example, a phone number, a home address, a GPS position of the requesting object, etc.
- the authentication server wants certification of several attributes, it is possible to approach several different certification authorities (or a single certification authority if it can do so).
- the (or the, if any) certification authority can then contact the requesting object (message 1 17) to retrieve the attribute to be certified (message 1 1 8). This is especially useful if the attribute is likely to evolve over time. If the attribute is static and the CA already knows it, the messages 17 and 18 become optional.
- the CA may return the certified attribute (or the certified attributes, if any) to the authentication server (message 1 19).
- the authentication server can determine which (s) is the capability (capabilities) of the requesting object (the. or the actions allowed for the requesting object) by comparing the attribute or the list of attributes with a database of security rules (eg the database may contain "authorizing the opening of the garage door by objects having as attribute the phone number 06xxxxxxxx and a GPS position located within a radius of 300m around the house ").
- the requesting object will have the ability to authorize the opening of the garage door if the rule "the phone number is 06xxxxxxxx and the GPS position is within 300m of the house” is verified.
- Abilities and rules can be prerecorded for a given community. Abilities can be linked to one or more objects in the community to see all objects in the community.
- the token with the capacity can thus take the form of the following data structure:
- - id the identifier of the capacity token
- - ii the date of issue of the token (eg number of seconds since January 1, 1970)
- - is: the identification of the person who signed the token
- - ar the rights associated with the capacity
- - ac the description of the authorized action (eg GET, POST, PUT, DELETE)
- - c a set of conditions corresponding to the action (eg broadcasting of music only if no music is being broadcast),
- Figure 1b illustrates a second embodiment of determining a capacity of a connected object.
- the requesting object contacts a certification authority 108 (message 121) to transmit an attribute or a plurality of attributes to be certified.
- a certification authority 108 message 121
- a plurality of certification authorities can be used.
- the CA signs the attribute and returns it to the requesting object 101 (message Therefore, the requesting object can send its interaction request (message 123 - corresponding to the message 101 in the previous embodiment) to the master object, accompanied by the certified attribute.
- This request is then transferred (message 124) to the authentication server 107.
- the authentication server has a relationship of trust with the certification authority having certified the attribute transmitted (eg it has the public key of the certification authority): thus, the authentication server can verify that the signature of the attribute has been done by the certification authority that is indicated in the message 124. If no trust relationship exists between the certification authority and the authentication server, the authentication server: - may refuse the transaction by asking the requesting object to change the certification authority,
- - may request the CA to authenticate itself and / or communicate its public key in a secure manner (eg via a key management system known in the field of asymmetric encryption / signature).
- a certification authority may sign / certify one of its attributes (and that it has not changed / the certification is still valid), there is no need to exchange messages 121 and 122.
- Figure 1c illustrates a third embodiment of determining a capacity of a connected object.
- the message 130 (respectively 131) is identical / similar to the message 1 1 0 (respectively 1 1 1).
- the authentication server can request (message 132) from a certification authority 108 to certify an attribute associated with the requesting object (the certification authority in question may have been previously negotiated or be proposed in the message 131).
- the certification authority 108 addresses (message 133) to the requesting object so that it returns (message 134) the attribute to be certified.
- the attribute is sent (message 135) to the requesting object.
- the certified attribute can then be transferred to the authentication server via the master object 102 (messages 136 and 137).
- the authentication server can then check the signature of the attribute (ie the fact that the certification is correct) and determine the adequate capacity of the requesting object, that is to say the action or actions that it is authorized to perform.
- Figure 2a illustrates a first embodiment for using the capacity of a connected object.
- the server d After verification of the list of attributes by the authentication server 1 07 and determination of the capacity of the requesting object (see description relating to FIGS. 1a to 1c) according to said list of attributes, the server d The authentication sends a capacity token to the master object (message 201) and the master object sends it back to the requesting object (message 202). This token is signed by the authentication server.
- the messages 201 and 202 can be replaced by a single message between the authentication server and the requesting object.
- the requesting object may address (message 203) to the master object by requesting access to a service provided by a given internal object (eg object 103) or by requesting to join the community 106, joining the message 203 the signed token.
- a service provided by a given internal object (eg object 103) or by requesting to join the community 106, joining the message 203 the signed token.
- the master object can then verify that the token is valid and gives the right to perform the requested action (eg verification of the cryptographic / asymmetric signature). If the token is invalid or does not perform the requested action, the master object may send an error message to the requesting object (not shown here). If the request for message 203 is for joining community 106, the master object can update an internal database containing a list of community objects in order to add the requesting object as a new member of that community. . In addition, it is possible to update a database (the same as before or a different database) to indicate the attributes of the new member, for future reuse. Message exchanges can stop at this point.
- the master object can transfer the request to said internal object 1 03 (message 204) which responds to it (message 205) because the master object is well-known. This response is transferred (message 206) to the requesting object.
- An ability to join a community can be included in a "community" token.
- Figure 2b illustrates a second embodiment for using the capacity of a connected object.
- the message 21 1 (respectively 212, 213) is identical / similar to the message 201 (respectively 202, 203).
- the master object can verify that the capacity is valid and correctly confers the rights indicated therein. If the capacity is invalid or does not perform the requested action, the master object may send an error message to the requesting object (not shown here).
- the master object can indicate to the requesting object the address of the internal object 103 that is the subject of an interaction request.
- This address may be accompanied, for example, by a password (eg temporary) or an authentication token (eg certificate) to activate the service with the internal object.
- the requesting object can connect (message 215) to the internal object 103 using the password or the authentication token and thereby obtain the requested information (message 216).
- Fig. 2c illustrates a third embodiment for using the capacity of a connected object.
- the message 221 (respectively 222) is identical / similar to the message 201 (respectively 202).
- the requesting object connects directly (message 223) to the internal object 103, wishing to interact with the service of this internal object.
- message 223 the requesting object joins the object token (describing its transmitted capability in message 222).
- the internal object can ask the master object to check for it (message 224). Once verified, the result of this check is sent to the internal object (message 225), which then decides whether the requested interaction should be performed (message 226).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1660889A FR3058540A1 (fr) | 2016-11-10 | 2016-11-10 | Procede de gestion d'autorisation dans une communaute d'objets connectes |
PCT/FR2017/053063 WO2018087483A1 (fr) | 2016-11-10 | 2017-11-09 | Procédé de gestion d'autorisation dans une communauté d'objets connectes |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3539272A1 true EP3539272A1 (fr) | 2019-09-18 |
Family
ID=58314370
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP17808543.7A Pending EP3539272A1 (fr) | 2016-11-10 | 2017-11-09 | Procédé de gestion d'autorisation dans une communauté d'objets connectes |
Country Status (4)
Country | Link |
---|---|
US (1) | US11277396B2 (fr) |
EP (1) | EP3539272A1 (fr) |
FR (1) | FR3058540A1 (fr) |
WO (1) | WO2018087483A1 (fr) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SE1850155A1 (en) * | 2018-02-13 | 2019-08-14 | Fingerprint Cards Ab | Registration of data at a sensor reader and request of data at the sensor reader |
JP7289111B2 (ja) * | 2019-06-26 | 2023-06-09 | パナソニックIpマネジメント株式会社 | 通信装置、認証方法およびコンピュータプログラム |
US11580239B2 (en) * | 2019-10-22 | 2023-02-14 | Microsoft Technology Licensing, Llc | Controlling access to cloud resources in data using cloud-enabled data tagging and a dynamic access control policy engine |
US11627138B2 (en) | 2019-10-31 | 2023-04-11 | Microsoft Technology Licensing, Llc | Client readiness system |
US11310235B1 (en) * | 2021-08-04 | 2022-04-19 | Netfay Inc. | Internet of things system based on security orientation and group sharing |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9832026B2 (en) * | 2010-04-30 | 2017-11-28 | T-Central, Inc. | System and method from Internet of Things (IoT) security and management |
KR101453154B1 (ko) * | 2012-05-30 | 2014-10-23 | 모다정보통신 주식회사 | M2m 통신에서 리소스 접근 권한 설정 방법 |
US20150121470A1 (en) * | 2013-10-25 | 2015-04-30 | Qualcomm Incorporated | Peer-to-peer onboarding of internet of things (iot) devices over various communication interfaces |
EP2890073A1 (fr) * | 2013-12-31 | 2015-07-01 | Gemalto SA | Système et procédé pour sécuriser des communications machine-machine |
US9814084B2 (en) * | 2014-08-07 | 2017-11-07 | Belkin International Inc. | Location and pairing of devices on a local area network using a unique identifier |
US9801044B2 (en) * | 2014-05-13 | 2017-10-24 | Samsung Electronics Co., Ltd. | Apparatus and method for accessing wireless network |
US9699659B2 (en) * | 2014-07-31 | 2017-07-04 | Qualcomm Incorporated | On-boarding a device to a secure local network |
US10001759B2 (en) * | 2014-08-11 | 2018-06-19 | Qualcomm Incorporated | Method and apparatus for automatically generating an events dictionary in an internet of things (IOT) network |
WO2016192387A1 (fr) * | 2015-05-29 | 2016-12-08 | 乐鑫信息科技(上海)有限公司 | Procédé et système de configuration de l'internet des objets destiné à un dispositif de mandataire à faible consommation d'énergie sécurisé |
US10044674B2 (en) * | 2016-01-04 | 2018-08-07 | Afero, Inc. | System and method for automatic wireless network authentication in an internet of things (IOT) system |
GB2567591B (en) * | 2016-08-11 | 2021-09-22 | Reliance Jio Infocomm Ltd | Methods and systems for secure onboarding of devices over a wireless network |
-
2016
- 2016-11-10 FR FR1660889A patent/FR3058540A1/fr active Pending
-
2017
- 2017-11-09 US US16/345,795 patent/US11277396B2/en active Active
- 2017-11-09 EP EP17808543.7A patent/EP3539272A1/fr active Pending
- 2017-11-09 WO PCT/FR2017/053063 patent/WO2018087483A1/fr unknown
Also Published As
Publication number | Publication date |
---|---|
US11277396B2 (en) | 2022-03-15 |
WO2018087483A1 (fr) | 2018-05-17 |
FR3058540A1 (fr) | 2018-05-11 |
US20190268328A1 (en) | 2019-08-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3539272A1 (fr) | Procédé de gestion d'autorisation dans une communauté d'objets connectes | |
EP3568794B1 (fr) | Procédés et systèmes pour l'exécution de contrats intelligents dans des environnements sécurisés | |
Fan et al. | Diam-iot: A decentralized identity and access management framework for internet of things | |
EP2491735B1 (fr) | Dispositif et procédé de gestion des droits d'accès à un réseau sans fil | |
US20130061055A1 (en) | Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones | |
CA2971647A1 (fr) | Methode de traitement d'une autorisation de mise en oeuvre d'un service, dispositifs et programme d'ordinateur correspondant | |
EP0800300A1 (fr) | Vérification d'intégrité des réquêtes dans un réseau client serveur | |
EP1911194A1 (fr) | Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants | |
FR2864289A1 (fr) | Controle d'acces biometrique utilisant un terminal de telephonie mobile | |
EP1646176A2 (fr) | Attribution d'une autorisation d'accès à une ressource | |
EP3857413A1 (fr) | Procede de traitement d'une transaction, dispositif, systeme et programme correspondant | |
CN116980163A (zh) | 基于可信执行环境的数据处理方法、装置、设备及介质 | |
EP3568965A1 (fr) | Procédé d'authentification en deux étapes, dispositif et programme d'ordinateur correspondant | |
WO2002097751A1 (fr) | Procédé et dispositif de certification d'une transaction | |
EP3479325B1 (fr) | Procédé d'authentification de données de paiement, dispositifs et programmes correspondants. | |
CA3100170A1 (fr) | Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede | |
FR3073998B1 (fr) | Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur | |
WO2006021665A1 (fr) | Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat | |
EP2911365B1 (fr) | Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation | |
WO2024096914A1 (fr) | Partage de documents et de données basé sur une chaîne de blocs | |
CN115967495A (zh) | 基于区块链的公益应用管理方法和装置 | |
OA20002A (fr) | Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé. | |
FR2880488A1 (fr) | Procede d'authentification d'un terminal | |
Laginski | Peer to peer role based authentication within JXTA | |
WO2017060624A1 (fr) | Moyens de gestion d'accès à des données |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
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 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20190425 |
|
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 |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: ORANGE |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20200819 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: ORANGE |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |