DISCOVERY AND ANALYTICS FOR EPISODIC DOWNLOADED MEDIA

Abstract

Matching advertising information to media content/user combinations in which information and content are delivered to a user over a network is disclosed. Content providers and advertisers may find out about the offerings of one another as well as user profiles and preferences thereby facilitating agreement of ads with content and users. Viral syndication is also facilitated by allowing the user to share downloaded media with friends and associates. Users may bookmark, share, and/or request/find more content with similarities to the downloaded content with various analytics being reported with respect to the same.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation and claims the priority benefit of U.S. patent application Ser. No. 14/315,694 filed Jun. 26, 2014, issuing as U.S. Pat. No. 9,525,902, which is a continuation and claims the priority benefit of U.S. patent application Ser. No. 12/370,531 filed Feb. 12, 2009, now U.S. Pat. No. 8,769,558, which claims the priority benefit of U.S. provisional application 61/028,185 filed Feb. 12, 2008, the disclosures of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to subscription-based reception of information over a computer network. More specifically, the present invention relates to the ‘podcasting’ of media.

Description of the Related Art

Podcasting involves syndicated distribution of multimedia content files over a network, typically the Internet. Podcasts may be played back on mobile devices or personal computers. Ordinarily, these content files contain audio or video but may also contain images, text, or other file types such as Portable Document Format (PDF).

Syndicated distribution of content is a format used to associate computer readable files that are available for delivery over a network. The syndication format is also used to provide users with information concerning the subject matter or content of files available for download. Based upon information provided through syndicated distribution, a user may decide to subscribe to delivery of one or more files. Syndication format-aware computer programs can, as a result of the subscription, automatically determine what files need to be downloaded to a subscribing user and then automatically download such files as they become available.

A feed is an association amongst files specified in accordance with a syndication format. A feed is generally used to associate files according to criteria specified by a publisher of the content. Files associated with a feed, for example, may represent episodes of a program in a manner similar to episodes of a television or radio program (i.e., episodic media).

A feed may include a list of Uniform Resource Locators (URLs) by which episodes of a show may be accessed over the Internet. A content provider may post a feed on a web server. This location (i.e., the web server) may be referred to as the feed Uniform Resource Identifier (URI) or feed URL. A feed is ordinarily updated each time a new episodic media (e.g., a new episode or media file) is published and made available. Alternatively, a feed may be associated with files based upon more arbitrary criteria such as files corresponding to the favorite songs of a particular blogger.

The Real Simple Syndication (RSS) and Atom formats are two examples of popular feed formats. The RSS format is an example of a simple Extensible Markup Language (XML) based format that allows users to subscribe to content available for download from network sites such as websites on the Internet. An RSS feed includes an association of files using the RSS format. An Atom feed, in turn, operates in a fashion similar to that of the RSS format and includes an association of files using the Atom format.

A computer program known as an aggregator, which may sometimes be referred to as a ‘podcatcher’ or podcast receiver, is used to subscribe to and manage subscriptions to feeds. Upon execution of the aggregator program, application, or module by a processor at a computing device, the aggregator monitors a set of feeds for a user. The aggregator downloads file updates (e.g., new episodes) at a specified interval, for example, every two hours to the extent file updates are available. A downloaded file, such as an episode of a television show, can then be played, replayed, and/or archived.

RSS, as noted above, is an example of an XML-based feed format that allows users to subscribe to content provided by their favorite websites. Using RSS, a webmaster can host content in a standard file format such as mp4 or mp3. The content can then be consumed and organized through RSS-aware software such as the aforementioned aggregator application.

In accordance with the RSS 2.0 standard, the web address of a file such as a media file may be contained in an enclosure tag of an item in an XML file. In a similar regard, two constituent elements of a typical RSS feed are the channel element and the item element. Both the channel element and the item element may include a variety of sub-elements; the item element is, in many instances, a sub-element of the channel element. A channel may contain any number of items. An item may be complete in and of itself as inclusion of elements in an item are optional. The following list exemplifies some RSS channel elements with a brief description and example of each element.

TABLE 1
Element	Description	Example
Title	The title of the item.	Excellent New Song
Link	The URL of the item.	http://publication.com/item.
		2006/10/18EAF.html
Descrip-	Brief description	The Excellent New Song was of
tion		the item released to critical
		acclaim.
Enclosure	Description of an	Has three required attributes. url
	object attached to	indicating where the enclosure is
	the item.	located, length indicating size in
		bytes, and type indicates file type
		is, e.g. standard MIME type.
		<enclosure
		url = “http://www.videoname.com/
		mp4s/firstsong.mp4” length =
		“13217840” type = “video/mpeg” I>
Guid	Globally unique	<guid>http://arbitraiy.server.com/
	identifier, a string that	weblogItem5050</guid>
	uniquely identifies the
	item. When present, an
	aggregator may choose
	to use this string to
	determine if an item is
	new.
Source	RSS channel where the	<source
	item came from. (The	url = “http://www.musicreview.org/
	purpose of this	links2.xml”>moviereview's
	element is to propagate	location </source>
	credit for links)
Dest	Pointer to location of	<dest url = http://
	analytics engine. (the	www.myanalytics.com/ma.js
	purpose of this	</dest>
	element is to enable
	publishers to track
	actual usage of
	their downloadable
	media)

Podcasting provides a superior paradigm for delivery of information over computer networks. As podcasting has become an increasingly established format for the delivery of audio and video content over the Internet, podcasting has likewise created the need for new mechanisms that operate to the mutual benefit of content owners and consumers. An example of such a need and one that remains unmet by the current state of the art is media metric discovery and reporting.

When a video is played online using a web browser, media usage is measured on the connected web server and within the browser embedded media player. In one example involving the Flash media player, Javascript code embedded within the web page is typically in communication with an online analytics engine such as Google Analytics.

Podcast media, however, is typically downloaded for time-shifted playback and off-line consumption. In these instances, a podcast video might be played using a standalone media player such as iTunes®, which does not typically support the embedding of Javascript along with the media. iTunes®, too, does not allow for playback measurements to be connected to an online analytics engine.

The growing popularity of podcasting has created a need to make downloaded media consumption more easily measurable for content owners and to create a corresponding set of consumer features around seamless sharing and discovery of podcasts.

SUMMARY OF THE PRESENTLY CLAIMED INVENTION

Systems and methods for discovery and analysis of episodic media.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for sharing content amongst users with disparate means of consumption including devices all the while capturing usage logs for analytics and reporting.

FIG. 2 illustrates a user device including a plug-in for ingesting content and feeds and generating data logs for analytics and reporting systems.

FIG. 3A illustrates an interface to add an RSS content subscription.

FIG. 3B illustrates a graphical user interface (GUI) for a registration profile gathering server.

