EP3637682B1 - Dynamic content distribution in an enterprise network - Google Patents

Dynamic content distribution in an enterprise network Download PDF

Info

Publication number
EP3637682B1
EP3637682B1 EP19202105.3A EP19202105A EP3637682B1 EP 3637682 B1 EP3637682 B1 EP 3637682B1 EP 19202105 A EP19202105 A EP 19202105A EP 3637682 B1 EP3637682 B1 EP 3637682B1
Authority
EP
European Patent Office
Prior art keywords
group
content
node
piece
distribution
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
EP19202105.3A
Other languages
German (de)
English (en)
French (fr)
Other versions
EP3637682A2 (en
EP3637682A3 (en
Inventor
Marc E. Mosko
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.)
Palo Alto Research Center Inc
Original Assignee
Palo Alto Research Center Inc
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 Palo Alto Research Center Inc filed Critical Palo Alto Research Center Inc
Publication of EP3637682A2 publication Critical patent/EP3637682A2/en
Publication of EP3637682A3 publication Critical patent/EP3637682A3/en
Application granted granted Critical
Publication of EP3637682B1 publication Critical patent/EP3637682B1/en
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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1051—Group master selection mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies

Definitions

  • This disclosure is generally related to the field of content distribution. More specifically, this disclosure is related to a system and method for efficiently distributing content in an enterprise network.
  • An enterprise or large corporation may include a network of managed devices, such as cloud storage devices and printers, distributed across multiple sites.
  • a device manager may manage (e.g., configure and control) the devices in a local network of one of the sites. This device manager can be responsible for firmware updates, policy file distribution, or data transfers. These operations typically involve large file transfers to a large number of managed devices within the enterprise network.
  • a conventional device manager typically manages devices based on, e.g., a Simple Network Management Protocol (SNMP) query, which is based on the Internet Protocol (IP) addresses of the managed devices.
  • IP Internet Protocol
  • each device can be assigned an IP address by a Dynamic Host Configuration Protocol (DHCP) server based on a local address pool (e.g., from a set of private IP addresses).
  • DHCP Dynamic Host Configuration Protocol
  • the device manager conventionally resides within the same network, such as the same private IP sub-network and the local area network (LAN).
  • LAN local area network
  • the device manager may need to distribute large files across multiple subnets.
  • the device manager typically uses the existing networking framework and protocols to enable large-scale file distribution within the enterprise network.
  • solutions are directed toward topology-aware peer-to-peer content distribution solutions. These solutions estimate the network conditions between the participants to find suitable candidates for a specific file.
  • These solutions usually do not plan the distribution of a file.
  • the file may be distributed in the network based on demand.
  • these solutions are for the Internet, they are designed for widely distributed participants with minimum topological correlation.
  • a particular file might have a flash popularity and create a temporal interest correlation, but the topological correlation remains disperse. Therefore, these solutions may not serve an enterprise environment, which can have a high degree of topological and temporal correlation for planned use, such as firmware updates or operating system patches.
  • US 2014/0006597 describes managing hardware resources in a cloud scheduling environment which includes a zone controller.
  • the zone controller can manage groups of node servers in a cloud datacenter using a check-in service.
  • the check-in service allows server groups to be created automatically based on one or more hardware characteristics of the node servers, server health information, workload scheduling or facilities management parameters, and/or other criteria.
  • US 2013/0188521 describes a switch which includes a discovery module, a device management module, and a logical group management module.
  • the discovery module constructs a multicast query message for a first multicast group to which the computing system is registered.
  • the device management module extracts information about a remote switch from a query response message from the remote switch and constructs a client database, wherein a first entry in the client database contains the information extracted from the query response message.
  • the logical group management module associates the remote switch with a second multicast group.
  • Embodiments described herein provide a system for facilitating dynamic content distribution in an enterprise environment.
  • the embodiments described herein solve the problem of efficiently distributing large pieces of content in an enterprise environment by (i) planning the distribution of a large piece of content based on the topographical information of the enterprise environment; and (ii) facilitating deferrable and delegable content distribution in the enterprise environment.
  • a source device e.g., a device manager
  • a receiving device e.g., a managed device. If a piece of content, such as a firmware update, is sent to a large number of receiving devices, this process is repeated for each receiving device.
  • a piece of content such as a firmware update
  • Such a mode of distribution can cause a large amount of traffic in the networking infrastructure of the enterprise environment.
  • each transfer can be an individual transfer between a device pair, each transfer can be vulnerable to failure. As a result, the enterprise environment can face a non-trivial failure rate.
  • Embodiments described herein solve these problems by providing a content distribution system that can discover the topography of the enterprise environment, plan a distribution overlay for a piece of content, and use peer-to-peer technology to execute the transfer via the overlay.
  • the system can facilitate a security framework, a control framework, and a data transfer framework.
  • the security framework can provide security to both the control channel and the data channel.
  • a distinguished node can be responsible for controlling the system and is thus called the controller.
  • the role of the controller can be distributed over multiple devices (e.g., to have redundancy).
  • the controller can authenticate messages (e.g., using a public key system (RSA) and/or a symmetric key exchange).
  • RSA public key system
  • the control framework can use a set of messages, which can be commands, requests, responses, and notifications.
  • the commands can be issued from the controller, requests and notifications can be issued from devices, and responses follow commands or requests.
  • Each message can be signed by the sender and transported over the control channel.
  • the control channel can be implemented based on a message queue or Transmission Control Protocol (TCP) connections. They can use the control channel for monitoring, organizing, and controlling other devices.
  • the controller can instruct devices to take measurements, such as device configurations and network conditions, and provide the measurements to the controller.
  • the controller can determine the topographical information of the enterprise environment based on the measurements.
  • the controller can then plan efficient distribution paths for a specific piece of content from a source device (e.g., a storage server).
  • a source device e.g., a storage server
  • the data transfer framework can provide a file transfer protocol in the enterprise environment.
  • the controller can notify each managed device in the enterprise environment regarding which piece of content to request.
  • the controller can also notify a respective managed device of a timeframe for the piece of content (e.g., when to request and where to request from).
  • Managed devices can be configured with a priority value that indicates a priority for the request. For example, the priority can indicate which source device the managed device should request a piece of content from first.
  • the controller organizes a set of managed devices into a logical group (e.g., based on Internet Protocol (IP) subnets).
  • IP Internet Protocol
  • the controller can generate a distribution tree that includes a logical group as a node of the tree.
  • Each group can include one or more group heads responsible for obtaining the piece of content from an upstream node (i.e., the parent node of the tree).
  • the root of the tree can be the subnet that includes the source of the piece of content.
  • the group heads can deploy a block-based protocol that allows multiple group heads to simultaneously download unique blocks of the piece of content. For example, the group heads can begin downloading random blocks and coordinate with each other to avoid duplication. Alternatively, one group head can download the odd-numbered blocks, while the other can download the even-numbered blocks. Each block can include one or more data chunks (e.g., a unit of data based on which the piece of content can be divided).
  • the group heads can also incorporate pipelining. When an upstream node downloads a threshold amount of data, a downstream node can start retrieving that data even if the entire piece of content has not been downloaded by the upstream node.
  • MB 100 megabyte
  • Mbps megabytes per second
  • the system can include a deferrable and delegable content distribution technique in the enterprise environment.
  • the number of sources for a piece of content can be limited. That piece of content can be requested by a large number of managed devices, which operate as receiving nodes.
  • the source node can defer the delivery by indicating a timeline when the source can deliver the content to a receiving node.
  • the receiving node can request the piece of content at the time indicated by the deferral.
  • that node can start operating as a source node.
  • the original source node can delegate a request for that piece of content to that new source node. This allows a receiving device to choose a source node that can deliver the piece of content efficiently (e.g., can deliver the earliest).
  • FIG. 1A illustrates an exemplary enterprise environment supporting an efficient content distribution, in accordance with an embodiment of the present application.
  • An enterprise environment 100 can be distributed across a number of sites 112, 114, 116, 118, 120, and 122. These sites can be coupled to each other via a network 110, such as a local or a wide area network.
  • the wide area network can be the Internet.
  • the sites can also have direct connection with each other (e.g., with point-to-point optical fiber).
  • a site, such as site 112 can include multiple subnets 111 (e.g., 10.1.0.0/16) and 113 (e.g., 10.2.0.0/16).
  • site 114 can have one subnet (e.g., 10.3.3.0/24), which may span a sub-site 124 (e.g., a nearby smaller site under the same management).
  • site 120 can have one subnet (e.g., 10.7.0.0/16), which may span a sub-site 126. It should be noted that sub-sites 124 and 126 can also maintain their own sub-nets.
  • a source device 102 distributes large pieces of content via point-to-point communication to a receiving device. If a piece of content, such as a firmware update, is sent to a large number of receiving devices across the sites of enterprise environment 100, this process is repeated for each receiving device in each site. Such a mode of distribution can cause a large amount of traffic in network 110 of enterprise environment 100.
  • each transfer can be an individual transfer between a device pair, each transfer can be vulnerable to failure. As a result, enterprise environment 100 can face a non-trivial failure rate.
  • a content distribution system 150 that can discover the topography of enterprise environment 100, plan a distribution overlay for a piece of content, and use peer-to-peer technology to execute the transfer via the overlay.
  • System 150 can facilitate a security framework, a control framework, and a data transfer framework.
  • the security framework can provide security to both the control channel and the data channel.
  • a distinguished node 140 can be responsible for controlling the system and is thus called controller 140.
  • system 150 can be hosted on controller 140.
  • Enterprise environment 100 can include a plurality of controllers 140 and 142, which can facilitate high availability to each other. Controller 140 can authenticate messages (e.g., using a public key system and/or a symmetric key exchange).
  • the control framework provided by system 150 can use a set of messages, which can be commands, requests, responses, and notifications.
  • the commands can be issued from controller 140, requests and notifications can be issued from managed devices, such as devices 106 and 108, and responses follow commands or requests.
  • Each message can be signed by the sender and transported over the control channel. For example, if controller 140 sends a message to device 106, controller 140 can sign that message with a private key of controller 140.
  • the control channel can be implemented based on message queuing or TCP connections.
  • the control channel can be used for monitoring, organizing, and controlling other devices.
  • controller 140 can instruct managed devices to take measurements, such as device configurations and network conditions, and provide the measurements to controller 140.
  • Controller 140 can determine the topographical information of enterprise environment 100 based on the measurements. Controller 140 can then plan efficient distribution paths for a specific piece of content 160 from a source device 102. Controller 140 and source device 102 can be the same device or different devices.
  • the data transfer framework can provide a file transfer protocol in enterprise environment 100.
  • Controller 140 can notify each managed device in enterprise environment 100 regarding which piece of content to request. Controller 140 can also notify a respective managed device of a timeframe for content 160 (e.g., when to request and where to request from).
  • Managed devices can be configured with a priority value that indicates a priority for the request. For example, the priority can indicate which source device the managed device should request a piece of content from first.
  • controller 140 organizes a set of managed devices into a logical group based on one or more grouping criteria. Examples of a grouping criterion include, but are not limited to, an IP subnet, a local area network, and a spanning tree in a layer-2 network.
  • controller 140 can generate a distribution tree that includes a logical group as a node of the tree.
  • a respective site or sub-site is represented as a logical group and a highlighted arrow depicts each branch of the tree. Since site 112 has two subnets 111 and 113, they can be two different nodes on the tree. If a site or sub-site, such as sub-site 128, of enterprise environment 100 does not include a recipient for content 160, that sub-site is not included in the tree.
  • Each group can include one or more group heads (denoted with dashed circles) responsible for obtaining the piece of content from an upstream node (i.e., the parent node of the tree).
  • the group corresponding to subnet 111 can include source device 102 and managed device 104 as group heads.
  • the logical group corresponding to site 114 can include devices 106 and 108 as group heads
  • the logical group corresponding to site 116 can include devices 132 and 134 as group heads.
  • devices 102, 104, 106, 108, 132, and 134 can be referred to as group heads as well.
  • the root of the tree in this example is subnet 111, which includes source device 102 hosting content 160. It should be noted that controller 140 can plan a distribution tree for each piece of content, which can vary (e.g., based on source device and receiving devices).
  • controller 140 can calculate a Steiner tree (e.g., a minimum-cost tree) to generate the inter-group distribution tree.
  • some devices can be receiving devices (e.g., a recipient of content 160) and the other devices can operate as relay devices or dormant devices.
  • the Steiner tree can span all receiving devices, if needed, using some relay devices, to find the minimum-cost tree.
  • Controller 140 can calculate a minimum-cost tree using a combination of shortest paths. Controller 140 can determine the shortest paths from each receiving device to the source device in enterprise environment 100 using the topography information of enterprise environment 100. Controller 140 then determines the minimum cost single source directed spanning tree from all receiving devices to source device 102.
  • Controller 140 can determine the topography information of enterprise environment 100 based on one or more of: a user input and network discovery using measurements. Controller 140 can perform the network discovery by measuring the bandwidth and round-trip time between two subnets. To do so, source node 102 sends a series of packets of different lengths a number of times to each group head. Controller 140 determines the minimum response time for each packet size and calculates the linear regression on those values. Controller 140 also determines the bandwidth in bits per second and the round-trip time is in seconds. Controller 140 can aggregate multiple measurements via an exponential moving average to determine the bandwidth of a link.
  • Group heads are responsible for inter-group data transfer.
  • Group heads 106 and 108 can be logically coupled to upstream group heads 102 and 104.
  • group heads 132 and 134 can be logically coupled to upstream group heads 106 and 108. If a logical group does not have a sufficient number of receiving devices for content, that logical group may not have multiple group heads.
  • the logical group corresponding to sub-site 124 can include one group head 136.
  • controller 140 can divide content 160 into a number of blocks (e.g., each with a predefined number of data chunks of fixed size). Since group head 104 is in the same logical group of source 102, group head 104 first obtains content 160 from source 102.
  • group heads 106 and 108 can deploy a block-based protocol that allows both group heads to simultaneously download unique and non-overlapping blocks of content 160.
  • Group heads 106 and 108 can begin downloading random blocks and coordinate with each other to avoid duplication. If one group head, such as group head 108, fails during the transfer, group head 106 can continue downloading the remaining blocks.
  • group head 106 can download the odd-numbered blocks of content 160 from upstream group heads 102 and 104.
  • group head 106 can download a subset of the odd-numbered blocks of content 160 from group head 102, while downloading the rest from group head 104. In the same way, group head 108 can download the even-numbered blocks from upstream group heads 102 and 104.
  • Group heads 106 and 108 can exchange the unique blocks over their peer link to obtain each block and reconstruct a full copy of content 160.
  • Group head 106 can also download the odd-numbered blocks of content 160 from upstream group head 102, and group head 108 can then download the even-numbered blocks of content 160 from upstream group head 104.
  • Group heads can also incorporate pipelining. When group heads 106 and 108 have downloaded a threshold number of blocks, downstream group heads 132 and 134 can start retrieving those blocks even if content 160 has not been downloaded by upstream groups heads 106 and 108 in its entirety.
  • FIG. 1B illustrates exemplary inter-group and intra-group distributions of content in an enterprise environment, in accordance with an embodiment of the present application.
  • Controller 140 can generate a distribution tree 170 for distributing content 160.
  • Distribution tree 170 can include logical groups 162, 164, 166, 168, 172, 174, and 176 as nodes of tree 170.
  • Logical groups 162, 164, 166, 168, 172, 174, and 176 can correspond to subnet 111, site 114, sub-site 124, site 116, subnet 113, site 122, and site 120, respectively.
  • Controller 140 can determine at least two managed devices, which can be receiving devices or relaying devices, as group heads.
  • Source 102 and device 104 can be group heads for group 162, devices 106 and 108 can be group heads for group 164, device 136 can be group heads for group 166, and devices 132 and 134 can be group heads for group 168.
  • the inter-group links can be formed between the group heads.
  • the links between groups 162 and 164 are between group heads 102 and 104 of group 162, and group heads 106 and 108 of group 164.
  • group 166 includes one group head 136, the links between groups 164 and 166 are between group heads 1 06 and 108 of group 164, and group head 136 of group 166.
  • a group can be an intermediary group, such as group 174 corresponding to site 122.
  • a group head can be an intermediary operating as a relay or a receiving device.
  • group heads 144 and 146 of group 174 can be intermediary group heads that facilitate the establishment of data transfer from group 172 to group 176.
  • Each group head can maintain a link with each upstream group head (e.g., each parent group head).
  • group head 136 can have a link to each of group heads 106 and 108.
  • Group heads within a group can have a full peer relationship with each other with a corresponding peer link, which allows them to transfer data using peer-to-peer transfer protocol to coordinate data blocks.
  • group heads 106 and 108 can maintain a full pair relationship.
  • Group heads 106 and 108 can coordinate between themselves to avoid downloading the same block more than once on the inter-group links. If content 160 is divided into blocks 181, 182, 183, and 184, group head 106 can download blocks 181 and 183, and group head 108 can download blocks 182 and 184 from upstream group heads 102 and 104.
  • Group head 106 then obtains blocks 182 and 184 from group head 108 via the peer link, and group head 108 can obtain blocks 181 and 183 from group head 106 via the peer link.
  • group heads 106 and 108 can be configured with a higher preference to obtain blocks from peer links.
  • Each of group heads 106 and 108 then combines blocks 181, 182, 183, and 184 to generate content 160.
  • a number of managed devices can obtain content 160 from group heads 132 and 134.
  • controller 140 creates a distribution hierarchy rooted at group heads 132 and 134.
  • the hierarchy can be represented as an n -ary tree where each managed device is coupled to p upstream parent nodes in the n -ary tree.
  • one link can be the active link and the others can operate as standby links for facilitating redundancy.
  • Each managed device can download blocks 181, 182, 183, and 184 from the active parent node.
  • the network within a logical group can be a high-speed local area network (LAN).
  • LAN local area network
  • group heads 132 and 134 can use LAN broadcast to transfer blocks 181, 182, 183, and 184 to all managed device in group 168.
  • controller 140 can notify each managed device regarding the time and schedule of the distribution of content 160. Controller 140 can expect the peer-to-peer protocol to connect to the upstream device to subscribe to content 160, and wait until that upstream device obtains at least a threshold number of blocks. If the upstream device has downloaded the threshold number of blocks, a downstream device can start downloading those blocks from the upstream device.
  • FIG. 2 illustrates an exemplary system architecture that facilitates efficient distribution of content in an enterprise environment, in accordance with an embodiment of the present application.
  • controller 140 and a respective managed device include the principle operational modules controller module 200 and managed device module 250, respectively.
  • Controller module 200 operates based on registration module 202, key module 204, grapher module 206, scheduler module 214, and planner module 208.
  • managed device module 250 can operate based on registration module 252, key module 254, measurement module 256, and transfer module 258.
  • registration module 202 can listen for registration requests and unregister request messages from managed devices. Based on the requests, registration module 202 maintains information of a current set of devices and subnets in enterprise environment 100 in a node database 212.
  • Key module 204 can listen for key request messages from managed devices and perform key exchange, such as Ephemeral Elliptic Curve Diffie Hellman, using message queuing. Key module 204 also updates controller 140's KeyRing with symmetric keys, such as hash-based message authentication code (HMAC).
  • Grapher module 206 can listen for the measurement response messages, and based on these messages, maintains a weighted subnet-to-subnet graph of enterprise environment 100.
  • Scheduler module 214 periodically schedules measurements between subnets to measure network performance and properties. Scheduler module 214 also maintains a table indicating the edges between the subnets in node database 212.
  • Planner module 208 determines, for a piece of content, the source device and target subnets, which include receiving devices, based on the currently registered devices and schedules experiments to determine a distribution tree. Planner module 208 initiates distribution of the piece of content by generating a distribution plan and storing it in a plan database 216. Planner module 208 can receive notification from the managed devices regarding the distribution.
  • registration module 252 sends periodic registration request messages to controller 140 and listens for responses.
  • Key module 254 periodically generates new keys by sending a key exchange request message and listens for corresponding responses.
  • Key module 254 can also update managed device 106's KeyRing with the HMAC keys.
  • Measurement module 256 can listen for initialization of the network measurement. Based on that, measurement module 256 can schedule network measurement and sends the measurements to grapher module 206.
  • Transfer module 258 listens for a message from controller 140 initializing the distribution of a piece of content and schedules peer-to-peer transfers via a peer-to-peer protocol 260.
  • Transfer module 258 can send the responses to acknowledge the transfer initialization message and notifies controller 140 regarding significant events (e.g., starting, finishing, detection of error, etc.).
  • Protocol 260 performs a peer-to-peer file transfer under the control of planner module 208.
  • FIG. 3A presents a flowchart 300 illustrating a method of a content distribution system determining topographical information of an enterprise environment, in accordance with an embodiment of the present application.
  • the system determines an IP subnet in an enterprise environment (operation 302) and determines the managed devices in the subnet (operation 304).
  • the system issues a measurement command for a respective managed device (operation 306) and receives measurements from a respective managed device (operation 308).
  • the measurement command instructs the managed device to measure network and device conditions (e.g., bandwidth, latency, utilization, etc.), and report back to the system.
  • the system generates a weighted sub-graph of the IP subnet and updates the edge information based on the received measurement (operation 310).
  • the system checks whether all subnets have been checked (operation 312). If checked, the system generates a weighted overlay graph of the enterprise network (operation 314). Otherwise, the system continues to determine the next IP subnet in the enterprise environment (operation 302).
  • FIG. 3B presents a flowchart 350 illustrating a method of a content distribution system planning the distribution of a piece of content based on the topographical information of an enterprise environment, in accordance with an embodiment of the present application.
  • the system identifies a logical group in the enterprise environment (e.g., based on a subnet or a site) (operation 352) and determines whether the source device of the piece of content is in the logical group (operation 354). If the source device is in the logical group, the system determines the source device as a group head for the logical group (operation 356).
  • the system determines whether the group head selection has completed (e.g., a predetermined number, such as two, of group heads has been selected or no more devices to select) (operation 358). If group head selection is not completed, the system checks whether any receiving device for the piece of content is available in the logical group (operation 360).
  • the system randomly selects a receiving device as a group head for the logical group (operation 362). Otherwise, the system randomly selects a relay device as a group head for the logical group (operation 364).
  • the system continues to determine whether the group head selection has completed (operation 358). If group head selection is completed, the system generates inter-group and intra-group distribution trees (operation 366) and configures the group heads for intra-group and inter-group distribution (operation 368). This configuration can include configuring block-based protocol.
  • FIG. 4A presents a flowchart 400 illustrating a method of a content distribution system determining an inter-group distribution tree in an enterprise environment, in accordance with an embodiment of the present application.
  • the system represents a logical group as a logical node (operation 402) and computes the shortest path between a respective logical node and the source logical node (i.e., the logical node associated with the source device) (operation 404).
  • the system generates an auxiliary graph based on the computed shortest paths (operation 406) and computes a minimum-cost single source spanning tree rooted at the source logical node (operation 408).
  • the system determines the physical paths between a respective logical node pair on the spanning tree based on the corresponding group heads (operation 410).
  • FIG. 4B presents a flowchart 430 illustrating a method of a group head obtaining a file via an inter-group distribution tree in an enterprise environment, in accordance with an embodiment of the present application.
  • the group head receives a transfer command, a file descriptor, and a schedule associated with a piece of content from the controller (operation 432).
  • the group head determines a subset of unique blocks of the piece of content to be retrieved from the upstream group heads and allocates a source group head (e.g., from the upstream group heads) for a respective block in the subset (operation 434).
  • the group head determines whether a threshold number of blocks is available in the upstream group heads (operation 436). This allows pipelined download of the piece of content.
  • the group head continues to determine whether a threshold number of blocks is available in the upstream group heads (operation 436). On the other hand, if a threshold number of blocks is available (operation 438), the group head obtains a respective block in the subset from the corresponding source group head (operation 440). The group head obtains the rest of the blocks, if any, from a peer group head (442). It should be noted that some logical group can have a single group head, which would retrieve each block from the upstream group heads. The group head then combines the obtained blocks to reconstruct the piece of content (operation 444) and performs the operation indicated in the transfer command (e.g., a firmware update) on the piece of content (operation 446).
  • the transfer command e.g., a firmware update
  • FIG. 4C presents a flowchart 450 illustrating a method of a content distribution system determining an intra-group load-sharing distribution tree in a logical group, in accordance with an embodiment of the present application.
  • the system determines levels for a respective receiving device in a logical group such that group heads are at an initial level and each level has a specified number of devices (operation 452). It should be noted that all devices in a level may not be receiving devices; some devices can be relay devices.
  • the system selects the next level for establishing connections (operation 454). For each level at the selected level, the system couples devices to a predetermined number of devices in the previous level (e.g., the upstream devices) with corresponding edges (operation 456). If there are more levels (operation 458), the system continues to select the next level for establishing connections (operation 454). Otherwise, the system forms a load-sharing distribution tree (e.g., an n-ary tree) based on the established connections (operation 460).
  • a load-sharing distribution tree e
  • FIG. 4D presents a flowchart 470 illustrating a method of a receiving device obtaining a file via an intra-group load-sharing distribution tree in a logical group, in accordance with an embodiment of the present application.
  • the receiving device receives a transfer command and a file descriptor associated with a piece of content from an upstream device in a load-sharing distribution tree (operation 472).
  • the receiving device obtains a respective block of the piece of content from an active upstream device (operation 474) and combines the obtained blocks to reconstruct the piece of content (operation 476).
  • the receiving device then performs the operation indicated in the transfer command (e.g., a firmware update) on the piece of content (operation 478).
  • the transfer command e.g., a firmware update
  • a large number of receiving devices obtain a piece of content from a limited number of sources.
  • a source device can delegate a request for the piece of content to a receiving device that has already received the piece of content.
  • a source device such as source device 102 of content 160 can delegate the request locally (e.g., without intervention from controller 140).
  • Source device 102 can also defer the request for a later time.
  • the receiving device can resend a request at the deferred time.
  • network environment 100 can facilitate a decentralized system that can defer and delegate the requests.
  • FIG. 5A illustrates an exemplary deferrable content distribution in enterprise environment, in accordance with an embodiment of the present application.
  • a number of receiving nodes 550 can discover that a piece of content 570 is hosted in a number of source nodes 500, including source nodes 502, 504, and 506.
  • Receiving nodes 550 can discover content 570 by one or more of: an advertisement from source nodes 500 indicating the presence of content 570 and an external input (e.g., from a user).
  • Each source node of source nodes 500 can have respective resource limits and, hence, can serve a limited number of receiving nodes.
  • receiving node 508 can request content 570 from source nodes 502, 504, and 506 (operation 512).
  • a source node can (a) serve the request immediately, (b) accept the request for a later service, (c) delegate the job to another node, or (d) reject the request.
  • a respective source node determines, based on a scoreboard of current and reserved timeslots, one of the response options to ensure that, statistically, the source node is not oversubscribed.
  • source nodes 502, 504, and 506 can maintain scoreboards 503, 505, and 507, respectively, and determine a response option (operation 514).
  • source node 502 can reject the request and notify receiving node 508 (operation 516).
  • Source node 502 can include an indication whether it can service the request at a later time.
  • source node 504 can issue a token that grants receiving node 508 access to content 570 for a specific time window and marks a pending status in scoreboard 505 (operation 518).
  • source node 506 can issue a token that grants receiving node 508 access to content 570 for a specific time window and marks a pending status in scoreboard 507 (operation 520).
  • the token can be a cryptographic data structure authenticated by the issuing source node.
  • a token is issued with an offer (e.g., the time window) for a specific receiving node by a specific source node.
  • the token issued by source node 504 can identify receiving node 508 based on an IP address of receiving node 508 and issuing source node 504 based on a key of source node 504 that authenticates the token.
  • Receiving node 508 compares the tokens from source nodes 504 and 506 to determine the efficient option for source node 508 (operation 522). Examples of an efficient option include, but are not limited to, minimum delay and least cost. Receiving node 508 can either accept an offer or reject it. Suppose that receiving node 508 accepts the offer from source node 506 (operation 524). Source node 506 can then update scoreboard 507 by changing the pending indicator to a permanent indicator against the offered time window (operation 528). On the other hand, receiving node 508 rejects the offer from source node 504 (operation 526). Source node 504 can then update scoreboard 505 by removing the pending indicator (operation 530).
  • an offer can have a time limit and receiving node 508 needs to confirm the offer within that time limit.
  • Source node 504 can use the confirmation to manage scoreboard 507.
  • Receiving node 508 can defer accepting an offer up to the time limit. Receiving node 508 can also accept an offer and later cancel the offer if receiving node 508 receives a better offer.
  • Receiving node 508 Upon waiting for a period of time indicated by the time window of the token (operation 532), receiving node 508 can be ready to use the token.
  • Receiving node 508 submits the token to source node 506 (operation 534). If source node 506 is ready to serve the request, source node 506 can allocate a data channel for receiving node 508 (operation 536).
  • source node 506 can issue a data channel identifier to receiving node 508.
  • the data channel identifier represents how to access content 570 with the token. Examples of the data channel identifier can include, but are not limited to, a Uniform Resource Identifier (URI), an IP address and port number pair, or a media access control (MAC) address.
  • Source node 506 can also issue a new token with the data channel identifier. The new token can be tied to the data channel identifier.
  • Receiving node 508 can obtain content 570 via the allocated data channel (operation 538). To do so, receiving node 508 can submit the token, which can be the original token or the new token, via the data channel to source node 506 for verification. Upon verification, source node 506 can initiate the transfer if source node 506 is ready to do so and has the capacity.
  • the data channel can be the same network connection that facilitates the request channel.
  • receiving node 508 may submit tokens at least twice: once to request the channel and once on the data channel.
  • source node 506 may construct the data channel identifier uniquely for receiving node 508 and include information in the first token that would only verify the data channel identifier. In other words, source node 506 can bind the first token to the data channel identifier during the generation process, but may not provide the data channel identifier to receiving node 508 until the token is submitted.
  • source nodes 500 can offer tokens with a priority level, such as bronze, silver, and gold level services.
  • source node 506 would only offer gold-level tokens if source node 506 can service that token.
  • source node 506 may oversubscribe silver- or bronze-level tokens.
  • the higher priority offers can create an artificial ceiling on scoreboard 507 for the number of accepted tokens on the data channel. For example, if source node 506 can service ten requests, source node 506 may offer three gold-level, five silver-level, and two bronze-level tokens. If source node 506 supports job preemption, source node 506 could significantly oversubscribe lower priority tokens with the allowance that a lower priority token could be preempted.
  • the request channel and the data channel may not be short-lived connections.
  • Requesting node 508 may stay connected to source node 506's request channel for a time up to a threshold amount of time.
  • requesting node 508 may stay connected to source node 506's data channel up to a threshold amount of time, but can only submit a request at the rate allowed by the tokens.
  • source node 506 can present the token and the data channel identifier.
  • FIG. 5B illustrates an exemplary delegable content distribution in an enterprise environment, in accordance with an embodiment of the present application.
  • Source node 506 can delegate the distribution of content 570 upon receiving a new request or when a token is submitted. For example, source node 506 can determine that receiving node 510 has obtained content 570 and receiving node 508 can obtain content 570 more efficiently from receiving node 510.
  • source node 506 can use two mechanisms for the delegation. In a first way, source node 506 can offer receiving node 510 as another source node, and receiving node 508 requests content 570 from receiving node 510, considering it a source node.
  • source node 506 can maintain a scoreboard for each receiving node that has already downloaded content 570.
  • source node 506 can maintain a scoreboard 511 for receiving node 510.
  • Source node 506 can issue tokens and data channel identifiers that redirect receiving node 508 to receiving node 510's data channel. In that case, source node 506 and receiving node 508 can share a cryptographic key to authenticate the redirection.
  • Source node 506 may use an existing protocol, such as OAuth 2.0, or source node 506 and receiving node 508 may agree on a key.
  • receiving node 510 can notify source node 506 regarding the completion of the transfer of content 570 (operation 552). This may cause source node 506 to create a scoreboard 511 for receiving node 510 (operation 554).
  • receiving node 508 submits the token (operation 534)
  • source node 506 can notify receiving node 508 regarding the delegation of the distribution of content 570 to receiving node 510 with a new token (operation 556).
  • Receiving node 508 can submit the new token to receiving device 510 (operation 558).
  • receiving device 510 can allocate its data channel to receiving device 508 (operation 560). Receiving node 508 can obtain content 570 via the allocated data channel from receiving node 510 (operation 562).
  • source node 506 may run a time service such that all requests have the current producer time.
  • receiving node 508 can request source node 506's time. This allows receiving node 508 to synchronize a token to source node 506's clock even if source node 506 and receiving node 508 do not have synchronized clocks.
  • Receiving node 508 can use more a sophisticated clock synchronization mechanism, such as requesting source node 506's time at specific time intervals to determine the clock skew between oscillators. This allows these nodes to accurately derive a future time. These mechanisms use virtual times (or oscillators) for each source node and do not need to reset the actual operating system time or hardware clock. If a request is delegated to receiving node 510, receiving node 510 can keep a virtual clock corresponding to source node 506. This allows receiving node 510 to authorize tokens with source node 506's clock.
  • FIG. 6A presents a flowchart 600 illustrating a method of a source node providing a piece of content to a receiving node, in accordance with an embodiment of the present application.
  • the source node receives a channel request for a piece of content and checks the scoreboard to determine an option (operation 602). The source node determines whether to accept the request (operation 604). If accepted, the source node determines the acceptance type (operation 606). If the acceptance is immediate, the source node can issue a token for an immediate distribution (operation 608). If the acceptance is deferred, the source node can issue a token for a deferred distribution for a deferred timeline (operation 610).
  • the source node Upon issuing the token (operation 608 or 610), the source node can receive a token submission (operation 612). The source device can decide whether to delegate the request (operation 614). If the acceptance type is delegation (operation 606) or the source device has delegated the token submission (operation 614), the source node can issue a new token for the delegated node (operation 616). If the source device has not delegated the token submission (operation 614), the source node allocates a channel (and a new token) to the receiving node, receives a request for the piece of content (e.g., based on the new token), and initiates the distribution (operation 618). If the request is not accepted (operation 604), the source node issues a rejection to the receiving node (operation 620).
  • FIG. 6B presents a flowchart 630 illustrating a method of a receiving node obtaining a piece of content from a source node, in accordance with an embodiment of the present application.
  • the receiving node sends a request for a piece of content to a set of source nodes (operation 632) and determines a subset of source node(s) that have accepted the request based on the received token(s) (operation 634).
  • the receiving node analyzes the token(s) to select a source node with an efficient offer (operation 636), and notifies the selected source node with an acceptance and all other nodes in the subset with a rejection (operation 638).
  • the receiving node determines the type of the token (operation 640).
  • the receiving node waits for a deferred period of time based on the token (operation 642). If the token type is immediate (operation 640) or upon waiting for the period of time (operation 642), the receiving node sends a channel request based on the token to the selected source node (operation 644) and checks whether it has received a new delegated token (operation 646). If not, the receiving node receives a channel identifier and initiates the content retrieval on the corresponding channel (operation 648).
  • the receiving node receives a channel identifier of the delegated node, and sends a channel request based on the token and the channel identifier to the delegated node (operation 650).
  • FIG. 6C presents a flowchart 660 illustrating a method of a delegated node providing a piece of content to a receiving node, in accordance with an embodiment of the present application.
  • the delegated node which can be another receiving node, receives a channel request based on a token and a channel identifier (operation 662), and verifies the token to determine validity (operation 664).
  • the delegated node then allocates channel corresponding to the channel identifier (operation 666).
  • the delegated node receives a request for the piece of content and initiates the distribution (operation 668).
  • FIG. 7 illustrates an exemplary computer system that facilitates efficient content distribution in an enterprise environment, in accordance with an embodiment of the present application.
  • Computer system 700 includes a processor 702, a memory device 704, and a storage device 708.
  • Memory device 704 can include a volatile memory device (e.g., a dual in-line memory module (DIMM)).
  • DIMM dual in-line memory module
  • computer system 700 can be coupled to a display device 710, a keyboard 712, and a pointing device 714.
  • Storage device 708 can store an operating system 716, a content distribution system 718, and data 736.
  • Content distribution system 718 can facilitate the operations of one or more of: controller 140, source device 102, group heads 104, 106, 108, 144, and 146, source device 506, and receiving devices 508 and 510.
  • Content distribution system 718 can include instructions, which when executed by computer system 700 can cause computer system 700 to perform methods and/or processes described in this disclosure. Specifically, content distribution system 718 can include instructions for maintaining information of a current set of devices and subnets in the enterprise environment in a node database (registration module 720). Content distribution system 718 can also include instructions for discovering topographical information of the enterprise environment based on measurements (measurement module 722). Furthermore, content distribution system 718 can also include instructions for planning the distribution of a piece of content in the enterprise environment based on an inter-group distribution tree and an intra-group distribution tree (planner and transfer module 724).
  • content distribution system 718 can also include instructions for distributing the piece of content via these trees (planner and transfer module 724).
  • Content distribution system 718 can include instructions for generating an immediate, deferred, or delegated token for distributing a piece of content (token module 726).
  • Content distribution system 718 can further include instructions for allocating a channel based on the token (channel module 728).
  • Content distribution system 718 may further include instructions for sending and receiving messages (communication module 730).
  • Data 736 can include any data that can facilitate the operations of content distribution system 718.
  • FIG. 8 illustrates an exemplary apparatus that facilitates efficient content distribution in an enterprise environment, in accordance with an embodiment of the present application.
  • Content distribution apparatus 800 can comprise a plurality of units or apparatuses which may communicate with one another via a wired, wireless, quantum light, or electrical communication channel.
  • Apparatus 800 may be realized using one or more integrated circuits, and may include fewer or more units or apparatuses than those shown in FIG. 8 .
  • apparatus 800 may be integrated in a computer system, or realized as a separate device that is capable of communicating with other computer systems and/or devices.
  • apparatus 800 can comprise units 802-812, which perform functions or operations similar to modules 720-730 of computer system 700 of FIG. 7 , including: a registration unit 802; a measurement unit 804; a planner and transfer unit 806; a token unit 808; a channel unit 810; and a communication unit 812.
  • the data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system.
  • the computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disks, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.
  • the methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above.
  • a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.
  • the methods and processes described above can be included in hardware modules.
  • the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), and other programmable-logic devices now known or later developed.
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate arrays
  • the hardware modules When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
