Dynamic advertisement delivery over multiple multicast channels

Abstract

Examples described address the scenario where multiple multicast channels are used to deliver advertisements to client devices, with the aim to optimise the usage of the advertisements. The examples use knowledge of which advertisements each client device needs, to determine which advertisements to deliver on each multicast channel, and which multicast channel each client should join. In this scenario, there are multiple multicast channels, and a large number of advertisements, together with numerous client advertisement requirements, which means that finding an optimum solution for the scheduling of advertisement delivery is computationally extremely challenging. The examples present a simple but effective solution.

Description

[0001] A36161

[0002] DYNAMIC ADVERTISEMENT DELIVERY OVER MULTIPLE MULTICAST CHANNELS

[0003] Field of the Invention

[0004] This invention relates to the field of managing the delivery of advertisements in a network to client devices, where the delivery is optimised by determining which advertisements should be delivered over a given multicast channel and the timing of the deliveries.

[0005] Background to the Invention

[0006] Video content is currently delivered to a range of user devices using unicast delivery, where a single stream of data is transmitted specifically for each individual user. Often, web (HTTP) technology is used for content delivery, where content is segmented into short content segment files, of typical duration six to ten seconds, enabling each content segment file to be requested and delivered by HTTP.

[0007] However, HTTP is delivered over unicast (one to one) transport and so is inefficient for delivering the same content at the same time to many receivers. Multicast (one to many) transport would be far more efficient. Yet multicast is rarely used for any services other than network operators’ on-net linear channels delivered to their own set-top boxes. The reason for this is that multicast does not lend itself to open use on the Internet.

[0008] To bring the benefits of multicast scalability to HTTP-based Internet media streaming, a class of techniques known as Multicast-Adaptive Bitrate (mABR) is being investigated and standardised.

[0009] Multicast-Adaptive Bitrate (m-ABR) is a relatively new technology. It aims to allow more efficient delivery of ABR content over networks by enabling the use of multicast for content streams where many clients are requesting the same content at about the same time.

[0010] One ambition of many m-ABR systems is to deploy multicast and enable m-ABR without any change to the client device and the client application that are already supporting HTTP (unicast) streaming. This can be achieved using a hybrid approach that uses a combination of both multicast and unicast delivery, where a proxy is inserted between the client device and the content server. The proxy can inspect content requests from theA36161

[0011] client device, and when appropriate, join to a multicast channel, receive multicast content, and provide this content to the client, packaged to look like unicast delivered content.

[0012] The present Applicant has developed its own improved hybrid m-ABR techniques known as Multicast Assisted Unicast Delivery (MAUD).

[0013] At the same time, the methods by which advertising content is delivered for presentation within programming is also changing. Dynamic advertising is a relatively new technology, but one that is growing in deployment, where each client (or viewer) may be shown their own customised stream of advertisements. Current ad-serving systems exist that can generate customised advertisement assemblies to serve to individual viewers or cohorts of viewers, based on for example geographic location, previous viewing history or other segmentation data, whilst meeting the terms of campaigns placed by product suppliers.

[0014] However, mABR and dynamic advertising are two technologies that do not naturally fit well together. mABR relies on delivering the same content to many clients at the same time, whereas dynamic advertising is based on the idea of delivering different content to each client at the same time.

[0015] Thus, if dynamic advertising is used with mABR technology, delivery of the advertising content would need to rely on unicast delivery specific for each client. This would result in an increased use of the network compared just using mABR, and potentially back to the level of use that would have been required had mABR technology not been used at all, negating all the benefits of using mABR in the first place.

[0016] The Applicant’s own International application W02020 / 173878 describes a method of delivering content over a network using an approach referred to here as “Multicast Assisted Unicast Delivery” (MAUD), as a multicast network is used to assist, rather than substituting for, an otherwise unicast path. Content is requested by client devices from a content server over unicast. The responses containing the requested content are separated into two components: a first component containing elements that are specific to individual client devices (for example session specific data), and a second component that is common to all client devices (typically this is the video content being requested). The first component can be delivered over unicast and the second component over multicast. Identifiers are introduced into each of the first and second components to aid recombination of the components to form the original responses.A36161