FIG. 4 illustrates a user and usage information gathering system.

FIG. 5 illustrates a system to deliver RSS subscription content to a user

FIG. 6 illustrates a modular architecture coupling a user device plug-in to analytics, distribution, media, and campaign management systems.

FIG. 7 illustrates an interface for invoking the sharing of downloadable media.

FIG. 8A illustrates a three-button-companion graphical user interface to a user, specifically a highlighted “more” function.

FIG. 8B illustrates a method for operation of a three button companion, specifically the “more” function.

FIG. 9A illustrates a three-button-companion graphical user interface, specifically a highlighted “share” button.

FIG. 9B illustrates the operation of a “share” function in order to email a video from within a standalone media player.

FIG. 9C illustrates an email message received by a recipient of the sharing action.

FIG. 10 illustrates a three-button-companion graphical user interface to the user, specifically a highlighted “bookmark” button.

FIG. 11 illustrates an instance of an online video player embedded in a web browser, where the player allows the user to further share or subscribe to the video, in addition to playing the video.

DETAILED DESCRIPTION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Embodiments of the present invention concern a system and method for matching selected information, such as advertising information, to media content/user combinations in which information and content are delivered to a user over a network. Such embodiments may facilitate an online marketplace in which providers of media content and ad providers match ads with content and with online users who receive or subscribe to receive the content. The online marketplace may provide a venue in which content providers and advertisers can find out about the offerings of one another user profiles and preferences thereby facilitating agreement of ads with content and users.

Content providers provide media content, which may comprise sound, motion pictures, or a combination of both. A motion picture may represent real-life images or computer generated images such as video game environment. Media content may comprise music, news reports, talk shows, weather reports, traffic reports, video dips, and radio/TV like programs, which may be referred to as episodic media.

Media content may be organized into periodically updated content channels. A talk show channel, for example, may be updated with the latest interview. A weather channel may be updated with a new weather report. Content providers may use a network such as the Internet to designate criteria for associating their content with ads.

Computer Code Table A, which appears prior to the claims, identifies computer program code that may be used in the implementation of some embodiments of the present invention. The “Get Podcast” code comprises automatically generated JavaScript that can be attached to a content provider's web site to provide a link that permits visitors to the content provider's web site to easily sign up for the content subscription service, and install media player plug-in software that enhances discovery and sharing of downloaded subscription media.

FIG. 1 illustrates a system 100 for sharing content amongst users with disparate means of consumption including devices all the while capturing usage logs for analytics and reporting. An advertiser 101 feeds the system 100 with advertisement media content and campaign rules governing distribution of that content. Publisher 102 feeds the system 100 with information and/or media content, which may include episodic media (e.g., video clips, series of interviews, and other multimedia content) along with associated metadata.

Central Service Provider 105 matches ad media with content media. Matching of content media from publisher 102 may be matched with advertisement content from advertiser 101 based on the campaign rules provided by advertiser 101. For example, an advertiser may desire to have their advertisement content (e.g., for a sporting goods store) inserted only in the context of sports related content (e.g., a baseball game). The Central Service Provider 105 inserts the advertising media file within the content media file to create a newly modified, ad-infused media content file. Such insertion process may require re-encoding (e.g., transcoding) the advertising file, the content file, or both the advertising and content file to a uniform matching profile. Central Service Provider 105 may be a single operating entity or a loose affiliation of or wholly unaffiliated group of computing devices and/or software applications offering ad matching and related services.

Once a uniform matching profile is created, the content file is split into two parts: Part I and Part II. The split occurs at the location where the advertisement is to be inserted. For example, a content file may be split 1 minute from the start of a video that is 30 minutes long. Part I is now 1 minute long whereas Part II is 29 minutes in length. The end of Part I of the content file is then stitched to the beginning of the advertisement file and Part II of the content file is stitched to the end of the advertisement file thereby creating the ad-infused content file. Any number of ads can be inserted into any number of locations within a content file. As such, a content file may be split into any number of parts or segments.

Several variants of the modified content file may be created thereby addressing different types of content. For example, sporting good advertisements may be ‘stitched’ into football content whereas feminine product advertisements may be introduced into women oriented content.

Other variants may also be created through a similar re-encoding process to address compatibility for different types of devices. For example, a smaller phone screen may require a different encoding format than a file formatted for a personal computer screen. The modified content file may then be made available for delivery on a content hosting server at the Central Service Provider 105.

Modified content downloaded from a hosting server at Central Service Provider 105 may be consumed by a variety of devices with any variety of device settings. For example, content may be consumed at a personal computer (140) by a user utilizing a web browser to visit a website through entry of a URL and selecting a ‘play button’ in an embedded web media player. The user may then immediately start watching the video content file stored on a content hosting server.

Another user, however, may manually or automatically download a version of this same video file to a standalone media player (130). An example of such a standalone player is the podcast application software found in iTunes®. The user may also watch the video at a later time by downloading the file in a format for a particular mobile media device (150).

Still other users may watch content through a web-based media player embedded in a social networking site (160) such as MySpace. The social network site 160 may not actually host the content notwithstanding the fact that the content may be viewed at the site. For example, the actual host of the content may be YouTube. MySpace may operate as a portal that embeds content otherwise hosted on a YouTube server. For example, a designer of the social network site portal may use an embedded source call as follows, which not only retrieves the content from a server at the Central Service Provider 105 but also calls for the content to be rendered in a Flash media player:

• • <embed src=“http://www.youtube.com/v/B2qo2bV1ORc&h1=en&fs=1”
  • type=“application/x-shockwave-flash” allowscriptaccess=“always”
  • allowfullscreen=“true” width=“480” height=“295”></embed>

But for the presently disclosed system 100, this fragmentation of audiences and media consumption behavior might otherwise be problematic for publishers 102 and advertisers 101 who each desire to seamlessly reach audiences of scale without having to deal with the intricacies and peculiarities of each platform. Such peculiarities, for example could include video formats and encoding resolution. The system 100 of FIG. 1 addresses this problem by automatically encoding and transcoding publisher 102 and advertiser 101 content such that it is compatible with different platforms.

Further illustrating this disparity amongst users and means of content consumption- and thus further highlighting the benefits of the present invention-a user operating with standalone media player 130 might share a video via email 131. The recipient of the email 131 may watch the video in a web media player 140 at, for example, a website operated by the content owner. Some recipients of the email 131 could decide to download 141 the video to their standalone media player 130 while others might decide to showcase the video within a web video player on their social network profile page 160 using embedded code 143. Still others may decide to email 142 the video to their friends who would then receive the email on a mobile media device 150 such as an iPhone, which includes one or more built-in media players. A visitor to the social network site 160 may find the displayed video entertaining or informative and elect to subscribe (or immediately download) 161 to the corresponding channel in order to automatically receive subsequent and future updates of the content in their standalone media player 130. Another user, still, could bookmark 144 (or embed) the content at another site having a web media player (140) such as a personal website or a website associated with bookmarked content.

