ADVERTISING DOWNLOAD VERIFICATION

Methods and systems are described for verifying that advertising content has been downloaded by a client. When a streaming client requests advertising content from an advertising server, the streaming client receives one or more verifiers from the advertising server. The streaming client sends information associated with the verifiers to a media server. The media server is configured to validate streaming of the advertising content to the streaming client based on the information associated with the verifiers.

DETAILED DESCRIPTION

Streaming clients that receive media content from a media server may be modified with software for preventing advertising content associated with the media content from being downloaded. For example, the streaming client may be modified such that the streaming client downloads short duration media from a non-advertising server in lieu of downloading advertising content from the designated advertising server. In order to prevent delivery of media content to streaming clients that are modified to avoid downloading advertising content, one or more advertising verifiers can be generated by an advertising server and sent to a streaming client when advertising content is sent to the streaming client. The streaming client can send information associated with the advertising verifiers to the media server. The media server can use the information received from the streaming client to verify that the streaming client downloaded advertising content from the ad server. The media server may prevent subsequent streaming of media content to the streaming client if the media server is unable to verify that the streaming client downloaded advertising content from the ad server. As used herein, the term “downloading” (such as downloading of advertising content by a streaming client) may indicate streaming (such as streaming of advertising content from the ad server to the streaming client). In some instances, the “advertising content” or “content” may include executable code or instructions that are otherwise interpreted in execution.

FIG. 1shows an illustrative system diagram100. Media content may be provided to streaming client102from media server104. The terms “client” and “streaming client” are used interchangeably herein.

Media content may be stored in media content database106. Media content database106may be stored on media server104or may be stored on one or more servers communicatively coupled to media server104. Media content can include video, audio, streaming text, and any other content that can be received over a period of time by streaming client102, such as live webcast content and stored media content. The terms “media content” and “media” are used interchangeably herein.

Advertising content may be provided to streaming client102from an ad server108. Advertising content may be stored in ad content database110. Ad content database110may be stored on ad server108or may be stored on one or more servers communicatively coupled to ad server108. Advertising content may include video, audio, advertising images and/or text overlaid on media content, or other content. Advertising content may be shown before, after, concurrently with, or interspersed within media content. Typically, media content is content that is requested by a user, for example, by using a user interface of streaming client102. Advertising content118may be content not requested by a user that is provided to streaming client102in association with the user-requested media content. The terms “advertising” and “ad” are used interchangeably herein.

Streaming client102may be a device configured to provide media playback capabilities. For example, streaming client102may be a personal computer; a mobile device such as a cellular phone, media player, tablet, laptop computer; or other device capable of playing streaming media. Streaming client102may execute code for playing back media, such as a standalone media playback application112or a browser-based media player114configured to run in an Internet browser116.

One or more of streaming client102, media server104, ad server108, media content database106, ad content database110can be located on the same device, such as a server computer. In some embodiments, streaming client102receives media content and advertising content via a network, such as network118. Network118may be a wide area network (WAN), local area network (LAN), the Internet, a cellular network, one or more other networks, or a combination thereof.

One or more cryptographic keys (e.g., a shared secret key or a public-private key pair) may be established between the ad server108and the media server104. In one embodiment, ad server108will hold the signing key (i.e., the private key of a public-private key pair) and media server104hold the verification key (i.e., the public key of a public-private key pair). For example, ad server108may generate a shared secret key or public-private key pair and send the shared secret key or public key to media server104. Ad server108may send a key to media server104before each streaming session (for example, in response to a request for a key received by ad server108from media server104each time a streaming session is initiated), before each time ad server108sends advertising content to streaming client102, or at another point in time prior to sending advertising content to streaming client102. In an embodiment, the ad server108may send the key using a secure protocol, e.g., sending the key with a certificate that may be used to authenticate the key.