[0017] US patent application US2005193410A1 describes a targeted advertising system based on subgroups. Different subgroups are formed based on one or more subscriber characteristics, and different targeted advertisements transmitted to the different subgroups. In the Internet-environment, the subgroups are formed by utilizing multicast addresses. In cable-based and satellite-based systems, the subgroups are formed by node configurations. The targeted advertisements are inserted in the program streams at a centralized distribution point such as a router or a cable television head-end.

[0018] US patent application US2012192222A1 describes a method and apparatus for managing targeted advertisements for linear television. During operation a client device will determine whether or not an advertisement opportunity duration is known, unknown, or variable. Based on this determination, advertisements that best match the advertisement opportunity duration will be chosen via separate algorithms.

[0019] Summary of the Invention

[0020] It is the aim of examples of the present invention to provide improved methods of dynamic advertisement delivery over multicast.

[0021] According to one example of the invention, there is provided a method as set out in claim 1.

[0022] Brief Description of the Drawings

[0023] For a better understanding of the present invention reference will now be made by way of example only to the accompanying drawings, in which:

[0024] Figure 1 system diagram showing the main components of an example of the present invention;

[0025] Figure 2 is a flow chart summarising the steps of an example of the invention Figure 3 is a flow chart illustrating an example of the invention in more detail.

[0026] Description of Preferred Embodiments

[0027] The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples.A36161

[0028] Currently, in some dynamic advertising scenarios, the decisions of which advertisements (being a video sequence of advertising content) each viewer is going to see during the next advertising break are made in a very a short period of time before the start of the next advertising break. This time period could be as short as around 10 seconds. Where HTTP unicast streaming is used as the delivery mechanism for the advertisements, advertisements can just be delivered as they are needed for each viewer, and the short time period does not present a problem.

[0029] However, if a multicast delivery mechanism is being used, as under mABR, then problems can arise. Given that advertisements can be around 30s in duration, and are likely to be transmitted at a rate approximately equal to their encoded bit rate, there is not sufficient time to use multicast to deliver and cache all the required advertisements before the start of the advertising break. Multicast delivery could be used, but only starting a few seconds ahead of when advertisements are needed at a client.

[0030] Therefore, examples of the invention propose the following scenario, where a sequence of advertisements is delivered in real time, i.e. at the rate needed for continuous decoding and display, and these are cached, either at a network proxy such as a home gateway, or on the end user client device, until needed for display.

[0031] An advertisement break is considered as consisting of a series of time slots, during each of which one advertisement is delivered over a given multicast channel and cached by a proxy for use by a client device. An advertisement delivered by multicast in one time slot can be cached and used to satisfy a client device requirement for that advertisement in that time slot, and any subsequent (later) time slot in the advertising break. If an advertisement is not available from the cache by the time it is needed for playback by a client device, it can be obtained by unicast.

[0032] Advertisements received by multicast that the client device does not need during the advertising break do not need to be cached, but could be, in case they are needed during a subsequent advertising break.

[0033] Examples of the invention present various methods for determining which advertisements to deliver on a multicast channel, and the order in which to deliver them, to optimise the usage of the advertisements delivered over multicast by the client devices. The methodsA36161

[0034] may take into account any advertisements that are already cached, such as those delivered (by multicast or unicast) during a previous advertising break. This can simply be done by considering that the client device does not need such advertisements.

[0035] System Architecture

[0036] Figure 1 shows a content streaming system 100 comprising the main components of an example of the invention. The system 100 comprises an advertisement decision server 102, a manifest manipulator 104, a multicast transmitter 106, an advertisement assignment module 108, a unicast server 110, a plurality of proxies 112 and a plurality of client devices 114. Each client device 114 is logically associated with one proxy 112, although in practice a single proxy could serve content to more than one client device. For simplicity only one proxy 112 and associated client device 114 has been shown in Figure 1 . However, in practice, there are a plurality of the proxies connecting to the multicast transmitter 106, the advertisement assignment module 108, and the unicast server 110, with each of the plurality of proxies having an associated one or more client devices 114.