Movement of consumption of a single video multiplied by the millions of users consuming thousands of videos on tens of different platforms results in the aforementioned need for a comprehensive measuring analytics and reporting system for publishers 102 and advertisers 101. The present invention may capture media usage from a variety of media players 130, 140, 150, and 160 and corresponding content servers (e.g., servers as Central Service Provider 105) for analysis and creation of insightful reports. Such data may be stored at database 170.

Irrespective of how content is consumed, usage measurements may be made when the content is consumed. Standard web logs may provide measurements of content downloaded from the hosting servers at Central Service Provider 105. Playback logs may also be maintained and acquired from each of the aforementioned media players/device (130, 140, 150, and 160). Reports may be generated based upon all captured events and stored in aforementioned database 170.

These reports are made accessible via an online analytics and reporting portal 180. These reports may be accessed by publishers 102 and advertisers 101 to make determinations concerning the success of advertisement campaigns, the desirability of content, and the success of integrating the two forms of content (ads and entertainment/information). Portal 180 may present data from database 170 to publisher and advertiser accounts as part of a single comprehensive account in order to manage the entire information about the content as well as schedule ad campaigns.

FIG. 2 illustrates a user device 200 including a plug-in 220 application for ingesting content and feeds and generating data logs for analytics and reporting systems. User device 200 is inclusive of any device capable of acquiring and allowing for consumption of content. For example, user device 200 may be a mobile device 150 as referenced in FIG. 1. User device is also inclusive of computing devices operating media players/browser devices 130, 140, and 160 in FIG. 1 as well as user device 406, as that device is discussed in the context of FIG. 4. Plug-in application 220 is a lightweight software application executable by the processor of a computing device such as user device 200. Plug-in application 220 may encompass various subsidiary software modules such as reporting module 235, content assembler module 223, and request handler module 221.

The content and feed servers 210 may be part of the central services 105 as referenced in FIG. 1 or may be hosted elsewhere. Content servers host the media file and serve the content upon receipt of a request generated by execution of the request handler module 221 contained in the plug-in application 220. The feed servers hold the RSS feed, which is a text file in XML format. A podcast application, such as iTunes, will receive the feed from the feed server at the time of subscription. The RSS feed holds information on the location of the media file hosted on the content server.

Execution of the plug-in application 220, generates the aforementioned request for the RSS feed. The application 220 then transforms delivers the modified feed to the podcast application thereby resulting in the addition of a channel subscription. Execution of the plug-in application 220 offers the user enhanced mechanisms to easily discover and share attractive content through a graphical user interface, while managing content and feeds alongside the media player and collecting precise usage (e.g., playback) events from the corresponding media player. The usage events are then delivered to a reporting and analytics service 250 via a communications network 225 such as the Internet for further analysis. The usage data could also be sent to multiple reporting services; each RSS feed may specify data to be sent to a different reporting service.

Execution of the content assembler 223 causes the plug-in application 220 to receive content from a publisher 102 or content server 506 (as illustrated in FIG. 5), advertisements from an advertiser 101 or advertising server 505 (also illustrated in FIG. 5), and insert the advertisement into the content to create an ad infused media file. Expired advertisements, too, may be removed with a new advertisement inserted in its place. Content assembler 223 splits the content file into two parts as described above whereby the end of a first part of the content file is stitched to the beginning of the advertisement file and the second part of the content file is stitched to the end of the advertisement file. The content assembler 223 can assemble any number of ads into any number of locations within a content file.

The reporting module 235 of the plug-in application 220 is executed at the user device 200/406 to collect media usage data. When reporting events to a usage information gathering server 250 (also illustrated as server 403 in FIG. 4), usage data may be associated with a unique User ID. The User ID may be generated and issued by the usage information gathering server 250/403. The User ID allows the server 250/403 to correlate usage to user while maintaining anonymity and privacy of the actual user. The usage information gathering server 250/403 further aggregates user and usage logs including data from the content server and feed server web logs. Aggregated data may be maintained at a database 255, which also corresponds to the database 170 of FIG. 1.

The following list exemplifies events collected and sent to a usage information gathering server

EVENT                        CODE
episode download success     cc
episode download failure     ce
channel subscribed           af
initial add feed             ia
episode play                 pl
episode play count           pc
episode play count on device pd
ad playback                  vl
ad full playback             vc
buttons shown                bs
share episode                sh
share view                   sv
bookmark episode             bm
bookmark view                bv
open more tab                mo

FIG. 3A illustrates an interface to add an RSS content subscription whereas FIG. 3B illustrates a graphical user interface (GUTI) for a registration profile gathering server. The GUIs of FIGS. 3A and 3B may be used by the user device 406 of FIG. 4 (and the user devices of FIG. 1) to interact over a network 225 (as illustrated in FIG. 4) with a registration profile gathering server 402.

FIG. 3A illustrates that the content provider web page may include various information and a “Get Podcast” button, which may have been added using the copy and paste process set forth in the computer code listed in Table A. Upon a user actuating the “Get Podcast” button on the web site of a content provider or on the web site of the intermediary, the browser is redirected to a web page of the intermediary site that provides the registration information request shown in FIG. 3B. Registration information may generally include user attribute information but is also inclusive of requests for user acceptability rules that indicate the kinds of information that the user does and does not want to receive. User acceptability rules can be used to recommend particular types of content. While only one user registration screen is illustrated in FIG. 3B, more than one screen may be used.

Following a subscription process, which may take place through the interface illustrated in FIG. 3A, the plug-in application (220 of FIG. 2) is downloaded from a software download server such as a web server. Once the plug-in application 220 has been installed and executed for the first time, the application 220 triggers a request to the user to provide user profile information via an interface like that illustrated in FIG. 3B.

User profile information may be provided via the user device 406 of FIG. 4 (or a corresponding user device as illustrated in FIG. 1) over the network 225 to the registration profile gathering server 402. The plug-in application then downloads content from a content server (e.g., content server 506 of FIG. 5). Content server may be any content server specified in an RSS feed subscribed to by a user. A JavaScript subscription function (e.g., the VoloMediaSubscribe ( ) function of Table A) is run on the user device 406 and ensures that the user device 406 has the client-side plug-in application installed. The actions initiated by user actuation of the Get Podcast button of FIG. 3A include checking if the plug-in application module is installed. If the plug-in is not installed, an installation file is downloaded and executed followed by a registration process.