EP19202105.3A 2018-10-10 2019-10-08 Dynamic content distribution in an enterprise network Active EP3637682B1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/156,565 US10862962B2 (en) 2018-10-10 2018-10-10 Dynamic content distribution in an enterprise network

Publications (3)

Publication Number Publication Date
EP3637682A2 EP3637682A2 (en) 2020-04-15
EP3637682A3 EP3637682A3 (en) 2020-07-29
EP3637682B1 true EP3637682B1 (en) 2021-08-11

Family

ID=68295933

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19202105.3A Active EP3637682B1 (en) 2018-10-10 2019-10-08 Dynamic content distribution in an enterprise network

Country Status (3)

Country Link
US (1) US10862962B2 (ja)
EP (1) EP3637682B1 (ja)
JP (1) JP7295752B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220188167A1 (en) * 2020-12-14 2022-06-16 Dell Products, Lp System and method to adapt memory usage of containerized workspaces

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7013389B1 (en) * 1999-09-29 2006-03-14 Cisco Technology, Inc. Method and apparatus for creating a secure communication channel among multiple event service nodes
US6983317B1 (en) * 2000-02-28 2006-01-03 Microsoft Corporation Enterprise management system
US6748447B1 (en) * 2000-04-07 2004-06-08 Network Appliance, Inc. Method and apparatus for scalable distribution of information in a distributed network
JP3904885B2 (ja) * 2000-11-30 2007-04-11 富士通株式会社 データの配布経路を生成する装置および方法
US7801857B2 (en) * 2003-12-19 2010-09-21 Solace Systems, Inc. Implicit routing in content based networks
US8688803B2 (en) * 2004-03-26 2014-04-01 Microsoft Corporation Method for efficient content distribution using a peer-to-peer networking infrastructure
US20080072035A1 (en) * 2005-01-31 2008-03-20 Johnson Robert A Securing multicast data
US8751605B1 (en) * 2006-11-15 2014-06-10 Conviva Inc. Accounting for network traffic
US8140479B2 (en) * 2006-12-21 2012-03-20 International Business Machines Corporation Logical classification of objects on a computer system
JP4504415B2 (ja) * 2007-12-21 2010-07-14 富士通株式会社 ネットワーク機器管理プログラム
WO2010120281A1 (en) * 2009-04-14 2010-10-21 Alcatel-Lucent Usa Inc. Method and apparatus for distributed media conferencing
US8918835B2 (en) * 2010-12-16 2014-12-23 Futurewei Technologies, Inc. Method and apparatus to create and manage virtual private groups in a content oriented network
US9935781B2 (en) * 2012-01-20 2018-04-03 Arris Enterprises Llc Managing a large network using a single point of configuration
US9207988B2 (en) * 2012-06-29 2015-12-08 Intel Corporation Method, system, and device for managing server hardware resources in a cloud scheduling environment
EP2819364A1 (en) * 2013-06-25 2014-12-31 British Telecommunications public limited company Content distribution system and method
JP6229743B2 (ja) * 2016-02-17 2017-11-15 コニカミノルタ株式会社 データ配信システム、データ配信方法、データ処理装置およびコンピュータプログラム
US10045203B2 (en) * 2016-08-27 2018-08-07 Verizon Patent And Licensing Inc. Enterprise software/firmware management and distribution
EP3934203A1 (en) * 2016-12-30 2022-01-05 INTEL Corporation Decentralized data storage and processing for iot devices