[0037] The unicast server 110 stores content, including live sports and TV broadcast content, and pre-recorded advertisements, that have been encoded using a suitable compression scheme, such as ITU-T Recommendation H.264 for video content, and segmented into a sequence of content segments, each content segment typically of duration 2 to 10 seconds. The content stored on the unicast server 110 has been encoded at one or more quality levels or bit rates, resulting in one or more (at each quality level) encoded segments corresponding to each uncompressed content segment. Such an arrangement is typical of an adaptive bit rate streaming service. The unicast server 110 responds to unicast requests for content segments with unicast responses using the stored data.

[0038] The proxy 112 may be located within a device such as a home gateway or router. As suggested above, the system 100 may include a plurality of proxies, with each proxy connected and operable as described here with reference to proxy 112. Note, the proxy 112 may alternatively run on the client device 114.

[0039] The client device 114 is assumed to be running a client application, which is the source of content requests. For simplicity, the term client device has been used to refer to a client device running a client application.A36161 6

[0040] The client device 114 may periodically obtain a manifest file from the unicast server 110. Manifest files are used by client devices to identify where segments are located (by a URL in the manifest). These segments constitute a video sequence, and may be of content (such as live sports) and / or advertisements. The client device 114 can then request these segments in sequence using HTTP requests from the unicast server 110, and concatenate them to form a continuous stream of segments for playback, the stream consisting of sequences of content interleaved with sequences of advertisements, with each such sequence of advertisements being termed an “advertising break”. As each segment is available on the unicast server 110 at a plurality of encoded bit rates, the client device 110 determines for each content segment, the encoded bit rate (quality) at which to request it, taking into account such factors as the available network throughput and how much data is already received and buffered at the client device awaiting play-out.

[0041] The system may be configured to support multicast ABR (mABR), including the Applicant’s MAUD systems, where multicast is used to deliver segments of content (not client-specific advertisements) to the proxy 112 at one or more quality levels, and where these segments are cached, and delivered to the client device 114 on request over unicast. When applied across a system with multiple client devices 114 requesting the same content at the same time, the use of mABR realises significant benefits in network efficiency. However, as was described earlier, current mABR systems are unable to realise these benefits for the delivery of different advertisements to the multiple client devices 114 at the same time. The following arrangements aim to provide solutions to this problem.

[0042] The advertisement decision server 102 determines for each client device 114 the sequence of advertisements to be obtained and presented to the user in each advertising break. This determination may often be made only a short time period before the start of the advertising break, for example, ten seconds before the start of the advertising break. The advertisement decision server 102 informs the manifest manipulator 104 of the results of this determination.

[0043] The manifest manipulator 104, after receiving this information from the advertisement decision server 102, creates a set of manifest files and makes them available to client devices 114 via the unicast server 110. Each client device 114 on request for a manifest file will receive a manifest file describing the advertisements it is to obtain and present toA36161 7

[0044] the user. Typically, a client will make regular requests for a manifest or updated manifest when streaming video, so a manifest file describing the advertisements can be easily made available for the client to request. Advertisements will only be present in the manifest file shortly before the start of an advertising break and during the advertising break. Each client device 114 may be instructed to obtain and present a unique sequence of advertisements, or groups of client devices 114 may be instructed to present the same sequence of advertisements, with that sequence being different to the sequence that other groups of client device 114 are be instructed to obtain and present.

[0045] The advertisement assignment module 108 receives the same information from the advertisement decision server 102 as the manifest manipulator 104. Alternatively, although not shown in Figure 1 , the advertisement assignment module 108 may receive this information from the manifest manipulator 104.

