Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
  • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
  • H04N21/632—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing using a connection between clients on a wide area network, e.g. setting up a peer-to-peer communication via Internet for retrieving video segments from the hard-disk of other client devices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
  • H04N21/2385—Channel allocation; Bandwidth allocation
• • 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/60—Network streaming of media packets
  • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
  • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
• • 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/60—Network streaming of media packets
  • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
  • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
• • 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/80—Responding to QoS
• • 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/55—Push-based network services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
  • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
  • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
  • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
  • H04N21/845—Structuring of content, e.g. decomposing content into time segments

Definitions

• the present invention relates to a method of broadcasting content from a remote server to a plurality of terminals of a private network, some of which have a limited bandwidth.
• Each organization may have a different need for the dissemination of such content. For example, it is a message from a manager to all employees or a promotional message about a new product or service in a bank branch or store. This may still be a personalized message for hotel guests, service delivery in an administration, or educational content, such as courses broadcast in E-leaming mode in a school, or upgrade in different areas of the skills of employees of a company.
• Extended networks or WANs are the most common in these organizations. However, these networks are not always dedicated to the transport of multimedia content, which limits their ability to provide professional quality of service and adequate latency to ensure a satisfactory experience for all end users.
• WO 2008/038280 discloses a method for real-time broadcasting of media on a public peer-to-peer network, where certain peers that do not consume content are used to retransmit it.
• a) List in particular in a management server (EB), at least one of said terminals as a master client and at least two other of said terminals as slave clients,
• EB management server
• the method may further include the step of: d) for at least one slave client that has not received the necessary packets of the content to be broadcast from the master client, receiving the missing packets from at least one other slave client using existing links between slave clients within the private network.
• the invention makes it possible to maintain a fluid distribution of the content while keeping the initial network architecture of the organization.
• client and “terminal” are synonymous.
• public network By public network, one must understand a broadband internet network. Access to the content server and / or the management server may be via a public network, as appropriate.
• the broadcast of the content can be performed according to a first transmission protocol when the bandwidth is sufficient, and according to a second protocol when the bandwidth is insufficient for the implementation of the first protocol.
• a management server which can connect the terminals of the private network, before starting to receive the content broadcast by the content server.
• This management server can determine, when connecting a terminal to it, with which protocol this terminal can receive the broadcast content.
• the management server can perform a bandwidth test during the connection of the terminal, or alternatively determine the bandwidth according to the location of the terminal, for example its IP address, with the help of a base of data information on the bandwidth according to the location.
• the management server can be accessible by the terminals of the private network via a public network for example, or be part of the private network.
• a terminal operating according to the first protocol may be configured to wait a predefined time to receive a packet from other terminals with which it exchanges data before querying the content server. This duration may depend for example on the size of the packets, the number of slave and master clients.
• the second protocol above is advantageously a broadcast protocol with content pushed from the master client, in a format allowing a peer-to-peer exchange possibility between the slave terminals. At least part of the content to be broadcast can be pushed by the master client to slave clients of the private network, these slave clients preferably being chosen randomly by the master client.
• Broadcasting at least a portion of the content to be broadcast between the slave clients is advantageously carried out by a peer-to-peer broadcast mechanism in addition to receiving the packets pushed by the master client.
• the method according to the invention may include the step of listing at least one of the slave clients of the private network as priority slave client, and to cause the master client to push the packets of the content to be broadcast in priority to this slave client priority. Packets can be pushed to other slave clients by randomly selecting them.
• push "push” in English) must be understood a mode of broadcast where the receiver of the packets receives them without having requested the sending, once he became known to the issuer.
• Each packet also called “chunk” may be a video packet having a size between 256 kB and 2.56 MB, for example 1M.
• the method may also include the step of causing the slave clients of the private network, other than the priority slave client, to address the priority slave client to receive the packets of the content to be broadcast in the event of a failure of the master client.
• the method may include the step of listing as master client the first terminal of the private network to connect to the management server to request the receiving the content to be broadcast.
• the management server verifies that the bandwidth available to this terminal is sufficient to receive the video packets according to the first protocol from the remote server, before listing it as a master client.
• the method may include the step of listing as priority slave client the second terminal of the private network to connect to the management server to request the reception of the content to be broadcast.
• the management server can thus transmit to a terminal of the private network information relating to the information exchange protocol to be implemented with the other clients of the private network to retrieve the packets of the content to be broadcast, and / or broadcast them.
• the management server can be arranged to check, when connecting a terminal to the management server, if this terminal has resources greater than the master client with which it is intended to exchange to receive the content packets.
• this terminal will be able to play the role of master client in a more favorable way for other slave clients who will receive their packets from it. ci, as the current master client. If this is the case, the management server can be arranged to list this terminal as a new master client instead of the old one, and warn the old master client that it no longer has the status.
• the management server can change the status of the old master client to a slave slave client or a slave client, depending on the resources available to it and those of other swarm clients.
• the method may comprise the step of determining, during a connection to the management server of a terminal of the private network, whether this terminal can directly access, due to the available bandwidth, the packets of the content to broadcast, and if so bring this terminal to receive directly said packets content server or a peer-to-peer connection with other terminals without receiving packets pushed.
• At least one slave client or a priority slave client is shared between two swarms.
• the choice of the shared client is made by the preference management server according to the degree of progress in the download of each of the two swarms, preferably choosing at least one priority slave or slave client from the one of the two swarms which is the more advanced in its download.
• only a slave client or priority slave is shared between two swarms.
• This shared client may be chosen according to the time difference between the downloads of the content, and may in particular be chosen from the customers of a swarm in advance of download compared to the clients of the other swarm.
• a master client may be arranged to wait a predefined time to receive a packet of the content of other terminals, including master clients, with which it exchanges data, before contacting the content server to obtain this packet.
• the master client In the presence of one or more terminals having sufficient bandwidth to receive the packets directly from the content server and exchange packets with at least one master client, but not exchanging packets with any slave client, the master client (s) can be arranged to seek first and foremost to receive the content packets of one or more of these terminals which are the most advanced in downloading the content. If packets can not be obtained from these terminals within a predefined time, then the master client can contact the content server.
• the management server can be dedicated to several separate private networks.
• the private network comprises between 3 and 10 000 terminals, better between 10 and 10000 terminals.
• the number of slave terminals to which a content is pushed by a master client is for example between 2 and 50.
• the content to be broadcast is for example a video content, including an intervention filmed live or lightly deferred.
• the subject of the invention is also a computer program product, in particular for implementing the method according to the invention as defined above, comprising, on a computer medium or to be downloaded, a set of instructions that can be read by a management server, these instructions bringing during the execution of the program the management server to:
• the bandwidth with which this first terminal can connect to a content server is sufficient to allow the content to be broadcast to this first terminal by a direct connection thereof to the content server, list this terminal as a master client and cause the terminal to receive the content to be broadcast in particular via its connection to the content server,
• this first terminal to push at least a portion of the packets of the broadcast content received, to at least one other terminal of the private network
• the bandwidth with which this other terminal can connect to the content server is insufficient to allow the content to be broadcast to this other terminal, list this terminal as a slave client and cause the terminal to receive the content to be broadcast from the master client and / or at least one other slave terminal of the private network by data exchange within the private network.
• FIG. 1 illustrates the links that can exist between different entities of an organization, a remote content server and a management server,
• FIG. 2 gives an example of client profile assignment to users connecting to the management server
• FIG. 3 illustrates an example of exchanges of data within two terminals of the private network, the remote content server and the management server, and
• FIG. 4 illustrates the implementation of different broadcasting protocols within the same entity.
• FIG. 1 shows an example of an organization comprising several entities seeking to receive content broadcast by a content server CDN, also called content source or remote server.
• CDN content server
• FIG. 1 shows an example of an organization comprising several entities seeking to receive content broadcast by a content server CDN, also called content source or remote server.
• An EB management server is provided to implement the invention.
• the content server CDN can communicate with N branches of the organization, each grouping several branches, which can be broken down into several divisions.
• Each of the branches includes for example more than 1000 terminals, also called workstations, and communicates with the CDN server via a high-speed link, for example a public network, while some agencies communicate with their divisions by a private network having a low-rate link, for example 2.5 or 3MB / s. For example, each agency has between 10 and 30 terminals.
• Figure 1 there is shown a "divisionl" grouping six terminals. The number of terminals is given for illustrative purposes only and the invention applies to any type of organization regardless of the number of terminals and the distribution of these within the organization.
• Each branch can recover from the CDN server the multimedia content to be broadcast.
• the private networks of the various branches can communicate with each other for example by the public network by a high speed link.
• the management server EB is for example external to the private networks of the organization, as illustrated, and can communicate with them by the public network.
• Each terminal in the organization can connect to the EB management server using its web browser.
• the terminals In order to receive the content broadcast by the CDN server, the terminals first connect to the management server EB, which decides on the protocol that is implemented for a terminal to receive the video packets of the content broadcast by the CDN server.
• This protocol is made according to the resources, including the bandwidth, available to this terminal.
• Two different transmission protocols, called for the EB Protocol Suite (also called V2V) and EB SPV Protocol are implemented depending on the availability of bandwidth.
• the V2V exchange protocol is implemented to facilitate the reception of packets by the branches and relieve the CDN server.
• This V2V exchange protocol is of the peer-to-peer type and preferably in accordance with the teaching of patent application EP 3 156 920 A1 in the name of the applicant. It consists in serving the content to at least one client in client / server mode, in a format allowing its subsequent broadcast in P2P mode.
• the management server EB selects for each user, from all those who watch the same content, the best list of users who can retrieve the content with the best quality of service. This list is based on several parameters including geo location, connection quality and the connection network, the machine and the browser used, among other possibilities. In the absence of a strong real-time constraint, unlike the live streaming of television channels, the video packet recovery protocol policy is much more geared toward recovery between users with higher latency.
• the EB SPV Protocol is implemented to take into account the low available bandwidth and allows part of the content to be broadcast in push mode from a master terminal to one or more slave terminals, in a format that makes it possible to exchange them in P2P mode. between the slave terminals.
• the management server EB is arranged to determine with which protocol each terminal of the organization can or must operate.
• the management server causes this client to operate according to the V2V protocol.
• Another preferred method is the geolocation of the client, as will now be described with reference to FIG.
• step 11 connection peers corresponds to the connection of a client, for example after the beginning of the broadcast of the content by the server CDN.
• step 12 "Geolocalize Viewers"
• the client is located, thanks to its IP address.
• the management server EB can know in step 13 whether the client is in a band zone. passable enough or not, and can compare the resources available to terminals, so as to privilege in the role of master client those with the best resources.
• the terminal in question can join the "swarm” and receive the packets by the V2V protocol.
• the management server EB determines in step 16 the profile of the terminal as part of the implementation of the EB protocol SPV protocol.
• the number of master clients and priority slave clients may vary depending on the size of the network.
• Step 20 corresponds to a connection request "Join ()" sent by the Viewerl terminal to the EB management server "EB Server Manager”.
• the server EB interrogates in step 21 the DB database "geoloc Database”, which corresponds to the exchanges “Check_localization ()” "Send_Localization ()", and determines in view of the IP address or a different identifier of the client if, given the location of the user, the bandwidth is sufficient.
• the management server EB informs the user in step 22, and assigns in this example the profile SPV Master Client "Assign Profile (SPV)" and informs him that he will implement the V2V protocol "EB Protocol (on)”.
• the user Viewerl responds by asking the management server EB a list of users in step 23 "Get_Viewer_List ()", with which it will be able to exchange.
• the user Viewerl obtains in response from the management server EB in step 24 the list of users with whom he can exchange content packets by implementing the V2V protocol "Send_Viewer_list ()".
• the Viewerl user then operates in a V2V ("EB Protocol") mode. This includes obtaining packets in step 25 from the CDN content server "Get_Chunk ()", receiving them at step 26 "Send_chunk ()", as well as obtaining packages from other master client users in particular.
• V2V EB Protocol
• each master client will wait for a predefined time to receive a chunk missing from other master clients, and if it does not, it will download it directly from the content server.
• step 27 corresponds to a request to obtain a missing packet from one of the users of the list communicated in step 23, namely the Viewer2 user in FIG.
• the corresponding packet is communicated in step 28.
• the Viewerl user can also transmit to other clients in the list of missing packets, as illustrated by steps 29 and 30.
• Step 29 corresponds to a request by the Viewer2 terminal of a packet to the Viewerl terminal (Get_Chunk request (ID15)) and step 30 when the Viewerl terminal sends this packet (Send_Chunk (ID15)).
• the management server EB imposes a content broadcast mode according to the EB SPV Protocol, and informs the Viewer terminal 2 by the message 32 ("EB SPV Protocol (On)").
• This protocol implies the existence of at least one "master” terminal, also called “Super Viewer” (SPV) to ensure an internal server role vis-à-vis one or more slave terminals, also called “Slave Viewer” Or SLV. In the example shown, this is the Viewerl terminal. Its role will be to push the received video packets to the other terminals composing its "swarm".
• This master terminal is here supposed to already exist when connecting the Viewer2 client in step 31 to the management server EB.
• step 33 the user Viewer2 requests "Get_Viewer_list ()” the list of users composing the swarm to the management server EB and gets it in step 34 "Send_Vlist (VL [], SPV (ID))". This list also contains the address of the master client.
• the management server warns in step 35 the Viewerl master client "Hello ()". Then, the master client pushes "Push_Chunk ()" the packets in steps 36i, 36 2 , ... to the Viewer2 terminal, as they are available and able to be received by this Viewer2 slave client.
• the management server EB determines that the resources and in particular the bandwidth is sufficient, it informs the displayer terminal 2 of the state of the swarm in step 37 and assigns a profile to it in step 38, in this case that of priority slave client SPV '"Assign_Profile (SPV')" and it means that the broadcast protocol is the EB protocol SPV Protocol "EB SPV Protocol (on) ".
• the Viewer2 terminal then requests the EB management server in step 39 the list of users, it gets in step 40.
• the Viewer2 terminal can report to the master client in step 41, and obtains in stages 42i, 42 2 , ... the content packets ("chunks"), delivered in "push” mode by the Viewerl terminal.
• the management server EB determines that the resources of the Viewerl terminal are better than those of an existing master client "Swarm_state (Res_V2> R_SPV)", in this case Viewerl, then the management server EB assigns in step 43 to the Viewer2 terminal the profile of an SPV master client "Assign Profile (SPV)" and initiates the EB SPV protocol in step 44 "EB SPV Protocol (on)".
• Swarm_state Res_V2> R_SPV
• the master client Viewer2 then requests the management server EB in step 45 the list of users "Get_Viewer_list ()".
• the management server EB then sends in step 47 to the Viewer2 terminal the list of clients of the swarm "Send_Viewer_List ()".
• the Viewer2 terminal requires content server at step 48 of the content packets, which it obtains in step 49.
• the Viewerl terminal is indicated in step 49 the master client Viewer2 mode and can receive "push" packet content to steps 50i, 50 2, ...
• the library with the various protocols V2V and EB SPV Protocol can be in Javascript and retrieved on the browser of the terminal at the moment when it connects on the web page to recover the flow, namely that of the management server EB.
• the choice of the protocol and the profile of the user are fixed after the first exchange with the management server EB.
• the profile of the terminal as well as the protocol used may change during the viewing of the content, according to the instructions of the management server EB.
• the choice by the management server EB of the master terminal or terminals SPV can be made in order of connection to the network, as illustrated in FIG. 2, or according to its resources, as described with reference to FIG.
• the broadcasting of the content to several slave terminals can be carried out if necessary via several SVP master terminals, according to various parameters such as the bandwidth, the size of the network, the type of encoding of the content, among others.
• the SLV slave terminal profile is assigned to all the terminals constituting its swarm.
• One of these slave terminals can nevertheless be assigned a priority slave client profile SPV 'and become privileged to receive more video packets from the master client SPV than the other slave clients, so as to constitute a support solution to replace the SPV master terminal in case of "crash" or disconnection thereof, thus ensuring the continuity of the broadcast and preventing the video from freezing at other SLV slave terminals.
• FIG. 1 there is shown the private network corresponding to the "division", formed by a master terminal SPV1 which receives its packets from the CDN server by the V2V protocol.
• a network may require the presence of several priority slave terminals SPV '.
• the SPV master terminals can exchange packets with each other through the V2V protocol, as illustrated by the V2V arrows for SPV1 to SPV3 clients.
• the master terminal SPV 1 operates according to the protocol EB SPV Protocol with respect to slave terminals SLV1 to SLV5 and SPV'l and SPV'2 and thus pushes ("Push_packets") the packets of the video content to these slave terminals.
• the master terminal SPV2 pushes ("Push_packets") the packets to a set of terminals comprising five slave terminals SLV 1 to SLV5 and two priority slave terminals SPV'l and SPV'2.
• the master terminal SPV3 pushes ("Push_packets") the packets to a set of terminals comprising five slave terminals SLV1 to SLV5 and a priority slave terminal SPV'l.
• slave SLV terminals exchange what they have received via the V2V protocol.
• Each SPV master client receives the packets of content from the content server and other master clients with which it exchanges packets.
• Each master client can wait a predefined time for a package that is missing from other master clients. If at the end of this time, the requested packets are still missing, then it can request it from the CDN content server.
• the bandwidth with which the master clients exchange the packets between them or receive them from the content server is for example 60 Mb / s, and the content is divided into packets of 1M.
• the bandwidth with which the master clients exchange the packets between them or receive them from the content server is for example 60 Mb / s, and the content is divided into packets of 1M.
• FIG. 4 illustrates the possibility for two swarms to share a user, for example a slave client or a priority slave client.
• the priority slave client SVP'l of the swarm S2 exchanges packets at a time from the other clients of the swarm S2 and with the clients of the swarm S 1, and the slave client SLV3 of the swarm S3 exchanges packets at the same time from the other clients the S3 swarm as well as those of the S2 swarm.
• the choice of the shared client is decided dynamically by the management server according to the progress of the download of the content by each of the swarms. If between two swarms, one of them is more advanced in their download, then a slave client or priority slave of this swarm is shared with another swarm.
• FIG. 4 also illustrates the possibility of a fourth profile that may be present on the network, namely that of ordinary user OV, which corresponds to a terminal having sufficient bandwidth to obtain the content of the content server.
• CDN as well as to exchange with the SPV master clients according to the EB SPV protocol, but which are not connected to any SLV slave client.
• the master clients will have priority to receive the OV user packets that are advanced in the download, as well as the CDN content server to be able to serve the clients themselves. slaves connected to them.
• This operation has the effect of the presence of more advanced swarms than others.
• V2V or EB SPV protocol may provide for a change of resolution or a switchover to audio mode depending on the available bandwidth.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=63143197

Family Applications (1)

Country Status (4)

Family Cites Families (3)

• 2018
  • 2018-03-19 FR FR1852326A patent/FR3079099B1/fr active Active
• 2019
  • 2019-03-13 WO PCT/EP2019/056334 patent/WO2019179855A1/fr unknown
  • 2019-03-13 EP EP19709077.2A patent/EP3769535A1/de active Pending
  • 2019-03-13 US US16/982,845 patent/US20210058651A1/en not_active Abandoned

Also Published As

Similar Documents

Legal Events