FIG. 4 illustrates a user and usage information gathering system 400. A user 405 operates a user device 406, which is inclusive of personal computers, personal digital assistants (PDAs), an iPod from Apple Inc. or other portable media devices such as a PlayStation Portable from Sony Computer Entertainment Inc., which permits the downloading of content over a network 225 such as the Internet. System 400 gathers user registration profile information when user 405 first registers to receive certain content. In addition, the system 400 periodically gathers user usage information indicative of content and advertisements obtained or subscribed to by a user.

User registration profile gathering server 402 gathers user profile information over the network 225 during user registration. Server 402 may be a web page server that serves up web pages to a browser enabled user device 406 over the network 225 to solicit user preferences and/or rules during registration of the user 405. Usage information gathering server 403 periodically gathers user usage related information over the network 225.

In one embodiment, a user device 406 runs an application 407 (e.g., plug-in application 220) that gathers usage information and periodically uploads that information over the network 225 to the user usage information gathering server 403. The usage information upload may be automated thereby obviating the need for user interaction.

The system 400 also includes a storage repository 404 to store user-related information. The user-related information may include user acceptability rules 404a that express preferences of user 405. Such preferences may be absolute such as what type of information a user absolutely does or does not want to receive. Alternatively, rules 404a may be flexible and merely indicative of preferences.

The user-related information may also comprise user attributes 404b that express user qualities or characteristics. User attributes may comprise gender, age, listening and/or viewing habits of a user. Attributes may further include geographic information such as zip code or whether or not the user 405 has children.

FIG. 5 illustrates a system 500 to deliver RSS subscription content to a user. System 500 may combine ad campaign provider ads into content provider content. A web page 502 is displayed by a PC web browser. The web page 502 is associated with a content provider. A content provider content server 506 serves content in response to RSS feed requests.

At time=t1, a user actuates a link on web page 502 to request an RSS feed associated with content served by content server 506. In response to the request, at time=t2, the RSS feed is delivered over the network 225 to the podcast application 504.

A transform function 510, which is a part of the plug-in application 220 running on the user device (user device 406 of FIG. 4) receives the RSS feed and changes all content URLs to point to local host (127.0.0.1). At time=t3, the RSS feed with the transformed URLs is delivered to the podcast application 504, such as iTunes® running on the user device. The content provider web page 502 includes a “get podcast” button associated with JavaScript used to download the plug-in 220 like that discussed in the context of FIG. 2 and acquired via an interface like that of FIG. 3A. When a user selects the “get podcast” button, the user is asked for permission to install the plug-in client 220 if it was not previously installed. If the client has already been installed, the client takes control and adds the feed to the podcast application 504.

At time=t4, the podcast application 504, such as iTunes initiates an update of content associated with the RSS feed. The request is intercepted by the request handler module 221 of the plug-in application 220 illustrated in FIG. 2. Request handler 221 includes a listener on local host (127.0.0.1), which ‘listens’ on the local host IP 127.0.0.1 and intercept calls by the iTunes® application or any other media manager application.

At time=t5, the request handler module 221 forwards the intercepted request over the network 225 to a content server 506. At time=t6, the content server 506 receives the request sent by the content assembler module 223, which is also illustrated in the context of the plug-in application 220 of FIG. 2. At time=t7, the content server 506 returns the requested content over the network 225 to the content assembler module 223.

At time=t8, the content assembler module 223 receives the requested content update. At time=t9, content assembler module 223 inserts advertisements into the newly arriving content if an advertisement is available to be inserted. At time=t10, the original content or the modified ad infused content is streamed to be played or to be stored as a content file for later playback in the podcast media player application 504.

The original RSS XML is transformed by the management plug-in (after download) to point all the URLs of the files, such as content files, to the “local server” (127.0.0.1) so that all podcast manager application content requests for this RSS will be directed to and handled by the plug-in (client application). The podcast management plug-in listens on a local host port and intermediates in content requests by the podcast manager application. Each RSS feed may represent a podcast content feed with a list of episodes. In one example, there exists one RSS feed per podcast subscription, which is similar to a virtual channel. The client-side plug-in intervenes each time the user clicks on a “Get Podcast” button for each feed by rewriting address elements within each RSS feed (e.g., changing address to 127.0.0.1:port) before handing it off to the podcast manager application. For example, if a user subscribes to 100 feeds/channels, then there are 100 RSS feeds for which the client-side plug-in intervenes.

The podcast manager application requests a file from the RSS feed. The management plug-in intercepts the feed request, which has been modified to point to the request to the local host. The management plug-in, rather than the podcast manager application, forwards the request for the file indicated by the RSS feed. The plug-in generates a new http request for the file from the server such as the content server 506. A content server that hosts the content can be either hosted within the central services provider 105 of FIG. 1, by a content provider, or by an intermediary. The plug-in intercepts file requests from the podcast manager application (to 127.0.0.1:port) and rewrites each such request so that the content server 506 receiving the request sends requested content back to the management plug-in rather than sending it directly to the podcast manager application.

The following is an illustrative example of the intermediation of the management plug-in application in the retrieval of a content feed. A user requests that a content feed be added by clicking an icon on a user device interface. The request is captured by the management plug-in software, which changes the original URL of the file in the RSS feed. For example, http://www.somesite.com/podcast/channels/morningnews.mp4 may be changed to http://127.0.0.1:10930/?getitem www.somesite.com/podcast/channels/momingnews.mp4. The full original URL of the file is stored as an argument after the “getitem_.” Subsequently, a user may request a file from that RSS feed. Thus, the podcast manager uses the changed URL—http://127.0.0.1:10930/?getitem_www.somesite.com/podcast/channels/mo-mingnews.mp4 to actually make the call for the file. The plug-in software remains listening on the address 127.0.0.1:10930, however. The plug-in captures the request and generates a request to a content server that serves the requested RSS feed, using the original URL that is stored as an argument after the “getitem_.” (i.e., www.somesite.com/podcast/channels/momingnews.mp4). Alternatively, the plug-in application could also be implemented and directly used on user devices with Internet Protocol (IP) capabilities. These devices do not need to use an intermediate podcast manager application (e.g., iTunes) for content syncing as they can obtain the RSS and the content directly from the network, such as the Internet.

FIG. 6 illustrates a modular architecture coupling a user device plug-in 220 to analytics, distribution, media, and campaign management systems. In one example, a plug-in application 220 operating in an iTunes® environment determines when an episode or advertisement has played and reports such data to other subsystems. The plug-in reporting module (235 of FIG. 2) logs data about the played file along with data concerning the starting offset and duration of the playback event. Reporting module 235 further analyzes the advertisements that were inserted into the content file to determine which advertisements and content were viewed by the user.