[0046] The advertisement assignment module 108 determines from this information, for each of a set of multicast channels, the sequence of advertisements to transmit on the multicast channel. It also determines which proxies 112 should join which one or more of these multicast channels to receive and cache advertisements that may be required by their associated client devices 114. The advertisement assignment module 108 informs the multicast transmitter 106 and the proxies 112 of its decisions. Methods that the advertisement assignment module 108 may use to make these decisions are described below in examples of the invention.

[0047] The multicast transmitter 106 receives instructions from the advertisement assignment module 108 specifying which advertisements to transmit on each multicast channel and in which order to transmit them. The multicast transmitter 106 requests and receives these advertisements from the unicast server 110, and transmits the received data on suitably configured multicast channels to all devices that have subscribed to one or more of those multicast channels.

[0048] The proxy 112 receives instructions from the advertisement assignment module 108 specifying which multicast channel or channels, if any, to join. The proxy 112 joins the multicast channel or channels it has been instructed to join, receives content segments representing advertisements by multicast and stores them in a cache. The proxy 112 may also join one or more other multicast channels that are used to transmit content segmentsA36161

[0049] representing content (rather than advertisements) and may also store these content segments in a cache.

[0050] The proxy 112 receives requests for content segments from the client device 114 over unicast. These content segments may represent content or advertisements. The proxy 112 replies to these requests using data received over multicast and stored in cache if possible, and otherwise obtains the requested data from the unicast server, and forwards it to the client device 114 over unicast.

[0051] Overview of System Operation

[0052] Each client device 114 requests and receives broadcast TV content, interleaved with advertising breaks in which the client device 114 requests and receives advertising content. The system is described with reference to client devices 114 that request and receive broadcast TV content using unicast Adaptive Bit Rate (ABR) technology. However, the invention is not limited to this, and client devices 114 could receive broadcast TV content by terrestrial, satellite or cable broadcast, IP multicast, or unicast Adaptive Bit Rate (ABR) technology with the decision of the encoded bit rate (quality) at which to deliver each content segment being made at the serving (rather than client) side, but with delivery of advertisements managed in accordance to the described examples.

[0053] An overview of how advisements may be handled according to examples of the invention will now be described with reference to the flow chart shown in Figure 2.

[0054] In step 200, the advertisement decision server 102, for each of a plurality of client devices 114, determines which advertisements are required to be displayed by the client device 114 and the order in which they are required to be displayed. The advertisement decision server 102 informs both the manifest manipulator 104 and the advertisement assignment module 108 of these decisions.

[0055] In step 202, the advertisement assignment module 108 determines, for each of a set of one or more multicast channels, which advertisements to transmit on the multicast channel, and the order in which they are to be transmitted.A36161

[0056] In step 204, the advertisement assignment module 108 determines, for each of the plurality of proxies 112, whether the proxy 112 should join one or more multicast channels, and if so, determines which multicast channels the proxy 112 should join.

[0057] In step 206, the advertisement assignment module 108 instructs each of the plurality of proxies 112 to join multicast channels according to the said determination.

[0058] In step 208, the advertisement assignment module 108 instructs the multicast transmitter 106 to transmit the determined advertisements in the determined orders, on the one or more multicast channels.

[0059] In step 210, the manifest manipulator 104 creates a set of manifest files specifying the advertisements and their order of presentation and makes the manifest files available to client devices 114 via the unicast server 110 and the proxies 112.

[0060] In step 212, each of the plurality of client devices 114 requests a manifest file from the unicast server 110, which in the case of an advertising break, describes the advertisements that it is to obtain and present to the user, and the order in which they are to be presented.

[0061] In step 214, each proxy 112 that has joined one or more multicast channels receives advertisements on the one or multicast channels and stores them in a cache.

[0062] In step 216, the client device 114 requests content segments via the proxy 114. These may represent content or advertisements. The proxy 112 replies using data stored in cache when possible, and otherwise by requesting them from the unicast server 110.

[0063] Whilst the methods described are relation to the delivery of advertisements, as advertisements are video sequences, then the methods can be applied equally to any video sequences.

[0064] Multiple multicast channels are used to deliver advertisements just-in-time

