Video advertising has been around for many decades in the form of commercial television (“TV”) broadcasting. A TV video advertisement (a/k/a “commercial” or “ad”) is a segment of television programming produced and paid for by an organization to convey a message, e.g. the marketing of a product or service. Advertising revenue typically provides a significant portion of the funding for many privately owned television networks.
The demographics of the viewers of television programming, as measured by such companies as Nielsen Media Research, are often used as metrics for television advertisement placement. For example, if the demographics for a television show indicates that a significant percentage of the viewers are teenagers, advertisements can be selected that would market products or services that would likely be of interest to teenagers. Nonetheless, viewers tend to be significantly diverse and generally only relatively small segment of the audience viewing a commercial will have any interest in the good or service being presented.
Electronic commerce, often known as “e-commerce,” includes the buying and selling of products or services over electronic systems such as the Internet. The amount of trade conducted electronically has grown immensely with the widespread adoption of Internet technology. One particularly explosive area of growth in c-commerce is in the field of advertising and, in particular, video advertising on the Internet.
With the advent of hybrid televisions (also known as “Smart TV” and “Connected TV”) the opportunity to mix traditional television advertising with Internet delivered advertising has arisen. While the definitions for Smart TV can vary, it generally refers to the integration of the Internet and Web 2.0 features into modern television sets and set-top boxes, as well as the technological convergence between computers and such television sets and set-top boxes. Smart TV tends to have a much higher focus on online interactive media, Internet TV, on-demand streaming media and software applications (“apps”) and less of a focus on traditional broadcast media than was the case with previous generations of television sets and set-top boxes.
A Smart TV typically includes one or more processors (“CPUs”) which execute program instructions to perform the Smart TV functions. These program instructions (often referred to as “firmware”) are typically stored in a non-volatile semiconductor memory such as a ROM, EPROM, EEPROM, etc. The CPU and firmware form a part of what is often referred to as an “embedded system” which is used to digitally control various aspects of the Smart TV operation.
Despite the merging of television and Internet technologies, television advertising remains substantially as it has been for decades. That is, television advertising is a “lean back” experience, generally without user interaction, as opposed to Internet advertising which tends to be a “lean forward” experience, where the user interacts with the advertisement. Furthermore, valuable demographic information that could have been derived from Smart Television usage has not been applied to video advertisement delivery over the Internet.
It has become increasingly common for several hardware platforms (“devices”) to be accessed concurrently. For example, it is not uncommon for viewers to be watching television while using another device such as a laptop computer, tablet computer, or smart phone to browse the web or check email. However, such devices tend to operate independently thereby losing the synergies of device and cooperative network interactions.
These and other limitations of the prior art will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing.
In an embodiment, set forth by way of example and not limitation, a non-volatile integrated circuit digital memory storing binary code segments includes client code segments, board support package (BSP) code segments, player support package (PSP) code segments, and application support package (ASP) code segments. In some example embodiment the client code segments, the BSP code segments, the PSP code segments and the ASP code segments are stored on one or more integrated circuit device.
In a further non-limiting example, the client code segments include PSP API code segments and BSP API code segments. In certain example embodiments, at least portions of the client code segments and the ASP code segments are accessible by an application executing on a digital processor. In further example embodiments, at least portions the BSP code segments and the PSP code segments are referenced by the client code segments.
In a further embodiment, set forth by way of example and not limitation, a video display apparatus includes a processor, non-volatile memory coupled to the processor storing binary code segments, an Internet interface coupled to the processor, and a video display coupled to the processor capable of displaying an advertisement received via the Internet. In this example, the binary code segments include client code segments, board support package (BSP) code segments, player support package (PSP) code segments, application support package (ASP) code segments and application code capable of interacting with the client code segments and the ASP code segments.
In a still further embodiment, set forth by way of example and not limitation, a multi-platform video advertising system includes a first video display device having a first firmware module including code segments facilitating communication over the Internet, a second video display device having a second firmware module including code segments facilitating communication over the Internet, and a video advertiser server system coupled to the Internet capable of communicating with the first video display device and the second video display device. The video advertising system is configured to determine whether the first video display device and the second video display device are related by a concurrent use in this non-limiting example. If so, the example video advertising system delivers a video advertisement to at least one of the first video display device and the second video display device using demographics associated with both the first video display device and the second video display device. The first video display device and the second video display device are capable of inter-device communication via, for example, the Internet, a wired connection or a wireless connection in another non-limiting example. In the case of Internet inter-device communication a facilitating web server may be employed.
These and other embodiments and other features disclosed herein will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing.
Several example embodiments will now be described with reference to the drawings, wherein like components are provided with like reference numerals. The example embodiments are intended to illustrate, not limit, concepts disclosed herein. The drawings include the following figures:
As used herein, “YuMe” is used as an arbitrary label to aid in the understanding of the various embodiments, and is not to be an implication that the product, process, article or composition with which it is associated must be derived from YuMe, Inc., a Delaware Corporation, or any other particular entity. Furthermore, use of YuMe herein as an adjective or adverb does not act as a limitation with respect to any element or step disclosed herein. YUME® is a registered trademark of YuMe, Inc. for advertising services in International Class 035.
The hardware platform 12 includes, by way of non-limiting examples, electronics capable of displaying video advertisements on a video display or “screen” including digital processor(s) capable of executing code segments to implement various processes (embodied, for example, as firmware or software) as described herein. Some of these processes include, by way of non-limiting example, client controller processes 16, YuMe Client Library processes 18, and player processes 20. As will be discussed subsequently, the YuMe Client Library will be sometimes referred to as the YuMe embedded SDK.
As will be appreciated by those of skill in the art, the hardware 44 may be of the type illustrated in
Application 48, in this non-limiting example, can provide the basic functionality of the video display apparatus 12′. For example, it can digitally process and develop the video for display on a screen of the video display apparatus 12′. In this non-limiting example, Application 48 has bi-directional links with Operating System 46, ASP 54, and PSP 56.
YuMe Compiled Client 50, in this non-limiting example, forms a part of YuMe Client Library 18 of
BSP 52 serves as an interface between the YuMe Compiled Client 50 and Operating System 46. ASP 54 serves as an interface between YuMe Compiled Client 50 and Application 48. PSP 56 serves as an interface between YuMe Compiled Client 50 and Player 58 as well as Application 48 and Player 58. As will also be discussed subsequently, this architecture provides hardware, operating system, application and player independence for the YuMe Compiled Client 50. ASP 54 provides application support for Application 54, as will also be discussed subsequently.
As will be appreciated by those of skill in the art, there are many practical applications for embedded applications such example Application 48. For example, the embedded applications can run in televisions, Blu-ray players, table computers, cellular telephones, etc. By “embedded application” it is meant that the application, comprising code segments, becomes, essentially part of the hardware of the device and is usually stored in non-volatile integrated circuit memory such as in a ROM, EPROM, EEPROM, etc. When code segments are stored in non-volatile integrated circuit memory, it is often referred to as “firmware” or “embedded software.” As used herein, the generic term “software” may include code segments stored in any media and, therefore, may at times refer to firmware or embedded software.
The YuMe Compiled Client 50 is typically provided as a binary file, i.e. it is typically provided to a manufacturer after it has been compiled by the supplier (YuMe in this example). The code segments represented by the binary file comprise, in this non-limiting example, at least a part of a “library” that provides resources and functionality to the Application 58. The YuMe Compiled Client 50 is customized by the supplier depending upon the type of video display apparatus.
In contrast, the BSP 52 and the PSP 56 may be provided as source code so that the manufacture can customize them prior to compilation and storage as firmware for the video display apparatus. This provides the manufacture with the freedom of changing its hardware, its operating system or its player without having to obtain a modified YuMe Compiled Client 50 from the supplier. This provides “platform independence” for the YuMe Complied Client 50, meaning that is can run on any hardware platform that conforms to its APIs. The customization of the BSP 52 and PSP 56, as well as the additional APIs provided by the ASP 54, are accomplished by a Software Developer's Kit (SDK) provided by YuMe. Since the resulting modified firmware is “embedded” into the devices' system, the resulting YuMe Client Library is also referred to herein as the “YuMe embedded SDK” or simply “embedded SDK.”
There are many advantages to the hardware and software platform independence of the YuMe Compiled Client 50. For one, it allows manufactures to change their hardware at will for cost or availability considerations. Also, it allows manufactures to change their players or their operating system, should they so desire. For example, the player can be changed from Flash to QuickTime or to a proprietary player of the manufacturer. Still further, the Application 48 can change (e.g. with the assistance of ASP 54 which can provide additions APIs for the application) without the need to change the YuMe Complied Client. Therefore, the architecture implementing the YuMe Compiled Client as described herein and as set forth by way of example in
Publisher Client Interfaces.
The YuMeSDKContainer, the YuMePSPComponent and the YuMeBSPComponent interface are implemented by the Publisher client. These three interfaces are used by the YuMeSDKComponent and the YuMePSPContainer to access publisher functions.
The YuMeSDKContainer interface allows the YuMeSDKComponent to:
YuMe Client Interfaces
The YuMeSDKComponent interface allows the Publisher Client to:
Initialize the YuMe SDK.
Manage ad context(s)
Enable/disable ad caching of ad assets
Initiate the fetching of ads
Initiate the playback of a fetched ad
Initiate a non-pre-fetched ad request and ad playback sequence
□Initiate a stop ad request
Access flow control features
The YuMePSPContainer allows the YuMePSPComponent implemented by the Publisher client to:
indicate when video playback has finished
indicate when a click has occurred on the video or on a customization
inform the YuMPSPContainer of ad progress via TimelineEvents.
An example video display apparatus 12″ is illustrated in
Since the YuMe Client Library is embedded as firmware in the Smart TV, in this example, it becomes an extension to, and part of, the application running on the Smart TV. As such, it has full access to all aspects of the operation of the Smart TV, from the hardware to the software. As such, the YuMe Client Library can obtain finely detailed demographic and usage information concerning the hardware of which it forms a part.
Continuing with this example, when the Smart TV with YuMe Client Library is powered up, the embedded SDK in the Smart TV's code begins to execute. Any advertising experience outside of the scope of the standard application of the Smart TV is handled by the embedded SDK. For example, the player can be “skinned” with an advertisement related to the context and/or demographics of the presumed viewer(s). The embedded SDK can also opportunistically use idle time, e.g. when an app is being downloaded, to download and cache video advertisements.
The embedded SDK is advantageous in that it is integrated at the device level and can monitor the entire user experience. For example, cross-application data can be used. Also, viewing history, Internet browsing, or social media interaction can be used to derive preference data and/or viewer demographics. This data can be communicated to advertising servers via the Internet so that appropriate video advertisements can be selected for delivery to the device (the Smart TV in this example).
For example, if the Smart TV is being used to view a movie at the Netflix® website, the embedded SDK can monitor the category of movie and make certain assumptions about the viewer. For example, if the movie is a travel documentary, it can be assumed that the view is interested in travel, and an appropriate video advertisement might for luggage. This may be further reinforced if the view watches the travel channel on television, or orders a TV app related to travel.
Since certain devices, such as Smart TV's, may be used by multiple individuals, the embedded SDK, and the advertising server(s) with which it communicates, can attempt to determine which users, or groups of users, are using the Smart TV at a particular time. Video advertisements can then be selected as appropriate to the viewing audience.
If operation 82 determines that the assets are not to be cached, an “ad” is requested from an “ad server” in an operation 86. If no ad is returned (i.e. a “null” is the result of the request), the system is informed that an ad is not available in an operation 90 and the process 72 ends at 92. However, if an ad is returned, it is played in an operation 94. Operation 96 tracks the parameters of the play (e.g. if it is played all the way through) and an ad completion signal is provided by operation 98 after the ad is done playing.
It is not un-common for a user (“viewer”) to be accessing several hardware platforms (devices) concurrently. For example, a user may be watching or interacting with Smart TV 130 at the same time that he is using a tablet computer 132. Since, in this example, both devices are provided with the YuMe embedded SDK. C, there is the opportunity to derive additional usage and demographic information concerning the concurrent user and to provide the user with targeted video advertisements.
As seen in the non-limiting example of
A video advertiser server system can be coupled to the Internet to communicate with the Smart TV 130 and the Tablet Computer 132 via their respective embedded SDKs. In a further non-limiting example, the video advertising server system is configured to determine whether the Smart TV 130 and the Tablet Computer 132 are related by their concurrent use. If the two devices are considered to be related (e.g. it is deduced that the same user is using both devices simultaneously) the video advertising system can deliver a video advertisement to either or both of the devices using usage and demographic information derived from both devices.
In a further non-limiting example, the devices are capable of inter-device communication, such as via the Internet, by a hardwire connection 140 as illustrated between Smart TV 130 and DVR 134, and/or wirelessly such as by WiFi or Bluetooth. Other forms of communication are also possible, such as audio or infrared. For example, the tablet computer 132 can use a microphone to monitor audio from the Smart TV 130 which is used to determine that the two devices are “related”, i.e. they are in the same room and exposed to the same audio signals. In another example, infrared (I/R) signals can be used to communicate between devices that are in line-of-sight of each other.
In another non-limiting example, the Tablet Computer 132 and the Smart TV 130 both communicate over the Internet with a web server (not shown in
Although various embodiments have been described using specific terms and devices, such description is for illustrative purposes only. The words used are words of description rather than of limitation. It is to be understood that changes and variations may be made by those of ordinary skill in the art without departing from the spirit or the scope of any embodiments described herein. In addition, it should be understood that aspects of various other embodiments may be interchanged either in whole or in part. It is therefore intended that the claims herein and hereafter presented be interpreted in accordance with their true spirit and scope and without limitation or estoppel.
This application claims the benefit of U.S. Patent Application No. 61/661,769, filed on Jun. 19, 2012, which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61661769 | Jun 2012 | US |