In the present example, the plug-in reporting module 235 makes use of the iTunes® music library xml file to determine the play counts for any given episode. By keeping track of the playback events from the reporting system and looking at the playback counts listed in the iTunes® music library file, the plug-in is also able to determine how many times an episode was played on a corresponding iPod device. Using application interfaces built on the HTTP protocol, the plug-in application 220 can communicate detailed iTunes® playback data to external advertising systems 610 such as Doubleclick's DART or any other third party reporting system 600 (e.g., reporting and analytics systems 180 of FIG. 1).

The location of the analytics and reporting system may be specified in the form of a URL included in an RSS feed item element. The URL pointer to the analytics and reporting system may likewise (and in a real world implementation) be passed on to the plug-in application 220 as an argument to the VoloMediaSubscribe( ) function as referenced in Table A. The RSS feed of the subscribed channel is an argument to the VoloMediaSubscribe( ) function call from Table A. Usage data, including play events, related to the RSS feed is sent over HTTP protocol to the analytics and reporting system. In a still further example, the location URL of the reporting system is specified within the header of the media file.

Some embodiments of the present invention include providing for viral syndication by allowing the user to share downloaded media with friends and associates. Sharing may take place through a graphic or text overlay associated with the downloaded content. The overlay may indicate options for bookmarking, sharing, and/or requesting/finding more content with similarities to the downloaded content.

Embodiments of the present invention may be integrated with various bookmarking services, email services, and media player environments. If a user chooses to bookmark a media file, the user may be presented with a menu of bookmarking services associated with the user. The user may then designate a particular bookmarking service (e.g., Google Bookmarks) and information concerning the bookmark may automatically be sent to the user account on the bookmarking service. Bookmarking may include storing and retrieving information concerning the website from which the content was downloaded, inviting friends to view the bookmarked (favorite) video dips, and copying and sending such information to various other bookmark services such as Google Bookmarks, del.ici.ous, and Digg.

If a user wishes to share a media file, emails with information concerning the media file (e.g., media URLs) may automatically be generated to send to friends and associates. Sharing the content may also include sharing the bookmark or ‘pushing’ the downloaded content back onto the Internet. If the user requests similar content, the similar content may be delivered to the particular media environment in which the user made the request. For example, the user may be watching a video file on iTunes® and request content similar to that of the video file just consumed. Similar content may then be added to iTunes® including a subscription. The information concerning sharing, bookmarking, and searching for similar content may be captured and analyzed for reports to advertisers and/or content publishers.

Publishers or content owners may likewise recommend similar content to users. For example, a user may watch a program from ABC News. A publisher or content provider (which may be the host of the ABC News program) may identify similar content, individual shows, or channels and recommend the same. Recommended content may then be added to a particular media environment (e.g., iTunes®) for downloading by clicking a single button or added as a RSS subscription when a channel is recommended. Publishers may recommend content to users who may or may not be connected to the Internet or those users who are not currently visiting the website of the content provider. Publishers may also recommend content to users based upon their demographic information (e.g. age, gender, or location) or upon their behavioral information (e.g. types of content the user watches).

Sharing of content initiated at one platform such as iTunes®. but consumed on another platform such as through a Flash video player while preserving an advertiser's and/or publisher's ability to present freshly inserted advertisements at the time of consumption are further provided by embodiments of the present invention. A podcast publisher may likewise track the consumption of a video or other content file when played within a standalone media player such as iTunes® by using any online web based analytics and reporting engine. The movement and consumption of video files from downloads to online, across different online locations, and from online to download may be tracked thus producing detailed analytics of the movement and consumption of media.

FIG. 7 illustrates an interface for invoking the sharing of downloadable media. When a user wishes to share, bookmark, or find other related videos, pressing the pause button is a first step to invoking sharing and discovery functions. FIG. 7 illustrates an invitation to a user consuming the content to press the “pause” button to trigger presentation of a three-button-companion interface.

FIG. 8A illustrates a three-button-companion graphical user interface to a user, specifically a highlighted “more” function. Through this interface, which may be displayed to a user on a corresponding user device (for example, user device 406 of FIG. 4), a user may obtain related information or recommendations based upon metadata in a current content file or information within a corresponding RSS feed. The interface allows the related information or recommendations to be obtained over a network while the user is downloading the content or when the user has cached the content for later use when the user is offline as is discussed with respect to the FIG. 8B. The interface of FIG. 8A is, in one embodiment of the present invention, displayed to the user when the user pauses the media file in the context of FIG. 7.

FIG. 8B illustrates a method for operation of a three button companion, specifically the “more” function. The flow diagram also depicts the ability of the system to notify the user if a given action requires network connectivity and to act upon that action once the user returns to an online state. In step 810, the interface (like that of FIG. 8A) is launched. Launch of the interface companion may occur as a result of selecting ‘pause’ as discussed in the context of FIG. 7. A determination is then made, in step 820, as to whether the user is on-line or off-line. RSS, images, and “more” content are downloaded and cached in step 830 for current and/or later display if it is determined that the user is on-line. If the user is determined not to be on-line, previously cached content is displayed in step 840. If the user initiates an action that otherwise requires an on-line connection (step 850), then the browser or media application (e.g., iTunes®) will display an appropriate message indicating the present off-line state in step 860. Should there be a state change with respect to connectivity as determined in step 870, the appropriate steps of the flowchart are then followed.

With respect to steps 830 and 840, the interface is populated with both related information as well as recommendations that are obtained either from the network or from a local cache that was obtained while the media file was being downloaded. The location of the related information and recommendations may be specified in the form of a URL included in an RSS feed item element. Both the related information and the recommendations may themselves contain metadata that allows a user to further act upon the information.

In one example, selecting related information or a recommendation may cause the user device to download additional media files from the network. In another instance, selecting the related information or recommendation may cause the user device to display additional information about the media file. This additional information may be in the form of a web page that is displayed on the device or the additional information could be displayed in the form of a graphical user interface laid over an existing interface. Metadata that would cause additional media files to be downloaded may be labeled ‘Get’ and metadata that would cause additional information to be displayed would be labeled ‘Go’. Examples of both types of metadata are illustrated in FIG. 8A.

Interactions of the user with the user device may immediately be sent over the network to a usage information gathering server (such as gathering server 403 of FIG. 4) or can be locally cached to be sent at a later time. Examples of the actions that could be sent include the user selecting the ‘More’ interface element to display related information and recommendations. Other examples of actions that could be sent include the user selecting a ‘Go’ or ‘Get’ interface element.

A URL location pointer passed on to the plug-in application as an argument in the VoloMediaSubscribe( ) function and illustrated in Table A is invoked on selection of the ‘More’ interface element. Selection of the ‘More’ interface element invokes a URL included in the RSS feed as an item element. The ‘More’ URL may be specified within the header of the media file. Selection of the ‘Get’ interface element by the user may add an associated RSS feed as a new channel subscription.