[0065] This invention addresses the scenario where multiple multicast channels are used to deliver advertisements. It provides a method for the advertisement assignment module 108, using knowledge of which advertisements each client device 114 needs, to determineA36161

[0066] which advertisements to deliver on each multicast channel, and which multicast channel (or channels) each proxy 112 should join. This is performed under step 202 in Figure 2.

[0067] The invention is not concerned with the order in which each client devices 114 needs the advertisements and is not concerned with the order in which to deliver them on the multicast channels. While these would be important features of a real implementation, ignoring them here allows the description to focus on the issue of assigning advertisements to multicast channels and then proxies 112 to multicast channels.

[0068] In this scenario, there are multiple multicast channels, and a large number of advertisements, together with numerous client advertisement requirements, which means that finding an optimum solution for the scheduling of advertisement delivery is computationally extremely challenging. This invention presents a simple but effective solution.

[0069] The invention will now be described by reference to a worked example, in which each proxy 112 is associated with a single client device 114, and in which the proxy 112 joins one multicast channel and the number of advertisements delivered on a multicast channel in one advertising break is equal to the number required by each client device 114 in the advertising break. However, the invention is not limited to these, and, for example, some or all proxies 112 could join more than one multicast channel.

[0070] In this example, the advertising break has six time slots, there are three multicast channels available, labelled MC_1 , MC_2 and MC_3, there are 100 proxies 112 numbered P 2001 to P_2100, each of which is associated with a single client device 114, which are numbered C_2001 to C_2100. These client devices 114 are each required to obtain and display six advertisements from a set of 100 advertisements numbered A 1001 to A 1100. These advertisements do not have a uniform frequency distribution: some of them are required to be displayed by client devices 114 much more than others.

[0071] The method will now be described with reference to the flow chart shown in Figure 3.

[0072] In steps 300 to 304, the advertisement assignment module 108, makes an initial assignment of advertisements to the multicast channels.A36161

[0073] In step 300, the advertisement assignment module 108 starts a loop over each multicast channel. When there is at least one multicast channel left to consider, flow passes to step 302. When all multicast channels have been considered, and advertisements have been assigned to each one, flow passes to step 310.

[0074] In step 302, the advertisement assignment module 108 makes an initial selection of N advertisements, where N is equal to six in this example. These advertisements could be chosen at random from a set of advertisements, or some starting selection (allocation) could be used. Flow then passes to step 304.

[0075] In step 304, the advertisement assignment module 108 assigns the advertisements selected in step 302 to the multicast channel. Flow then passes back to step 300.

[0076] In steps 310 to 316, the advertisement assignment module 108, assigns each proxy 112 to a multicast channel that would maximise the number of advertisements that match the needs of its associated client device 114 in any slot order.

[0077] In step 310, the advertisement assignment module 108 starts a loop over each proxy 112. When there is at least one proxy 112 left to consider, flow passes to step 312. When all proxies 112 have been considered, and each has been assigned to a multicast channel, flow passes to step 320.

[0078] In step 312, the advertisement assignment module 108 determines, for each multicast channel, in consideration of the advertisements that have been assigned to it, the number of advertisements assigned to the multicast channel that match the needs of the proxy’s associated client device 114 in any slot order. Flow then passes to step 314.

[0079] In step 314, the advertisement assignment module 108 selects a multicast channel that maximises the number determined in step 312. When two or more multicast channels have the same maximum determined number, the selection of a multicast channel may be made randomly between these two or more multicast channels, or the selection among these two or more multicast channels may be made in some other way. Flow then passes to step 316.

[0080] In step 316, the advertisement assignment module 108 assigns the proxy 112 to the selected multicast channel. Flow passes the back to step 310.A36161

[0081] In steps 320 to 326, the advertisement assignment module 108 assigns a new set of advertisements to each multicast channel considering the proxies 112 that are assigned to the multicast channel, to maximise the advertisements that match the requirements of the client devices associated with the proxies 112 that are assigned to the multicast channel.

