Methods and apparatus for secondary content management and fraud prevention

Information

  • Patent Grant
  • 10586023
  • Patent Number
    10,586,023
  • Date Filed
    Thursday, April 21, 2016
    8 years ago
  • Date Issued
    Tuesday, March 10, 2020
    4 years ago
Abstract
Methods and apparatus for secondary content management, including preventing viewing fraud, are disclosed. In one embodiment, apparatus of the present disclosure includes an Advertisement Decisioning Service (ADS) and Manifest Manipulator (MM) configured cooperate to receive client requests for secondary content, select one or more secondary content elements (e.g., advertisements), and generate and transmit one or more identifiers that uniquely identify the client's request for a session. The selected advertisements in one implementation include embedded beacons or tags used to ensure accurate accounting with regards to the amount or quality of consumption of the advertisement by a user.
Description

A portion of the disclosure of this patent document contains material that 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 files or records, but otherwise reserves all copyright rights whatsoever.


BACKGROUND
1. Technological Field

The disclosure relates generally to the field of content delivery and management, and in one exemplary aspect, methods and apparatus for fraud prevention, such as e.g., preventing illegitimate advertisement view counts, and for ensuring accurate accounting with regards to the amount of an advertisement viewed or otherwise consumed by a client.


2. Description of Related Technology

In managed content distribution networks (such as e.g., cable television HFCu, or satellite networks), advertisements are usually interspersed within a given broadcasted or delivered program. In this manner, every user premises device (e.g., a subscriber's settop box or the like) in a local service area which is currently tuned to the same program channel will receive the same advertisements at approximately the same time and in the same order.


Advertisements or other “secondary content” (including, without limitation, promotions or “info-mercials”, commercials, telescoping information/advertisements, and short segments) that are ultimately viewed by subscribers or other content consumers in such networks can be controlled in several ways. Generally, two categories or subdivisions of these techniques exist: (i) national- or high-level insertion, and (ii) local- or low-level insertion.


Under national level insertion, national networks (such as NBC, ABC, etc.) are responsible for determining the advertisements or promotions that are resident in a given program or other primary content stream or discrete content element. The pre-configured stream is delivered to the network operator (e.g., MSO), and the MSO merely then delivers the stream (content and advertisements) to the relevant subscribers over their network.


Under local-level insertion, the MSO (and even broadcast affiliates) can insert locally-generated advertisements or commercials and other such segments into remotely distributed regional programs before they are delivered to the network subscribers.


Secondary content insertion may comprise a major source of revenue for Internet website operators (e.g., YouTube™), commercial television/content distributors, and for the network operator. For example, where the secondary content comprises advertisements, it may be a main source of income for national television broadcasters and their local over-the-air affiliates. Cable, satellite, and other content distribution networks, as well as Internet content providers, also derive income from the sale of advertising time.


In order for an advertiser to maximize the return on their advertising investment, advertisers, promoters or other entities need to be assured that the secondary content for which they are paying to have displayed are actually being consumed by a client device at the direction of a human who is viewing the secondary content and associated primary or program content. An advertisement accounting service (also referred to as an Advertisement Decisioning Service (ADS) in some contexts) is used within content distribution network infrastructure to determine which individual ones of the secondary (or other) content will be placed in each of the advertisement placement opportunities prior to the delivery of content to the client device. The ADS may include, for example, an ad server or the like. In addition, the ADS is used to keep track of other data, such as e.g., the number of times an individual one of the secondary content is requested by the client device. Somewhat analogous to an Internet advertisement “click through”, this information is used to invoice the advertiser who pays the advertisement distributor based upon the number of advertisements served. However, most of the methods of displaying secondary content are susceptible to computer-automated programs (e.g., “bots”) created by malicious agents. Theses computer-automated programs “spoof” or trick the ADS by communicating data or messaging to the ADS that an advertisement is being requested, when in fact there are no legitimate viewers consuming the advertising. This scenario constitutes one type of “advertisement viewing fraud.” Extant advertising management systems such as the aforementioned ADS do not actually verify that the request for the advertisement is in fact legitimate, but rather merely log such requests and presume that delivery actually occurs, and such delivery is to a legitimate consumer. For example, a typical prior art management system receives a request from a client (e.g., subscriber device) for a manifest file, which contains information such as URLs (universal resource locators) for primary and secondary content elements (e.g., video content and advertisements, respectively). The manifest file request is directed to an entity which coordinates obtaining information about the advertisements that should be inserted into the video stream via the manifest file. The manifest file is then assembled, including a first “accounting” URL for each unique request, and delivered to the requesting client. The client then uses the manifest file to obtain the manifested primary (e.g., video/audio) content. When an advertising break occurs within the primary content, a first advertising-related URL is utilized to notify a network entity that an advertisement is about to be delivered, and presumably viewed by the video rendering client. The video client then requests the video chunks representing the advertisement from the network using the manifest file URLs pertaining to the advertisement.


Unfortunately, a rogue client or surreptitious “bot” can merely perform the aforementioned notification of the network entity one or more times to artificially “trick” the network entity/management system into believing that advertisements are being requested by a valid video client (and presumably being viewed by a human). There is no mechanism to ensure that a requesting “client” requests the entertainment video chunks, or requests all of the video chunks containing the advertisements.


Typically, a principal motivation of the malicious agent in advertisement viewing fraud scenarios is to undermine confidence in the integrity and accounting practices of the distributor, who is paid to distribute the secondary content and associated primary content. This is somewhat similar to “click fraud” scenarios, whereby a “click bot” imitates a legitimate user of a web browser clicking on an ad, thereby generating a charge-per-click without having actual interest in the target of the advertisement's link. However, in click fraud scenarios, the malicious agent is typically a competitor who seeks to beat down the advertiser's website and advertising account. Under any scenario, such malicious activity is highly detrimental and undesirable.


In a related aspect, advertisers (and other content managers or distributers) desire to maintain an accurate accounting of secondary content consumption; e.g., in terms of how much of a given requested secondary content asset was “consumed” by a valid consumer (e.g., web site or network user or subscriber, part of target audience, etc.). For example, it is often very telling to an advertiser to know how much of the total runtime of a video and/or audio advertisement was actually rendered for viewing/listening by the consumer; advertisements which (statistically) are only viewed by the target audience for a few seconds before a tune-away or other terminating event occurs may be presumed to be of little interest to that target audience. Existing methods and apparatus for obtaining such data are at best marginally effective, in that they are modeled for prefatory or introductory advertisements for short clips (i.e., at beginning or end of a video segment only), and are generally “binary” in nature (i.e., completed or not completed).


For example, in both managed and unmanaged networks, Internet Protocol (IP) content is typically delivered with embedded secondary content links or elements. For instance, exemplary YouTube™ or similar packetized audio-visual media frequently include an embedded or prefatory advertisement, such as a fifteen-second clip for a product or service. In many cases, the requesting viewer can opt-out of the advertisement (and proceed directly to the requested content element) after a period of time, or by clicking on a graphical control element rendered on the screen (e., a “close window” or “x” box rendered within the viewing window of the content). However, one can only infer so much behavioral motivation or obtain so much useful insight from data indicating only completion, early termination, etc.


Hence, a reliable mechanism for determining “how much” (whether measured temporally, or in terms of other consumption attributes or parameters) of a given advertisement is consumed by a valid user is also needed.


Based on the foregoing, both (i) apparatus and methods for preventing viewership fraud with regards to the distribution of primary content having secondary content inserted therein to a one or more users, and (ii) apparatus and methods for accurately determining a degree or quality of audience consumption of such secondary content, are needed. Ideally, these apparatus and methods would, inter alia, prevent the relevant network infrastructure (e.g., ADS) from counting requests for secondary content unless the secondary content is actually requested by a client, including e.g., a client that is also requesting primary content. Such apparatus and methods would, in addition, also ideally ensure accurate accounting of the consumption of an advertisement or other secondary content element by one or more users.


SUMMARY OF THE DISCLOSURE

The present disclosure provides, inter alia, apparatus and methods for secondary content management and fraud prevention.


In a first aspect, a method of delivering Internet Protocol (IP) packetized media content and advertising content is disclosed. In one embodiment, the delivery is to an IP-enabled client device of a subscriber within a managed content delivery network, and the method includes: authenticating at least one of the subscriber and/or client device to access content via the managed content delivery network; receiving a first communication from the client device for delivery of the IP packetized media content; causing generation of a unique session identifier relating to the first communication; transmitting a manifest file containing the unique session identifier, first information relating to a plurality of media elements, and second information relating to at least one advertising element, to the client device; receiving from the client device another communication, the another communication comprising at least a portion of the second information and the unique session identifier; validating the another communication based at least on the unique session identifier contained therein; causing counting of the validated another communication as a valid advertising request; and causing provision of the at least one advertising element to the client device via an IP transport.


In one variant, the method further includes: receiving a communication containing the unique session identifier and at least a portion of the first information; and causing delivery of at least a portion of the plurality of media elements to the client device via an IP transport.


In one implementation, the receiving the communication containing the unique session identifier and at least a portion of the first information, and the causing delivery of at least a portion of the plurality of media elements to the client device via an IP transport, each occur before the receipt of the another communication; and the receipt of the communication containing the unique session identifier and at least a portion of the first information is a condition precedent for the validating of the another communication.


In another aspect, a method for validating a secondary content request received in a content distribution network is disclosed. In one embodiment, the method includes: receiving a request for provision of secondary content at a secondary content management entity of the content distribution network; examining the request to identify a shared data element present within the request; utilizing information present within the shared data element to validate the secondary content request; and forwarding information to a accounting process enabling the accounting process to count the secondary content request as a valid request.


In one variant, the shared data element comprises an at least periodically unique identifier issued by an entity of the network and transmitted to a valid client of the network for use in a secondary content request, such as e.g., a globally unique identifier (GUID) useful only within the content distribution network.


In another variant, the shared data element comprises a data value previously provided to a particular client device of the content distribution network, the data value having a finite temporal period of validity, and the utilizing the information present in the shared data element to validate the request comprises determining that the request for secondary content including the data value was received by the secondary content management entity within the finite temporal period of validity.


In a further variant, the shared data element comprises a cryptographic hash of a value, the value previously provided to a client of the content distribution network by an entity of the content distribution network; and the utilizing the information present in the shared data element to validate the request comprises: (i) retrieving a copy of the value from local storage within the content distribution network; (ii) utilizing a cryptographic hash algorithm common to both the secondary content management entity and the client, to hash the retrieved copy of the value to generate a local hash; and (iii) comparing the local hash to the cryptographic hash to identify any differences there between.


In another embodiment of the method, the method includes: receiving a first communication from the client device for delivery of the IP packetized media content; causing generation of a unique session identifier relating to the first communication; transmitting a manifest file comprising the unique session identifier, first information relating to a plurality of advertising content elements, and second information relating to the media content, to the client device, the plurality of advertising content elements collectively comprising a complete advertisement; receiving from the client device another communication, the another communication comprising at least: (i) a first portion of the first information, the first portion of the first information relating to a first of the plurality of advertising content elements, and (ii) the unique session identifier; validating the another communication based at least on the unique session identifier contained therein; causing provision of the first of the plurality of advertising content elements to the client device via an IP transport; and receiving from the client device a subsequent communication, the subsequent communication comprising: (i) a second portion of the first information, the second portion of the first information relating to a second of the plurality of advertising content elements, (ii) the unique session identifier, and (iii) a consumption-related value.


In one variant, the consumption-related value is indicative of at least one of a quality or amount of a then-current consumption of the advertisement by the client device.


In another variant, the consumption-related value comprises a value related to an ID3 tag embedded in the second of the plurality of advertising content elements.


In another variant, the consumption-related value comprises a value related to a metadata element embedded in a stream of the second of the plurality of advertising content elements.


In another variant, the another communication further comprises a consumption-related value.


In another aspect of the disclosure, a network apparatus of a content distribution network is provided. In one embodiment, the network apparatus is configured for validating an advertising content request, the advertising content request associated with delivery of packetized media content via an IP (Internet Protocol) transport, and includes: processing apparatus; network interface apparatus in data communication with the processing apparatus and configured to conduct data communications with a plurality of client devices via at least the content distribution network; and storage apparatus in data communication with the processing apparatus and comprising computerized logic executable on the processing apparatus.


In one variant, the computerized logic is configured to, when executed: cause generation of a shared data element for provision to a particular client device; transmit at least the shared data element to the particular client device via the network interface apparatus and the content distribution network; receive a request for provision of advertising content from the particular client device, the request including the shared data element; extract the shared data element present within the request; and utilize at least a portion of the shared data element to validate the advertising content request.


In another variant, the shared data element comprises an identifier which is globally unique at least within the content distribution network for at least a prescribed period of time; the transmission of the shared data element to the particular client device comprises a transmission of a host data structure of which the shared data element is part, the host data structure further comprising data indicating one or more network locations where the packetized media content may be obtained by the particular client device; and the request specifies a universal resource locator (URL) present within the host data structure from which at least a portion of the advertising content can be obtained. The host data structure comprises for example a manifest file comprising (i) one or more URLs corresponding to the one or more locations where the packetized media content may be obtained; and (ii) the URL.


In another variant, the computerized logic is further configured to, when executed, verify that at least a portion of the packetized media content has been previously requested by the particular client device as part of a common session. The common session is identified within the shared data element.


In yet a further variant, the causation of the generation of the shared data element for provision to a particular client device is pursuant to receipt by the network apparatus of a prior request issued by the particular client device to obtain a manifest file relating to the packetized media content.


In a further aspect, a method of delivering Internet Protocol (IP) packetized advertising content to an IP-enabled client device of a user within a content distribution network is disclosed. In one embodiment, the method includes: obtaining a unique identifier; transmitting a data structure comprising at least the unique identifier, and first information relating to a plurality of advertising content elements, to the client device, the plurality of advertising content elements each comprising a portion of a complete advertisement; receiving from the client device a communication, the communication comprising at least: (i) a first portion of the first information, the first portion of the first information relating to a first of the plurality of advertising content elements, and (ii) the unique identifier or a derivative thereof; validating the communication based at least on the unique identifier or derivative of contained therein; causing provision of the first of the plurality of advertising content elements to the client device via an IP transport; and receiving from the client device a subsequent communication, the subsequent communication comprising: (i) a second portion of the first information, the second portion of the first information relating to a second of the plurality of advertising content elements, (ii) the unique identifier or the derivative thereof, and (iii) consumption-related data.


In one variant, the consumption-related data is indicative of at least one of an amount of a then-current consumption of the advertisement by the client device.


In yet another aspect of the disclosure, an IP-enabled client device is provided. In one embodiment, the client device comprises a software component (e.g., middleware or application) configured to receive manifest files with unique identifiers, and issue content requests including one or more of the unique identifiers or derivations thereof.


In yet a further aspect, a method of determining the consumption of a secondary content element is disclosed. In one embodiment, beacons or tags are included within at least portions of an address associated with multi-part secondary content element. Upon transmission of the address by a rendering client, the beacon or tag is extracted from the address, and used to determine how much (e.g., percentage) of the secondary content element has been rendered. In another embodiment, the beacon or tag is embedded within the secondary content element itself, and is extracted upon decode, and sent to the serving device as part of a subsequent communication, so as to assure that decode of the segment has actually occurred, and to indicate progress of the rendering process.


In still another aspect, a method of mitigating or preventing advertising fraud on a content distribution network is disclosed. In one embodiment, the method includes inserting a unique identifier in one or more of a plurality of content segment addresses, such that a requesting client must present the unique identifier (e.g., within a prescribed period of time in one variant) to the serving or managing delivery device before the request is acted upon. In another embodiment, the identifier is embedded within one or more of the content elements (“chunks”) themselves, such that the client must decode the content element(s) to obtain the identifier and retrieve the next content element chunk from the network.


These and other aspects of the disclosure shall become apparent when considered in light of the disclosure provided herein.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a functional block diagram illustrating an exemplary hybrid fiber coax (HFC) cable network configuration useful with various aspects of the present disclosure.



FIG. 1a is a functional block diagram illustrating one exemplary HFC cable network headend configuration useful with various aspects of the present disclosure.



FIG. 1b is a functional block diagram illustrating one exemplary embodiment of a local service node configuration useful with various aspects of the present disclosure.



FIG. 1c is a functional block diagram illustrating one exemplary embodiment of a broadcast switched architecture (BSA) useful with various aspects of the present disclosure.



FIG. 1d is a functional block diagram illustrating one exemplary embodiment of a packetized content delivery network architecture useful with the present disclosure.



FIG. 1e is a functional block diagram illustrating a second exemplary packetized content delivery network architecture useful with various aspects of the present disclosure.



FIG. 2 is a functional block diagram of an exemplary secondary content management architecture, in accordance with various aspects of the present disclosure.



FIG. 3 is a logical flow diagram illustrating one embodiment of a method for preventing secondary content (e.g., advertisement) fraud in a content distribution network.



FIG. 3a is a logical flow diagram illustrating another embodiment of a method for preventing secondary content (e.g., advertisement) fraud in a content distribution network.



FIG. 4 is a logical flow diagram illustrating one embodiment of a method for managing secondary content consumption in a content distribution network.



FIG. 4a is a logical flow diagram illustrating another embodiment of a method for managing secondary content consumption in a content distribution network.



FIG. 4b is a logical flow diagram illustrating yet another embodiment of a method for managing secondary content consumption in a content distribution network.



FIG. 5 is a logical process diagram illustrating an exemplary implementation of the operation of the architecture of FIG. 2, including both advertising fraud prevention and advertising consumption management functions thereof.





All Figures © Copyright 2015 Time Warner Cable Enterprises, Inc. All rights reserved.


DETAILED DESCRIPTION

Reference is now made to the drawings wherein like numerals refer to like parts throughout.


As used herein, the term “advertisement” and similar forms refers without limitation to any audio, visual, or promotion, message, or communication, whether for-profit or otherwise, that is perceptible by a human. Examples of advertisements include so-called “bumper” advertisements (advertisements inserted before or after a client requested program), “pause” advertisements (presented when a client sends a pause control command to a video server or the like), or additional and replacement advertisements.


As used herein, the term “application” refers generally and without limitation to a unit of executable software that implements a certain functionality or theme. The themes of applications vary broadly across any number of disciplines and functions (such as on-demand content management, Internet browsers, e-commerce transactions, brokerage transactions, home entertainment, calculator etc.), and one application may have more than one theme. The unit of executable software generally runs in a predetermined environment; for example, the unit could comprise a downloadable Java Xlet™ that runs within the JavaTV™ environment.


As used herein the term “browser” refers to any computer program, application or module which provides network access capability including, without limitation, Internet browsers adapted for accessing one or more websites or URLs over the Internet, as well as any “user agent” including those adapted for visual, aural, or tactile communications.


As used herein, the terms “client device” and “end user device” include, but are not limited to, set-top boxes (e.g., DSTBs), “smart” televisions, gateways, modems, personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise, and mobile devices such as handheld computers, PDAs, personal media devices (PMIDs), tablets, and smartphones.


As used herein, the term “codec” refers to an video, audio, or other data coding and/or decoding algorithm, process or apparatus including, without limitation, those of the MPEG (e.g., MPEG-1, MPEG-2, MPEG-4, etc.), Real (Real Video, etc.), AC-3 (audio), DiVX, XViD/ViDX, Windows Media Video (e.g., WMV 7, 8, 9, 10), ATI Video codec, or VC-1 (SMPTE standard 421M) families.


As used herein, the term “computer program” or “software” is meant to include any sequence or human or machine cognizable steps which perform a function. Such program may be rendered in virtually any programming language or environment including, for example, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., H™ L, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ (including J2ME, Java Beans, etc.), Binary Runtime Environment (e.g., BREW), and the like.


As used herein, the term “conditional access” refers to any access control scheme, whether implemented in hardware, software, or firmware (or combinations thereof), including without limitation members of the “Powerkey” family (Powerkey Book 2, Powerkey Book 3, etc.), NDS (including VideoGuard, mVideoGuard, etc.), ANSI/SCTE Standard 52 2003 (DVS-042), incorporated herein by reference in its entirety, and Motorola/General Instrument DigiCipher® family (DigiCipher II, etc.). These can be implemented using, for example, the so-called “CableCard” plug-in security module access technology, a downloadable CA system (DCAS), or otherwise.


The terms “Consumer Premises Equipment (CPE)” and “host device” refer without limitation to any type of electronic equipment located within a consumer's or user's premises and connected to or in communication with a network, and may include client devices or end-user devices. The term “host device” includes terminal devices that have access to digital television content via a satellite, cable, wireless or terrestrial network. The host device functionality may be integrated into a digital television (DTV) set.


As used herein, the term “display” means any type of device adapted to display information, including without limitation CRTs, LCDs, TFTs, plasma displays, LEDs, incandescent and fluorescent devices. Display devices may also include less dynamic devices such as, for example, printers, e-ink devices, and the like.


As used herein, the term “DOCSIS” refers to any of the existing or planned variants of the Data Over Cable Services Interface Specification, including for example DOCSIS versions 1.0, 1.1, 2.0 and 3.0.


As used herein, the term “headend” refers generally to a networked system controlled by an operator (e.g., an MSO or multiple systems operator) that distributes programming to MSO clientele using client devices. Such programming may include literally any information source/receiver including, inter alia, free-to-air TV channels, pay TV channels, interactive TV, and the Internet.


As used herein, the terms “Internet” and “internet” are used interchangeably to refer to inter-networks including, without limitation, the Internet.


As used herein, the term “mass storage” includes any type of integrated circuit or other storage device adapted for storing digital data including, without limitation, ROM. PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), and PSRAM.


