US20090222580A1 - System and method for optimizing distribution of media files - Google Patents

System and method for optimizing distribution of media files Download PDF

Info

Publication number
US20090222580A1
US20090222580A1 US12/407,715 US40771509A US2009222580A1 US 20090222580 A1 US20090222580 A1 US 20090222580A1 US 40771509 A US40771509 A US 40771509A US 2009222580 A1 US2009222580 A1 US 2009222580A1
Authority
US
United States
Prior art keywords
media file
recipient
site
file
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US12/407,715
Other versions
US8880733B2 (en
Inventor
Christopher Stasi
Kelly Perdue
Dom Stasi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vubiquity Entertainment Corp
Original Assignee
TVN Entertainment Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by TVN Entertainment Corp filed Critical TVN Entertainment Corp
Priority to US12/407,715 priority Critical patent/US8880733B2/en
Assigned to MORGAN STANLEY SENIOR FUNDING, INC. reassignment MORGAN STANLEY SENIOR FUNDING, INC. SECURITY AGREEMENT Assignors: TVN ENTERTAINMENT CORPORATION
Assigned to NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE reassignment NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE SECURITY AGREEMENT Assignors: AURORAS ENTERTAINMENT, INC., AVAIL MEDIA HOLDINGS, INC., AVAIL MEDIA, INC., AVAIL ON DEMAND, INC., BROADSTREAM COMMUNICATIONS, INC., IBBOC, L.L.C., TVN ENTERTAINMENT CORPORATION
Publication of US20090222580A1 publication Critical patent/US20090222580A1/en
Assigned to SILICON VALLEY BANK reassignment SILICON VALLEY BANK SECURITY AGREEMENT Assignors: AURORAS ENTERTAINEMENT, INC., AVAIL MEDIA HOLDINGS, INC., AVAIL MEDIA, INC. F/K/A SYNDETIK, INC., AVAIL-TVN INTERNATIONAL HOLDINGS, INC., BROADSTREAM COMMUNICATIONS, INC., TVN ENTERTAINMENT CORPORATION
Assigned to TVN ENTERTAINMENT CORPORATION, AURORAS ENTERTAINMENT, INC., AVAIL MEDIA HOLDINGS, INC., AVAIL MEDIA, INC., AVAIL ON DEMAND, INC., BROADSTREAM COMMUNICATIONS, INC., IBBOC, L.L.C. reassignment TVN ENTERTAINMENT CORPORATION TERMINATION Assignors: NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE
Assigned to TVN ENTERTAINMENT CORPORATION reassignment TVN ENTERTAINMENT CORPORATION PATENT OWNERSHIP Assignors: PERDUE, KELLY, STASI, CHRISTOPHER, STASI, DOM
Assigned to VUBIQUITY ENTERTAINMENT CORPORATION reassignment VUBIQUITY ENTERTAINMENT CORPORATION CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: TVN ENTERTAINMENT CORPORATION
Assigned to TVN ENTERTAINMENT CORPORATION, AURORAS ENTERTAINMENT, INC., AVAIL MEDIA HOLDINGS, INC., AVAIL MEDIA, INC., AVAIL ON DEMAND, INC., BROADSTREAM COMMUNICATIONS, INC., IBBOC, L.L.C. reassignment TVN ENTERTAINMENT CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: MORGAN STANLEY SENIOR FUNDING, INC.
Assigned to AURORAS ENTERTAINMENT, INC., AVAIL MEDIA HOLDINGS, INC., BROADSTREAM COMMUNICATIONS, INC., AVAIL-TVN INTERNATIONAL HOLDINGS, INC., VUBIQUITY ENTERTAINMENT CORPORATION (F/K/A TVN ENTERTAINMENT CORPORATION), VUBIQUITY, INC. (F/K/A AVAIL MEDIA, INC.) reassignment AURORAS ENTERTAINMENT, INC. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS Assignors: SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT
Assigned to BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT reassignment BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT NOTICE OF GRANT OF SECURITY INTEREST IN PATENTS Assignors: VUBIQUITY ENTERTAINMENT CORPORATION
Priority to US14/531,622 priority patent/US20150058453A1/en
Publication of US8880733B2 publication Critical patent/US8880733B2/en
Application granted granted Critical
Assigned to VUBIQUITY ENTERTAINMENT CORPORATION reassignment VUBIQUITY ENTERTAINMENT CORPORATION TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS (RECORDED 5/9/13 AT REEL/FRAME 030390/0449) Assignors: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0637Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/765Media network packet handling intermediate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/162Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/165Centralised control of user terminal ; Registering at central

Definitions

  • This invention relates generally to a media file distribution system and method, and more particularly, to a system and methodology that provides end-to-end management of distribution of a media asset.
  • recipient sites The task of distributing media files from network content providers to recipient media front-end customers, such as cable providers, and the like (collectively called “recipient sites” herein), has become a complex process. This is mainly due to competing interests in file formats, transmission protocols, processing requirements, program guide entry format, and various other parameters configured according to different standards as amongst the various content and service providers involved in the distribution process. Accordingly, inordinate amounts of time are now spent converting formats in order for content providers, distributors, and the recipient site customers to manipulate and modify media files throughout the distribution process in order to comply with their diverse system requirements.
  • the typical media file is a media/digital file for use in video playback, gaming, or any other digital medium.
  • a file is sent over satellite, the Internet, or other network, to those involved in distribution and final presentation to the public from the front end or to the recipient site customers.
  • a data control file arrives with the media file which data file must be constantly modified with each conversion to a new system.
  • Current systems typically transmit the control file in one of three ways. The first is to target a unique metadata control file to each receiving site, thereby requiring N number of files for N sites. The second way is to send one generalized file to all receiving sites and then have a site-specific transformation occur at each site dictated by information stored at each site that is triggered by the general information in the control file.
  • a third way to is to send one control file to all receiving sites and then to require each site to process the one format in that control file to be used, but this approach precludes any site specificity.
  • limitations are necessarily imposed on, for example, the amount and types of different properties that can be applied to an ingested media file, and its distribution characteristics.
  • multiple systems are required, increasing the working time and likelihood of errors, as well as causing synchronization issues.
  • these approaches can be characterized by the frequent failure of in-bound value readers to pass data that is expected by site-specific transform mechanisms. Users in these media distribution system are then forced to manually adjust all of the media assets within the schedule accordingly, while continuing to monitor any additional changes that might be introduced by any of the entities that play a role in, or that otherwise involved in the overall media distribution system.
  • the claimed invention resolves the aforementioned and other problems by providing a media file distribution data system and method.
  • a single media file is used for distribution to two or more recipient sites.
  • a first recipient site has first parameter requirements for processing the media file
  • a second recipient site has second parameter requirements for processing the media file that are different from the first parameter requirements.
  • a first set of parameters is included in the media file that meets the first parameter requirements.
  • a second set of parameters is included in the media file that meets the second parameter requirements.
  • the first set of parameters is for use during distribution to the first recipient site
  • the second set of parameters is for use during distribution to the second recipient site.
  • a media file is received for distribution.
  • the media file has an asset type, and is validated according to one or more requirements according to the asset type. As a result of validating, one or more errors are produced. These errors are corrected by applying a rules application to the media file.
  • the media file is then distributed.
  • a media file is provided for distribution.
  • the multi-media file is processed to produce data parameters for distribution.
  • a receiving status of the recipient site is checked.
  • One or more of the data parameters are changed according to the receiving status of the recipient site.
  • the data parameters are changed according to a set or rules defined in a contract with the recipient site.
  • the media file is then distributed to the recipient site according to the data parameters. Further, an interface is provided so as to allow an operator of the recipient site to view status information regarding distribution of the media file.
  • the claimed invention is a system and method for optimizing distribution of a media file to a plurality of recipient sites.
  • a receive status of a first recipient site is checked, thereby producing a first status check result.
  • a receive status of a second recipient site is checked, thereby producing a second status check result.
  • a rules engine is applied to determine a priority for distribution to the first recipient site respective of the second recipient site.
  • the media file is then distributed to the first recipient site and the second recipient site according to the determined priority.
  • the claimed invention is a system and method for providing connectivity in a media file distribution system.
  • the system includes a data store, a portion of which is for storing a media file received from a content provider.
  • a database in the data store contains editable parameters for distribution to the recipient site.
  • An interface to the database allows the content provider to edit the parameters.
  • the interface further allows the recipient site to edit the parameters.
  • a distribution “sub system” is configured for distributing the media file according to the parameters.
  • the claimed invention is a system and method for providing interactive program guide entry for a media file.
  • a distribution hub stores a media file received from a content provider for distribution to a recipient site.
  • An interface to the distribution hub allows editing of program guide data for the media file.
  • the interface stores the program guide data to the media file.
  • the interface further allows the content provider to view the program guide data for the media file.
  • the interface further allows the content provider to edit the program guide data, and to set parameters regarding editing of the program guide data by the recipient site.
  • the claimed invention is a system and method for providing a multi-port catcher.
  • the system includes a computer, a data store, and a network connection for connecting the computer to a network.
  • a partition application is executed on the computer to partition the computer into multiple partitions.
  • a catcher application executes in each partition.
  • Each catcher application is capable of receiving a separate media file over the network connection, simultaneously.
  • Each media file is stored in the data store.
  • the system may use a plurality of catcher applications, wherein, for example, a first partition executes a first catcher application, and a second partition executes a second catcher application. Therefore, the first catcher application can use a different protocol than the second catcher application.
  • the partition application is configured to divide processing of a processor of the computer into virtual computers, such that each of the media files are received by a partition executing in one of the virtual computers.
  • one of the partitions is configured as a content provider itself, such that one or more of the media files can be provided internally from the data store into the catcher without using a separate computer to provide the one or more media files to the catcher.
  • one of the partitions is further configured as a gateway computer to provide gateway processing for each of the other partitions.
  • the claimed invention is a system and method for administrating a contract for distribution of a media file.
  • a media file is received from a content provider, after which, contract parameter data is entered into the media file according to a contract between the content provider and a recipient site. Metadata is calculated for the media file based on the contract parameter data.
  • the media file is then distributed to the recipient site.
  • the contract data includes price limitations that the recipient site can charge for viewing of the media file.
  • the contract data includes time limitations defining limitations regarding a time that the recipient site can present the media file.
  • FIG. 1 is network block data flow diagram illustrating components and steps performed in a media file distribution system and method according to one embodiment
  • FIG. 2 is a screen shot from an example interface for a content provider for the system and method of FIG. 1 ;
  • FIG. 3 is a screen shot from an example interface for a content recipient site for the system and method of FIG. 1 ;
  • FIG. 4 is a block diagram illustrating field portions of a media file formatted according to one embodiment
  • FIG. 5 is a network block data flow diagram illustrating components and method steps in a transmission “sub system” and method according to the embodiment illustrated in FIG. 1 ;
  • FIG. 6 is a network block data flow diagram illustrating data flow between content providers, catchers, and a data store, according to one embodiment
  • FIG. 7 is a screen shot from an example asset tracking interface for a content provider for the system and method of FIG. 1 ;
  • FIG. 8 is a screen shot from an example package profile editing interface for a content provider for the system and method of FIG. 1 ;
  • FIG. 9 is a screen shot from an example interactive program guide editing interface for a recipient site for the system and method of FIG. 1 ;
  • FIG. 10 is another screen shot from an example interactive program guide editing interface for a recipient site for the system and method of FIG. 1 ;
  • FIG. 11 is data flow diagram illustrating steps performed by a contract manager “sub system” according to one embodiment.
  • FIG. 12 is data flow diagram illustrating the flow of data for applying a contract template to create contract parameters for a media file according to one embodiment.
  • the claimed invention provides an asset management and delivery system for the distribution of digital files and data.
  • the system has two major functions, with sub-functions within each.
  • the system first serves as a fully automated management system for a company involved in video/file distribution, such as in video on demand (VOD) or other digital file industries.
  • VOD video on demand
  • the system can ingest, prepare, schedule, transmit, track and report on any aspect of the business chain.
  • it also serves as a product for both content providers and recipient sites to be able to view, manage and run their entire content offering remotely from anywhere through the internet.
  • the claimed invention has the ability to ingest media files and data, prepare them for transmission across the media industry, localize all the applicable data by customer and track, and reconcile the distribution of that data, all within the same system.
  • the structure of the system 100 includes a series of components and functions.
  • the first component is for asset ingestion into the system.
  • Digital files and associated data are entered into the system in a variety of ways such as through standard file transfer protocol (FTP) or satellite transmission over a satellite link such as an outgoing satellite link 190 used for distribution.
  • FTP file transfer protocol
  • This data is then scanned for compliance to formats, quality, and expected parameter values, process block 150 .
  • the expected parameter values that are specific to each content provider are stored in provider tables 170 , wherein the system compares the stored provider specific expected parameter values to those received with each media asset.
  • Media package specific expected parameters are stored in package tables 504 , wherein the system further compares those package specific expected parameters to the parameter values received with each media asset.
  • the system calculates those parameter values based on data stored in metadata tables 516 .
  • Such calculated metadata may be archived into an archive table 176 for later review, or backup.
  • the digital files are then transformed into customer-specific formats, a process that begins at process block 152 .
  • the metadata of the media file is processed and added to the file.
  • the system 100 has the unique ability to be ingestion-format agnostic, meaning that, however the content provider would like to enter files into the system, it can recognize the interface type automatically, and perform the appropriate protocol to ingest the file, process block 154 .
  • the data is then queued, process block 156 , and scheduled for transmission over any medium (e.g. over the satellite link 190 , the Internet, and such), and prepared for that transmission.
  • reporting information regarding each file to be transmitted is stored in transformed asset tables 159 .
  • transmission of the media files 190 occurs via satellite 190 through a communication server 160 , to docking stations 186 at the recipient site head ends.
  • the media files are tracked, reconciled, and reported on, through a network management system (NMS) 188 .
  • NMS network management system
  • the system 100 enables users to author metadata (the control and information file for digital files in the video on demand environment) for video assets and export them for use.
  • the metadata affects the transmission of the media assets from content providers to recipient sites, such as multiple system operators (MSOs) receiving video-on-demand content.
  • MSOs system operators
  • the system also performs gateway functionality, which in the context of one embodiment, includes aggregation of files from multiple transmission systems through one point of entry. This comprehensive control gives the system the unique capability of allowing any and all formerly disparate or disconnected functions of the distribution chain to interact with each other, thereby optimizing all functions and capabilities of the entire network and allowing file handling based on data from the entire distribution system 100 .
  • the system 100 functions as an automated file recipient system for content distributors to aggregate data and digital media files. These media files are ingested into the system 100 through an automated ingest subsystem, processing block 104 . Once received the media files are manipulated and scheduled for distribution to the recipient sites or customers of the content providers, such as local cable companies and the like.
  • the system 100 also allows those same content providers to author the parameter data for their media files directly through a provider remote interface sever (PRI) 120 .
  • PRI provider remote interface sever
  • the parameter data is edited directly into the system or provided pre-formed into a folder on the network in order to be automatically ingested with the media file. Once entered, this parameter data is immediately transformed into data specific to the content recipient sites that will receive it later.
  • the system 100 provides the ability for all the customers to view the media file and status data through the Internet at all points in the distribution chain, using an affiliate remote interface server (ARI) 122 .
  • the customers can log into the system over the web through the ARI 122 , and view relevant media file data, not only in the original form in which it was entered, but also in the form after transformation in the system.
  • ARI affiliate remote interface server
  • parameter data can be viewed in a form, as it will appear when recipients display it to their cable or media viewers.
  • a content provider logs into the system to view the properties of their media file that are provided to a recipient, for example, a cable MSO. These properties include the price for viewing the media file from the affiliate, times or available times for viewing the media file, overrides to certain values found in the control metadata, such as provider or distributor information, and financial information, such as revenue splits.
  • the providers can also view the interface the content recipients display to their viewers.
  • FIG. 2 shows an example screen shot from PRI 120 .
  • the media recipients can log in through the ARI 122 , and can also review content available in the system. Through the ARI 122 , media recipients can sign up to receive content, thereby added the media recipient to distribution lists for media files. The recipients can also view the media file content before making decision on which media files to receive.
  • An example screen from the ARI 122 used to perform these functions is shown in FIG. 3 .
  • an example scenario with respect to ingestion and processing of a media file follows.
  • a file first arrives at an ingestion server 108 without any manual intervention.
  • the network connection 106 preferably comprises any high speed internet connection, such as a T1, T2 or high-end DSL connection.
  • the ingestion server 108 reads the file's parameters, which are entered by the content provider, and the type of file is determined.
  • a media file manager 512 manages processing of the file. For example, the media manager 512 can determine that the parameters of a media file require it to move immediately to the front of a satellite distribution queue, process block 156 .
  • the parameters read are a part of the corresponding metadata received with the file from the content provider. Certain fields are present in that data, such as the content tier, which tells the system the file type, which defines processing rules that are applied to the file in process block 154 .
  • parameters related to one or more contracts between the recipient and the content provider are added to the aggregate file, as described below with respect to FIGS. 11-12 .
  • the contract parameters may be determined from contract data in financial/contract tables 172 .
  • financial reports regarding the file are calculated and stored in a financial reporting module 174 .
  • the file is then moved across an internal system 100 , transmitted immediately, and reported on immediately so that all the recipient sites have it as quickly as possible.
  • a media file that arrives late automatically triggers a change in any previously scheduled transmission date within its parameters. This change flows through the entire system where parameters for that media file are kept. The system changes the availability date for that media file within its associated metadata. That change affects any financial projections, which are also automatically figured from the same data.
  • a change in receiving status/capability of one of the remote recipient sites triggers a change in the expected transmission schedule should that recipient site be part of an upcoming scheduled distribution.
  • This status affects the transmission order and timeline, and the changes populate back through the system. For example, should a number of recipient sites be unable to receive the media file at the time they are intended to receive transmission from the distribution, the system automatically changes the schedule for distribution according to one or more set of rules. The schedule may be changed to the next immediate distribution, or a distribution that occurs the next hour or later to allow those sites change to a favorable receiving status.
  • time updating has the effect of optimizing the use of transmission making the system more efficient.
  • a contract management subsystem determine rules for proceeding and adjust data surrounding the media file accordingly.
  • the contract management rules might require the media file to be sent to a recipient site regardless of the receiving status of the recipient site.
  • a rule may define the latest date that a media file may be sent. In that case, similarly, if the latest send-date indicates that the media file cannot be delayed any longer, the media file is required to be sent regardless of the receiving status of the target recipient site in the distribution.
  • Content providers viewing data in the system see these changes in real time and related report data is also changed applicably.
  • Changes can also be made manually. If parameters for a media file are changed by one of the content providers or recipient sites through the PRI 120 or the ARI 122 , the changes can be made anywhere in the distribution chain, including post transmission, because all of the subsystems are integrated. If distribution for the media file has already occurred, an updated media file recipient sites remote locations. This means that the content provider can change the availability dates for an individual media file by logging onto the web, pulling up the data for that particular media file, changing the availability dates, and the system will change the availability dates not only within the system 100 itself, but also at all at the file's destinations. The system sends updated copies of the media file if necessary (over satellite, internet etc.) to perform the updates.
  • the system also has rules that allow the content providers to change certain data such as availability windows for the media file, but the recipient sites are allowed to change other data that is applicable to their specific systems, such as price.
  • the identification of which entities are allowed to change which parameter fields can be stored as additional parameters in the media file itself.
  • IPG interactive program guide
  • Some prior systems enable users to author IPG metadata, but only the claimed system 100 enables entities to see exactly what that IPG metadata will look like at the eventual content recipient sites system immediately.
  • the recipient site can see what their IPG content looks like on their own system even before the media file arrives. This is because the system takes the content provider's data and transforms it into recipient site-specific data immediately upon ingestion in process blocks 150 - 154 .
  • the system includes a multicast asset data packaging subsystem and method, which is part of the package determination process 152 of FIG. 1 .
  • a single media file 400 is used for distribution to two or more recipient sites.
  • a first recipient site has first parameter requirements for processing the media file 400
  • a second recipient site has second parameter requirements for processing the media file 400 that are different from the first parameter requirements.
  • a first set of parameters 404 is included in the media file that meets the first parameter requirements.
  • a second set of parameters 408 is included in the media file 400 that meets the second parameter requirements.
  • the first set of parameters 404 are for use during distribution to the first recipient site
  • the second set of parameters 408 are for use during distribution to the second recipient site.
  • a third set of parameters 412 is included in the file to meet the parameter requirements of a third recipient site.
  • Each of the first 404 , second 408 and third 412 sets of parameters are each identified by customer identifiers 402 , 406 and 410 respectively in the media file 400 .
  • the media file 400 includes a main body portion, wherein the actual media file content 450 is stored for eventual presentation in a recipient site viewing system.
  • the system 100 has the ability to superset (combine multiple media files into one larger multicast file encompassing all the data of the disparate media files) customized metadata for a recipient site, as well as delivery and interface parameters into a single media file 400 .
  • To multicast means using a single transmission of a digital file to multiple reception points simultaneously.
  • the claimed system allows a multicast channel to be used in a more efficient manner, and to centralize coordination of all remote recipient site requirements.
  • the system also allows a single docking station 186 to offload files to a discrete list of destinations without having to send the media file 400 to all of those destinations.
  • the media file 400 allows for use of a method of distribution whereby the same file is sent to all applicable receiving sites at the same time.
  • the media file 400 is a media or digital file for use in video playback, gaming or any other digital file.
  • This file 400 is sent over a satellite link ( 190 in FIG. 1 ), the Internet, or the like, from the central system 100 to a local server. It arrives on that server and is moved to a server for a receiving customer when a data control file arrives for the media file 400 .
  • the data parameters and/or files required by each site are built into one aggregate media file 400 .
  • Each section of that file 400 is targeted for a specific receive site, thereby keeping the localizing functionality, but requiring only one media file 400 to be sent over the multicast.
  • the receiving site's equipment need know only the site's unique customer identifier 402 , 406 or 410 in order to extract the proper parameter data set for its use.
  • the data within the media file 400 is customizable by recipient site.
  • the price of the media file 400 or menu location being used by the on-screen guide can be recipient site-specific for each receiving recipient customer site.
  • the media file 400 itself can appear to have multiple formats (XML, iTV, or any other widely accepted digital format), even though the specific format of the file as used by a recipient site is part of the larger aggregate of the file 400 , thereby enabling interaction with any format of receiving site.
  • the media file 400 also contains, for each recipient site as part of the parameters 404 , 408 , 412 , interface and delivery specifications unique to each recipient site. Examples include the specific IP address for each recipient site's video server, the interface protocol required at that site (ADI, Windows, FTP), the version of metadata file required at that particular site (XML, iTV), and how the media file 400 should be processed after it is transferred from the central system 100 to the receiving customer (e.g., delete immediately, stay on the system server for 24 hours etc.) as indicated by the parameters 404 , 408 , 412 . This information tells the recipient sites how to react to, and act on, each file 400 it is receiving individually.
  • ADI interface protocol required at that site
  • XML, iTV version of metadata file required at that particular site
  • the system enables a site to change the delivery address of it's video on demand (VOD) server without having to stop the system 100 from offloading while it is reconfigured, since the parameter information is in each title as it arrives.
  • VOD video on demand
  • This parameter information 404 , 408 , 412 is contained in the header of each data file 400 , and is populated by the system each time a file 400 is built for distribution. This enables a receiving server to receive located at a site-specific control information on an file-by-file basis without that information having to be stored in the recipients data file, which, in some cases would violate industry standards.
  • the header is stripped off the file before storage in the file to the recipient site's system.
  • This aggregation of the site-specific media data and delivery properties also has the effect of making a change at the centralized asset management system instantaneously applicable to any, or all, remote receiving and distribution sites without having to configure files for each site individually, or at the recipient site equipment itself.
  • software is used to implement the asset data packaging subsystem to create the media file 400 .
  • generalized metadata control file is ingested into the system for each media file 400 that the system is expected to distribute to customers.
  • This control file contains information specific to the media file 400 itself and, as such, is not specific to any recipient customer needs.
  • this control file is transmitted by the system and checked against expected values that the media file 400 is allowed to have (e.g., ESPN would not be allowed to enter into the system titles with an “X” rating), and the values are all normalized, that is, transformed into values the system can recognize and can key other functions off of.
  • the media file 400 is then run through a series of transformations, one for every customer recipient site it will be transmitted to.
  • the parameters are stored as site-specific data for each of those customers in the media file 400 .
  • these transformations include changing any provider-specific information, such as a product type, into a value desired by the recipient, applying the recipient site's correct price and royalty information, applying the correct content category, and transforming the raw data itself into the type of file each recipient site requires as each of their servers may be built on different operating systems.
  • the finalized information for each recipient site is aggregated into one file 400 containing the data and applicable file structure for every site to which it will be transmitted.
  • the media file 400 is built as a contiguous series of these site-specific control files, or sets of parameters 404 , 408 , 412 , each in the recipient's own site-specific format, containing site-specific control information and control data.
  • this file 400 is subsequently queued, process block 156 , and transmitted to each recipient.
  • the file 400 is searched for the applicable site-specific section(s). For each recipient site, the relevant section is extracted and stripped of any encompassing transmission-only control data portions. This leaves only the relevant file information in the proper format for each specific site, ready to be processed.
  • the remote site devices at the recipient sites need only know their assigned customer identifiers 402 , 406 , 410 in order to search the aggregate file for the recipient's relevant section and to extract the right parameters they will use to process the media file 400 .
  • This allows the control data for every distributed device to be modified and controlled at the centralized system, eliminating the need for data to be kept on remote servers or for extensive configuration changes to occur before transmission.
  • the claimed invention is a system and method for automated validation of a media file 400 for distribution.
  • a media file 400 having an asset type is received for distribution. It is validated according to one or more requirements for the asset type. As a result of the validation process, one or more errors typically are produced. These errors are corrected by applying a rules application to the media file. The media file 400 is then distributed.
  • processing and validation includes polling (process block 104 ), parsing, validating, normalizing, rules application, error checking (process block 150 ), package determination (process block 152 ), site-specific data transformation (process block 156 ), scheduling (process block 156 ), transmission (process block 158 ), and finally, reconciliation and tracking of the media file 400 .
  • the system 100 receives the media files 400 by polling. Polling is the automated receipt and scanning of content into the system. The system constantly signals all points on its network to determine if a media file has been input to any of them. If any media files 400 are found for input, the system downloads them, at process block 140 .
  • Parsing is the automated determination of the file type for each media file 400 coming into the system, and the application of the proper procedures to that media file based on the file type.
  • Validation is the determination of whether the incoming parameter data values and asset types match the expected incoming parameter data values and asset types based on certain criteria such as the inputting party or file format.
  • the system also checks for file-specific required constructs in the incoming data such as allowable lengths, time formats (24 hours vs. 12 hours) and ID structures such as Cablelabs requirements of 20-digit ID values.
  • Normalization means taking the validated incoming data and transforming it into system-specific formats and values so the data can be acted upon further by the system 100 . For example, date transformations occur for the recipient sites to provide a baseline from which to transform the media file 400 .
  • a rules application processes the media file 400 through a complex rules engine that is specific to the system 100 that enables the system 100 to set parameters and to format the media file 400 as necessary for further distribution to receiving customers.
  • this rules application process if a specific set of data contains specific values in certain fields, the accompanying file is priced at a certain level at some recipient sites but not at others. If a media file 400 enters the system priced at $2.99 instead of, $3.99 from a particular movie studio, the system determines that the media file 400 is a “special” title for example, a higher standard price such as and therefore changes the data set it applies to the media file for the recipient sites.
  • Some of the receiving sites might elect to make any media file available the standard price via their cable system, but others might decide to follow the lead of the studio and price the title at the special price.
  • a rule can be used to define that, if a certain content provider refuses to populate certain fields within the metadata, such as the content package description, the system uses other mandatory fields, such as the provider name and price, to analyze the media file, for example, divine that the package must be a specific package from a certain provider.
  • the system 100 then has the ability to run normal receiving site transformations on the media file 400 for distribution.
  • the rules engine applies intelligent rules to the data once it has been validated and normalized as the first part of ingestion.
  • the system 100 determines whether the incoming media file 400 is free of errors and unexpected values, and therefore whether the media file is ready to be approved for processing.
  • each media file 400 is assigned to a specific content package based on parameters in the media file's metadata. This assigned package determines the distribution list for that media file 400 .
  • the process of site-specific data transformation transforms the media file 400 into data requested by each recipient site in order to be applicable to their system-specific hardware, software, marketing wishes, and such.
  • the claimed invention is a system and method for automated determination of priority in processing a media file 400 for distribution to a recipient site.
  • a media file 400 is received for distribution, at process block 140 .
  • the media file 400 is processed to produce data parameters for distribution, process block 150 .
  • a receiving status of the recipient site is checked.
  • One or more of the data parameters are changed according to the receiving status of the recipient site.
  • the data parameters are changed according to a set or rules defined in a contract with the recipient site.
  • the media file 400 is then distributed to the recipient site according to the data parameters. Further, an interface is provided so as to allow the recipient site personnel to view status information regarding distribution of the media file 400 .
  • the claimed invention is a system and method for optimizing distribution of a media file 400 to a plurality of recipient sites.
  • a receive status of a first recipient site is checked, thereby producing a first status check result.
  • a receive status of a second recipient site is checked, thereby producing a second status check result.
  • a rules engine (process block 154 in FIG. 1 ) is applied to determine a priority for distribution to the first recipient site relative to the second recipient site.
  • the media file 400 is then distributed to the first recipient site and the second recipient site according to the determined priority.
  • the system 100 is the first asset management system to prioritize, reorganize and intelligently manipulate a multicast pitch, which is a single transmission of a media file 400 to multiple recipient sites simultaneously.
  • the system transmits media files 400 over a satellite or Internet protocol data network based on a schedule.
  • the schedule is derived based on when the need of the media file 400 is to be transmitted to the recipient sites.
  • This transmission is a multicast transmission to a predetermined combination of destinations, each with varying ability to receive media files 400 based on the equipment status at each recipient site.
  • One unique feature of the system 100 is its ability to optimize distribution efficiency by accounting for these status changes across its network and then reconciling those status changes with intelligent rules.
  • the system 100 applies intelligent rules to determine whether that transmission requires alteration.
  • one of those rules defines a minimum percentage of recipient sites that must have a “good” receive status before allowing transmission of the media file.
  • the system's automated decision-making process takes into account whether a non-functional recipient site has not received the media file 400 .
  • the media file 400 can be retransmitted to that recipient site later.
  • the system may delay the entire transmission for a set period of time.
  • decisions are based on rules derived from individual recipient sites (e.g., ability to receive files at that moment) and asset properties (e.g., time left before the specific asset is required to be transmitted to its customer base), as well as other relevant states (e.g., transmission speed, quality of the channel).
  • asset properties e.g., time left before the specific asset is required to be transmitted to its customer base
  • other relevant states e.g., transmission speed, quality of the channel.
  • another circumstance that causes a status change to the media file 400 is the manual alteration of the transmission schedule.
  • the system 100 determines whether the change will have an undesired effect on another transmission or file status for a different media file 400 . Additionally, the system can predict when future transmission problems may occur, by calculating the performance of network components (e.g., bandwidth, speed, current transmission load), or anticipating upcoming requirements that may cause transmission failures. If a problem is predicted, the system adjusts the schedule accordingly.
  • network components e.g., bandwidth, speed, current transmission load
  • FIG. 5 a transmission specific flow diagram is shown that illustrates the data flow in performing prioritization and transmission of the media files 400 .
  • the transmission flow begins with the site-specific metadata transformer 500 passing data to the queue scheduler 502 .
  • the queue scheduler 502 applies scheduling rules to each incoming media file 400 based on rules located in both the package tables 504 and site tables 506 . These rules include a date range for pitch, a potential time range, priority, channel requirements, and such.
  • the scheduler Once the scheduler has the pitching parameters for an individual file 400 , it passes a reference to that asset to a queue table, which will store it in a preliminary pitch order.
  • This table is also viewable through the ARI 122 and PRI 120 , wherein users 560 can enter manual overrides, reprioritizations and re-pitches.
  • This table is periodically scanned by the transmission controller 158 .
  • the transmission controller 158 uses an offline queue 510 to instruct a media file manager 512 when to begin fetching media files from a media file data store 514 , and to route them to a pitch drive.
  • the controller 158 then calls site-specific metadata tables 516 to aggregate metadata into the media files using a media file creator module 520 .
  • the final file distribution list is sent to the multicast transmission subsystem at process block 522 .
  • the transmission subsystem is constantly sending and receiving status data across its network. While the system 100 is aggregating the network “health” information, it is applying what it finds to the list of media files 400 it has in its distribution transmission queue 510 . Each media file 400 to be distributed has site-specific parameters 404 , 408 , 412 that need to be taken into account, such as the earliest or latest it can be sent in order to meet its usability requirements.
  • the system 100 determines that a certain percentage of the receiving devices for a certain media file 400 are not on-line at the derived transmission time, the system applies that knowledge against a rules system. The system then determines if the media file 400 still has time to be delayed. It takes that information and looks at the next media file 400 in the transmission queue. If the distribution group of recipients for that media file is 100% online, it will transmit a different media file 400 instead, saving the problem media file 400 until such time as its distribution group is back on line for receiving. Alternatively, the file may need to be transmitted to whatever recipient in the distribution group is capable of capturing it due to timing constraints.
  • This intelligence combined with the ability to manually adjust the queue 156 , gives the system the unique ability to maximize the efficiency of its distribution bandwidth. There is a finite amount of content that can be sent in any timeframe, and the ability to transmit only when the highest percentage of targeted recipient sites can accept the media file 400 minimizes the need to retransmit files and maximizes the finite bandwidth available to the system.
  • the claimed invention is a system and method for providing connectivity in a media file distribution system 100 .
  • the system includes a data store 720 , a portion of which is for storing a media file 400 received from a content provider 702 .
  • a database in the data store 720 contains editable parameters for distribution of the recipient site.
  • the PRI 120 provides an interface to the database and allows the content provider 702 to edit the site-specific parameters 404 , 408 , 412 .
  • the ARI 122 further allows the recipient site to edit the parameters.
  • the distribution subsystem is configured for distributing the media file 400 according to the site-specific parameters, 404 , 408 , 412 .
  • the distribution subsystem includes connections to the Internet 10 and/or to a satellite communications link 190 .
  • the system allows customers at either usage end—i.e., receiving sites providers 702 and—the unique ability to view, edit and assign parameters 404 , 408 412 to a media files 400 in either their own or the other's system.
  • the claimed system 100 enables both content providers 702 and recipient sites to gain information relevant to their product and make relevant changes to their media files 400 within a single system.
  • the system is implemented by receiving edits and acting on the actual source media file 400 itself.
  • a content provider 702 wants to assign an approval for a certain recipient site to acquire its programming, a content provider 702 can do so remotely through the PRI 120 . If the recipient site signs up for that content, which can also be done remotely through the ARI 122 , the system 100 automatically requests parameters for assigning to the file for the recipient site (such as price, on-screen guide placement category, provider value), and it completes the transaction without any manual intervention.
  • the content providers 702 supply information about the content, such as the parameter values with which each file will arrive (suggested price, suggested rating, and such).
  • the receiving site can assign its desired site-specific parameters 404 , 408 412 to the file 400 as well through the ARI 122 .
  • the content provider 702 can display the parameter information and view exactly how the content is being offered to that particular receiving site's customers through the PRI 120 .
  • FIG. 7 Another example screen shot of the provider interface into the system 100 , the PRI 120 , is shown in FIG. 7 .
  • the provider is shown a list of available media packages for media files 400 stored in the data store 720 .
  • Another example screen shot from the ARI 122 is shown in FIG. 8 .
  • the recipient customer can enter pricing information, package name information, a product description, transmission priority, and rating information for the package, which are customizations that can be viewed, edited, and/or validated by the content provider 702 in the ARI 122 in a similar screen. In this way, because both content providers and recipient sites have access to data within the system applicable to each other, they are able to view and change the data for customization to their own systems.
  • Content providers 702 are able to authorize a recipient site's ordering of a package containing the content provider's media file 400 , and the system eliminates the need for manual assignment of that recipient site into the transmission distribution list for the media file 400 .
  • the recipient sites are able to view and edit the metadata associated with the media file 400 over the Internet, which allows them to set the data without having to create their own separate system to do so.
  • a content provider 702 submits content into the system (i.e., the content provider 702 sends a media file along with the controlling metadata file with its appropriate asset-specific information)
  • the media file 400 is checked against expected properties and approved for ingestion into the system, as described above. These properties and values are then, through a series of steps, modified to the individual requirements of each individual recipient site wishing to receive that content, as described above. Those site-specific values are then assigned to that recipient site within the central database in the data store 720 , and displayed to the customer prior to transmission.
  • the recipient site has the ability to change any values prior to transmission through the ARI 122 .
  • the site-specific parameters 404 , 408 , 412 follow certain expected criteria and value ranges. Automated assignment of at least some of those values is triggered by the expected input values and assignment of others is triggered by the expected outbound values for the site-specific parameters 404 , 408 , 412 of the media file 400 .
  • the system 100 allows the recipient sites to see the inbound media files 400 in order to transform it from 100 any way they see fit.
  • the system also allows the inputting customers, i.e., the content providers 702 , to see the results of their data being transformed by the recipient sites. Since both sets of data reside within a single data store 720 , it is possible to display both sets to users at either end of the distribution chain.
  • a content provider 702 can assign contract values or on-screen display values to a particular video asset in a media file and restrict the recipient sites to which the media file is made available from changing those values. The content providers can then see the end result by looking at the actual data within the system. They can also authorize or de-authorize specific recipient sites within the system for receiving an media file 400 in the first place, simply by logging into the system and assigning parameters to their content, such as which recipients can or cannot receive particular media files 400 .
  • Recipient sites can see the incoming values the content provider 702 makes available with the content providers assets and then the recipient sites can set up transformations to those assets prior to or after transmission to its own equipment.
  • the recipient sites can stop specific media files from coming to their system if the media files for those assets contain certain data types (such as those with an “X” rating, and the like.).
  • a recipient site can request certain media files if they have not already been authorized for them, and they can track the input delivery timeframes to see whether a media file will be transmitted as expected. This ability to act on the actual data inputted by the content providers means the system is the only place participating content providers and recipient sites need to view, enter and edit the parameter data, and it gives them the ability to do so at any point in time along the media file 400 asset lifecycle.
  • the claimed invention is a system and method for providing interactive program guide entry for a media file 400 .
  • a distribution hub (data store 720 in FIG. 6 ) stores a media file 400 received from a content provider 702 for distribution to a recipient site.
  • An interface to the distribution hub (ARI 122 ) allows editing of program guide data for the media file.
  • the interface stores the program guide data as site-specific parameters 404 , 408 , 412 to the media file 400 .
  • the interface further allows the content provider to view the program guide data for the media file 400 .
  • the interface further allows the content provider 702 , through the PRI 120 , to edit the program guide data, and to set parameters regarding editing of the program guide data by the recipient.
  • GUI graphical user interface
  • the recipient site e.g., cable company or telephone company.
  • the recipient site maps every asset it receives on its video-on-demand VOD servers to an IPG menu location prior to the asset's arrival within its system, and the data files accompanying each digital file preferably contain this information.
  • the claimed system graphically links the content provider 702 and recipient site's IPG. This enables the recipient site to do the manually intensive mapping process on an easily manipulated graphic user interface, available in the ARI 122 . Through the same interface, the system also provides the ability to link incoming content providers' menu data to IPG menu.
  • a media file 400 sent by the system to a recipient has a field in the site-specific parameter 404 , which carries the hierarchical menu data that defines the destination on the recipient site's IPG.
  • This IPG might be displayed, for example, on a television, set-top box, web page, phone or any other electronic system.
  • the media files 400 being input into system by the content provider 702 contain a generalized value in this field, used more as a characteristic of the asset contained in the media file than an expected display value.
  • This generalized value is transformed into a specific value for each recipient site to use in processing the media file 400 which, in one embodiment, comprises taking any expected potential incoming menu value and performing a site-specific transformation (per recipient site) on it, based on previously entered information about the recipient site's IPG.
  • FIGS. 9 and 10 example embodiments of IPG editing screens that can be presented from the ARI 122 are shown.
  • a graphical menu builder provides easy IPG entry into the IPG parameters 404 of the media file 400 .
  • Recipient sites have the ability to enter, map, move, replace, delete and populate menu locations through this easily usable interactive GUI.
  • FIG. 10 illustrates the screen shown after selection of the “Outdoor Life Network” entry in the screen show in FIG. 9 .
  • the claimed invention is a system and method for providing a multi-port catcher 146 .
  • the system includes a computer 108 , a data store 514 (or 720 in FIG. 6 ), and a network connection 106 for connecting the computer to a network.
  • a partition application is executed on the computer 146 to partition the computer into multiple partitions.
  • a catcher application 146 (a remote receiving computer that receives and rebuilds the transmitted files) executes in each partition.
  • Each catcher application 146 is capable of receiving a separate media file 400 over the network connection, simultaneously.
  • Each media file 400 is stored in the data store 514 .
  • the system may use a plurality of catcher applications 146 , wherein, for example, a first partition executes a first catcher application 146 , and a second partition executes a second catcher application 146 . Therefore, the first catcher application 146 can use a different protocol than the second catcher application 146 .
  • the partition application is configured to divide processing of a processor of the computer into virtual computers, such that each of the media files 400 is received by a partition executing on one of the virtual computers.
  • one of the partitions is configured as a content provider itself, such that one or more of the media files 400 can be provided internally from the data store into the catcher 146 without using a separate computer 108 to provide the one or more media files 400 to the catcher 146 .
  • one of the partitions is further configured as a gateway computer to provide gateway processing, such as SMTP 144 , FTP 148 , and/or encoding/offloading functions 149 , for each of the other partitions.
  • the catcher 146 is implemented as a file reception server 800 located at a recipient customer location or cable head end, executing catcher partitions 146 a and 146 b .
  • the system 100 allows one catcher 146 to receive multiple asset reception streams/transmissions from multiple distributors, all organized and reported on from the centralized database in the data store 720 .
  • a “catcher” has one reception path that validates and offloads the received files onto the destination server for the received files (the recipient sites equipment).
  • the partitions 146 a and 146 b on the catcher 146 enable multiple, unique, exclusive reception paths for multiple transmission systems to deliver media files 400 to it.
  • the media files 400 are treated uniquely based on their origination point, but the data is entered into the central data store 720 (by way of the catcher sending it back to the central system), giving one point of reference to the recipient site. This is unique because previously, any recipient site that required content delivered from multiple sources required multiple catchers (one per source), and a separate physical gateway to manage the multiple offloads into one destination video server.
  • the catcher 146 of the presently claimed system is capable of not only receiving multiple inbound transmissions from different sources on the same hardware platform, but it is also capable of performing the gateway traffic management function, thereby consolidating previously disparate functions into one.
  • the catcher 146 also includes the ability to ingest a local media file 400 without the need for it to be transmitted from a remote destination.
  • a software application executes internally in the computer to partition a single computer into multiple receiving points 146 a and 146 b .
  • Each partition has the ability to execute industry standard file-movement protocols within the same computer 108 .
  • This allows the catcher 146 to receive multiple streams from different satellite receivers, from locally introduced content over an IP network, or from another catcher 147 physically attached to the catcher 146 .
  • the media files 400 are offloaded from the catcher 146 through one point, eliminating the need for the recipient site to put a separate gateway on the network.
  • the media files 400 are aggregated into the centralized data store 720 , thereby allowing the recipient site to perform data manipulation and reporting from one system regardless of the origination point of the transmission.
  • each catcher 146 a , 146 b is implemented in software. This software scans both internal folders in catcher 146 and external folders on the network to which the catcher 146 is attached. These files are brought into a staging area/folder in the catcher 146 . The metadata associated with those files (which arrives with the files) is sent back through the Internet to the centralized data store 720 . With reference back to FIG. 1 , the metadata is then scanned for compliance, process block 150 in FIG. 1 , which includes analyzing the media file 400 to determine the identity of the content provider 702 , and normalizing the site specific parameters 404 , 408 , 412 into a standard set of values the recipient site has requested.
  • the parameters 404 , 408 , 412 are stored into the multicast structure, and the data is re-sent to the catcher 146 .
  • the system then moves the submitted digital file 400 off of the central data store 720 onto the recipient site's video server. Should a media file 400 that is not allowed or expected arrive on the system catcher 146 from an outside source, the file is quarantined on the catcher 146 and not moved to the central data store 720 .
  • the centralization in the system allows the recipient site to view all of its digital file parameter and media data in one central place, and also allows it to use that same system to update media files 400 across the entire set of sites it owns from one place, regardless of whether or not those media files originated from the central data store 720 .
  • the claimed invention is a system and method for administrating a contract for distribution of a media file 400 .
  • a media file 400 is received from a content provider 702 , after which, contract parameter data is entered into the media file 400 according to a contract between the content provider and a recipient site. Metadata is calculated for the media file 400 based on the contract parameter data, which is stored in the site-specific parameters 404 , 408 , 412 of the media file 400 .
  • the media file 400 is then distributed to the recipient site.
  • the site-specific parameters 404 , 408 , 412 include price limitations for the price that the recipient site can charge viewers for viewing of the media file 400 .
  • the contract parameter data 404 , 408 , 412 include time limitations defining limitations regarding a time that the recipient site can present the media file 400 .
  • the contract management system enables functions for the administration of a contract (between any or all of content providers, distributors, recipient sites, studios or other applicable parties) with respect to a media file 400 .
  • these functions include a contract to derive N number of unique, site-specific financial parameters for use in multiple places within the system, and the unique use of contract entity building blocks (such as provider, receiver or distributor element) to determine financial fulfillment and processing.
  • one entity has the option of managing contracts in one of two different ways, either by using package properties or by using site properties of the site-specific parameters 404 , 408 , 412 .
  • a choice is presented to the user for selecting the level not selected in step 1100 (i.e., if the option for package properties was selected, the site properties are selected).
  • the user can view the hierarchy of the package recipient sites sorted by MSO, and the recipient sites they each own.
  • the recipient site of content provider 702 can then select any of these groups (the entire set of package recipient sites or any number of MSO's and/or sites) for contract creation or editing.
  • the level to be applied is selected, which includes by package, MSO, or recipient site, at step 1104 . If the selected level doesn't have a contract already created, step 1106 , the system 100 offers the opportunity to create the contract or contracts, at step 1108 . If a recipient site group is selected and applied in bulk by using MSO or package editing, and some of the recipient sites do not yet have a site contract, then one will be created for those that do not already have one, at step 1110 . Then all recipient sites under the contract parameters are updated to reflect the choice of contract to use for the sites, at step 1112 . Otherwise, if the user chose not to create a contract when there was no contract in place for a package, MSO or recipient site, then those sites that are left without contracts are marked with an error condition in the system, step at 1114 .
  • the user can view all packages that exist, and the packages to which a recipient site belongs. If a new package for a recipient site is selected, the user is taken to a contract application level selection screen, where the user can chose contract editing by package, MSO, or recipient site. The user can also select a package for which the recipient site is already a member, and update contract parameters. As explained above, if the newly chosen level doesn't yet have a contract created, the user is offered the choice to create the contract.
  • parameter data reflecting the contract is stored in the package tables of FIG. 1 .
  • the package tables are read and the appropriate parameters are inserted into the site specific parameters 404 , 408 , 412 into the media file 400 .
  • the system 100 when choosing a contract level (through site properties) the system 100 shows all three potential levels, the package level 1200 , the MSO level 1202 , and the recipient site level 1204 , whether or not a contract is available on those levels.
  • the system displays an indicator showing whether a contract exists at that level. If a contract is created by the system, initially, a contract template 1206 is used to form the contract, after which, the contract is modifiable.

Abstract

There is disclosed a media file distribution system and method. An asset management and delivery system and method for the distribution of digital files and data is provided. There are two major functions, with sub-functions within each. The system first serves as a fully automated management system for a company involved in video/file distribution, such as in video on demand (VOD) or other digital file industries. The system can ingest, prepare, schedule, transmit, track and report on any aspect of the business chain. Secondly, it also serves as a product for both content providers and recipients to be able to view, manage and run their entire content offering remotely from anywhere through the Internet.

Description

    CROSS-REFERENCE TO RELATED APPLICATION(S)
  • This is a divisional of U.S. application Ser. No. 11/182,724, filed on Jul. 15, 2005. The contents of which are incorporated herein by reference.
  • COPYRIGHT NOTICE
  • A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
  • FIELD OF THE INVENTION
  • This invention relates generally to a media file distribution system and method, and more particularly, to a system and methodology that provides end-to-end management of distribution of a media asset.
  • BACKGROUND OF THE INVENTION
  • The task of distributing media files from network content providers to recipient media front-end customers, such as cable providers, and the like (collectively called “recipient sites” herein), has become a complex process. This is mainly due to competing interests in file formats, transmission protocols, processing requirements, program guide entry format, and various other parameters configured according to different standards as amongst the various content and service providers involved in the distribution process. Accordingly, inordinate amounts of time are now spent converting formats in order for content providers, distributors, and the recipient site customers to manipulate and modify media files throughout the distribution process in order to comply with their diverse system requirements.
  • The typical media file is a media/digital file for use in video playback, gaming, or any other digital medium. Such a file is sent over satellite, the Internet, or other network, to those involved in distribution and final presentation to the public from the front end or to the recipient site customers. A data control file arrives with the media file which data file must be constantly modified with each conversion to a new system. Current systems typically transmit the control file in one of three ways. The first is to target a unique metadata control file to each receiving site, thereby requiring N number of files for N sites. The second way is to send one generalized file to all receiving sites and then have a site-specific transformation occur at each site dictated by information stored at each site that is triggered by the general information in the control file. A third way to is to send one control file to all receiving sites and then to require each site to process the one format in that control file to be used, but this approach precludes any site specificity. In each of these approaches limitations are necessarily imposed on, for example, the amount and types of different properties that can be applied to an ingested media file, and its distribution characteristics. Further, multiple systems are required, increasing the working time and likelihood of errors, as well as causing synchronization issues. For example, these approaches can be characterized by the frequent failure of in-bound value readers to pass data that is expected by site-specific transform mechanisms. Users in these media distribution system are then forced to manually adjust all of the media assets within the schedule accordingly, while continuing to monitor any additional changes that might be introduced by any of the entities that play a role in, or that otherwise involved in the overall media distribution system.
  • In summary, no current system performs end-to-end automated ingestion and monitoring of media assets.
  • BRIEF SUMMARY OF THE INVENTION
  • Briefly, and in general terms, the claimed invention resolves the aforementioned and other problems by providing a media file distribution data system and method. A single media file is used for distribution to two or more recipient sites. A first recipient site has first parameter requirements for processing the media file, and a second recipient site has second parameter requirements for processing the media file that are different from the first parameter requirements. A first set of parameters is included in the media file that meets the first parameter requirements. Further, a second set of parameters is included in the media file that meets the second parameter requirements. In this regard, the first set of parameters is for use during distribution to the first recipient site, and the second set of parameters is for use during distribution to the second recipient site.
  • In accordance with another aspect of a system and method for automated processing of a media file for distribution. In the distribution system and method, a media file is received for distribution. The media file has an asset type, and is validated according to one or more requirements according to the asset type. As a result of validating, one or more errors are produced. These errors are corrected by applying a rules application to the media file. The media file is then distributed.
  • In accordance with another aspect of a system and method for automated processing of a media file for distribution to a recipient site. A media file is provided for distribution. The multi-media file is processed to produce data parameters for distribution. A receiving status of the recipient site is checked. One or more of the data parameters are changed according to the receiving status of the recipient site. For example, according to one embodiment, the data parameters are changed according to a set or rules defined in a contract with the recipient site. The media file is then distributed to the recipient site according to the data parameters. Further, an interface is provided so as to allow an operator of the recipient site to view status information regarding distribution of the media file.
  • In accordance with another aspect of a preferred embodiment, the claimed invention is a system and method for optimizing distribution of a media file to a plurality of recipient sites. A receive status of a first recipient site is checked, thereby producing a first status check result. A receive status of a second recipient site is checked, thereby producing a second status check result. Based on the first status check result and the second status check result, a rules engine is applied to determine a priority for distribution to the first recipient site respective of the second recipient site. The media file is then distributed to the first recipient site and the second recipient site according to the determined priority.
  • In accordance with another aspect of a preferred embodiment, the claimed invention is a system and method for providing connectivity in a media file distribution system. The system includes a data store, a portion of which is for storing a media file received from a content provider. A database in the data store contains editable parameters for distribution to the recipient site. An interface to the database allows the content provider to edit the parameters. The interface further allows the recipient site to edit the parameters. A distribution “sub system” is configured for distributing the media file according to the parameters.
  • In accordance with another aspect of a preferred embodiment, the claimed invention is a system and method for providing interactive program guide entry for a media file. A distribution hub stores a media file received from a content provider for distribution to a recipient site. An interface to the distribution hub allows editing of program guide data for the media file. The interface stores the program guide data to the media file. The interface further allows the content provider to view the program guide data for the media file. In one embodiment, the interface further allows the content provider to edit the program guide data, and to set parameters regarding editing of the program guide data by the recipient site.
  • In accordance with another aspect of a preferred embodiment, the claimed invention is a system and method for providing a multi-port catcher. The system includes a computer, a data store, and a network connection for connecting the computer to a network. In one aspect of this embodiment, a partition application is executed on the computer to partition the computer into multiple partitions. A catcher application executes in each partition. Each catcher application is capable of receiving a separate media file over the network connection, simultaneously. Each media file is stored in the data store. The system may use a plurality of catcher applications, wherein, for example, a first partition executes a first catcher application, and a second partition executes a second catcher application. Therefore, the first catcher application can use a different protocol than the second catcher application. In this sense, the partition application is configured to divide processing of a processor of the computer into virtual computers, such that each of the media files are received by a partition executing in one of the virtual computers.
  • In one embodiment, one of the partitions is configured as a content provider itself, such that one or more of the media files can be provided internally from the data store into the catcher without using a separate computer to provide the one or more media files to the catcher. In this or other embodiments, one of the partitions is further configured as a gateway computer to provide gateway processing for each of the other partitions.
  • In accordance with another aspect of a preferred embodiment, the claimed invention is a system and method for administrating a contract for distribution of a media file. A media file is received from a content provider, after which, contract parameter data is entered into the media file according to a contract between the content provider and a recipient site. Metadata is calculated for the media file based on the contract parameter data. The media file is then distributed to the recipient site. In one embodiment, by way of example, and not by limitation, the contract data includes price limitations that the recipient site can charge for viewing of the media file. As another example, and not by limitation, the contract data includes time limitations defining limitations regarding a time that the recipient site can present the media file.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is network block data flow diagram illustrating components and steps performed in a media file distribution system and method according to one embodiment;
  • FIG. 2 is a screen shot from an example interface for a content provider for the system and method of FIG. 1;
  • FIG. 3 is a screen shot from an example interface for a content recipient site for the system and method of FIG. 1;
  • FIG. 4 is a block diagram illustrating field portions of a media file formatted according to one embodiment;
  • FIG. 5 is a network block data flow diagram illustrating components and method steps in a transmission “sub system” and method according to the embodiment illustrated in FIG. 1;
  • FIG. 6 is a network block data flow diagram illustrating data flow between content providers, catchers, and a data store, according to one embodiment;
  • FIG. 7 is a screen shot from an example asset tracking interface for a content provider for the system and method of FIG. 1;
  • FIG. 8 is a screen shot from an example package profile editing interface for a content provider for the system and method of FIG. 1;
  • FIG. 9 is a screen shot from an example interactive program guide editing interface for a recipient site for the system and method of FIG. 1;
  • FIG. 10 is another screen shot from an example interactive program guide editing interface for a recipient site for the system and method of FIG. 1;
  • FIG. 11 is data flow diagram illustrating steps performed by a contract manager “sub system” according to one embodiment; and
  • FIG. 12 is data flow diagram illustrating the flow of data for applying a contract template to create contract parameters for a media file according to one embodiment.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Referring now to the drawings, wherein like reference numerals denote like or corresponding parts throughout the drawings and, more particularly to FIGS. 1-12, there is shown one embodiment of a media file distribution system in accordance with the claimed invention. Specifically, the claimed invention provides an asset management and delivery system for the distribution of digital files and data. The system has two major functions, with sub-functions within each. The system first serves as a fully automated management system for a company involved in video/file distribution, such as in video on demand (VOD) or other digital file industries. The system can ingest, prepare, schedule, transmit, track and report on any aspect of the business chain. Secondly, it also serves as a product for both content providers and recipient sites to be able to view, manage and run their entire content offering remotely from anywhere through the internet.
  • There are three typical users for the system. One is any company or individual distributing digital media and associated information. They would typically use the system to automate distribution. Another user is a content provider in the digital media space. This entity can use the system to enter assets, track them at their destination, and receive reports on them. Another typical user is a receiving client or customer who can use the system to view and alter their assets, and schedule, monitor or change their receiving equipment setup or architecture. With each “sub module” described as follows, the usefulness of the claimed system will become apparent to those skilled in the art.
  • In one embodiment, the claimed invention has the ability to ingest media files and data, prepare them for transmission across the media industry, localize all the applicable data by customer and track, and reconcile the distribution of that data, all within the same system.
  • With reference to FIG. 1, the structure of the system 100 includes a series of components and functions. The first component is for asset ingestion into the system. Digital files and associated data are entered into the system in a variety of ways such as through standard file transfer protocol (FTP) or satellite transmission over a satellite link such as an outgoing satellite link 190 used for distribution. This data is then scanned for compliance to formats, quality, and expected parameter values, process block 150. The expected parameter values that are specific to each content provider are stored in provider tables 170, wherein the system compares the stored provider specific expected parameter values to those received with each media asset. Media package specific expected parameters are stored in package tables 504, wherein the system further compares those package specific expected parameters to the parameter values received with each media asset. To the extent that any parameters need to be added or are missing, the system calculates those parameter values based on data stored in metadata tables 516. Such calculated metadata may be archived into an archive table 176 for later review, or backup.
  • The digital files are then transformed into customer-specific formats, a process that begins at process block 152. In a package determination process, the metadata of the media file is processed and added to the file. The system 100 has the unique ability to be ingestion-format agnostic, meaning that, however the content provider would like to enter files into the system, it can recognize the interface type automatically, and perform the appropriate protocol to ingest the file, process block 154. The data is then queued, process block 156, and scheduled for transmission over any medium (e.g. over the satellite link 190, the Internet, and such), and prepared for that transmission. Before distribution, reporting information regarding each file to be transmitted is stored in transformed asset tables 159.
  • The actual distribution is then performed, process block 158. In the example of FIG. 1 transmission of the media files 190 occurs via satellite 190 through a communication server 160, to docking stations 186 at the recipient site head ends. After distribution, the media files are tracked, reconciled, and reported on, through a network management system (NMS) 188. This comprehensive approach enables any one area of the system 100 to affect properties and functionality of any or all of the other components, and to optimize the entire end-to-end performance of the system.
  • The system 100 enables users to author metadata (the control and information file for digital files in the video on demand environment) for video assets and export them for use. In one embodiment, the metadata affects the transmission of the media assets from content providers to recipient sites, such as multiple system operators (MSOs) receiving video-on-demand content. The system also performs gateway functionality, which in the context of one embodiment, includes aggregation of files from multiple transmission systems through one point of entry. This comprehensive control gives the system the unique capability of allowing any and all formerly disparate or disconnected functions of the distribution chain to interact with each other, thereby optimizing all functions and capabilities of the entire network and allowing file handling based on data from the entire distribution system 100.
  • In one sense, the system 100 functions as an automated file recipient system for content distributors to aggregate data and digital media files. These media files are ingested into the system 100 through an automated ingest subsystem, processing block 104. Once received the media files are manipulated and scheduled for distribution to the recipient sites or customers of the content providers, such as local cable companies and the like. The system 100 also allows those same content providers to author the parameter data for their media files directly through a provider remote interface sever (PRI) 120. In one embodiment, the parameter data is edited directly into the system or provided pre-formed into a folder on the network in order to be automatically ingested with the media file. Once entered, this parameter data is immediately transformed into data specific to the content recipient sites that will receive it later.
  • In another sense, the system 100 provides the ability for all the customers to view the media file and status data through the Internet at all points in the distribution chain, using an affiliate remote interface server (ARI) 122. The customers can log into the system over the web through the ARI 122, and view relevant media file data, not only in the original form in which it was entered, but also in the form after transformation in the system. For example, with respect to program guide data, parameter data can be viewed in a form, as it will appear when recipients display it to their cable or media viewers.
  • In one example, a content provider logs into the system to view the properties of their media file that are provided to a recipient, for example, a cable MSO. These properties include the price for viewing the media file from the affiliate, times or available times for viewing the media file, overrides to certain values found in the control metadata, such as provider or distributor information, and financial information, such as revenue splits. The providers can also view the interface the content recipients display to their viewers. FIG. 2 shows an example screen shot from PRI 120.
  • The media recipients can log in through the ARI 122, and can also review content available in the system. Through the ARI 122, media recipients can sign up to receive content, thereby added the media recipient to distribution lists for media files. The recipients can also view the media file content before making decision on which media files to receive. An example screen from the ARI 122 used to perform these functions is shown in FIG. 3.
  • In one embodiment, an example scenario with respect to ingestion and processing of a media file follows. At a network connection 106 in FIG. 1, a file first arrives at an ingestion server 108 without any manual intervention. The network connection 106 preferably comprises any high speed internet connection, such as a T1, T2 or high-end DSL connection. The ingestion server 108 reads the file's parameters, which are entered by the content provider, and the type of file is determined.
  • After initially receiving the media file, in one embodiment, a media file manager 512 manages processing of the file. For example, the media manager 512 can determine that the parameters of a media file require it to move immediately to the front of a satellite distribution queue, process block 156. The parameters read are a part of the corresponding metadata received with the file from the content provider. Certain fields are present in that data, such as the content tier, which tells the system the file type, which defines processing rules that are applied to the file in process block 154. In this step, parameters related to one or more contracts between the recipient and the content provider are added to the aggregate file, as described below with respect to FIGS. 11-12. The contract parameters may be determined from contract data in financial/contract tables 172. At that time, financial reports regarding the file are calculated and stored in a financial reporting module 174.
  • Since, in this example, the parameters indicate that immediate processing is necessary, the file is then moved across an internal system 100, transmitted immediately, and reported on immediately so that all the recipient sites have it as quickly as possible.
  • In another example, a media file that arrives late automatically triggers a change in any previously scheduled transmission date within its parameters. This change flows through the entire system where parameters for that media file are kept. The system changes the availability date for that media file within its associated metadata. That change affects any financial projections, which are also automatically figured from the same data.
  • Further in another example, a change in receiving status/capability of one of the remote recipient sites triggers a change in the expected transmission schedule should that recipient site be part of an upcoming scheduled distribution. This status affects the transmission order and timeline, and the changes populate back through the system. For example, should a number of recipient sites be unable to receive the media file at the time they are intended to receive transmission from the distribution, the system automatically changes the schedule for distribution according to one or more set of rules. The schedule may be changed to the next immediate distribution, or a distribution that occurs the next hour or later to allow those sites change to a favorable receiving status. With this feature of automated transmission, time updating has the effect of optimizing the use of transmission making the system more efficient.
  • If there is an automatic parameter change, such as in the examples regarding time of transmission described above, other subsystems in the claimed system, such as a contract management subsystem, determine rules for proceeding and adjust data surrounding the media file accordingly. For example, the contract management rules might require the media file to be sent to a recipient site regardless of the receiving status of the recipient site. Alternatively, a rule may define the latest date that a media file may be sent. In that case, similarly, if the latest send-date indicates that the media file cannot be delayed any longer, the media file is required to be sent regardless of the receiving status of the target recipient site in the distribution. Content providers viewing data in the system see these changes in real time and related report data is also changed applicably.
  • Changes can also be made manually. If parameters for a media file are changed by one of the content providers or recipient sites through the PRI 120 or the ARI 122, the changes can be made anywhere in the distribution chain, including post transmission, because all of the subsystems are integrated. If distribution for the media file has already occurred, an updated media file recipient sites remote locations. This means that the content provider can change the availability dates for an individual media file by logging onto the web, pulling up the data for that particular media file, changing the availability dates, and the system will change the availability dates not only within the system 100 itself, but also at all at the file's destinations. The system sends updated copies of the media file if necessary (over satellite, internet etc.) to perform the updates. Users at the recipient sites can also change data surrounding that asset and the same functions will apply. The system also has rules that allow the content providers to change certain data such as availability windows for the media file, but the recipient sites are allowed to change other data that is applicable to their specific systems, such as price. The identification of which entities are allowed to change which parameter fields can be stored as additional parameters in the media file itself.
  • This end-to-end visibility and system interoperability enables the system to affect any asset at any part of the distribution and management chain. The claimed system is the only asset management system with this scope and combination of functionality.
  • One of the functions of the system 100 includes interactive program guide (IPG) metadata authoring. Some prior systems enable users to author IPG metadata, but only the claimed system 100 enables entities to see exactly what that IPG metadata will look like at the eventual content recipient sites system immediately. In addition, the recipient site can see what their IPG content looks like on their own system even before the media file arrives. This is because the system takes the content provider's data and transforms it into recipient site-specific data immediately upon ingestion in process blocks 150-154.
  • In one preferred embodiment, the system includes a multicast asset data packaging subsystem and method, which is part of the package determination process 152 of FIG. 1. With reference to FIG. 4, a single media file 400 is used for distribution to two or more recipient sites. A first recipient site has first parameter requirements for processing the media file 400, and a second recipient site has second parameter requirements for processing the media file 400 that are different from the first parameter requirements. A first set of parameters 404 is included in the media file that meets the first parameter requirements. Further, a second set of parameters 408 is included in the media file 400 that meets the second parameter requirements. In this regard, the first set of parameters 404 are for use during distribution to the first recipient site, and the second set of parameters 408 are for use during distribution to the second recipient site. Similarly, a third set of parameters 412 is included in the file to meet the parameter requirements of a third recipient site. Each of the first 404, second 408 and third 412 sets of parameters are each identified by customer identifiers 402, 406 and 410 respectively in the media file 400. The media file 400 includes a main body portion, wherein the actual media file content 450 is stored for eventual presentation in a recipient site viewing system.
  • In this sense, the system 100 has the ability to superset (combine multiple media files into one larger multicast file encompassing all the data of the disparate media files) customized metadata for a recipient site, as well as delivery and interface parameters into a single media file 400. To multicast means using a single transmission of a digital file to multiple reception points simultaneously. The claimed system allows a multicast channel to be used in a more efficient manner, and to centralize coordination of all remote recipient site requirements. Referring again to FIG. 1, the system also allows a single docking station 186 to offload files to a discrete list of destinations without having to send the media file 400 to all of those destinations.
  • This structure of the media file 400 allows for use of a method of distribution whereby the same file is sent to all applicable receiving sites at the same time. In one embodiment, the media file 400 is a media or digital file for use in video playback, gaming or any other digital file. This file 400 is sent over a satellite link (190 in FIG. 1), the Internet, or the like, from the central system 100 to a local server. It arrives on that server and is moved to a server for a receiving customer when a data control file arrives for the media file 400. The data parameters and/or files required by each site are built into one aggregate media file 400. Each section of that file 400 is targeted for a specific receive site, thereby keeping the localizing functionality, but requiring only one media file 400 to be sent over the multicast. The receiving site's equipment need know only the site's unique customer identifier 402, 406 or 410 in order to extract the proper parameter data set for its use.
  • In this since, the data within the media file 400 is customizable by recipient site. For example, the price of the media file 400 or menu location being used by the on-screen guide can be recipient site-specific for each receiving recipient customer site. Further, the media file 400 itself can appear to have multiple formats (XML, iTV, or any other widely accepted digital format), even though the specific format of the file as used by a recipient site is part of the larger aggregate of the file 400, thereby enabling interaction with any format of receiving site.
  • The media file 400 also contains, for each recipient site as part of the parameters 404, 408, 412, interface and delivery specifications unique to each recipient site. Examples include the specific IP address for each recipient site's video server, the interface protocol required at that site (ADI, Windows, FTP), the version of metadata file required at that particular site (XML, iTV), and how the media file 400 should be processed after it is transferred from the central system 100 to the receiving customer (e.g., delete immediately, stay on the system server for 24 hours etc.) as indicated by the parameters 404, 408, 412. This information tells the recipient sites how to react to, and act on, each file 400 it is receiving individually. This enables recipients to be unrestricted in their interactive behavior since the site itself no longer requires parameters to be set within it, but rather can adopt asset-specific parameters each time a file 400 arrives because of the control information contained within that file 400 by virtue of the parameters 404, 408, 412. This enables functions such as prioritizing files, wherein a media file 400 can be prioritized so that it jumps ahead in the sequence of transfer to the server it will reside on if it is a time-sensitive title. Or, the system enables a site to change the delivery address of it's video on demand (VOD) server without having to stop the system 100 from offloading while it is reconfigured, since the parameter information is in each title as it arrives. This parameter information 404, 408, 412 is contained in the header of each data file 400, and is populated by the system each time a file 400 is built for distribution. This enables a receiving server to receive located at a site-specific control information on an file-by-file basis without that information having to be stored in the recipients data file, which, in some cases would violate industry standards. The header is stripped off the file before storage in the file to the recipient site's system.
  • This aggregation of the site-specific media data and delivery properties also has the effect of making a change at the centralized asset management system instantaneously applicable to any, or all, remote receiving and distribution sites without having to configure files for each site individually, or at the recipient site equipment itself.
  • In one embodiment, software is used to implement the asset data packaging subsystem to create the media file 400. With reference back to FIG. 1, the steps performed by the software and the flow of data through the system components are illustrated. At process block 104 generalized metadata control file is ingested into the system for each media file 400 that the system is expected to distribute to customers. This control file contains information specific to the media file 400 itself and, as such, is not specific to any recipient customer needs. At process block 150 this control file is transmitted by the system and checked against expected values that the media file 400 is allowed to have (e.g., ESPN would not be allowed to enter into the system titles with an “X” rating), and the values are all normalized, that is, transformed into values the system can recognize and can key other functions off of. At process block 152, the media file 400 is then run through a series of transformations, one for every customer recipient site it will be transmitted to. The parameters are stored as site-specific data for each of those customers in the media file 400. At process block 154, by way of example, and not by way of limitation, these transformations include changing any provider-specific information, such as a product type, into a value desired by the recipient, applying the recipient site's correct price and royalty information, applying the correct content category, and transforming the raw data itself into the type of file each recipient site requires as each of their servers may be built on different operating systems.
  • When transmission occurs, the finalized information for each recipient site is aggregated into one file 400 containing the data and applicable file structure for every site to which it will be transmitted. The media file 400 is built as a contiguous series of these site-specific control files, or sets of parameters 404, 408, 412, each in the recipient's own site-specific format, containing site-specific control information and control data. At process block 158 this file 400 is subsequently queued, process block 156, and transmitted to each recipient. At each recipient site, the file 400 is searched for the applicable site-specific section(s). For each recipient site, the relevant section is extracted and stripped of any encompassing transmission-only control data portions. This leaves only the relevant file information in the proper format for each specific site, ready to be processed.
  • In this process, the remote site devices at the recipient sites need only know their assigned customer identifiers 402, 406, 410 in order to search the aggregate file for the recipient's relevant section and to extract the right parameters they will use to process the media file 400. This allows the control data for every distributed device to be modified and controlled at the centralized system, eliminating the need for data to be kept on remote servers or for extensive configuration changes to occur before transmission.
  • In one embodiment, the claimed invention is a system and method for automated validation of a media file 400 for distribution. A media file 400 having an asset type is received for distribution. It is validated according to one or more requirements for the asset type. As a result of the validation process, one or more errors typically are produced. These errors are corrected by applying a rules application to the media file. The media file 400 is then distributed.
  • With reference again to FIG. 1, in one embodiment, processing and validation includes polling (process block 104), parsing, validating, normalizing, rules application, error checking (process block 150), package determination (process block 152), site-specific data transformation (process block 156), scheduling (process block 156), transmission (process block 158), and finally, reconciliation and tracking of the media file 400. In one embodiment, the system 100 receives the media files 400 by polling. Polling is the automated receipt and scanning of content into the system. The system constantly signals all points on its network to determine if a media file has been input to any of them. If any media files 400 are found for input, the system downloads them, at process block 140.
  • Parsing is the automated determination of the file type for each media file 400 coming into the system, and the application of the proper procedures to that media file based on the file type. Validation is the determination of whether the incoming parameter data values and asset types match the expected incoming parameter data values and asset types based on certain criteria such as the inputting party or file format. The system also checks for file-specific required constructs in the incoming data such as allowable lengths, time formats (24 hours vs. 12 hours) and ID structures such as Cablelabs requirements of 20-digit ID values.
  • Normalization means taking the validated incoming data and transforming it into system-specific formats and values so the data can be acted upon further by the system 100. For example, date transformations occur for the recipient sites to provide a baseline from which to transform the media file 400.
  • A rules application processes the media file 400 through a complex rules engine that is specific to the system 100 that enables the system 100 to set parameters and to format the media file 400 as necessary for further distribution to receiving customers. As an example of this rules application process, if a specific set of data contains specific values in certain fields, the accompanying file is priced at a certain level at some recipient sites but not at others. If a media file 400 enters the system priced at $2.99 instead of, $3.99 from a particular movie studio, the system determines that the media file 400 is a “special” title for example, a higher standard price such as and therefore changes the data set it applies to the media file for the recipient sites. Some of the receiving sites might elect to make any media file available the standard price via their cable system, but others might decide to follow the lead of the studio and price the title at the special price.
  • In another example, a rule can be used to define that, if a certain content provider refuses to populate certain fields within the metadata, such as the content package description, the system uses other mandatory fields, such as the provider name and price, to analyze the media file, for example, divine that the package must be a specific package from a certain provider. The system 100 then has the ability to run normal receiving site transformations on the media file 400 for distribution. In summary, the rules engine applies intelligent rules to the data once it has been validated and normalized as the first part of ingestion.
  • In the process of error checking, the system 100 determines whether the incoming media file 400 is free of errors and unexpected values, and therefore whether the media file is ready to be approved for processing.
  • In the process of package determination, at process block 152 in FIG. 1, each media file 400 is assigned to a specific content package based on parameters in the media file's metadata. This assigned package determines the distribution list for that media file 400.
  • The process of site-specific data transformation, a process block 154, transforms the media file 400 into data requested by each recipient site in order to be applicable to their system-specific hardware, software, marketing wishes, and such.
  • With reference again to FIG. 1, in one embodiment, the claimed invention is a system and method for automated determination of priority in processing a media file 400 for distribution to a recipient site. A media file 400 is received for distribution, at process block 140. The media file 400 is processed to produce data parameters for distribution, process block 150. As part of the processing step 150, a receiving status of the recipient site is checked. One or more of the data parameters are changed according to the receiving status of the recipient site. For example, according to one embodiment, the data parameters are changed according to a set or rules defined in a contract with the recipient site. The media file 400 is then distributed to the recipient site according to the data parameters. Further, an interface is provided so as to allow the recipient site personnel to view status information regarding distribution of the media file 400.
  • In one embodiment, the claimed invention is a system and method for optimizing distribution of a media file 400 to a plurality of recipient sites. A receive status of a first recipient site is checked, thereby producing a first status check result. A receive status of a second recipient site is checked, thereby producing a second status check result. Based on the first check result and the second check result, a rules engine (process block 154 in FIG. 1) is applied to determine a priority for distribution to the first recipient site relative to the second recipient site. The media file 400 is then distributed to the first recipient site and the second recipient site according to the determined priority.
  • The system 100 is the first asset management system to prioritize, reorganize and intelligently manipulate a multicast pitch, which is a single transmission of a media file 400 to multiple recipient sites simultaneously. The system transmits media files 400 over a satellite or Internet protocol data network based on a schedule. The schedule is derived based on when the need of the media file 400 is to be transmitted to the recipient sites. This transmission is a multicast transmission to a predetermined combination of destinations, each with varying ability to receive media files 400 based on the equipment status at each recipient site. One unique feature of the system 100 is its ability to optimize distribution efficiency by accounting for these status changes across its network and then reconciling those status changes with intelligent rules.
  • For example, if a recipient site in a distribution list for a specific multicast transmission of a media file 400 is not functioning at the time transmission is scheduled for that media file, the system 100 applies intelligent rules to determine whether that transmission requires alteration. In one embodiment, one of those rules defines a minimum percentage of recipient sites that must have a “good” receive status before allowing transmission of the media file. The system's automated decision-making process takes into account whether a non-functional recipient site has not received the media file 400. The media file 400 can be retransmitted to that recipient site later. Alternatively, the system may delay the entire transmission for a set period of time. These decisions are based on rules derived from individual recipient sites (e.g., ability to receive files at that moment) and asset properties (e.g., time left before the specific asset is required to be transmitted to its customer base), as well as other relevant states (e.g., transmission speed, quality of the channel).
  • In one embodiment, another circumstance that causes a status change to the media file 400 is the manual alteration of the transmission schedule. The system 100 determines whether the change will have an undesired effect on another transmission or file status for a different media file 400. Additionally, the system can predict when future transmission problems may occur, by calculating the performance of network components (e.g., bandwidth, speed, current transmission load), or anticipating upcoming requirements that may cause transmission failures. If a problem is predicted, the system adjusts the schedule accordingly.
  • With reference to FIG. 5, a transmission specific flow diagram is shown that illustrates the data flow in performing prioritization and transmission of the media files 400. Some of the components in FIG. 5 are also shown in FIG. 1 with respect to the overall system. The transmission flow begins with the site-specific metadata transformer 500 passing data to the queue scheduler 502. The queue scheduler 502 applies scheduling rules to each incoming media file 400 based on rules located in both the package tables 504 and site tables 506. These rules include a date range for pitch, a potential time range, priority, channel requirements, and such. Once the scheduler has the pitching parameters for an individual file 400, it passes a reference to that asset to a queue table, which will store it in a preliminary pitch order. This table is also viewable through the ARI 122 and PRI 120, wherein users 560 can enter manual overrides, reprioritizations and re-pitches. This table is periodically scanned by the transmission controller 158. The transmission controller 158 uses an offline queue 510 to instruct a media file manager 512 when to begin fetching media files from a media file data store 514, and to route them to a pitch drive. The controller 158 then calls site-specific metadata tables 516 to aggregate metadata into the media files using a media file creator module 520. When the parameters are properly packaged in the media file 400 for transmission, the final file distribution list is sent to the multicast transmission subsystem at process block 522.
  • The transmission subsystem is constantly sending and receiving status data across its network. While the system 100 is aggregating the network “health” information, it is applying what it finds to the list of media files 400 it has in its distribution transmission queue 510. Each media file 400 to be distributed has site- specific parameters 404, 408, 412 that need to be taken into account, such as the earliest or latest it can be sent in order to meet its usability requirements.
  • In another example, if the system 100 determines that a certain percentage of the receiving devices for a certain media file 400 are not on-line at the derived transmission time, the system applies that knowledge against a rules system. The system then determines if the media file 400 still has time to be delayed. It takes that information and looks at the next media file 400 in the transmission queue. If the distribution group of recipients for that media file is 100% online, it will transmit a different media file 400 instead, saving the problem media file 400 until such time as its distribution group is back on line for receiving. Alternatively, the file may need to be transmitted to whatever recipient in the distribution group is capable of capturing it due to timing constraints. This intelligence, combined with the ability to manually adjust the queue 156, gives the system the unique ability to maximize the efficiency of its distribution bandwidth. There is a finite amount of content that can be sent in any timeframe, and the ability to transmit only when the highest percentage of targeted recipient sites can accept the media file 400 minimizes the need to retransmit files and maximizes the finite bandwidth available to the system.
  • Referring now to FIG. 6, in another embodiment, the claimed invention is a system and method for providing connectivity in a media file distribution system 100. The system includes a data store 720, a portion of which is for storing a media file 400 received from a content provider 702. A database in the data store 720 contains editable parameters for distribution of the recipient site. The PRI 120 provides an interface to the database and allows the content provider 702 to edit the site- specific parameters 404, 408, 412. The ARI 122 further allows the recipient site to edit the parameters. The distribution subsystem is configured for distributing the media file 400 according to the site-specific parameters, 404, 408, 412. In one embodiment, the distribution subsystem includes connections to the Internet 10 and/or to a satellite communications link 190.
  • The system allows customers at either usage end—i.e., receiving sites providers 702 and—the unique ability to view, edit and assign parameters 404, 408 412 to a media files 400 in either their own or the other's system. The claimed system 100 enables both content providers 702 and recipient sites to gain information relevant to their product and make relevant changes to their media files 400 within a single system. The system is implemented by receiving edits and acting on the actual source media file 400 itself.
  • In one example, if a content provider 702 wants to assign an approval for a certain recipient site to acquire its programming, a content provider 702 can do so remotely through the PRI 120. If the recipient site signs up for that content, which can also be done remotely through the ARI 122, the system 100 automatically requests parameters for assigning to the file for the recipient site (such as price, on-screen guide placement category, provider value), and it completes the transaction without any manual intervention. The content providers 702 supply information about the content, such as the parameter values with which each file will arrive (suggested price, suggested rating, and such). The receiving site can assign its desired site- specific parameters 404, 408 412 to the file 400 as well through the ARI 122. The content provider 702 can display the parameter information and view exactly how the content is being offered to that particular receiving site's customers through the PRI 120.
  • Another example screen shot of the provider interface into the system 100, the PRI 120, is shown in FIG. 7. In the screen shot of FIG. 7, the provider is shown a list of available media packages for media files 400 stored in the data store 720. Another example screen shot from the ARI 122 is shown in FIG. 8. In this screen, the recipient customer can enter pricing information, package name information, a product description, transmission priority, and rating information for the package, which are customizations that can be viewed, edited, and/or validated by the content provider 702 in the ARI 122 in a similar screen. In this way, because both content providers and recipient sites have access to data within the system applicable to each other, they are able to view and change the data for customization to their own systems. Content providers 702 are able to authorize a recipient site's ordering of a package containing the content provider's media file 400, and the system eliminates the need for manual assignment of that recipient site into the transmission distribution list for the media file 400. Given that a preferred embodiment of the ARI 122 is web-based, and runs in a standard browser window, the recipient sites are able to view and edit the metadata associated with the media file 400 over the Internet, which allows them to set the data without having to create their own separate system to do so.
  • In another feature of the system, when a content provider 702 submits content into the system (i.e., the content provider 702 sends a media file along with the controlling metadata file with its appropriate asset-specific information), the media file 400 is checked against expected properties and approved for ingestion into the system, as described above. These properties and values are then, through a series of steps, modified to the individual requirements of each individual recipient site wishing to receive that content, as described above. Those site-specific values are then assigned to that recipient site within the central database in the data store 720, and displayed to the customer prior to transmission. The recipient site has the ability to change any values prior to transmission through the ARI 122.
  • In one embodiment, the site- specific parameters 404, 408, 412 follow certain expected criteria and value ranges. Automated assignment of at least some of those values is triggered by the expected input values and assignment of others is triggered by the expected outbound values for the site- specific parameters 404, 408, 412 of the media file 400. The system 100 allows the recipient sites to see the inbound media files 400 in order to transform it from 100 any way they see fit. The system also allows the inputting customers, i.e., the content providers 702, to see the results of their data being transformed by the recipient sites. Since both sets of data reside within a single data store 720, it is possible to display both sets to users at either end of the distribution chain. This gives both content providers 702 and recipient sites each more visibility into what the other is doing with their half of the distribution chain. It also gives them more control. A content provider 702 can assign contract values or on-screen display values to a particular video asset in a media file and restrict the recipient sites to which the media file is made available from changing those values. The content providers can then see the end result by looking at the actual data within the system. They can also authorize or de-authorize specific recipient sites within the system for receiving an media file 400 in the first place, simply by logging into the system and assigning parameters to their content, such as which recipients can or cannot receive particular media files 400.
  • Recipient sites can see the incoming values the content provider 702 makes available with the content providers assets and then the recipient sites can set up transformations to those assets prior to or after transmission to its own equipment. The recipient sites can stop specific media files from coming to their system if the media files for those assets contain certain data types (such as those with an “X” rating, and the like.). A recipient site can request certain media files if they have not already been authorized for them, and they can track the input delivery timeframes to see whether a media file will be transmitted as expected. This ability to act on the actual data inputted by the content providers means the system is the only place participating content providers and recipient sites need to view, enter and edit the parameter data, and it gives them the ability to do so at any point in time along the media file 400 asset lifecycle.
  • In another embodiment, the claimed invention is a system and method for providing interactive program guide entry for a media file 400. A distribution hub (data store 720 in FIG. 6) stores a media file 400 received from a content provider 702 for distribution to a recipient site. An interface to the distribution hub (ARI 122) allows editing of program guide data for the media file. The interface stores the program guide data as site- specific parameters 404, 408, 412 to the media file 400. The interface further allows the content provider to view the program guide data for the media file 400. In one embodiment, the interface further allows the content provider 702, through the PRI 120, to edit the program guide data, and to set parameters regarding editing of the program guide data by the recipient.
  • As discussed above with respect to FIGS. 2, 3, 7 and 8, the system has web-browser based graphical user interface (GUI) functionality. Further built in to this GUI functionality is the ability to allow entities (i.e., either content providers or recipient sites) to easily manipulate their interactive program guide (IPG), or on-screen TV set navigation guide. The interface allows the recipient to structure and map incoming media files 400 to their interface.
  • For example, in one embodiment, when a viewer on a recipient site's network enters a video-on-demand (VOD) section of the recipient site's television IPG, there is a hierarchical menu through which to navigate via the remote control organizing all of the video files by category. The recipient site (e.g., cable company or telephone company.) maps every asset it receives on its video-on-demand VOD servers to an IPG menu location prior to the asset's arrival within its system, and the data files accompanying each digital file preferably contain this information. The claimed system graphically links the content provider 702 and recipient site's IPG. This enables the recipient site to do the manually intensive mapping process on an easily manipulated graphic user interface, available in the ARI 122. Through the same interface, the system also provides the ability to link incoming content providers' menu data to IPG menu.
  • A media file 400 sent by the system to a recipient has a field in the site-specific parameter 404, which carries the hierarchical menu data that defines the destination on the recipient site's IPG. This IPG might be displayed, for example, on a television, set-top box, web page, phone or any other electronic system. The media files 400 being input into system by the content provider 702 contain a generalized value in this field, used more as a characteristic of the asset contained in the media file than an expected display value. This generalized value is transformed into a specific value for each recipient site to use in processing the media file 400 which, in one embodiment, comprises taking any expected potential incoming menu value and performing a site-specific transformation (per recipient site) on it, based on previously entered information about the recipient site's IPG. Current systems do this by taking a text menu string of incoming data and transforming it into an outgoing text string. This requires repeated entry (manual or automated depending on the systems) of the strings per each incoming type and for each recipient site. This is no longer required when using the claimed system.
  • With reference to FIGS. 9 and 10, example embodiments of IPG editing screens that can be presented from the ARI 122 are shown. A graphical menu builder provides easy IPG entry into the IPG parameters 404 of the media file 400. Recipient sites have the ability to enter, map, move, replace, delete and populate menu locations through this easily usable interactive GUI. FIG. 10 illustrates the screen shown after selection of the “Outdoor Life Network” entry in the screen show in FIG. 9.
  • Referring back to FIG. 1, in another embodiment, the claimed invention is a system and method for providing a multi-port catcher 146. The system includes a computer 108, a data store 514 (or 720 in FIG. 6), and a network connection 106 for connecting the computer to a network. In one aspect of this embodiment, a partition application is executed on the computer 146 to partition the computer into multiple partitions. A catcher application 146 (a remote receiving computer that receives and rebuilds the transmitted files) executes in each partition. Each catcher application 146 is capable of receiving a separate media file 400 over the network connection, simultaneously. Each media file 400 is stored in the data store 514. The system may use a plurality of catcher applications 146, wherein, for example, a first partition executes a first catcher application 146, and a second partition executes a second catcher application 146. Therefore, the first catcher application 146 can use a different protocol than the second catcher application 146. In this sense, the partition application is configured to divide processing of a processor of the computer into virtual computers, such that each of the media files 400 is received by a partition executing on one of the virtual computers.
  • In one embodiment, one of the partitions is configured as a content provider itself, such that one or more of the media files 400 can be provided internally from the data store into the catcher 146 without using a separate computer 108 to provide the one or more media files 400 to the catcher 146. In this or other embodiments, one of the partitions is further configured as a gateway computer to provide gateway processing, such as SMTP 144, FTP 148, and/or encoding/offloading functions 149, for each of the other partitions.
  • In one embodiment, the catcher 146 is implemented as a file reception server 800 located at a recipient customer location or cable head end, executing catcher partitions 146 a and 146 b. The system 100 allows one catcher 146 to receive multiple asset reception streams/transmissions from multiple distributors, all organized and reported on from the centralized database in the data store 720.
  • In current digital video distribution networks, a “catcher” has one reception path that validates and offloads the received files onto the destination server for the received files (the recipient sites equipment). The partitions 146 a and 146 b on the catcher 146 enable multiple, unique, exclusive reception paths for multiple transmission systems to deliver media files 400 to it. The media files 400 are treated uniquely based on their origination point, but the data is entered into the central data store 720 (by way of the catcher sending it back to the central system), giving one point of reference to the recipient site. This is unique because previously, any recipient site that required content delivered from multiple sources required multiple catchers (one per source), and a separate physical gateway to manage the multiple offloads into one destination video server. The catcher 146 of the presently claimed system is capable of not only receiving multiple inbound transmissions from different sources on the same hardware platform, but it is also capable of performing the gateway traffic management function, thereby consolidating previously disparate functions into one. The catcher 146 also includes the ability to ingest a local media file 400 without the need for it to be transmitted from a remote destination.
  • In order for the catcher to perform these functions, a software application executes internally in the computer to partition a single computer into multiple receiving points 146 a and 146 b. Each partition has the ability to execute industry standard file-movement protocols within the same computer 108. This allows the catcher 146 to receive multiple streams from different satellite receivers, from locally introduced content over an IP network, or from another catcher 147 physically attached to the catcher 146. The media files 400 are offloaded from the catcher 146 through one point, eliminating the need for the recipient site to put a separate gateway on the network. The media files 400 are aggregated into the centralized data store 720, thereby allowing the recipient site to perform data manipulation and reporting from one system regardless of the origination point of the transmission.
  • In one embodiment, each catcher 146 a, 146 b is implemented in software. This software scans both internal folders in catcher 146 and external folders on the network to which the catcher 146 is attached. These files are brought into a staging area/folder in the catcher 146. The metadata associated with those files (which arrives with the files) is sent back through the Internet to the centralized data store 720. With reference back to FIG. 1, the metadata is then scanned for compliance, process block 150 in FIG. 1, which includes analyzing the media file 400 to determine the identity of the content provider 702, and normalizing the site specific parameters 404, 408, 412 into a standard set of values the recipient site has requested. The parameters 404, 408, 412 are stored into the multicast structure, and the data is re-sent to the catcher 146. The system then moves the submitted digital file 400 off of the central data store 720 onto the recipient site's video server. Should a media file 400 that is not allowed or expected arrive on the system catcher 146 from an outside source, the file is quarantined on the catcher 146 and not moved to the central data store 720.
  • The centralization in the system allows the recipient site to view all of its digital file parameter and media data in one central place, and also allows it to use that same system to update media files 400 across the entire set of sites it owns from one place, regardless of whether or not those media files originated from the central data store 720.
  • In another embodiment, the claimed invention is a system and method for administrating a contract for distribution of a media file 400. A media file 400 is received from a content provider 702, after which, contract parameter data is entered into the media file 400 according to a contract between the content provider and a recipient site. Metadata is calculated for the media file 400 based on the contract parameter data, which is stored in the site- specific parameters 404, 408, 412 of the media file 400. The media file 400 is then distributed to the recipient site. In one embodiment, by way of example, and not by limitation, the site- specific parameters 404, 408, 412 include price limitations for the price that the recipient site can charge viewers for viewing of the media file 400. As another example, and not by limitation, the contract parameter data 404, 408, 412 include time limitations defining limitations regarding a time that the recipient site can present the media file 400.
  • The contract management system enables functions for the administration of a contract (between any or all of content providers, distributors, recipient sites, studios or other applicable parties) with respect to a media file 400. By way of example, and not by limitation, these functions include a contract to derive N number of unique, site-specific financial parameters for use in multiple places within the system, and the unique use of contract entity building blocks (such as provider, receiver or distributor element) to determine financial fulfillment and processing.
  • With reference to FIG. 11, in one embodiment, at step 1100, one entity has the option of managing contracts in one of two different ways, either by using package properties or by using site properties of the site- specific parameters 404, 408, 412. Next, at step 1102, a choice is presented to the user for selecting the level not selected in step 1100 (i.e., if the option for package properties was selected, the site properties are selected). With respect to package properties, the user can view the hierarchy of the package recipient sites sorted by MSO, and the recipient sites they each own. The recipient site of content provider 702 can then select any of these groups (the entire set of package recipient sites or any number of MSO's and/or sites) for contract creation or editing. The level to be applied is selected, which includes by package, MSO, or recipient site, at step 1104. If the selected level doesn't have a contract already created, step 1106, the system 100 offers the opportunity to create the contract or contracts, at step 1108. If a recipient site group is selected and applied in bulk by using MSO or package editing, and some of the recipient sites do not yet have a site contract, then one will be created for those that do not already have one, at step 1110. Then all recipient sites under the contract parameters are updated to reflect the choice of contract to use for the sites, at step 1112. Otherwise, if the user chose not to create a contract when there was no contract in place for a package, MSO or recipient site, then those sites that are left without contracts are marked with an error condition in the system, step at 1114.
  • In one embodiment, if additional recipient sites are added to the package, they do not automatically inherit the contract level choice made in bulk earlier by selecting MSO or Package for contract creation or editing.
  • In one example using the system, the user can view all packages that exist, and the packages to which a recipient site belongs. If a new package for a recipient site is selected, the user is taken to a contract application level selection screen, where the user can chose contract editing by package, MSO, or recipient site. The user can also select a package for which the recipient site is already a member, and update contract parameters. As explained above, if the newly chosen level doesn't yet have a contract created, the user is offered the choice to create the contract.
  • In one embodiment, after contract creation, parameter data reflecting the contract is stored in the package tables of FIG. 1. When a media file 400 that is subject to the a contract is processed through the system 100, during the package determination process 152, the package tables are read and the appropriate parameters are inserted into the site specific parameters 404, 408, 412 into the media file 400.
  • With reference to FIG. 12, when choosing a contract level (through site properties) the system 100 shows all three potential levels, the package level 1200, the MSO level 1202, and the recipient site level 1204, whether or not a contract is available on those levels. When the contract level is selected, the system displays an indicator showing whether a contract exists at that level. If a contract is created by the system, initially, a contract template 1206 is used to form the contract, after which, the contract is modifiable.
  • Although the invention has been described in language specific to computer structural features, methodological acts, and by computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific structures, acts, or media described. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the claimed invention.
  • Furthermore, the various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the claimed invention without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the claimed invention, which is set forth in the following claims.

Claims (20)

1. A method for optimizing distribution of a media file to a plurality of recipient sites over a communication network, the method comprising:
checking a receive status of a first recipient site to produce a first status check result;
checking a receive status of a second recipient site to produce a second status check result;
aggregating a first set of control data specific to requirements of the first recipient site and a second set of control data specific to requirements of the second recipient site, into the media file;
based on the first check result, the second check result, the first set of control data and the second set of control data, applying a set of rules to determine a priority for distributing the aggregated media file to the first recipient site and the second recipient site; and
transmitting the aggregated media file to the first recipient site and transmitting the aggregated media file to the second recipient site over said communication network, according to the determined priority.
2. The method of claim 1, wherein said set of rules includes one or more rules from the group consisting of data range, time range, and communication channel requirements.
3. The method of claim 1, wherein said determining a priority comprises determining whether a certain percentage of a plurality of devices at each of the first and second recipient sites are ready to receive the aggregated media file.
4. The method of claim 1, wherein said receive statuses are equipment statuses located in the first and second recipient sites.
5. The method of claim 1, wherein said first set of control data include data regarding an earliest or latest time that the media file can be transmitted to said first recipient site.
6. The method of claim 1, wherein said set of rules include a rule for transmitting the media file when a highest percentage of targeted recipient sites can accept the media file.
7. The method of claim 1, wherein said communication network is the Internet.
8. The method of claim 1, wherein said communication network is a satellite link.
9. The method of claim 1, wherein said media file is for use in a video play back.
10. The method of claim 1, wherein said media file is for use in gaming.
11. The method of claim 1, further comprising preventing the media file from loading to a recipient computer, according to control data specific to said recipient computer.
12. A method for optimizing distribution of a media file to a plurality of recipient sites over a communication network, the method comprising:
aggregating a plurality of control data into the media file, each of the plurality of control data being specific to requirements of a respective one of the plurality of recipient sites;
checking a respective receive status of each of the plurality of recipient sites;
determining a percentage of the plurality of recipient sites that are ready to receive the aggregated media file;
transmitting the aggregated media file to all of the recipient sites over said communication network, if the determined percentage is higher than a set value; and
delaying the transmission of the aggregated media file to a portion of the recipient sites based on respective control data specific to requirements of said portion of the recipient sites, if the determined percentage is lower than or equal to said set value.
13. The method of claim 12, wherein said delaying the transmission of the aggregated media file comprises delaying the transmission of the aggregated media file to those recipient sites not ready to receive the aggregated media file.
14. The method of claim 12, wherein said communication network is the Internet.
15. The method of claim 12, wherein said communication network is a satellite link.
16. The method of claim 12, wherein said media file is for use in a video play back.
17. The method of claim 12, wherein said media file is for use in gaming.
18. The method of claim 12, further comprising preventing the aggregated media file from loading to a recipient computer at a first recipient site, according to control data specific to requirements of said first recipient site.
19. The method of claim 12, further comprising processing the received media file by a recipient computer at a first recipient site, according to control data specific to requirements of said first recipient site.
20. The method of claim 12, further comprising changing one or more of the control data according to one or more of the receive statuses of the plurality of recipient sites.
US12/407,715 2005-07-15 2009-03-19 System and method for optimizing distribution of media files with transmission based on recipient site requirements Active 2026-09-25 US8880733B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/407,715 US8880733B2 (en) 2005-07-15 2009-03-19 System and method for optimizing distribution of media files with transmission based on recipient site requirements
US14/531,622 US20150058453A1 (en) 2005-07-15 2014-11-03 System And Method For Optimizing Distribution Of Media Files

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/182,724 US20070016530A1 (en) 2005-07-15 2005-07-15 Multi-media file distribution system and method
US12/407,715 US8880733B2 (en) 2005-07-15 2009-03-19 System and method for optimizing distribution of media files with transmission based on recipient site requirements

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/182,724 Division US20070016530A1 (en) 2005-07-15 2005-07-15 Multi-media file distribution system and method

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/531,622 Division US20150058453A1 (en) 2005-07-15 2014-11-03 System And Method For Optimizing Distribution Of Media Files

Publications (2)

Publication Number Publication Date
US20090222580A1 true US20090222580A1 (en) 2009-09-03
US8880733B2 US8880733B2 (en) 2014-11-04

Family

ID=37662821

Family Applications (7)

Application Number Title Priority Date Filing Date
US11/182,724 Abandoned US20070016530A1 (en) 2005-07-15 2005-07-15 Multi-media file distribution system and method
US12/407,715 Active 2026-09-25 US8880733B2 (en) 2005-07-15 2009-03-19 System and method for optimizing distribution of media files with transmission based on recipient site requirements
US12/409,384 Abandoned US20090222865A1 (en) 2005-07-15 2009-03-23 System and method for managing media files based on contracts
US12/409,374 Active 2026-04-07 US8627507B2 (en) 2005-07-15 2009-03-23 System and method for multimedia data validation
US12/412,305 Abandoned US20090187947A1 (en) 2005-07-15 2009-03-26 System and method for managing distributed media files
US12/427,641 Abandoned US20090204670A1 (en) 2005-07-15 2009-04-21 Multi-port catcher system for media data
US14/531,622 Abandoned US20150058453A1 (en) 2005-07-15 2014-11-03 System And Method For Optimizing Distribution Of Media Files

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/182,724 Abandoned US20070016530A1 (en) 2005-07-15 2005-07-15 Multi-media file distribution system and method

Family Applications After (5)

Application Number Title Priority Date Filing Date
US12/409,384 Abandoned US20090222865A1 (en) 2005-07-15 2009-03-23 System and method for managing media files based on contracts
US12/409,374 Active 2026-04-07 US8627507B2 (en) 2005-07-15 2009-03-23 System and method for multimedia data validation
US12/412,305 Abandoned US20090187947A1 (en) 2005-07-15 2009-03-26 System and method for managing distributed media files
US12/427,641 Abandoned US20090204670A1 (en) 2005-07-15 2009-04-21 Multi-port catcher system for media data
US14/531,622 Abandoned US20150058453A1 (en) 2005-07-15 2014-11-03 System And Method For Optimizing Distribution Of Media Files

Country Status (4)

Country Link
US (7) US20070016530A1 (en)
EP (1) EP1910935A4 (en)
CA (1) CA2649395A1 (en)
WO (1) WO2007011537A2 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110066742A1 (en) * 2009-08-21 2011-03-17 Yiubun Lee Devices and methods for scheduling transmission time of media data
US20110209224A1 (en) * 2010-02-24 2011-08-25 Christopher Gentile Digital multimedia album
US20120185566A1 (en) * 2007-11-07 2012-07-19 Sony Corporation Server device, client device, information processing system, information processing method, and program
CN103310162A (en) * 2012-03-06 2013-09-18 北京印刷学院 Remote format file transmitting system and method based on central node mode
US9213724B2 (en) 2007-10-22 2015-12-15 Sony Corporation Information processing terminal device, information processing device, information processing method, and program
US10264305B2 (en) * 2010-03-02 2019-04-16 Twentieth Century Fox Film Corporation Delivery of encoded media content

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7631336B2 (en) 2004-07-30 2009-12-08 Broadband Itv, Inc. Method for converting, navigating and displaying video content uploaded from the internet to a digital TV video-on-demand platform
US9584868B2 (en) 2004-07-30 2017-02-28 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US9344765B2 (en) 2004-07-30 2016-05-17 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US9635429B2 (en) 2004-07-30 2017-04-25 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US7590997B2 (en) 2004-07-30 2009-09-15 Broadband Itv, Inc. System and method for managing, converting and displaying video content on a video-on-demand platform, including ads used for drill-down navigation and consumer-generated classified ads
US11259059B2 (en) 2004-07-30 2022-02-22 Broadband Itv, Inc. System for addressing on-demand TV program content on TV services platform of a digital TV services provider
US7853498B2 (en) * 2005-11-03 2010-12-14 International Business Machines Corporation Method, system, and computer program product for on-demand creation and distribution of customized dynamic contracts
US20070143775A1 (en) * 2005-12-16 2007-06-21 Savoor Raghvendra G Methods and systems to determine pricing of Internet protocol television services
US8037506B2 (en) * 2006-03-03 2011-10-11 Verimatrix, Inc. Movie studio-based network distribution system and method
WO2007130116A1 (en) * 2006-05-02 2007-11-15 Digicorp, Inc. System and method for assembling data
US8015237B2 (en) * 2006-05-15 2011-09-06 Apple Inc. Processing of metadata content and media content received by a media distribution system
US7962634B2 (en) * 2006-05-15 2011-06-14 Apple Inc. Submission of metadata content and media content to a media distribution system
FR2913512B1 (en) 2007-03-09 2009-07-03 Archos Sa "PORTABLE CONTAINER FOR STORING AT LEAST ONE MULTIMEDIA OBJECT, CHARGING AND ADAPTATION DEVICES FOR RECEIVING THIS CONTAINER, SYSTEM AND ASSOCIATED METHODS"
US8744246B2 (en) * 2007-04-12 2014-06-03 Gvbb Holdings S.A.R.L. Operational management solution for media production and distribution
WO2008127570A2 (en) * 2007-04-13 2008-10-23 Thomson Licensing Enhanced database scheme to support advanced media production and distribution
US11570521B2 (en) 2007-06-26 2023-01-31 Broadband Itv, Inc. Dynamic adjustment of electronic program guide displays based on viewer preferences for minimizing navigation in VOD program selection
US8286212B2 (en) 2007-08-17 2012-10-09 Microsoft Corporation On-demand asset distribution
US8015213B2 (en) * 2008-06-26 2011-09-06 Microsoft Corporation Content having native and export portions
US8589993B2 (en) * 2008-08-29 2013-11-19 At&T Intellectual Property I, L.P. Distributing on-demand multimedia content
US9336214B2 (en) * 2009-01-31 2016-05-10 Hewlett-Packard Development Company, L.P. File-name extension characters for file distribution
WO2010101959A2 (en) * 2009-03-02 2010-09-10 Realnetworks, Inc. Re-headerer system and method
US20100257140A1 (en) * 2009-03-31 2010-10-07 Philip John Davis Data archiving and retrieval system
US8584256B2 (en) 2010-04-21 2013-11-12 Fox Entertainment Group, Inc. Digital delivery system and user interface for enabling the digital delivery of media content
US10339570B2 (en) 2010-04-21 2019-07-02 Fox Entertainment Group, Inc. Customized billboard website advertisements
US10061863B2 (en) * 2010-12-17 2018-08-28 Verizon Patent And Licensing Inc. Asset manager
US20120197902A1 (en) 2011-01-28 2012-08-02 International Business Machines Corporation Data ingest optimization
WO2012126964A1 (en) * 2011-03-21 2012-09-27 Unwired Planet, Inc. Method and system for providing media optimization
US9609370B2 (en) * 2011-05-31 2017-03-28 Alcatel Lucent Video delivery modification based on network availability
CN102737075B (en) * 2011-08-26 2017-09-19 新奥特(北京)视频技术有限公司 A kind of method and apparatus for configuring medium resource flow
CN103888843B (en) * 2014-03-11 2017-12-12 惠州Tcl移动通信有限公司 The method and system that the programme channel of intelligent television is integrated with application program
CN104460019B (en) * 2014-12-11 2017-04-12 合肥鑫晟光电科技有限公司 Three-dimensional display equipment and three-dimensional display method
US9680583B2 (en) 2015-03-30 2017-06-13 The Nielsen Company (Us), Llc Methods and apparatus to report reference media data to multiple data collection facilities
US10282633B2 (en) * 2015-10-20 2019-05-07 Apple Inc. Cross-asset media analysis and processing
US10638181B2 (en) 2016-06-20 2020-04-28 Scripps Networks Interactive, Inc. Non-linear C3 content scheduling and encoding system
CN108574854A (en) * 2017-03-10 2018-09-25 达创科技股份有限公司 Method, servomechanism and the system of transmitting multimedia data
US11340760B2 (en) * 2019-09-06 2022-05-24 Dropbox, Inc. Generating a customized organizational structure for uploading content to a cloud-based storage system
CN114598895B (en) * 2020-12-04 2023-08-11 腾讯云计算(长沙)有限责任公司 Audio and video processing method, device, equipment and computer readable storage medium

Citations (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4671772A (en) * 1985-10-22 1987-06-09 Keilty, Goldsmith & Boone Performance appraisal and training system and method of utilizing same
US4863384A (en) * 1986-04-10 1989-09-05 Keilty, Goldsmith & Boone Personalized feedback system utilizing pre-recorded media and method of making same
US5099422A (en) * 1986-04-10 1992-03-24 Datavision Technologies Corporation (Formerly Excnet Corporation) Compiling system and method of producing individually customized recording media
US5123089A (en) * 1989-06-19 1992-06-16 Applied Creative Technology, Inc. Apparatus and protocol for local area network
US5550735A (en) * 1992-08-26 1996-08-27 Datavision Technologies Compiling system and method for mass producing individually customized media
US5825876A (en) * 1995-12-04 1998-10-20 Northern Telecom Time based availability to content of a storage medium
US5844595A (en) * 1996-05-31 1998-12-01 Thomson Consumer Electronics, Inc. Decoding of digital data including program specific information
US5892909A (en) * 1996-09-27 1999-04-06 Diffusion, Inc. Intranet-based system with methods for co-active delivery of information to multiple users
US6104705A (en) * 1997-12-31 2000-08-15 U.S. Philips Corporation Group based control scheme for video compression
US6105066A (en) * 1998-05-05 2000-08-15 International Business Machines Corp. Client-server system with central application management and using fully qualified class names of object-oriented applications for determining permanent server storage locations for application configuration information
US20010003831A1 (en) * 1998-05-29 2001-06-14 Vernon K. Boland Method and apparatus for allocating network resources and changing the allocation based on dynamic workload changes
US6269275B1 (en) * 1998-03-31 2001-07-31 Michael G. Slade Method and system for customizing and distributing presentations for user sites
US6304906B1 (en) * 1998-08-06 2001-10-16 Hewlett-Packard Company Method and systems for allowing data service system to provide class-based services to its users
US20020010759A1 (en) * 1999-12-30 2002-01-24 Hitson Bruce L. System and method for multimedia content composition and distribution
US20020038359A1 (en) * 2000-08-31 2002-03-28 Sony Corporation Content distribution method and content supply system
US6401238B1 (en) * 1998-12-10 2002-06-04 International Business Machines Corporation Intelligent deployment of applications to preserve network bandwidth
US6405215B1 (en) * 1998-11-06 2002-06-11 International Business Machines Corp. Workflow agent for a multimedia database system
US20020078449A1 (en) * 2000-11-27 2002-06-20 Gordon Donald F. Method and apparatus for providing interactive program guide (IPG) and video-on-demand (VOD) user interfaces
US20020083182A1 (en) * 2000-12-18 2002-06-27 Alvarado Juan C. Real-time streamed data download system and method
US20020116517A1 (en) * 2001-01-17 2002-08-22 Hudson Michael D. Virtual program streaming multi-media system
US20020129371A1 (en) * 2001-03-08 2002-09-12 Matsushita Elecric Industrial Co., Ltd. Media distribution apparatus and media distribution method
US20020152318A1 (en) * 2001-03-02 2002-10-17 Menon Satish N. Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
US20030009579A1 (en) * 2001-07-06 2003-01-09 Fujitsu Limited Contents data transmission system
US20030009553A1 (en) * 2001-06-29 2003-01-09 International Business Machines Corporation Method and system for network management with adaptive queue management
US20030023757A1 (en) * 2001-07-13 2003-01-30 Fujitsu Limited Contents distribution method, contents information processing device, and computer product
US6516348B1 (en) * 1999-05-21 2003-02-04 Macfarlane Druce Ian Craig Rattray Collecting and predicting capacity information for composite network resource formed by combining ports of an access server and/or links of wide arear network
US20030030750A1 (en) * 2001-08-13 2003-02-13 Hoarty William Leo System and method for data distribution network
US20030093530A1 (en) * 2001-10-26 2003-05-15 Majid Syed Arbitrator system and method for national and local content distribution
US20030110501A1 (en) * 2001-12-12 2003-06-12 Rafey Richter A. Personalizing media presentations based on a target duration
US20030126275A1 (en) * 2001-12-31 2003-07-03 Change Masters, Incorporated Digital distribution system for dynamic media
US20030187932A1 (en) * 2002-03-28 2003-10-02 Kennedy Bruce C. Network project development system and method
US20030204614A1 (en) * 2002-04-29 2003-10-30 The Boeing Company Method and apparatus for the display and distribution of cinema grade content in real time
US20030229898A1 (en) * 2002-06-05 2003-12-11 Babu Suresh P. Multiple on-demand media vendor integration
US20040088730A1 (en) * 2002-11-01 2004-05-06 Srividya Gopalan System and method for maximizing license utilization and minimizing churn rate based on zero-reject policy for video distribution
US20040103120A1 (en) * 2002-11-27 2004-05-27 Ascent Media Group, Inc. Video-on-demand (VOD) management system and methods
US6760721B1 (en) * 2000-04-14 2004-07-06 Realnetworks, Inc. System and method of managing metadata data
US20040143764A1 (en) * 2003-01-13 2004-07-22 Kartik Kaleedhass System and method of preventing the transmission of known and unknown electronic content to and from servers or workstations connected to a common network
US6769127B1 (en) * 2000-06-16 2004-07-27 Minerva Networks, Inc. Method and system for delivering media services and application over networks
US20040186993A1 (en) * 2002-09-04 2004-09-23 Hank Risan Method and system for controlling presentation of media on a media storage device
US20040194131A1 (en) * 1999-03-11 2004-09-30 Ellis Michael D. Television system with scheduling of advertisements
US20040210926A1 (en) * 2003-01-08 2004-10-21 Avtrex, Inc. Controlling access to content
US20040255335A1 (en) * 2002-11-27 2004-12-16 Ascent Media Group, Inc. Multicast media distribution system
US20040254940A1 (en) * 2003-01-31 2004-12-16 Brush Hector Cesar Digital media distribution method and system
US20050050218A1 (en) * 2003-09-02 2005-03-03 Microsoft Corporation Video delivery workflow
US20050125660A1 (en) * 2003-07-28 2005-06-09 Limelight Networks, Llc Authentication of content download
US6925469B2 (en) * 2001-03-30 2005-08-02 Intertainer, Inc. Digital entertainment service platform
US20050204017A1 (en) * 2003-08-08 2005-09-15 Roger Graves Media keying for updateable content distribution
US20050228858A1 (en) * 2004-03-25 2005-10-13 Mika Mizutani Content utilization management method corresponding to network transfer, program, and content transfer system
US6986158B1 (en) * 1999-03-18 2006-01-10 Fujitsu Limited System and method for distributing video information over network
US20060064476A1 (en) * 2004-09-23 2006-03-23 Decasper Dan S Advanced content and data distribution techniques
US7020888B2 (en) * 2000-11-27 2006-03-28 Intellocity Usa, Inc. System and method for providing an omnimedia package
US20060069720A1 (en) * 2004-09-27 2006-03-30 Kabushiki Kaisha Toshiba Video distributing system, video distributing method, and server
US20070005795A1 (en) * 1999-10-22 2007-01-04 Activesky, Inc. Object oriented video system
US20070033609A1 (en) * 2003-09-12 2007-02-08 Hiroaki Dei Media stream multicast distribution method and apparatus
US20070038717A1 (en) * 2005-07-27 2007-02-15 Subculture Interactive, Inc. Customizable Content Creation, Management, and Delivery System
US20070061835A1 (en) * 2005-08-05 2007-03-15 Realnetworks, Inc. System and method for registering users and devices
US20070060096A1 (en) * 2005-09-14 2007-03-15 Yoshiaki Hayakawa Communications system, presence server, and communications method used for them
US20070216538A1 (en) * 2004-04-15 2007-09-20 Koninklijke Philips Electronic, N.V. Method for Controlling a Media Content Processing Device, and a Media Content Processing Device
US20070239609A1 (en) * 1998-03-06 2007-10-11 Starguide Digital Networks, Inc. Method and apparatus for push and pull distribution of multimedia
US20080027792A1 (en) * 2006-07-26 2008-01-31 Wu Louis L Election-based electronic compilations
US20080243527A1 (en) * 2007-03-30 2008-10-02 Macrovision Corporation Custom Media Production and Distribution System and Methods
US7483879B2 (en) * 2003-01-17 2009-01-27 International Business Machines Corporation System and method for accessing non-compatible content repositories
US20100175100A1 (en) * 2009-01-06 2010-07-08 Koichi Ogasawara Presence information sharing apparatus, presence information sharing method, presence information sharing program and presence information sharing system
US20100254536A1 (en) * 2009-04-02 2010-10-07 Broadcom Corporation Authenticated mode control
US20120102184A1 (en) * 2010-10-20 2012-04-26 Sony Corporation Apparatus and method for adaptive streaming of content with user-initiated quality adjustments
US8255950B1 (en) * 2004-10-28 2012-08-28 Aol Inc. Dynamic identification of other viewers of a television program to an online viewer
US20120232916A1 (en) * 2006-07-26 2012-09-13 V V S Virtual Video Systems (Canada) Inc. Video and multimedia distribution system
US8438603B2 (en) * 2006-12-22 2013-05-07 Time Warner Cable Inc. Methods and apparatus for supporting content distribution
US20130275611A1 (en) * 2012-04-16 2013-10-17 Oren Somekh Method and system of dynamic routing of aggregated online media streams
US20130304604A1 (en) * 2011-11-02 2013-11-14 Michael Theodor Hoffman Systems and methods for dynamic digital product synthesis, commerce, and distribution

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2754444B1 (en) * 1996-10-10 1999-07-02 W K Et Associes INTRAOCULAR IMPLANT WITH FLEXIBLE OPTICS AND A SINGLE RIGID CIRCULAR HANDLE
US6370571B1 (en) * 1997-03-05 2002-04-09 At Home Corporation System and method for delivering high-performance online multimedia services
US6892226B1 (en) * 1997-03-27 2005-05-10 Intel Corporation System for delivery of dynamic content to a client device
US6381682B2 (en) * 1998-06-10 2002-04-30 Compaq Information Technologies Group, L.P. Method and apparatus for dynamically sharing memory in a multiprocessor system
US6324691B1 (en) * 1998-11-12 2001-11-27 Hewlett-Packard Company Manufacture of software distribution media packages from components resident on a remote server source
US6757736B1 (en) * 1999-11-30 2004-06-29 International Business Machines Corporation Bandwidth optimizing adaptive file distribution
US20010034839A1 (en) 1999-12-24 2001-10-25 Guenter Karjoth Method and apparatus for secure transmission of data and applications
US6389469B1 (en) * 2000-03-27 2002-05-14 Targetize Innovative Solutions Ltd. System and method for customized content delivery
US7650376B1 (en) * 2000-03-27 2010-01-19 Blumenau Trevor I Content distribution system for distributing content over a network, with particular applicability to distributing high-bandwidth content
US20020016831A1 (en) * 2000-08-07 2002-02-07 Vidius Inc. Apparatus and method for locating of an internet user
US7058694B1 (en) * 2000-09-07 2006-06-06 Clix Network, Inc. Method for comparing two trinary logic representations in the process of customizing radio broadcasting
US20020111852A1 (en) * 2001-01-16 2002-08-15 Levine Robyn R. Business offering content delivery
US20020141584A1 (en) * 2001-01-26 2002-10-03 Ravi Razdan Clearinghouse for enabling real-time remote digital rights management, copyright protection and distribution auditing
US7089558B2 (en) * 2001-03-08 2006-08-08 International Business Machines Corporation Inter-partition message passing method, system and program product for throughput measurement in a partitioned processing environment
US20030032409A1 (en) * 2001-03-16 2003-02-13 Hutcheson Stewart Douglas Method and system for distributing content over a wireless communications system
US20030061206A1 (en) * 2001-09-27 2003-03-27 Richard Qian Personalized content delivery and media consumption
US8166185B2 (en) * 2002-03-05 2012-04-24 Hewlett-Packard Development Company, L.P. System and method for enterprise software distribution
US7707409B2 (en) 2002-04-30 2010-04-27 Kt Corporation Method and system for authenticating software
AU2003240964A1 (en) * 2002-05-31 2003-12-19 Context Media, Inc. Cataloging and managing the distribution of distributed digital assets
EP1377054A1 (en) 2002-06-25 2004-01-02 Canal+ Technologies Société Anonyme Discovery information for IP multicast
AU2003258092A1 (en) * 2002-08-15 2004-03-03 Predictive Media Corporation A smart audio guide system and method
US20040113936A1 (en) * 2002-12-11 2004-06-17 Dempski Kelly L. Optimized delivery of multimedia content
WO2004063911A1 (en) 2003-01-16 2004-07-29 Koninklijke Philips Electronics N.V. Preventing distribution of modified or corrupted files
US7526545B2 (en) * 2003-01-17 2009-04-28 Relevant Media Llc Content distribution system
US7461319B2 (en) 2003-04-04 2008-12-02 Sun Microsystems, Inc. System and method for downloading files over a network with real time verification
US20050080667A1 (en) * 2003-10-08 2005-04-14 Sbc Knowledge Ventures, L.P. System and method for automated customized content delivery for web sites
US8046409B2 (en) * 2003-10-31 2011-10-25 Hewlett-Packard Development Company, L.P. Communications methods, collaboration session communications organizers, collaboration sessions, and articles of manufacture
KR100584448B1 (en) 2004-01-19 2006-05-26 삼성전자주식회사 Remote download method and system of embedded software using the position of binary image
US9805400B2 (en) * 2004-03-02 2017-10-31 Nokia Technologies Oy Downloading different versions of media files based on a type of download link
US8914606B2 (en) * 2004-07-08 2014-12-16 Hewlett-Packard Development Company, L.P. System and method for soft partitioning a computer system
US7567846B2 (en) * 2004-09-24 2009-07-28 Sztybel Robert S Interactive audio content delivery system and method
US20060170759A1 (en) 2005-02-03 2006-08-03 Navio Systems Inc. Methods and apparatus for optimizing digital asset distribution
US20070088660A1 (en) * 2005-10-13 2007-04-19 Abu-Amara Hosame H Digital security for distributing media content to a local area network
US8230037B2 (en) * 2006-09-29 2012-07-24 Audible, Inc. Methods and apparatus for customized content delivery
US8548918B1 (en) * 2006-12-18 2013-10-01 Qurio Holdings, Inc. Methods and systems for automated content distribution
US8055749B1 (en) * 2008-09-30 2011-11-08 Amazon Technologies, Inc. Optimizing media distribution using metrics

Patent Citations (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4671772A (en) * 1985-10-22 1987-06-09 Keilty, Goldsmith & Boone Performance appraisal and training system and method of utilizing same
US4863384A (en) * 1986-04-10 1989-09-05 Keilty, Goldsmith & Boone Personalized feedback system utilizing pre-recorded media and method of making same
US5099422A (en) * 1986-04-10 1992-03-24 Datavision Technologies Corporation (Formerly Excnet Corporation) Compiling system and method of producing individually customized recording media
US5123089A (en) * 1989-06-19 1992-06-16 Applied Creative Technology, Inc. Apparatus and protocol for local area network
US5550735A (en) * 1992-08-26 1996-08-27 Datavision Technologies Compiling system and method for mass producing individually customized media
US5825876A (en) * 1995-12-04 1998-10-20 Northern Telecom Time based availability to content of a storage medium
US5844595A (en) * 1996-05-31 1998-12-01 Thomson Consumer Electronics, Inc. Decoding of digital data including program specific information
US5892909A (en) * 1996-09-27 1999-04-06 Diffusion, Inc. Intranet-based system with methods for co-active delivery of information to multiple users
US6104705A (en) * 1997-12-31 2000-08-15 U.S. Philips Corporation Group based control scheme for video compression
US20070239609A1 (en) * 1998-03-06 2007-10-11 Starguide Digital Networks, Inc. Method and apparatus for push and pull distribution of multimedia
US6269275B1 (en) * 1998-03-31 2001-07-31 Michael G. Slade Method and system for customizing and distributing presentations for user sites
US6105066A (en) * 1998-05-05 2000-08-15 International Business Machines Corp. Client-server system with central application management and using fully qualified class names of object-oriented applications for determining permanent server storage locations for application configuration information
US20010003831A1 (en) * 1998-05-29 2001-06-14 Vernon K. Boland Method and apparatus for allocating network resources and changing the allocation based on dynamic workload changes
US6304906B1 (en) * 1998-08-06 2001-10-16 Hewlett-Packard Company Method and systems for allowing data service system to provide class-based services to its users
US6405215B1 (en) * 1998-11-06 2002-06-11 International Business Machines Corp. Workflow agent for a multimedia database system
US6401238B1 (en) * 1998-12-10 2002-06-04 International Business Machines Corporation Intelligent deployment of applications to preserve network bandwidth
US20040194131A1 (en) * 1999-03-11 2004-09-30 Ellis Michael D. Television system with scheduling of advertisements
US6986158B1 (en) * 1999-03-18 2006-01-10 Fujitsu Limited System and method for distributing video information over network
US6516348B1 (en) * 1999-05-21 2003-02-04 Macfarlane Druce Ian Craig Rattray Collecting and predicting capacity information for composite network resource formed by combining ports of an access server and/or links of wide arear network
US20070005795A1 (en) * 1999-10-22 2007-01-04 Activesky, Inc. Object oriented video system
US20020010759A1 (en) * 1999-12-30 2002-01-24 Hitson Bruce L. System and method for multimedia content composition and distribution
US6760721B1 (en) * 2000-04-14 2004-07-06 Realnetworks, Inc. System and method of managing metadata data
US6769127B1 (en) * 2000-06-16 2004-07-27 Minerva Networks, Inc. Method and system for delivering media services and application over networks
US20020038359A1 (en) * 2000-08-31 2002-03-28 Sony Corporation Content distribution method and content supply system
US7020888B2 (en) * 2000-11-27 2006-03-28 Intellocity Usa, Inc. System and method for providing an omnimedia package
US20020078449A1 (en) * 2000-11-27 2002-06-20 Gordon Donald F. Method and apparatus for providing interactive program guide (IPG) and video-on-demand (VOD) user interfaces
US20020083182A1 (en) * 2000-12-18 2002-06-27 Alvarado Juan C. Real-time streamed data download system and method
US20020116517A1 (en) * 2001-01-17 2002-08-22 Hudson Michael D. Virtual program streaming multi-media system
US20020152318A1 (en) * 2001-03-02 2002-10-17 Menon Satish N. Metadata enabled push-pull model for efficient low-latency video-content distribution over a network
US20020129371A1 (en) * 2001-03-08 2002-09-12 Matsushita Elecric Industrial Co., Ltd. Media distribution apparatus and media distribution method
US6925469B2 (en) * 2001-03-30 2005-08-02 Intertainer, Inc. Digital entertainment service platform
US20030009553A1 (en) * 2001-06-29 2003-01-09 International Business Machines Corporation Method and system for network management with adaptive queue management
US20030009579A1 (en) * 2001-07-06 2003-01-09 Fujitsu Limited Contents data transmission system
US20030023757A1 (en) * 2001-07-13 2003-01-30 Fujitsu Limited Contents distribution method, contents information processing device, and computer product
US20030030750A1 (en) * 2001-08-13 2003-02-13 Hoarty William Leo System and method for data distribution network
US20030093530A1 (en) * 2001-10-26 2003-05-15 Majid Syed Arbitrator system and method for national and local content distribution
US20030110501A1 (en) * 2001-12-12 2003-06-12 Rafey Richter A. Personalizing media presentations based on a target duration
US20080155114A1 (en) * 2001-12-31 2008-06-26 Change Masters, Incorporated Digital distribution system for dynamic media
US20030126275A1 (en) * 2001-12-31 2003-07-03 Change Masters, Incorporated Digital distribution system for dynamic media
US20030187932A1 (en) * 2002-03-28 2003-10-02 Kennedy Bruce C. Network project development system and method
US20030204614A1 (en) * 2002-04-29 2003-10-30 The Boeing Company Method and apparatus for the display and distribution of cinema grade content in real time
US20030229898A1 (en) * 2002-06-05 2003-12-11 Babu Suresh P. Multiple on-demand media vendor integration
US20040186993A1 (en) * 2002-09-04 2004-09-23 Hank Risan Method and system for controlling presentation of media on a media storage device
US8250663B2 (en) * 2002-09-04 2012-08-21 Music Public Broadcasting, Inc. Method and system for controlling presentation of media on a media storage device
US20040088730A1 (en) * 2002-11-01 2004-05-06 Srividya Gopalan System and method for maximizing license utilization and minimizing churn rate based on zero-reject policy for video distribution
US20040103120A1 (en) * 2002-11-27 2004-05-27 Ascent Media Group, Inc. Video-on-demand (VOD) management system and methods
US20040255335A1 (en) * 2002-11-27 2004-12-16 Ascent Media Group, Inc. Multicast media distribution system
US7921448B2 (en) * 2002-11-27 2011-04-05 Ascent Media Group, LLP Multicast media distribution system
US20040210926A1 (en) * 2003-01-08 2004-10-21 Avtrex, Inc. Controlling access to content
US20040143764A1 (en) * 2003-01-13 2004-07-22 Kartik Kaleedhass System and method of preventing the transmission of known and unknown electronic content to and from servers or workstations connected to a common network
US7483879B2 (en) * 2003-01-17 2009-01-27 International Business Machines Corporation System and method for accessing non-compatible content repositories
US20040254940A1 (en) * 2003-01-31 2004-12-16 Brush Hector Cesar Digital media distribution method and system
US20050125660A1 (en) * 2003-07-28 2005-06-09 Limelight Networks, Llc Authentication of content download
US7606876B2 (en) * 2003-08-08 2009-10-20 Kincaid Technology Corporation Media keying for updateable content distribution
US20050204017A1 (en) * 2003-08-08 2005-09-15 Roger Graves Media keying for updateable content distribution
US20050050218A1 (en) * 2003-09-02 2005-03-03 Microsoft Corporation Video delivery workflow
US20070033609A1 (en) * 2003-09-12 2007-02-08 Hiroaki Dei Media stream multicast distribution method and apparatus
US20050228858A1 (en) * 2004-03-25 2005-10-13 Mika Mizutani Content utilization management method corresponding to network transfer, program, and content transfer system
US20070216538A1 (en) * 2004-04-15 2007-09-20 Koninklijke Philips Electronic, N.V. Method for Controlling a Media Content Processing Device, and a Media Content Processing Device
US20060064476A1 (en) * 2004-09-23 2006-03-23 Decasper Dan S Advanced content and data distribution techniques
US20060069720A1 (en) * 2004-09-27 2006-03-30 Kabushiki Kaisha Toshiba Video distributing system, video distributing method, and server
US8255950B1 (en) * 2004-10-28 2012-08-28 Aol Inc. Dynamic identification of other viewers of a television program to an online viewer
US20070038717A1 (en) * 2005-07-27 2007-02-15 Subculture Interactive, Inc. Customizable Content Creation, Management, and Delivery System
US20070061835A1 (en) * 2005-08-05 2007-03-15 Realnetworks, Inc. System and method for registering users and devices
US20070060096A1 (en) * 2005-09-14 2007-03-15 Yoshiaki Hayakawa Communications system, presence server, and communications method used for them
US20080027792A1 (en) * 2006-07-26 2008-01-31 Wu Louis L Election-based electronic compilations
US20120232916A1 (en) * 2006-07-26 2012-09-13 V V S Virtual Video Systems (Canada) Inc. Video and multimedia distribution system
US8275746B2 (en) * 2006-07-26 2012-09-25 V V S Virtual Video Systems (Canada) Inc. Video and multimedia distribution system
US8438603B2 (en) * 2006-12-22 2013-05-07 Time Warner Cable Inc. Methods and apparatus for supporting content distribution
US20080243527A1 (en) * 2007-03-30 2008-10-02 Macrovision Corporation Custom Media Production and Distribution System and Methods
US20100175100A1 (en) * 2009-01-06 2010-07-08 Koichi Ogasawara Presence information sharing apparatus, presence information sharing method, presence information sharing program and presence information sharing system
US20100254536A1 (en) * 2009-04-02 2010-10-07 Broadcom Corporation Authenticated mode control
US20120102184A1 (en) * 2010-10-20 2012-04-26 Sony Corporation Apparatus and method for adaptive streaming of content with user-initiated quality adjustments
US20130304604A1 (en) * 2011-11-02 2013-11-14 Michael Theodor Hoffman Systems and methods for dynamic digital product synthesis, commerce, and distribution
US20130275611A1 (en) * 2012-04-16 2013-10-17 Oren Somekh Method and system of dynamic routing of aggregated online media streams

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9213724B2 (en) 2007-10-22 2015-12-15 Sony Corporation Information processing terminal device, information processing device, information processing method, and program
US20120185566A1 (en) * 2007-11-07 2012-07-19 Sony Corporation Server device, client device, information processing system, information processing method, and program
US8862781B2 (en) * 2007-11-07 2014-10-14 Sony Corporation Server device, client device, information processing system, information processing method, and program
US9319487B2 (en) 2007-11-07 2016-04-19 Sony Corporation Server device, client device, information processing system, information processing method, and program
US20110066742A1 (en) * 2009-08-21 2011-03-17 Yiubun Lee Devices and methods for scheduling transmission time of media data
US8719435B2 (en) * 2009-08-21 2014-05-06 The Chinese University Of Hong Kong Devices and methods for scheduling transmission time of media data
US20110209224A1 (en) * 2010-02-24 2011-08-25 Christopher Gentile Digital multimedia album
US10264305B2 (en) * 2010-03-02 2019-04-16 Twentieth Century Fox Film Corporation Delivery of encoded media content
CN103310162A (en) * 2012-03-06 2013-09-18 北京印刷学院 Remote format file transmitting system and method based on central node mode

Also Published As

Publication number Publication date
CA2649395A1 (en) 2007-01-25
US20090204670A1 (en) 2009-08-13
EP1910935A4 (en) 2009-09-09
US20090222865A1 (en) 2009-09-03
US8627507B2 (en) 2014-01-07
WO2007011537A3 (en) 2007-07-19
US20150058453A1 (en) 2015-02-26
US8880733B2 (en) 2014-11-04
US20090187947A1 (en) 2009-07-23
US20090222930A1 (en) 2009-09-03
EP1910935A2 (en) 2008-04-16
US20070016530A1 (en) 2007-01-18
WO2007011537A2 (en) 2007-01-25

Similar Documents

Publication Publication Date Title
US8880733B2 (en) System and method for optimizing distribution of media files with transmission based on recipient site requirements
US9027063B2 (en) Video-on-demand (VOD) management system and methods
US8136142B2 (en) Centralized content management system for managing distribution of packages to video service providers
US7054949B2 (en) System and method for streaming media
US9743147B2 (en) Network video unit
US9563703B2 (en) System, method and device for sharing of playlists of authorized content with other users
US10229438B2 (en) System and method for integrated, automated inventory management and advertisement delivery
US20030088686A1 (en) System and method for streaming media
US20150089020A1 (en) Live video content exchange
US20070067806A1 (en) Provision of broadcast network services
CA2440279A1 (en) Method and system for managing and updating metadata associated with digital assets
US20090271837A1 (en) Apparatus and method for providing broadcast contents in internet broadcast system
US8037499B2 (en) Systems, methods, and computer products for recording of repeated programs
WO2013186663A1 (en) Live video content exchange
US7593922B1 (en) Method and system for providing delivery of segmented data files
US10733663B2 (en) Systems and methods for strategic customer order capture
US8380816B2 (en) System and method for managing and distributing bundled code objects

Legal Events

Date Code Title Description
AS Assignment

Owner name: MORGAN STANLEY SENIOR FUNDING, INC., NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:TVN ENTERTAINMENT CORPORATION;REEL/FRAME:022804/0332

Effective date: 20090609

Owner name: NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE, VIR

Free format text: SECURITY AGREEMENT;ASSIGNORS:AVAIL MEDIA HOLDINGS, INC.;AVAIL MEDIA, INC.;AVAIL ON DEMAND, INC.;AND OTHERS;REEL/FRAME:022804/0254

Effective date: 20090609

AS Assignment

Owner name: SILICON VALLEY BANK, MASSACHUSETTS

Free format text: SECURITY AGREEMENT;ASSIGNORS:AVAIL MEDIA HOLDINGS, INC.;AVAIL MEDIA, INC. F/K/A SYNDETIK, INC.;AURORAS ENTERTAINEMENT, INC.;AND OTHERS;REEL/FRAME:028246/0581

Effective date: 20120521

AS Assignment

Owner name: AVAIL MEDIA, INC., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: TVN ENTERTAINMENT CORPORATION, VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: AVAIL MEDIA HOLDINGS, INC., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: BROADSTREAM COMMUNICATIONS, INC., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: IBBOC, L.L.C., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: AVAIL ON DEMAND, INC., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

Owner name: AURORAS ENTERTAINMENT, INC., VIRGINIA

Free format text: TERMINATION;ASSIGNOR:NATIONAL RURAL TELECOMMUNICATIONS COOPERATIVE;REEL/FRAME:028498/0289

Effective date: 20120604

AS Assignment

Owner name: TVN ENTERTAINMENT CORPORATION, CALIFORNIA

Free format text: PATENT OWNERSHIP;ASSIGNORS:STASI, CHRISTOPHER;PERDUE, KELLY;STASI, DOM;REEL/FRAME:030360/0265

Effective date: 20060721

Owner name: VUBIQUITY ENTERTAINMENT CORPORATION, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:TVN ENTERTAINMENT CORPORATION;REEL/FRAME:030361/0939

Effective date: 20130305

AS Assignment

Owner name: AVAIL ON DEMAND, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: IBBOC, L.L.C., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: TVN ENTERTAINMENT CORPORATION, VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: AURORAS ENTERTAINMENT, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: AVAIL MEDIA HOLDINGS, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: BROADSTREAM COMMUNICATIONS, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: AVAIL MEDIA, INC., VIRGINIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:030387/0840

Effective date: 20120723

Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, IL

Free format text: NOTICE OF GRANT OF SECURITY INTEREST IN PATENTS;ASSIGNOR:VUBIQUITY ENTERTAINMENT CORPORATION;REEL/FRAME:030390/0449

Effective date: 20130508

Owner name: AVAIL-TVN INTERNATIONAL HOLDINGS, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

Owner name: VUBIQUITY, INC. (F/K/A AVAIL MEDIA, INC.), VIRGINI

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

Owner name: BROADSTREAM COMMUNICATIONS, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

Owner name: VUBIQUITY ENTERTAINMENT CORPORATION (F/K/A TVN ENT

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

Owner name: AVAIL MEDIA HOLDINGS, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

Owner name: AURORAS ENTERTAINMENT, INC., VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SILICON VALLEY BANK, AS ADMINISTRATIVE AGENT;REEL/FRAME:030390/0439

Effective date: 20130508

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: VUBIQUITY ENTERTAINMENT CORPORATION, VIRGINIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS (RECORDED 5/9/13 AT REEL/FRAME 030390/0449);ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:036343/0721

Effective date: 20150812

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551)

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8