When streaming client102receives advertising content from ad server108, streaming client102may also receive one or more ad verifiers from ad server108. Ad verifiers may be received by streaming client102before, after, or as part of the ad content. Ad verifiers may include information including one or more of an identifier for a particular streaming session, a timestamp, an identifier of a particular streaming client, information indicating a byte range of an ad stream, and a digital signature generated using a key stored by ad server108. The terms “ad verifier” and “verifier” are used interchangeably herein.

Streaming client102can transmit information associated with the ad verifiers to media server104. Media server104may apply the shared secret key or public key to the information received from streaming client102in order to verify that streaming client102received ad content streamed from ad server108.

FIG. 2shows an illustrative sequence diagram200indicating communications between an ad server, a media server, and a streaming client according to an embodiment. Streaming client102may request media content from media server104, as indicated at202. Media server104may respond to the request by streaming media content to streaming client102, as indicated at204. Media server104may signal to streaming client102that the streaming client will need to download advertising content, as indicated at206. In some embodiments, signaling for advertising206may occur prior to the request for media content202and the streaming of media content204. Signaling for advertising206occurs periodically or at predefined intervals during media content streaming204. In various embodiments, signaling for advertising206may be based on one or more of information contained in media content204, information sent independently of media content from media server104to streaming client102, or commands of an application (such as media playback application112or browser-based media player114) executed by streaming client102. In one embodiment, media server104may send code, such as a Javascript routine, to be executed by streaming client102for obtaining advertising content.

In response to the signal for advertising206, streaming client102may send a request for advertising content to ad server108, as indicated at208. Ad server108may respond to the request for ad content208by streaming ad content to streaming client102, as indicated at210. One or more ad verifiers may be included in the ad content stream. Alternatively, ad verifiers may be provided from ad server108to streaming client102before or after sending ad content. Streaming clients with ad-blocking modifications may not request ad content, bypassing208, or may respond to the signal for advertising206by requesting substitute content from a server that is not an advertising server.

In some embodiments, streaming client102may request media content after receiving ad content from ad server108, as indicated at212. Media server104may request information associated with the one or more ad verifiers that streaming client102received from ad server108, as indicated at214. Streaming client102may respond to the request214by sending information associated with the one or more ad verifiers to media server104, as indicated at216. The information associated with the one or more ad verifiers may include one or more of a signature, a hash of part or all of the advertising stream provided at210, a session identifier, a streaming client identifier, a timestamp, a cryptographic nonce, or combinations thereof (such as a concatenation of a timestamp, a nonce, and a streaming client identifier).

When media server104receives the information associated with the ad verifiers, media server104may use the information associated with the ad verifiers to validate streaming of advertising content to streaming client102, which was indicated at210above. If media server104determines that advertising content was downloaded by streaming client102, media server104may stream media content to streaming client102, as indicated at218. If media server104determines that advertising content was not downloaded by streaming client102, media server104may halt streaming media content to streaming client102.

FIG. 3shows illustrative components that may be included in an ad verifier300. Ad verifier300may include one or more of a session identifier302, a body specifier304, and a digital signature306. Ad verifier300may be generated by ad server108. Ad verifier300may be included in a file, such as a multimedia file having an International Organization for Standardization (ISO) Base Media File Format (BMFF) described in ISO/IEC 14496-12 or derived specifications (such as the 3GP file format described in 3GPP Technical Specification 26.244). ISO BMFF defines a structure for media files. A media file formatted using ISO BMFF may include one or more free space boxes. Free space boxes may contain information that is irrelevant to media playback. One or more ad verifiers may be stored in a free space box. In one embodiment, advertising content may be sent in a file formatted as defined by ISO BMFF and one or more ad verifiers may be stored in one or more free space boxes in the file.

An ad verifier300may be inserted at the beginning, end, and/or within an advertising stream. Ad verifiers300may be located periodically or at random or irregular intervals within the ad content. In some embodiments, ad verifiers associated with an advertising stream may be sent separately from the advertising stream. Ad verifiers may be transmitted via a platform-based communication channel, such as a browser. For example, ad verifiers may be sent to streaming client102and retrieved by media server104using a browser cookie. In another example, a locally stored object (LSO) as defined in the Adobe Flash media player platform may be used to communicate ad verifiers between the ad server108, streaming client102, and media server104. It will be recognized that other file formats and/or communication approaches may be used for sending ad verifiers300from ad server108to streaming client102. Streaming client102may send information associated with ad verifier300to media server104so that media server104can verify that streaming client102downloaded advertising content from ad server108. Information associated with ad verifier300is also referred to as “verification information” herein.

