|
(11) | EP 2 026 483 A1 |
| (12) | EUROPEAN PATENT APPLICATION |
|
|
|
|
||||||||||||||||||||
| (54) | Enhanced monitoring of mobile TV service usage |
| (57) The invention relates to a method of monitoring usage of a broadcast service, using
an usage information collecting entity (30) in a receiver of a user, characterized
in that the method comprises the step of remotely programming (20) the collecting
entity with an usage information to be collected.
|
[0001] The invention relates to audience monitoring schemes for broadcast services. It relates to TV Broadcast such as mobile TV, pay TV, TV rating, audience/usage monitoring/tracking/reporting.
[0003] One way for monitoring broadcast audience is to collect all the history of viewing of all users with a fine grain of time. This requires a huge amount of upstream bandwidth and processing power. Another way is to focus on a limited group of willing users, and ask their participation to capture their interest etc... through a dedicated device or software.
[0004] The purpose of the invention is to monitor behaviours of users of broadcast services without requiring a large bandwidth, nor active participation of the user, as the process may be fully automated. Composite behaviours may be detected, where composite here refers to patterns of behavior that are a combination of several actions, possibly over time (sequence of actions).
[0006] Other purposes, advantages and aspects of the invention will appear through the following description, which is made in reference to the appended drawings, among which :
- figure 1 is a diagram representing a preferred embodiment of the invention;
- figure 2 is a diagram illustrating a practical embodiment of the invention ;
[0007] The hereafter described embodiment consists in an audience monitoring operation, which is built onto three phases:
The first phase is a definition of a monitoring campaign, realized by an audience monitoring operator. The second phase consists in a launch of the campaign and collection of records over a period of time. The third phase is a phase of analysis of the records.
[0008] The campaign definition 10 consists in programming what the system will monitor during the campaign. The audience monitoring may, for example, be aimed at quantifying an impact of a future program promotion on program viewing. Another example of audience monitoring may be to quantify a number of users making phone calls during advertising spots. Still another example may be to quantify the efficiency of broadcasting an active URL at a given period of the day onto actual use of such URL by the end-user.
[0010] In the first phase, the audience monitoring operator defines characteristics of the campaign. Mostly, he defines what kind of patterns should be detected. The system translates this into fixed filters and pattern descriptors for the duration of the campaign, and into a schedule of tags. Pattern descriptors and filters are sent to the receiver by some means before the monitoring starts. Tags are broadcast together with programs. The tag schedule covers the whole duration of the campaign.
[0011] Patterns, tags, and other variables will now be described in connection with a specific embodiment of the invention.
[0012] Tags are metadata that can be used to characterize broadcast services. Tags are broadcast together and synchronously with services they relate to. Tags are then received by all receivers at the same time. Some tags are used to characterize global environment, i.e. environment applicable to all the end-users.
[0013] For example, some service-related tags may be a program identifier, or a type of program, such as movie, news, advertising spot, series. A service-related tag may also be an indication of a program duration, a phase of program, e.g. ten first minutes of the program or ten last minutes of the program. Another example of service-related tag may also be the channel number of the program.
[0014] A global environment tag may be the date, or an indication of night-time / day-time, or a minute-of-the-day indication.
[0015] Tags may identify a content, such as a type of content, an advertisement slot, or a global environment (date and time of the day, wheather conditions...)
[0016] Tags are broadcast together and synchronized with services they relate to (time binding). The planning and semantics of tags are up to the designer of the campaign.
[0018] A tag-event is a behavioural event performed by the end-user onto a service he is currently benefiting from, which program may be tagged and relating to which service the end-user performs the event. The receiver can detect tag events because it receives all tags for the service that the user is accessing, even for a few seconds, Then for example, a tag event may be the start of a new program or a change of channel.
[0019] A local event is an event performed at the level of the end-user independent from the broadcast service, i.e. at the level of the receiver, which event may be initiated by the end-user or not.
[0020] For instance, a local event may be the start of a phone call, or the change of a cell in the mobile network..
[0021] Local parameters may also be taken into account during the audience monitoring campaign, such as the quality of reception, the type of receiver. Local parameters are parameters available on the receiver side. They are chosen by the campaign operator because they carry information that are relevent to the campaign.
[0022] In the present embodiment, patterns are detected which consist in the appearance of a specified set of tags, basic events comprising tag-events, and local parameters.
[0023] In a simple example, the detected pattern is a synchronous pattern, i.e. the timely concurrent availability of one or more tags in the selected incoming broadcast, and one or more basic events comprising tag-events, and local parameters.
[0024] A synchronous pattern is here a concurrent appearance of one or more concurrent tags with tag event or local events (e.g. phone call, switch off,...) or local parameters (handset type such as product reference of the terminal or technical characteristics of the terminal, geographical location...). Any local parameter available on the receiving side may be involved in a synchronous event.
[0025] In the present example, the local parameters are a poor reception condition and night-time, and the tag is "desperate housewives" as a currently broadcasted program, and the tag event is the selection by the end-user of such program.
[0026] In an other embodiment of the invention, the pattern may be a sequential pattern which is some way is a composite pattern of sequential occurrence over time of several synchronous patterns. A sequential pattern refers In the present example to a particular sequence of synchronous patterns or events. Sequential patterns are described by tables describing state machines that the audience monitoring client can parse/execute. At the start of the campaign, the pattern tables are broadcast for a period of time and stored by all receiving devices for later execution. This step is represented under reference 20 on figure 1.
[0027] An example of detection of sequential pattern may be the reception of a promotion spot for a program P, and later the watching of program A, i.e. synchronous pattern of tag "program A" and tag event "select program" onto program A or onto channel carrying program A.
[0028] Another example of detection of sequential pattern may be the reception of a first advertising spot, i.e. a tag identifying an advertising spot, and afterwards a channel change i.e. a tag event identifying a channel change, and then a channel change again back to the same first channel less than 10 minutes after the first channel had been left. Such sequential pattern, consisting in a series of timely tracked tags and tag-events, constitutes the detected sequential pattern.
[0029] Typically, a pattern detection, as represented under reference 30 on figure 1, consists in detection of a combination of basic events with local parameters. When a combination matches a pattern at a given time, then a pattern is detected. Detecting a behavioural pattern then consists, as represented under reference 35, in combining new events, that may be filtered as described here-under, in real-time with the current state of the receiver, and comparing the result with a pre-defined pattern descriptor. If they match, then a behavioral pattern has been detected, and a counter can be incremented or a value stored.
[0030] The detection of patterns advantageously involves the use of filters. Filters are used to raise the level of detection of events that are processed in order to ignore "noise", and keep only relevant events. Filters work like a threshold. The events they apply to are ignored by the receiver unless their inputs reach a certain level. As an example, a threshold onto a tag event or a local event may be applied, consisting in ignoring any channel choice that is changed again less than 15 seconds afterwards. With such a filter, such quick change of channel is considered as a non significant zapping behaviour. Then an basic event will be considered detected only once the user selltles for a particular channel more thant 15 seconds.
[0031] If an audience monitoring operator wants to analyze the number of programs that a user views in an evening, the fact that a user changes channels many times every 10 seconds before deciding to stay on a particular channel may be considered as irrelevant to the study. What matters is the programs that were viewed for at least e.g. 30 minutes. Using filters allows the audience monitoring operator to optimize detection by selecting the right threshold.
[0032] At the end of the campaign, reports from all users are compiled for further analysis. This step is referenced 40 on figure 1.
[0033] The report step is preceded by an aggregation phase 38 which saves band with and allows to keep the memory footprint small.
[0034] Periodically or on pre-defined conditions, the user equipment sends back the report to the back-end, where all reports are concatenated for global statistical analysis. The report includes all recorded patterns history since the previous report.
[0035] A full organizing set of commands which would correspond to figure 1 would be the following one :
- a) Define filters and pattern descriptors
- b) Store filters and pattern descriptors.
- c) Start sending tags
- d) While the campain is on, do (in the receiver):
d1)Until buffer is full or reporting is triggered:
d 1.1 Capture (unfiltered) local events, update local parameters, capture (unfiltered) broadcast events
d1.2) Filter events according to pre-loaded filters
d1.3) IF combination of filtered local events status, local parameters, filtered broacast events = one of pre-stored synchronous pattern descriptors THEN
d.1.3.1) IF synchronous pattern is standalone, then aggregate it (=record pattern detection in history buffer in addition to previous ones);
d.1.3.2) IF (i.e. synchronous pattern is part of one of the pre-stored sequential pattern) THEN
d.1.3.2.1) Update state machine of sequential pattern.
d.1.3.2.2) IF current state of state machine = last state
d.1.3.2.2.1)THEN aggregate sequential pattern ((=record pattern detection in the history buffer in addition to previous ones);
d.1.3.2.2.1) ELSE do nothing;
d2) Report to server, reset history buffer;
- e) End of the campaign (triggered from the head-end)
- f) Stop sending program tags;
- g) Send and End Tag
Resets the history buffer.
[0037] The present detailed example consists in a campaign manager wishing to estimate the impact of poor reception on average viewing time of a particular channel or type of program.
[0038] The campaign should allow the report of average viewing time in a given period following one or more occurrences of poor reception conditions, and allow a comparison of it with average viewing time for the same person before this occurrence (comparison done in the backend, based on reporting). This means measuring average viewing time before poor reception occurrence, detecting a period of poor reception and then measuring again average viewing time.
[0039] At step 21, a particular tag is scheduled for broadcast together with the monitored programs, or permanently with the monitored channel.
[0040] At step 31, a filter applies to local parameters which defines what is considered as poor reception conditions, e.g. bit error rate measured by the receiver, and what duration of poor reception conditions is considered meaningful, e.g. 50% of time over a period of 5mns. This filter is loaded at step 29, before the campaing starts, at the receiver end at the start of the campaign.
[0041] At step 29, The sequential pattern descriptor is programmed defining the following phases in the form of a state machine. At step 36, a detection is performed of poor reception period (local event). At step 37, a calculation is performed of viewing time over a period of time for the monitored channel. This is a loop of filtered patterns or tag events until the program time period elapses. The pattern consists in the detection of tag event "select" with content tag "Channel N" and global tag "Minute of day" during the specified period of time.
[0042] An example of implementation with a USIM in the case of mobile Pay TV may be the following one.
[0043] Downstream (broadcast) channel carries tags synchronized with the broadcast of programs, from an audience monitoring server to the USIM. The downstream channel is implemented using the SCP service protection data flows: the audience monitoring data are carried in the payload of STKMs. Audience monitoring data are added as an extension to the MIKEY in the STKM. The extension is proprietary, not processed by the handset, but passed to the USIM through the Authenticate command. This is SCP-compliant behavior, as far as the user equipment is concerned.
Downstream synchronization with programs:
[0044] The initial source of information is an ESG (Electronic Service Guide) streams. The audience monitoring server can use either one or more ESG sources, as defined by OMA-BCAST, aggregated ESG streams from the broadcast head-end, or even a full ESG stream from an actual local DVB-H receiver adapted to deliver ESG streams on an Ethernet port.
[0045] An upstream (unicast) channel carries IRs (individual reports) from the USIM to the audience monitoring Manager. The upstream channel uses usual SIM OTA bearers such as SMS or BIP over GPRS. Upstream reporting is controlled by the OTA platform. The report scheduling policy can be periodic or based on a USIM buffer status.
[0046] As concerns viewing event detection, in the service protection system of OMA SCP the terminal requests a key from the SIM every n seconds for decrypting the currently received program. The SIM verifies acquired rights and delivers the key if OK.
[0047] For the purpose of audience monitoring, in addition to the above, the SIM interprets incoming key requests from the terminal as an indication of the program that the user is watching (as there are no requests for keys other services than the current viewed one). Thanks to the insertion of tags as payload of the message, the SIM can derive viewing basic events from the sequence of these requests. Filters can be applied to discard meaningless events.
[0048] As the SIM does not have an internal absolute time reference, the audience monitoring data broadcast inside the STKMs may include a time reference (Current Time). Another solution may be based on the use of standard time stamps carried by the STKMs.
[0049] At the beginning of the campaign, filters and patterns are sent to all user equipments, which stores them and uses them for the duration of the campaign. This set of parameters programs the detection process for user behavior patterns in each of the user equipments;
[0050] During all the campaign, tags are broadcast together with each broadcast service relevant to the current monitoring campaign, according to the set schedule (e.g. derived from the schedule of the programs for each service). During the campaign operations, adequate tags are broadcast synchronously with programs, events, ads, or whatever is being monitored.
[0051] Local relevant environment parameters are collected and maintained up-to-date (e.g. type of handset, quality of reception, geographical location...). Local relevant events are tracked and relevant states stored and maintained up-to-date (e.g. ongoing call...). Occurrences of relevant patterns are recorded: e.g. through increments of a dedicated counter.
[0052] Each receiver detects above-threshold patterns according to programmed pattern descriptors, and stores a record of it or e.g. increments a dedicated counter. From times to times the stored history is uploaded to a collection server. Data from all users are compiled into a data base for analysis.
[0054] "recevant" here means involved in the set of the patterns that have boon programmed at the beginning of the campaign.
[0056] Technically, programming the campaign translates to programming of Tags, basic events Filters, Synchronous and Sequential Patterns.
[0057] According to feedback received, the campaign parameters can be modified by changing one or more of the three kinds of variables.
[0058] In a particular implementation of the invention, the processing at the receiving end is done in a secure token such as a smart card hosted in a receiving terminal such as mobile phone enabled for mobile TV. This is possible with cards involved in conditional access of broadcast services (e.g, pay TV, mobile TV). In this case, tags and pattern updates are advantageously inserted in the ECM (entitlement control messages) that come synchronous with the program and carry the decryption key. A dedicated server connected to the broadcast head-end provides timely tags and patterns to the ECM generator upon request. As the card gets all (non-redundant) ECMs for services that the user wants to watch, it can extract whatever audience monitoring data for processing, storage, and later reporting.
[0059] This allows to leverage the audience monitoring system to bring confidentiality and temper-resistance to the system.
[0060] The solution requires very small downstream bandwidth, local processing power, local storage, and upstream bandwidth, while allowing monitoring of complex events that are not visible from the head-end and would require extensive history recording if they were to be extracted from a fine-grained historical records data-base.
[0061] The proposed scheme uses a limited amount of downstream broadcast bandwidth, processing power and memory in the end user equipment, and upstream unicast bandwidth in order to collect statistics of usage behavior on a large population of users. The scheme allows detection and reporting of composite and sequential behavioral patterns. These patterns can relate broadcast as well as other services, and to global as well as local elements of the user environment.
1. A method of monitoring usage of a broadcast service, using an usage information collecting
entity (30) in a receiver of a user, characterized in that the method comprises the step of remotely programming (20) the collecting entity
with an usage information to be collected.
2. The method according to claim 1, characterized in that the remote programming is performed by broadcasting (20) the said at least usage
information to be collected.
3. The method according to claim 1 characterized in that the method comprises inserting service tags in the broadcast and collecting the tags
of the service selected in the receiver of the user.
4. The method according to claim 1, characterized in that the programmed usage information comprises at least a user-event.
5. The method according to anyone of the preceding claims, characterized in that the usage information comprises at least a plurality of tags.
6. The method according to anyone of the preceding claims, characterized in that the usage information comprises at least a tag and at least a local event.
7. The method according to anyone of the preceding claims, characterized in that the usage information comprises at least a tag and at least a local parameter.
8. The method according to anyone of the preceding claims, characterized in that the usage information comprises at least a local parameter and at least a local event.
9. The method according to anyone of the preceding claims, characterized in that the usage information specifies a plurality of usage indicators among tags, local
events, local parameters.
10. The method according to the preceding claim, characterized in that the usage information specifies that the plurality of usage indicators occurs in
time sequence.
11. The method according to the preceding claim, characterised in that the pattern specifies time delays between occurrences of the usage indicators.
12. The method according to anyone of the preceding claims, characterized in that the usage information comprises at least one filter which identifies a difference
between relevant and non-relevant usage and the collecting entity uses the filter
for considering a usage as relevant or non-relevant to be collected.
13. The method according to anyone of the preceding claims, characterized in that the receiver of the user comprises a terminal and a subscriber identity module hosted
in the terminal, and the collecting entity (30) is run in the subscriber identity
module.
14. The method according to the preceding claim, characterized in that the subscriber identity module is a subscriber identity module for a mobile TV service.
15. The method according to claim 13 or claim 14, characterized in that the subscriber identity module is a subscriber identity module for a mobile telephony
service.