As used herein, the terms “microprocessor” and “digital processor” are meant generally to include all types of digital processing devices including, without limitation, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurable computer fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components.


As used herein, the term “modem” refers to any kind of modulation or demodulation process or apparatus including without limitation cable (e.g., DOCSIS compliant) modems, DSL modems, analog modems, and so forth.


As used herein, the terms “MSO” or “multiple systems operator” refer without limitation to a cable, fiber to the home (FTTH), fiber to the curb (FTTC), satellite, Hybrid Fiber Copper (HFCu), or terrestrial network provider having infrastructure required to deliver services including programming and data over those mediums.


As used herein, the terms “network” and “bearer network” refer generally to any type of telecommunications or data network including, without limitation, hybrid fiber coax (HFC) networks, HFCu networks, satellite networks, telco networks, and data networks (including MANs, WANs, LANs, WLANs, internets, and intranets). Such networks or portions thereof may utilize any one or more different topologies (e.g., ring, bus, star, loop, etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeter wave, optical, etc.) and/or communications or networking protocols.


As used herein, the term “network interface” refers to any signal, data, or software interface with a component, network or process including, without limitation, those of the FireWire (e.g., FW400, FW800, etc.), USB (e.g., USB2), Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E, etc.), MoCA, Coaxsys (e.g., TVnet™), radio frequency tuner (e.g., in-band or OOB, cable modem, etc.), Wi-Fi (802.11), WiMAX (802.16), PAN (e.g., 802.15), or IrDA families.


As used herein, the term “node” refers to any functional entity associated with a network, such as for example: CPE, edge device, server, gateway, router, Optical Line Terminal (OLT), Optical Network Unit (ONU), etc. whether physically discrete or distributed across multiple locations.


As used herein, the term “server” refers to any computerized component, system or entity regardless of form which is adapted to provide data, files, applications, content, or other services to one or more other devices or entities on a computer network.


As used herein, the term “user interface” refers to, without limitation, any visual, graphical, tactile, audible, sensory, or other means of providing information to and/or receiving information from a user or other entity. A user interface may comprise, for example, a computer screen display, touch screen, speech recognition engine, text-to-speech (TTS) algorithm, and so forth.


As used herein, the term “Wi-Fi” refers to, without limitation, any of the variants of IEEE-Std. 802.11 or related standards including e.g., 802.11 a/b/g/n/v/ac.


As used herein, the term “wireless” means any wireless signal, data, communication, or other interface including without limitation Wi-Fi, Bluetooth, 3G (3GPP/3GPP2), HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A, WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20, narrowband/FDMA, OFDM, PC S/DCS, LTE/LTE-A, analog cellular, CDPD, satellite systems, mesh networks, millimeter wave or microwave systems, acoustic, and infrared (i.e., IrDA).


Overview


In one exemplary aspect, the present disclosure provides apparatus and methods for preventing or mitigating surreptitious activities such as advertising fraud. In one embodiment described herein, a managed content distribution network (e.g., cable television network) is configured to prevent extant video advertising accounting systems from “counting” requests for advertisements or other secondary content elements unless the advertisement/content element is truly requested by a valid video client (e.g., end user or subscriber device). In one implementation, this is accomplished using a session-specific data which is embedded within e.g., the manifest file delivered to the client. The session-specific data is then transmitted by the requesting client along with its request for advertisement or other assets to the relevant network entity, and the network entity evaluates the transmitted session-specific data to determine whether it meets certain validation criteria before marking the request as “valid” and enabling it to be counted.


Moreover, in another embodiment, the network is configured to further determine that the ostensibly valid requesting client is also validly requesting video assets or other primary content along with the advertisement(s), thereby providing further assurance of the authenticity of the advertisement request.


Using the foregoing techniques, malicious agents such as “bots” are frustrated from tricking the relevant network infrastructure into counting advertisements that are never actually consumed.


In another exemplary aspect, the present disclosure provides apparatus and methods of measuring actual consumption of secondary content (such as advertisements) by valid content consumers. In one embodiment, “beacons” or other such data are introduced into the video advertisement or other secondary content element that can be used to determine, for instance, how much of the advertisement has been delivered. In one implementation, the video player client uses the advertisement accounting URL delivered in the manifest and associated with the advertisement to send the relevant network entity (e.g., ADS) one or more message with information relating to one or more consumption attributes (e.g., for each portion successfully rendered), along with the session-specific data associated with the rendering session.


DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments of the apparatus and methods of the present disclosure are now described in detail. While these exemplary embodiments are described primarily in the context of mentioned managed hybrid fiber coax (HFC) cable architecture having a multiple systems operator (MSO), digital networking capability, IP delivery capability (including e.g., IP-packetized delivery via CMTS/DOCSIS, and/or so called “in band” delivery of IP content such as via an MPEG transport stream carrying IP-packetized content), and a plurality of client devices/CPE, the general principles and advantages of the disclosure may be extended to other types of networks and architectures that are configured to deliver digital media data (e.g., text, video, and/or audio, discrete content elements such as files, executables, etc.). Such other networks or architectures may be broadband, narrowband, wired or wireless, managed or unmanaged, hybridized between two or more topologies or delivery modalities, or otherwise.


It will also be appreciated that while described generally in the context of a network providing service to a customer or consumer (i.e., residential) end user domain, the present disclosure may be readily adapted to other types of environments including, e.g., commercial/enterprise, and government/military applications. Myriad other applications are possible.


Also, while certain aspects are described primarily in the context of the well-known Internet Protocol (described in, inter alia, Internet Protocol DARPA Internet Program Protocol Specification, IETF RCF 791 (September 1981) and Deering, et al., Internet Protocol, Version 6 (IPv6) Specification, IETF RFC 2460 (December 1998) each of which is incorporated herein by reference in its entirety), it will be appreciated that the present disclosure may utilize other types of protocols (and in fact bearer networks to include other internets and intranets) to implement the described functionality.


Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.


Bearer Network



FIG. 1 illustrates a typical managed content delivery network configuration. The various components of the network 100 include (i) one or more data and application origination points 102; (ii) one or more content sources 103, (iii) one or more application distribution servers 104; (iv) one or more Video-On-Demand (VOD) servers 105, and (v) customer premises equipment (CPE) 106. The distribution server(s) 104, VOD servers 105 and CPE(s) 106 are connected via a bearer (e.g., HFC) network 101. A simple architecture comprising one of each of the aforementioned components 102, 104, 105, 106 is shown in FIG. 1 for simplicity, although it will be recognized that comparable architectures with multiple origination points, distribution servers, VOD servers, and/or CPE devices (as well as different network topologies) may be utilized consistent with the present disclosure. For example, the headend architecture of FIG. 1a (described in greater detail below), or others, may be used.