Session identifier302may include one or more of a timestamp308, a nonce310, and streaming client identifier312. In some embodiments, media server104may use timestamp308for validating information associated with an ad verifier300received from streaming client102. For example, media server104may require that information associated with an ad verifier include a timestamp that falls within a predefined window of time, such as 120 seconds, from a timestamp value. It will be recognized that other time window definitions can be used to define periods of time spanning seconds, minutes, hours, etc. If a timestamp provided by streaming client102to media server104does not fall within the time window, media server104may determine that the verification information received from streaming client102is not valid and may halt streaming of media content to streaming client102. For example, if an ad verifier300has a timestamp308of “Aug. 1, 2012 13:30:05” and the valid time window is 120 seconds, then verification information submitted to media server104between “Aug. 1, 2012 13:30:05” and “Aug. 1, 2012 13:32:05” may be successfully validated by media server104. In this manner, streaming client102may be prevented from using verification information generated for advertising content that was not recently downloaded by streaming client102(e.g., verification information generated by another streaming client at an earlier time).

In some embodiments, session identifier302may include a nonce310and a timestamp308. For example, a binary representation or text associated with a nonce may be concatenated a binary representation or text associated with session identifier302. Nonce310may be a random number or a pseduo-random number. Nonce310may be used to prevent replay attacks. In this manner, a different nonce310may be generated by ad server108for each ad verifier300to prevent streaming client102from using verification information generated by another streaming client or generated at another time. Verification information containing a valid nonce may be successfully validated by media client104. In some embodiments, the nonce may only be successfully validated if it is used within a valid time window relative to a timestamp.

A sequence number may be used in lieu of or in addition to a timestamp in session identifier302. The sequence number may be generated by ad server108. For example, ad server108may iterate the sequence number for each ad verifier sent in all ad streams or for each ad verifier sent in a particular ad stream. In this manner, each ad verifier received by streaming client102may be sequenced such that streaming client102is prevented from reusing verification information from different ad verifiers. Verification information containing a valid sequence number may be successfully validated by media client104.

Session identifier302may include a streaming client identifier312. The streaming client identifier can be any information usable to identify a streaming client102, such as IP address, a combination of IP address and port number, or other identifying information. A streaming client identifier312can be used to prevent verification information generated by another streaming client from being used by streaming client102for validation that advertising content has been downloaded. Verification information containing a correct streaming client identifier may be successfully validated by media client104.

Ad verifier300may include a body specifier304. In some embodiments, body specifier304includes byte range314. Byte range314can indicate one or more parts or all of the advertising content. For example, a byte range of 100-200 can indicate the data stored in bytes 100-200 of the advertising content. When a byte range314is specified in body specifier304, streaming client102may be required to perform a hash of the data indicated by the byte range and include the hash in the verification information to be provided to media server104. In some embodiments, body specifier304may be null. When body specifier is null, streaming client102may provide verification information that does not include a hash to media server104.

Ad verifier300may include digital signature306. Digital signature306may be generated by ad server108using a cryptographic key stored by ad server108. When body specifier304is null, digital signature306may be generated using information associated with session identifier302, such as timestamp308, nonce310, and/or streaming client identifier312. Digital signature may306may be produced by encrypting some or all of this information with the cryptographic key. When body specifier304indicates a byte range314, digital signature306may be generated by ad server108using information associated with session identifier302and/or a hash of the advertising content data associated with the indicated byte range. In a preferred embodiment, a shared secret key is used to produce a digital signature based on a hash of the advertising content data.