FIG. 9A illustrates a three-button companion graphical user interface, specifically the highlighted “share” button. The “share” button allows for the emailing of a video from within a standalone media player. In the interface of FIG. 9A, the user is presented with a form user interface that includes fields to list recipient email addresses, the name and email address of the user sending the content, and a message. In this example an optional captcha form is included to help validate that the user is a valid person and not a computer program.

FIG. 9B illustrates the operation of a “share” function in order to email a video from within a standalone media player. Additional information may also be shared through this methodology, the additional information may include but not being limited to the original URL for the media file, the feed URL for the show where the media file originated, the title of the show, the title of the media file, and a subject and message included by the user.

In step 910, a user clicks on a share button, which may be similar to the button illustrated in FIG. 9A. A window is then launched in step 920 whereby a user is prompted to provide information for e-mailing the video or other content. In many instances, the content itself is not sent due to bandwidth constraints. Instead, a link identifying and allowing for access to the content is sent. The user fills out the form in step 930 including an e-mail address of the recipient, that of the user, and/or a note for the recipient that is to accompany to the content being delivered to the recipient. The message is sent through the clicking of a send button on step 940. Instead of an e-mail address, other forms of contact information may be used including an instant messaging address or cell phone number.

If all fields from the popup window displayed in step 920 are determined to have been correctly filled out at step 950, the message is sent in step 960 along with a Globally Unique Identifier (GUID) and metrics information. The GUID information is requested by a backend log in step 970. The GUTID and IP address of sender may be applied against a spam database in step 980 such that a determination may be made at step 990 as to whether the message being sent is legitimate or unwanted spam. If the message is determined to be spam, delivery fails and a corresponding delivery failure message is displayed. If the message is determined not to be spam, then the content and corresponding message is sent along with an indication that delivery is successful.

Returning to step 950, if it is determined that all fields have not been correctly filled out (e.g., an email address of the recipient or sender is omitted), then the process returns to step 930 to correct the erroneous information. An indication as to the error might be reflected in step 995. Different fields may be necessary to allow for delivery of content or a link to the same. Other fields may be optional whereby incorrectly provided information does not otherwise prevent delivery of the content.

As noted above, additional information may be sent with a media file or a link thereto. Additional information may be obtained by parsing the media file and extracting information from the metadata within the media file. The additional information may also be obtained by parsing the RSS feed from which the media file originated or receiving the information directly from the user. The additional information could also be obtained by using any combination of the three methods. Once the additional information is obtained, the system may share the media file and information in a manner similar to that described above in FIG. 9B.

FIG. 9C illustrates an email message received by a recipient of the sharing action. The message could include links to play back the media file as well as a link to report that the shared media was received in error by the recipient user. Before sending the media file and additional information to the recipient, the information can be formatted to be properly displayed on the recipient user's device. If the recipient address was an email address, the information could be formatted to include a snapshot from the video file along with a link to view the media file in a web browser. In another example, the message could be formatted to embed a video player so that the recipient user could directly view the media file in the message. A URL link to a page containing the embedded shared media could also be sent to the recipient. The recipient may be able to view the shared media within an embedded media player contained in a web browser.

FIG. 10 illustrates a three-button companion graphical user interface to a user, specifically a highlighted “bookmark” button. Bookmarking the content file and/or additional information allows for the content and information to be bookmarked to one or more social bookmarking websites. The additional information can include but is not limited to the original URL for the media file, the feed URL for the show from where the media file originated, the title of the show, the title of the media file, tags associated with the media file or show, or a message included by the user. Additional information may be obtained by utilizing any of the aforementioned methodologies including parsing the media file or the RSS feed as well as receiving information directly from a user.

Through the interface of FIG. 9C, the user may select one or more social bookmarking websites on which to bookmark the media file and additional information. The system determines the parameters that need to be passed to each site in order to allow the information to be bookmarked properly. When the user is on-line, the information can be sent directly to the social bookmarking site using the network. When the user is off-line, the system can cache the information to be sent when the user returns to an on-line state. Examples of social bookmarking sites include but are not limited to Digg, Google Bookmarks, and StumpleUpon.

Once placed on the social bookmarking site, the bookmark enables the user or other users to directly download the media file without first requiring the RSS feed or show subscription. The bookmark also enables users to gain access to media files that have since been removed from the RSS feed. In another related embodiment, embed code may be generated with information extracted from parsing the RSS file or the media file. The embed code, when manually pasted or automatically uploaded to a personal user profile page on a social media site, a web media player containing the embed video is generated at the social media site. Examples of social media sites include but are not limited to Facebook, Myspace and Tagged. The user may be required to input login and password information for their social network account in order to upload the content or information.

FIG. 11 illustrates an instance of an online video player 1100 embedded in a web browser, where the player allows the user to further share or subscribe to the video, in addition to playing the video. To view video within such a web media player 1100, a user is not required to install a standalone media player or the plug-in software. An online embedded video player 1100 as illustrated in FIG. 11 contains certain viral sharing features as ‘built in’ functions whereby users may invite other users to view the video or embed the video on their social media personal profile pages. The embedding of the video may be accomplished manually or automatically by copying the embed code 1130 and pasting it in social media profile pages.

FIG. 11 also illustrates an additional feature allowing web users to get the channel feed as a subscription download 1120. This feature may prove useful for those users that prefer to have the media automatically downloaded to their device on a periodic basis instead of having to actually visit websites to receive periodic updates to content of their interest. Downloaded content is consumed using a standalone media player such as iTunes® and can become portable on non-networked portable media devices such as the ipod allowing usage even while a user is offline.

In one exemplary embodiment, users may share their favorite videos with friends and family via email using the ‘share this clip’ link 1110. In another embodiment, users may embed the web media player 1100 containing episodes and channels they wish to share with friends, family, and visitors to their profile pages from within the standalone media player running on the user device. This may be accomplished by automatically writing the related embed code or bookmark links to the users profile page. The user may be required to input login and password information for their social network account. These sharing mechanisms enable viral discovery of media and fast adoption of popular media because of user-to-user remarketing.

Computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (CPU) for execution. Such media can take many forms, including, but not limited to, non-volatile and volatile media such as optical or magnetic disks and dynamic memory, respectively. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, RAM, PROM, EPROM, a FLASHEPROM, any other memory chip or cartridge.

Various forms of transmission media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU. Various forms of storage may likewise be implemented as well as the necessary network interfaces and network topologies to implement the same.

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. The descriptions are not intended to limit the scope of the invention to the particular forms set forth herein. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments. It should be understood that the above description is illustrative and not restrictive. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