The data/application origination point 102 comprises any medium that allows data and/or applications (such as a VOD-based or “Watch TV” application) to be transferred to a distribution server 104. This may include for example a third party data source, application vendor website, CD-ROM, external network interface, mass storage device (e.g., RAID system), etc. Such transference may be automatic, initiated upon the occurrence of one or more specified events (such as the receipt of a request packet or ACK), performed manually, or accomplished in any number of other modes readily recognized by those of ordinary skill. The application distribution server 104 comprises a computer system where such applications enter the network system. Distribution servers are well known in the networking arts, and accordingly not described further herein.


The VOD server 105 comprises a computer system where on-demand content is received from one or more of the aforementioned data sources 102 and enter the network system. These servers may generate the content locally, or alternatively act as a gateway or intermediary from a distant source.


The VOD server 105 and application distribution servers 104 are a part of the headend architecture of the network 100. The headend 150 is connected to an internetwork (e.g., the Internet) 111.


Referring now to FIG. 1a, one exemplary embodiment of a headend architecture is described. As shown in FIG. 1a, the headend architecture 150 comprises typical headend components and services including billing module 152, subscriber management system (SMS) and CPE configuration management module 154, cable-modem termination system (CMTS) and OOB system 156, as well as LAN(s) 158, 160 placing the various components in data communication with one another. It will be appreciated that while a bar or bus LAN topology is illustrated, any number of other arrangements as previously referenced (e.g., ring, star, etc.) may be used consistent with the disclosure. It will also be appreciated that the headend configuration depicted in FIG. 1a is high-level, conceptual architecture, and that each MSO may have multiple headends deployed using custom architectures.


The exemplary architecture 150 of FIG. 1a further includes a conditional access system (CAS) 157 and a multiplexer-encrypter-modulator (MEM) 162 coupled to the HFC network 101 adapted to process or condition content for transmission over the network. The distribution servers 164 are coupled to the LAN 160, which provides access to the MEM 162 and network 101 via one or more file servers 170. The VOD servers 105 are coupled to the LAN 160 as well, although other architectures may be employed (such as for example where the VOD servers are associated with a core switching device such as an 802.3z Gigabit Ethernet device). As previously described, information is carried across multiple channels. Thus, the headend must be adapted to acquire the information for the carried channels from various sources. Typically, the channels being delivered from the headend 150 to the CPE 106 (“downstream”) are multiplexed together in the headend, as previously described and sent to neighborhood hubs (FIG. 1b) via a variety of interposed network components.


Content (e.g., audio, video, data, files, etc.) is provided in each downstream (in-band) channel associated with the relevant service group. To communicate with the headend or intermediary node (e.g., hub server), the CPE 106 may use the out-of-band (OOB) or DOCSIS channels and associated protocols. The OCAP 1.0, 2.0, 3.0 (and subsequent) specification provides for exemplary networking protocols both downstream and upstream, although the present disclosure is in no way limited to these approaches.


“Switched” Networks



FIG. 1c illustrates an exemplary “switched” network architecture. Switching architectures allow improved efficiency of bandwidth use for ordinary digital broadcast programs. Ideally, the subscriber is unaware of any difference between programs delivered using a switched network and ordinary streaming broadcast delivery.



FIG. 1c shows the implementation details of one exemplary embodiment of this broadcast switched network architecture. Specifically, the headend 150 contains switched broadcast control 190 and media path functions 192; these element cooperating to control and feed, respectively, downstream or edge switching devices 194 at the hub site which are used to selectively switch broadcast streams to various service groups. BSA media path 192 may include a staging processor 195, source programs, and bulk encryption in communication with a switch 275. A BSA server 196 is also disposed at the hub site, and implements functions related to switching and bandwidth conservation (in conjunction with a management entity 198 disposed at the headend). An optical transport ring 197 is utilized to distribute the dense wave-division multiplexed (DWDM) optical signals to each hub in an efficient fashion.


In addition to “broadcast” content (e.g., video programming), the systems of FIGS. 1a and 1c (and 1d discussed below) also deliver Internet data or video services using the Internet protocol (IP), although other protocols and transport mechanisms of the type well known in the digital communication art may be substituted. One exemplary delivery paradigm comprises delivering MPEG-based video content, with the video transported to user PCs (or IP-based STBs) over the aforementioned DOCSIS channels comprising MPEG (or other video codec such as H.264 or AVC) over IP over MPEG. That is, the higher layer MPEG- or other encoded content is encapsulated using an IP protocol, which then utilizes an MPEG packetization of the type well known in the art for delivery over the RF channels. In this fashion, a parallel delivery mode to the normal broadcast delivery exists; i.e., delivery of video content both over traditional downstream QAMs to the tuner of the user's STB or other receiver device for viewing on the television, and also as packetized IP data over the DOCSIS QAMs to the user's PC or other IP-enabled device via the user's cable modem. Delivery in such packetized modes may be unicast, multicast, or broadcast.


Referring again to FIG. 1c, the IP packets associated with Internet services are received by edge switch 194, and in one embodiment forwarded to the cable modem termination system (CMTS) 199. The CMTS examines the packets, and forwards packets intended for the local network to the edge switch 194. Other packets are discarded or routed to another component. The edge switch 194 forwards the packets receive from the CMTS 199 to the QAM modulator 189, which transmits the packets on one or more physical (QAM-modulated RF) channels to the CPE. The IP packets are typically transmitted on RF channels (e.g., DOCSIS QAMs) that are different that the RF channels used for the broadcast video and audio programming, although this is not a requirement. The CPE 106 are each configured to monitor the particular assigned RF channel (such as via a port or socket ID/address, or other such mechanism) for IP packets intended for the subscriber premises/address that they serve.


“Packet-Optimized Networks”


While the foregoing network architectures described herein can (and in fact do) carry packetized content (e.g., IP over MPEG for high-speed data or Internet TV, MPEG2 packet content over QAM for MPTS, etc.), they are often not optimized for such delivery. Hence, in accordance with another embodiment of the disclosure, a “packet optimized” delivery network is used for carriage of the packet content (e.g., IPTV content). FIG. 1d illustrates one exemplary implementation of such a network, in the context of a 3GPP IMS (IP Multimedia Subsystem) network with common control plane and service delivery platform (SDP), as described in co-owned U.S. Provisional Patent Application Ser. No. 61/256,903 filed Oct. 30, 2009 and entitled “METHODS AND APPARATUS FOR PACKETIZED CONTENT DELIVERY OVER A CONTENT DELIVERY NETWORK”, which is now published as U.S. Patent Application Publication No. 2011/0103374 of the same title filed on Apr. 21, 2010, each of which is incorporated herein by reference in its entirety. Such a network provides, inter alia, significant enhancements in terms of common control of different services, implementation and management of content delivery sessions according to unicast or multicast models, etc.; however, it is appreciated that the various features of the present disclosure are in no way limited to this or any of the other foregoing architectures.



FIG. 1e shows another exemplary network architecture optimized for the delivery of packetized content disclosure useful with the present disclosure. In addition to on-demand and broadcast content (e.g., video programming), the system of FIG. 1e may deliver Internet data services using the e.g., Internet protocol (IP).


The network 1000 generally comprises a local headend 1001 in communication with at least one hub 1003 via an optical ring 1007. The distribution hub 1003 is able to provide content to various user devices, CPE 1022, and gateway devices 1020, via a network 1005.


Various content sources 1002 are used to provide content to a content server 1004. For example, content may be received from a local, regional, or network content library as discussed in co-owned U.S. application Ser. No. 12/841,906 filed on Jul. 22, 2010 entitled “APPARATUS AND METHODS FOR PACKETIZED CONTENT DELIVERY OVER A BANDWIDTH-EFFICIENT NETWORK”, and issued as U.S. Pat. No. 8,997,136 on Mar. 31, 2015, which is incorporated herein by reference in its entirety. Alternatively, content may be received from linear analog or digital feeds, as well as third party content sources. Internet content sources 1010 (such as e.g., a web server) provide Internet content to a packetized content server 1006. Other IP content may also be received at the packetized content server 1006, such as voice over IP (VoIP) and/or IPTV content. Content may also be received from subscriber and non-subscriber devices (e.g., a PC or smartphone-originated user made video). In one embodiment, the functionality of both the content server 1004 and packetized content server 1006 may be integrated into a single server entity.


A central media server located in the headend 1001 may be used as an installed backup to the hub media servers as (i) the primary source for lower demand services, and (ii) as the source of the real time, centrally encoded programs with PVR (personal video recorder) capabilities. By distributing the servers to the hub stations 1003 as shown in FIG. 1e, the size of the fiber transport network associated with delivering VOD services from the central headend media server is advantageously reduced. Hence, each user has access to several server ports located on at least two servers. Multiple paths and channels are available for content and data distribution to each user, assuring high system reliability and enhanced asset availability. Substantial cost benefits are derived from the reduced need for a large content distribution network, and the reduced storage capacity requirements for hub servers (by virtue of the hub servers having to store and distribute less content).


It will also be recognized that a heterogeneous or mixed server approach may be utilized consistent with the disclosure. For example, one server configuration or architecture may be used for servicing cable, satellite, HFCu, etc. subscriber CPE-based session requests, while a different configuration or architecture may be used for servicing mobile client requests. Similarly, the content servers 1004, 1006 may either be single-purpose/dedicated (e.g., where a given server is dedicated only to servicing certain types of requests), or alternatively multi-purpose (e.g., where a given server is capable of servicing requests from different sources).


The network 1000 of FIG. 1e may further include a legacy multiplexer/encrypter/modulator (MEM; not shown) coupled to the network 1005 adapted to “condition” content for transmission over the network. In the present context, the content server 1004 and packetized content server 1006 may be coupled to the aforementioned LAN, thereby providing access to the MEM and network 1005 via one or more file servers (not shown). The content server 1004 and packetized content server 1006 are coupled via the LAN to a headend switching device 1008 such as an 802.3z Gigabit Ethernet (or incipient “10G”) device. Video and audio content is multiplexed at the headend 1001 and transmitted to the edge switch device 1012 (which may also comprise an 802.3z Gigabit Ethernet device).


Individual CPEs 1022 of the implementation of FIG. 1e may be configured to monitor the particular assigned RF channel (such as via a port or socket ID/address, or other such mechanism) for IP packets intended for the subscriber premises/address that they serve.


In the switched digital variant, the IP packets associated with Internet services are received by edge switch, and forwarded to the cable modem termination system (CMTS) 1016. The CMTS examines the packets, and forwards packets intended for the local network to the edge switch. Other packets are in one variant discarded or routed to another component.


The edge switch forwards the packets receive from the CMTS to the QAM modulator, which transmits the packets on one or more physical (QAM-modulated RF) channels to the CPE. The IP packets are typically transmitted on RF channels that are different than the RF channels used for the broadcast video and audio programming, although this is not a requirement. As noted above, the CPE are each configured to monitor the particular assigned RF channel (such as via a port or socket ID/address, or other such mechanism) for IP packets intended for the subscriber premises/address that they serve.


In one embodiment, both IP data content and IP-packetized audio/video content is delivered to a user via one or more universal edge QAM devices 1018. According to this embodiment, all of the content is delivered on DOCSIS channels, which are received by a premises gateway 1020 (described subsequently herein) and distributed to one or more CPE 1022 in communication therewith. Alternatively, the CPE 1022 may be configured to receive IP content directly without need of the gateway or other intermediary. As a complementary or back-up mechanism, audio/video content may also be provided in downstream (in-band) channels as discussed above; i.e., via traditional “video” in-band QAMs. In this fashion, a co-enabled digital set top box (DSTB) or other CPE could readily tune to the new (in-band) RF video QAM in the event that their IP session over the DOCSIS QAM is for some reason interrupted. This may even be accomplished via appropriate logic within the CPE (e.g., autonomously, or based on signaling received from the headend or other upstream entity, or even at direction of a user in the premises; e.g., by selecting an appropriate DSTB or other CPE function).


In the embodiment illustrated in FIG. 1e, IP packetized content is provided to various user devices via the network 1005. For example, content may be delivered to a gateway apparatus 1020 which distributes content received thereat to one or more CPE 1022 in communication with the apparatus 1020.


In another variant, IP simulcast content and existing on-demand, voice, and broadcast content are all provided to the headend switch device 1008 of FIG. 1e. The headend switch 1008 then provides the content to the optical ring 1007 for provision to one or more distribution hubs 1003. IP simulcast content is in one exemplary implementation retrieved from a plurality of content sources at an IPTV server.


