EP2859704B1 - Anwendungsserver und verfahren zur verarbeitung einer nachricht für eine von mehreren vorrichtungen geteilte öffentliche identität - Google Patents

Anwendungsserver und verfahren zur verarbeitung einer nachricht für eine von mehreren vorrichtungen geteilte öffentliche identität Download PDF

Info

Publication number
EP2859704B1
EP2859704B1 EP13733364.7A EP13733364A EP2859704B1 EP 2859704 B1 EP2859704 B1 EP 2859704B1 EP 13733364 A EP13733364 A EP 13733364A EP 2859704 B1 EP2859704 B1 EP 2859704B1
Authority
EP
European Patent Office
Prior art keywords
message
devices
public identity
core network
response
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
EP13733364.7A
Other languages
English (en)
French (fr)
Other versions
EP2859704A1 (de
Inventor
Bertrand Bouvet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP2859704A1 publication Critical patent/EP2859704A1/de
Application granted granted Critical
Publication of EP2859704B1 publication Critical patent/EP2859704B1/de
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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Definitions

  • the invention relates to the general field of telecommunications and multimedia IP (Internet Protocol) network architectures, such as network architectures using in particular the technology referred to as “voice over IP” (or VoIP for Voice over IP).
  • IP Internet Protocol
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • the invention applies in particular to IP multimedia network cores based on an IMS (IP Multimedia Subsystem) architecture as proposed by the 3GPP (Third Generation Partnership Project) standard.
  • IMS IP Multimedia Subsystem
  • 3GPP Third Generation Partnership Project
  • multimedia IP network core architectures such as for example proprietary architectures, whether or not implementing the SIP protocol for the establishment of multimedia sessions (voice, text, video , data, etc.).
  • the invention relates more particularly to the processing of a so-called “remote” capability and state discovery message, received from a sender device and intended for a public identity managed by a multimedia IP core network, this message being sent as part of a multimedia communications service offered by a telecommunications operator or by a multimedia service provider.
  • a message for discovering the capabilities and status of the “remote” enables the sending device to be informed of the status (eg available, in communication, out of coverage, not registered, etc.). ) and the capabilities of a device using the public identity for which the message is intended (that is to say, the services, protocols, and / or applications that this device supports or implements).
  • the RCS-e (Rich Communication Suite - Enhanced) service described in the document " RCS-e Advanced Communications: Services and client specification ”, version 1.1, April 8, 2011 , is a multimedia communications service in which such a discovery message is used.
  • the RCS-e service allows two devices (e.g. two terminals) registered with an IMS core network to establish communication via a circuit switched network not connected to the IMS core network (e.g. via a network GSM (Global System for Mobile Communications)), then in parallel or in addition to this communication, to use, via a packet-switched network connected to the IMS (IP Multimedia Subsystem) core network, additional so-called communication multimedia services enriched, such as for example a service photo transfer service, instant messaging service, file sharing service, etc.
  • GSM Global System for Mobile Communications
  • the RCS-e service provides, in particular when creating in the directory of an RCS-e device a new contact associated with a public identity such as a telephone number or a SIP URI (Uniform Request Identifier), or when establishing a communication between an RCS-e device and another device associated with a public identity, the implementation of a mechanism for automatically discovering the status and capabilities of this contact or other device. As part of the RCS-e service, this mechanism results in the sending, by the RCS-e device, of a SIP OPTIONS message intended for the public identity.
  • a public identity such as a telephone number or a SIP URI (Uniform Request Identifier)
  • SIP URI Uniform Request Identifier
  • This SIP OPTIONS message is a “remote capability and state discovery message” or a “device capability and state discovery message associated with (or sharing) the public identity” within the meaning of 'invention. It invites the device associated with the public identity to declare, in response to this message, on the one hand its state and on the other hand its capacities, that is to say the services, the protocols, and / or the applications that it supports or implements.
  • any device receiving a SIP OPTIONS discovery message is required to respond to it transparently, by sending the device sending the discovery message a response message reflecting its state and containing its capabilities.
  • the device receiving the discovery message if it is available and compatible with the RCS-e service, it sends a 200 OK response message to the device sending the discovery message, containing in a “feature tag” field the identifier of the RCS-e service, as well as the identifiers of the other services supported by the receiving device (via other feature tags and / or SDP (Session Description Protocol) sessions).
  • the 200 OK response message also contains the SIP methods supported by the receiving device, etc.
  • the same public user identity (also referred to as IMPU for IMS Public User identity) can be associated with a single device (such as 'a terminal, a gateway, a server, etc.) or be shared by several devices associated with different private identities (or IMPI for IMS Private user Identity).
  • This public identity is for example a telephone number, a SIP URI address, a TEL URI address, etc.
  • Such an operating mode if it ensures that a response to the SIP OPTIONS message is actually provided to the sending device, unfortunately does not guarantee that the information sent in this response to the sending device is very relevant for the implementation of the service.
  • multimedia based on the discovery mechanism. However, this information is taken into account during the implementation of the multimedia service, and therefore has a direct influence on the level and quality of the service provided.
  • the document WO 2010/099829 describes a method for processing a capability and status discovery message in a communication network.
  • the invention thus offers a more flexible and flexible solution than that envisaged today in the 3GPP standard for responding to the remote capacity and status discovery message sent by the sender device to the public identity, while respecting the constraints imposed by the 3GPP standard and the SIP protocol concerning in particular the obligation to respond to the discovery message and the requirement of transparency in the responses returned by the devices sharing the public identity.
  • the invention no longer proposes to systematically send back to the sending device the first response received from a registered device sharing the common identity, but to develop a response from at least one response received from a device. recorded in a predetermined period of time.
  • the introduction of this predetermined period of time allows the application server not to wait unduly for a response from a device registered with the core network which is not able to respond, for example because it is not. no longer connected to the core network although still registered with it. Such a situation may arise in particular when the device is suddenly switched off or goes out of network coverage without having time to deregister with the core network.
  • the invention thus offers the possibility of developing a response better suited to the discovery message sent by the sending device to the public identity, by taking into account all or part of the information contained in the responses of the registered devices sharing the public identity. .
  • the invention has a privileged but non-limiting application when the core network implements the SIP session initiation protocol and the main message and the secondary discovery messages are SIP OPTIONS messages. .
  • the response to the main discovery message corresponds to the response received from a device considered to have priority among the registered devices sharing the public identity and having responded to the secondary discovery messages within the predetermined period of time.
  • the device considered to have priority can in particular be the device having the largest parameter q as defined in document RFC 3261 of the IETF.
  • the response to the primary message will preferably correspond to the response received from the priority device having the period d highest registration expiration among these priority devices.
  • the response to the main discovery message contains all or part of the capacities of each registered device that responded to a said secondary discovery message during the predetermined period.
  • the sending device is thus offered an overview of the services, protocols and / or applications supported by the various devices registered with the multimedia IP core network and sharing the public identity.
  • the provision of all or part of the capacities of the registered devices can be configured by the user of these devices, for example via a web interface. It can be conditioned by different factors. Thus, for example, it may depend on the identifier of the sending device, the date / time at which the main discovery message was sent, or the number of active sessions already in progress at the level of the registered devices, etc.
  • This strategy can be configurable and vary according to various elements, such as for example the multimedia service in the context of which the discovery mechanism is implemented, or the device sending the discovery message (e.g. depending on whether the identifier of this device checks certain predetermined conditions), etc.
  • the response to the main discovery message corresponds to the response received which identifies the greatest number of services or distinct types of services supported.
  • the method according to the invention comprises a step of interrogating the registration server to identify the devices among said plurality of devices sharing the public identity registered with the core network.
  • this registration server interrogation step may include sending a SIP REGISTER request to the network core without a contact address.
  • the application server then receives in response to this interrogation step a 200 OK message containing in particular the reachability information (eg contact address) of the registered devices sharing the common identity, as well as others.
  • the reachability information eg contact address
  • types of information on these devices such as for example a prioritization parameter associated with each of these devices (e.g. parameter q defined by document RFC 3261), a registration expiration value of each device, optionally the or the supported services (feature tag), etc.
  • the method further comprises a prior step of subscribing the application server to the registration server in order to be notified when a device of the plurality of devices sharing the public identity has registers with the core network.
  • the application server subscription can be done via the mechanism provided by the 3GPP standard and known under the name of “Third Party Registration”. This mechanism allows the application servers that so wish and subscribe to receive the SIP registration messages from the devices to the multimedia IP core network. The application servers are thus informed in real time of the list of devices registered with the core network and of their reachability information (eg contact addresses).
  • the different steps of the processing method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in an application server or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a treatment method as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable shape.
  • the invention also relates to an information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information medium can be any entity or device capable of storing the program.
  • the medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disk. hard.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet type network.
  • the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • processing method, the application server and the communications system according to the invention prefferably have all or part of the aforementioned characteristics in combination.
  • the figure 1 shows a communications system 1 according to the invention, in its environment, in a particular embodiment.
  • the communications system 1 comprises a plurality of multimedia devices D1, D2-1, ..., D2-N.
  • These devices D1, D2-1, D2-2, ..., D2-N are for example multimedia terminals such as intelligent mobile telephones (or “smartphones” in English), capable of communicating with each other via CN1 and CN2 multimedia IP network cores.
  • the network cores CN1 and CN2 are, in the embodiment described here, network cores using the so-called “voice over IP” (VoIP) technology, respectively managing the device D1 and the devices D2-1, D2-2. , ..., D2-N.
  • VoIP voice over IP
  • IMS architecture implementing the SIP session initiation protocol, as defined in the 3GPP document TS 22.228 “Service requirements for the IP Multimedia Core Network Subsystem (Stage 1)”.
  • the invention also applies when the network cores CN1 and CN2 form only one multimedia IP network core.
  • multimedia devices such as, for example, servers or gateways
  • multimedia IP network core architectures such as, for example, servers or gateways
  • session such as for example to proprietary network core architectures using the SIP protocol or another proprietary or standardized session initiation protocol providing a message for discovering the capabilities and status of the remote).
  • the devices D2-1, D2-2, ..., D2-N share the same public identity or IMPU, denoted IMPU2.
  • This public identity is for example a telephone number or a SIP address such as a SIP URI or TEL URI address.
  • D2-1, D2-2, ..., D2-N devices are identified using separate private or IMPI identities, and are accessible (ie reachable) via contact addresses (or AoC for Address of Contact), denoted respectively AoC1, AoC2, ..., AoCN.
  • the contact address of a device in the IP domain comprises the IP address of the device, a port number associated with its protocol stack (SIP stack here), as well as the transport protocol used by the device. to communicate (eg UDP (User Data Protocol), TCP (Transport Control Protocol), TLS (Transport Layer Security)).
  • This contact address defines the physical address at which the device can be reached. This is so-called reachability information within the meaning of the invention.
  • the communications system 1 also includes an application server 2, able to process, in accordance with the invention, the remote capacity and state discovery messages intended for the public identity IMPU2.
  • These discovery messages are, in the contexts IMS and SIP considered here, SIP OPTIONS messages containing in their R-URI (Request URI) field, the public identity IMPU2 shared by the devices D2-1, D2-2, ..., D2-N.
  • these SIP OPTIONS messages allow their transmitters to discover the capacities and the state of a device associated with the public identity IMPU2.
  • the application server 2 can be a server dedicated to the implementation of the method for processing SIP OPTIONS messages according to the invention or an application server that already exists and is triggered during the implementation of other applications.
  • This triggering of the application server 2 is carried out in accordance with a trigger criterion or iFC (initial Filter Criteria) stored in a profile of the user to whom the public identity IMPU2 is allocated, this profile being stored at the level of the server.
  • a trigger criterion or iFC initial Filter Criteria
  • HSS Home Subscriber Server subscribers of the CN2 multimedia IP core network (not shown on the figure 1 ).
  • This trigger criterion can be positioned in the user's profile by the operator of the core network CN2, for example when the service offer authorizes the use of several multimedia devices sharing the same public identity IMP2, or as a variant, it can be positioned in the user's profile at the user's request (for example via subscription to a suitable service with the operator of the core network CN2, or via a web interface).
  • the registration server 3 implements, in the presence of a message intended for a public identity shared by a plurality of devices registered with the core network (in other words a message containing, in its SIP field R -URI, the shared public identity), a FORK replication function of this message (also known as the forking function) in as many replicas as there are registered devices sharing the public identity, the replicated messages then being transmitted to devices registered by the replication function passing through the P-CSCF server of the CN2 core network (not shown on figure 1 ).
  • a message intended for a public identity shared by a plurality of devices registered with the core network in other words a message containing, in its SIP field R -URI, the shared public identity
  • a FORK replication function of this message also known as the forking function
  • the application server 2 is triggered by the recording server 3 upstream of this FORK replication function implemented by the recording server 3, so as to inhibit the application of this function FORK by registration server 3 on the discovery message processed by application server 2, as described in more detail later.
  • upstream is meant here that the application server 2 is triggered before the application of the FORK function by the recording server 3, with reference to the path taken by the discovery message in the direction of the sending of the message. discovery to receiver of the discovery message.
  • the application server 2 here has the hardware architecture of a computer as shown schematically on figure 2 .
  • It comprises in particular a processor 2A, a random access memory 2B, a read only memory 2C, a 2D non-volatile flash memory as well as communication means 2E implementing in particular the SIP protocol.
  • These communication means allow it to communicate with the entities of the core network CN2 and with the devices D2-1, D-2, ..., D2-N sharing the public identity IMPU2.
  • the read only memory 2C of the application server 2 constitutes a recording medium according to the invention, readable by the processor 2A and on which is recorded a computer program according to the invention, comprising instructions for the execution. steps of a treatment process now described with reference to figure 3 .
  • the sending device D1 is registered with the core network CN1, and that among the devices D2-1, D2-2, ..., D2-N sharing the public identity IMPU2, R devices D2-1, D2 -2, ..., D2-R, 1 ⁇ R ⁇ N, are registered with the core network CN2 managing the public identity IMPU2.
  • the MOPT message sent by the device D1 is a SIP OPTIONS message, as described in detail in the document RFC 3261 cited above. It contains in particular in a FROM field, an identifier of the device D1 at the origin of the message, and in an R-URI (Request URI) field and in a TO field, the public identity IMPU2 for which the message is intended.
  • SIP OPTIONS SIP OPTIONS message
  • the MOPT message sent by the device D1 to the public identity IMPU2 is received by the registration server 3 of the core network CN2. This is a main discovery message within the meaning of the invention.
  • the application server 2 Upon detection by the registration server 3 that this is a message for discovering the capabilities and status of a device associated with the identity IMPU2 (in other words here, a SIP OPTIONS message intended for to the public identity IMPU2), the application server 2 is triggered in accordance with the information (iFC criteria) contained in the profile of the user to whom the public identity IMPU2 is allocated, stored in the HSS server of the core network CN2 .
  • the MOPT message received from the device D1 is transmitted during this triggering by the recording server 3 to the application server 2 for processing in accordance with the invention (step E10).
  • the application server 2 determines, first of all, whether several devices bearing the public identity IMPU2 for which the MOPT message is intended are registered with the core network CN2 (step E20).
  • the application server 2 queries the registration server 3 by sending it a SIP REGISTER message containing the public identity IMPU2 but not containing a contact address.
  • a SIP REGISTER message without a contact address makes it possible, in accordance with the SIP protocol, to obtain from the core network CN2 information on the devices bearing the public identity IMPU2 and which are registered with the core network.
  • Sending this message therefore allows the application server 2 to identify the devices sharing the public identity IMPU2 registered with the core network when receiving the MOPT message.
  • the information transmitted by the registration server 3 in response to the SIP REGISTER message without a contact address is information related to the registration itself of each device sharing the public identity IMPU2. They can include in particular an identifier of the device, its contact address, its capabilities ("feature tags"), its priority compared to other devices sharing the public identity IMPU2, the registration expiration period EXP associated with it. , etc.
  • the devices D2-1, D2-2, ..., D2-R, R ⁇ N are registered with the core network CN2.
  • the application server 2 therefore obtains, in response to the SIP REGISTER message sent to the registration server 3, a 200 OK message containing the contact addresses AOC1, AOC2, ..., AOCR of the R devices D2-1, D2- 2, ..., D2-R registered with the core network CN2 (step E20).
  • the parameter qk associated with the device D2-k, k 1, ..., R, corresponds here to the priority parameter q defined in the document RFC 3261 cited above.
  • the application server 2 determines whether several devices sharing the public identity IMPU2 are registered with the core network CN2 and if necessary identifies these devices, via the “Third Party Registration” mechanism defined by the network. 3GPP standard (Third Generation Partnership Project).
  • this mechanism allows the application server 2 to subscribe to the registration server 3 in order to be notified when a device sharing the public identity IMPU2 registers with the core network CN2.
  • the server application 2 receives reachability information from the considered device such as its contact address of the device, as well as other information such as its registration expiration period, its priority compared to other devices sharing the same public identity , etc.
  • the application server 2 determines from the information received from the registration server 3 the number of devices registered with the core network CN2 sharing the public identity IMPU2. In the example considered here, this number is equal to R.
  • step E40 the application server 2 does not perform any specific processing on the MOPT message: in other words, the MOPT message is relayed by the application server 2 to the recording server 3, without changing the content.
  • the registration server 3 transmits the MOPT message, if applicable, to the only registered device carrying the public identity IMPU2, which responds to the MOPT message in accordance with the standard, providing its status and its capabilities.
  • the processing applied by the application server 2 during step E50 therefore advantageously makes it possible to avoid the replication of the SIP OPTIONS MOPT message by the FORK function of the recording server 3, and a fortiori to inhibit the sending. by the recording server 3 to the device D1, a response message corresponding to the first response message received from the devices D2-k.
  • the choice of period T results from a compromise between performance and execution time required to respond to the SIP OPTIONS MOPT message sent by device D1.
  • Each REPk response message is here similar or identical to the response message to the SIP OPTIONS message provided for in the RFC 3261 document of the SIP standard (same format and same content with regard to the state and capabilities of the D2-k device) .
  • the REPk response from device D2-k follows the reverse path of the MOPTk message, in accordance with the SIP protocol operating mode. This response therefore passes through the application server 2.
  • a device D2-k it is possible for a device D2-k to appear as registered with the registration server 3 although it is no longer connected to the core network CN2 when the message MOPTk is sent, for example due to '' sudden loss of network connection or sudden shutdown of the device. Of course, in such a situation, the device D2-k cannot receive the MOPTk message and / or cannot respond to it within the predetermined period of time T.
  • test step E70 determines whether it has received one or more responses to the MOPTk messages sent to the devices D2-k (test step E80).
  • step E80 If it has not received any response (no response to step E80), it sends the device D1 a response defined by default, reflecting the absence of response from the devices sharing the public identity IMPU2 (step 90) . For example, it can send a “480 temporarily Unavailable” response message to device D1 in response to the MOPT discovery message.
  • the application server 2 prepares a RESP response to the MOPT discovery message from said at least one response received during the period T, according to a predefined response RULE rule with which the application server 2 has been configured during a preliminary step (step E100).
  • This preliminary step of configuring the application server 2 consists, strictly speaking, in transmitting to the application server 2 the RULE rule to be applied to develop the RESP responses to the SIP OPTIONS messages intended for the public identity IMPU2.
  • This configuration step can follow in particular the storage of the iFC trigger criterion of the application server 2 in the profile of the user to whom the public identity IMPU2 is allocated.
  • the RULE rule defining the response strategy to the SIP OPTIONS MOPT message applied by the application server 2 can be configured: it can thus change over time and / or depend on various factors such as for example the public identity IMPU2, the service originating the SIP OPTIONS message, an identifier of the device originating the SIP OPTIONS message, etc.
  • the application server 2 has been configured with a RULE rule according to which the RESP response to the MOPT message produced by the application server 2 corresponds to the response received during the period T from the device having the highest priority parameter q among the devices registered with the core network CN2 sharing the public identity IMPU2, in other words, the response RESP corresponds to the response of the device considered to have priority among the devices D2-1, D2- 2, ..., D2-R having responded during period T.
  • the application server 2 selects the priority device that responded during the period T and having the highest registration expiration period EXP among the registration expiration periods transmitted during step E20 by the registration server 3.
  • the RESP response produced by the application server 2 corresponds to the response received in period T from the priority device which was most recently registered or re-registered.
  • the RESP response produced by the application server 2 can correspond to the response received from the devices D2-1, ..., D2-R during the period T containing the most services (or "feature tags” ) or capabilities, or which contains a particular type of services or capabilities, etc.
  • the RESP response can be a SIP 200 OK message containing all the capabilities of each registered device D2-k that responded to the MOPTk message during the period of time T, so as to inform the device D1 of the extent of the capacities of all the devices sharing the public identity IMPU2 and registered with the core network CN2.
  • the RESP response can be a SIP 200 OK message containing only a selection of the capacities of each registered device D2-k which replied to the MOPTk message during the time period T, or the capacities of a sub - only set of registered devices that responded to the discovery message during the time period T.
  • the RESP response produced by the application server 2 is then sent to the device D1 (step 110), via the recording server 3, according to the reverse path to the path taken by the MOPT message.
  • the device D1 thus has a response to the SIP OPTIONS message containing relevant information, since it is prepared from responses received during a predetermined period from all the devices registered with the core network and sharing the public identity IMPU2, according to a response strategy chosen by the operator of the core network or by the user of the public identity IMPU2.
  • the application server 2 sends a “secondary” discovery message to all of the devices D2-1, D2-2, ..., D2- R registered with the CN2 core network and sharing the public identity IMPU2. Then, during step E100, it develops the RESP response from the response received from the priority device among the devices which responded to these secondary discovery messages during the period T.
  • the server application 2 can send a secondary discovery message only to the priority device among the devices D2-1, D2-2, ..., D2-R, and develop the RESP response from the response received from this unique device. Note, however, that this embodiment presents the risk that the application server 2 does not receive a response from the priority device before the expiration of the period T, in particular if this priority device is unavailable (for example because it no longer has a network connection or is out of coverage).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Claims (13)

  1. Verfahren zur Verarbeitung einer von einer Sendevorrichtung (D1) kommenden Nachricht (MOPT), die für eine öffentliche Identität (IMPU2) bestimmt ist, die von einem Multimedia-IP-Netzwerkkern (CN2) verwaltet und von einer Mehrzahl von Vorrichtungen (D2-1,...,D2-N) gemeinsam genutzt wird, wobei die Nachricht (MOPT) eine Hauptnachricht zur Feststellung der Kapazitäten und eines Zustands einer der Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, ist, wobei das Verfahren dazu bestimmt ist, von einem Anwendungsserver (2) des Netzwerkkerns durchgeführt zu werden, der stromauf einer Replikationsfunktion (FORK) ausgelöst wird, die von einem Registrierungsserver (3) des Netzwerkkerns implementiert wird, der die öffentliche Identität verwaltet, wobei die Replikationsfunktion (FORK) geeignet ist, Nachrichten zu replizieren, die für die öffentliche Identität bestimmt sind, und die replizierten Nachrichten zu der Mehrzahl von Vorrichtungen zu übertragen, die die öffentliche Identität gemeinsam nutzen,
    das Verarbeitungsverfahren umfassend, bei Empfang (E10) der Haupt-Feststellungsnachricht (MOPT), wenn mehrere Vorrichtungen von der Mehrzahl von Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, beim Netzwerkkern registriert sind (E30):
    - einen Schritt des Sendens (E50), an mindestens eine Vorrichtung (D2-1,...,D2-R) der Mehrzahl von Vorrichtungen, die beim Netzwerkkern registriert sind, einer Sekundärnachricht (MOPT1, MOPT2,..., MOPTR) zur Feststellung der Kapazitäten und eines Zustands dieser Vorrichtung;
    - einen Schritt des Erstellens (E100) einer Antwort (RESP) auf die Haupt-Feststellungsnachricht (MOPT) anhand mindestens einer Antwort (RESP1, RESP2,..., RESPR) von einer registrierten Vorrichtung (D2-1,...,D2-R) auf eine Sekundär-Feststellungsnachricht, die in einem vorbestimmten Zeitraum empfangen wird, wobei diese Antwort für einen Zustand und die Kapazitäten dieser Vorrichtung repräsentativ ist; und
    - einen Schritt des Sendens (E110) der erstellten Antwort (RESP) auf die Haupt-Feststellungsnachricht an die Sendevorrichtung (D1).
  2. Verfahren nach Anspruch 1, umfassend einen Schritt des Abfragens (E20) des Registrierungsservers (3), um die Vorrichtungen (D2-1,...,D2-R) von der Mehrzahl von Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, die beim Netzwerkkern registriert sind, zu identifizieren, und eine Erreichbarkeitsinformation dieser Vorrichtungen (AoC1,AoC2,...,AoCR).
  3. Verfahren nach Anspruch 2 wobei:
    - der Netzwerkkern (CN2) das Protokoll zur Initiierung einer SIP-Sitzung durchführt; und
    - der Schritt des Abfragens (E20) des Registrierungsservers (3) das Senden einer SIP-REGISTER-Anfrage an den Netzwerkkern ohne Kontaktadresse umfasst.
  4. Verfahren nach Anspruch 1, ferner umfassend einen vorhergehenden Schritt des Abonnierens des Anwendungsservers beim Registrierungsserver, um benachrichtigt zu werden, wenn eine Vorrichtung der Mehrzahl von Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, sich beim Netzwerkkern registriert.
  5. Verfahren nach Anspruch 1, wobei die Antwort (RESP) auf die Hauptnachricht der Antwort entspricht, die von einer Vorrichtung empfangen wird, die von den registrierten Vorrichtungen, die auf die Sekundär-Feststellungsnachrichten im vorbestimmten Zeitraum geantwortet haben, als vorrangig betrachtet wird.
  6. Verfahren nach Anspruch 5, wobei der Netzwerkkern (CN2) das Protokoll zur Initiierung einer SIP-Sitzung durchführt und die Vorrichtung, die als vorrangig betrachtet wird, die Vorrichtung ist, die den größten q-Parameter, wie im Dokument RFC3261 der IETF festgelegt, aufweist.
  7. Verfahren nach Anspruch 5, wobei, wenn mindestens zwei Vorrichtungen als vorrangig betrachtet werden, die Antwort auf die Hauptnachricht der Antwort entspricht, die von der vorrangigen Vorrichtung mit der höchsten Registrierungsablaufzeit von den vorrangigen Vorrichtungen empfangen wird.
  8. Verfahren nach Anspruch 1, wobei die Antwort auf die Haupt-Feststellungsnachricht die gesamten oder einen Teil der Kapazitäten jeder registrierten Vorrichtung enthält, die auf eine der Sekundär-Feststellungsnachrichten während des vorbestimmten Zeitraums geantwortet hat.
  9. Verfahren nach Anspruch 1 wobei:
    - der Netzwerkkern (CN2) das Protokoll zur Initiierung einer SIP-Sitzung durchführt; und
    - die Haupt- (MOPT) und die Sekundär-(MOPT1,MOPT2,...,MOPTR) Feststellungsnachrichten SIP-OPTIONS-Nachrichten sind.
  10. Anwendungsserver (2) eines Multimedia-IP-Netzwerkkerns (CN2), der eine öffentliche Identität (IMPU2) verwaltet, die von einer Mehrzahl von Vorrichtungen (D2-1,...,D2-N) gemeinsam genutzt wird, wobei der Anwendungsserver stromauf einer Replikationsfunktion (FORK) ausgelöst wird, die von einem Registrierungsserver (3) des Netzwerkkerns implementiert wird, der die öffentliche Identität verwaltet, wobei die Replikationsfunktion geeignet ist, Nachrichten zu replizieren, die für die öffentliche Identität bestimmt sind, und die replizierten Nachrichten zu der Mehrzahl von Vorrichtungen zu übertragen, die die öffentliche Identität gemeinsam nutzen, der Anwendungsserver umfassend:
    - Mittel zum Bestimmen, ob mehrere Vorrichtungen (D2-1,...,D2-R) von der Mehrzahl von Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, beim Netzwerkkern registriert sind, wobei diese Mittel bei Empfang einer Hauptnachricht (MOPT) zur Feststellung der Kapazitäten und des Zustands einer der Vorrichtungen, die die öffentliche Identität gemeinsam nutzen, aktiviert werden, wobei die Hauptnachricht von einer Sendevorrichtung (D1) kommt und für die öffentliche Identität bestimmt ist;
    - Mittel, die gegebenenfalls aktiviert werden:
    o um an mindestens eine registrierte Vorrichtung (D2-1,...,D2-R) der Mehrzahl von Vorrichtungen eine Sekundärnachricht (MOPT1,...,MOPTR) zur Feststellung der Kapazitäten und eines Zustands dieser Vorrichtung zu senden;
    o um eine Antwort (RESP) auf die Haupt-Feststellungsnachricht (MOPT) anhand mindestens einer Antwort (RESP1,RESP2,...,RESPR) auf eine Sekundär-Feststellungsnachricht, die in einem vorbestimmten Zeitraum von einer registrierten Vorrichtung empfangen wird, zu erstellen, wobei diese Antwort für einen Zustand und die Kapazitäten dieser Vorrichtung repräsentativ ist; und
    o um die erstellte Antwort auf die Haupt-Feststellungsnachricht an die Sendevorrichtung (D1) zu senden.
  11. Kommunikationssystem (1) umfassend:
    - eine Mehrzahl von Vorrichtungen (D2-1,...,D2-N), die eine öffentliche Identität (IMPU2) gemeinsam nutzen, die von einem Multimedia-IP-Netzwerkkern (CN2) verwaltet wird;
    - eine Sendevorrichtung (D1), die geeignet ist, an die öffentliche Identität eine Hauptnachricht (MOPT) zur Feststellung der Kapazitäten und des Zustands einer der Vorrichtungen, die diese öffentliche Identität gemeinsam nutzen, zu senden; und
    - einen Anwendungsserver (2) des Netzwerkkerns, der geeignet ist, diese Haupt-Feststellungsnachricht zu verarbeiten, und Anspruch 10 entspricht.
  12. Computerprogramm, aufweisend Anweisungen für die Ausführung der Schritte des Verarbeitungsverfahrens nach Anspruch 1, wenn das Programm von einem Computer ausgeführt wird.
  13. Computerlesbares Speichermedium, auf dem ein Computerprogramm gespeichert ist, das Anweisungen für die Ausführung der Schritte des Verarbeitungsverfahrens nach Anspruch 1 umfasst.
EP13733364.7A 2012-06-12 2013-06-06 Anwendungsserver und verfahren zur verarbeitung einer nachricht für eine von mehreren vorrichtungen geteilte öffentliche identität Active EP2859704B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1255503A FR2991839A1 (fr) 2012-06-12 2012-06-12 Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
PCT/FR2013/051299 WO2013186466A1 (fr) 2012-06-12 2013-06-06 Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs

Publications (2)

Publication Number Publication Date
EP2859704A1 EP2859704A1 (de) 2015-04-15
EP2859704B1 true EP2859704B1 (de) 2020-12-02

Family

ID=48746071

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13733364.7A Active EP2859704B1 (de) 2012-06-12 2013-06-06 Anwendungsserver und verfahren zur verarbeitung einer nachricht für eine von mehreren vorrichtungen geteilte öffentliche identität

Country Status (3)

Country Link
EP (1) EP2859704B1 (de)
FR (1) FR2991839A1 (de)
WO (1) WO2013186466A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230098402A1 (en) * 2020-02-03 2023-03-30 Nokia Solutions And Networks Oy Providing multi-device service using network application programming interface

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090316690A1 (en) * 2008-06-23 2009-12-24 Research In Motion Limited Method for Delivering Device and Server Capabilities

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101471871B (zh) * 2007-12-28 2013-11-06 华为技术有限公司 终端、服务器、终端管理方法和终端能力信息上报方法
CN105245493B (zh) * 2009-03-06 2018-08-21 瑞典爱立信有限公司 通信网络中的能力查询处理

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090316690A1 (en) * 2008-06-23 2009-12-24 Research In Motion Limited Method for Delivering Device and Server Capabilities

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "RFC 3261 - SIP: Session Initiation Protocol", 1 June 2002 (2002-06-01), XP055324488, Retrieved from the Internet <URL:https://tools.ietf.org/html/rfc3261> [retrieved on 20161130] *

Also Published As

Publication number Publication date
EP2859704A1 (de) 2015-04-15
WO2013186466A1 (fr) 2013-12-19
FR2991839A1 (fr) 2013-12-13

Similar Documents

Publication Publication Date Title
EP2772035B1 (de) Verfahren zur verwaltung einer kommunikation für einen benutzer und anwendungsserver
WO2010109125A1 (fr) Procede et dispositif de traitement d&#39;une information indicatrice d&#39;un souhait d&#39;implication dans au moins une session applicative d&#39;un utilisateur
EP2708002B1 (de) Verfahren zur behandlung ein umschalten der kommunikation zwischen zwei zugangsnetze
EP2856732B1 (de) Verfahren und einheit zur verarbeitung einer nachricht
FR2929473A1 (fr) Procede de terminaison d&#39;un appel et terminal de voix sur ip
EP3549368B1 (de) Verfahren zum verteilen von anwendungsmeldungen in einem ip-netzwerk
EP3646554B1 (de) Verfahren zur verarbeitung einer anforderung und server eines multimedia-ip-netzwerkkerns
EP2859704B1 (de) Anwendungsserver und verfahren zur verarbeitung einer nachricht für eine von mehreren vorrichtungen geteilte öffentliche identität
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
FR3090252A1 (fr) Procédé de basculement d’une communication de TCP sur UDP
EP2786546A1 (de) Registrierung einer vorrichtung in einem voip-core-netzwerk
EP3391615B1 (de) Verfahren zur kommunikation zwischen einem anrufenden endgerät und einer vielzahl angerufener endgeräte
WO2017203118A1 (fr) Procédé de repli dans un réseau de télécommunication
EP3472993B1 (de) Verfahren zur bestimmung eines satzes von codierungsformaten zum aufbau einer kommunikation
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2238727B1 (de) Verfahren zur kommunikation für die verwaltung von kommunikationssitzungen auf der ebene eines häuslichen gateway
FR3001351A1 (fr) Enregistrement d&#39;un equipement client par l&#39;intermediaire d&#39;un serveur mandataire dans un reseau de communication
FR2977114A1 (fr) Procede d&#39;indexation d&#39;un message court relatif a un terminal provisionne aupres d&#39;un cœur de reseau ims
FR2988951A1 (fr) Procede d&#39;enregistrement d&#39;un serveur aupres d&#39;une pluralite de coeurs de reseau, et serveur.
FR2989548A1 (fr) Procede de traitement d&#39;un message, entite et coeur de reseau
WO2013102716A1 (fr) Procede dynamique de determination d&#39;une liste de services dans un reseau sip

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

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

DAX Request for extension of the european patent (deleted)
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: 20181217

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602013074439

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0029080000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20200612BHEP

Ipc: H04L 29/06 20060101ALI20200612BHEP

INTG Intention to grant announced

Effective date: 20200630

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

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

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1342189

Country of ref document: AT

Kind code of ref document: T

Effective date: 20201215

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602013074439

Country of ref document: DE

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

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

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

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

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20201202

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1342189

Country of ref document: AT

Kind code of ref document: T

Effective date: 20201202

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

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

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

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

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

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

Ref country code: NL

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

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

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

RAP4 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: ORANGE

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

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

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

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

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

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

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

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

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

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

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602013074439

Country of ref document: DE

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

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

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

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

26N No opposition filed

Effective date: 20210903

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602013074439

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000

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

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

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

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

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20210630

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 NON-PAYMENT OF DUE FEES

Effective date: 20210606

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

Ref country code: LI

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

Effective date: 20210630

Ref country code: IE

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

Effective date: 20210606

Ref country code: CH

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

Effective date: 20210630

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

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

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 NON-PAYMENT OF DUE FEES

Effective date: 20210630

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

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

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

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

Ref country code: FR

Payment date: 20230523

Year of fee payment: 11

Ref country code: DE

Payment date: 20230523

Year of fee payment: 11

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

Ref country code: GB

Payment date: 20230524

Year of fee payment: 11

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