TABLE A
<!-- Copy and Paste this javascript in your page in the <head? section to display the ‘Get
Podcast‘ button -
<script type=“text/javascript” language=“javascript”
src=“http://plugins.volomedia.com/new_agent/button_header.js”></script>
<!-- When a link to subscribe to a podcast is to be displayed somewhere on the page, the
following HTML element
<!-- that calls the VoloMediaSubscribe function in it's onClick handler should be coded
as follows:
<a href=‘javascript:;‘
onClick=“VoloMediaSubscribe(‘http://podcasts.nbc.com/nightly_news.xml‘, ‘NBC
Nightly News‘,
‘http://podcasts.nbc.com/images/msnbc_logo.png‘,‘http://www.myanalytics.com
/ma.js‘, ‘http://www.podcasts.nbc.com‘);return false;”>Get Podcast
</a>
// Create the VoloMedia Url Array
var voloUrlArray = new Array( );
var voloReportServer = “http://ticks.podbridge.com”;
var voloImageServer = “http://plugins.volomedia.com/new_agent”;
var voloScriptServer = “http://plugins.volomedia.com/new_agent”;
var voloDefaultOfferUrl = “http://www.volomedia.com/rss/plugin-download-
video.xml”;
var voloJSRelease = “new_agent”;
var voloJSVersion = “1.2”;
var voloClientID = VoloGenerateGUID( );
function VoloS4( )
{
return (((1+Math.random( ))*0x10000)|0).toString(16).substring(1);
}
// Function to help generate a pseudo unique client id
function VoloGenerateGUID( )
{
return (VoloS4( )+VoloS4( )+“-”+VoloS4( )+“-”+VoloS4( )+“-”+VoloS4( )+“-
”+VoloS4( )+VoloS4( )+VoloS4( ));
}
// Push a VoloMedia Url onto the array stack. These urls will be called once the agent is
accessible function VoloPushUrl(url)
{
// First check to see if this exact url is already in the stack
var found = false;
for ( i = 0; i < voloUrlArray.length; i++ )
{
if ( voloUrlArray[i] == url )
{
found = true;
break;
}
}
if ( !found )
voloUrlArray.push(url);
}
function VoloReportEvent( )
{
// This function is going to accept a variable number of arguments in the
following order
// event -> the string representing the event type
// channel -> the url for the feed or channel that was requested
// client_id -> a unique id to represent this client
// referrer -> the referring page for this code.
var voloEvent = null;
var voloChannel = null;
var voloClient_ID = null;
var voloReferrer = null;
// at the very least we need an event argument
if ( arguments.length < 1 )
return;
voloEvent = arguments[0];
if ( arguments.length > 1 )
voloChannel = encodeURIComponent(arguments[1]);
if ( arguments.length > 2 )
voloClient_ID = arguments[2];
else
voloClient_ID = voloClientID;
if ( arguments.length > 3 )
voloReferrer = encodeURIComponent(arguments[3]);
else
voloReferrer = encodeURIComponent(document.location);
var id = “voloImg”;
var voloBodyLoc = document.getElementsByTagName(“body”).item(0);
// Cleanup so we aren't littering the DOM with new elements
var imgObj = document.getElementById(id);
if ( null != imgObj )
voloBodyLoc.removeChild(imgObj);
var voloReportUrl = voloReportServer + “/vm.gif”;
var voloImgObj = document.createElement(“img”);
var voloRand = parseInt(Math.random( )*99999999); // random number to get
around caching issues
voloReportUrl += “?event=” + voloEvent;
if ( voloReferrer != null )
voloReportUrl += “&referrer=” + voloReferrer;
voloReportUrl += “&rand=” + voloRand;
if ( voloChannel != null )
voloReportUrl += “&channel_url=” + voloChannel;
if ( voloClient_ID != null )
voloReportUrl += “&client_id=” + voloClient_ID;
voloReportUrl += “&PBver=” + voloJSRelease;
voloReportUrl += “&PV_jsVer=” + voloJSVersion;
voloImgObj.setAttribute(“src”, voloReportUrl);
voloImgObj.setAttribute(“id”, id);
voloBodyLoc.appendChild(voloImgObj);
//alert(“calling report url: ” + voloReportUrl);
}
function VoloCallUrl(url)
{
//alert(“calling url: ” + url);
var id = “voloAgentScript”;
var voloHeadLoc = document.getElementsByTagName(“head”).item(0);
// Cleanup so we aren't littering the DOM with new elements
var scriptObj = document.getElementById(id);
if ( null != scriptObj )
voloHeadLoc.removeChild(scriptObj);
var voloScriptObj = document.createElement(“script”);
// Add script object attributes
voloScriptObj.setAttribute(“type”, “text/javascript”);
voloScriptObj.setAttribute(“src”, url);
voloScriptObj.setAttribute(“language”, “javascript”);
voloScriptObj.setAttribute(“id”, id); voloHeadLoc.appendChild(voloScriptObj);
}
function VoloPingAgent( )
{
var voloUrl = “http://127.0.0.1:10930/?cmd=Ping&ret=js”;
//alert(“Ping Agent: ” + voloUrl);
VoloCallUrl(voloUrl);
}
function VoloIsAgentInstalled( )
{
return ( typeof(volomediaVersion) != “undefined” );
}
function VoloIsMac( )
{
return navigator.userAgent.toLowerCase( ).indexOf(“mac”) != −1;
}
function VoloIsWindows( )
{
return navigator.userAgent.toLowerCase( ).indexOf(“windows”) != −1;
}
function VoloIsSupported( )
{
// Only Mac and Windows are supported at this time
//return (VoloIsMac( ) | | VoloIsWindows( ));
return VoloIsWindows( );
}
function VoloMediaSubscribe(url, title, logo)
{
if ( typeof(url) == “undefined” ) return false;
VoloReportEvent(“GPC”, url);
if ( !VoloIsSupported( ) )
{
// navigate to itpc://
if (url.indexOf(“http://”) == 0) //replace with itpc
url = url.replace(“http://”, “itpc://”);
else if (url.indexOf(“HTTP://”) == 0) //replace with itpc
url = url.replace(“HTTP://”, “itpc://”);
else
url = “itpc://” + url;
window.location = url;
return false;
}
var request = “”;
if ( VoloIsAgentInstalled( ) ) // Subscribe for an RSS feed
{
request = “http://127.0.0.1:10930/?cmd=Subscribe&ret=js”;
}
else // Install and subscribe for an RSS feed
{
request = voloScriptServer + “/install_popup.php?cmd=Install”;
VoloReportEvent(“DPV”, url);
}
if ( logo != undefined )
request += “&logo=” + encodeURIComponent(logo);
if ( title != undefined )
request += “&title=” + encodeURIComponent(title);
if ( url != undefined )
request += “&url=” + encodeURIComponent(url);
// add the client id and referrer to the url
request += “&client_id=” + voloClientID;
request += “&referrer=” + encodeURIComponent(document.location);
VoloCallUrl(request);
return false;
}
function VoloMediaSubscribeOffer(url, title, logo, offer_url)
{
if ( !VoloIsAgentInstalled( ) )
{
if ( typeof(offer_url) == “undefined” )
offer_url = voloDefaultOfferUrl;
encoded_offer_url = encodeURIComponent(offer_url);
push_url = ‘http://127.0.0.1:10930/?cmd=Subscribe&url=’ +
encoded_offer_url;
VoloPushUrl(push_url);
VoloMediaSubscribe(url, title, logo);
}
else
{
VoloMediaSubscribe(url, title, logo);
}
return false;
}
function VoloLaunchUrls( )
{
if ( VoloIsAgentInstalled( ) )
{
//alert(“Check Agent is launch urls: ” + voloUrlArray);
// Check if there are any subscriptions that need to go out while (
voloUrlArray.length > 0 )
{
var url = voloUrlArray.shift( );
//alert(“Add Url: ” + url);
VoloCallUrl(url);
}
}
else
{
//alert(“Agent isn't running”);
setTimeout(“VoloCheckAgent( )”, 2000);
}
}
function VoloCheckAgent( )
{
//alert(“VoloCheckAgent”);
volomediaVersion = undefined;
VoloPingAgent( );
if ( voloUrlArray.length > 0 )
{
// set a timeout to check the agent
setTimeout(“VoloLaunchUrls( )”, 500);
}
}
// Ping the agent to see if it's running
VoloPingAgent( );

Claims

1. (canceled)

2. A computer-implemented method for analyzing episodic media consumption, the method comprising:

receiving information over a communication network regarding an association between at least one subscribing user and an insertable content file;

automatically sending an episodic media file over the communication network to a client device associated with the at least one subscribing user, wherein the episodic media file is split into two parts at an insertion point, and at least a portion of the insertable content file is stitched between the two parts to create a single new media file comprising both the episodic media file and the insertable content file; and

receiving usage information over the communication network regarding the subscribing user, wherein the usage information indicates whether at least a portion of the insertable content file was consumed by the at least one subscribing user during a time period in which the client device was off-line.

3. The computer-implemented method of claim 2, further comprising encoding the new media file for compatibility with the client device.

4. The computer-implemented method of claim 2, further comprising encoding the new media file for compatibility with two or more client device types.

5. The computer-implemented method of claim 2, further comprising analyzing the received usage information to identify at least one recommended media content file, wherein identifying the at least one recommended media content file is based on metadata of the episodic media file.

6. The computer-implemented method of claim 5, further comprising transmitting a recommendation to the client device regarding the recommended media content file, the recommendation including metadata to cause the recommended media content file to be downloaded to the client device.

7. The computer-implemented method of claim 2, wherein the received usage information comprises a plurality of event indicators regarding the new media file, the plurality of event indicators comprising an indication of one or more of: success in downloading the new media file, failure in downloading the new media file, playback completion of the insertable content file, and a play count of the episodic media file.

8. The computer-implemented method of claim 2, wherein automatically sending the episodic media file over the communication network to the client device comprises matching the insertable content file with the at least one subscribing user associated with the client device, and further comprising re-encoding the single new media file to have a uniform matching profile and to be compatible with the client device of the at least one subscribing user.

9. A system for analyzing episodic media consumption, the system comprising:

a match server configured for receiving information over a communication network regarding an association between at least one subscribing user and an insertable content file;

a hosting server communicatively coupled with the match server, the hosting server configured for automatically sending an episodic media file over the communication network to a client device associated with the at least one subscribing user, wherein the episodic media file is split into two parts at an insertion point, and at least a portion of the insertable content file is stitched between the two parts to create a single new media file comprising both the episodic media file and the insertable content file; and

a database communicatively coupled with the hosting server, the database configured for receiving usage information over the communication network regarding the subscribing user, wherein the usage information indicates whether at least a portion of the insertable content file was consumed by the at least one subscribing user during a time period in which the client device was off-line.

10. The system of claim 9, wherein the hosting server further encodes the new media file for compatibility with the client device.

11. The system claim 9, wherein the hosting server further encodes the new media file for compatibility with two or more client device types.

12. The system of claim 9, wherein the hosting server further analyzes received usage information to identify at least one recommended media content file, wherein identifying the at least one recommended media content file is based on metadata of the episodic media file.

13. The system of claim 12, wherein the hosting server further transmits a recommendation to the client device regarding the at least one recommended media content file, the recommendation including metadata to cause the recommended media content file to be downloaded to the client device.

14. The system of claim 9, wherein the received usage information comprises a plurality of event indicators regarding the new media file, the plurality of event indicators comprising an indication of one or more of: success in downloading the new media file, failure in downloading the new media file, playback completion of the insertable content file, and a play count of the episodic media file.

15. The system of claim 9, wherein the hosting server further automatically sends the media file over the communication network to the client device by matching the insertable content file with the at least one subscribing user associated with the client device, and re-encodes the new media file to have a uniform matching profile and to be compatible with the client device of the at least one subscribing user.

16. A non-transitory computer-readable storage medium, having embodied thereon a program executable by a processor to perform a method for analyzing episodic media consumption, the method comprising:

receiving information over a communication network regarding an association between at least one subscribing user and an insertable content file;

automatically sending an episodic media file over the communication network to a client device associated with the at least one subscribing user, wherein the episodic media file is split into two parts at an insertion point, and at least a portion of the insertable content file is stitched between the two parts to create a single new media file comprising both the episodic media file and the insertable content file; and

receiving usage information over the communication network regarding the subscribing user, wherein the usage information indicates whether at least a portion of the insertable content file was consumed by the at least one subscribing user during a time period in which the client device was off-line.

17. The non-transitory computer-readable storage medium of claim 16, further comprising instructions executable to encode the new media file for compatibility with the client device.

18. The non-transitory computer-readable storage medium of claim 16, further comprising instructions executable to encode the new media file for compatibility with two or more client device types.

19. The non-transitory computer-readable storage medium of claim 16, further comprising instructions executable to analyze the received usage information to identify at least one recommended media content file, wherein identifying the at least one recommended media content file is based on metadata of the episodic media file.

20. The non-transitory computer-readable storage medium of claim 16, further comprising instructions executable to transmit a recommendation to the client device regarding the at least one recommended media content file, the recommendation including metadata to cause the recommended media content file to be downloaded to the client device.

21. The non-transitory computer-readable storage medium of claim 16, wherein the received usage information comprises a plurality of event indicators regarding the new media file, the plurality of event indicators comprising an indication of one or more of: an episode download success, an episode download failure, playback completion of the insertable content file, and a play count of the episodic media file.