[0082] In step 320, the advertisement assignment module 108 starts a loop over each multicast channel. When there is at least one multicast channel left to consider, flow passes to step 322. When all multicast channels have been considered, and advertisements have been assigned to each one, flow passes to step 330.

[0083] In step 322, the advertisement assignment module 108 determines, for each advertisement, the number of the proxies 112 that are assigned to the multicast channel that have an associated client device 114 that requires the advertisement in any slot order. Flow then passes to step 324.

[0084] In step 324, the advertisement assignment module selects N advertisements with the highest determined numbers in step 322, where N is equal to six in this example. When it is not possible to select a unique set of N advertisements in this way, due to some advertisements having equal determined numbers, the selection of advertisements from those with equal determined numbers may be made randomly, or the selection among those with equal determined numbers may be made in some other way, for example, in consideration of whether these advertisements have been assigned to a different multicast channel. Flow then passes to step 326.

[0085] In step 326, the advertisement assignment module 108 assigns the advertisements selected in step 324 to the multicast channel. Flow then passes back to step 320.

[0086] In step 330, the advertisement assignment module 108 considers whether to iterate the process of assigning each proxy 112 to a multicast channel and then assigning advertisements to multicast channels. If so, flow passes back to step 310, and otherwise the process terminates.

[0087] The advertisement assignment module 108 may choose to iterate until there is no change in the assignment of proxies to multicast channels and / or no change in the assignment ofadvertisements to multicast channels. Alternatively, the advertisement assignment module 108 may choose to iterate a predetermined number of times, which may for example be in the range four to ten times, inclusive. Or the advertisement assignment module 108 may choose to iterate until there is no change, or little change in the number of displayed advertisements for which unicast delivery is not needed.

[0088] In testing, it was found with these configuration parameters of 100 client devices 114, 100 advertisements, and six advertisements per client device 114, and with a non-uniform distribution of how many times each advertisement was required, that the solution converges after about four to ten iterations. Furthermore, the cache benefits are generally the same regardless of the initial random allocation of advertisements to multicast channels, but the actual solutions (i.e. which advertisements are on which multicast channels) do vary with the initial random allocation.

[0089] In the initial steps 300 to 304, advertisements are randomly allocated to multicast channels. This is done using the “select and replace” method, enabling an advertisement to be allocated to more than one multicast channel, but duplication within a multicast channel could be avoided, although this is not necessary.

[0090] Table 1 below gives an example of an initial random allocation advertisements to multicast channels. It can be seen that advertisement A_1016 has been randomly allocated to both multicast channels MC_2 and MC_3 (in Slot 5 and Slot 4 respectively), and that all other randomly allocated advertisements are assigned to only one multicast channel.

[0091]

[0092] Table 1

[0093] Table 2 below shows the advertisements required by four of the one hundred client devices 114, how many of these have been assigned to each of the three multicastchannels (labelled as “MC_x Match” for multicast channel “MC_x”), and to which multicast channel each proxy 112 (and hence each associated client device 114) has been assigned. The matching advertisements are highlighted in bold font- A_1068 for C_2001 , A1093 and A1016 for C_2006, and A_1050 and A_1013 for C_2009. This illustrates steps 310 to 316 described above.

[0094]

[0095] Table 2

[0096] For simplicity, the description refers to assigning a client device 114 to a multicast channel. However, in practice, it will be appreciated that it is the proxy 112 associated with the client device 114 that (is assigned to and) joins the multicast channel and receives advertisements, which the client device 114 can obtain from the proxy 112 for display.

[0097] Client device C_2001 (associated with Proxy P 2001) is assigned to multicast channel MC_1 as one of the advertisements it is required to display has been assigned to MC_1 and none have been assigned to the other multicast channels. None of the advertisements that client C_2002 (associated with Proxy P 2002) is required to display have been assigned to a multicast channel. Thus, it has been randomly assigned to multicast channel MC_1 .Client device C_2006 (associated with Proxy P 2006) is assigned to multicast channel MC_2 as two of the advertisements it is required to display have been assigned to MC_2, one to MC_3 and none to MC_1.