The IP-packet content is transmitted to subscriber devices via the universal edge QAM 1018 and the edge network 1005. The IP video (“simulcast”) content is presented to client devices capable of receiving content over the DOCSIS QAMs. For example, the aforementioned gateway device 1020 (as well as an advanced CPE 1022 such as an IP-enabled DSTB may receive the IP simulcast. Legacy CPE may receive content via the gateway device 1020, or via an audio/video “back-up” MPEG transport stream as previously described.


In the illustrated embodiment, the gateway device 1020 serves as a gateway to the IP content for other client devices (such as other CPE 1022 and PMD). The gateway device 1020 may communicate with one or more connected CPE 1022, as well as utilize Wi-Fi capabilities (where so equipped) to communicate wirelessly to other devices. It will also be recognized that the present disclosure may be configured with one or more short-range wireless links such as Bluetooth for lower bandwidth applications (or PAN for greater bandwidth applications).


It is still further appreciated that the delivery of content may include delivery from an “off-net” distribution hub (not shown) to another network (not shown), not associated with the MSO. In this embodiment, a requesting device (such as CPE 1022 or gateway 1020, or user mobile device) may request content from a local headend 1001 which is transferred over both MSO-maintained (“on-net”) and “off-net” networks, such as an interposed Wi-Fi access point (AP) with non-MSO broadband connection to the Internet, such as a Telco FiOS, 4G LTE modem, or the like (and via which the serving MSO server at e.g., the headend 1001 delivers content).


Exemplary Secondary Content Management Architecture


Referring now to FIG. 2, an exemplary embodiment of a secondary content management architecture 200 specifically implementing the various aspects of the disclosure is shown and described. It will be appreciated that the architecture 200 of FIG. 2 can be used in conjunction with any of the foregoing network content distribution architectures (i.e., those of FIGS. 1-1e discussed supra), or can form the basis of its own distribution and delivery architecture.


Additionally, the architectures and systems discussed in co-owned U.S. patent application Ser. No. 13/403,802 filed on Feb. 23, 2012 and entitled “APPARATUS AND METHODS FOR PROVIDING CONTENT TO AN IP-ENABLED DEVICE IN A CONTENT DISTRIBUTION NETWORK”, which is incorporated herein by reference in its entirety, may be utilized in conjunction with the present disclosure as well.


As shown in FIG. 2, the exemplary management architecture 200 generally comprises an Advertisement Management Service (AMS) 203, which is configured to select individual ones of a plurality of secondary content (e.g., advertisements, promotions or “info-mercials”, commercials, telescoping information/advertisements, and short segments) for delivery to individual ones of the client 106 from an secondary content store (not shown). The AMS 203 may, in one embodiment, comprise a server or other computerized device and may be adapted to comply with the requirements set forth in the Society of Cable Telecommunications Engineers SCTE 130-1 and SCTE 130-3 Digital Program Insertion—Advertising Systems Interfaces standards, and/or IAB (Interactive Advertising Bureau) standards and practices, including e.g., those set forth in “Traffic Fraud: Best Practices for Reducing Risk to Exposure”, updated May 2015; “OpenRTB Dynamic Native Ads API—Specification Version 1” dated February 2015; “OpenDirect API Specification Version 1.0”, finalized January 2015; “Digital Video In-Stream Ad Format Guidelines” released Jan. 8, 2016; “RTB Project OpenRTB API Specification Version 2.4” (Final Draft) dated March 2016; and “RTB Project OpenRTB Dynamic Native Ads API, Specification Version 1.1” dated March 2016, each of the foregoing incorporated herein by reference in its entirety. In one embodiment, the AMS 203 is in communication with an Advertisement Decisioning Service (ADS) 202, the ADS comprising another computerized network entity which is adapted to determine individual ones of the plurality of secondary content from the content store (not shown) to be inserted into the primary content and delivered to the client 106, based on e.g., selection applications or algorithms running on the ADS.


A receiver/decoder entity 208 of the network 200 receives content (e.g., audio, video, data, files, etc.) which is then encoded at the encoder/transcoder 210 to an appropriate format (codec, bitrate, etc.) for the requesting device 106. In one implementation, video is transcoded from a mezzanine quality down to e.g., MPEG-4. The encoder/transcoder 210 may also be used to transcode the content to MP4 in MPEG-2 transport stream (TS) format in a non-rate adaptive manner. The non-rate adaptive format may be used in this case because the stream has a constant bit rate (CBR) at this stage. Utilization of the MPEG-2 TS container enables the MP4 or other content to be multicast to a plurality of devices on the network. Additionally, the MPEG-2 TS content may be delivered with advertisement or other “secondary” content inserted therein via one or more intermediary advertisement insertion mechanisms (not shown). Exemplary apparatus and methods for selection of secondary content to be inserted (e.g., via a “targeted” approach) are described in co-owned U.S. patent application Ser. No. 11/186,452 filed on Jul. 20, 2005 and entitled “METHOD AND APPARATUS FOR BOUNDARY-BASED NETWORK OPERATION”, U.S. patent application Ser. No. 12/284,757 filed on Sep. 24, 2008 entitled “METHODS AND APPARATUS FOR USER-BASED TARGETED CONTENT DELIVERY”, and issued as U.S. Pat. No. 9,071,859 on Jun. 30, 2015, and U.S. patent application Ser. No. 12/766,433 filed on Apr. 23, 2010 and entitled “APPARATUS AND METHODS FOR DYNAMIC SECONDARY CONTENT AND DATA INSERTION AND DELIVERY”, each of which is incorporated herein by reference in its entirety, although other approaches may be used consistent with the present disclosure.


In one embodiment (see discussion of FIG. 3 infra), the architecture 200 of FIG. 2 is configured to generate a unique identifier (e.g., session ID, such as a globally unique ID or GUID, or identifier which is unique for each particular client device or process) for includion with a manifest file relating to delivery of primary content (e.g., video assets) requested by the user. As detailed subsequently herein, this approach allows the architecture (including AMS via ADS) to prevent false “counts” for secondary content (e.g., advertisements) which are associated with the primary content assets, such as might be instigated by a “bot” or other malicious entity.


In one exemplary implementation of the foregoing architecture, one or more “beacons” or indicators (including, without limitation, advertisement tags, web beacons, and metadata or data containers) are also embedded into e.g., the metadata of the secondary content, the secondary content itself, or associated with the URLs of the secondary content (as described in greater detail below). In one embodiment, the one or more beacons or indicators may comprise quartile beacons, indicating that 25%, 50%, and 75% (and 100% if desired) of the individual one of the secondary content has been “consumed” by the client device that is rendering the content. It will be appreciated that the term “consumed” as used in the present context may have various definitions, including without limitation: (i) receipt of a valid consumption request at the AMS; (ii) receipt of a data indicative of an actual decode of the relevant chunk(s), or (iii) receipt of data indicative of extraction of the beacon/indicator from e.g., the metadata of a received content chunk (without knowledge of actual decode by the client). In one implementation, the one or more beacons may comprise ID3 tags, such as for example as those adapted to comply with the requirements set forth in ID3 tag version 2.3.0 (see e.g., http://id3.org/id3v2.3.0), which is incorporated herein by reference in its entirety. Alternatively, another mechanism to carry or entrain metadata within an ABR streaming protocol can be used, such as without limitation an encoder-agnostic approach such as MPEG-DASH (aka Dynamic Adaptive Streaming over HTTP); see e.g., ISO/IEC Std. 23009-1:2012 published April, 2012, and incorporated herein by reference in its entirety. The embedding functions are performed by, in one embodiment, the encoder/transcoder 210, although depending on the scheme used, such “embedding” may be performed by other entities (such as where the tag or indicator is part of e.g., a URL or other data element other than the encoded content).


The encoded content is passed from the encoder 210 to the packager 212, where various service variants are generated and distributed to an origin server 214. The service variants created by the packager 212 correspond to the various services identified by the content providers 201. Thus, each service variant is, in the illustrated embodiment, provided a different playlist (or manifest) containing one or more triggers or markers for varying content based on various considerations. In addition, certain service variants may have triggers embedded in the manifest which other variants may not have.


In on embodiment, the triggers or markers contained in the primary content mark an event that is of interest. In an exemplary embodiment, the events of interest are secondary content (e.g., advertisement) insertion events. That is to say, the primary content is segmented at least at advertisement insertion breaks. The segmenting functions may be performed by, in one embodiment, a staging processor (not shown). Triggering functions may occur using e.g., in-band signaling. In one embodiment, the trigger comprises an Society of Cable Telecommunication Engineers (SCTE)-35 trigger of the type known in the art. Specifically, an SCTE-35 trigger is a cue message embedded in the transport stream which indicates an insertion event which is used to, inter alia, indicate advertisement insertion points (see e.g., SCTE Standards Document ANSI/SCTE 118-2 2007 entitled “Program-Specific Ad Insertion-Content Provider to Traffic Communication Applications Data Model”, which is incorporated herein by reference in its entirety). In the exemplary embodiment of the present disclosure, the SCTE-35 cue is maintained within the manifest or playlist; it will be appreciated that traditional SCTE-35 cues may be used in addition to those used for embedding beacons or indicators into advertisements as described elsewhere herein. In one exemplary implementation, the SCTE-35 cues are transported in a binary structure in a MPEG-2 transport stream, and are converted to a ASCII- or XML-based structure and embedded in the manifest file which later can trigger the secondary content (e.g., advertisement) insertion.


Still further, the packager may use a Placement Opportunity Interface Specification (POIS) as described by SCTE Standards Document ANSI/SCTE 130-1 200 entitled “Digital Program Insertion—Advertising Systems Interfaces”, which is incorporated herein by reference in its entirety, to signal to the alternate event service of alternate event notifications signaled via SCTE-35 triggers.


When primary content is requested by the client 106, the request is serviced via the edge cache 216 which receives content from the origin server 214. Primary content may be stored at the edge 216 in order to facilitate delivery thereof with less latency than content delivered from the origin server 214 (or even deeper towards the core of the network). A content request from a client device 106 to the edge cache 216 in one implementation contains at least the headend ID (or other identifier) assigned to the device 106 by an authorization server (not shown). Alternatively, the MAC address or other device/user-specific identifier (e.g., IP address) or URL which is associated with a known or determinable location may be utilized. Yet further, location-specific coordinates such as e.g., GPS/A-GPS—generated lat/lon., zip code, or other geolocation data may be used to identify one or more such locations. The edge cache uses the identifier to ensure that the appropriate service variant is provided to the requesting device 106.


During playback of the requested primary content according to the playlist or manifest thereof, the client may reach a trigger (such as a URL redirect trigger which is placed in a manifest at each instance of an SCTE-35 marker by the packager 212), indicating that content may no longer be provided, and/or alternate content is needed. The trigger event in one exemplary implementation causes the CPE 106 to request an appropriate URL from the Manifest Manipulator (MM) 204, another computerized network entity (which may be a software application or process operating on a host server 205 or other hardware environment; e.g., co-located with other network functionality). The MM 204 then queries the ADS 202 for information regarding which individual ones of the plurality of secondary content should be inserted into the content. In one implementation, the ADS 202 consults a list of pre-designated alternative content provided by the content providers 201 to determine which URL (i.e., the URL for which content) should be transmitted to the requesting device 106.


The ADS 202 responds to the MM 204 with a decision which gets translated into a list of URL's that represent the “chunks” of the secondary content that collectively comprise secondary content element (e.g., an entire advertisement). In an exemplary embodiment of the present disclosure, the ADS response also contains one or more unique identifiers (such as, e.g., a session-specific identifier such as a globally unique identifier (GUID) or universally unique identifier (UUID) that uniquely represent the client's request for a session (e.g., a video session)), or yet other types of identifying information. The list of secondary content-related URLs is then inserted into the manifest or playlist that contains the list of addresses or URLs for the associated primary content, whether in addition to, or in substitution of, the primary content URLs. The purpose of implementing the unique identifiers is so that the client is required to request at least one of the actual secondary content “chunks” using the included identifier, in order for an accounting request to be considered legitimate.


The client 106 parses the manifest and requests from the ADS 202 the first URL for each unique secondary content request (referred to herein as an “accounting” URL), which also contains the unique identifier for the session. The ADS 202 verifies that the unique identifier is the actual unique identifier that the ADS 202 had (recently) generated. Upon a successful validation, the ADS 202 considers the client's 106 request based at least in part on the verification of the accounting URL to be legitimate.


It will be appreciated that various implementations described herein may also dictate varying client device configuration (e.g., in terms of application or other software or middleware) in order to accommodate the fraud prevention and/or consumption management functions described herein. For instance, certain embodiments of the CPE 106 of FIG. 2 may be IP-enabled client devices (whether fixed or mobile in form), that may include an MSO or third party “app” thereon for interface with the MSO's IP-packetized content delivery service. The app may, for example, include the necessary code to examine and extract the aforementioned GUID and/or beacons from the received manifest file, and utilize them in forming requests to the ADS or CDN for content delivery, or for informational purposes to the ADS (e.g., messages indicate of beacons for percent completion).


In other implementations, the client 106 may comprise a DSTB (digital settop box) or the like, with middleware which can be “flashed” or updated in order to implement the GUID and/or beacon functionality. Myriad other configurations of CPE 106 useful with the present disclosure will be recognized by those of ordinary skill.


Methods


Referring now to FIG. 3, an exemplary embodiment of a method 300 for preventing advertisement viewing fraud within a managed network, such as the exemplary network of FIGS. 1-1e, is illustrated.


As shown, per step 302, one or more primary content elements are obtained. For instance, a number of different programs may be ingested into the network 200 from third party content sources. In one particular implementation of step 302 of the method 300, a content provider 201 creates a cross-reference list of identifiers (such as e.g., headend IDs, geographic or location identifiers, system identifier, market identifier, program ID, stream ID) to appropriate services based on negotiated viewing rights. In one embodiment, each available service may be associated to e.g., a relevant geographic region, and/or according to other criteria.


The content provider 201 publishes the matchup of headend ID (or other ID as indicated above) to particular programming for use by the AMS 203. A new list is generated, in one embodiment, based on particular events (such as a user request), or periodically, or whenever an event notification is needed. The AMS 203 may also request or “pull” the list from the content provider(s). The list is published to the AMS 203 in one embodiment using a WebServices interface, although other approaches may be used consistent with the present disclosure.


The content is marked with one or more markers or triggers. In one embodiment, the markers comprise SCTE-35 markers as discussed above, and indicate alternate program events. In one such implementation, the content provider 201 is responsible for marking events.


Alternatively, the content provider 201 may merely provide necessary information to the AMS 203, ADS 202, packager 212, or the origin server 214, and one of these entities may insert appropriate markers or triggers into the relevant events. As yet another alternative, the marker insertion task may be divided between the content providers and one or more other entities, such as based on a prescribed division scheme (e.g., content providers insert certain types of markers, while other entities insert others).


The content is then encoded and published per step 304. In one embodiment, the content is encoded into an ABR (adaptive bit rate) streaming protocol based on a hypertext transfer protocol (HTTP) transport for provision to mobile devices using e.g., HLS or Smooth Streaming, or ISO-DASH, as discussed above. As the content is encoded, the SCTE-35 or otherwise marked alternate program event is converted by the packager 212 to a redirection URL in the manifest or playlist for the content which is ultimately published and stored on the origin server 214 or edge cache 216. Normally, the client device 106 plays the content from the manifest, and when the redirect URL is encountered, it points the client to the MM 204, which acts as a proxy server for the ADS 202. However, in the exemplary embodiment of the present disclosure, the redirect URL resolves to the ADS 202 which, as described elsewhere herewin, validates the client's request.


At step 306, the client requests the manifest for the primary content from the MM 204. For example, one of the previously ingested and encoded/marked programs is requested by the client via e.g., an application program (e.g., guide, web browser, etc.) running thereon, which triggers a request for the manifest file.


At step 308, the MM 204 queries the ADS 202 for information regarding which individual ones of the plurality of secondary content should be inserted into the content. The ADS 202 consults a list of pre-designated alternative content provided by the content providers 201 (or otherwise, such as being based on one or more local advertising campaigns from e.g., an content distributor (MVPD)) to determine which URL (i.e., the URL for which content) should be transmitted to the requesting device 106. In one embodiment, the MM 204 queries the ADS 202 by sending a message.


In one exemplary configuration, the ADS 202 also generates one or more unique identifiers embedded in the data or metadata of the secondary content or associated with the secondary content streamed or transmitted from the head end of the network, such as by the MSO, or by a third party server or service (step 310). The one or more identifiers are again, in one exemplary embodiment, utilized to determine whether an accounting request is to be considered legitimate, by requiring that the client requesting the manifest or playlist present an authentic or valid unique identifier, as discussed elsewhere herein.


In one embodiment, the one or more unique identifiers are “per-session” unique identifier that uniquely represents the client's request for a session (e.g., a video session). In one implementation, the one or more unique identifiers comprise a globally unique identifier (GUID) and/or universally unique identifier (UUID)), although it will be appreciated that other approaches may be used. For instance, in one alternate implementation, the unique identifier may comprise a seed value to be used by a shared one-way hash algorithm possessed by the client and the ADS or MM. As is well known, one-way hashing functions are cryptographic elements which, when a given value (seed) is inserted, produce a wholly unique output value. The algorithm is undiscoverable by the output alone, and hence surreptitious attempts to “hack” the algorithm using the output values are frustrated. The sharing entities (here, client and ADS/MM) should produce an identical output when the seed (input) is identical, and hence this can be used to authenticate the request, such as where the manifest file contains a unique seed (which may be issued on a per-session basis, rotated periodically, or expire, and itself comprise an output of another cryptographic process) which the client operates on using the hash algorithm to generate an output, and returns that output (i.e., in place of or along with the aforementioned GUID) as part of the secondary content request to the ADS.


In another implementation, the selection of URLs or other addressing may be used to indicate authenticity of the secondary content request. For instance, the secondary content URLs disposed within each manifest file (even for the same secondary content asset) may be changed or rotated periodically or per-session, so that each manifest is unique in one or both of (i) one or more URLS used for content delivery, and/or (ii) the order of which the URLs are presented to the ADS. Hence, in one variant, the ADS is configured to select the URLs associated with the chunks of the secondary content element(s) to be served with the manifest file in such a fashion as to be unique in some capacity (there by address, order, both, or some other metric), and later verify this same uniqueness is preserved on any subsequent “client” requests for the request to be considered valid. This approach advantageously allows use of a client which requires no special adaptation of its software/firmware (e.g., to extract and include a GUID or similar in its requests); rather, the client merely extracts the URLs as it normally would and includes them in its request, and it is the URLs themselves (or their order) which act as the “unique identifier”.


Similarly, the GUID or unique identifier can be appended to or embedded within the URL itself, such that “static” URLs can be used for a given secondary element, but validation of the request via the GUID or other identifier can still occur by the ADS.


The list of secondary content-related URLs is then inserted or embedded into the manifest or playlist that contains the list of URLs for the associated primary content. The first URL for each unique secondary content request is an “accounting” URL which also contains the unique identifier for the session.


It is appreciated, however, that other identifiers may be employed, the foregoing being merely illustrative of the overall concept of linking the individual ones of the secondary content being requested to the user/device requesting access to the secondary content and associated primary content. For example, the present disclosure also contemplates using other mechanisms such as those employed in the registration process for authenticating user and/or requesting device identity, discussed in previously referenced co-owned U.S. patent application Ser. No. 13/403,802 filed Feb. 23, 2012 and entitled “APPARATUS AND METHODS FOR PROVIDING CONTENT TO AN IP-ENABLED DEVICE IN A CONTENT DISTRIBUTION NETWORK”. Such mechanisms for authenticating user and/or requesting device identity described therein, include e.g., digital certificates, key exchanges, biometric data relating to a user, and so forth.


In one embodiment, the ADS 202 maintains a list of all identifiers that it has generated for secondary content decision requests made for all active sessions.


At step 312, the ADS 204 publishes one or more URLs for the appropriate content that will replace the requested content at the marked event. In other words, the ADS 202 responds to the MM 204 with a decision which gets translated into a list of URL's that comprise the individual ones of secondary content. The ADS 202 may obtain the correct redirect URL from the content providers 201 or, alternatively, the packager 212 or MM 204 may provide the URL's of the primary and secondary content to the ADS 204. As another option or alternative, a local ad campaign (or content distributor (MVPD) may act as the source. The ADS 202 uses the URLs to create the associated service list with the appropriate URLs. In this instance, when the client device 106 encounters the event, and requests a redirect URL the ADS 202 may consult the service list to redirect the device to the appropriate content. The individual ones of secondary content may also optionally contain one or more beacons or tags inserted therein, as discussed infra.


At step 314, the MM 204 inserts the URLs for individual ones of secondary content determined by the ADS 202 into the manifest associated with the insertion points indicated by the triggers contained in the primary content. The MM 204 then provides the manifest to the client 106.


At step 316, the client 106 then parses the manifest, and the device 106 attempts to access content from the network (e.g., CDN) by sending a request for the primary content. The client 106 uses each URL listed in the manifest to request data from the service provider. For URLs that represent the primary content, the requests are typically made to a CDN which returns “chunks” of content to be rendered by the client device.


Per step 318, when an secondary content break occurs, the first secondary content-related URL resolves to the ADS 202, wherein the one or more unique identifiers provided to the client 106 in step 314 are presented (whether as part of the requested URL of the first chunk, as part of each URL of each chunk, as part of a separate message sent to the ADS, or yet other approach.


In one embodiment, the manifest manipulation-based secondary content insertion appears seamless to the end user by configuring the primary content “chunks” and the secondary content “chunks” to align the secondary content break boundaries with the primary content “chunk” boundaries.


At step 320, the verification process is performed. When the ADS 202 receives this request, the ADS 202 verifies that the one or more unique identifiers provided in the request is corresponding one or more unique identifiers that it had recently generated in step 310 (or via other uniqueness attributes as described previously herein). If the one or more unique identifiers is/are determined to be the recently generated one or more unique identifiers, then the ADS 202 performs an accounting function to note that an individual one of the secondary content is about to be delivered (and presumably viewed by the client 106). In other words, upon a successful validation, the ADS 202 considers the client's 106 request based at least in part on the verification of the accounting URL to be legitimate and thus, counts is to be utilized by the content distributor in billing the advertiser. It is noted that in this particular embodiment, no actual consumption or rendering is verified; rather, the presentation of the correct GUID or other data validates the request. Moreover, the exemplary approach of FIG. 3 also does not validate the primary content request via the GUID; rather, the only predicate for delivery of the secondary content chunk(s) is the validation of the secondary content request by the ADS.


Per step 322, the client 106 then requests the other ones of the individual ones of the secondary content from the CDN 214 based upon the remaining secondary content related URLs listed in the manifest file, and receives and renders. Note that in one variant, the validation of step 320 need only occur for the first chunk; all remaining URLs associated with eth secondary content in the manifest file resolve to the CDN (or another non-ADS entity); these are presumed to be valid requests (e.g., if received within a prescribed period of time). Alternatively, in another variant, each secondary content URL may resolve to the ADS, such that validation of each chunk request occurs before the relevant secondary content chunk is delivered. Various combinations of the foregoing may also be utilized, as will be appreciated by the artisan of ordinary skill given the present disclosure.


For each quartile received by the client 106, an accounting message is sent to the ADS 202, allowing the ADS 202 to report on the percentage of the individual one of the secondary content rendered (step 320).



FIG. 3a illustrates an alternate embodiment of the foregoing method.


Specifically, at step 332, the primary content is ingested, and markers for secondary content redirect are inserted as previously described. Next, at step 334, the primary content is encoded, and listed as available.


At step 336, the client requests the manifest file (e.g., via selection of the primary content).


At step 338, a secondary content decision is requested from the ADS 202 by the MM 204. At step 340, the GUID or other identifier is generated, and provided to the MM along with the secondary content insertion decision per step 342.


At step 344, the manifest file is created (including GUID) and sent to the requesting client.


At step 346, the client requests the primary content (which in this case resolves to the ADS for request validation per the GUID inserted therein), or is otherwise validated.


Per step 348, the first request for the secondary content is received at the ADS, and the request is validated based on (i) proper presentation of the GUID or other unique identifier, and (ii) the prior validation of the primary content request from the same client (such as via GUID associated with the primary request per step 346) per step 350. In this fashion, both the presentation of the valid GUID and the prior validated content request are used as indicia of the authenticity of the secondary content request (i.e., the same client is actually consuming the primary content as well as requesting the secondary content).


Finally, the secondary content is delivered to, and rendered by the client 106 (step 352).


Secondary Content Tag or Beacon Insertion


Referring now to FIG. 4, a further aspect of the disclosure is described, wherein so-called “beacons”, tags, or other indicators are inserted into the secondary content (or associated metadata or URLs) indicate of one or more parameters relating to e.g., the consumption of the secondary content asset by the client device.


At step 402 of the method 400, the primary content is ingested, and markers for secondary content redirect are inserted as previously described.


At step 404, the primary content is encoded, and listed as available.


At step 406, the client requests the manifest file (e.g., via selection of the primary content).


At step 408, a secondary content decision is requested from the ADS 202 by the MM 204. At step 410, the GUID or other identifier is generated, and provided to the MM along with the secondary content insertion decision.


At step 412, the manifest file is created (including GUID) and sent to the requesting client. Also part of step 412 is the “insertion” of one or more beacons or tags into the secondary content. In one exemplary implementation, the insertion of the beacons or tags involves inserting these elements into the metadata associated with the secondary content element (the latter which comprises a series of temporally contiguous chunks of media data).


As a brief aside, “metadata” includes extra data not typically found in (or at least not visible to the users of) the network. This metadata may be validated against relevant specifications if desired, such as e.g., those provided by CableLabs. For each individual secondary content element, a metadata file is generated that specifies which events are associated with that individual secondary content element. For example, a simple “one-association” secondary content element would include metadata that associates the individual secondary content element chunk with a URL where that chunk can be found. The metadata can be rendered in human-readable form if desired. Additional and/or different metadata content may be used, such as, for example, providing user rating data for particular events, source of the content element, etc. The metadata information can be packaged in a prescribed format such as a markup language (e.g., XML, or JSON). International standards for audiovisual metadata, such as the ISO/IEC “Multimedia Content Description Interface” (also referred to as MPEG7), or the TV-Anytime Forum's “Specification Series: S-3 on Metadata”, could also be used as the basis for the metadata.


The metadata is in the exemplary implementation delivered with the manifest file issued by the MM, although other approaches may be used consistent with the disclosure. As described previously, one particular implementation of the foregoing approach uses temporally-related (e.g., quartile or percentage completion) beacons, indicating e.g., 25%, 50%, and 75% and 100% of the individual one of the secondary content has been “consumed” by the client device that is rendering the content.


In one implementation of the method 400, the one or more beacons may comprise ID3 tags (for HLS), or DASH metadata/events. The embedding functions may be performed by, in one embodiment, the encoder/transcoder 210 (FIG. 2), although depending on the scheme used, such “embedding” may be performed by other entities (such as where the tag or indicator is part of e.g., a URL or other data element other than the encoded content).


As noted, the term “consumed” as used in the present context may have various definitions, including without limitation: (i) receipt of a valid consumption request at the AMS; (ii) receipt of a data indicative of an actual decode of the relevant chunk(s), or (iii) receipt of data indicative of extraction of the beacon/indicator from e.g., the metadata of a received content chunk (without knowledge of actual decode by the client). Hence, the present disclosure contemplates variants of the foregoing process wherein the beacon or tag data is embedded in or associated with various different elements delivered to the client. For instance, as noted above, the beacons may be embedded in or be part of the metadata which is associated with the manifest file.


In another implementation, the beacons or tags are embedded in or part of one or more of the URLs associated with the secondary content chunks. In yet another implementation, the beacons or tags are embedded within the encoded content itself (e.g., as part of or after the last GOP, etc. in the encoded MPEG-4 or H.264 content files). In this fashion, a given content chunk must actually be decoded (and presumably rendered) by the client device in order for the beacon or tag to be extracted. See discussions of FIGS. 4a and 4b provided subsequently herein.


At step 414, the client requests the primary content (which in this case resolves to the CDN).


Per step 416, the first request for the secondary content is received at the ADS, the request is validated based on proper presentation of the GUID or other unique identifier, and the requested content chunk(s) then delivered to the client (step 418).


At step 420, the received secondary content chunks are rendered by the client, and the beacons or tags extracted from the metadata (or the content elements themselves, as noted above). Each extracted tag (or information derived therefrom) is then sent to the ADS per step 422. It will be appreciated that various orders of performance of the foregoing steps are contemplated by the present disclosure, such as where e.g., (i) the extracted tags or beacons are sent to the ADS prior to rendering of the encoded content chunk; (ii) the extracted tags or beacons are sent to the ADS during rendering of the encoded content chunk; and (iii) the extracted tags or beacons are sent to the ADS after completion of rendering of the encoded content chunk, such as by way of the subsequent chunk request to the source URL, or as a separate communication. The individual tags/beacons may also be aggregated and sent to the ADS or other responsible network entity as a file or similar, such as via an 00B message protocol.



FIG. 4a shows an alternate methodology to that 400 of FIG. 4. Specifically, at step 432, the primary content is ingested, and markers for secondary content redirect are inserted as previously described. Next, at step 434, the primary content is encoded, and listed as available.


At step 436, the client requests the manifest file (e.g., via selection of the primary content).


At step 438, a secondary content decision is requested from the ADS by the MM. At step 440, the GUID or other identifier is generated, and provided to the MM along with the secondary content insertion decision. Also part of step 440 is the “insertion” of one or more beacons or tags into the URLs associated with the secondary content. In the exemplary implementation of FIG. 4a, the insertion of the beacons or tags involves inserting these elements into or associating them with individual ones of the URLs for the secondary content. For instance, where a secondary content element is divided temporally into N chunks, tags or beacons with data corresponding to 1/N, 2/N, . . . N/N completion may be utilized. Hence, a first tag may be indicative of 1/N completion; i.e., that the first of the N chunks has been at least requested. Other partitioning or indication schemes may be used as well, such as those relating to other consumption-related parameters of interest (e.g., chunks within which a “pause” or termination event was received, a single end-to-end or “full play” of the advertisement, interactivity by the user with a telescoping or other function indicative of possible interest, etc.).


At step 442, the manifest file is created (including GUID) and sent to the requesting client.


At step 444, the client requests the primary content (which in this case resolves to the CDN).


Per step 446, the first request for the secondary content is received at the ADS, the request is validated based on proper presentation of the GUID or other unique identifier, and the requested content chunk(s) then delivered to the client (step 448). Also received at step 446 by the ADS is the nth chunk tag or beacon, which is embedded within or otherwise associated with the requested chunk's URL.


At step 450, the received secondary content chunk is rendered by the client. At or before completion of the nth chunk rendering by the client, the client accesses the manifest for the next URL (including the nth beacon or tag associated therewith), and transmits it to the serving entity (e.g., CDN). In such case, the CDN may pass the received tag to the ADS, or the client may be configured to route the tag portion to the ADS, while routing the URL to the CDN.


Per steps 452 and 454, the foregoing process iterates until all N of the secondary content chunks have been delivered to the client.



FIG. 4b shows yet another alternate methodology to that 400 of FIG. 4. Specifically, at step 460, the primary content is ingested, and markers for secondary content redirect are inserted as previously described. The secondary content is also obtained or identified per step 460.


At step 462, the primary content is encoded, and listed as available.


At step 464, the secondary content is encoded into N separate chunks, and the beacons or tags for each chunk inserted as part of the encoding process (i.e., within the content of each chunk), such that the content chunk has to be decoded to extract the beacon/tag.


At step 466, the client requests the manifest file (e.g., via selection of the primary content).


At step 468, a secondary content decision is requested from the ADS by the MM. At step 469, the GUID or other identifier is generated, and provided to the MM along with the secondary content insertion decision (and associated secondary content asset information).


At step 470, the manifest file is created (including GUID) and sent to the requesting client.


At step 472, the client requests the primary content (which in this case resolves to the CDN).


Per step 474, the first request for the secondary content is received at the ADS, the request is validated based on proper presentation of the GUID or other unique identifier, and the requested content chunk(s) then delivered to the client (step 476).


At step 478, the received secondary content chunk is decoded and rendered by the client. As part of the decode, the nth tag or beacon is extracted from the content element, such as after rendering of the element has completed.


At step 480, it is determined whether the all N chunks have delivered to the client; if not, the method proceeds to step 482, wherein the count (n) is incremented, and the extracted nth tag or beacon is provided to the ADS along with presentation of the URL for the n+1 chunk to e.g., the CDN.


When all N chunks have been delivered (or rendering of N−1 chunks have been confirmed by receipt of the N−1th tag) per step 480, the final (Nth) content element is rendered, the Nth tag extracted, and the Nth tag sent to the ADS per step 484.


It will be recognized that while certain aspects of the disclosure are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods described herein, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the embodiments disclosed and claimed herein.


While the above detailed description has shown, described, and pointed out novel features of the disclosed embodiments as applied to various systems, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the principles described herein. The foregoing description is of the best mode presently contemplated. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the disclosure. The scope of the disclosure should be determined with reference to the claims.

Claims
  • 1. A method of mitigating advertising viewing fraud during delivery of Internet Protocol (IP) packetized media content and advertising content to an IP-enabled client device of a subscriber within a managed content delivery network, the method comprising: authenticating at least one of the subscriber and the IP-enabled client device to access content via the managed content delivery network;receiving a first communication from the IP-enabled client device for delivery of the IP packetized media content;causing generation of a unique session identifier relating to the first communication;transmitting a manifest file containing the unique session identifier, a first information relating to a plurality of media elements, and a second information relating to at least one advertising element, to the IP-enabled client device;receiving from the IP-enabled client device another communication, the another communication comprising at least a portion of the second information and the unique session identifier;validating the another communication based at least on the unique session identifier contained therein;causing counting of the validated another communication as a valid advertising request; andcausing provision of the at least one advertising element to the IP-enabled client device via an IP transport; andwherein the validating is configured to reject a false communication not having the unique session identifier from being counted.
  • 2. The method of claim 1, further comprising: receiving a communication containing the unique session identifier and at least a portion of the first information; andcausing delivery of at least a portion of the plurality of media elements to the IP-enabled client device via an IP transport.
  • 3. The method of claim 2, wherein: the receiving the communication containing the unique session identifier and the at least a portion of the first information, and the causing delivery of the at least the portion of the plurality of media elements to the IP-enabled client device via an IP transport, each occurs before the receiving from the IP-enabled client device of the another communication; andthe receiving the communication containing the unique session identifier and the at least a portion of the first information is a condition precedent for the validating of the another communication.
  • 4. The method of claim 1, wherein the transmitting the manifest file further comprises transmitting data relating to an indicator of one or more parameters related to consumption of the at least one advertising element.
  • 5. The method of claim 4, wherein the transmitting the data relating to the indicator comprises transmitting data relating to a percentage of a secondary content associated with the at least one advertising element consumed by the IP-enabled client device.
  • 6. The method of claim 1, further comprising causing insertion of the at least one advertising element at an advertisement insertion break within the plurality of media elements.
  • 7. Network apparatus of a content distribution network, the network apparatus configured for mitigating advertising viewing fraud by validating an advertising content request, the advertising content request associated with delivery of packetized media content via an IP (Internet Protocol) transport, the network apparatus comprising: processing apparatus;network interface apparatus in data communication with the processing apparatus and configured to conduct data communications with a plurality of client devices via at least the content distribution network; andstorage apparatus in data communication with the processing apparatus and comprising a plurality of computerized instructions executable on the processing apparatus, the plurality of computerized instructions configured to, when executed: cause generation of a shared data element for provision to a particular client device;transmit at least the shared data element to the particular client device via the network interface apparatus and the content distribution network;receive a request for provision of advertising content from the particular client device, the request including the shared data element;extract the shared data element present within the request;utilize at least a portion of the shared data element to validate the request; andusing the validation with respect to at least one fraudulent or unconsumed request to prevent the network apparatus from counting the at least one fraudulent or unconsumed request.
  • 8. The network apparatus of claim 7, wherein: the shared data element comprises an identifier which is globally unique at least within the content distribution network for at least a prescribed period of time;the transmission of the shared data element to the particular client device comprises a transmission of a host data structure of which the shared data element is part, the host data structure further comprising data indicating one or more network locations where the packetized media content may be obtained by the particular client device; andthe request specifies a universal resource locator (URL) present within the host data structure from which at least a portion of the advertising content can be obtained.
  • 9. The network apparatus of claim 8, wherein the host data structure comprises a manifest file comprising (i) one or more URLs corresponding to the one or more network locations where the packetized media content may be obtained; and (ii) the URL present within the host data structure from which the at least a portion of the advertising content can be obtained.
  • 10. The network apparatus of claim 7, wherein the plurality of computerized instructions are further configured to, when executed, verify that at least a portion of the packetized media content has been previously requested by the particular client device as part of a common session.
  • 11. The network apparatus of claim 10, wherein the common session is identified within the shared data element.
  • 12. The network apparatus of claim 7, wherein the causation of the generation of the shared data element for the provision to the particular client device is pursuant to receipt by the network apparatus of a prior request issued by the particular client device to obtain a manifest file relating to the packetized media content.
  • 13. A method of delivering Internet Protocol (IP) packetized advertising content to an IP-enabled client device of a user within a content distribution network, the method comprising: obtaining a unique identifier;transmitting a data structure comprising at least the unique identifier, and first information relating to a plurality of advertising content elements, to the IP-enabled client device, the plurality of advertising content elements each comprising a portion of a complete advertisement;receiving from the IP-enabled client device a communication, the communication comprising at least: (i) a first portion of the first information, the first portion of the first information relating to a first one of said plurality of advertising content elements, and (ii) the unique identifier or a derivative thereof;validating the communication based at least on the unique identifier or the derivative thereof;causing provision of the first one of said plurality of advertising content elements to the IP-enabled client device via an IP transport;receiving from the IP-enabled client device a subsequent communication, the subsequent communication comprising: (i) a second portion of the first information, the second portion of the first information relating to a second one of said plurality of advertising content elements, (ii) the unique identifier or the derivative thereof, and (iii) consumption-related data; andwherein the consumption-related data is indicative of at least an amount of a then-current consumption of the complete advertisement by the IP-enabled client device.
  • 14. The method of claim 13, wherein the transmitting the data structure comprises transmitting a selection of universal resource locators (URLs) relating to the plurality of advertising content elements, the selection of URLs changed periodically and configured to be used to indicate authenticity of the communication.
  • 15. The method of claim 14, wherein the validating the communication comprises validating the selection of URLs and an order of the selection of URLs.
  • 16. The method of claim 13, wherein the transmitting the data structure comprises embedding the unique identifier within a universal resource locator (URL) relating to the plurality of advertising content elements.
  • 17. The method of claim 13, further comprising adding the unique identifier to a list, the list configured to maintain all unique identifiers.
  • 18. A method of delivering Internet Protocol (IP) packetized media content and advertising content to an IP-enabled client device of a user within a managed content delivery network, the method comprising: receiving a communication from the IP-enabled client device for delivery of the IP packetized media content;causing generation of a unique session identifier relating to the communication;transmitting a manifest file comprising the unique session identifier, a first information relating to a plurality of advertising content elements, and a second information relating to the IP packetized media content, to the IP-enabled client device, the plurality of advertising content elements collectively comprising a complete advertisement;receiving from the IP-enabled client device an another communication, the another communication comprising at least: (i) a first portion of the first information, the first portion of the first information relating to a first one of said plurality of advertising content elements, and (ii) the unique session identifier;validating the another communication based at least on the unique session identifier contained therein;causing provision of the first one of said plurality of advertising content elements to the IP-enabled client device via an IP transport;receiving from the IP-enabled client device a subsequent communication, the subsequent communication comprising: (i) a second portion of the first information, the second portion of the first information relating to a second one of said plurality of advertising content elements, (ii) the unique session identifier, and (iii) a consumption-related value; andwherein the consumption-related value is indicative of at least one of a quality or an amount of a then-current consumption of the complete advertisement by the IP-enabled client device.
  • 19. The method of claim 18, wherein the receiving the subsequent communication comprises receiving a value related to an ID3 tag embedded in the plurality of advertising content elements.
  • 20. The method of claim 18, wherein the receiving the another communication further comprises receiving a consumption-related value.
US Referenced Citations (556)
Number Name Date Kind
4521881 Stapleford et al. Jun 1985 A
4546382 McKenna et al. Oct 1985 A
4602279 Freeman Jul 1986 A
4905080 Watanabe et al. Feb 1990 A
4930120 Baxter et al. May 1990 A
5155591 Wachob Oct 1992 A
5313454 Bustini et al. May 1994 A
5373315 Dufresne et al. Dec 1994 A
5481294 Thomas et al. Jan 1996 A
5497185 Dufresne et al. Mar 1996 A
5600364 Hendricks et al. Feb 1997 A
5675647 Garneau et al. Oct 1997 A
5734720 Salganicoff Mar 1998 A
5758257 Herz et al. May 1998 A
5774170 Hite et al. Jun 1998 A
5793409 Tetsumura Aug 1998 A
5812642 Leroy Sep 1998 A
5862312 Mann et al. Jan 1999 A
5878324 Borth et al. Mar 1999 A
5914945 Abu-Amara et al. Jun 1999 A
5926205 Krause et al. Jul 1999 A
5929849 Kikinis Jul 1999 A
5935206 Dixon et al. Aug 1999 A
5956037 Osawa et al. Sep 1999 A
5963844 Dail Oct 1999 A
5974299 Massetti Oct 1999 A
6002393 Hite et al. Dec 1999 A
6029045 Picco et al. Feb 2000 A
6047327 Tso et al. Apr 2000 A
6081830 Schindler Jun 2000 A
6088722 Herz et al. Jul 2000 A
6092178 Jindal et al. Jul 2000 A
6124878 Adams et al. Sep 2000 A
6128316 Takeda et al. Oct 2000 A
6134532 Lazarus et al. Oct 2000 A
6161142 Wolfe et al. Dec 2000 A
6169728 Perreault et al. Jan 2001 B1
6177931 Alexander et al. Jan 2001 B1
6182050 Ballard Jan 2001 B1
6202210 Ludtke Mar 2001 B1
6211901 Imajima et al. Apr 2001 B1
6216129 Eldering Apr 2001 B1
6219840 Corrigan et al. Apr 2001 B1
6240553 Son et al. May 2001 B1
6249680 Wax et al. Jun 2001 B1
6272176 Srinivasan Aug 2001 B1
6282713 Kitsukawa et al. Aug 2001 B1
6330609 Garofalakis et al. Dec 2001 B1
6353626 Sunay et al. Mar 2002 B1
6378130 Adams Apr 2002 B1
6389538 Gruse et al. May 2002 B1
6396055 Biedendorf May 2002 B1
6434141 Oz et al. Aug 2002 B1
6446261 Rosser Sep 2002 B1
6463585 Hendricks et al. Oct 2002 B1
6467089 Aust et al. Oct 2002 B1
6498783 Lin Dec 2002 B1
6502076 Smith Dec 2002 B1
6549718 Grooters et al. Apr 2003 B1
6560578 Eldering May 2003 B2
6590865 Ibaraki et al. Jul 2003 B1
6601237 Ten et al. Jul 2003 B1
6604138 Virine et al. Aug 2003 B1
6615039 Eldering Sep 2003 B1
6615251 Klug et al. Sep 2003 B1
6647548 Lu et al. Nov 2003 B1
6671736 Virine et al. Dec 2003 B2
6681393 Bauminger et al. Jan 2004 B1
6687735 Logston et al. Feb 2004 B1
6700624 Yun Mar 2004 B2
6704930 Eldering et al. Mar 2004 B1
6711148 Hills Mar 2004 B1
6718551 Swix et al. Apr 2004 B1
6725461 Dougherty et al. Apr 2004 B1
6738978 Hendricks et al. May 2004 B1
6742187 Vogel May 2004 B1
6763391 Ludtke Jul 2004 B1
6771290 Hoyle Aug 2004 B1
6775843 McDermott Aug 2004 B1
6813776 Chernock et al. Nov 2004 B2
6842783 Boivie et al. Jan 2005 B1
6859845 Mate Feb 2005 B2
6891841 Leatherbury et al. May 2005 B2
6898762 Ellis et al. May 2005 B2
6901606 Wright et al. May 2005 B2
6909837 Unger Jun 2005 B1
6915528 McKenna, Jr. Jul 2005 B1
6986156 Rodriguez et al. Jan 2006 B1
6990680 Wugofski Jan 2006 B1
7007170 Morten Feb 2006 B2
7017179 Asamoto et al. Mar 2006 B1
7024676 Klopfenstein Apr 2006 B1
7039928 Kamada et al. May 2006 B2
7065216 Benaloh et al. Jun 2006 B1
7069573 Brooks et al. Jun 2006 B1
7075945 Arsenault et al. Jul 2006 B2
7086077 Giammaressi Aug 2006 B2
7100183 Kunkel et al. Aug 2006 B2
7109848 Schybergson Sep 2006 B2
7143431 Eager et al. Nov 2006 B1
7146627 Ismail et al. Dec 2006 B1
7152237 Flickinger et al. Dec 2006 B2
7155508 Sankuratripati et al. Dec 2006 B2
7165268 Moore et al. Jan 2007 B1
7174126 McElhatten et al. Feb 2007 B2
7191461 Arsenault et al. Mar 2007 B1
7197472 Conkwright et al. Mar 2007 B2
7213036 Apparao et al. May 2007 B2
7222078 Abelow May 2007 B2
7228555 Schlack Jun 2007 B2
7237250 Kanojia et al. Jun 2007 B2
7240355 Eldering et al. Jul 2007 B1
7242988 Hoffberg et al. Jul 2007 B1
7246150 Donoho et al. Jul 2007 B1
7246172 Yoshiba et al. Jul 2007 B2
7248694 Husemann et al. Jul 2007 B2
7266836 Anttila et al. Sep 2007 B2
7280737 Smith Oct 2007 B2
7281261 Jaff et al. Oct 2007 B2
7308415 Kimbrel et al. Dec 2007 B2
7317728 Acharya et al. Jan 2008 B2
7327692 Ain et al. Feb 2008 B2
7334044 Allen Feb 2008 B1
7340759 Rodriguez Mar 2008 B1
7346688 Allen et al. Mar 2008 B2
7352775 Powell Apr 2008 B2
7353543 Ohmori et al. Apr 2008 B2
7355980 Bauer Apr 2008 B2
7356751 Levitan Apr 2008 B1
7357775 Koh Apr 2008 B1
7363371 Kirby et al. Apr 2008 B2
7363643 Drake et al. Apr 2008 B2
7367043 Dudkiewicz et al. Apr 2008 B2
7369750 Cheng et al. May 2008 B2
7379494 Raleigh et al. May 2008 B2
7444655 Sardera Oct 2008 B2
7457520 Rossetti et al. Nov 2008 B2
7464179 Hodges et al. Dec 2008 B2
7487363 Alve et al. Feb 2009 B2
7567565 La Joie Jul 2009 B2
7567983 Pickelsimer et al. Jul 2009 B2
7577118 Haumonte et al. Aug 2009 B2
7602820 Helms et al. Oct 2009 B2
7603529 MacHardy et al. Oct 2009 B1
7650319 Hoffberg et al. Jan 2010 B2
7712125 Herigstad et al. May 2010 B2
7720432 Colby et al. May 2010 B1
7729940 Harvey et al. Jun 2010 B2
7730509 Boulet et al. Jun 2010 B2
7783316 Mitchell Aug 2010 B1
7801803 Forlai Sep 2010 B2
7870599 Pemmaraju Jan 2011 B2
7900052 Jonas et al. Mar 2011 B2
7900229 Dureau Mar 2011 B2
7930558 Hori Apr 2011 B2
7930715 Hendricks et al. Apr 2011 B2
7954131 Cholas et al. May 2011 B2
8010691 Kollmansberger Aug 2011 B2
8028322 Riedl et al. Sep 2011 B2
8041785 Mazur et al. Oct 2011 B2
8042131 Flickinger Oct 2011 B2
8065703 Wilson et al. Nov 2011 B2
8084792 Lehmann et al. Dec 2011 B2
8099757 Riedl et al. Jan 2012 B2
8205226 Ko et al. Jun 2012 B2
8214256 Riedl et al. Jul 2012 B2
8228818 Chase Jul 2012 B2
8296185 Isaac Oct 2012 B2
8306634 Nguyen et al. Nov 2012 B2
8341242 Dillon et al. Dec 2012 B2
8347341 Markley et al. Jan 2013 B2
8365213 Orlowski Jan 2013 B1
8396055 Patel et al. Mar 2013 B2
8396056 Dalton, Jr. et al. Mar 2013 B2
8442265 Bosworth et al. May 2013 B1
8484511 Engel et al. Jul 2013 B2
8516529 Lajoie et al. Aug 2013 B2
8561113 Cansler et al. Oct 2013 B2
8571931 Riedl et al. Oct 2013 B2
8583484 Chalawsky et al. Nov 2013 B1
8621501 Matheny et al. Dec 2013 B2
8713623 Brooks Apr 2014 B2
8769559 Moon et al. Jul 2014 B2
8856825 Mick, Jr. Oct 2014 B1
8862155 Stern et al. Oct 2014 B2
8863164 Mick, Jr. Oct 2014 B1
8866911 Sivertsen Oct 2014 B1
8898270 Stack et al. Nov 2014 B1
8997136 Brooks et al. Mar 2015 B2
9003436 Tidwell et al. Apr 2015 B2
9027062 Patel et al. May 2015 B2
9071859 Lajoie Jun 2015 B2
9215423 Kimble et al. Dec 2015 B2
9479807 Bugajski Oct 2016 B1
20010001160 Shoff et al. May 2001 A1
20010013123 Freeman et al. Aug 2001 A1
20010030785 Pangrac et al. Oct 2001 A1
20020013772 Peinado Jan 2002 A1
20020026496 Boyer et al. Feb 2002 A1
20020032754 Logston et al. Mar 2002 A1
20020049902 Rhodes Apr 2002 A1
20020054589 Ethridge et al. May 2002 A1
20020059577 Lu et al. May 2002 A1
20020059619 Lebar May 2002 A1
20020063621 Tseng et al. May 2002 A1
20020069404 Copeman et al. Jun 2002 A1
20020073419 Yen et al. Jun 2002 A1
20020078441 Drake et al. Jun 2002 A1
20020078444 Krewin et al. Jun 2002 A1
20020087975 Schlack Jul 2002 A1
20020087976 Kaplan et al. Jul 2002 A1
20020095684 St. John et al. Jul 2002 A1
20020100063 Herigstad et al. Jul 2002 A1
20020104083 Hendricks et al. Aug 2002 A1
20020112240 Bacso et al. Aug 2002 A1
20020120498 Gordon et al. Aug 2002 A1
20020123928 Eldering et al. Sep 2002 A1
20020124182 Bacso et al. Sep 2002 A1
20020129378 Cloonan et al. Sep 2002 A1
20020144263 Eldering et al. Oct 2002 A1
20020147984 Tomsen et al. Oct 2002 A1
20020152393 Thoma et al. Oct 2002 A1
20020154655 Gummalla et al. Oct 2002 A1
20020163928 Rudnick et al. Nov 2002 A1
20020166119 Cristofalo Nov 2002 A1
20020174430 Ellis et al. Nov 2002 A1
20020178445 Eldering Nov 2002 A1
20020178447 Plotnick et al. Nov 2002 A1
20020184629 Sie et al. Dec 2002 A1
20020184634 Cooper Dec 2002 A1
20020184635 Istvan Dec 2002 A1
20030002862 Rodriguez et al. Jan 2003 A1
20030004810 Eldering Jan 2003 A1
20030005446 Jaff Jan 2003 A1
20030005453 Rodriguez et al. Jan 2003 A1
20030007516 Abramov et al. Jan 2003 A1
20030018977 McKenna Jan 2003 A1
20030020744 Ellis et al. Jan 2003 A1
20030030751 Lupulescu et al. Feb 2003 A1
20030033199 Coleman Feb 2003 A1
20030046704 Laksono et al. Mar 2003 A1
20030056217 Brooks Mar 2003 A1
20030061619 Giammaressi Mar 2003 A1
20030071117 Meade Apr 2003 A1
20030077067 Wu et al. Apr 2003 A1
20030093311 Knowlson May 2003 A1
20030093784 Dimitrova et al. May 2003 A1
20030093790 Logan et al. May 2003 A1
20030093792 Labeeb et al. May 2003 A1
20030101449 Bentolila et al. May 2003 A1
20030101451 Bentolila et al. May 2003 A1
20030101454 Ozer et al. May 2003 A1
20030110499 Knudson et al. Jun 2003 A1
20030110503 Perkes Jun 2003 A1
20030114162 Chheda et al. Jun 2003 A1
20030115601 Palazzo et al. Jun 2003 A1
20030115612 Mao et al. Jun 2003 A1
20030135513 Quinn et al. Jul 2003 A1
20030139980 Hamilton Jul 2003 A1
20030140351 Hoarty et al. Jul 2003 A1
20030145323 Hendricks et al. Jul 2003 A1
20030149975 Eldering et al. Aug 2003 A1
20030149990 Anttila et al. Aug 2003 A1
20030149993 Son et al. Aug 2003 A1
20030163739 Armington et al. Aug 2003 A1
20030172376 Coffin Sep 2003 A1
20030174838 Bremer Sep 2003 A1
20030179773 Mocek et al. Sep 2003 A1
20030192060 Levy Oct 2003 A1
20030204602 Hudson Oct 2003 A1
20030208767 Williamson et al. Nov 2003 A1
20030217365 Caputo Nov 2003 A1
20030220100 McElhatten Nov 2003 A1
20030221100 Russ et al. Nov 2003 A1
20030229681 Levitan Dec 2003 A1
20030237090 Boston et al. Dec 2003 A1
20040019691 Daymond et al. Jan 2004 A1
20040034873 Zenoni Feb 2004 A1
20040047599 Grzeczkowski Mar 2004 A1
20040060076 Song Mar 2004 A1
20040073915 Dureau Apr 2004 A1
20040078809 Drazin Apr 2004 A1
20040109569 Ellison et al. Jun 2004 A1
20040109672 Kim et al. Jun 2004 A1
20040117817 Kwon et al. Jun 2004 A1
20040133467 Siler Jul 2004 A1
20040133907 Rodriguez et al. Jul 2004 A1
20040138909 Mayer Jul 2004 A1
20040146006 Jackson Jul 2004 A1
20040148625 Eldering et al. Jul 2004 A1
20040163109 Kang et al. Aug 2004 A1
20040163111 Palazzo et al. Aug 2004 A1
20040177383 Martinolich et al. Sep 2004 A1
20040181811 Rakib Sep 2004 A1
20040186774 Lee Sep 2004 A1
20040187159 Gaydos et al. Sep 2004 A1
20040193609 Phan et al. Sep 2004 A1
20040194134 Gunatilake et al. Sep 2004 A1
20040199789 Shaw et al. Oct 2004 A1
20040230994 Urdang et al. Nov 2004 A1
20050007278 Anson et al. Jan 2005 A1
20050022237 Nomura Jan 2005 A1
20050027696 Swaminathan et al. Feb 2005 A1
20050028208 Ellis et al. Feb 2005 A1
20050034171 Benya Feb 2005 A1
20050034173 Hatanaka Feb 2005 A1
20050039205 Riedl Feb 2005 A1
20050047596 Suzuki Mar 2005 A1
20050055685 Maynard et al. Mar 2005 A1
20050060742 Riedl et al. Mar 2005 A1
20050060745 Riedl et al. Mar 2005 A1
20050066339 Thoen Mar 2005 A1
20050086334 Aaltonen et al. Apr 2005 A1
20050086691 Dudkiewicz et al. Apr 2005 A1
20050091173 Alve Apr 2005 A1
20050105396 Schybergson May 2005 A1
20050111844 Compton et al. May 2005 A1
20050114141 Grody May 2005 A1
20050114686 Ball et al. May 2005 A1
20050114900 Ladd et al. May 2005 A1
20050123001 Craven et al. Jun 2005 A1
20050125832 Jost et al. Jun 2005 A1
20050144632 Mears et al. Jun 2005 A1
20050144635 Boortz et al. Jun 2005 A1
20050168323 Lenoir et al. Aug 2005 A1
20050176444 Tanaka Aug 2005 A1
20050198686 Krause et al. Sep 2005 A1
20050210502 Flickinger et al. Sep 2005 A1
20050223409 Rautila et al. Oct 2005 A1
20050229209 Hildebolt et al. Oct 2005 A1
20050234998 Lesandrini et al. Oct 2005 A1
20050235318 Grauch et al. Oct 2005 A1
20050262542 Deweese et al. Nov 2005 A1
20050268107 Harris et al. Dec 2005 A1
20050273629 Abrams et al. Dec 2005 A1
20050273819 Knudson et al. Dec 2005 A1
20050276284 Krause et al. Dec 2005 A1
20050289588 Kinnear Dec 2005 A1
20050289618 Hardin Dec 2005 A1
20050289619 Melby Dec 2005 A1
20060004662 Nadalin et al. Jan 2006 A1
20060019702 Anttila et al. Jan 2006 A1
20060031883 Ellis et al. Feb 2006 A1
20060036488 Golan Feb 2006 A1
20060036750 Ladd et al. Feb 2006 A1
20060037060 Simms et al. Feb 2006 A1
20060080408 Istvan et al. Apr 2006 A1
20060117341 Park Jun 2006 A1
20060130107 Gonder et al. Jun 2006 A1
20060130113 Carlucci et al. Jun 2006 A1
20060154674 Landschaft et al. Jul 2006 A1
20060165197 Morita et al. Jul 2006 A1
20060171390 La Joie Aug 2006 A1
20060171423 Helms et al. Aug 2006 A1
20060190336 Pisaris-Henderson et al. Aug 2006 A1
20060197828 Zeng et al. Sep 2006 A1
20060218604 Riedl et al. Sep 2006 A1
20060218632 Corley et al. Sep 2006 A1
20060236131 Vauclair Oct 2006 A1
20060248555 Eldering Nov 2006 A1
20060253328 Kohli et al. Nov 2006 A1
20060253584 Dixon et al. Nov 2006 A1
20060253864 Easty Nov 2006 A1
20060259924 Boortz et al. Nov 2006 A1
20060277098 Chung Dec 2006 A1
20060277569 Smith Dec 2006 A1
20060288374 Ferris et al. Dec 2006 A1
20060294259 Matefi et al. Dec 2006 A1
20070022459 Gaebel et al. Jan 2007 A1
20070029379 Peyer Feb 2007 A1
20070033531 Marsh Feb 2007 A1
20070061023 Hoffberg et al. Mar 2007 A1
20070061197 Ramer et al. Mar 2007 A1
20070074258 Wood et al. Mar 2007 A1
20070076728 Rieger et al. Apr 2007 A1
20070089127 Flickinger et al. Apr 2007 A1
20070094691 Gazdzinski Apr 2007 A1
20070101370 Calderwood May 2007 A1
20070113243 Brey May 2007 A1
20070115389 McCarthy et al. May 2007 A1
20070118852 Calderwood May 2007 A1
20070150919 Morishita Jun 2007 A1
20070157242 Cordray et al. Jul 2007 A1
20070157262 Ramaswamy et al. Jul 2007 A1
20070180230 Cortez Aug 2007 A1
20070204310 Hua et al. Aug 2007 A1
20070217436 Markley et al. Sep 2007 A1
20070233857 Cheng et al. Oct 2007 A1
20070244760 Bodnar et al. Oct 2007 A1
20070266395 Lee et al. Nov 2007 A1
20070274537 Srinivasan Nov 2007 A1
20070276926 LaJoie et al. Nov 2007 A1
20070276928 Rhoads Nov 2007 A1
20070280298 Hearn et al. Dec 2007 A1
20070294178 Pinder et al. Dec 2007 A1
20080016526 Asmussen Jan 2008 A1
20080021836 Lao Jan 2008 A1
20080052157 Kadambi et al. Feb 2008 A1
20080092181 Britt Apr 2008 A1
20080101460 Rodriguez May 2008 A1
20080104634 Gajdos et al. May 2008 A1
20080109307 Ullah May 2008 A1
20080115169 Ellis et al. May 2008 A1
20080124056 Concotelli May 2008 A1
20080134274 Derrenberger et al. Jun 2008 A1
20080141317 Radloff et al. Jun 2008 A1
20080141353 Brown Jun 2008 A1
20080147497 Tischer Jun 2008 A1
20080155588 Roberts et al. Jun 2008 A1
20080155614 Cooper et al. Jun 2008 A1
20080163305 Johnson et al. Jul 2008 A1
20080170551 Zaks Jul 2008 A1
20080182591 Krikorian Jul 2008 A1
20080183705 Shivaji-Rao et al. Jul 2008 A1
20080192770 Burrows Aug 2008 A1
20080192820 Brooks et al. Aug 2008 A1
20080229354 Morris et al. Sep 2008 A1
20080244667 Osborne Oct 2008 A1
20080263578 Bayer et al. Oct 2008 A1
20080271068 Ou et al. Oct 2008 A1
20080273591 Brooks et al. Nov 2008 A1
20080306903 Larson et al. Dec 2008 A1
20080313671 Batrouny et al. Dec 2008 A1
20080313691 Cholas et al. Dec 2008 A1
20090025027 Craner Jan 2009 A1
20090025075 Chow et al. Jan 2009 A1
20090030802 Plotnick et al. Jan 2009 A1
20090064251 Savoor et al. Mar 2009 A1
20090086643 Kotrla et al. Apr 2009 A1
20090132346 Duggal et al. May 2009 A1
20090133048 Gibbs et al. May 2009 A1
20090150917 Huffman et al. Jun 2009 A1
20090170479 Jarenskog Jul 2009 A1
20090187939 Lajoie Jul 2009 A1
20090210899 Lawrence-Apfelbaum et al. Aug 2009 A1
20090216761 Raichelgauz Aug 2009 A1
20090244290 McKelvey et al. Oct 2009 A1
20090319379 Joao Dec 2009 A1
20090320059 Bolyukh Dec 2009 A1
20100005527 Jeon Jan 2010 A1
20100014496 Kalika et al. Jan 2010 A1
20100027560 Yang et al. Feb 2010 A1
20100070867 Lemmers Mar 2010 A1
20100081416 Cohen Apr 2010 A1
20100082983 Shah et al. Apr 2010 A1
20100115091 Park et al. May 2010 A1
20100122276 Chen May 2010 A1
20100122288 Minter et al. May 2010 A1
20100125658 Strasters May 2010 A1
20100150027 Atwal et al. Jun 2010 A1
20100151816 Besehanic et al. Jun 2010 A1
20100153544 Krassner Jun 2010 A1
20100159951 Shkedi Jun 2010 A1
20100161492 Harvey et al. Jun 2010 A1
20100175084 Ellis et al. Jul 2010 A1
20100175584 Kusaka et al. Jul 2010 A1
20100218231 Frink et al. Aug 2010 A1
20100251304 Donoghue et al. Sep 2010 A1
20100251305 Kimble et al. Sep 2010 A1
20100262488 Harrison et al. Oct 2010 A1
20100269131 Newberry et al. Oct 2010 A1
20100280641 Harkness et al. Nov 2010 A1
20100293165 Eldering Nov 2010 A1
20100309051 Moshfeghi Dec 2010 A1
20100313225 Cholas et al. Dec 2010 A1
20100313226 Cholas et al. Dec 2010 A1
20110015989 Tidwell et al. Jan 2011 A1
20110016479 Tidwell et al. Jan 2011 A1
20110016482 Tidwell et al. Jan 2011 A1
20110090898 Patel et al. Apr 2011 A1
20110093900 Patel et al. Apr 2011 A1
20110099017 Ure Apr 2011 A1
20110103374 Lajoie et al. May 2011 A1
20110107364 Lajoie et al. May 2011 A1
20110107379 Lajoie et al. May 2011 A1
20110107389 Chakarapani May 2011 A1
20110110515 Tidwell et al. May 2011 A1
20110112717 Resner May 2011 A1
20110138064 Rieger et al. Jun 2011 A1
20110163888 Goedde Jul 2011 A1
20110167440 Greenfield Jul 2011 A1
20110178880 Karaoguz et al. Jul 2011 A1
20110178943 Motahari et al. Jul 2011 A1
20110197070 Mizrah Aug 2011 A1
20110206136 Bekedam et al. Aug 2011 A1
20110225619 Kesireddy et al. Sep 2011 A1
20110231265 Brown et al. Sep 2011 A1
20110235577 Hintermeister et al. Sep 2011 A1
20110247029 Yarvis et al. Oct 2011 A1
20110264530 Santangelo et al. Oct 2011 A1
20110265116 Stern et al. Oct 2011 A1
20110286437 Austin et al. Nov 2011 A1
20110307339 Russell et al. Dec 2011 A1
20110317977 Harris Dec 2011 A1
20120005527 Engel et al. Jan 2012 A1
20120011269 Krikorian et al. Jan 2012 A1
20120023535 Brooks et al. Jan 2012 A1
20120030363 Conrad Feb 2012 A1
20120030716 Zhang et al. Feb 2012 A1
20120046049 Curtis et al. Feb 2012 A1
20120054785 Yang et al. Mar 2012 A1
20120079546 Kalidindi et al. Mar 2012 A1
20120084813 Dmitriev et al. Apr 2012 A1
20120110620 Kilar et al. May 2012 A1
20120115501 Zheng May 2012 A1
20120124606 Tidwell et al. May 2012 A1
20120151549 Kumar et al. Jun 2012 A1
20120159603 Queck Jun 2012 A1
20120167173 Nadalin et al. Jun 2012 A1
20120202447 Edge et al. Aug 2012 A1
20120222081 Schaefer et al. Aug 2012 A1
20120302259 Busch Nov 2012 A1
20120310762 Robbin Dec 2012 A1
20120324552 Padala Dec 2012 A1
20120330759 Aggarwal et al. Dec 2012 A1
20130045681 Dua Feb 2013 A1
20130046623 Moritz et al. Feb 2013 A1
20130060385 Leen et al. Mar 2013 A1
20130081097 Park et al. Mar 2013 A1
20130095848 Gold et al. Apr 2013 A1
20130100818 Qiu et al. Apr 2013 A1
20130227283 Williamson et al. Aug 2013 A1
20130227608 Evans et al. Aug 2013 A1
20130254787 Cox et al. Sep 2013 A1
20130275557 Myers Oct 2013 A1
20130325995 Ispas et al. Dec 2013 A1
20130347089 Bailey et al. Dec 2013 A1
20140020017 Stern et al. Jan 2014 A1
20140046624 Miettinen Feb 2014 A1
20140066098 Stern et al. Mar 2014 A1
20140129351 Ringdahl May 2014 A1
20140129352 Ringdahl May 2014 A1
20140150014 Aitken May 2014 A1
20140150019 Ma May 2014 A1
20140215506 Kalmes et al. Jul 2014 A1
20140282721 Kuncl et al. Sep 2014 A1
20140309868 Ricci Oct 2014 A1
20140359649 Cronk et al. Dec 2014 A1
20150019982 Petitt, Jr. Jan 2015 A1
20150032550 Shah Jan 2015 A1
20150058883 Tidwell et al. Feb 2015 A1
20150058909 Miller et al. Feb 2015 A1
20150094098 Stern Apr 2015 A1
20150103685 Butchko et al. Apr 2015 A1
20150106846 Chen et al. Apr 2015 A1
20150185993 Wheatley et al. Jul 2015 A1
20150189377 Wheatley et al. Jul 2015 A1
20150365833 Stafford et al. Dec 2015 A1
20160019103 Basra Jan 2016 A1
20160127185 McAllister May 2016 A1
20160127260 Gordon May 2016 A1
20160127440 Gordon May 2016 A1
20160135230 Swierczynski May 2016 A1
20160226922 Russell Aug 2016 A1
20170164378 Gunasekara Jun 2017 A1
20170164416 Yeddala et al. Jun 2017 A1
Foreign Referenced Citations (1)
Number Date Country
WO-0191474 Nov 2001 WO
Non-Patent Literature Citations (24)
Entry
Gomez, Conserving Transmission Power in Wireless Ad Hoc Networks, 2001, Network Protocols.
Miao , et al., “Distributed interference-aware energy-efficient power optimization,” IEEE Transactions on Wireless Communications, Apr. 2011, vol. 10 (4), pp. 1323-1333.
Cisco Intelligent Network Architecture for Digital Video—SCTE Cable-Tec Expo 2004 information page, Orange County Convention Center, Jun. 2004, 24 pages.
Griffith, et al.,Resource Planning and Bandwidth Allocation in Hybrid Fiber-Coax Residential Networks, National Institute of Standards and Technology (NIST), 10 pages, no date.
Kanouff, Communications Technology: Next-Generation Bandwidth Management—The Evolution of the Anything-to-Anywhere Network, 8 pages, Apr. 1, 2004.
Motorola DOCSIS Cable Module DCM 2000 specifications, 4 pages, no date.
OpenVision Session Resource Manager—Open Standards-Based Solution Optimizes Network Resources by Dynamically Assigning Bandwidth in the Delivery of Digital Services article, 2 pages, (copyright 2006), (http://www.imake.com/hopenvision).
OpenVision Session Resource Manager features and information, 2 pages, no date, (http://www.imake.com/hopenvision).
Deering et al., Internet Protocol, Version 6 (Ipv6) Specification, IETF RFC 2460 (Dec. 1998).
Lab—“Digital Video In-Stream Ad Format Guidelines,” 23 pages, released Jan. 8, 2016.
Lab—RTB Project—“Open RTB API Specification Version 2.4” (Final Draft) dated Mar. 2016, 75 pages.
Lab—RTB Project—“Open RTB Dynamic Native Ads API Specification Version 1”, 35 pages, dated Feb. 2015.
Lab—RTB Project—“Open RTB Dynamic Native Ads API Specification Version 1.1” dated Mar. 2016, 36 pages.
Lab—“Traffic Fraud: Best Practices for Reducing Risk to Exposure”, 12 pages, dated Jan. 30, 2014.
Lab “Open Direct API Specification Version 1.0”, 95 pages, finalized Jan. 2015.
Informal Standard, Document: id3v2.3, by: M. Nilsson, dated Feb. 3, 1999, 39 pages, http://id3.org/id3v2.3.0.
Internet Protocol DARPA Internet Program Protocol Specification, IETF RFC 791 (Sep. 1981).
JICWEBS “Traffic Fraud: Best Practices for Reducing Risk to Exposure”, 14 pages, Version 1, Issued Jun. 2015.
Open Cable Specification entitled “Enhanced TV Binary Interchange Format 1 0” 0C-SP-ETV-131F1.0-106-110128 dated Jan. 28, 2011, 408 pages.
SCTE Standards Document ANSI/SCTE 118-2 2007 entitled “Program-Specific Ad Insertion—Content Provider to Traffic Communication Applications Data Model,” 20 pages.
SCTE Standards Document ANSI/SCTE 130-1 2013 entitled “Digital Program Insertion—Advertising Systems Interfaces, Part 1—Advertising Systems Overview,” 20 pages.
SCTE Standards Document ANSI/SCTE 130-2 2014 entitled “Digital Program Insertion—Advertising Systems Interfaces, Part 2—Core Data Elements,” 78 pages.
Tandberg Television specification entitled “AdPoint.RTM. Advanced Advertising Platform” dated Mar. 2008, 2 pages.
UTF-32, IBM, retrieved from http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fnls%2Frbagsutf32.htm on Aug. 28, 2013.
Related Publications (1)
Number Date Country
20170308681 A1 Oct 2017 US