EP2529506B1 - Contrôle d'accès - Google Patents

Contrôle d'accès Download PDF

Info

Publication number
EP2529506B1
EP2529506B1 EP11701533.9A EP11701533A EP2529506B1 EP 2529506 B1 EP2529506 B1 EP 2529506B1 EP 11701533 A EP11701533 A EP 11701533A EP 2529506 B1 EP2529506 B1 EP 2529506B1
Authority
EP
European Patent Office
Prior art keywords
token
access
issuer
receiver entity
key
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.)
Active
Application number
EP11701533.9A
Other languages
German (de)
English (en)
Other versions
EP2529506A2 (fr
Inventor
Trevor Burbridge
Andrea Soppera
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.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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 British Telecommunications PLC filed Critical British Telecommunications PLC
Priority to EP11701533.9A priority Critical patent/EP2529506B1/fr
Publication of EP2529506A2 publication Critical patent/EP2529506A2/fr
Application granted granted Critical
Publication of EP2529506B1 publication Critical patent/EP2529506B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention relates to apparatus, systems and methods for controlling access to information systems. More specifically, aspects of the present invention relate to apparatus, systems and methods for enabling access to one or more information systems by one or more entities on a path across a supply network to be controlled.
  • Radio Frequency IDentification is an emerging technology for use within supply chains to tag and track individual products.
  • RFID Radio Frequency IDentification
  • Each of a number of products (or assets such as transportation items, including boxes, pallets, roll cages etc.) can be given a unique serialised identifier which is stored within the RFID tag and can be read by other parties.
  • Each organisation can collect such product information and store it within its own data services (such as an EPCIS or "Electronic Product Code Information Service”) and use this information to optimise it own internal operations.
  • a challenge involves how one organisation can establish such access rights to its own data for external organisations. This is particularly problematic because appropriate access control may need to be both fine-grained and dynamic.
  • the access control may need to be fine-grained because individual products may flow along different paths through an end-to-end supply chain.
  • the access control may need to be dynamic because it is often impossible to define such access rights before the operation of the supply chain.
  • a distributor for example, may not know in advance which serialised products it will be receiving, and hence which data it will need access to from a manufacturer. Further, the distributor may not know which products it will then distribute to individual retailers, and hence which information it must share with such retailers.
  • an RFID tag's memory may be used to store a reference at which a receiving system could automatically apply for access rights to the serialised data concerning the item to which the RFID tag was affixed. Such a reference is referred to as an 'invitation'.
  • the receiving system may use the invitation to contact a token-issuing system. After passing a number of tests (potentially including authenticating the receiving system's identity, confirming that the item has been shipped to the receiver and authenticating the validity of the RFID tag containing the invitation) a token may be issued to the receiving system that can then be used to access a number of serialised information systems.
  • EP 08 253 008 filed by the present applicant on 12th September 2008 and later published as EP 2 166 493 discusses the use of proxy re-encryption technology for securing supply chains.
  • the re-encryption may be used to translate a signature on a tag which is used to validate that the tag has travelled via an authorised supply path.
  • United States patent application US2008/0164976 (“Griffiths-Harvey”) discloses an authenticated RFID system that uses elliptic curve cryptography (ECC) to reduce the signature size and read/write times when compared to traditional public key implementations such as "RSA", a well-known public-key cryptography algorithm first (publicly) described by Rivest, Shamir and Adleman.
  • ECC elliptic curve cryptography
  • Different digital signature schemes and algorithms can be used to reduce the signature size and hide a portion of an RFID tag that contains sensitive product identifying information.
  • smaller tags can be used or multiple signatures can be written at different stages in a manufacturing or supply chain.
  • a key management system may be used to distribute the verification keys and aggregate signature schemes may be provided for adding multiple signatures to the RFID tags, for example in a supply chain.
  • control apparatus for enabling access to one or more information systems by one or more entities on a path across a supply network to be controlled, access to the or each information system being policed by means of an access-policer, the network comprising: at least one token-issuer operable to issue an access pre-authorisation token, said access pre-authorisation token having associated therewith an information identifier and a digital signature, and to forward said access pre-authorisation token towards one or more entities on a path across said network; and at least one receiver entity operable to receive an access pre-authorisation token issued by said at least one token-issuer; the control apparatus comprising:
  • the key distributor may be further operable to distribute to said at least one receiver entity the receiver entity public key generated in respect of said at least one receiver entity.
  • a receiver entity may attempt to decrypt pre-authorisation tokens received from a token issuer, thereby ensuring that these have been correctly issued in respect of the information concerned by the expected token issuer. This can prevent the receiver entity from attempting to request access to information systems using incorrectly issued or otherwise invalid tokens.
  • the access pre-authorisation token and/or the digital signature may be stored in a memory component of the information identifier with which said token is associated, or they may be associated with the information identifier in other ways as will be discussed below.
  • Information identifiers themselves may identify one or more particular information systems (i.e. information systems in respect of which the token issuer is trusted to grant access). Alternatively or additionally, information identifiers may identify one or more particular items (products, for example) in relation to which the information identifiers are intended to be associated. It should be noted that in some scenarios, a particular receiver entity may only attempt to access one information system, in which case information identifiers would generally only need to identify the item(s) concerning which information may be requested.
  • information identifiers may be stored in the memory of radio-frequency identification devices (i.e. "RFID tags").
  • RFID tags radio-frequency identification devices
  • Electronic manifest may be carried on a memory device (such as an RFID tag, memory stick, Wi-fi or Bluetooth memory device) or may be released by a courier from a laptop or palm computer, for example.
  • the token translation key generated in respect of a particular receiver entity is preferably generated in dependence on the token-issuer private key of the key-pair generated in respect of the token-issuer and in dependence on the receiver entity private key generated in respect of said at least one receiver entity.
  • the token-issuer public key generated in respect of a particular token-issuer enables a digital signature guaranteeing the authenticity of a message created using a receiver-entity private key associated with said at least one receiver entity then translated using a token translation key generated in respect of said at least one receiver entity to be verified.
  • the token-issuer public key generated in respect of a particular token-issuer preferably enables a digital signature guaranteeing the authenticity of a message created using a receiver entity private key associated with said at least one receiver entity then translated using a token translation key generated in respect of said at least one receiver entity to be verified in the event that said receiver entity private key generated in respect of said receiver entity has been distributed to said token-issuer.
  • the token-issuer may be operated under the control of an entity trusted by the access policer of one or more information systems to grant access to said one or more information systems.
  • receiver entities there may be plurality of receiver entities, which may each be operable to receive access pre-authorisation tokens issued by a common token-issuer, or, where a plurality of token issuers are present, respective receiver entities may be operable to receive access pre-authorisation tokens issued by a different token-issuers.
  • Apparatus, systems and methods according to preferred embodiments may be used to allow fine-grained dynamic access control rights to be established automatically as a result of the supply chain operation. This can enable the immediate access to required data without the burden or costs of manually establishing such access rights.
  • apparatus, systems and methods according to preferred embodiments can be used to allow security tokens to be issued locally within the receiver premises, for example, and without requiring the use of specialist secure RFID tags.
  • Apparatus, systems and methods according to preferred embodiments may allow part-generated security tokens to be included within the user memory of, or otherwise associated with RFID tags or other appropriate types of identification devices, which may be attached to or otherwise associated with shipments of goods, for example. Such part-generated tokens may then be "completed” by a receiving party, thereby generating a final authorisation token that may be used in accessing an information system such as the shipping system of an upstream supply chain partner.
  • a part-generated token as a "pre-authorisation token” and a token whose authorisation has been completed by the receiver as a "final authorisation token”. It can be ensured that such a token cannot be generated by a receiver until it has received the initial pre-authorisation token.
  • Apparatus, systems and methods according to preferred embodiments may allow generation of tokens allowing access to secure serialised information services to occur completely within organisations that have received, are receiving, or will receive particular products. This may remove the burden of issuing such tokens from upstream supply chain partners holding the serialised information, along with the requisite communications facilities and costs involved.
  • an RFID tag carries only an initial 'invitation' or reference to the token issuing system, with a view to addressing the problem of unknown downstream supply chain players obtaining serial-level information.
  • a pre-authorisation token which, once distributed appropriately, may then be combined with a further secret possessed by a receiving organisation to generate a final, "usable” authorisation token.
  • Pre-authorisation tokens may be arranged to allow the generation of a valid final authorisation token only by the (or an) intended receiving system. Another system "eavesdropping" or reading a pre-authorisation token will not be able to generate the final authorisation token. Further, it may be arranged that even the (or an) intended receiver may not be able to generate the final authorisation token until it has actually received the associated goods and obtained the pre-authorisation token.
  • Preferred embodiments may thus be of particular use in relation to the automatic establishment of access rights for known downstream participants.
  • Public-key cryptography is a cryptographic approach which involves the use of asymmetric key algorithms instead of or in addition to symmetric key algorithms. Unlike symmetric key algorithms, it does not generally require a secure initial exchange of secret keys between a sender and a receiver.
  • the asymmetric key algorithms may be used to create a mathematically related key-pair, comprising a secret "private key” and a published "public key”. Use of these keys allows protection of the authenticity of a message by creating a "digital signature" of a message using the private key, the authenticity of which can be verified using the public key.
  • a reverse process known as public key encryption, allows protection of the confidentiality and integrity of a message; according to this process, a message is encrypted using the public key, and can then only be decrypted using the private key - this reverse process is of less relevance to the following explanation however.
  • a digital signature can thus be used to demonstrate the authenticity of a digital message or document.
  • a valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit.
  • Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery and tampering.
  • an issue of particular importance from the above summary of public-key cryptography is that for a public key / private key pair (i.e. a key-pair comprising a public key and a private key), the public key enables a digital signature guaranteeing the authenticity of a message created using the private key to be verified.
  • a proxy re-signature process is a process wherein a proxy is given information allowing it to transform the digital signature of a first entity (i.e. "Alice", in the example of Figure 1 ) into the digital signature of a second entity (i.e. "Bob").
  • Proxy re-signing allows this to be achieved without the proxy needing to have control of or access to the private keys associated with either Alice or Bob, therefore it cannot generate the digital signature for either Alice or Bob itself.
  • the proxy 12 translates a perfectly-valid and publicly-verifiable signature from Alice 10 into one from Bob 14. Given a message ' m 'and signing that message with Alice's secret private key generates a signature K s _ a (m) , whereas signing the same message with Bob's secret private key generates signature Ks _ b(m) . (It will be noted that the subscript "s” is used in symbolising (" s ecret") private keys K s ... in order to distinguish from the subscript "p” which will be used in symbolising " p ublic” keys K p . ..
  • a proxy In the proxy re-signature scheme, a proxy would receive the signature K s_a (m) from Alice and, by using a " t ranslation key" K t_a ⁇ b, it can convert the signature from Alice into a valid signature K s _ b (m) from Bob. This can be written as follows: K t _ ⁇ a ⁇ b K s _ ⁇ a m ⁇ K s _ ⁇ b m where:
  • proxy re-signature A property of proxy re-signature is that the "translation" from one signature to another can be performed in sequence and multiple times by distinct proxies without requiring the intervention of the signing entities (i.e. the owners of the private keys). In this way, the private keys can always remain offline and protected. All the signatures are publicly verifiable signatures as if they were signed by the real owner of the distinct entities.
  • a unidirectional scheme i.e. one that would allow the translation of a signature from Alice to one from Bob, but not from a signature from Bob to one from Alice.
  • this corresponds to the translation of a token signed using the private key of the receiver into a token that is identical to one signed using the private key of the pre-authorisation token issuer. This is shown in Figure 2 .
  • the re-signature key is generally expected to be known only to the product receiver who creates the final authorisation token.
  • the re-signature key is used to perform a "translation" function (i.e. translation of a token signed using the private key of one entity into a token that is identical to one signed using the private key of another entity), thus the term “translation key” will be used instead if the term "re-signature key” in the following explanation, although the terms are in fact interchangeable.
  • the supply chain control system 30 may be implemented in one or more computer systems.
  • the supply chain control system 30 is able to communicate with one or more pre-authorisation token issuers (symbolised by the letter T) 32, one or more receivers (symbolised as R1, R2, ..., R n ) 34, and with one or more information system (symbolised as IS1, IS2, ..., IS n ) 36.
  • pre-authorisation token issuers symbolised by the letter T
  • receivers symbolised as R1, R2, ..., R n
  • IS1, IS2, ..., IS n information system
  • the supply chain control system 30 has stored therein (i.e. in a memory component, for example) a supply chain model 310, indicating to the controller possible relationships between the other entities, such as which token issuer(s) is/are permitted to enable which receiver(s) to access which information system(s).
  • the supply chain control system 30 also contains a functional component which will be referred to as a Key Generator 320 whose function is to generate public/private key-pairs and token translation keys as appropriate, and a functional component which will be referred to as a Key Distributor 330, whose function is to distribute keys generated by the Key Generator 320 to the pre-authorisation token issuer(s) 32, the receiver(s) 34, and the information system(s) 36.
  • the supply chain control system 30 is also shown as having a "rubbish bin" 340. This need not be an actual component of the controller 30 - it is symbolised in Figure 3 (and in Figure 4 , to be discussed later) in order to indicate that not all of the keys generated by the Key Generator 320 are subsequently distributed by the Key Distributor 330. In preferred embodiments, as will be understood, one category of key is preferably used only by the controller itself, and may then be destroyed, rather than distributed to any other entity.
  • the communication between the supply chain control system 30 and the other entities generally involves key distribution and is indicated in Figure 3 by wide, dotted-line framed arrows. This may be performed by means of the Internet, or using any of a variety of communication techniques, and is such that the supply chain control system 30 is operable to distribute appropriate keys (directly or indirectly) to each of the other entities, as will be described later.
  • a different type of exchange, involving tokens, takes place between the other entities 32, 34, 36 themselves.
  • Tokens (of a first type, namely pre-authorisation tokens) may pass from a token issuer 32 to a receiver 34 by virtue of being stored in, attached to, or otherwise associated with items traversing a supply chain, for example, and tokens (of a second type, namely final authorisation tokens) may then be provided by a receiver 34 to an information system 36.
  • Exchanges involving tokens are indicated in Figure 3 by single-line arrows.
  • FIG 4 illustrates how the various keys may be distributed.
  • just one receiver R1 is shown.
  • This receiver R1 is shown as receiving pre-authorisation tokens from just one pre-authorisation token issuer T, and attempting to gain access to just one information system IS (although as explained in relation to Figure 3 earlier, there will in general be more than one receiver in a supply chain, and there may be more than token issuer and more than one information system).
  • a supply chain control system 30 creates a set of keys associated with the (or with each, if there are more than one) pre-authorisation token issuer 32.
  • One or more private/public key pairs are generated for each receiving system 34 to which access may be granted to the relevant information system(s) 36.
  • a private (or "secret") key K s _ R1 and a public key K p_R1 are generated, and for a second receiver organisation "Receiver R2" (not shown in Figure 4 ), a private key K s_ R2 and a public key K p _ R2 would be generated.
  • a further private/public key pair [K s_ T, K p_ T ] is also generated in respect of the pre-authorisation token issuer T, but it will be noted that neither key is sent thereto (the manner in which this key-pair is used is explained below).
  • a token translation key is produced, which may be used for translation (i.e. proxy re-signing) of a digital signature created using the private key generated in respect of that receiver into a digital signature associated with the pre-authorisation token issuer, and which is trusted by the information system(s) in question (or by an access policer 38 acting on its/their behalf) when deciding whether to grant access to the information system(s) in question.
  • token translation key K t_ R1 ⁇ T is produced for "Receiver R1”
  • token translation key K t_ R2 ⁇ T is produced for "Receiver R2”, etc.
  • Each token translation key is then distributed to the relevant receiver organisation 34 that may access the information system(s) 36, along with the public key for that organisation. It should be noted that the associated private key for each receiver organisation is not distributed to the organisation in question, but is instead sent to the pre-authorisation token issuer 32.
  • the public key K p_ T for the pre-authorisation token issuer 32 is distributed to any information system 36 for which the pre-authorisation token issuer is generating access tokens.
  • the token translation key generated in respect of a particular receiver is generally generated in dependence on the private key that has been generated in respect of the token-issuer concerned and in dependence on the private key that has been generated in respect of that receiver.
  • the private key K s _ T generated in respect of the token issuing system 32 is thus used by the controller 30 in producing the respective token translation keys K t _R1 ⁇ T for "Receiver R1" and K t_ R2 ⁇ T for "Receiver R2”, but the token issuer private key K s_ T does not need to be disseminated to any other entity at any stage in the procedure, and may therefore be destroyed by the controller 30 (as indicated by the arrow to the rubbish bin referred to in Figure 3 ).
  • the information system 36 in Figure 4 is shown as having an access policer 38 component within it. This is shown in order to illustrate that in addition to its function of providing information, information system 36 performs a policing function whereby a decision is first taken as to whether or not to grant requests for access to the information system in question.
  • the access policer 38 component may be a part of the information system 36 itself, or may be an external component, and need not in fact be performed under the control of the same organisation as the information system.
  • the supply chain control system 30 may be operated by the same organisation as the information system(s) 36, or may be operated by a trusted third party, for example.
  • Information systems may however be under the control of or acting on behalf of organisations other than those under whose control the supply chain controller is being operated; they may be under the control of organisations responsible for the provision of goods, for example.
  • the pre-authorisation token issuer generates a signed pre-authorisation token for the product or asset identifier contained within or otherwise associated with an item identifier (such as an RFID tag).
  • an item identifier such as an RFID tag.
  • this token is the identifier encrypted with a private key associated with the intended receiver, although other information may be included, as will be explained later.
  • This pre-authorisation token is then stored in the user memory of the RFID tag (or other such associated item identifier).
  • the token can also include a further unencrypted identifier which can be used to identify the issuing party who created the pre-authorisation token, for example.
  • This shipping process may then be performed involving the following steps:
  • the receiver When the product or asset is received, the receiver reads the pre-authorisation token from the user memory of the tag, incorporating the identifier of the pre-authorisation token issuer. This identifier is used to retrieve the correct a token translation key (since there may be many pre-authorisation token issuing systems).
  • the pre-authorisation token may be decrypted using the public key of the receiving organisation related to the token issuer. In this manner the receiving organisation can check that the pre-authorisation token is genuine for the product identifier and has been issued by the expected token issuer. This prevents the receiving organisation from requesting access to information systems with invalid tokens.
  • the pre-authorisation token is then re-encrypted with the token translation key. This produces the final authorisation token which can be validated using the public key of the pre-authorisation token issuer (where validation involves decrypting the token with the public key to obtain an identifier that matches the product identifier).
  • the receiving process may thus be performed as follows:
  • the receiver may now attempt to access the information systems of the shipper.
  • the client in the receiving organisation includes the final authorisation token in the information request for product or asset information.
  • the information system decrypts the final authorisation token using the public key Kp_T of the pre-authorisation token issuer. This may be assisted by including the pre-authorisation token issuer identifier unencrypted within the token. If the product identifier retrieved from within the token corresponds to the identifier requested by the client and the token issuer is trusted to release access for such an identifier, then the access is allowed to proceed.
  • the information system access control process may be as summarised below:
  • the pre-authorisation token issuer will commonly belong to the same organisation as the information systems for which it is producing pre-authorisation tokens. However, the information system organisation may also trust other parties to produce pre-authorisation tokens. In this manner they can delegate the control of access to their information systems to other parties. In order to trust a pre-authorisation token issuer they add the issuer's public key to the list of keys that are permitted to validate authorisation tokens during the information access.
  • the token may also be included in the token.
  • Other common types of information may include an expiry date for the token. In this case even if the token is validated using the public key of the pre-authorisation token issuer, the information access will not be allowed to proceed if the token has expired.
  • the pre-authorisation token issuer may also include other restrictions on the information access by placing additional policy constraints within the token. For example the token may also include the constraint that the information record must be of the type " shipping ". When the information system decrypts the security token it may then apply any such restrictions.
  • a particularly simple option is simply to include each receiver as an entity in the supply chain model 310 of the controller 30. A separate token may then be generated for each discrete receiver entity 34.
  • An single item identifier such as an RFID tag may carry several pre-authorisation tokens for a number of receivers to be able to generate their own final authorisation tokens. This approach has the drawback that multiple tokens will generally require additional memory space, which may be a problem with some types of RFID tag or other item identifiers.
  • An alternative approach is to group multiple receivers into sets. Each set may then be allocated a public/private key pair within the supply chain model 310 of the controller 30. A pre-authorisation token which is to be shared between receiver entity A and entity B may be signed using the private key for the set A+B. Both A and B receive the same translation key to be able to generate the final authorisation token.
  • the receiver A may simply inform receiver B of the correct translation key required in order to generate the final authorisation key. This enables B to generate final authorisation tokens for any goods destined for receiver A. If/when this delegation is revoked, the controller 30 may then need to generate new keys for receiver A (along with new translation keys) and distribute these to the token issuer and receiver A.
  • receiver A Another alternative is for receiver A to generate the final authorisation token and share this over a secure communications network with receiver B.
  • receiver A retains the confidentiality of its keys and can delegate the tokens on a per-item basis, for example.
  • receiver A may operate its own pre-authorisation token issuer.
  • the original pre-authorisation token may be replaced with one generated by the pre-authorisation token issuer of receiver A.
  • the public key of receiver A's token issuer may then be added to the trusted list of the information service.

Claims (15)

  1. Appareil de commande destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'information par une ou plusieurs entités sur un chemin à travers un réseau de fourniture, l'accès au ou à chaque système d'information étant contrôlé au moyen d'un contrôleur d'accès, le réseau comprenant : au moins un émetteur de jetons exploitable de manière à émettre un jeton d'autorisation préalable d'accès, ledit jeton d'autorisation préalable d'accès étant associé à un identifiant d'informations et à une signature numérique, et exploitable de manière à acheminer ledit jeton d'autorisation préalable d'accès vers une ou plusieurs entités sur un chemin à travers ledit réseau ; et au moins une entité réceptrice exploitable de manière à recevoir un jeton d'autorisation préalable d'accès émis par ledit au moins un émetteur de jetons ;
    l'appareil de commande comprenant :
    un générateur de clés exploitable de manière à générer, en ce qui concerne ladite au moins une entité réceptrice :
    (i) une paire « clé publique / clé privée » d'entité réceptrice comprenant une clé publique et une clé privée, la clé publique d'entité réceptrice permettant que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant la clé privée d'entité réceptrice ; et
    (ii) une clé de traduction de jetons, ladite clé de traduction de jetons permettant la traduction d'une signature numérique, créée en utilisant une clé privée générée en ce qui concerne ladite au moins une entité réceptrice, en une signature numérique associée à l'émetteur de jetons ;
    le générateur de clés étant en outre exploitable de manière à générer, en ce qui concerne ledit au moins un émetteur de jetons :
    (iii) une paire « clé publique / clé privée » d'émetteur de jetons, ladite clé publique d'émetteur de jetons permettant que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant ladite clé privée d'émetteur de jetons ;
    l'appareil de commande comprenant en outre un distributeur de clés exploitable de manière à distribuer :
    audit au moins un émetteur de jetons, la clé privée d'entité réceptrice générée en ce qui concerne ladite au moins une entité réceptrice ;
    à ladite au moins une entité réceptrice, la clé de traduction de jetons générée en ce qui concerne ladite au moins une entité réceptrice ; et
    audit contrôleur d'accès, ladite clé publique d'émetteur de jetons.
  2. Appareil de commande selon la revendication 1, dans lequel ledit distributeur de clés est en outre exploitable de manière à distribuer, à ladite au moins une entité réceptrice, la clé publique d'entité réceptrice générée en ce qui concerne ladite au moins une entité réceptrice.
  3. Appareil de commande selon la revendication 1 ou 2, dans lequel ledit jeton d'autorisation préalable d'accès est stocké au sein d'un composant de mémoire de l'identifiant d'informations auquel ledit jeton est associé.
  4. Appareil de commande selon la revendication 1, 2 ou 3, dans lequel ladite signature numérique est stockée au sein d'un composant de mémoire de l'identifiant d'informations auquel ledit jeton est associé.
  5. Appareil de commande selon l'une quelconque des revendications précédentes, dans lequel ledit identifiant d'informations est stocké sur un dispositif d'identification par radiofréquence.
  6. Appareil de commande selon l'une quelconque des revendications précédentes, dans lequel ladite clé de traduction de jetons générée en ce qui concerne une entité réceptrice spécifique est générée en fonction de la clé privée d'émetteur de jetons de la paire de clés générée en ce qui concerne l'émetteur de jetons.
  7. Appareil de commande selon l'une quelconque des revendications précédentes, dans lequel ladite clé de traduction de jetons générée en ce qui concerne une entité réceptrice spécifique est générée en fonction de la clé privée d'entité réceptrice générée en ce qui concerne ladite au moins une entité réceptrice.
  8. Appareil de commande selon l'une quelconque des revendications précédentes, dans lequel ladite clé publique d'émetteur de jetons générée en ce qui concerne un émetteur de jetons spécifique permet que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant une clé privée d'entité réceptrice associée à ladite au moins une entité réceptrice, traduite ensuite en utilisant une clé de traduction de jetons générée en ce qui concerne ladite au moins une entité réceptrice.
  9. Appareil de commande selon la revendication 8, dans lequel ladite clé publique d'émetteur de jetons générée en ce qui concerne un émetteur de jetons spécifique permet que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant une clé privée d'entité réceptrice associée à ladite au moins une entité réceptrice, traduite ensuite en utilisant une clé de traduction de jetons générée en ce qui concerne ladite au moins une entité réceptrice, dans le cas où ladite clé privée d'entité réceptrice générée en ce qui concerne ladite entité réceptrice a été distribuée audit émetteur de jetons.
  10. Appareil de commande selon l'une quelconque des revendications précédentes, dans lequel ledit émetteur de jetons est sous la commande d'une entité en laquelle a confiance le contrôleur d'accès d'un ou plusieurs systèmes d'information, en vue d'octroyer l'accès audit un ou auxdits plusieurs systèmes d'information.
  11. Appareil de commande selon l'une quelconque des revendications précédentes, destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'une pluralité de systèmes d'information, l'accès auxdits systèmes d'information étant contrôlé au moyen de contrôleurs d'accès respectifs.
  12. Appareil de commande selon l'une quelconque des revendications précédentes, destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'information par une ou plusieurs entités sur un chemin à travers un réseau de fourniture, ledit réseau comprenant une pluralité d'émetteurs de jetons qui sont exploitables chacun de manière à émettre des jetons d'autorisation préalable d'accès.
  13. Appareil de commande selon l'une quelconque des revendications précédentes, destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'information par une ou plusieurs entités sur un chemin à travers un réseau de fourniture, ledit réseau comprenant une pluralité d'entités réceptrices qui sont exploitables chacune de manière à recevoir des jetons d'autorisation préalable d'accès émis par un émetteur de jetons.
  14. Système destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'information par une ou plusieurs entités sur un chemin à travers un réseau de fourniture, l'accès au ou à chaque système d'information étant contrôlé au moyen d'un contrôleur d'accès, le système comprenant :
    l'appareil de commande selon l'une quelconque des revendications précédentes;
    au moins un émetteur de jetons exploitable de manière à émettre un jeton d'autorisation préalable d'accès, ledit jeton d'autorisation préalable d'accès étant associé à un identifiant d'informations et à une signature numérique, et exploitable de manière à acheminer ledit jeton d'autorisation préalable d'accès vers une ou plusieurs entités sur un chemin à travers ledit réseau ; et
    au moins une entité réceptrice exploitable de manière à recevoir un jeton d'autorisation préalable d'accès émis par ledit au moins un émetteur de jetons ; dans lequel :
    ledit au moins un émetteur de jetons est exploitable de manière à recevoir une clé privée d'entité réceptrice générée par l'appareil de commande en ce qui concerne ladite au moins une entité réceptrice, à signer ledit jeton d'autorisation préalable d'accès au moyen d'une signature numérique, en utilisant ladite clé privée d'entité réceptrice, et à acheminer ledit jeton d'autorisation préalable d'accès signé vers ladite au moins une entité réceptrice ;
    ladite au moins une entité réceptrice est exploitable de manière à recevoir une clé de traduction de jetons générée par l'appareil de commande en ce qui concerne ladite au moins une entité réceptrice, à signer à nouveau ledit jeton d'autorisation préalable d'accès signé au moyen d'une signature numérique, en utilisant ladite clé de traduction de jetons, et à fournir ledit jeton à nouveau signé audit contrôleur d'accès ; et
    ledit contrôleur d'accès est exploitable de manière à recevoir une clé publique d'émetteur de jetons générée par l'appareil de commande, à vérifier l'authenticité de la signature numérique sur ledit jeton à nouveau signé, en utilisant ladite clé publique d'émetteur de jetons, et à permettre, à ladite au moins une entité réceptrice, l'accès audit un ou auxdits plusieurs systèmes d'information en fonction de ladite vérification.
  15. Procédé destiné à permettre que soit autorisé l'accès à un ou plusieurs systèmes d'information par une ou plusieurs entités sur un chemin à travers un réseau de fourniture, l'accès au ou à chaque système d'information étant contrôlé au moyen d'un contrôleur d'accès, le réseau comprenant : au moins un émetteur de jetons exploitable de manière à émettre un jeton d'autorisation préalable d'accès, ledit jeton d'autorisation préalable d'accès étant associé à un identifiant d'informations et à une signature numérique, et exploitable de manière à acheminer ledit jeton d'autorisation préalable d'accès vers une ou plusieurs entités sur un chemin à travers ledit réseau ; et au moins une entité réceptrice exploitable de manière à recevoir un jeton d'autorisation préalable d'accès émis par ledit au moins un émetteur de jetons ;
    le procédé comprenant les étapes ci-dessous consistant à :
    générer, en ce qui concerne ladite au moins une entité réceptrice :
    (i) une paire « clé publique / clé privée » d'entité réceptrice comprenant une clé publique et une clé privée, la clé publique d'entité réceptrice permettant que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant la clé privée d'entité réceptrice ; et
    (ii) une clé de traduction de jetons, ladite clé de traduction de jetons permettant la traduction d'une signature numérique, créée en utilisant une clé privée générée en ce qui concerne ladite au moins une entité réceptrice, en une signature numérique associée à l'émetteur de jetons ;
    générer, en ce qui concerne ledit au moins un émetteur de jetons :
    (iii) une paire « clé publique / clé privée » d'émetteur de jetons, ladite clé publique d'émetteur de jetons permettant que soit vérifiée une signature numérique garantissant l'authenticité d'un message, créée en utilisant ladite clé privée d'émetteur de jetons ;
    distribuer, audit au moins un émetteur de jetons, la clé privée d'entité réceptrice générée en ce qui concerne ladite au moins une entité réceptrice ;
    distribuer, à ladite au moins une entité réceptrice, la clé de traduction de jetons générée en ce qui concerne ladite au moins une entité réceptrice ; et
    distribuer, audit contrôleur d'accès, ladite clé publique d'émetteur de jetons.
EP11701533.9A 2010-01-29 2011-01-14 Contrôle d'accès Active EP2529506B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP11701533.9A EP2529506B1 (fr) 2010-01-29 2011-01-14 Contrôle d'accès

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP10250145A EP2355402A1 (fr) 2010-01-29 2010-01-29 Contrôle d'accès
PCT/GB2011/000047 WO2011092451A2 (fr) 2010-01-29 2011-01-14 Commande d'accès
EP11701533.9A EP2529506B1 (fr) 2010-01-29 2011-01-14 Contrôle d'accès

Publications (2)

Publication Number Publication Date
EP2529506A2 EP2529506A2 (fr) 2012-12-05
EP2529506B1 true EP2529506B1 (fr) 2015-01-28

Family

ID=42712700

Family Applications (2)

Application Number Title Priority Date Filing Date
EP10250145A Ceased EP2355402A1 (fr) 2010-01-29 2010-01-29 Contrôle d'accès
EP11701533.9A Active EP2529506B1 (fr) 2010-01-29 2011-01-14 Contrôle d'accès

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP10250145A Ceased EP2355402A1 (fr) 2010-01-29 2010-01-29 Contrôle d'accès

Country Status (4)

Country Link
US (1) US8781130B2 (fr)
EP (2) EP2355402A1 (fr)
CN (1) CN102792633B (fr)
WO (1) WO2011092451A2 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2623724C2 (ru) * 2010-08-24 2017-06-28 Конинклейке Филипс Электроникс Н.В. Основанные на атрибутах цифровые подписи
US11361174B1 (en) * 2011-01-17 2022-06-14 Impinj, Inc. Enhanced RFID tag authentication
FR2982059A1 (fr) * 2011-10-28 2013-05-03 France Telecom Systeme de lutte contre la contrefacon de produits
US9027155B2 (en) 2012-07-02 2015-05-05 International Business Machines Corporation System for governing the disclosure of restricted data
US8997187B2 (en) * 2013-03-15 2015-03-31 Airwatch Llc Delegating authorization to applications on a client device in a networked environment
CN103220148B (zh) * 2013-04-03 2015-12-09 天地融科技股份有限公司 电子签名令牌响应操作请求的方法、系统和电子签名令牌
US9191213B2 (en) * 2013-12-18 2015-11-17 Xerox Corporation Methods and systems for messaging with physical presence and temporal verifications
US9686074B2 (en) * 2014-10-09 2017-06-20 Xerox Corporation Methods and systems of securely storing documents on a mobile device
CN106612253B (zh) * 2015-10-23 2019-10-22 中国科学院声学研究所 一种联动控制权管理装置及方法
US9894067B1 (en) * 2015-12-03 2018-02-13 Amazon Technologies, Inc. Cross-region roles
US10389722B2 (en) 2016-12-30 2019-08-20 Ssh Communications Security Oyj Access relationships in a computer system
US11700258B2 (en) * 2016-12-30 2023-07-11 Ssh Communications Security Oyj Access relationships in a computer system
CN108965299B (zh) * 2018-07-19 2021-06-15 湖南岳麓山数据科学与技术研究院有限公司 一种数据访问方法、访问验证设备及数据存储系统
US11316841B2 (en) * 2019-03-25 2022-04-26 Micron Technology, Inc. Secure communication between an intermediary device and a network
US20200364354A1 (en) * 2019-05-17 2020-11-19 Microsoft Technology Licensing, Llc Mitigation of ransomware in integrated, isolated applications
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7475250B2 (en) * 2001-12-19 2009-01-06 Northrop Grumman Corporation Assignment of user certificates/private keys in token enabled public key infrastructure system
US6971017B2 (en) * 2002-04-16 2005-11-29 Xerox Corporation Ad hoc secure access to documents and services
US6931530B2 (en) * 2002-07-22 2005-08-16 Vormetric, Inc. Secure network file access controller implementing access control and auditing
US8185744B2 (en) * 2006-09-08 2012-05-22 Certicom Corp. Aggregate signature schemes
EP2075766A1 (fr) 2007-12-28 2009-07-01 British Telecmmunications public limited campany Dispositifs d'identification de fréquence radio et processus associés
EP2166493A1 (fr) 2008-09-12 2010-03-24 BRITISH TELECOMMUNICATIONS public limited company Contrôle des réseaux d'approvisionnement et vérification d'articles
US20120046970A1 (en) * 2010-08-23 2012-02-23 Thomas John Potts Controlled substance distribution system

Also Published As

Publication number Publication date
CN102792633B (zh) 2015-04-01
CN102792633A (zh) 2012-11-21
US20120300937A1 (en) 2012-11-29
US8781130B2 (en) 2014-07-15
EP2529506A2 (fr) 2012-12-05
WO2011092451A3 (fr) 2011-09-22
EP2355402A1 (fr) 2011-08-10
WO2011092451A2 (fr) 2011-08-04

Similar Documents

Publication Publication Date Title
EP2529506B1 (fr) Contrôle d'accès
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
Salman et al. Security services using blockchains: A state of the art survey
EP3395006B1 (fr) Procédé de gestion d'une identité de confiance
US20230299938A9 (en) System for privacy protection during iot secure data sharing and method thereof
KR100734737B1 (ko) 조건부 전자 서명의 생성 방법, 조건부 전자 서명의 검증 방법, 데이터 처리 장치 및 컴퓨터 판독 가능 기록 매체
US20010020228A1 (en) Umethod, system and program for managing relationships among entities to exchange encryption keys for use in providing access and authorization to resources
Roe Cryptography and evidence
US20020144110A1 (en) Method and apparatus for constructing digital certificates
Win et al. Privacy enabled digital rights management without trusted third party assumption
Guo et al. Using blockchain to control access to cloud data
US20020144120A1 (en) Method and apparatus for constructing digital certificates
Konashevych Data insertion in blockchain for legal purposes. How to sign contracts using blockchain
Rajeb et al. Formal analyze of a private access control protocol to a cloud storage
Ugale et al. Digital rights management by using cloud computing
Li et al. Multi-domain rfid access control using asymmetric key based tag-reader mutual authentication
Knox et al. Digital credentials with privacy‐preserving delegation
Li et al. Public key based authentication for secure integration of sensor data and RFID
Imam Decentralized Confidential Secure Certified Notification System Using Rejectable Identity Tokens and Identity based Cryptography
Thangavel et al. We Bring Your Identity: A Secure Online Passenger Identity Protocol (SOPIP) for Indian Railways Using Aadhaar Number
Kravitz Exploration and impact of blockchain-enabled adaptive non-binary trust models
Marshall et al. Anonymity with identity escrow
Huebner et al. The CONVERGENCE Security Infrastructure
Dos Santos et al. Supporting national public key infrastructures using smart cards
Han et al. Privacy-preserving transactions protocol using mobile agents with mutual authentication

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

AK Designated contracting states

Kind code of ref document: A2

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

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20140828

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602011013501

Country of ref document: DE

Effective date: 20150312

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 708641

Country of ref document: AT

Kind code of ref document: T

Effective date: 20150315

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 708641

Country of ref document: AT

Kind code of ref document: T

Effective date: 20150128

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150428

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150428

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150429

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150528

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602011013501

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

26N No opposition filed

Effective date: 20151029

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 6

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160114

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160131

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160131

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160114

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20110114

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160131

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20150128

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230623

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20231219

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20231219

Year of fee payment: 14

Ref country code: FR

Payment date: 20231219

Year of fee payment: 14

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20231219

Year of fee payment: 14