FIG. 4is an illustrative flow diagram for verifying that ad content has been downloaded by a streaming client, according to an embodiment. At operation402, ad server108and media server104establish a cryptographic key relationship. For example, ad server108may generate a shared secret key and send the shared secret key to media server104. Alternatively, ad server108may generate a public-private key pair and send the public key to media server104.

At operation404, media server104may receive a request for media content from streaming client102. At operation406, media server104may stream media content to streaming client102. At operation408, media server104may signal streaming client102to request advertising content from ad server108. In some embodiments, streaming client102may request and receive advertising content from ad server108prior to requesting and receiving media content form media server104(i.e., operations404-406can be optional operations).

Streaming client102can receive advertising content from ad server108. One or more ad verifiers300may be sent with the advertising content. Ad verifier300may include a digital signature306. Streaming client102may generate verification information based on the one or more ad verifiers300. Media server104may receive the verification information from streaming client102, as indicated at operation410.

Media server104may use the verification information received from streaming client102to validate streaming of the advertising content to the streaming client102(i.e., determining whether advertising content was downloaded by streaming client102), as indicated at operation412. For example, when verification information includes digital signature306, media server can use the key it received from ad server108at operation402to verify the digital signature. When verification information includes session identifier information302, media server104can check the session identifier information. At decision diamond414, it is determined by media server104whether the verification information received from streaming client102indicates that streaming client102downloaded advertising content from ad server108. If the download of advertising content is validated, media server104can continue to stream media (or can initiate streaming media) to streaming client102, as indicated at operation416. If the download of advertising content is not validated, media server104may discontinue streaming media to streaming client102, as indicated at operation418. In some embodiments, steps408through418may be repeated one or more times during delivery of a media stream.

Typically, if streaming client102is signaled by media server104to request advertising content and streaming client102subsequently fails to provide information associated with ad verifiers, media server104will discontinue streaming of media content to streaming client102.

When multiple ad verifiers are delivered to streaming client102from ad server108, media server104may prevent streaming of media content to streaming client102until all (or, in some embodiments, a subset) of the ad verifiers have been validated.

FIG. 5is an illustrative flow diagram for verifying that ad content has been downloaded by a streaming client102when a byte range314is specified in an ad verifier300. At operation502, ad server108and media server104establish a cryptographic key relationship. For example, ad server108may generate a shared secret key and send the shared secret key to media server104. Alternatively, ad server108may generate a public-private key pair and send the public key to media server104. In an embodiment, the ad server108may send the shared secret key using a secure protocol, e.g., sending the key with a certificate that may be used to authenticate the key.

At operation504, streaming client102may request media content from media server104. At operation506, streaming client102may receive media content from media server104. At operation508, streaming client102may request advertising content from ad server108. For example, streaming client102may receive a signal for ad from media server104as indicated at206. In some embodiments, streaming client102may request and receive advertising content from ad server104prior to requesting and receiving media content form media server104(i.e., operations504-506can be optional operations).

At operation510, streaming client102can receive advertising content from ad server108. One or more ad verifiers300may be sent with the ad content. Ad verifier300may include a digital signature306and a specified byte range314. Streaming client102may generate a hash based on the specified byte range314, as indicated at operation512. At operation514, streaming client102may send verification information including the hash and the digital signature306to media server104.

Media server104can apply the key it received from ad server108at operation502to the hash and compare the resulting value to digital signature306, as indicated at operation516. At decision diamond518, media server104validates streaming of advertising content to streaming client102by determining whether the comparison of operation516results in a match. If the value resulting from applying the media server key to the hash matches digital signature306, media server104can continue to stream media (or can initiate streaming media) to streaming client102, as indicated at operation520. If the resulting value does not match digital signature306, media server104may discontinue streaming media to streaming client102, as indicated at operation522. In some embodiments, steps508through522may be repeated one or more times during delivery of a media stream.

