Patent Grant
RE50079
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Program Listing
This patent submission contains eleven (11) program listings as shown in the table below. Each of the following program listings is incorporated in this Specification by reference.
The following is a tabulation of some prior art that presently appears relevant:
With the ever increasing levels of consumer interaction with electronic devices of all kinds, it is important for the providers of the systems with which the consumers are interacting to understand the patterns of consumer interaction/device usage.
Cable Television Industry Problem
In the cable television industry, consumer demand for additional viewing choices along with demand for high definition television has put increasing loads on network infrastructure. Cable television providers need tools that provide detailed information on how their customers consume their product. Cable television providers need to provide adequate network capacity to deliver a quality product to consumers.
Cellular Telephony Industry Problem
In the cellular telephony industry, consumer demand for additional communication options has put increasing loads on network infrastructure. Cell phone providers need detailed information on how customers use cell phones and other personal communication devices. Cell phone providers must provide adequate capacity to handle customer interactions of all types including cell phone calls, web browsing, email access, file downloading, gaming, and other activities. When cell tower capacity is exceeded it results in dropped calls, undesired termination of users sessions, and other problems.
Need for Information about the Customer
In addition to these issues, cable companies, cell phone companies, content providers, advertisers, and other interested parties are continually desiring to know more about the customers they serve, the patterns of customer interactions, the content customers find interesting or that keeps their attention, the ads they view, the time of day the services are used, the volume of usage, and numerous other measures.
Fortunately, the advanced technologies do provide raw data that, with proper analysis, can begin to answer many of these questions, and even do so with great specificity. We will now look at some sources of raw data in the cable television industry.
Channel Change Data Sources
Switched Digital Video as a Data Source
One source of raw data is channel change data collected by switched digital video systems.
In the cable television industry, Switched Digital Video (SDV) is one technology that is currently being introduced to better manage cable company network resources. In the web page article “How Switched Digital Video Works” Strickland, Jonathan* provides a detailed explanation of the technology: * Strickland, Jonathan. “How Switched Digital Video Works” 20 Nov. 2007. HowStuffWorks.com. <http://electronics.howstuffworks.com/switched-digital-video.htm>
Two of the most widely used Switched Digital Video systems are provided by Motorola, Inc. and Cisco Systems, Inc.
The Motorola system is available from Motorola, Inc. 1303 East Algonquin Road, Schaumburg, Ill. The Motorola configuration is described in the Solutions Paper entitled “Implementing Switched Digital Video Solutions” found on the Motorola web site at:
http://www.motorola.com/staticfiles/Business/Products/_Documents/_Static%20files/SDV%20Implementation%20Solutions%20paper%20-555998-001-a.pdf?localeId=33
The Cisco Systems, Inc. system is available from Cisco Systems, Inc., 170 West Tasman Dr., San Jose, Calif. The CISCO SDV solution was formerly sold by Scientific-Atlanta, Inc.
The CISCO solutions are described at:
http://cisco.com/en/US/products/ps9258/index.html
http://cisco.com/en/US/products/ps9258/prod brochure list.html
A benefit of SDV systems is that individual set-top box channel change data is collected on the SDV servers as part of normal system operation without any additional actions on the part of the viewer.
One vendor produces channel change data containing fields similar to this (hereinafter SDV Vendor 1 Format):
Note: The data file is typically created daily. Business rules are applied if the tune-in and tune-out events occur on different days.
The other SDV vendor produces channel change data containing fields similar to this (hereinafter SDV Vendor 2 Format):
Note: The data file is typically created daily. Business rules are applied if the tune-in and tune-out events occur on different days.
Those with ordinary skill in the art will recognize that SDV Vendor 2 Format can be transformed into a format similar to SDV Vendor 1 Format by combining the tune-in record and the tune-out record into a single record containing both tune-in date-time and tune-out date-time. This is done by sorting the file in order by Market, Service Group, Set-top box identifier, Tuner index, Date, and Time and then matching each tune-out record to the previous tune-in record using Event code to identify tune-in and tune-out actions. They will also recognize that by adding a lookup table to the process they can enhance the Market+Service group information to also include Hub and Headend. They will also recognize that by adding a second lookup table to the process they can enhance the channel information to also include Channel Name, Channel Call Sign, Bit Rate, Program Type, and High definition or standard definition flag. Enhancing the tuning data with these additional fields allows us to produce valuable analytics to support network engineering, marketing, and programming.
The vendor may generate a tune-out event in the data file when the user turns off the power.
Set-Top Box Data as a Data Source
In a non-SDV configuration, the channel change data can be captured by the set-top box itself.
Set-top box tuning information is widely available for measuring audience viewing habits. For example, on Feb. 24, 2010 the STB Committee of the Council for Research Excellence published a study titled “The State Of Set-Top Box Viewing Data as of December 2009” in which the report reviewed current industry trends in this area and noted that channel tuning data is widely available.
In the case of set-top box data capture, the cable operators have ready access to this data as it is captured on the set-top box by the STB software. The data can then be transferred to central systems at the cable company for analysis. Similarly, satellite broadcasters have access to such data.
A set-top box software application may produce channel change data containing fields similar to this:
Those with ordinary skill in the art will recognize that this file format can be transformed into a format similar to SDV Vendor 1 Format by combining data from consecutive channel tune records into a single record containing both tune-in date-time and tune-out date-time. This is done by sorting the file in order by Set-top box identifier, Tuner index, and Time and then using the Time from the next record (minus 1 second) as the tune-out time of the current record. The result is that the tune-in time comes from the current record and the tune-out time comes from the next record. They will also recognize that it is a simple task to convert the time represented in seconds since some historic date to the current date and time in YYYY-MM-DD HH:MM:SS AM/PM format. They will also recognize that by adding a lookup table to the process they can use the Set-top box identifier to look up the values for Market, Headend, Hub, and Service Group. They will also recognize that by adding a second lookup table to the process they can enhance the channel information to also include Channel Name, High Definition or Standard Definition, Bit Rate, and Program Type.
The vendor may generate a tune-out event in the data file when the user turns off the power.
The vendor may also provide the tune-out time in the data file.
Note the current data collection methods support granularity of tuning data down to the second level.
IPTV Data as a Data Source
In the case of internet protocol television (IPTV), channel changes can be captured at the device level and transmitted to the IPTV provider.
Electronic Device Usage Data Sources
Cell Phone Call Records as a Data Source
In the case of electronic devices such as cell phones, the cell phone provider has ready access to detailed call records which can be prepared in the format needed for processing by the Analytics Engine 140. The communication on the cell phone can be initiated by the device user or it can be a response to another device such as another cell phone calling.
File Transfer to Receive the Data
In this case of channel change data, those with ordinary skill in the art would know how to capture channel change files or tuning data from various source systems and make them available to an analysis engine by reading them from the SDV system and transferring them to the data analysis computer using tools such as secure file transfer protocol. Other methods for receiving channel change data may be used such as Extensible Markup Language (XML) messages or any other computer readable format.
In the case of electronic device usage data, those with ordinary skill in the art would know how to capture such data from various source systems and make them available to an analysis engine using tools such as secure file transfer protocol. Other methods for receiving electronic device usage data may be used such as Extensible Markup Language (XML) messages or any other computer readable format.
Encryption may be applied for data security purposes. Compression may be applied to reduce data transfer volumes.
Summary on Data Sources
As noted, SDV systems capture channel change data in order to support the basic function of providing Switched Digital Video. SDV channel change data is particularly useful because it includes all channel changes, both of broadcast channels and of switched channels.
In a non-SDV configuration, the channel change data can be captured by the set-top box itself.
In all of these cases, the STB activity (both SDV and non-SDV) is collected without the viewer needing to take any special action. The avoids problems of non-response bias and respondent fatigue. STB data provides very large measurement samples. STB data provides the ability to gather data from many geographic areas. STB data can be augmented with demographic data. STB data can be augmented with program attribute data. Once the channel tune data is processed into a standardized format, the Analytics Engine 140 can produce metrics using the data—it does not matter whether the data is from an SDV system or from a STB application.
For other electronic devices, the necessary data can be captured as part of normal operations without any special effort on the part of the user.
SDV Data Quality
The vendors that provide the SDV systems also provide tools that use this data to perform basic analytics for capacity planning. This indicates that there is confidence in the quality of the data. This is important because others have noted that in the current technology environment there are concerns or issues with Set-top box data quality.
A benefit of using SDV data is that for switched channels which are only delivered when requested (as opposed to broadcast channels which are always available), the vendors may include algorithms for reclaiming bandwidth. Generally, when the SDV system detects the lack of activity on the part of the viewer for some period of time the system can force tune the STB to a broadcast channel. The vendor SDV software does this to make the bandwidth that was being used by the switched channel available for other channel tune requests. This has the result of removing false positives (e.g., it appears that someone is watching when no one is) from the data, at least to a certain degree, and thus increasing the quality of the data for analytics.
Data Cleansing—Extended Tune Time
Data cleansing algorithms can be introduced to reduce the implied viewing time when it is reasonable to assume that no one is viewing the television. For example, it is widely known that viewers will often turn off the television while leaving power on to the set-top box. This can make the tuning data appear as though the viewer is watching television, but really they are not. To reduce the incidence of such false positives, the Analytics Engine 140 can examine the duration of the tune when it is being loaded to the data array and adjust tune duration according the business rules. The business rules can include parameters based on demographic modeling, time of day, channel, etc. For example, if the tune duration is 10,800 seconds (3 hours), then stop counting viewing seconds at the half hour mark after 7,200 seconds of viewing time based on the assumption that the viewer is no longer watching the channel.
Data Cleansing—Channel Surfing
Channel surfing can be important to understand. Advertisers and others often need to understand channel surfing behavior. If the analyst needs to eliminate such behavior from the data set, algorithms can be added to the Analytic Engine's 140 data loading process such that any channel tune where the difference between tune-in and tune-out is less than x seconds can be ignored and thus those seconds are not marked or counted as viewed.
On the other hand, from the perspective of managing an SDV system, it may be desirable to include all channel tune events, even channel surfing events, because they created a load on the SDV system. By having the Analytic Engine 140 include such channel tune events in the data array, measurements can be performed to find the average tune duration. The Analytic Engine 140 could count the number of channel tune events per day where duration is less than x seconds.
Switched Digital Video Solutions
We have noted above that there are vendors that supply Switched Digital Video systems. We will now review two such systems paying particular attention to the data analysis part of the product offering.
Existing Tools for Data Analysis
We have seen by way of background that channel change data is readily available. We now turn our attention to the tools presently available for analyzing this data.
Capacity Planning Analysis in a Cable Television Environment
In an SDV environment, capacity planning is critical because when SDV capacity is not adequate, it results in blocked channels leading to customer complaints.
By understanding viewing patterns, the cable operator can make intelligent choices about which channels to deliver as switched channels and which to deliver as broadcast channels. From the perspective of the cable system operator, the fewer the number of viewers viewing the channel, the more suitable the channel is delivery as a switched channel.
Capacity in an SDV environment is typically measured in megabits per second of bandwidth that can be delivered. A standard definition channel usually requires 3.75 Mbits/second. A high definition channel usually requires 15 Mbits/second. The number of channels that can be delivered at any time is dependent on the available megabits per second of bandwidth. When the number of different channels requested by the various set-top boxes approaches the capacity of the network or of the switched digital video server equipment in the service group, the customer is more likely to experience a blocked channel tune request because the system has no more available capacity. Thus the SDV engineers need good tools to understand viewing behavior so that they can effectively manage bandwidth and server capacity, both being scarce resources. They also need to predict future viewing patterns to determine when to add additional capacity.
Both Motorola and CISCO provide tools to manage capacity in an SDV environment, but they do not provide the depth of analysis that would enable cable companies to manage SDV networks most effectively. These tools are reviewed next.
Motorola Tools for Data Analysis
For example, Motorola provides an analysis tool as described in the Solutions Paper entitled “Implementing Switched Digital Video Solutions”
http://www.motorola.com/staticfiles/Business/Products/_Documents/_Static%20files/SDV%20Implementation%20Solutions%20paper%20-555998-001-a.pdf?localeId=33
In this paper, Motorola highlights the importance of “monitoring channel usage” and describes their reporting tool including a report entitled “Channel Usage Pareto”. They suggest that “If average usage for a channel turns out to be less than one set-top per service group, the channel is a good candidate for being made available as a switched service.” Additionally, the sample “Channel Usage Pareto” report shows only the total number of hours viewed by each channel during a 24 hour period.
Thus we can see that the Motorola reporting tool does not provide in depth analysis of channel usage. It does not show average viewing duration, it does not show stay-away seconds, it does not show viewing or non-viewing seconds, it does not show what percent of the day an activity occurs, it does not show peak viewing second or peak viewing count. These and other measures are very helpful for capacity planning and for choosing switched vs. broadcast channels, and for other purposes such as customer behavioral analysis. But Motorola does not provide them.
CISCO Tools for Data Analysis
As a second example, CISCO provides a “Retriever” product which “Collects viewing data based on the consumer's ‘clicks’ of the set-top remote each time a new channel is selected”.
Reference: http://www.cisco.com/en/US/products/ps9122/index.html
CISCO also provides a “Channel Viewership Analyzer” tool as described on their web site.
Reference: http://www.cisco.com/en/US/prod/collateral/video/ps9119/ps9883/7016867.pdf
CISCO's “Channel Viewership Analyzer (CVA) application provides minute-by-minute viewership for all responding set-top boxes in a customer's system.” One sample report is “Top Channels by Aggregate Viewing Minutes”. This report appears to simply count the tune duration for each channel tune and aggregate this by channel. A second report is “Top Channels by Distinct Tuners”. This report appears to simply count the number of different tuners that made a channel change to each channel. A third report is “Top Channels by Viewing Minutes”. This report appears to simply divide aggregate viewing minutes by tuners.
Thus we can see that the CISCO reporting tool does not provide in depth analysis of channel usage. It does not show average viewing duration, it does not show stay-away seconds, it does not show viewing or non-viewing seconds, it does not show what percent of the day an activity occurs, it does not show peak viewing second or peak viewing count or whether a channel was viewed during peak or how many seconds it was viewed during the peak window. These and other measures are very helpful for capacity planning and for choosing switched vs. broadcast channels, and for other purposes. But CISCO does not provide them.
Ineoquest Tools for Data Analysis
As a third example, IneoQuest Technologies, Inc. provides “solutions for monitoring, testing and validating SDV components and networks”. These solutions are focused on monitoring the SDV application infrastructure rather than understanding viewer behavior. They appear to focus on monitoring system operations rather than viewer behavior.
Reference: http://www.ineoquest.com/switched-digital-video-solutions
Prior Design Work of Robert Alan Orlowski
Before developing this embodiment, I designed a methodology for tabulating set-top box channel tuning data with a granularity of one minute increments. I found this to be inadequate for comprehensive metrics. It did not and could not support many of the metrics taught in this embodiment. It did not and could not adequately track viewer behavior. It was not useful as a foundation for analyzing advertisement viewing or fine-grained program viewing. It had faulty algorithms for determining peak viewership. It had limited value for capacity planning because of the course granularity of the data. It did not include demographic attributes. It did not include program attributes. It did not combine multiple attributes. Based on that work, I determined that a more comprehensive solution was required. The methodology I designed was not implemented. No patents were filed on that methodology. The methodology was not published to the public.
Relevant Patents
Besides the vendor provided solutions, others have used channel change data for various purposes. Examples include:
Conkwright, et al. in U.S. Pat. No. 7,383,243 issued Jun. 3, 2008 teaches about collecting set-top box data for the purpose of predicting what consumers will do, not for the purpose of understanding actual viewer behavior. It appears that he does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis.
Hendricks, et al. in U.S. Pat. No. 7,590,993 Method and apparatus for gathering programs watched data issued Sep. 15, 2009 teaches about collecting tuning data from the set-top box and combining that with other data in a data base to determine the types of programming the STB tunes to. It appears that he does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis or of using such a data structure to determine the duration of program watching.
Relevant Patent Applications
Wood; Catherine Alexandra in U.S. Patent Application 20070074258 dated Mar. 29, 2007 teaches about collecting subscriber activity data, such as channel changes generated by the subscriber while watching video or TV in an IPTV system. It appears that she does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis. It appears instead that she teaches loading the channel tuning data to a relational data base and then performing various SQL based queries against that data base.
Eldering; Charles A.; et al. in U.S. Patent Application 20080127252 dated May 29, 2008 teaches about targeted advertising. He notes that SDV systems have the ability to provide viewership counts. It appears that he does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis.
Allegrezza; Fred J.; et al. in U.S. Patent Application 20090077577 dated Mar. 19, 2009 teaches about aggregating information obtained from the messages to generate channel viewership information identifying a number of subscribers tuned to each broadcast channel over a period of time, but it appears to be based simply on tune-in activity. It appears that he does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis.
Bou-Abboud; Claude H. in U.S. Patent Application 20070214483 dated Sep. 13, 2007 teach about a tool for predicting capacity demands on an electronic system. It appears that they do not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis.
Canning; Brian P.; et al. in U.S. Patent Application 20100145791 dated Jun. 10, 2010 teach about storing data in multiple shards and supporting queries against the data. It appears that he does not teach the loading of a data structure containing buckets representing individual units of time during a window of time of interest for analysis.
Summary of Short-Comings in Data Analysis Tools
In general, a short-coming of these methods is that the foundation is a non-procedural language (SQL) used in conjunction with a relational data base which together do not have the detailed processing capability required to perform complex analytics. In such an environment, in order to capture the richness of certain aspects of the channel change data, one would have to explode the data out into individual rows with one row for each second of viewer activity. In such an environment, this is extremely expensive because adding a primary key to each data record simply to record the second (time) multiplies the volume of data many times over because the size of the primary key requires much more storage space than the data being recorded. Thus we see that using a non-procedural language (SQL) in conjunction with a relational data base is very inefficient and requires extremely powerful data base servers to analyze this data. In contrast I am able to produce these complex analytics on a simple personal computer.
As a result of not having the tools to manage the SDV environment adequately, cable companies often mitigate the risk of service disruptions by purchasing and installing excess capacity to ensure that customer demand is satisfied. This is a costly solution to the problem of inadequate analytics.
Also as a result of not being able to perform the detailed analytics required, the behavioral and device usage information contained in the data remains hidden from other interested parties.
In addition to these short-comings, the existing solutions generally do not blend detailed channel change data with demographic data or program attribute data. Thus the solutions provided by Motorola, CISCO and others do not allow the cable companies or service providers to marry demographic or program attribute data with the tuning data to yield increased knowledge of customer behavior.
In accordance with one embodiment, I disclose a computer-implemented method, executed on a data analysis computer system, of analyzing a plurality of human interactions by a plurality of human beings with a plurality of electronic devices, each interacting with a computer system accessed through a network with the result of being able to (a) provide insight into the amount of resource consumed by the human interaction with the electronic device, (b) provide insight into the electronic device usage patterns, and (c) provide insight into the behavior of the human operator.
In contrast with the methods described above, I have found that the richness of this data can be accessed by using a procedural language to process/manipulate the data to produce various metrics quickly and efficiently. By populating a Data Structure with identifying information, device usage information such as channel tuning data or personal communication device usage data, demographic information on the human beings, and other supporting information I create a foundation upon which a comprehensive set of metrics can be produced. By reviewing the prior art, we can see that loading the tuning data on a second-by-second basis into buckets in a data structure for analytics is not a concept that was suggested or implied by the prior art. By reviewing the prior art, we can see that loading electronic device usage data into buckets representing seconds, or day-parts, or other time periods in a data structure for analytics is not a concept that was suggested or implied by the prior art.
In general, we can see that this methodology is applicable to any problem where there is a need to measure or count the information regarding a series of events which may overlap but which can be characterized by various non-uniform starting times and varying duration.
As nonlimiting examples, STB activity and cell phone activity fit this problem space. In both cases, the start time and the duration of the activity varies, and there are multiple users with each creating a load on the system. The peak load is dependent on concurrent activity, not start time or simply duration. The peak load must be determined by finding the point in time when the most devices are concurrently active. Resource consumption is also dependent on concurrent device activity rather than start time or duration.
The data structure can be populated with any level of detail. In one embodiment it may be populated with very detailed information such as individual device usage for each second of the period being analyzed. In another embodiment it may be populated with highly summarized data such as aggregate device usage for an entire geographic area for each second of the period being analyzed. Another embodiment may aggregate data according to demographics by time period. Yet another embodiment may aggregate data by program attribute and time period. Yet still other embodiments may combine various aspects of geographic area, demographic attribute, and program attribute information. Yet another embodiment may load fractional values into the buckets to represent fast forwarding through a program or an advertisement. Yet another embodiment may load fractional values into various buckets to represent each of several activities occurring concurrently on the electronic device with each activity possibly capturing some amount of the user's attention.
There are multiple dimensions of analysis that are possible:
Other dimensions of analysis can readily be envisioned by those skilled in the art. These may include device type or application being run on the device as non-limiting examples.
Once the Data Structure is populated, then a comprehensive set of metrics can be produced. The metrics can then be output as (i) a data file that can be read by a computer program, (ii) a data base table, (iii) an electronic message, or (iv) a spreadsheet.
A person skilled in the art will readily see the benefits of loading the calculated metrics to a relational data base where additional queries and analytics can be run using standard SQL. As nonlimiting examples, daily metrics calculated by the Analytics Engine 140 can be loaded to a data base in support of longer term analysis.
The Analytics Engine 140 presented in this embodiment provides a solution to the shortcomings identified in the vendor solutions, the issued patents, and the patent applications. A sampling of the metrics produced by the Analytics Engine 140 in the context of cable television is presented next:
Set-Top Box+Channel Viewing Metrics
STB channel viewing seconds, STB channel tune-ins, STB channel average viewing duration, STB Channel stay away seconds.
Channel Viewing Metrics
Channel viewing seconds, Channel non-viewing seconds, Aggregate channel viewing seconds, Peak viewing second for channel, Peak viewing count for channel, Percent of peak viewership at this channel's peak, Channel viewed seconds during peak window, Aggregate Channel viewed seconds during peak window.
Capacity Metrics
Peak usage in megabits per second, Percent of day megabits used is near peak, Maximum tune-in's per second, Peak usage by channel viewed count, Aggregate seconds viewed at the peak second of the day.
Demographic Viewing Detail
Demographic viewing seconds, Aggregate demographic viewing seconds, Percent of the day when this demographic is viewing television, Peak viewing second for demographic, Aggregate demographic viewing at this demographic's peak, Percent of peak viewership by this demographic's peak.
Program Viewing Detail
Program viewing seconds, Program one STB viewing seconds, Aggregate program viewing seconds, Percent of the day when only one STB is viewing programs having this attribute, Percent of peak viewership by this program attribute, Program viewed seconds during peak.
Non-Viewing Metrics
In addition to the various viewing metrics described, the Analytics Engine 140 is also able to produce metrics on non-viewing or non-use. Such metrics can be extremely valuable to advertisers since they indicate when not to advertise. Such metrics are useful to content providers because they identify non-viewed content. Such metrics are valuable to capacity planners because they identify potential times for system maintenance and in the case of SDV which channels are good candidates to be switched.
Summary of Metrics Produced
The metrics listed above are representative of those which can be produced by the Analytics Engine 140 in one embodiment. Many additional metrics could be produced once the data is loaded to the Data Structure. It is the extensive processing done by the Analytics Engine 140 which turns the device usage data into valuable information. The Analytics Engine 140 readily allows creation of both viewing and non-viewing metrics.
The metrics shown above all provide information useful for understanding human behavior; understanding various combinations of who uses the devices, when do they use the devices, and the purpose for which they use the devices; and understanding device usage for the benefit of service providers. These and other advantages of one or more aspects will become apparent from a consideration of the ensuing description and accompanying drawings.
Data Encryption
To protect the privacy of the viewer and to comply with various laws and/or regulations, cable companies and other service providers sometimes anonymize and/or encrypt any data that could identify a specific customer or viewer. Within the various embodiments presented herein, if the encryption algorithms applied to the electronic device usage data or channel tuning data are consistent over a period of time, this will allow the Analytics Engine 140 to produce metrics that track the behavior of the device user or set-top box over a period of time while also protecting the privacy of the user.
Furthermore, if the encryption algorithms applied to data are synchronized among the various data sources such as channel tuning data and demographic data, this would allow computer systems to combine channel tuning data and demographic data in support of end-to-end analysis of customer behavior. The same principal applies to cellular telephone call detail records and demographic data.
The following are definitions that will aid in understanding one or more of the embodiments presented herein:
Activity occurring on electronic device means any interaction or activity that may happen as a result of any aspect of a human interaction with an electronic device. Nonlimiting examples include:
(i) tuning activity on a set-top box,
(ii) call activity on a cell phone (initiate call, terminate call, call (talk), check voice mail),
(iii) packet transfer data related to internet activity,
(iv) browsing the internet,
(v) download file, upload file, watch video,
(vi) email usage (check email, send email),
(vii) any activity that generates internet protocol packets or Ethernet packets
(viii) any activity that uses radio frequencies, etc.
Activity occurring on set-top box means any interaction or activity that may happen as a result of any aspect of a human interaction with a set-top box. Nonlimiting examples include:
(i) tuning activity on a set-top box,
(ii) viewing a television program,
(iii) recording a movie, etc.
Amount of resource consumed means a measure of resource consumption. Nonlimiting examples include:
(i) megabits per second of bandwidth,
(ii) radio frequencies,
(iii) channels,
(iv) network capacity, etc.
Bandwidth means a measure of resource consumption to determine how much of the capacity of a communications channel is used in providing a service. In a digital system that capacity is typically measured in megabits per second.
Buckets means individual cells in a Data Structure. Nonlimiting examples include:
(i) addressable fields in a table in a COBOL program,
(ii) addressable fields in an array or similar structures in a ‘C’ program,
(iii) cells in a spreadsheet, etc.
Cell tower means a station for communicating with cell phones or personal communication devices in a cellular network.
Channel means a radio frequency signal within the frequency spectrum. The radio frequency signal is assigned to an identifier which is called a channel. Within a defined area in the cable providers network, each channel and the radio frequency signal assigned to it is unique. As a nonlimiting example within this embodiment, a channel is typically referred to by the call letters or channel call sign such as: ABC, CBS, NBC, etc. A channel may also refer to the radio frequency used to transmit a cellular telephone call.
Channel tuning events that occur as a result of a previous human action means those interactions with a set-top box which happen later in time because of something a human being did previously. Nonlimiting examples include:
(i) set-top box tuning to a channel and recording a movie based on a human setting a recording,
(ii) a human initiated event which causes the set-top box to ‘wake-up’ at a later point in time and do something such as record a program.
Circuit means a communication channel in a network or a cellular network or a cable television network. Any communication channel which transmits data or information.
Computer equipment means any computer equipment used to facilitate the interaction of a human being with an electronic device across a network.
Computer system accessed through a network means any computer system, any individual piece of computer equipment or electronic gear, or any combination of computer equipment or electronic gear which enables or facilitates the human interaction with the electronic device. Nonlimiting examples include:
(i) cable television system,
(ii) cable television switched digital video system,
(iii) cellular phone network,
(iv) web server,
(v) any individual piece of computer equipment or electronic gear without limitation,
(vi) any combination of computer equipment or electronic gear without limitation, etc.
Data analysis computer system means a combination of one or more computers on which a Data Analysis Program or Programs can be executed.
Data analysis computer of known type means any commonly available computer system running a commonly known operating system. Nonlimiting examples include:
(i) a standard personal computer running Windows® XP operating system from Microsoft® Corporation,
(ii) a computer running the UNIX operating system,
(iii) a computer running the Linux operating system, etc.
Data analysis program means a computer program or programs containing algorithms that are able to analyze the data that has been loaded to a Data Structure or a combination of Data Structures.
Data base table means any relational data base table structure.
Data file that can be read by a computer program means any computer readable file format. Nonlimiting examples include:
(i) formatted text files,
(ii) pipe delimited text files, etc.
Data structure means a place in a computer program or computer system where data can be stored for analysis in such a manner that formulas and algorithms can be run against the data to produce meaningful metrics. Nonlimiting examples include:
(i) table in a COBOL program,
(ii) array or similar structure in a ‘C’ program,
(iii) spreadsheet;
such structures may be stored in the memory of the computer, but they could also be stored on electronic disk or other computer hardware.
Electronic device means any electronic device that may be used either directly or indirectly by a human being. Nonlimiting examples include: Gaming station, web browser, MP3 Player, Internet Protocol phone, Internet Protocol television, set-top box, satellite receiver, set-top box in a cable television network, set-top box in a satellite television system, cell phone, personal communication device, cable modem, personal video recorder, etc.
Electronic device usage data means any data that captures any aspect of a human interaction with an electronic device. Nonlimiting examples include:
(i) tuning activity on a set-top box,
(ii) call activity on a cell phone,
(iii) packet transfer data related to any internet activity, etc.
Electronic message means any computer readable output that can be used as input to another computer or read by a human. Nonlimiting examples include:
(i) data output in Extensible Markup Language format,
(ii) data output in Hypertext Markup Language format, etc.
Frequencies means radio frequencies in a cable television system or a cellular network.
Headend means a location in a network where incoming signals are received, prepared, and then transmitted downstream to other parts of the network. Nonlimiting examples include:
In a cable television network the signals are received at the headend, prepared and amplified, and then transmitted to downstream hubs for further distribution. A headend typically serves multiple hubs.
HFC Network means hybrid fiber coax network.
High definition means television channels having high resolution and thus they are delivered using a data transfer rate of approximately 15 megabits per second.
Hub means a location in a network where incoming signals are received, and then transmitted downstream to other parts of the network. Nonlimiting examples include:
In a cable television network the signals are received at the hub and then transmitted to downstream service groups or nodes for further distribution. A hub typically serves multiple service groups.
Human interactions means any interaction with an electronic device interacting with a computer system accessed through a network. Nonlimiting examples include:
(i) any activity involving a set-top box such as tune-in, tune-out, power on, power off, fast forward, reverse, mute, trick plays, etc.
(ii) any activity involving a personal communication device such as placing a call, receiving a call, calling, checking email, downloading data files, surfing the web, etc.
(iii) any activity involving a personal computer that is accessing the internet such as watching a movie, downloading files, surfing the web, etc.
Identifier of cable television system equipment serving said set-top box means any combination of letters, numbers or symbols that can identify equipment in a cable television system that is used to deliver signals to a set-top box. Nonlimiting examples include:
(i) internet protocol address,
(ii) SDV system identifier,
(iii) Service Group identifier,
(iv) Hub identifier,
(v) Headend identifier,
(vi) Market identifier,
(vii) Node identifier,
(viii) Any combination of the above fields, etc.
Identifier of computer system accessed through said network means any combination of letters, numbers or symbols that can identify a computer system that may be access though a network. Nonlimiting examples include:
(i) Internet protocol address,
(ii) Cell tower identifier,
(iii) Router identifier,
(iv) SDV system identifier,
(v) Service Group identifier,
(vi) Hub identifier,
(vii) Headend identifier,
(viii) Market identifier,
(ix) Node identifier,
(x) Any combination of the above fields, etc.
Identifier of electronic device means any combination of letters, numbers or symbols that can identify a device. Nonlimiting examples include:
(i) Set-top box Media Access Control address (MAC address),
(ii) Cell phone Electronic Serial Number (ESN), Mobile Identification Number (MIN), System Identification Code (SIC), phone number,
(iii) Computer internet protocol address, etc.
(iv) Encrypted versions of these values,
(vi) A generic identifier assigned to a multiple electronic devices having a similar demographic profile or viewing profile or usage profile.
Identifier of resource consumed means any combination of letters, numbers or symbols that can identify a Resource. Nonlimiting examples include:
(i) Channel call sign,
(ii) Channel source id,
(iii) Cell tower identifier,
(iv) Frequency,
(v) Radio frequency, etc.
Identifier of set-top box means any combination of letters, numbers or symbols that can identify a set-top box. Nonlimiting examples include:
(i) Set-top box Media Access Control address (MAC address),
(ii) Set-top box serial number, etc.
(iii) Encrypted versions of these values,
(iv) A generic identifier assigned to a multiple set-top boxes having a similar demographic profile or viewing profile or usage profile.
Identifying fields for things of interest for analysis means a field or combination of fields that can be used to identify the buckets in a Data Structure. Nonlimiting examples include:
(i) fields to identify the elements of a network where the network may be sub-divided into regions based on operational, organizational, or geographic areas, one example is Market, Service Group, Headend, Hub;
(ii) fields to identify components in a cellular network such as the cell tower, nodes, ports, circuits, etc.;
(iii) fields to identify the demographics of a person;
(iv) fields to identify activity occurring on an electronic device;
(v) fields to identify resource consumption;
(vi) fields to identify channels on a cable television system;
(vii) fields to identify computer hardware;
Etc.
Individual units of time means any period of time that may be of interest in relation to measuring human interaction with an electronic devices accessed through a network. Nonlimiting examples include:
(i) seconds in a day,
(ii) minutes in a day,
(iii) commercial periods during a television program,
(iv) quarter hours of a day,
(v) hours of a day,
(vi) four hour blocks in a day,
(vii) days,
(viii) time period when a certain program is running,
(ix) user defined day parts,
(x) user defined time periods,
Etc.
Interactions with electronic device that occur as a result of a previous human action means those interactions with an electronic device which happen later in time because of something a human being did previously. Nonlimiting examples include:
(i) set-top box tuning to a channel and recording a movie based on a human setting a recording;
(ii) a human initiated event which causes the set-top box to ‘wake-up’ at a later point in time and do something such as record a program.
(iii) a personal communication device automatically receiving email;
(iv) a file download process occurring based on a delayed start time setting.
In each example given, the human being did some interaction or set some parameter to cause the electronic device to wake-up and do something and it is occurring at a later time.
Internet protocol packets transferred means a measure of the number of data packets transferred to support the interaction of a human being with an electronic device. This can be internet protocol packets or Ethernet packets. Nonlimiting examples include:
(i) packets of data transferred to show an internet protocol television program,
(ii) packets of data transferred to support a web page access,
(iii) packets of data transferred to support a cell phone call, etc.
Information about location means any information that can be used to identify the place on the earth where an electronic device or a set-top box is. Nonlimiting examples include:
(i) longitude/latitude coordinates,
(ii) physical address,
(iii) a network address,
(iv) a location in a network,
(v) a geographic identifier.
Market means a geographic area within a service providers' network.
Megabits per second of data transferred means a measure of the amount of data transferred to support an electronic service. Nonlimiting examples include:
(i) the amount of data transferred per second to broadcast a standard definition channel,
(ii) the amount of data transferred per second to broadcast a high definition channel.
Network means any computer network. Nonlimiting examples include:
(i) a cable television network,
(ii) a cellular telephony network,
(iii) hybrid fiber coax system,
(iv) any means that supports communication among electronic devices or computers or computer systems without limitation, etc.
Network capacity means a measure of the amount of data that can be transferred during a period of time.
Network equipment means any physical or logical device used in a network. Nonlimiting examples include: hubs, routers, switches, nodes, circuits, port, etc.
Node means a component in a cellular network or a cable television network.
Pipe delimited text files means data files where the fields are separated by the “|” character.
Quadrature amplitude modulation signals means a measure of bandwidth consumption.
Radio frequencies means radio waves of various measures.
Real time channel tuning events means those interactions which occur as the person interacts with a set-top box. Nonlimiting examples include:
(i) set-top box tuning activity.
Real time human interactions means those interactions which occur as the person interacts with an electronic device. Nonlimiting examples include:
(i) set-top box tuning activity,
(ii) placing a cell phone call,
(ii) downloading a file, etc.
Resource means anything that supports or enables the interaction of the human being with an electronic device across a network. Nonlimiting examples include:
(i) channels, frequencies, radio frequencies, bandwidth, megabits per second of data transferred, internet protocol packets transferred, Ethernet packets transferred, computer equipment, network equipment, network capacity, cell towers, hubs, routers, switches, nodes, circuits, devices where each such resource is identifiable;
(ii) channels, quadrature amplitude modulation signals, frequencies, radio frequencies, bandwidth, megabits per second of data transferred, internet protocol packets transferred, Ethernet packets transferred, computer equipment, network equipment, hubs, routers, switches, nodes, circuits, devices and network capacity, switched digital video computer systems, all in a cable television system, where each such resource is identifiable.
Service group means a location in a network where incoming signals are received and then transmitted to set-top boxes. Nonlimiting examples include:
In a cable television network the signals are received at the service group and then transmitted to downstream nodes or to set-top boxes. A service group typically serves 500 to 1000 homes.
In some cable television networks a service group may equate to a Node.
Set-top box means an electronic device that receives external signals and decodes those signals into content that can be viewed on a television screen or similar display device. The signals may come from a cable television system, a satellite television system, a network, or any other suitable means. A set-top box may have one or more tuners. The set-top box allows the user to interact with it to control what is displayed on the screen. The set-top box is able to capture the commands given by the user and the transmit those commands to another computer system.
Spreadsheet means any commonly known electronic worksheet format. Nonlimiting examples include:
(i) Microsoft® Excel® files.
Standard definition means television channels having standard resolution and thus they are delivered using a data transfer rate of approximately 3.75 megabits per second.
STB means Set-top box.
Tune-in date and time means the date and time when the set-top box initiates viewing on the channel. This can be represented in any format that can be used to identify the point in time when the set-top box initiates viewing on the channel. Nonlimiting examples include:
(i) YYYY-MM-DD HH:MM:SS AM/PM,
(ii) YYYY-MM-DD 24HH:MM:SS,
(iii) seconds since some historic date, etc.
Tune-out date and time means the date and time when the set-top box ended viewing on the channel. This can be represented in any format that can be used to identify the point in time when the set-top box ended viewing on the channel. Nonlimiting examples include:
(i) YYYY-MM-DD HH:MM:SS AM/PM,
(ii) YYYY-MM-DD 24HH:MM:SS,
(iii) seconds since some historic date, etc.
Tuner means a tuner in a Set-top box.
Tuner index means an identifier of a tuner in a Set-top box.
Window of time of interest for analysis means any period of time during which it is desired to measure the human interaction with an electronic devices accessed through a network. Nonlimiting examples include:
(i) minutes in a day,
(ii) commercial periods during a television program,
(iii) quarter hours of a day,
(iv) hours of a day,
(v) four hour blocks in a day,
(vi) days,
(vii) any period of time useful for analysis
Etc.
In the drawings, closely related figures have the same number but different alphabetic suffixes.
When reading the information below, it can be appreciated that these are merely samples of table layouts, format and content, and many aspects of these tables may be varied or expanded within the scope of the embodiment. This table layouts, field formats and content, algorithms, and other aspects are what I presently contemplate for this embodiment, but other table layouts, field formats and content, algorithms, etc. can be used. The algorithms are samples and various aspects of the algorithms may be varied or expanded within the scope of the embodiment.
For many of the metrics shown below, I have suggested what the metric indicates. This is not to limit the purpose of the metric to that one usage, but simply to indicate one of potentially many valuable uses for the metric.
In one embodiment the Analytics Engine 140 can be implemented on processors provided by the Intel® Corporation under the trademark PENTIUM® using single or multiple processor configurations. The operating system offered by Microsoft® Corporation under the trademark Windows® XP Professional can be used as the basis for the platform. The Analytics Engine 140 can be implemented in a number of programming languages, including but not limited to, COBOL, C and C++.
I have implemented the Analytics Engine 140 and supporting code in Fujitsu® NetCOBOL® for Windows® version 10.1 developed by Fujitsu® and distributed by Alchemy Solutions Inc. This product is available at http://www.alchemysolutions.com or http://www.netcobol.com. The Analytics Engine 140 and all of the supporting processes have been developed and run on a Dell® WORKSTATION PWS360 with Intel® Pentium® 4 CPU 2.60 Ghz with 2.25 GB of RAM running Microsoft® Windows® XP Professional Version 2002 Service Pack 3. The computer was purchased from Dell Computer Corporation. The operating system is from Microsoft.
Although the embodiments described herein enable one of ordinary skill in the art to implement (i.e. build) the Analytics Engine 140 and supporting software, it in no way restricts the method of implementation, the Analytics Engine 140 and supporting software being capable of being implemented on a variety of hardware/software platforms with a variety of development languages, databases, communication protocols and frameworks as will be evident to those of ordinary skill in the art.
A cable television company operating a Switched Digital Video system using the SDV platform of a first vendor 102 collects channel tune data 112 in the format provided by Vendor 1's SDV system as part of the normal operation of said Switched Digital Video system. Channel tune data 112 is then preprocessed using a computer program 122 which reformats said SDV vendor's channel tune data into a common format, performs data enrichments, and applies business rules as data quality checks all in preparation for passing an unsorted channel tune file in a common or standardized format 130 into a sort function 132 which then sorts the data producing Sorted Channel Tune File in common format 134 in preparation for processing by an Analytics Engine 140.
A cable television company operating a Switched Digital Video system using the SDV platform of a second vendor 104 collects channel tune data in the format provided by Vendor 2's SDV system as part of the normal operation of said Switched Digital Video system. Channel tune data 114 is then preprocessed using a computer program 124 which reformats said SDV vendor's channel tune data into a common format, performs data enrichments, and applies business rules as data quality checks all in preparation for passing an unsorted channel tune file in a common or standardized format 130 into a sort function 132 which then sorts the data producing Sorted Channel Tune File in common format 134 in preparation for processing by an Analytics Engine 140.
A cable television company or satellite television broadcasting company provides Set-top box application software 106 for its customers to use to operate their set-top box. Such software may be developed in-house or by a third party. The STB software 106 collects channel tune data 116 as part of the normal operation of said Set-top box application software system. STB Channel tune data 116 is then preprocessed using a computer program 126 which reformats the STB Channel tune data 116 into a common format, performs data enrichments, and applies business rules as data quality checks all in preparation for passing an unsorted channel tune file in a common or standardized format 130 into a sort function 132 which then sorts the data producing Sorted Channel Tune File in common format 134 in preparation for processing by an Analytics Engine 140.
Analytics Engine 140 then loads the preprocessed channel tune data into the memory of a computer performing various aggregations, calculations and analytics which are then exported (written) to one or more files to make the analytics available for further reporting and analysis or for loading to downstream systems. The files produced include: STB-Channel-viewing-detail 152, STB-viewing-detail 154, Channel-viewing-detail 156, Channel-Second-of-day-summary 162, Channel-daily-statistics-summary 164, Demographic-viewing-summary 166, Program-attribute-viewing-summary 168 each containing metrics that have used data collected in the channel tuning file 112 to
(i) provide insight into the amount of resource consumed by said human interaction with said set-top boxes interacting with said cable television system,
(ii) provide insight into the set-top box usage pattern of said human, and
(iii) provide insight into the behavior of said human.
For each record the program Reformats the record from the pipe-delimited format in which it was received to a fixed format 212.
The program then calculates 214 the tune-in and tune-out time in seconds of the day resulting in a values between 1 and 86,400. The calculations performed vary depending on the input format of the date and time.
The program then applies business rules 216 for data quality. For example, if the duration between tune-in and tune-out is more than 7,200 seconds (2 hours) the program terminates the session at the top of the next hour by assigning that second of the day as the tune-out time. Another business rule assigns default tune-in or tune-out times as needed to account for sessions that are missing a tune-in or tune-out time because the events occurred on different dates. The business rules to be applied vary depending on the what rules the SDV Vendor has applied to the file.
After the business rules 216 have been applied, the program checks to see if the record passes the quality checks 218.
For records that pass the quality checks 218, the program then optionally performs function Add demographic information 230 to the tuning record. This is done by using the Set-top box identifier to lookup various demographic values associated with the Set-top box user and then including those values as fields in the tuning record. The cable company or satellite provider or a third party could provide a file of demographic values (not shown) to associate with the Set-top box identifier. The Set-top box identifier may or may not be encrypted as long as the value of the STB identifier matches the values used in the demographic file.
Additionally, for records that pass the quality checks 218, the program then optionally performs function Add program attribute information 240 to the tuning record. This is done by using the Channel Source Id and the tune-in time of the tuning activity, along with Market+Headend+Hub as needed to locate the programming schedule relevant to the STB. Once the programming schedule information is located, the program can then access various program attribute values such as program type (sports, news, movie, advertisement), program genre, program rating, etc. and include these values as fields in the tuning record. The cable company or satellite provider or a third party could provide a file of program attributes to associate with the tuning data. This would measure the program attribute information at the time of tune-in event. Depending upon the type of measurement desired, one could systematically generate additional tuning records as the program attributes change in order to capture viewing behavior as program attributes change. The SDV vendor may be able to include this information in the data file.
At the completion of these steps, the record is Released to the sort function 250.
At this point the process proceeds to go to read the next record in the file 252.
If a tuning record fails the quality checks 218, the record is written to the discard file 220. From here the process proceeds to go to read next record in the file 222.
Thus Preprocess 124 requires an initial step Process Part A to prepare to reformat the file such that the tune-in and tune-out appear on the same record. This Preprocess computer program begins with 302. The program first Reformats 306 the entire Vendor 2 SDV Channel Tune File 114 file from pipe delimited format to fixed format. The program then Sorts 308 the file in order Market, Service Group, Set-top box id, Tuner index, Date, and Time. The sort output is 310 Vendor 2 Channel Tune File Sorted. The program is now Done with Process Part A and can proceed to Part B 312.
Step 324 is to identify end of file which indicates that file processing is Done 326.
For each record set, the program processes each record 328 in the set as follows: It loads the record set to an array in the memory of the computer. The program then matches the tune-out record to the previous tune-in record building a complete tuning record (one containing both a tune-in and a tune-out time).
The program then proceeds to 330 where for each record we enrich it by looking up the Hub and Headend using Market and Service Group as keys. When we find these values we include them in the tuning record.
The program then proceeds to 332 where for each record it is enriched by looking up the Channel Name, Channel Call Sign, Bit Rate, Program Type (SDV or Broadcast) using Market and Channel Id as keys. These values are then loaded to the tuning record.
The program then proceeds to 336 where for each record it is enriched by calculating the tune-in and tune-out time in seconds of day resulting in values between 1 and 86,400. The calculations performed vary depending on the input format of the date and time. These values are then loaded to the tuning record.
The program then proceeds to apply business rules 340 for data quality. For example, if the duration between tune-in and tune-out is more than 7,200 seconds (2 hours) the program terminates the session at the top of the next hour by assigning that second of the day as the tune-out time. Another business rule assigns default tune-in or tune-out times as needed to account for sessions that are missing a tune-in or tune-out time because the events occurred on different dates. Because of differences between the data from SDV Vendor 1 and SDV Vendor 2, the business rules may vary.
After the business rules 340 have been applied, the program checks to see if the record passes the quality checks 342.
For records that pass the quality checks 340, the program then optionally performs function Add demographic information 230 to the tuning record in the same manner as was done for SDV Vendor 1 data.
Additionally, for records that pass the quality checks 342, the program then optionally performs Add program attribute information 240 to the tuning record in the same manner as was done for SDV Vendor 1 data.
At the completion of these steps, the final formatting rules are applied and all the records in the record set are Released to the sort function 348.
At this point the program proceeds to go to read next record set 352. If a tuning record fails the quality checks 342, the record is written to the discard file 344.
Step 346 checks to see if it is the last record in the set.
If there are additional records in the set, step 350 continues processing records in the set.
If the record was the last record in the set 349, the program proceeds to read the next record set in the file 322.
Thus Preprocess 124 requires an initial step Process Part A to prepare to reformat the file such that the tune-in and tune-out appear on the same record. This Preprocess computer program begins with 402. The program first Reformats 406 the entire Set-top Box Channel Tune File 116 file from pipe delimited format to fixed format. The program then Sorts 408 the file in order Set-top box id, Tuner index, and Time (which is in seconds from some historic date). The sort output is 410 Set-top Box Vendor Channel Channel Tune File Sorted. The program is now Done with Process Part A and can proceed to Part B 412.
Step 424 is to identify end of file which indicates that file processing is Done 426.
For each record set, the program processes each record 428 in the set as follows: It loads the record set to an array in the memory of the computer. The program then matches the tune-out record to the previous tune-in record building a complete tuning record (one containing both a tune-in and a tune-out time). The tune-out time of a record is the tune-in time of the next (subsequent) record minus 1 second. When the next activity is a power off, the tune-out time can be set as the time of the power off minus 1 second.
The program then proceeds to 430 where for each record it converts the tune-in time in seconds from the historic date to the actual tune-in date in YYYY-MM-DD HH:MM:SS AM/PM format.
The program then proceeds to 432 where for each record it converts the tune-out time in seconds from the historic date to the actual tune-out date in YYYY-MM-DD HH:MM:SS AM/PM format.
The program then proceeds to 434 where each record is enriched by looking up the Market, Service Group, Hub, and Headend using Set-top box identifier as the key to a lookup table. These values are then loaded to the tuning record.
The program then proceeds to 436 where each record is enriched by looking up the Channel Call Sign, Channel Source Id, Bit Rate, High Def or Standard Def code, and SDV or Broadcast code using Market and channel information as the keys to a lookup table. These values are then loaded to the tuning record.
The program then proceeds to 438 where for each record it is enriched by calculating the tune-in and tune-out time in seconds of day resulting in values between 1 and 86,400. These values are then loaded to the tuning record.
The program then proceeds to 440 where it applies business rules for data quality. For example, if the duration between tune-in and tune-out is more than 7,200 seconds (2 hours) the program terminates the session at the top of the next hour by assigning that second of the day as the tune-out time. Another business rule assigns default tune-in or tune-out times as needed to account sessions that are missing a tune-in or tune-out time because the events occurred on different dates. Based on the particulars of the Set-top box application and the quality checks it applies to the data, the business rules may vary.
After the program has applied business rules 440, it checks to see if the record passes the quality checks 442.
For records that pass the quality checks 442, the program then optionally performs function 230 to Add demographic information to the tuning record in the same manner as was done for SDV Vendor 1 data.
Additionally, for records that pass the quality checks 442, the program then optionally performs function 240 to Add program attribute information to the tuning record in the same manner as was done for SDV Vendor 1 data. The STB vendor may add program attribute information to the tuning file.
At the completion of these steps, the program then applies final formatting rules and releases the record to sort function 448.
At this point the program proceeds to read next record set 452.
If a tuning record fails the quality checks 442, the record is written to the discard file 444.
If there are additional records in the set, step 450 continues processing records in the set.
If the record was the last record in the set 449, the program proceeds to read the next record set in the file 422.
The process begins with Sort Preprocessed Channel Tune File 502. The program first Determines run type 504. Depending on the type of analytics to be produced, the system will sort the file that is used as input in a particular order.
In one embodiment, the run type is Set-top box+Channel Viewing detail 510. In this case, the Unsorted Channel Tune File in common format 130 is Sort by 514 into order: Market, Service Group, Hub, Headend, Set-top box id, Tuner Index, Channel Call Sign, Channel Source Id, and Tune-in second of day. The resulting file from this computer sort is File sorted for Set-top box+Channel viewing Analytics 518 which is a particular instance of part 134.
In another embodiment, the run type is Set-top box Viewing detail 520. In this case, the Unsorted Channel Tune File in common format 130 is Sort by 524 into order: Market, Service Group, Hub, Headend, Set-top box id, Tuner Index, and Tune-in second of day. The resulting file from this computer sort is File sorted for Set-top box viewing Analytics 528 which is a particular instance of part 134.
In another embodiment, the run type is Channel Viewing detail 530. In this case, the Unsorted Channel Tune File in common format 130 is Sort by 534 into order: Market, Service Group, Hub, Headend, Channel Call Sign, Channel Source Id, and Tune-in second of day. The resulting file from this computer sort is File sorted for Channel viewing Analytics 538 which is a particular instance of part 134.
In another embodiment, the run type is Program Attribute Aggregation 540. In this case, the Unsorted Channel Tune File in common format 130 is Sort by 544 into order: Market, Service Group, Hub, Headend, Program Attribute 1, Program Attribute 2, and Tune-in second of day. The resulting file from this computer sort is File sorted for Program Attribute Analytics 548 which is a particular instance of part 134.
In another embodiment, the run type is Demographic Category Aggregation 550. In this case, the Unsorted Channel Tune File in common format 130 is Sort by 554 into order: Market, Service Group, Hub, Headend, Demographic Category 1, Demographic Category 2, and Tune-in second of day. The resulting file from this computer sort is File sorted for Demographic Category Analytics 558 which is a particular instance of part 134.
When it is not end of file, the program Searches for key of Channel Tune record in STB-CHANNEL-VIEWING-DETAIL Data Structure (table) in the memory 612. The Comparison fields for this search are STB-CVD-MARKET, STB-CVD-SERVICE-GROUP, STB-CVD-HUB, STB-CVD-HEADEND, STB-CVD-CHANNEL-CALL-SIGN, STB-CVD-CHANNEL-SOURCE-ID, STB-CVD-STB-ID, STB-CVD-TUNER-INDEX 614. When Found match on key 616 is Yes/true, the program proceeds to set STB-CHAN-VIEWED-FLAG to 1 for each second of the day from tune-in second of day to tune-out second of day inclusive 620.
When Found match on key 616 is No/false, the program Populate a row in STB-CHANNEL-VIEWING-DETAIL using the key in Channel Tune record 618. It then proceeds to 620 where populates the STB-CHAN-VIEWED-FLAG.
After the program has completed step 620, it proceeds to 606 to read the next record in the file.
When it is not end of file, the program Searches for key of Channel Tune record in STB-VIEWING-DETAIL table in the memory 712. The Comparison fields for this search are STB-VD-MARKET, STB-VD-SERVICE-GROUP, STB-VD-HUB, STB-VD-HEADEND, STB-VD-STB-ID, STB-VD-TUNER-INDEX 714. When Found match on key 716 is Yes/true, the program proceeds to set STB-VIEWED-FLAG to 1 for each second of the day from tune-in second of day to tune-out second of day inclusive 720.
When Found match on key 716 is No/false, the program Populate a row in STB-VIEWING-DETAIL using the key in Channel Tune record 718. It then proceeds to 720 where it populates the STB-VIEWED-FLAG.
After the program has set the completed step 720, it proceeds to 706 to read the next record in the file.
When it is not end of file, the program Searches for key of Channel Tune record in CHAN-VIEWING-DETAIL Data Structure in the memory 812. The Comparison fields for this search are CHAN-VD-MARKET, CHAN-VD-SERVICE-GROUP, CHAN-VD-HUB, CHAN-VD-HEADEND, CHAN-VD-CHANNEL-CALL-SIGN, CHAN-VD-CHANNEL-SOURCE-ID 814. When Found match on key 816 is Yes/true, the program proceeds to add 1 to CHAN-STB-VIEWED-CHANNEL-COUNT for each second of the day from tune-in second of day to tune-out second of day inclusive 820.
When Found match on key 816 is No/false, the program Populate a row in CHAN-VIEWING-DETAIL using the key in Channel Tune record 818. It then proceeds to 820 where the program does add 1 to CHAN-STB-VIEWED-CHANNEL-COUNT as before.
The program also tallies tune-ins-per-second 3940 at this time by adding 1 to the second of the day in which the tune-in occurs. See program for details.
After the program has completed step 820, it proceeds to 806 to read the next record in the file.
When it is not end of file, the program Searches for key of Channel Tune record in DEMO-VIEWING-DETAIL Data Structure in the memory 912. The Comparison fields for this search are DEMO-VD-MARKET, DEMO-VD-SERVICE-GROUP, DEMO-VD-HUB, DEMO-VD-HEADEND, DEMO-VD-DEMOGRAPHIC-CAT-1, DEMO-VD-DEMOGRAPHIC-CAT-2914. When Found match on key 916 is Yes/true, the program proceeds to add 1 to DEMO-STB-VIEWED-COUNT for each second of the day from tune-in second of day to tune-out second of day inclusive 920.
When Found match on key 916 is No/false, the program Populate a row in DEMO-VIEWING-DETAIL using the key in Channel Tune record 918. It then proceeds to 920 where add 1 to DEMO-STB-VIEWED-COUNT as before.
After the program has set the completed step 920, it proceeds to 906 to read the next record in the file.
When it is not end of file, the program Searches for key of Channel Tune record in PROG-VIEWING-DETAIL Data Structure in the memory 962. The Comparison fields for this search are PROG-VD-MARKET, PROG-VD-SERVICE-GROUP, PROG-VD-HUB, PROG-VD-HEADEND, PROG-VD-PROGRAM-ATTRIBUTE-1, PROG-VD-PROGRAM-ATTRIBUTE-2964. When Found match on key 966 is Yes/true, the program proceeds to add 1 to PROG-STB-VIEWED-COUNT for each second of the day from tune-in second of day to tune-out second of day inclusive 970.
When Found match on key 966 is No/false, the program Populate a row in PROG-VIEWING-DETAIL using the key in Channel Tune record 968. It then proceeds to 970 where add 1 to PROG-STB-VIEWED-COUNT as before.
After the program has completed step 970, it proceeds to 956 to read the next record in the file.
In order to reduce the size of this Data Structure, the program can limit the period of analysis to a part of the day such as prime time viewing hours.
The Analytics Engine 140 populates each of the fields as follows:
STB-CVD-MARKET 3010 is populated from MARKET 1810 in input file 518.
STB-CVD-SERVICE-GROUP 3020 is populated from SERVICE-GROUP 1820 in input file 518.
STB-CVD-HUB 3030 is populated from HUB 1830 in input file 518.
STB-CVD-HEADEND 3040 is populated from HEADEND 1840 in input file 518.
STB-CVD-CHANNEL-CALL-SIGN 3050 is populated from CHANNEL-CALL-SIGN 1870 in input file 518.
STB-CVD-CHANNEL-SOURCE-ID 3060 is populated from CHANNEL-SOURCE-ID 1880 in input file 518.
STB-CVD-STB-ID 3070 is populated from SET-TOP-BOX-ID 1850 in input file 518.
STB-CVD-TUNER-INDEX 3080 is populated from TUNER-INDEX 1860 in input file 518.
The following fields require more complex processing to populate.
STB-CHANNEL-VIEWING-SECONDS 3090 has this definition:
For each set-top box+channel combination, count of the number of seconds the set top box was tuned to the channel during the day. This measures how much time the STB was tuned to each channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying stb-chan-sub
End-perform
STB-CHANNEL-TUNE-INS 3100 has this definition:
For each set-top box+channel combination, count of the number of times the set-top box tuned to that channel during the day. This measures the propensity of the viewer to gravitate back to a channel after leaving it. A tune-in is identified in the table by a STB channel viewed flag of 1 that was immediately preceded by a STB channel viewed flag of 0. If the channel was tuned at the first second of the day, we count that as a tune in.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying stb-chan-sub
End-perform
STB-CHAN-AVG-VIEWING-DURATION 3110 has this definition:
Set-top box+Channel average viewing duration measures the average length of time that the set-top box was tuned to that channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying stb-chan-sub
End-perform
STB-CHAN-STAY-AWAY-SECS-TOTAL 3120 has this definition:
For each set-top box+channel combination, count the number of seconds the STB stays away from the channel, but include only those tune-away events where the STB returns to the channel soon thereafter, such as within 300 seconds or five minutes, and total this for the day. This measures the propensity of the viewer to return to the channel after leaving it.
The Analytics Engine 140 performs an algorithm to populate this field. The algorithm is shown in the source code.
STB-CHAN-STAY-AWAY-TUNE-COUNT 3130 has this definition:
For each set-top box+channel combination, count of the number of times the set top box goes away from the channel and then returns soon thereafter, totaled for the day. This measures how often the viewer leaves the channel only to return soon thereafter (for example, within 300 seconds).
The Analytics Engine 140 performs an algorithm to populate this field. The algorithm is shown in the source code.
STB-CHAN-AVG-STAY-AWAY-SECS 3140 has this definition:
For each set-top box+channel combination, this is a measure of the average stay away seconds, for those channel changes on the STB that qualify as stay-away channel changes. This produces an average of how long the viewer stays away when the viewer leaves the channel only to return soon thereafter.
The Analytics Engine 140 performs the following algorithm to populate this field:
If Stb-chan-stay-away-tune-count (stb-chan-sub)>0
Compute Stb-chan-avg-stay-away-secs(stb-chan-sub)=Stb-chan-stay-away-secs-total(stb-chan-sub)/Stb-chan-stay-away-tune-count(stb-chan-sub)
End-if
In order to reduce the size of this Data Structure, the program can limit the period of analysis to a part of the day such as prime time viewing hours.
The Analytics Engine 140 populates each of the fields as follows:
STB-VD-MARKET 3210 is populated from MARKET 1810 in input file 528.
STB-VD-SERVICE-GROUP 3220 is populated from SERVICE-GROUP 1820 in input file 528.
STB-VD-HUB 3230 is populated from HUB 1830 in input file 528.
STB-VD-HEADEND 3240 is populated from HEADEND 1840 in input file 528.
STB-VD-STB-ID 3250 is populated from SET-TOP-BOX-ID 1850 in input file 528.
STB-VD-TUNER-INDEX 3260 is populated from TUNER-INDEX 1860 in input file 528.
The following fields require more complex processing to populate.
STB-Viewing-seconds 3270 has this definition:
For each set-top box, count of the number of seconds the set top box was tuned to some channel during the day. This measures the quantity of viewing activity on the STB.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying stb-sub
End-perform
STB-tune-ins 3280 has this definition:
For each set-top box, count of the number of times the set-top box tuned to any channel during the day. This measures the propensity of the viewer to change channels.
The Analytics Engine 140 performs the following algorithm to populate this field:
PERFORM VARYING STB-SUB
END-PERFORM.
STB-Average-viewing-duration 3290 has this definition:
Set-top box average viewing duration measures the average length of time that the STB is tuned to a channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying stb-sub
End-perform
At the end of the tallying process, a 0 means that no STB tuned to that channel during that second. A 1 means that only one STB tuned to the channel during that second of the day. A number greater than 1 indicates the count of how many STB's tuned to that channel during that second of the day.
The Analytics Engine 140 populates each of the fields as follows:
CHAN-VD-MARKET 3410 is populated from MARKET 1810 in input file 538.
CHAN-VD-SERVICE-GROUP 3420 is populated from SERVICE-GROUP 1820 in input file 538.
CHAN-VD-HUB 3430 is populated from HUB 1830 in input file 538.
CHAN-VD-HEADEND 3440 is populated from HEADEND 1840 in input file 538.
CHAN-VD-CHANNEL-CALL-SIGN 3450 is populated from CHANNEL-CALL-SIGN 1870 in input file 538.
CHAN-VD-CHANNEL-SOURCE-ID 3460 is populated from CHANNEL-SOURCE-ID 1880 in input file 538.
CHAN-BIT-RATE 3470 is populated from BIT-RATE 1970 in input file 538
SDV-OR-BROADCAST-CODE 3480 is populated from SDV-OR-BROADCAST-CODE 1980 in input file 538
HIGH-DEF-OR-STD-DEF 3490 is populated from HIGH-DEF-OR-STD-DEF 1990 in input file 538.
The following fields require more complex processing to populate.
CHANNEL-VIEWING-SECONDS 3500 has this definition:
Channel viewing seconds measures at a channel level the number of seconds during the day that at least one set-top box was viewing the channel. When this value is low, it indicates that this channel may be a good candidate to be a switched channel in a Switched Digital Video environment. When this value is high it indicates that the channel may be a good candidate to be a broadcast channel in a Switched Digital Video environment. While this embodiment shows at least one STB viewing the channel, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's are viewing the channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
CHANNEL-NON-VIEWING-SECONDS 3510 has this definition:
Channel non-viewing seconds measures at a channel level the number of seconds during the day that no set-top box was viewing the channel. When this value is high, it indicates that this channel may be a good candidate to be a switched channel in a Switched Digital Video environment.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
CHANNEL-ONE-STB-VIEWING-SECONDS 3520 has this definition:
Channel one STB viewing seconds measures at a channel level the number of seconds during the day that only one set-top box was viewing the channel. While this embodiment shows one STB viewing the channel, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's are viewing the channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
AGG-CHANNEL-VIEWING-SECONDS 3530 has this definition:
Aggregate channel viewing seconds measures at a channel level the number of seconds of viewing of the channel during the day. When more STB's that are concurrently tuned to the channel then this value is higher. The higher this value the more popular the channel is. Advertisers would want to know this.
When this value is high it indicates that the channel may be a good candidate to be a broadcast channel in a Switched Digital Video environment.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PCT-OF-DAY-ONLY-ONE-STB-VIEWG-CHAN 3540 has this definition:
Percent of the day when only one STB is viewing the channel is calculated as Channel-one-STB-Viewing-seconds/seconds-in-day. When this value is high, it indicates that this channel may be a good candidate to be a switched channel in a Switched Digital Video environment. When this value is high it indicates that the advertising reach is low. While this embodiment shows one STB viewing the channel, this value could be set to any desired variable as described for field CHANNEL-ONE-STB-VIEWING-SECONDS 3520.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PCT-OF-DAY-NO-STB-VIEWING-CHANNEL 3550 has this definition:
Percent of the day when no STB is viewing the channel is calculated as Channel-Non-Viewing-seconds/seconds-in-day. When this value is high, it indicates that this channel may be a good candidate to be a switched channel in a Switched Digital Video environment. When this value is high it indicates that for much of the day no one is watching the channel thus advertising during those times would yield no benefit.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PCT-OF-DAY-VIEWING-CHANNEL 3560 has this definition:
Percent of the day when the channel is being viewed is calculated as Channel-Viewing-seconds/seconds-in-day. When this value is high, it indicates that this channel may be a good candidate to be a broadcast channel in a Switched Digital Video environment.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PEAK-VIEWING-COUNT-FOR-CHANNEL 3570 has this definition:
Peak viewing count for channel measures how many STB's are tuned to the channel during its peak viewing second.
Peak-viewing-second-for-chan can be compared with Peak-usage-second-by-STB-view which measures the peak viewing second based on the number of STB's viewing all the channels combined. This will tell whether the peak for this channel is significantly different from the peak viewing second for all the channels together. When the peak for this channel occurs near the peak for all the channels, it indicates that the program being aired on this channel draws strong viewership ratings even in a crowd.
PEAK-VIEWING-SECOND-FOR-CHAN 3580 has this definition:
Peak viewing second for channel measures the second of the day when the most STB's are tuned to this channel. This measures the time of day when the most people are tuned to this channel. Advertisers would like to know this.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
Perform varying chan-sub
End-perform
AGG-VIEWING-AT-THIS-CHAN-PEAK 3590 has this definition:
Aggregate channel viewing at this channel's peak measures how much aggregate viewing is happening when this channel is at its peak. This allows us to measure how this channel stacks up to other channels when this channel is at its best.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
calc-other-viewing.
Perform varying chan-sub-for-peak
End-perform
PCT-OF-PEAK-VIEW-BY-THIS-CHANPEAK 3600 has this definition:
Percent of peak viewership by this channel's peak measures what part of the total viewing audience is tuned to this channel during this channel's peak viewing period. This measures the popularity of this channel's best program compared to other programs running at the same time.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PCT-OF-PEAK-VIEW-BY-STB-VIEWNG 3610 has this definition:
Percent of peak viewership by STB Viewing measures what part of the viewing audience is tuned to this channel during the peak viewing period for all the channels when peak second is the most active second based on all the STB's viewing. This measures the viewing strength of this channel compared to the other channels during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
CHAN-VIEWED-DURING-PEAK-FLAG 3620 has this definition:
Channel viewed during peak flag identifies the channels that were viewed during the peak second of the day when peak second is the most active second based on all the STB's viewing.
For this channel, this identifies whether or not any STB was tuned to it during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PEAK-PERIOD-DURATION-IN-SECONDS 3630 has this definition:
Peak duration in seconds is an input variable that is used to specify the length of the peak viewing period. For example, 30 minutes would be 1,800 seconds.
The Analytics Engine 140 assigns the value to this field.
CHAN-VIEWED-SECS-DURING-PEAK 3640 has this definition:
Channel viewed seconds during peak identifies the number of seconds during the peak viewing window that this channel was viewed by at least one STB. This metric is useful for capacity planning to identify the amount of time during the peak period that this channel is viewed.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
AGG-CHAN-VIEWED-SECS-DURING-PEAK 3650 has this definition:
Aggregate Channel viewed seconds during peak identifies the number of aggregate viewing seconds that this channel captured during the peak viewing window. When multiple STB's are all tuned to the same channel for all or most of the peak viewing window, this measures that. This is a measure of channel popularity during the peak viewing window. As the number of viewers increases this number increases.
From a capacity planning perspective, when this value is high, it indicates that this channel may be a good candidate to be a broadcast channel in a Switched Digital Video environment.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
PCT-OF-PEAK-PERIOD-CHAN-WAS-VIEWED 3660 has this definition:
Percent of time the channel was viewed during peak period measures how much of the time during the peak viewing period that at least one STB was tuned to the channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying chan-sub
End-perform
CHAN-SOD-SERVICE-GROUP 3820 is populated from SERVICE-GROUP 1820 in input file 538.
CHAN-SOD-HUB 3830 is populated from HUB 1830 in input file 538.
CHAN-SOD-HEADEND 3840 is populated from HEADEND 1840 in input file 538.
The following fields require more complex processing to populate.
BY-SEC-CHAN-VIEWED-COUNT 3860 has this definition:
By second, channel viewed count is for each second of the day, a count of the number of channels that had viewing activity of at least one STB tuned to the channel. While this embodiment shows at least one STB viewing the channel, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's are viewing the channel.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-NO-CHAN-VIEWED-COUNT 3870 has this definition:
By second, no channel viewed count is for each second of the day, count the number of channels that had no viewing activity.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-AGG-CHAN-VIEWED-COUNT 3880 has this definition:
By second, aggregate channel viewed count is for each second of the day, count the number of different set-top boxes that were tuned to all the channels combined.
This is the second of the day when the most people are tuned to the system. The is the time when the demand on system capacity is greatest.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-BANDWIDTH-REQD-QUANTITY 3890 has this definition:
By second of the day, bandwidth required quantity is for each second of the day, a count of the amount of bandwidth required to service the channels being viewed, with bandwidth measured in megabits per second. Capacity planners would need to monitor this value to ensure that the system can meet the demand. If this value rarely approaches the installed capacity in the system, it may indicate that there is excess capacity.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-SDV-CHAN-VIEWED-COUNT 3900 has this definition:
By second, SDV channel viewed count is for each second of the day, a count of the number of Switched Digital Video channels that had viewing activity. In a Switched Digital Video environment when this value is consistently low it may indicate an opportunity to add additional switched channels.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
From 1 by 1
End-perform
BY-SEC-BCAST-CHAN-VIEWED-COUNT 3910 has this definition:
By second, Broadcast channel viewed count is for each second of the day, a count of the number of Broadcast channels that had viewing activity.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-STD-DEF-CHAN-VIEWED-CNT 3920 has this definition:
By second, Standard Definition channel viewed count is for each second of the day, a count of the number of Standard Definition channels that had viewing activity. This number is useful from a network engineering perspective.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
BY-SEC-HIGH-DEF-CHAN-VIEW-CNT 3930 has this definition:
By second, High Definition channel viewed count is for each second of the day, a count of the number of High Definition channels that had viewing activity. This number is useful from a network engineering perspective.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying second-sub
End-perform
TUNE-INS-PER-SECOND-COUNT 3940 has this definition:
The Analytics Engine 140 performs the following algorithm to populate this field:
Tune-in's per second are tallied at the time of loading the data array so no additional calculations are needed at this point.
CHAN-CDS-MARKET 4210 is populated from MARKET 1810 in input file 538.
CHAN-CDS-SERVICE-GROUP 4220 is populated from SERVICE-GROUP 1820 in input file 538.
CHAN-CDS-HUB 4230 is populated from HUB 1830 in input file 538.
CHAN-CDS-HEADEND 4240 is populated from HEADEND 1840 in input file 538.
The following fields require more complex processing to populate.
PEAK-PERIOD-DURATION-IN-SECONDS 4260 has this definition:
Peak period duration in seconds records the duration of the peak period in seconds. This is a user chosen value such as 30 minutes which would be 1800 seconds.
PEAK-PERIOD-MOST-CHAN-VIEW-BEG-SEC 4270 has this definition:
Peak period (measured in) most channels viewed beginning second records the second which marks the beginning of the peak viewing window when peak is based on largest number of channels viewed.
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Peak-period-most-chan-view-beg-sec=Peak-usage-second-by-chan-view−(Peak-period-duration-in-seconds/2)
Note: If the beginning of the peak period would fall in the previous day, then set it to the first second of the day, since we only process the current day.
PEAK-PERIOD-MOST-CHAN-VIEW-END-SEC 4280 has this definition:
Peak period (measured in) most channels viewed ending second records the second which marks the ending of the peak viewing window when peak is based on largest number of channels viewed.
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Peak-period-most-chan-view-end-sec=Peak-usage-second-by-chan-view+(Peak-period-duration-in-seconds/2)
Note: If the end of the peak period would fall in the next day, then set it to the last second of the day, since we only process the current day.
PEAK-PERIOD-MOST-STB-ACTIV-BEG-SEC 4290 has this definition:
Peak period (measured in) most set-top boxes active beginning second records the second which marks the beginning of the peak viewing window when peak is based on largest number of active set-top boxes.
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Peak-period-most-STB-activ-beg-sec=Peak-usage-second-by-STB-view−(Peak-period-duration-in-seconds/2)
Note: If the beginning of the peak period would fall in the previous day, then set it to the first second of the day, since we only process the current day.
PEAK-PERIOD-MOST-STB-ACTIV-END-SEC 4300 has this definition:
Peak period (measured in) most set-top boxes active ending second records the second which marks the ending of the peak viewing window when peak is based on largest number of active set-top boxes.
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Peak-period-most-STB-activ-end-sec=Peak-usage-second-by-STB-view+(Peak-period-duration-in-seconds/2)
Note: If the end of the peak period would fall in the next day, then set it to the last second of the day, since we only process the current day.
PEAK-USAGE-IN-MBITS-PER-SEC 4320 has this definition:
Peak usage in megabits per second is the highest bandwidth usage in megabits per second that was recorded during the day.
This measures the capacity in Megabits per second required to deliver the channels being viewed during the peak second of the day. If this value rarely approaches the installed capacity in the system, it may indicate that there is excess capacity.
PEAK-USAGE-SECOND-IN-MBITS-PER 4330 has this definition:
Peak usage second captures the second of the day when this peak usage occurred.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
Move zero to Peak-usage-in-mbits-per-sec
Move zero to Peak-usage-in-mbits-per-sectmp
Move zero to Peak-usage-second-in-mbits-per
Move zero to Peak-usage-second-in-mbits-tmp
Perform varying second-sub
End-perform
Move Peak-usage-second-in-mbits-tmp to
Move Peak-usage-in-mbits-per-sectmp to
PCT-OF-PEAK-TO-BE-NEAR-THRESHOLD 4340 has this definition:
Percent of peak to be near threshold is a system defined variable. It allows the analyst to specify a percentage of the peak usage that is considered to be near the threshold of system capacity.
The Analytics Engine 140 assigns a value as follows:
Move 0.90 to Pct-of-peak-to-be-near-threshold
NEAR-PEAK-THRESHOLD-IN-MBITS-PER 4350 has this definition:
Near peak threshold in megabits per second is the threshold value that is used to determine whether the network usage during any particular second is near the peak. For example, is the usage during any second of the day >90% of the peak usage second of the day?
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Near-peak-threshold-in-mbits-per=Peak-usage-in-mbits-per-sec*Pct-of-peak-to-be-near-threshold [e.g.: 0.90]
COUNT-OF-SEC-MBITS-NEAR-PEAK 4360 has this definition:
Count of seconds megabit near peak is a count of the number of seconds in the day when the megabits per second needed to deliver the channels being viewed is near the peak where peak is calculated as being within x percent of the peak usage for the day, measured in megabits per second. This measures the load on the system and tells how sustained that load is. For network capacity planning we can tell whether the load is a short spike or a sustained high volume.
The Analytics Engine 140 performs the following algorithm to populate this field:
Move zero to Count-of-sec-mbits-near-peak
Perform varying second-sub
End-perform
PCT-OF-DAY-MBITS-NEAR-PEAK 4370 has this definition:
Percent of day megabits near peak is a calculated value that tells the percentage of the day that the bandwidth usage in megabits per second is near the peak.
The Analytics Engine 140 performs the following algorithm to populate this field:
Compute Pct-of-day-mbits-near-peak=Count-of-sec-mbits-near-peak/seconds-in-array*100
MAX-TUNE-INS-PER-SECOND 4390 has this definition:
Maximum tune-in's per second measures the number of tune-in events on the busiest second of the day when busy is measured by number of tune-in's. This is useful from a capacity planning perspective to be sure that the SDV system has capacity to handle the volume of tune requests with a proper amount of spare capacity.
MAX-TUNE-INS-SEC-OF-DAY 4400 has this definition:
Maximum tune-in's second of the day records the second of the day during which the maximum number of tune-in's occurred.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
End-perform
Move Max-tune-ins-per-second-temp to
Move Max-tune-ins-sec-of-day-temp to
PEAK-USAGE-BY-CHAN-VIEWED-CNT 4420 has this definition:
Peak usage by channel viewed count measures the number of different channels being viewed on the busiest second of the day when busy is measured by number of channels viewed.
PEAK-USAGE-SECOND-BY-CHAN-VIEW 4430 has this definition:
Peak usage second (of the day) by channels being viewed records second of the day during which the maximum number of channels are being viewed.
This is the second of the day when the viewers are tuned to the most different channels. This is important from an advertiser's perspective to see when the viewing audience is most distributed. This is important from a capacity planning perspective to be sure that the SDV system has capacity to handle the volume of channels being viewed with a proper amount of spare capacity.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
Move zero to Peak-usage-by-chan-viewed-cnt
Move zero to Peak-usage-by-chan-viewed-cnt-tmp
Move zero to Peak-usage-second-by-chan-view
Move zero to Peak-usage-second-by-chan-view-tmp
Perform varying second-sub
End-perform
PEAK-USAGE-BY-STB-VIEWING-CNT 4440 has this definition:
Peak usage by STB viewing count measures the number of different set-top boxes tuned to the system during the busiest second of the day.
PEAK-USAGE-SECOND-BY-STB-VIEW 4450 has this definition:
Peak usage second (of the day) by set-top boxes being viewed records the second of the day during which the maximum number of different set-top boxes are tuned to the system.
This is important from an advertisers perspective to see when the viewing audience is largest.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
AGG-STB-VIEW-AT-PEAK-SEC-OFDAY 4460 has this definition:
Aggregate STB viewing at the peak second of the day measures how many different STB's were tuned to all the channels combined during the peak second of the day when peak is measured by STB count.
The Analytics Engine 140 performs the following algorithm to populate both of these fields:
At the end of the tallying process, a 0 means that no STB having that Demographic Category tuned-in during that second. A 1 means that only one STB having that Demographic Category tuned-in during that second of the day. A number greater than 1 indicates the count of how many STB's having that Demographic Category tuned-in tuned-in during that second of the day.
DEMO-VD-MARKET 4810 is populated from MARKET 1810 in input file 558.
DEMO-VD-SERVICE-GROUP 4820 is populated from SERVICE-GROUP 1820 in input file 558.
DEMO-VD-HUB 4830 is populated from HUB 1830 in input file 558.
DEMO-VD-HEADEND 4840 is populated from HEADEND 1840 in input file 558.
DEMO-VD-DEMOGRAPHIC-CAT-14850 is populated from DEMOGRAPHIC-CATEGORY-12020 in input file 166.
DEMO-VD-DEMOGRAPHIC-CAT-24860 is populated from DEMOGRAPHIC-CATEGORY-22030 in input file 166.
The following fields require more complex processing to populate.
DEMO-VIEWING-SECONDS 4880 has this definition:
Demographic viewing seconds measures at a demographic level the number of seconds during the day that at least one set-top box having this demographic was tuned-in. When this value is low, it indicates that people in this demographic are not watching television. While this embodiment shows at least one STB with the demographic viewing, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's having the demographic are viewing.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
DEMO-NON-VIEWING-SECONDS 4890 has this definition:
Demographic non-viewing seconds measures at a demographic level the number of seconds during the day that no set-top box having this demographic was tuned-in. When this value is high, it indicates that people in this demographic are not watching television.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
DEMO-ONE-STB-VIEWING-SECONDS 4900 has this definition:
Demographic one STB viewing seconds measures at a demographic level the number of seconds during the day that only one set-top box having this demographic was tuned-in. While this embodiment shows at least one STB with the demographic viewing, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's having the demographic are viewing.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
AGG-DEMO-VIEWING-SECONDS 4910 has this definition:
Aggregate demographic viewing seconds measures at a demographic level the number of total viewing seconds during the day that STB's having this demographic were tuned-in. When more STB's in this demographic are concurrently tuned to any channel then this value is higher. The higher this value the more this demographic watches television. Advertisers would want to know this.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PCT-OF-DAY-ONLY-ONE-STB-VIEWG-DEMO 4920 has this definition:
Percent of the day when only one STB having this demographic is tuned-in (viewing television) is calculated as Demo-one-STB-Viewing-seconds/seconds-in-day. When this value is high it indicates that the advertising reach is low.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
PCT-OF-DAY-NO-STB-VIEWING-DEMO 4930 has this definition:
Percent of the day when no STB having this demographic is tuned-in (viewing television) is calculated as Demo-Non-Viewing-seconds/seconds-in-day. When this value is high it indicates that for much of the day no one from this demographic is watching television thus advertising during those times would yield no benefit.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
PCT-OF-DAY-VIEWING-DEMO 4940 has this definition:
Percent of the day when this demographic is viewing television is calculated as Demo-Viewing-seconds/seconds-in-day. When this value is high, it indicates that STB's having this demographic view a lot of television.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
PEAK-VIEWING-COUNT-FOR-DEMO 4960 has this definition:
Peak viewing count for demo measures how many STB's from this demographic are tuned-in during its peak viewing second.
PEAK-VIEWING-SECOND-FOR-DEMO 4970 has this definition:
Peak viewing second for demographic measures the second of the day when the most STB's having this demographic are tuned-in. This measures the time of day when the most STB's having this demographic are tuned-in. Advertisers would like to know this.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
AGG-VIEWING-AT-THIS-DEMO-PEAK 4980 has this definition:
Aggregate demographic viewing at this demographic's peak measures how much aggregate viewing is happening when this demographic is at its peak. This allows us to measure how this demographic stacks up to other demographics when this demographic is at its best.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
calc-other-viewing.
Perform varying demo-sub-for-peak
End-perform
PCT-OF-PEAK-VIEW-BY-THIS-DEMOPEAK 4990 has this definition:
Percent of peak viewership by this demographic's peak measures what part of the total viewing audience is from this demographic during this demographic's peak viewing period. This measures the popularity of this demographic's best program compared to programs from other demographics running at the same time.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
PCT-OF-PEAK-VIEW-BY-STB-VIEWNG 5010 has this definition:
Percent of peak viewership by STB viewing measures what part of the viewing audience is from this demographic during the peak viewing second for all the demographic groups when peak second is the most active second based on all the STB's viewing. This measures the viewing strength of this demographic compared to the other demographic groups during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
DEMO-VIEWED-DURING-PEAK-FLAG 5020 has this definition:
Demographic viewed during peak flag identifies the demographic segments that were viewing during the peak second of the day when peak second is the most active second based on all the STB's viewing. For this demographic, this identifies whether or not any STB identified by this demographic was tuned-in during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying demo-sub
End-perform
PEAK-PERIOD-DURATION-IN-SECONDS 5030 has this definition:
Peak duration in seconds is an input variable that is used to specify the length of the peak viewing period. For example, 30 minutes would be 1,800 seconds.
DEMO-VIEWED-SECS-DURING-PEAK 5040 has this definition:
Demographic viewed seconds during peak identifies the number of seconds during the peak viewing window that at least one STB having this demographic was tuned-in. This metric measures whether or not people having this demographic view television during the peak viewing period.
The Analytics Engine 140 performs the following algorithm to populate this field:
If DEMO-STB-VIEWED-COUNT (demo-sub, second-sub)>0
Compute Demo-viewed-secs-during-peak(demo-sub)=Demo-viewed-secs-during-peak(demo-sub)+1
AGG-DEMO-VIEWED-SECS-DURING-PEAK 5050 has this definition:
Aggregate Demographic viewed seconds during peak identifies the number of aggregate viewing seconds captured by STB's having this demographic, during the peak viewing window. When multiple STB's all having the same demographic are all tuned to any channel for all or most of the peak viewing window, this measures that. This metric measures how many STB's having this demographic are tuned-in during the peak viewing period. As the number of viewers increases this number increases.
The Analytics Engine 140 performs the following algorithm to populate this field:
PCT-OF-PEAK-PERIOD-DEMO-VIEWED 5060 has this definition:
Percent of time the demographic was viewed during peak period measures how much of the time during the peak viewing window that at least one STB having this demographic was tuned-in.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
At the end of the tallying process, a 0 means that no STB tuned to any program having that Program Attribute 1 and Program Attribute 2 combination during that second. A 1 means that only one STB tuned to any program having that Program Attribute 1 and Program Attribute 2 combination during that second. A number greater than 1 indicates the count of how many STB's tuned to any program having that Program Attribute 1 and Program Attribute 2 combination during that second of the day.
The Analytics Engine 140 populates each of the fields as follows:
PROG-VD-MARKET 5210 is populated from MARKET 1810 in input file 548.
PROG-VD-SERVICE-GROUP 5220 is populated from SERVICE-GROUP 1820 in input file 548.
PROG-VD-HUB 5230 is populated from HUB 1830 in input file 548.
PROG-VD-HEADEND 5240 is populated from HEADEND 1840 in input file 548.
PROG-VD-PROGRAM-ATTRIBUTE-15250 is populated from PROGRAM-ATTRIBUTE-12000 in input file 134/548.
PROG-VD-PROGRAM-ATTRIBUTE-25260 is populated from PROGRAM-ATTRIBUTE-22010 in input file 134/548.
The following fields require more complex processing to populate.
PROG-VIEWING-SECONDS 5280 has this definition:
Program viewing seconds measures at a program attribute level the number of seconds during the day that at least one set-top box was tuned to a program having this program attribute. When this value is low, it indicates that programs having this program attribute are not being viewed very much. While this embodiment shows one STB viewing programs having this program attribute, this value could be set to any desired variable. As a non-limiting example, count seconds where greater than ten STB's are viewing programs having this program attribute.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PROG-NON-VIEWING-SECONDS 5290 has this definition:
Program non-viewing seconds measures at a program attribute level the number of seconds during the day that no set-top box was tuned to a program having this program attribute. When this value is high, it indicates that people do not watch programs having this program attribute very much.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PROG-ONE-STB-VIEWING-SECONDS 5300 has this definition:
Program one STB viewing seconds measures at a program attribute level the number of seconds during the day that only one set-top box was tuned to a program having this program attribute.
The Analytics Engine 140 performs the following algorithm to populate this field:
AGG-PROG-VIEWING-SECONDS 5310 has this definition:
Aggregate program attribute viewing seconds measures at a program attribute level the number of seconds during the day that programs having this program attribute were being viewed. When more STB's are concurrently tuned to programs having this program attribute then this value is higher. The higher this value the more popular the programs having this program attribute are. Advertisers would want to know this.
The Analytics Engine 140 performs the following algorithm to populate this field:
PCT-OF-DAY-ONLY-ONE-STB-VIEWG-PROG 5320 has this definition:
Percent of the day when only one STB is viewing programs having this program attribute is calculated as Prog-one-STB-Viewing-seconds/seconds-in-day. When this value is high it indicates that the advertising reach is low.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying prog-sub
End-perform
PCT-OF-DAY-NO-STB-VIEWING-PROG 5340 has this definition:
Percent of the day when no STB is viewing programs having this program attribute is calculated as Prog-Non-Viewing-seconds/seconds-in-day. When this value is high it indicates that for much of the day no one is viewing programs having this program attribute thus advertising during those times would yield no benefit.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PCT-OF-DAY-VIEWING-PROG 5350 has this definition:
Percent of the day viewing programs having this program attribute is calculated as Prog-Viewing-seconds/seconds-in-day. When this value is high, it indicates that the STB's are often tuned to programs having this program attribute.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying prog-sub
End-perform
PEAK-VIEWING-COUNT-FOR-PROG 5370 has this definition:
Peak viewing count for program attribute measures how many STB's are tuned to programs having this program attribute during the program attribute's peak viewing second.
PEAK-VIEWING-SECOND-FOR-PROG 5380 has this definition:
Peak viewing second for program attribute measures the second of the day when programs having this program attribute are viewed the most. This measures the time of day when the most STB's are tuned to programs having this program attribute. Advertisers would like to know this.
The Analytics Engine 140 performs the following algorithm to populate these fields:
End-perform
AGG-VIEWING-AT-THIS-PROG-PEAK 5390 has this definition:
Aggregate program attribute viewing at this program attribute's peak measures how much aggregate viewing is happening when viewing of programs having this program attribute is at its peak. This allows us to measure how programs having this program attribute stack up to programs with other attributes when programs having this program attribute are at their best.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
calc-other-viewing.
Perform varying prog-sub-for-peak
End-perform
PCT-OF-PEAK-VIEW-BY-THIS-PROGPEAK 5400 has this definition:
Percent of peak viewership by this program attribute's peak measures what part of the total active STB's were tuned to programs having this program attribute during its peak viewing period. This measures the popularity of this program attribute's best program compared to programs having other program attributes running at the same time.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PCT-OF-PEAK-VIEW-BY-STB-VIEWNG 5420 has this definition:
Percent of peak viewership by STB viewing measures what part of the total active STB's were tuned to programs having this program attribute during the peak viewing second for all the programs when peak second is the most active second based on all the STB's viewing. This measures the viewing strength of programs having this program attribute compared to the other programs during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PROG-VIEWED-DURING-PEAK-FLAG 5430 has this definition:
Program viewed during peak flag identifies the attributes of the programs to which the active STB's were tuned during the peak second of the day when peak second is the most active second based on all the STB's viewing. For programs having this program attribute, this identifies whether or not any STB was tuned to them during the peak viewing second.
The Analytics Engine 140 performs the following algorithm to populate this field:
Perform varying prog-sub
End-perform
PEAK-PERIOD-DURATION-IN-SECONDS 5440 has this definition:
Peak duration in seconds is an input variable that is used to specify the length of the peak viewing period. For example, 30 minutes would be 1,800 seconds.
PROG-VIEWED-SECS-DURING-PEAK 5450 has this definition:
Program viewed seconds during peak identifies the number of seconds during the peak viewing window that at least one STB was tuned to programs having this program attribute. This metric measures whether or not people view programs having this program attribute during the peak viewing period.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
AGG-PROG-VIEWED-SECS-DU RING-PEAK 5460 has this definition:
Aggregate Program viewed seconds during peak identifies the number of aggregate viewing seconds from STB's tuned to programs having this program attribute during the peak viewing window. When multiple STB's are all tuned to programs having this program attribute for all or most of the peak viewing window, this measures that. This metric measures how many STB's are tuned to programs having this program attribute during the peak viewing period. As the number of viewers viewing programs having this program attribute increases, this number increases.
The Analytics Engine 140 performs the following algorithm to populate this field:
End-perform
PCT-OF-PEAK-PERIOD-PROG-VIEWED 5470 has this definition:
Percent of time the program attribute was viewed during peak period measures how much of the time during the peak viewing period that at least one STB was tuned to programs having this program attribute.
The Analytics Engine 140 performs the following algorithm to populate this field:
This is the detail of part 152.
The Analytics Engine 140 is moving data from the Data Structure defined in
End-perform
This is the detail of part 154.
The Analytics Engine 140 is moving data from the Data Structure defined in
End-perform
This is the detail of part 156.
The Analytics Engine 140 is moving data from the Data Structure defined in
End-perform
This is the detail of part 162.
The Analytics Engine 140 is moving data from the Data Structure defined in
Perform varying second-sub
End-perform
This is the detail of part 164.
The Analytics Engine 140 is moving data from the Data Structure defined in
This is the detail of part 166.
The Analytics Engine 140 is moving data from the Data Structure defined in
End-perform
This is the detail of part 168.
The Analytics Engine 140 is moving data from the Data Structure defined in
End-perform
In this nonlimiting example, the purpose is not to describe in detail the operations of a cellular network, but to simply show that the human being 7800 is interacting with an electronic device 8010 which is interacting with a computer system 8050 accessed through a network 8040.
To follow the chain of interactions in this nonlimiting example, the human being 7800 is using an electronic device 8010 such as a cell phone or a personal communication device or any similar electronic device. The electronic device 8010 uses a radio wave or electronic signal 8020 to communicate with a cell tower 8030 which then communicates via a network 8040 to reach a computer system such as a node or port 8050 which then communicates via a another network segment 8040 to access a computer system 8050 which uses another network segment 8040 to communicate with another computer system 8050 which uses another network segment 8040 to communicate with another node or port 8050 which users another network segment 8040 to communicate with another cell tower 8030 which sends out an electronic signal 8022 to communicate with a second electronic device 8012 which is being used by a second human being 7802.
In this nonlimiting example, the purpose is not to describe in detail the operations of an internet protocol network, but to simply show that the human being 7800 is interacting with an electronic device 8220 which is interacting with a computer system 8230 accessed through a network 8040.
To follow the chain of interactions in this nonlimiting example, the human being 7800 is using an electronic device 8220 such as an internet protocol television or any similar electronic device. The electronic device 8220 uses a network 8040 to communicate with an IP TV Delivery computer system 8230 which provides video the IP TV. IP TV Delivery computer system 8230 itself also uses a network 8040 to communicate with an IP TV Video Server computer system 8250.
In these nonlimiting examples, the purpose is not to describe in detail the operations of a cable television network or a switched digital video system, but to simply show that the human being 7800 or 7802 or 7804 is interacting with a set-top box 7810 or 7812 or 7814 which is interacting with a computer system 102 or 104 or 7870 accessed through a network 7830 or 7832 or 7834 and that the overall network includes various components such as SDV systems, Cable Video systems, STB systems, Service Groups, Hubs, and Headends which are all part of a Market in a cable television system.
To follow the chain of interactions in this nonlimiting example, in the first Switched Digital Video part of this Figure, the human being 7800 is using a set-top box 7810 or any similar electronic device attached to a television 7820. The signal produced by the set-top box 7810 is viewed on a television 7820. The set-top box 7810 uses a HFC network segment 7830 to communicate with Switched Digital Video system from Vendor 1102 which is accessed via a Service Group 7840 and a Hub 7850. The Hub 7850 is linked to a Headend 7890 via a transport ring 7900. Switched Digital Video system from Vendor 1102 produces the file Vendor 1 SDV Channel Tune File 112 which can then be made available for preprocessing in preparation for processing by the Analytics Engine 140 as explained in other Figures.
To continue following the chain of interactions in this nonlimiting example, in the second Switched Digital Video part of this Figure, the human being 7802 is using a set-top box 7812 or any similar electronic device attached to a television 7822. The signal produced by the set-top box 7812 is viewed on a television 7822. The set-top box 7812 uses a HFC network segment 7832 to communicate with Switched Digital Video system from Vendor 2104 which is accessed via a Service Group 7840 and a Hub 7850. The Hub 7850 is linked to a Headend 7890 via a transport ring 7900. Switched Digital Video system from Vendor 2104 produces the file Vendor 2 SDV Channel Tune File 114 which can then be made available for preprocessing in preparation for processing by the Analytics Engine 140 as explained in other Figures.
To further continue following the chain of interactions in this nonlimiting example, in the non-Switched Digital Video part of this Figure, a different human being 7804 is using a different set-top box 7814 or any similar electronic device attached to a television. The signal produced by the set-top box 7814 is viewed on a different television 7824. The set-top box 7814 uses a different HFC network segment 7834 to communicate with a Cable Video Computer System 7870 which is accessed via a Service Group 7840 and a Hub 7850. The Hub 7850 is linked to a Headend 7890 via a transport ring 7900. Set-top box 7814 is running Set-top box application software from STB software vendor 106 and said software is collecting channel tuning data which is used to produce Set-top box Vendor Channel Tune File 116.
The following details are not shown: The Set-top box Vendor Channel Tune File 116 from a plurality of set-top boxes is routed back through the HFC Network 7834 where the files are aggregated and can then be made available for preprocessing in preparation for processing by the Analytics Engine 140 as explained in other Figures.
To summarize these nonlimiting examples shown in
In these nonlimiting examples, the purpose is not to describe in detail the operations of a satellite television network, but to simply show that the human being 7806 is interacting with a set-top box 7816 which is interacting with computer systems 8004 and 8050 accessed through networks 8006 and 8040 and that the overall network includes various components such as a Computer that sends signals to a satellite and a computer that receives set-top box activity, both being part of a satellite television system.
To follow the chain of interactions in this nonlimiting example, the video or audio signal is sent by the Computer sending Signal to Satellite 8004 as a Signal to Satellite 8006. The Satellite 8010 receives the signal and beams it as a Signal from a Satellite 8020 to the Satellite receiver dish 8030 where it is then passed on to the Set-top box 7816. The Human Being 7806 controls the Set-top box 7816 by interacting with it. The Set-top box application software from STB software vendor 106 captures the interactions of the Human Being 7806 and packages them into a file Set-top box Vendor Channel Tune File 116 or other message which is then send to the Satellite providers STB Usage Data Collection Computer System 8050 using or across the Satellite providers network 8040. The file of set-top box activity can then be made available for preprocessing in preparation for processing by the Analytics Engine 140 as explained in other Figures.
Although the descriptions above contains many specificities, these should not be construed as limiting the scope of the embodiments but as merely providing illustrations of some of several embodiments. As a nonlimiting example, any of the calculations can be done for the day or for any part of the day, additional calculations can be done once the data is loaded to the Data Structure, and/or aggregations can be done to summarize data to minute or day-part.
As a second nonlimiting example, device usage data can reflect multiple concurrent activities such as a set-top box using multiple tuners simultaneously as in multiple pictures on a television screen or one picture on the television screen and one video stream being recorded by a digital video recorder. One can readily envision set-top box applications or personal computer applications or advanced television applications which show multiple windows such as a television program, a TV menu, a sports channel, a weather channel, a traffic cam, a twitter (© 2010 Twitter, Twitter, Inc.) session, an instant message session, a You Tube (© 2010 YouTube, LLC, www.youtube.com) video, an email session, a web browsing session, a Facebook (Facebook© 2010, www.facebook.com) session, etc. Usage data could be collected for each of these activities with perhaps weightings assigned to the activities based on business rules. I presently contemplate device usage data being provided in flat files, but another embodiment may provide this data in any computer readable format including but not limited to data base tables, XML messages, or other messaging constructs.
I presently contemplate using mnemonics for the various identifiers such as market, headend, hub, service group, channel call sign, program attribute data, demographic category, and other similar fields, but another embodiment could use numeric values as identifiers.
I presently contemplate using identifiers such as market, headend, hub, and service group, but another embodiment could use fewer identifiers or different identifiers or no identifiers.
I presently contemplate reading the tuning data from a flat file, but another embodiment could obtain the tuning data directly from a data base as a result of a query or from an XML message. In like manner, Electronic device usage data could also be obtained from a data base or from an XML message instead of a flat file.
I presently contemplate sorting the tuning data as a separate step, but another embodiment could use an “order by” clause in a data base query to sort the result set.
I presently contemplate executing the algorithms described herein separately in some sequence, but another embodiment could combine multiple simple algorithms into fewer complex algorithms.
I presently contemplate sorting the tuning data before loading it to the Data Structure, but another embodiment may load unsorted data to the Data Structure as long as the search algorithms were configured to find matching key values in the Data Structure as the data is being loaded.
In regard to Channel data (
In regard to Demographic data (
In regard to Program Attribute data (
I presently contemplate a separate process to enhance the device usage data with program attribute data and/or demographic category data, but this step could be combined into a single process in which device usage data is retrieved from a data base along with program attribute data and/or demographic category data as part of a larger query process.
I presently contemplate that the tune-in date and time and the tune-out date and time will be presented in YYYY-MM-DD HH:MM:SS AM/PM format. Another embodiment could provide these values in seconds from some historic date such as Epoch time (Jan. 1, 1970) and then subtract the proper number of seconds from the value so as to bring the value into the seconds of the current date. For example, Aug. 1, 2010 at 12:00:00 AM is Epoch time 1280646000. Subtracting this value from any tune-in date and time or tune-out date and time from Aug. 1, 2010, will result in the second of the day that can be used in populating the Data Structure. A tune-in at Aug. 1, 2010 at 12:30:00 AM has Epoch time of 1280647800. Thus we see that 1280647800−1280646000=1800 seconds which would be 30 minutes after midnight. Either embodiment can be used as input to create the metrics.
I presently contemplate that the Analytics Engine will be provided with the tune-in date and time and the tune-out date and time presented in YYYY-MM-DD HH:MM:SS AM/PM format. Another embodiment could provide the tune-in date and time in this format and then provide the Analytics Engine with the duration of the tuning activity in seconds instead of providing the tune-out date and time presented in YYYY-MM-DD HH:MM:SS AM/PM format. In this situation the Analytics Engine would add the tuning duration in seconds to the tune-in time in seconds to arrive at the tune-out time.
I presently contemplate that the analytics engine will be provided with the tune-in date and time and the tune-out date and time presented in YYYY-MM-DD HH:MM:SS AM/PM format. Another embodiment could provide the tune-out date and time in this format and then provide the Analytics Engine with the duration of the tuning activity in seconds instead of providing the tune-in date and time presented in YYYY-MM-DD HH:MM:SS AM/PM format. In this situation the Analytics Engine would subtract the tuning duration in seconds from the tune-out time in seconds to arrive at the tune-in time.
I presently contemplate processing one day's data at a time, but another embodiment may process more than one day of data or a part of a day.
I presently contemplate using variables having the data types and field sizes shown, but another embodiment may use variables with different data types and field sizes to accomplish a similar result. I presently contemplate using Data Structure(s) similar to those defined herein, but another embodiment may use a different Data Structure or Data Structures to accomplish a similar result.
I presently contemplate using the Windows® XP operating system from Microsoft® Corporation, but another embodiment may use a different operating system.
I presently contemplate using Fujitsu® NetCOBOL® for Windows® version 10.1 developed by Fujitsu® and distributed by Alchemy Solutions Inc, but another embodiment may use a different programming language or a different version of COBOL.
It will be apparent to those of ordinary skill in the art that various changes and modifications may be made which clearly fall within the scope of the embodiments revealed herein. In describing an embodiment illustrated in the drawings, specific terminology has been used for the sake of clarity. However, the embodiments are not intended to be limited to the specific terms so selected, and it is to be understood that each specific term includes all technical equivalents which operate in a similar manner to accomplish a similar purpose.
In general, it will be apparent to one of ordinary skill in the art that various embodiments described herein, or components or parts thereof, may be implemented in many different embodiments of software, firmware, and/or hardware, or modules thereof. The software code or specialized control hardware used to implement some of the present embodiments is not limiting of the present embodiment. For example, the embodiments described hereinabove may be implemented in computer software using any suitable computer software language type such as, for example, C, C#, or C++ using, for example, conventional or object-oriented techniques. Such software may be stored on any type of suitable computer-readable medium or media such as, for example, a magnetic or optical storage medium. Thus, the operation and behavior of the embodiments are described in COBOL style pseudocode purely as a matter of convenience. It is clearly understood that artisans of ordinary skill would be able to design software and control hardware to implement the embodiments presented in the language of their choice based on the description herein with only a reasonable effort and without undue experimentation.
The processes associated with the present embodiments may be executed by programmable equipment, such as computers. Software or other sets of instructions that may be employed to cause programmable equipment to execute the processes may be stored in any storage device, such as, for example, a computer system (non-volatile) memory, an optical disk, magnetic tape, or magnetic disk. Furthermore, some of the processes may be programmed when the computer system is manufactured or via a computer-readable medium.
It can also be appreciated that certain process aspects disclosed herein may be performed using instructions stored on a computer-readable memory medium or media that direct a computer or computer system to perform process steps. A computer-readable medium may include, for example, memory devices such as diskettes, compact discs of both read-only and read/write varieties, optical disk drives, and hard disk drives. A computer-readable medium may also include memory storage that may be physical, virtual, permanent, temporary, semi-permanent and/or semi-temporary.
In various embodiments disclosed herein, a single component or algorithm may be replaced by multiple components or algorithms, and multiple components or algorithms may be replaced by a single component or algorithm, to perform a given function or functions. Except where such substitution would not be operative to implement the embodiments disclosed herein, such substitution is within the scope presented herein. Thus any element expressed herein as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a combination of elements that performs that function. Therefore, any means that can provide such functionalities may be considered equivalents to the means shown herein.
While I have developed this embodiment on a personal computer, it can be appreciated that the “data analysis computer system” may be, for example, a wireless or wire line variety of a microcomputer, minicomputer, server, mainframe, laptop, personal data assistant (PDA), wireless e-mail device (e.g., “BlackBerry” trade-designated devices), phone, smart phone, cellular phone, cable box, pager, processor, fax machine, scanner, or any programmable device configured to transmit and receive data over a network. Computer devices disclosed herein may include memory for storing certain software applications used in obtaining, processing and communicating data. It can be appreciated that such memory may be internal or external to the disclosed embodiments. The memory may also include any means for storing software, including a hard disk, an optical disk, floppy disk, ROM (read only memory), RAM (random access memory), PROM (programmable ROM), EEPROM (electrically erasable PROM), and other computer-readable media.
While various embodiments have been described herein, it should be apparent, however, that various modifications, alterations and adaptations to those embodiments may occur to persons skilled in the art with the attainment of some or all of the advantages described herein. The disclosed embodiments are therefore intended to include all such modifications, alterations and adaptations without departing from the scope and spirit of the embodiments presented herein as set forth in the appended claims.
Accordingly, the scope should be determined not by the embodiments illustrated, but by the appended claims and their legal equivalents.
Advantages
From the description above, a number of advantages of some embodiments of my Analytics Engine 140 and its supporting processes become evident:
By loading the device usage data to a data structure with individual buckets (cells in memory) representing individual units of time during a window of time of interest for analysis, and then correlating those buckets (cells) with identifying fields, this produces the result that the Analytics Engine 140 can produce metrics that were not previously possible. This method is contrary to the teaching of those who work with start time and duration (seconds viewed) in a relational data base model. Thus I am able to solve problems previously found insolvable when limited to using the existing techniques.
In regard to television viewing, I have provided numerous metrics showing a level of detailed analytics not previously possible. For example, the Analytics Engine 140 allows us measure detailed viewing behavior of lightly viewed channels for which traditional survey methods do not provide data. The Analytics Engine 140 allows us to provide deeper insight into highly viewed channels. The Analytics Engine 140 is able to provide the detailed information that industry researchers urgently need. There are many other examples contained herein.
In regard to other electronic devices such as cell phones and personal communication devices, the same Analytic Engine 140 can be applied to provide numerous similar metrics.
Set-Top Box Channel Viewership Analysis
The Analytics Engine 140 allows us to produce detailed metrics of individual set-top box behavior. These metrics have multiple uses including capacity planning, resource consumption analysis, understanding electronic device usage patterns, and understanding human behavior. Some of these metrics include:
The Analytics Engine 140 allows us to produce detailed metrics of channel viewing behavior. These metrics have multiple uses including capacity planning, resource consumption analysis, understanding electronic device usage patterns, and understanding human behavior. Some of these metrics include:
In addition to the metrics presented above, the Analytics Engine 140 is able to merge demographic data with detailed viewing patterns or detailed device usage patterns. Many in the industry recognize the value of being able to associate demographics with customer activities. Advertisers are continually seeking to better understand various characteristics about both current customers and potential customers. Additionally, service providers such as cable companies and cell phone companies need to better understand their customers in order to provide relevant services to them.
In the case of cable providers, channel change data, whether from the STB or from the SDV system, does not typically contain any demographic data. In the case of STB data, it is common to provide power on/power off, channel change, volume change, trick play, and similar data. In the case of SDV channel change data, it is common to provide Service Group, Channel identifier, STB identifier, tune-in date-time, tune-out date-time, bit rate, and similar fields. In neither case does the vendor provide demographic data.
The problem of missing demographic data can be solved relatively simply by the cable company. The SDV channel change log files contain a Set-top box identifier. This is typically a MAC address. Those with normal skill in the art will readily understand that it would be a relatively simple process for the cable provider to use this MAC address to look up demographic data associated with the MAC address and provide it along with the channel change data.
In the case of cell phone providers, device activity data can be augmented with demographic data. The cell phone company has the phone number or other unique identifier of the device. This could be used to associate the device usage data with demographic data.
In both cases, the demographic information or demographic attributes could include fields such as these as nonlimiting examples:
For privacy considerations, the cable company could provide a consistent substitute (e.g. a scrambled MAC address) for the set-top box identifier (the MAC address) in the channel change file. By substituting a scrambled MAC address for the actual MAC address, no one would be able to identify the particular household by using the MAC address to look up the customer. By having a consistent substitute (one that does not change over time), the privacy of the viewer is maintained and the Analytics Engine 140 can track the viewer's viewing and usage patterns across multiple channel change events over a period of time. Similarly the cell phone company could take steps to protect the privacy of its customers.
Once the demographic data is available to the Analytics Engine 140, numerous additional metrics can be developed. A few examples related to cable television will suffice for this recap:
In each of the examples, the demographic attribute could be any two values in the list above. So the metric produced could be:
The Analytics Engine 140 I have developed will produce metrics based on combining two different demographic attributes. It will produce metrics for all combinations of the two specified attributes. As a nonlimiting example, the same concept that produces metrics for two demographic attributes could be used to produce metrics for more than two demographic attributes.
Program Attribute Analysis
As to identifying the attributes of programming consumed, the channel change data, whether from the STB or from the SDV system, does not typically provide this. A list of program attributes could include any of the following as nonlimiting examples:
Those with normal skill in the art will readily understand that the cable company or data provider could associate any of these program attributes with the channel change data such that the channel change record would also identify some number of these program attributes. The Analytics Engine 140 that I have developed will produce metrics based on combining two different program attributes. The cable company can during preprocessing augment the tuning data with additional tuning records to reflect each change in program attributes. For example, if a channel tune lasts two hours, there may be programs each having different program attributes that occur during this time. The cable company could create tuning records for each of these with the result that the Analytics Engine 140 would then create more detailed metrics based on program attribute.
As a nonlimiting example, the same concept that produces metrics for two program attributes could be used to produce metrics for more than two program attributes.
Benefits of Combining Channel Change Data with Program Attribute Data
By having program attribute data available along with the channel change data, the Analytics Engine 140 can produce metrics based on program attribute. Such metrics could be useful in several areas:
SDV Node Assignment Benefits
In SDV systems, it is helpful from a capacity planning perspective to assign viewers with similar viewing patterns to the same node within a service group or to the same service group. This is because the bulk of the resource consumption related to supplying a switched channel at a point in time is the resource required to service the first requestor of that channel in that service group. Any additional set-top boxes can be given access to the same viewing stream with very minimal extra resource consumption. By analogy, once a train is operating for one passenger, it is a small task to take along additional passengers.
A very simple example of this is that if ten viewers in a service group all typically watch a particular switched history channel during the day and a particular switched nature channel during the evening, then it is more efficient to assign these ten viewers to the same fiber node or service group because once the first viewer causes the SDV system to make the signal available for his STB, it is readily available for all of the other STB's in that fiber node or service group.
The opposite of this case would be to have a fiber node or service group in which every viewer typically watches a different channel. This would require more resources to support.
Thus the goal of data analysis should be to provide insight into how to assign customers to fiber nodes or service groups so that viewers with similar viewing patterns are assigned to the same fiber node or service group. The Analytics Engine 140 I have developed will create the aggregated data that can then be loaded to a statistical analysis package to identify these patterns in support of group assignment.
Advertisement Placement
By combining the channel tuning data with the program attributes, advertisers can see the time of day when programs having certain attributes are typically being viewed. This can be done with fine granularity so as to provided more targeted advertising. A few examples will suffice:
In each of the examples, the program attribute could be any two values in the list above. So the metric produced could be:
The methods taught herein can also be applied to combinations of metrics. As non-limiting examples, those with normal skill in the art will see that Channel data can be combined with Demographic data and Program Attribute data to produce metrics such as:
We can see that once the device usage data has been loaded to the Data Structure and processed by the Analytics Engine 140, the foundation has been laid for developing a comprehensive data warehouse including the analytics taught herein along with others that readily fit within the spirit and scope of this embodiment. When loading the data to the Data Structure, it can be very detailed such as device usage for each second in the period of analysis, or highly summarized such as seconds of device usage for an entire market. Such analysis would allow the provider to compare statistics for parts of a market with those for the entire market.
The metrics readily lend themselves to dimensional analysis using contemporary data warehouse methods. A Fact table in such an application may be at the device detail level or an aggregation of many devices. A Dimension table of Time may be at the level of seconds, minutes, hour, day part, days, etc. A Dimension table of Demographics could include any of the demographics described herein. A Dimension table of Program Attribute could include any of the program attribute values described herein. A Dimension table of Device could identify details about the electronic device. A Dimension table of Usage may be used to describe the method in which the device is being used (email, phone call, web browser, etc.).
The metrics produced by the Analytics Engine 140 can be loaded to a data warehouse to support longitudinal analysis. Thus we can readily envision a myriad of uses for the metrics produced by the Analytics Engine 140.
Other Ramifications
We can see that once the device usage data has been loaded to the Data Structure and processed by the Analytics Engine 140, the foundation has been laid for detailed analytics to determine how many set-top boxes were tuned to each channel during any particular day part. By combining this data with data that identifies when a particular program or commercial was playing on a particular channel within a certain geographic area, one could determine the exact number of set-top boxes that were tuned-in when a commercial was aired. Another use of such data is to identify the popularity of a television program. Another use of such data is to determine the point at which viewers tuned away from an ad or television program. For example, one could identify the ability of a show to hold a viewing audience from beginning to end. This could be particularly useful in the case of a new pilot program before developing an entire series.
Other ramifications include the ability to measure commercial viewing based on demographics of the viewer.
Other ramifications include the ability to measure program viewing by program attributes and demographics combined.
Other ramifications include the ability to identify the time of day that is most optimal for airing various types of programs and/or advertisements.
Other ramifications include the ability to place set top boxes into Service Groups in support of Switched Digital Video capacity management.
Besides these ramifications, many additional uses of the data have been described in various parts of this specification.
Numerous other ramifications can be identified. These are simply non-limiting examples.
Electronic Device Comparison
A person with ordinary skill in the art will readily see the similarities between cable television capacity planning and cell phone capacity planning. The methods revealed herein can be readily applied to cellular telephone systems. This will be explained next.
A personal communication device includes any portable, battery-powered device typically capable of sending and receiving telephone calls, sending and receiving email, sending and receiving text messages, interacting with the world wide web, accessing the internet, downloading files, viewing streaming video, viewing internet protocol television, and similar functions. An example would be a cellular telephone.
A cellular telephone system contains many cell towers. The capacity of a cell tower is limited. In order to manage capacity, the cell phone company needs metrics on things such as:
Each of these metrics can be provided at a cell tower level or for an aggregation of cell towers. The unique identifier of a cell phone may include any of: Electronic Serial Number (ESN), Mobile Identification Number (MIN), System Identification Code (SIC).
Cell Tower generally equates to Service Group in the embodiment reviewed above. Radio Network Controller which facilitates communication between cell towers generally equates to Hub in the embodiment reviewed above.
ESN, MIN, SIC all generally equate to Set Top Box identifier in the embodiment reviewed above.
Call start time generally equates to tune-in-time.
Call end time generally equates to tune out time.
Radio Frequency/Channel generally equates to to Channel.
IP packet rate generally equates to megabits per second.
Thus we can see that there are numerous similarities between a cellular network and a cable television network. The methods taught herein could be applied to a cellular network.
Ramifications related to electronic device usage include things such as:
Numerous other ramifications will be apparent to those who work with this data.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5374951 | Welsh | Dec 1994 | A |
| 5790935 | Payton | Aug 1998 | A |
| 5872588 | Aras | Feb 1999 | A |
| 6286005 | Cannon | Sep 2001 | B1 |
| 6820277 | Eldering et al. | Nov 2004 | B1 |
| 7383243 | Conkwright et al. | Jun 2008 | B2 |
| 7490045 | Flores et al. | Feb 2009 | B1 |
| 7509663 | Maynard et al. | Mar 2009 | B2 |
| 7590993 | Hendricks et al. | Sep 2009 | B1 |
| 7614064 | Zigmond | Nov 2009 | B2 |
| 7729940 | Harvey | Jun 2010 | B2 |
| 7930391 | Holt | Apr 2011 | B1 |
| 8001561 | Gibbs | Aug 2011 | B2 |
| 8214867 | Hudspeth | Jul 2012 | B2 |
| 8280996 | Lu et al. | Oct 2012 | B2 |
| 8351645 | Srinivasan | Jan 2013 | B2 |
| 8352984 | Gogoi et al. | Jan 2013 | B2 |
| 8365212 | Orlowski | Jan 2013 | B1 |
| 8365213 | Orlowski | Jan 2013 | B1 |
| 8453173 | Anderson et al. | May 2013 | B1 |
| 8548991 | Zamir et al. | Oct 2013 | B1 |
| 8694396 | Craner et al. | Apr 2014 | B1 |
| 8739197 | Pecjak et al. | May 2014 | B1 |
| 8745647 | Shin et al. | Jun 2014 | B1 |
| 8924993 | Niebles Duque et al. | Dec 2014 | B1 |
| 8949873 | Bayer | Feb 2015 | B1 |
| 8959540 | Gargi et al. | Feb 2015 | B1 |
| 9277275 | Arini | Mar 2016 | B1 |
| 9794360 | Farhangi et al. | Oct 2017 | B1 |
| 9854292 | Matthews et al. | Dec 2017 | B1 |
| 9883233 | Barton | Jan 2018 | B1 |
| 10070177 | Gupta | Sep 2018 | B1 |
| 10779042 | Gupta et al. | Sep 2020 | B1 |
| 11240539 | Joshi et al. | Feb 2022 | B1 |
| 11265602 | Malhotra et al. | Mar 2022 | B2 |
| 20020055854 | Kurauchi et al. | May 2002 | A1 |
| 20020059576 | Feininger et al. | May 2002 | A1 |
| 20020062393 | Borger et al. | May 2002 | A1 |
| 20020083451 | Gill et al. | Jun 2002 | A1 |
| 20020104083 | Hendricks | Aug 2002 | A1 |
| 20020194196 | Weinberg et al. | Dec 2002 | A1 |
| 20030046696 | Mizuno et al. | Mar 2003 | A1 |
| 20030088715 | Chaudhuri et al. | May 2003 | A1 |
| 20030115585 | Barsness | Jun 2003 | A1 |
| 20030145323 | Hendricks | Jul 2003 | A1 |
| 20030172374 | Vinson | Sep 2003 | A1 |
| 20030174160 | Deutscher et al. | Sep 2003 | A1 |
| 20030237095 | Srinivas | Dec 2003 | A1 |
| 20040019899 | Pelletier | Jan 2004 | A1 |
| 20040215698 | Bertin | Oct 2004 | A1 |
| 20040268226 | McMullin | Dec 2004 | A1 |
| 20050086110 | Haley et al. | Apr 2005 | A1 |
| 20050229199 | Yabe | Oct 2005 | A1 |
| 20050235307 | Relan et al. | Oct 2005 | A1 |
| 20050286860 | Conklin | Dec 2005 | A1 |
| 20060015891 | Lazzaro et al. | Jan 2006 | A1 |
| 20060075420 | Ludvig et al. | Apr 2006 | A1 |
| 20060075421 | Roberts et al. | Apr 2006 | A1 |
| 20060168609 | Chen | Jul 2006 | A1 |
| 20060184961 | Lee et al. | Aug 2006 | A1 |
| 20060198302 | Sofman | Sep 2006 | A1 |
| 20060223495 | Cassett et al. | Oct 2006 | A1 |
| 20070067794 | Russell et al. | Mar 2007 | A1 |
| 20070074258 | Wood et al. | Mar 2007 | A1 |
| 20070092204 | Wagner et al. | Apr 2007 | A1 |
| 20070124756 | Covell | May 2007 | A1 |
| 20070157249 | Cordray et al. | Jul 2007 | A1 |
| 20070186228 | Ramaswamy et al. | Aug 2007 | A1 |
| 20070214483 | Bou-Abboud | Sep 2007 | A1 |
| 20070271300 | Ramaswamy | Nov 2007 | A1 |
| 20070283409 | Golden | Dec 2007 | A1 |
| 20070288950 | Downey et al. | Dec 2007 | A1 |
| 20080046912 | Gemelos | Feb 2008 | A1 |
| 20080077951 | Maggio | Mar 2008 | A1 |
| 20080127252 | Eldering et al. | May 2008 | A1 |
| 20080300965 | Doe | Dec 2008 | A1 |
| 20090007171 | Casey et al. | Jan 2009 | A1 |
| 20090052864 | Ohde | Feb 2009 | A1 |
| 20090070798 | Lee et al. | Mar 2009 | A1 |
| 20090077577 | Allegrezza | Mar 2009 | A1 |
| 20090077579 | Li et al. | Mar 2009 | A1 |
| 20090094630 | Brown | Apr 2009 | A1 |
| 20090133047 | Lee et al. | May 2009 | A1 |
| 20090150224 | Lu et al. | Jun 2009 | A1 |
| 20090150814 | Eyer et al. | Jun 2009 | A1 |
| 20090172725 | Heilbron et al. | Jul 2009 | A1 |
| 20090183210 | Andrade | Jul 2009 | A1 |
| 20090193460 | Barnett | Jul 2009 | A1 |
| 20090268905 | Matsushima et al. | Oct 2009 | A1 |
| 20090313232 | Tinsley | Dec 2009 | A1 |
| 20090327208 | Bittner et al. | Dec 2009 | A1 |
| 20100043021 | Torsiello et al. | Feb 2010 | A1 |
| 20100088716 | Ellanti et al. | Apr 2010 | A1 |
| 20100145791 | Canning | Jun 2010 | A1 |
| 20100161492 | Harvey | Jun 2010 | A1 |
| 20100211439 | Marci et al. | Aug 2010 | A1 |
| 20100235852 | Mears | Sep 2010 | A1 |
| 20100251302 | Chao | Sep 2010 | A1 |
| 20100262986 | Adimatyam et al. | Oct 2010 | A1 |
| 20100330954 | Manning Cassett et al. | Dec 2010 | A1 |
| 20110072448 | Stiers et al. | Mar 2011 | A1 |
| 20110110515 | Tidwell et al. | May 2011 | A1 |
| 20110126241 | Beattie, Jr. et al. | May 2011 | A1 |
| 20110145847 | Barve et al. | Jun 2011 | A1 |
| 20110289524 | Toner | Nov 2011 | A1 |
| 20110307913 | Wang et al. | Dec 2011 | A1 |
| 20110321077 | Wang et al. | Dec 2011 | A1 |
| 20120005527 | Engel et al. | Jan 2012 | A1 |
| 20120079518 | Wan et al. | Mar 2012 | A1 |
| 20120151511 | Bernard et al. | Jun 2012 | A1 |
| 20120191815 | Tabbal et al. | Jul 2012 | A1 |
| 20120222058 | el Kaliouby et al. | Aug 2012 | A1 |
| 20120240143 | Mathews | Sep 2012 | A1 |
| 20120260278 | Lambert et al. | Oct 2012 | A1 |
| 20120278161 | Lazzaro | Nov 2012 | A1 |
| 20120278828 | Yazdani et al. | Nov 2012 | A1 |
| 20120296909 | Cao et al. | Nov 2012 | A1 |
| 20120304210 | Zaslavsky et al. | Nov 2012 | A1 |
| 20120304211 | Berezowski et al. | Nov 2012 | A1 |
| 20130007789 | Wang et al. | Jan 2013 | A1 |
| 20130024901 | Sharif-Ahmadi et al. | Jan 2013 | A1 |
| 20130124309 | Traasdahl et al. | May 2013 | A1 |
| 20130145385 | Aghajanyan et al. | Jun 2013 | A1 |
| 20130198125 | Oliver et al. | Aug 2013 | A1 |
| 20130247081 | Vinson et al. | Sep 2013 | A1 |
| 20130283304 | Wan et al. | Oct 2013 | A1 |
| 20130346154 | Holz et al. | Dec 2013 | A1 |
| 20140075465 | Petrovic et al. | Mar 2014 | A1 |
| 20140109124 | Morales et al. | Apr 2014 | A1 |
| 20140123173 | Mak | May 2014 | A1 |
| 20140150005 | Kalmes et al. | May 2014 | A1 |
| 20140181019 | Bajaria et al. | Jun 2014 | A1 |
| 20140359649 | Cronk | Dec 2014 | A1 |
| 20150113153 | Lin | Apr 2015 | A1 |
| 20150128162 | Ionescu | May 2015 | A1 |
| 20160261655 | Aggarwal et al. | Sep 2016 | A1 |
| 20160314404 | Carmichael et al. | Oct 2016 | A1 |
| 20170289226 | Deshpande et al. | Oct 2017 | A1 |
| 20180007431 | Sidhu et al. | Jan 2018 | A1 |
| 20190378164 | Eich et al. | Dec 2019 | A1 |
| 20190379938 | Salo et al. | Dec 2019 | A1 |
| 20200296456 | Yungster | Sep 2020 | A1 |
| 20210058670 | Benamrouche | Feb 2021 | A1 |
| 20210158391 | Sheppard et al. | May 2021 | A1 |
| 20210240681 | Algranati et al. | Aug 2021 | A1 |
| 20220084052 | Sheppard et al. | Mar 2022 | A1 |
| 20220150581 | Sidhu et al. | May 2022 | A1 |
| 20220159326 | Sheppard et al. | May 2022 | A1 |
| 20220182722 | Bolivar et al. | Jun 2022 | A1 |
| 20220256219 | Saafi | Aug 2022 | A1 |
| 20220303618 | Whitely et al. | Sep 2022 | A1 |
| 20220383350 | Keshavan et al. | Dec 2022 | A1 |
| Number | Date | Country |
|---|---|---|
| 102236867 | Nov 2011 | CN |
| 1995878 | Nov 2008 | EP |
| 2012162693 | Nov 2012 | WO |
| 2013033123 | Mar 2013 | WO |
| Entry |
|---|
| Response to European Search Report—EP 141838276—Dated Sep. 10, 2015. |
| Response to European Search Report—EP Appl. 14182927.5—submitted Sep. 4, 2015. |
| Response to EP Search Report—EP 14186382.9—Dated Sep. 29, 2015. |
| EP Office Action—EP App 14182921.5—Mailed Mar. 31, 2016. |
| Motorola, Inc., Solutions Paper, “Implementing Switched Digital Video Solutions” http://www.motorola.com/staticfiles/Business/Products/_Documents/_Static%20files/SDV%20Implementation%20Solutions%20paper%20-555998-001-a.pdf?localeId=33, Copyright 2008, p. 6 File: Motorola-SDV_Implementation_Solutions_paper_-555998-001-a.pdf. |
| Strickland, Jonathan, “How Switched Digital Video Works”, Nov. 20, 2007. HowStuffWorks.com. <http://electronics.howstuffworks.com/switched-digital-video.htm>, pp. 1-4 File: HowSwitchedDigitalVideoWorks.pdf. |
| Rentrak Corporation, Television, TV Essentials, Web source: http://www.rentrak.com/section/media/tv/linear.html, Feb. 1, 2011, p. 1. |
| Wayne Friedman, Rentrak's ‘Stickiness’ Mines TV Value On Granular Level , MediaPost, Jan. 27, 2010, p. 1 of attached file Web source: http://www.tvb.org/media/file/TVB_Measurement_Rentraks_Stickiness_Mines_TV_Value_on_Granular_Level_1-27-10.pdf File: Rentraks_Stickiness_Mines_TV_Value_on_Granular_Level_1-27-10.pdf. |
| Rentrak Corporation, Reaching Your Target Audience Using Viewership Segments, Rentrak Case Studies http://rentrak.com/downloads/Viewership_Segment_Case_Study.pdf, Oct. 18, 2013, p. 1-2 C-1-Rentrak-Viewership_Segment_Case_Study.pdf www.rentrak.com. |
| Rentrak Corporation, Reaching Your Target Audience Using Commercial Ratings and Pod Analysis Rentrak Case Studies, http://www.rentrak.com/downloads/Commercial_and_Pod_Analysis_Case_Study.pdf Oct. 18, 2013, p. 1-2, C-2-Rentrak-Commercial_and_Pod_Analysis_Case_Study.pdf www.rentrak.com. |
| Rentrak Corporation, Rentrak Overview: Exact Commercial Ratings® http://www.rentrak.com/downloads/Exact_Commercial_Ratings_Presentation.pdf, Jan. 22, 2013, p. 1-30 File: C-Rentrak-Exact_Commercial_Ratings_Presentation.pdf www.rentrak.com. |
| Tim Brooks, Stu Gray, Jim Dennison, “The State Of Set-Top Box Viewing Data as of Dec. 2009”, STB Committee of the Council for Research Excellence. Research Report, Feb. 24, 2010, http://researchexcellence.com/stbstudy.php, pp. 1-9 File: A-STBCommitteeforResearchExcellenceSTBFINALREPORT_3_5_10.pdf. |
| FourthWall Media, Product information from web page, MassiveDataTM http://www.fourthwallmedia.tv, Oct. 18, 2013, p. 1 File: B-FourthWall-Media-MassiveData.pdf. |
| Cisco Systems, Inc., “Network Efficiency with Switched Digital”, Web page: http://www.cisco.com/en/US/products/ps9258/index.html, accessed Oct. 13, 2014, 2 pages. |
| Cisco Systems, Inc., “Access Viewership Data, Monitor Performance”, Web page: http://www.cisco.com/en/US/products/ps9122/index.html, accessed May 20, 2013, 1 page. |
| Extended European Search Report—EP 14183827.6—Mailing date: Oct. 23, 2014. |
| Extended European Search Report—EP 14182927.5—Mailing date: Dec. 16, 2014. |
| Welch T A: “A Technique for High-Performance Data Compression”, Computer. IEEE. US, vol. 17. No. 6. Jun. 1, 1984 (Jun. 1, 1984), XP000673349. |
| Extended European Search Report, EP Application 14186382.9, Dated Feb. 4, 2015. |
| Konstantin Shvachko et al.: “The Hadoop Distributed File System”, Mass Storage Systems and Technologies (MSST), 2010 IEEE 26th Symposium On, IEEE, Piscataway, NJ, USA, May 3, 2010 (May 3, 2010), pp. 1-10, XP031698650, ISBN: 978-1-4244-7152-2. |
| Anonymous: “Apache Hadoop”, Sep. 5 2013 (Sep. 5 2013), XP055394634, Retrieved from the Internet: URL: https://en.wikipedia.org/w/index.php?title=Apache_Hadoop&oldid=571641303 [retrieved on Jul. 28, 2017]. |
| Aug. 4, 2017—(EP) Office Action—App No. 14183827.6. |
| Mark Landler, Digital TV Converter Boxes to Expand Cable Offerings, 1996, The New York Times. |
| May 22, 2018—European Office Action—EP 14183827.6. |
| Mar. 22, 2019—EP Office Action—EP 14186382.9. |
| Jan. 12, 2021—Canadian Office Action—CA 2,860,802. |
| Jan. 13, 2021—Canadian Office Action—CA 2,861,861. |
| Nov. 10, 2020—CA Office Action—CA 2,864,621. |
| Nov. 6, 2020—EP Office Action—EP 14186382.9. |
| Jun. 23, 2021—Canadian Office Action—CA 2,864,621. |
| Jun. 22, 2021—European Office Action—EP 14186382.9. |
| Nov. 3, 2021—Canadian Office Action—CA 2,860,802. |
| Nov. 5, 2021—Canadian Office Action—CA 2,861,861. |
| Jan. 3, 2023—EP Office Action—EP App. No. 14186382.9. |
| Cisco Systems, Inc., “Channel Viewership Analyzer” Web page: http://www.cisco.com/en/US/prod/collateral/video/ps9119/ps9883/7016867.pdf pp. 1-2 File: CISCO-ChannelViewershipAnalyzer.pdf. |
| IneoQuest Technologies, Inc., “Switched Digital Video Solutions” http://www.ineoquest.com/switched-digital-video-solutions Dec. 28, 2010 pp. 1-2 File: IneoQuest-Switched-Digital-Video-Solutions.pdf. |
| Motorola, Inc. Solutions Paper “Implementing Switched Digital Video Solutions” http://www.motorola.com/staticfiles/Business/Products/_Documents/_Static%20files/SDV%20Implementation%20Solutions%20paper%20-555998-001-a.pdf?localeId=33 Copyright 2008. |
| Strickland, Jonathan, “How Switched Digital Video Works” Nov. 20, 2007. HowStuffWorks.com. <http://electronics.howstuffworks.com/switched-digital-video.htm> pp. 1-4. |
| Tim Brooks, STU Gray, Jim Dennison, “The State of Set-Top Box Viewing Data as of Dec. 2009” STB Committee of the Council for Research Excellence. Research Report Feb. 24, 2010. |
| Rentrak Corporation Television TV Essentials http://www.rentrak.com/section/media/tv/linear.html Feb. 1, 2011. |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12981301 | Dec 2010 | US |
| Child | 14608929 | US |