[0098] Client device C_2009 (associated with Proxy P 2009) is also assigned to multicast channel MC_2, another random assignment as one of the advertisements it is required to display has been assigned to MC_2, one to MC_3 and none to MC_1.

[0099] Overall, 29 client devices 114 were assigned to multicast channel MC_1 , 37 to MC_2, and the remaining 34 to MC_3. The number of advertisement “matches” on each multicast channel were 23, 31 and 20 respectively, making a total of 74.

[0100] In the final steps 320 to 326, new assignments of advertisements to the multicast channels are made, to maximise the number of matches to client devices 114 that are assigned to the multicast channels.

[0101] For the 29 client devices 114 assigned to multicast channel MC_1 , 6 x 29 = 174 advertisements are required to be displayed. The mostly frequently occurring are A_1001 , A 1008, A 1015, A 1005, A 1009 and A 1011 , and hence these are the new assignments for multicast channel MC_1. Similar processing is performed to make new assignments of advertisements to the other multicast channels. The resulting new assignments of advertisements to multicast channels is shown in the Table 3 below.

[0102]

[0103] Table 3

[0104] It can be observed that there are only 12 unique advertisements assigned to the three multicast channels. This is a result of the frequency distribution of the advertisements, with some required by many more client devices 114 than others.The method then repeats, by making new assignments of client devices 114 to the multicast channels, and then afterwards, by making new assignments of advertisements to the multicast channels.

[0105] This continues until some end condition is satisfied. This may be that the solution remains unchanged after an iteration. Alternatively, a predetermined number of iterations may be performed, which may for example be in the range four to ten inclusive. Or iteration may continue until there is no change, or little change in the number of displayed advertisements for which unicast delivery is not needed.

[0106] In the example, the number of displayed advertisements for which unicast delivery is not needed reached 176 on the fourth iteration and in the next two iterations there was no further improvement and there was no change in the advertisements assigned to the multicast channels, with a total of 16 unique advertisements being assigned to the three multicast channels.

[0107] In general, it is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.

Claims

1. A36161CLAIMS1. A method of managing the delivery by a network element of a set of advertisements to a client device in a network comprising a plurality of client devices, said method comprising:i) receiving, for each of the plurality of client devices, knowledge of which advertisements are required by the client device;ii) defining, for each of a plurality of multicast channels, an initial set of advertisements to be delivered on the multicast channel;iii) selecting, for each of the plurality of client devices, one of the plurality of multicast channels that could be used to maximise the number of advertisements required by the client device that could be delivered on the multicast channel, and associating the client device with the selected multicast channel;iv) determining, for each of a plurality of multicast channels, an alternative set of advertisements to be delivered on the multicast channel, to maximise the number of advertisements required by client devices associated with the multicast channel that could be delivered on the multicast channel;v) transmitting, on each of the plurality of multicast channels, the alternative set of advertisements determined for the multicast channel.

2. The method according to claim 1 further comprising repeating steps iii) and iv) a predetermined number of times before performing step v).

3. The method according to claim 1 , further comprising repeating steps iii) and iv) until there is no change in the association of client devices with multicast channels in step iii) before performing step v).

4. The method according to claim 1 , further comprising repeating steps iii) and iv) until there is no change in the total number of advertisements required by client devices that could be delivered on the multicast channels before performing step v).

5. The method according to any preceding claim, wherein the network comprises a plurality of proxies each connected to respective one or more client devices, and instructing one or more of the plurality of proxies to join the selected multicast channel associated with respective client device.A36161 186. The method according to claim 5, further comprising receiving by the one or more proxies that has joined a multicast channel the selected advertisements, and caching the selected advertisements.

7. The method according to claim 6, wherein for each of the one or more instructed proxies, receiving a request from a respective client device for one of the selected advertisements and the proxy responding by transmitting the requested advertisement over unicast to the client device.

8. The method according to any previous claim, wherein an advertisement is a video sequence.

Images