Abstract:
An IPTV network and a method are described herein that seamlessly integrate a multicast-based file transfer mechanism with unicast IPTV middleware to enable the efficient transfer of VOD assets from a Super Headend Office (SHO) to one or more Video Hub Offices (VHOs).

Description:
CLAIM BENEFIT OF PRIOR FILED U.S. APPLICATION 
       [0001]    This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/943,161 which was filed on Jun. 11, 2007 the contents of which are hereby incorporated by reference herein. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention is related to an IPTV network that seamlessly integrates a multicast-based file transfer mechanism with unicast IPTV middleware to enable the efficient transfer of Video-On-Demand (VOD) assets from a Super Headend Office (SHO) to one or more Video Hub Offices (VHOs). 
       DESCRIPTION OF RELATED ART 
       [0003]    The following abbreviations are herewith defined, at least some of which are referred to in the ensuing description of the prior art and the present invention. 
       API Application Programming Interface 
     BTV Broadcast Television 
     CO Central Office 
     DAS Direct Attached Storage 
       [0004]    DNS Domain Name server 
       DRM Digital Rights Management 
     DSL Digital Subscriber Line 
     DSLAM Digital Subscriber Line Access Multiplexer 
     FQDN Fully-Qualified Domain Name 
     HTTP HyperText Transfer Protocol 
     HTTPS HyperText Transfer Protocol Secure 
     IP Internet Protocol 
     IPTV Internet Protocol Television 
     OSS Operations Support System 
     RGW Residential Gateway 
     SAI Service Area Interface 
     SHO Super Headend Office 
     SMT Service Management Tool 
     SSL Secure Sockets Layer 
     STB Set-Top Box 
     TV Television 
     UDP User Datagram Protocol 
     URI Uniform Resource Indicator 
     VHO Video Hub Office 
     VOD Video-On-Demand 
       [0005]    Referring to  FIG. 1  (PRIOR ART), there is a block diagram that illustrates the basic components of an exemplary IPTV network  100  which provides broadcast TV channels to homes via for example optical fiber or DSL phone lines. The exemplary IPTV network  100  shown includes two SHOs  102 , a backbone network  104 , multiple VHOs  106 , multiple IOs  108 , multiple COs  110 , multiple SAIs  112  and multiple RGWs  114 . In operation, each SHO  102  receives international/national TV feeds and supplies those international/national TV feeds via the backbone network  104  to each VHO  106 . Then, each VHO  106  receives regional/local TV feeds and multicasts all of the TV feeds to their respective IOs  108 . And, each IO  108  then multicasts all of the TV feeds to their respective COs  110 . Then, each CO  110  multicasts all of the TV feeds to their respective SAIs  112 . And, each SAI  112  then sends a few TV feeds out of all the possible TV feeds to their respective RGWs  114  which are associated with STBs  115 . Thus, users can interface with their STB  115  and select one of the multicast TV channels to watch on their television set. If desired, the users can interface with their STB  115  and select a VOD to watch on their television set. The VOD feature and in particular how VOD assets (e.g., VOD titles) can be transported from each SHO  102  and deployed in their respective VHOs  106  is a main topic of the present discussion. 
         [0006]    Referring to  FIG. 2  (PRIOR ART), there is a diagram illustrating the basic components within the traditional SHO  102  and the traditional VHO  106  which has a bandwidth VOD asset deployment problem that will be addressed by the present invention. As shown, the traditional SHO  102  includes a VOD OSS/SMT server  202  and a VOD importer server  204 . The traditional VHO  106  includes a branch management server  206 , a branch controller  208 , a branch database  210  and multiple VOD servers  212   a  and  212   b  (two shown). The SHO  102  and VHO  106  may include more components than the ones discussed herein but for clarity only the components associated with the present invention have been described herein. 
         [0007]    In the current IPTV architecture, a VOD asset  214  (e.g., VOD title) is sent from a post-production house and received at the VOD importer server  204  in the SHO  102 . The VOD importer server  204  places the VOD asset  214  in a staging volume  216  and applies encryption algorithms  218  (e.g., DRM keys  218 ) and makes custom metadata  220  modifications to the VOD asset  214 . Once this is complete, the VOD asset  214  is ready for distribution to all of the VHOs  106  (only one has been shown). How this is done when the IPTV network  100  and in particular the SHO  102  and VHO  106  implement a unicast IPTV middleware  221  such as Microsoft&#39;s Mediaroom Middleware is described next. 
         [0008]    The operator  222  interfaces (step  1   a ) with the branch management server  206  and instructs (step  1   b ) the branch controller  208  to make an HTTPS connection  224  with the VOD OSS/SMT server  202  in the SHO  102  (step  1   c ). The VOD OSS/SMT server  202  requests the file locations and status for the desired VOD asset  214  from the VOD importer server  204  (steps  1   d  and  1   e ). The collected data is returned back to the branch controller  208  and is stored in the branch database  210  (step  1   f ). Based on current usage statistics, the branch controller  208  then assigns a configurable number of VOD servers  212   a  and  212   b  to retrieve the VOD asset  214 . Thereafter, the first VOD server  212   a  checks in with the branch controller  208  every 10 seconds (step  2   a ), at which time the branch controller  208  queries the branch database  210  to determine if a job exists for the VOD server  212   a  (step  2   b ). Since there is a job, the first VOD server  212   a  retrieves the VOD asset  214  from the VOD importer server  204  in the SHO  102  via a HTTPS connection  226  (steps  2   c  and  2   d ) and stores the VOD asset  214  on a connected DAS device  228  (step  2   e ). When this download is complete, the branch controller  208  contacts the VOD OSS/SMT server  202  in the SHO  102  via another HTTPS connection  230  to retrieve the DRM keys  218  (step  3   a ). The VOD OSS/SMT server  202  proxies (step  3   b ) the request to the VOD importer server  204  which performs a proper transcription (step  3   c ) based on the branch certificate&#39;s public key and returns the DRM keys  218 . The branch controller  208  then stores the DRM keys  218  in the branch database  210  (step  3   d ). At this point in the transfer process, the remaining VOD server(s)  212   b  (only one shown) in the VHO  106  will be triggered to retrieve the VOD asset  214 . Upon being triggered, the remaining VOD server(s)  212   b  check (step  4   a ) with the branch controller  208  but instead of retrieving the asset from the SHO  102 , the remaining VOD server(s)  212   b  retrieve the VOD asset  214  from the first VOD server  212   a  (steps  4   b  and  4   c ). Then, the remaining VOD server(s)  212   b  store the VOD asset  214  in the media volume on their connected DAS device(s)  228  (step  4   d ). 
         [0009]    In this scheme, the VHO  106  has one VOD server  212   a  which retrieves the VOD asset  214  using the HTTPS connection  226  from the VOD importer server  204  within the SHO  102 . However, each VOD asset  214  is comprised of several large files which can be up to 2 GB in size that have to pass through the HTTPS connection  230 . This is problematical since the bandwidth required for the transfer of this VOD asset  214  can be a bottleneck for deployment. This is especially true since each of the VHOs  106  in the IPTV network  100  has one VOD server  212   a  which retrieves the VOD asset  214  from their respective SHO  102  in this manner. Accordingly, there has been a need and still is a need for addressing this shortcoming and other shortcomings which cause bandwidth problems for IPTV networks that implement unicast IPTV middleware. This need and other needs have been satisfied by the present invention. 
       SUMMARY 
       [0010]    In one aspect, the present invention provides a method that seamlessly integrates a multicast-based file transfer mechanism with unicast IPTV middleware so as to be able to efficiently transfer VOD assets from a SHO to a VHO. In one embodiment, the method comprises the steps of: (a) using a multicast file transfer server associated with the SHO to multicast the VOD asset to one or more multicast file transfer clients in the VHO; (b) storing the VOD asset received by the one or more multicast file transfer clients within one or more multicast caches in the VHO; (c) accessing a unicast IPTV middleware in the VHO to initiate deployment of the VOD asset from the one or more multicast caches to one or more VOD servers within said VHO; (d) deploying the VOD asset using a HTTP connection from one multicast cache to the first VOD server within the VHO; and (e) instructing each of the remaining VOD servers if any within the VHO to retrieve the VOD asset from the first VOD server. 
         [0011]    In another aspect, the present invention provides an IPTV network that seamlessly integrates a multicast-based file transfer mechanism with unicast IPTV middleware so as to be able to efficiently transfer VOD assets from a SHO to a VHO. In one embodiment, the SHO includes a multicast file transfer server that multicast a VOD asset to one or more multicast file transfer clients associated with the VHO. The VHO includes one or more multicast caches that store the VOD asset received by the one or more multicast file transfer clients. Plus, the VHO includes a branch management server with unicast IPTV middleware that initiates deployment of the VOD asset from the one or more multicast caches to one or more VOD servers in the VHO. In addition, the VHO includes a branch controller that uses a HTTP connection to deploy the VOD asset from one multicast cache to the first VOD server. Furthermore, the VHO includes the branch controller that instructs each of the remaining VOD servers if any to retrieve the VOD asset from the first VOD server. 
         [0012]    Additional aspects of the invention will be set forth, in part, in the detailed description, figures and any claims which follow, and in part will be derived from the detailed description, or can be learned by practice of the invention. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as disclosed. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein: 
           [0014]      FIG. 1  (PRIOR ART) is a diagram of an exemplary IPTV network which has traditional SHOs and traditional VHOs that provide broadcast TV channels to homes via for example optical fiber or DSL phone lines; 
           [0015]      FIG. 2  (PRIOR ART) is a diagram of one of the traditional SHOs and one of the traditional VHOs shown in  FIG. 1  which is used to help explain a VOD asset deployment bandwidth problem that is solved by the present invention; 
           [0016]      FIG. 3  is a diagram of an exemplary IPTV network which has enhanced SHOs and enhanced VHOs in accordance with the present invention; 
           [0017]      FIG. 4  is a diagram of one of the enhanced SHOs and one of the enhanced VHOs shown in  FIG. 3  that addresses the aforementioned VOD asset deployment bandwidth problem in accordance with a first embodiment of the present invention; and 
           [0018]      FIG. 5  is a diagram of one of the enhanced SHOs and one of the enhanced VHOs shown in  FIG. 3  that addresses the aforementioned VOD asset deployment bandwidth problem in accordance with a second embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    Referring to  FIG. 3 , there is a block diagram that illustrates the basic components of an exemplary IPTV network  300  which has enhanced SHOs  302  and enhanced VHOs  306  that together address the aforementioned bandwidth VOD asset deployment problem in accordance with the present invention. The exemplary IPTV network  300  shown includes two enhanced SHOs  302 , a backbone network  304 , two enhanced VHOs  306 , multiple IOs  308 , multiple COs  310 , multiple SAIs  312  and multiple RGWs  314 . In operation, each enhanced SHO  302  receives international/national TV feeds and supplies those international/national TV feeds via the backbone network  304  to each enhanced VHO  306 . Then, each enhanced VHO  306  receives regional/local TV feeds and multicasts all of the TV feeds to their respective IOs  308 . And, each IO  308  then multicasts all of the TV feeds to their respective COs  310 . Then, each CO  310  multicasts all of the TV feeds to their respective SAIs  312 . And, each SAI  312  then sends a few TV feeds out of all the possible TV feeds to their respective RGWs  314  which are associated with STBs  315 . Thus, users can interface with their STB  315  and select one of the multicast TV channels to watch on their television set. If desired, the users can interface with their STB  315  and select a VOD to watch on their television set. The VOD feature and in particular how VOD assets (e.g., VOD titles) can be efficiently transported from the enhanced SHOs  302  and deployed in their respective enhanced VHOs  306  is discussed in detail below with respect to  FIGS. 4-5 . 
         [0020]    Referring to  FIG. 4 , there is a diagram illustrating the basic components within the enhanced SHO  302 ′ and the enhanced VHO  306 ′ shown in  FIG. 3  in accordance with a first embodiment of the present invention. As shown, the enhanced SHO  302 ′ includes a VOD OSS/SMT server  402 , a VOD importer server  404 , and a third-party multicast file transfer server  405  (compare to  FIG. 2 ). The enhanced VHO  306  includes a branch management server  406 , a branch controller  408 , a branch database  410 , multiple VOD servers  412   a  and  412   b  (two shown), and third-party multicast file transfer clients  413   a  and  413   b  (compare to  FIG. 2 ). The enhanced SHO  302 ′ and VHO  306 ′ may include more components than the ones discussed herein but for clarity only the components associated with the present invention have been described herein (note: the same is true for the enhanced SHO  302 ′ and the enhanced VHO  306 ′ which are discussed in detail below with respect to  FIG. 5 ). 
         [0021]    Basically, the present invention is related to seamlessly integrating the multicast file transfer server  405 , the multicast file transfer clients  413   a  and  413   b  and the unicast-based IPTV middleware  421  (shown in the branch management server  406 ) by making a change as to how the VOD asset  414  is transported so as to be transparent to the unicast-based IPTV middleware  421 . This seamless integration allows the bandwidth-efficient deployment tools associated with the multicast file transfer server  405  and the multicast file transfer client(s)  413   a  and  413   b  to efficiently transport VOD assets  414  from one or more SHOs  302 ′ to their respective VHO&#39;s  306 ′. A more detailed description about one way that this seamless integration can be implemented is provided after a brief discussion about the changes that should be made to the traditional architecture and traditional network flows of the SHOs and the VHOs. 
         [0022]    First, a multicast file transfer product including the multicast file transfer server  405  and the multicast file transfer client(s)  413   a  and  413   b  should be selected or designed which can provide, for example, the following functionalities:
       The multicast file transfer product  405 ,  413   a  and  413   b  should provide reliable multicast file transfer, meaning any lost packets should be retransmitted or recovered to ensure the file (e.g., VOD asset  414 ) is not corrupted or incomplete at the receivers (e.g., VHOs  306 ′).   The multicast file transfer product  405 ,  413   a  and  413   b  should provide/feedback about the state of the receivers (e.g., VHOs  306 ′) to allow the sender (e.g., SHO  302 ′) and, thus, the operator  422  to determine when all of the receivers (e.g., VHOs  306 ′) have successfully received the file (e.g., VOD asset  414 ).   The multicast file transfer product  405 ,  413   a  and  413   b  should provide multicast transfer since a multipoint transfer which creates unicast streams to the receivers (e.g., VHOs  306 ′) is not acceptable.       
 
         [0026]    Several commercial off-the-shelf products such as, for example, the Stratacache OmniCast product satisfy these requirements. 
         [0027]    Second, the IPTV servers  402 ,  404 ,  406 ,  408 ,  412   a  and  412   b  need to be configured to allow the multicast transfer to operate transparently to the unicast IPTV middleware  421 . The following changes should be made:
       The multicast file transfer server  405  needs to be installed in the SHO  302 ′ such that it has read access to the staging volume  416  in the VOD importer server  404 . The staging volume  416  houses the encrypted VOD assets  414  which will be deployed to the VHO  306 ′ during VOD deployments. Assuming Microsoft&#39;s Mediaroom Middleware is being utilized, the multicast file transfer server  405  could be installed on the VOD importer server  304  itself, if the multicast file transfer server  405  selected is compatible with Windows server 2003.   A local “multicast cache” volume  415   a  and  415   b  needs to be created on each VOD server  412   a  and  412   b  in the VHO  306 ′ if the multicast file transfer clients  413   a  and  413   b  are installed directly on the VOD servers  412   a  and  412   b . The local “multicast cache” volume  415   a  and  415   b  can physically reside on the local hard drives or be a subsection of a mounted disk array. The local “multicast cache” volume  415   a  and  415   b  should be shared via IIS as a virtual directory, with the appropriate security permissions applied. This share is named “staging” to match the “staging” volume name in the local cache volume  416  of the VOD importer server  404  within the SHO  302 ′. The size of the multicast cache volume  415   a  and  415   b  determines how many VOD assets  414  can be in-flight at any given time, so they should be configured based on the expected VOD deployment operational profile. Also, some consideration should be taken into account to allow for the expected larger file sizes associated with future high-definition (HD) VOD assets. In another embodiment, the multicast file transfer client  413  can be installed on a separate/dedicated server and not the VOD servers  412   a  and  412   b . This embodiment is discussed below with respect to  FIG. 5 .   A pruning job should be used to remove any files older than a configurable date/time to prevent the local “multicast cache” volume  415   a  and  415   b  from growing too large.   The software associated with the multicast file transfer client  413   a  and  413   b  needs be installed in the VHO  306 ′ so that it has write access to the multicast cache volume  415   a  and  415   b . Assuming Microsoft&#39;s Mediaroom Middleware is being utilized, the multicast file transfer client software  413   a  and  413   b  could be installed directly on the VOD servers  412   a  and  412   b  if the software is compatible with Windows server 2003.   The VOD importer server  404  in the SHO  302 ′ needs to be updated to use HTTP transfers instead of HTTPS to access the “staging” virtual directory in the staging volume  416  of the VOD importer server  404 . Thus, the HTTPS connection  230  (SSL tunnel) used in the prior art will no longer be necessary, as the VOD servers  412   a  and  412   b  in the VHO  306 ′ will no longer directly contact the VOD importer server  404  for deployments of VOD assets  414  (a more detailed discussion about this aspect is provided below).   The hosts file (e.g., located in C:\WINDOWS\system32\drivers\etc\) needs to be updated on each VOD server  412   a  and  412   b  to translate the fully-qualified domain name (FQDN) of the VOD importer server  404  in the SHO  302  to the corresponding VOD server&#39;s local loopback IP address of 127.0.0.1 (for example) if they have the multicast file transfer client  413   a  and  413   b  installed thereon (a more detailed discussion about this aspect is provided below). Alternatively, if the multicast file transfer client  413  is installed on a separate server, then the hosts file should be updated to translate the FQDN of the VOD importer server  404  to the IP address of the separate server (see the discussion related to  FIG. 5 ).       
 
         [0034]    In view of these changes, the following flow could occur to deploy a VOD asset  414  from the SHO  302 ′ to the VHO  306 ′. This exemplary flow is illustrated in  FIG. 4 , which shows a first embodiment of the present invention where the software for the multicast file transfer clients  413   a  and  413   b  has been installed directly on the VOD servers  412   a  and  412   b . In this example, a VOD asset  414  (e.g., VOD title) is sent from a post-production house and received at the VOD importer server  404  in the SHO  302 ′. The VOD importer server  404  places the VOD asset  414  in a staging volume  416  and applies encryption algorithms  418  (e.g., DRM keys  418 ) and makes custom metadata  420  modifications to the VOD asset  414 . Once this is complete, the VOD asset  414  is ready for distribution to all of the VHOs  306  (only one has been shown). To accomplish this, the operator  422  accesses the third party multicast file transfer server  405  and chooses to download the files of the desired VOD asset  414  to all of the VOD servers  412   a  and  412   b  (step  1   a ). The multicast file transfer server  405  retrieves the metadata  420  and media files related to the VOD asset  414  from the staging volume/folder  416  in the VOD importer server  404  (step  1   b ). The multicast file transfer server  405  then multicasts over UDP the required files associated with the VOD asset  414  to all of the third party multicast file transfer clients  413   a  and  413   b  associated with the VOD servers  412   a  and  412   b  (step  1   c ) (note: the files could also be multicast at the same time to other VHOs  306 ′). If needed, the third party multicast file transfer clients  413   a  and  413   b  may request retransmissions for any packets lost during the transmission of the VOD asset  414 . The VOD asset  414  is stored in the configured “staging” cache volume  415   a  and  415   b  in each of the VOD servers  412   a  and  412   b  (step  1   d ). 
         [0035]    When the file transfer is complete, the operator  422  accesses the unicast IPTV middleware  421  in the branch management server  406  and chooses to deploy the VOD asset  414  (step  2   a ). In response, the branch management server  406  proxies the request to the branch controller  408  (step  2   b ). The branch controller  408  creates (step  2   c ) an HTTPS tunnel  424  to the VOD OSS/SMT server  402  which then proxies the request to the VOD importer server  404  to verify the status of the VOD asset  414  and retrieve the file location (steps  2   d  and  2   e ). The retrieved file location is an URI which contains the FQDN of the VOD importer server  404 , such as “http://shovodimp01.sho.domain.com/Staging/asset1/asset_file1.rtp”. Upon receiving the URI of the VOD importer server  404 , the branch controller  408  stores the results of this transaction within the branch database  410  and creates the deployment jobs for the VOD servers  412   a  and  412   b  (step  2   f ). 
         [0036]    Thereafter, when the first VOD server  412   a  checks in with the branch controller  408  (step  3   a ), it is assigned its deployment job as listed in the branch database  410  (step  3   b ). The first VOD server  412   a  then uses the URI retrieved by the branch controller  408  to download (step  3   c ) the required files of the VOD asset  414  which where previously stored in its own configured “staging” cache volume  415   a . This is possible since each VOD server  412   a  and  412   b  previously updated its host files (e.g., located in C:\WINDOWS\system32\drivers\etc\) to force the translation of the FQDN of the VOD importer server  404  to their respective VOD server&#39;s local IP address of 127.0.0.1 (for example) which is associated with the location of the multicast cache volumes  415   a  and  415   b . Without the hosts entry, the FQDN would be translated by a DNS (not shown) at deployment time to the VOD importer server&#39;s  404  IP address, forcing the VOD server  412   a  to send a request during step  3   c  to the VOD importer server  404  in the SHO  302 ′. Instead, as a result of all of this, the VOD server  412   a  will locally retrieve (step  3   c ) the files of the VOD asset  414  via HTTP from the multicast cache volume  415   a  which is desirable because the VOD server  412   a  no longer needs to use the problematical HTTPS connection  230  (SSL tunnel) to retrieve the files directly from the VOD importer server  404  as was required in the prior art (compare  FIGS. 2 and 4 ). This saves a large amount of bandwidth since the VOD server  412   a  no longer needs to directly contact the VOD importer server  404  during the deployment of the VOD assets  414 . Finally, the VHO server  412   a  would store the retrieved files associated with the VOD asset  414  in the media share volume of the connected DAS device  428  (step  3   d ). 
         [0037]    At this point, the branch controller  408  creates an HTTPS connection  430  to the VOD OSS/SMT server  402  in the SHO  302 ′ to retrieve the DRM keys  418  for the VOD asset  414  (step  4   a ). The VOD OSS/SMT server  402  proxies the request to the VOD importer server  404  which performs a proper transcription based on the branch certificate&#39;s public key and returns the DRM keys  418  (steps  4   b  and  4   c ). The branch controller  408  then stores the DRM keys  418  in the branch database  410  (step  4   d ). This transfer requires very low bandwidth. Thereafter, the remaining VOD server(s)  412   b  (only one shown) retrieves the VOD asset  414  from the first VOD server&#39;s DAS device  428 . In particular, each remaining VOD server  412   b  retrieves their jobs from the branch controller  408  (step  5   a ), accesses the first VOD server&#39;s DAS device  428  via HTTP (steps  5   b  and  5   c ) and stores the metadata and media files associated with the VOD asset  414  on their local DAS device  428  (step  5   d ). 
         [0038]    Referring to  FIG. 5 , there is a diagram illustrating the basic components within the enhanced SHO  302 ″ and the enhanced VHO  306 ″ shown in  FIG. 3  in accordance with a second embodiment of the present invention. As shown, the enhanced SHO  302 ″ includes a VOD OSS/SMT server  402 , a VOD importer server  404 , and a third-party multicast file transfer server  405 . The enhanced VHO  306 ″ includes a branch management server  406 , a branch controller  408 , a branch database  410 , multiple VOD servers  412   a  and  412   b  (two shown), a third-party multicast file transfer client  413   c , and a dedicated server  417  (compare to  FIG. 4 ). The IPTV servers  402 ,  404 ,  406 ,  408 ,  412   a  and  412   b , and  417  are configured as discussed above with respect to the first embodiment so as to allow the multicast transfer of the VOD asset  414  to operate transparently to the unicast IPTV middleware  421 . An exemplary flow is illustrated in  FIG. 5 , which shows a second embodiment of the present invention being implemented when the software for the multicast file transfer client  413  has been installed on the dedicated server  417 . 
         [0039]    In this IPTV architecture, a VOD asset  414  (e.g., VOD title) is sent from a post-production house and received at the VOD importer server  404  in the SHO  302 ″. The VOD importer server  404  places the VOD asset  414  in a staging volume  416  and applies encryption algorithms  418  (e.g., DRM keys  418 ) and makes custom metadata  420  modifications to the VOD asset  414 . Once this is complete, the VOD asset  414  is ready for distribution to all of the VHOs  306 ″ (only one has been shown). To accomplish this, the operator  422  accesses the third party multicast file transfer server  405  and chooses to download the files of the desired VOD asset  414  to the dedicated server  417  in the VHO  306 ″ (step  1   a ). The multicast file transfer server  405  retrieves the metadata  420  and media files related to the VOD asset  414  from the staging volume/folder  416  in the VOD importer server  404  (step  1   b ). The multicast file transfer server  405  then multicasts over UDP the required files associated with the VOD asset  414  to the multicast file transfer client  413   c  which is associated with the dedicated server  417  (step  1   c ) (note: the files could also be multicast at the same time to other VHOs  306 ″). If needed, the third party multicast file transfer client  413   c  may request retransmissions for any packets lost during the transmission of the VOD asset  414 . The VOD asset  414  is stored in the configured “staging” cache volume  415   c  in dedicated server  417  (step  1   d ). 
         [0040]    When the file transfer is complete, the operator  422  accesses the unicast IPTV middleware  421  in the branch management server  406  and chooses to deploy the VOD asset  414  (step  2   a ). In response, the branch management server  406  proxies the request to the branch controller  408  (step  2   b ). The branch controller  408  creates (step  2   c ) an HTTPS tunnel  424  to the VOD OSS/SMT server  402  which then proxies the request to the VOD importer server  404  to verify the status of the VOD asset  414  and retrieve the file location (steps  2   d  and  2   e ). The retrieved file location is an URI which contains the FQDN of the VOD importer server  404 , such as “http://shovodimp01.sho.domain.com/Staging/asset1/asset_file1.rtp”. Upon receiving the URI of the VOD importer server  404 , the branch controller  408  stores the results of this transaction within the branch database  410  and creates the deployment jobs for the VOD servers  412   a  and  412   b  (step  2   f ). 
         [0041]    Thereafter, when the first VOD server  412   a  checks in with the branch controller  408  (step  3   a ), it is assigned its deployment job as listed in the branch database  410  (step  3   b ). The first VOD server  412   a  then uses the URI retrieved by the branch controller  408  to download (step  3   c ) the required files of the VOD asset  414  which where previously stored in the dedicated server&#39;s configured “staging” cache volume  415   c . This is possible since each VOD server  412   a  and  412   b  previously updated its host files (e.g., located in C:\WINDOWS\system32\drivers\etc\) by translating the FQDN of the VOD importer server  404  to the dedicated server&#39;s local IP address 10.1.1.10 (for example) which is associated with the location of the multicast cache volume  415   c . Without the hosts entry, the FQDN would be translated by a DNS (not shown) at deployment time to the VOD importer server&#39;s  404  IP address, forcing the VOD server  412   a  to send a request during step  3   c  to the VOD importer server  404  in the SHO  302 ′. Instead, as a result of all of this, the VOD server  412   a  will retrieve (step  3   c ) the files of the VOD asset  414  via HTTP from the dedicated server  417  which is desirable because the VOD server  412   a  no longer needs to use the problematical HTTPS connection  230  (SSL tunnel) to retrieve the files directly from the VOD importer server  404  as was required in the prior art (compare  FIGS. 2 and 5 ). This saves a large amount of bandwidth since the VOD server  412   a  no longer needs to directly contact the VOD importer server  404  during the deployment of the VOD assets  414 . Finally, the VHO server  412   a  would store the retrieved files associated with the VOD asset  414  in the media volume in the connected DAS device  428  (step  3   d ). 
         [0042]    At this point, the branch controller  408  creates an HTTPS connection  430  to the VOD OSS/SMT server  402  in the SHO  302 ″ to retrieve the DRM keys  418  for the VOD asset  414  (step  4   a ). The VOD OSS/SMT server  402  proxies the request to the VOD importer server  404  which performs a proper transcription based on the branch certificate&#39;s public key and returns the DRM keys  418  (steps  4   b  and  4   c ). The branch controller  408  then stores the DRM keys  418  in the branch database  410  (step  4   d ). This transfer requires very low bandwidth. Thereafter, the remaining VOD server(s)  412   b  (only one shown) retrieves the VOD asset  414  from the first VOD server&#39;s DAS device  428 . In particular, each remaining VOD server  412   b  retrieves their jobs from the branch controller  408  (step  5   a ), accesses the first VOD server&#39;s DAS device  428  via HTTP (steps  5   b  and  5   c ) and stores the metadata and media files associated with the VOD asset  414  on their local DAS device  428  (step  5   d ). 
         [0043]    In the second embodiment, the multicast file transfer client  414   c  is installed directly on the dedicated server  417  instead of the VOD servers  412   a  and  412   b  which is desirable since the multicast file transfer client  414   c  and cache  415   c  would be installed on a smaller subset of servers within each VHO  306 ″. In this scheme, a smaller set of servers  417  receive the multicast transfer of the VOD asset  414  which decreases the local load of multicast traffic. Plus, this scheme reduces the number of unused copies of the VOD assets  414  in the VHO  306 ″. Lastly, in this scheme, measures could be taken to provide fault tolerance such that if one dedicated server  417  hosting the multicast file transfer had a failure then an alternate server hosting the same information could be made available. For example, possibilities include multiple entries in the VOD server&#39;s hosts file coupled with a monitoring script to detect communication failures to the dedicated server  417 . 
         [0044]    Referring to both embodiments, if the multicast file transfer product  405 ,  413   a ,  413   b  and  413   c  offers an API which exposes an interface for file transfer and receiver status, further integration benefits could be realized. For instance, a tool could be created which would first interface with the multicast file transfer API to push the files of the VOD asset  414  into the VHOs  306 . When the receivers (VOD servers  412   a  and  412   b , dedicated server  417 ) report a successful transfer (via an API query or callback), the tool could then interface with the unicast IPTV middleware&#39;s API to perform the VOD deployment. Creating such a tool would minimize the amount of manual work for the operator  422  and allow scheduling of VOD deployments during off-peak hours. 
         [0045]    From the foregoing, it should be appreciated that operators of major IPTV middleware solutions can use the present invention to seamlessly integrate a bandwidth-efficient delivery mechanism for VOD assets to their regional sites. The bandwidth required for VOD deployment would be decreased from a function of the number of sites to a single UDP stream per deployment. Thus, the entire network can scale with minimal impact to the VOD deployment process. VOD deployment times would improve dramatically with the increased bandwidth, allowing the operator to keep pace with the current VOD ingestion rate and offer a more appealing VOD lineup to the end-users. This should directly improve the operator&#39;s revenue and operating expenses. 
         [0046]    Although two embodiments of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the invention as set forth and defined by the following claims.