FIG. 6is an illustrative flow diagram for verifying that advertising content has been downloaded by a streaming client102with a browser-based media player114. At operation602, ad server108and media server104establish a cryptographic key relationship. For example, ad server108may generate a shared secret key and send the shared secret key to media server104. Alternatively, ad server108may generate a public-private key pair and send the public key to media server104. In an embodiment, the ad server108may send the shared secret key using a secure protocol, e.g., sending the key with a certificate that may be used to authenticate the key.

At operation604, streaming client102may request media content from media server104. At operation606, streaming client102may receive media content from media server104. At operation608, streaming client102may request advertising content from ad server108. For example, streaming client102may receive a signal for ad from media server104as indicated at206. In some embodiments, streaming client102may request and receive ad content from ad server104prior to requesting and receiving media content form media server104(i.e., operations604-606can be optional operations).

At operation610, streaming client102can receive ad content from ad server108. One or more ad verifiers300may be sent to streaming client102in a browser cookie or an anonymous code. The browser cookie or the anonymous code may include a digital signature. Media server104may retrieve the one or more ad verifiers300from the browser cookie or the anonymous code, as indicated at612. For example, streaming client102may send the browser cookie or the anonymous code to media server104, or media server104may otherwise obtain the browser cookie or the anonymous code from streaming client102. Media server102may parse the browser cookie or the anonymous code to obtain the ad verifiers300.

Media server104can use the key it received from ad server108at operation602to verify a digital signature obtained from an ad verifier in a browser cookie or an anonymous code, as indicated at operation616. At decision diamond618, media server104validates streaming of advertising content to streaming client102by determining whether the digital signature can be verified. If the digital signature is verified, media server104can continue to stream media (or can initiate streaming media) to streaming client102, as indicated at operation620. If the digital signature is not verified, media server104may discontinue streaming media to streaming client102, as indicated at operation622.

In some embodiments, media playback on streaming client102may be performed using a media playback application such as the Adobe Flash media player platform. The Adobe Flash media player may run in browser116or as a standalone application, such as media playback application112. Adobe Flash uses local shared objects (LSOs) to store data associated with a website or with the Adobe Flash application. For example, LSOs may be stored to a storage medium of streaming client102and obtained by media server104. Ad verifiers may be sent to a client and retrieved from a client according to the flow described with reference toFIG. 5, using LSOs in lieu of browser cookies. In this way, if a user has configured browser116to block cookies, the LSO may still be used to deliver ad verifiers.

FIG. 7is an illustrative block diagram of a computer system that may be used to implement any of the entities or components described above (e.g., client system102, media server104, and advertising server108). The computer system may be implemented as a combination of hardware and software components, according to various embodiments. The computer system may comprise a set of instructions that can be executed to cause the system to perform any one or more of the methods discussed herein. The computer system may be realized as a specific machine in the form of a computer. The system may be a server computer, a personal computer (PC), or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system. Further, while only a single system is illustrated, the term “system” shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The computer system may include the processor702(e.g., a central processing unit (CPU)), a memory704which may store program code during execution, and non-volatile storage706, all of which communicate with each other via a bus700. The system may further include a video display unit708(e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)). The system also may include an alphanumeric input device710(e.g., a keyboard), and a network interface device712for receiving content source and delivering content store.

The non-volatile storage unit706may include a machine-readable medium on which may be stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, within the memory704and/or within the processor702during execution thereof by the system, with the memory704and the ingestion processor702also constituting machine-readable media.

Further embodiments can be envisioned to one of ordinary skill in the art after reading this disclosure. In other embodiments, combinations or sub-combinations of the above disclosed invention can be advantageously made. The example arrangements of components are shown for purposes of illustration and it should be understood that combinations, additions, re-arrangements, and the like are contemplated in alternative embodiments of the present invention. Thus, while the invention has been described with respect to exemplary embodiments, one skilled in the art will recognize that numerous modifications are possible.

For example, the processes described herein may be implemented using hardware components, software components, and/or any combination thereof. In some cases, the software components can be provided on tangible, non-transitory media for execution on hardware that is provided with the media or is separate from the media. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims and that the invention is intended to cover all modifications and equivalents within the scope of the following claims.