Also Published As

Publication number Publication date
US20200120156A1 (en) 2020-04-16
US10862962B2 (en) 2020-12-08
JP7295752B2 (ja) 2023-06-21
JP2020061135A (ja) 2020-04-16
EP3637682A2 (en) 2020-04-15
EP3637682A3 (en) 2020-07-29

Similar Documents

Publication Publication Date Title
EP3654619B1 (en) A dynamic content distribution protocol for an enterprise environment
US10541877B2 (en) Dynamic reservation protocol for 5G network slicing
JP7365610B2 (ja) モバイル輸送環境の予測可能なスケジュールに基づいて、データをインテリジェントにキャッシュするためのシステム及び装置
Singh et al. Jupiter rising: A decade of clos topologies and centralized control in Google's datacenter network
US20180337892A1 (en) Scalable proxy clusters
US8321862B2 (en) System for migrating a virtual machine and resource usage data to a chosen target host based on a migration policy
CN111612466B (zh) 一种共识和资源传输方法、设备及存储介质
EP3688934B1 (en) Migrating services in data communication networks
US9743367B2 (en) Link layer discovery protocol (LLDP) on multiple nodes of a distributed fabric
CN115037624A (zh) 全局网络状态管理
EP2949084A2 (en) Scalable transport for multicast replication and scalable object storage using multicast transport
WO2012058915A1 (zh) 一种路径计算方法及系统、节点设备
Zheng et al. LazyCtrl: A scalable hybrid network control plane design for cloud data centers
EP3637682B1 (en) Dynamic content distribution in an enterprise network
WO2018036521A1 (zh) 资源调整方法、装置及系统
Luo et al. Efficient multisource data delivery in edge cloud with rateless parallel push
WO2016206470A1 (zh) 一种自动交换光网络资源控制方法、装置和计算机可读存储介质
CN103685497A (zh) 一种在线存储共享方法和系统
US9804907B2 (en) Remote procedure call for a distributed system
JP2024505147A (ja) ファブリック可用性および同期化
US20210168074A1 (en) Methods and systems for identifying optimal network paths within an association
Cui et al. Optimizing P2P streaming throughput under peer churning
EP3651415B1 (en) Network measurement in an enterprise environment
CN115242646B (zh) 一种基于区块链的网络切片应用方法以及相关装置
US11522845B2 (en) Methods and systems for automatically and securely joining an association

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

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

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

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

AX Request for extension of the european patent

Extension state: BA ME

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

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

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/18 20060101AFI20200619BHEP

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

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

17P Request for examination filed

Effective date: 20210129

RBV Designated contracting states (corrected)

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

INTG Intention to grant announced

Effective date: 20210310

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

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602019006769

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Ref country code: AT

Ref legal event code: REF

Ref document number: 1420506

Country of ref document: AT

Kind code of ref document: T

Effective date: 20210915

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20210811

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1420506

Country of ref document: AT

Kind code of ref document: T

Effective date: 20210811

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602019006769

Country of ref document: DE

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

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

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

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

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

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

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

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

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20211031

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

26N No opposition filed

Effective date: 20220512

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

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

Ref country code: BE

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

Effective date: 20211031

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

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

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

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

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

Ref country code: CH

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

Effective date: 20221031

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

Ref country code: DE

Payment date: 20230920

Year of fee payment: 5

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

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

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

Ref country code: GB

Payment date: 20240919

Year of fee payment: 6

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

Ref country code: FR

Payment date: 20240919

Year of fee payment: 6