Dynamic advertisement delivery over multicast

Abstract

Presented are 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 methods 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.

Description

[0001] A36160

[0002] DYNAMIC ADVERTISEMENT DELIVERY OVER MULTICAST

[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 theA36160

[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.A36160

[0017] US patent application US2007169145A1 describes a method and system for allocating a dynamic advertisement according to audience ratings. The method includes selecting an advertisement broadcast to be transmitted based on broadcast viewing information of users and a transmission condition, and providing the selected advertisement broadcast.

[0018] US patent application US2003110171 A1 relates to managing the delivery of advertising impressions on devices that are intermittently-connected to a network. More specifically, examples relate to planning an advertising campaign of advertisements, managing delivery of advertisement content associated with the advertisement to one or more receiver modules, and managing the selection of the advertisement, and associated advertising content, for display to a viewer.

[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.

[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.

[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 theA36160

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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 methods 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.A36160

[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.

[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 URLA36160

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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 to 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 theA36160 7

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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 segments representing content (rather than advertisements) and may also store these content segments in a cache.A36160

[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.

[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.A36160

[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] One multicast channel is used to deliver advertisements just-in-time

[0065] This invention addresses the scenario with a single multicast channel being used to deliver advertisements to the proxy 112. It provides a method for the advertisement assignment module 108, using knowledge of which advertisements each client device 114 needs, and the order in which it needs them, to determine which advertisements to deliver on the multicast channel, and in which order to deliver them. This is largely shown as step 202 in Figure 2.A36160

[0066] The invention will be described by reference to a worked example.

[0067] Table 1 below shows, for eight advertisements required by many client devices 114, how many client devices 114 are to be shown the advertisement in each of the six time slots that the advertising break consists of.

[0068]

[0069] Table 1

[0070] This shows that the advertisement Ad_1 is to be shown on four client devices 114 in the first time slot, on 13 client devices 114 in the next, nine in the one after that, and hence 49 times in total during the advertising break.

[0071] Other advertisements, with generally lower figures, and not shown in the table, are to be shown on some client devices 114.

[0072] The term OA,S is used to denote the number of client devices 114 on which advertisement A is shown in time slot S. So in this example, m,2 = 13.

[0073] In this invention, in a first step, cumulative values are calculated from these figures for each time slot, as an advertisement delivered by multicast in the first time slot is received and cached at the proxy 112 and can be used to satisfy a request from the client device 114 for any subsequent time slot. These cumulative values are calculated working from right to left.A36160

[0074] The term NA,S IS used to denote the number of client devices 114 on which advertisement A is shown in time slot S or a later time slot.

[0075] Specifically, with SMAX being the last time slot in the advertising break, equal to six in this example:

[0076] N ,S, = Sum(s = S to SMAX) nA,s

[0077] So, for example, NI,5= 9 + 7 = 16.

[0078] Table 2 below shows these cumulative values of NA,s-

[0079]

[0080] Table 2

[0081] This shows that if the advertisement Ad_1 is delivered by multicast during the first time slot, it could be used 49 times during the advertising break (made up of 6 time slots), and that if advertisement Ad_2 is delivered by multicast during the second time slot, it could be used 38 times during the advertising break.

[0082] One method of determining which advertisement to deliver in each time slot on the multicast channel would be to determine the highest cumulative value in each column,A36160

[0083] working left to right, and select the advertisement with the highest cumulative value that has not already been selected.

[0084] In this method, for time slot S=1 , A is chosen to maximise the value of NA,I . Then for each time slot S in increasing order of S, A is chosen to maximise the value of NA,s, subject to A not having been chosen previously.

[0085] This would result in the following sequence of advertisements:

[0086] Ad_1, Ad_2, Ad_3, Ad_5, Ad_4, Ad_8

[0087] The total number of time slots that have advertisements delivered in time by multicast would be the sum of the corresponding cumulative values, NA,s, and hence would be:

[0088] 49 + 38 + 30 + 14 + 8 + 4 = 143

[0089] This total number can be seen alternatively as the total number of advertisements for which for which unicast delivery is not needed (as these advertisements have been successfully delivered in time by multicast).

[0090] However it is possible to do better than this, without the need for a full search of all the options, which, if there are many advertisements, would be computationally very intensive.

[0091] Looking at Table 2 showing cumulative sums, it can be seen that advertisement Ad_1 is used 49 times if delivered in the first time slot, while advertisement Ad_2 is used only 47 times, and hence in the above method advertisement Ad_1 is selected for the first time slot. But this method does not take into account how effective each of these advertisements would be if they were delayed and delivered in the second time slot instead. Again looking at the table, it can be seen that advertisement Ad_1 would be used only four times less (45 instead of 49) whereas advertisement Ad_2 would be used nine times less (38 instead of 47). So there is a larger loss by delaying advertisement Ad_2 rather than by delaying advertisement Ad_1.

[0092] Hence in an improved method, the cumulative sums are adjusted to allow for how much less effective an advertisement would be if it were delivered one time slot later. The term LA,S is used to denote the weighted sum of the effectiveness of delivering theA36160

[0093] advertisement A in time slot S, NA,S, and the reduction in effectiveness if it were delivered one time slot later, NA,s - NA,S+I .

[0094] Specifically, LA,s is calculated for each advertisement for each time slot:

[0095] LA,S = NA,S + w (NA,S - NA,S+I) for S < SMAX

[0096] LA,S = NA,S S = SMAX

[0097] Where w is a weighting factor to allow for the impact of delivering an advertisement one time slot later on the multicast channel. It would typically be in the range zero to two, but is not limited to this range.

[0098] So, for example, when w=0.5, Ni ,1 = 49 + 0.5 (49 - 45) = 49 + 2 = 51.

[0099] Table 3 below shows weighted sums when w=0.5.

[0100]

[0101] Table 3

[0102] The advertisement to deliver in each time slot on the multicast channel is selected by determining the highest weighted sum in each column, working left to right, and selecting the advertisement with the highest weighted sum that has not already been selected.So for time slot S=1 , A is chosen to maximise the value of l_A,i . Then for each time slot S in increasing order of S, A is chosen to maximise the value of LA,s, subject to A not having been chosen previously.

[0103] This would result in the following sequence of advertisements.

[0104] Ad_2, Ad_1, Ad_3, Ad_5, Ad_4, Ad_8

[0105] The total number of displayed advertisements for which unicast delivery was not needed, that is, the number that were delivered in time by multicast, and delivered from cache, Cw, is given by the sum of the corresponding cumulative values, NA,s, for the selected advertisements.

[0106] Specifically, Cwis calculated for weight w as below, where Asis the advertisement selected for time slot s.

[0107] C _ SMAX

[0108] GN

[0109] w - 2<s=l ^As,S

[0110] Hence in this example, the number of advertisements delivered in time by multicast would be:

[0111] 47 + 45 + 30 + 14 + 8 + 4 = 148

[0112] Note this is calculated using the cumulative values, NA,s, and not the weighted sums, LA,s.

[0113] Therefore by using the improved method, the number of displayed advertisements for which unicast delivery was not needed could be increased from 143 to 148.

[0114] Returning briefly to the equations defining LA,s, and noting that NA,s - NA,s+i = nA,s, the equations can be rewritten as follows:

[0115] LA,S = NA,s + w nA,s for S < SMAX

[0116] LA,S = NA,S S = SMAX

[0117] In other words, for all time slots except the last, LA,s is calculated as the weighted sum of the cumulative and single values for the time slot. And for the last time slot, there wouldbe no harm from doing the same, as LA,s would simply be calculated as a scaled version of NA,S as (1 + w) NA,S-

[0118] While the method could be implemented using a single value for the weighting factor w, in a further improved method, a set of values for the weighting factor w is used, and the choice and order of advertisements to be delivered on the multicast channel is determined using the value of the weighting factor w that maximises the number of displayed advertisements delivered in time over multicast, Cw.

[0119] As an example, the number of displayed advertisements for which unicast delivery is not needed, Cw, could be calculated for values of w in the range 0 to 2 in steps of 0.1, the maximum of these calculated numbers could be determined, and the choice and order of advertisements to be delivered on the multicast channel selected accordingly.

[0120] 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

CLAIMS1 . A method of managing the delivery of advertisements in a sequence of time slots on a multicast channel by a network element in a network comprising a plurality of client devices, said method comprising:i) receiving, for each of the plurality of client devices, information relating to which advertisements are required by said client device in each time slot;ii) determining, for each advertisement and each time slot, a value (NA,s) equal to the number of client devices that require said advertisement in said time slot or a later time slot;iii) determining, for each advertisement and each time slot, a weighted sum (LA,s) of the corresponding determined value (NA,s) and the number of client devices that require the advertisement in the said time slot;iv) selecting, for each time slot, an advertisement with the largest determined weighted sum for the corresponding time slot;v) transmitting the selected advertisements on the multicast channel in the corresponding time slots.

2. The method according to claim 1 , wherein performing steps iii) and iv) for two or more values of weight in the weighted sum, and wherein for each value of weight, determining, for the advertisements selected in step iv), the sum of the values determined in step ii) and selecting the advertisements associated with the largest determined sum as the advertisements to transmit in step v).

3. The method according to claim 1 or 2, wherein the network comprises a plurality of proxies, and instructing one more of the plurality of proxies to join the multicast channel.

4. The method according to claim 3, further comprising receiving by a proxy that has joined the multicast channel the selected advertisements, and caching the selected advertisements.

5. The method according to claim 4, wherein a client device associated with the proxy makes a request for one of the selected advertisements, and the proxy responds by transmitting the requested advertisement over unicast to the client device.A36160 -| 76. The method according to any previous claim, wherein in step iv), selecting excludes any advertisements that were selected for an earlier time slot.

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

Images