[go: up one dir, main page]

WO2005078623A1 - Systeme reparti et methodologie de distribution de contenu multimedia - Google Patents

Systeme reparti et methodologie de distribution de contenu multimedia Download PDF

Info

Publication number
WO2005078623A1
WO2005078623A1 PCT/US2005/004575 US2005004575W WO2005078623A1 WO 2005078623 A1 WO2005078623 A1 WO 2005078623A1 US 2005004575 W US2005004575 W US 2005004575W WO 2005078623 A1 WO2005078623 A1 WO 2005078623A1
Authority
WO
WIPO (PCT)
Prior art keywords
media
chent
client
top box
server
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.)
Ceased
Application number
PCT/US2005/004575
Other languages
English (en)
Inventor
Jack Oswald
David Williams
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.)
Alio Inc
Original Assignee
Graftworx Inc
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
Priority claimed from US10/709,393 external-priority patent/US20050177853A1/en
Priority claimed from US10/709,391 external-priority patent/US20050177745A1/en
Priority claimed from US10/709,392 external-priority patent/US20050177624A1/en
Application filed by Graftworx Inc filed Critical Graftworx Inc
Priority to EP05713478A priority Critical patent/EP1782343A4/fr
Publication of WO2005078623A1 publication Critical patent/WO2005078623A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management 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/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4432—Powering on the client, e.g. bootstrap loading using setup parameters being stored locally or received from the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4627—Rights management associated to the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/475—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data
    • H04N21/4756—End-user interface for inputting end-user data, e.g. personal identification number [PIN], preference data for rating content, e.g. scoring a recommended movie
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/632—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing using a connection between clients on a wide area network, e.g. setting up a peer-to-peer communication via Internet for retrieving video segments from the hard-disk of other client devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments

Definitions

  • the present invention relates generally to a system providing methods for distribution and playback of media content, with particular emphasis on techniques that allow distributed distribution of media content via a network such as the Internet.
  • video content is being distributed to a large number of consumers.
  • video content has mainly been distributed via broadcast method, namely terrestrial broadcast from an antenna, a satellite, a cable, or the like.
  • broadcast method namely terrestrial broadcast from an antenna, a satellite, a cable, or the like.
  • consumers have long desired access to a much broader variety of media than can possibly be delivered using the broadcast method of distribution.
  • a particular advantage of the broadcast method is that a particular media item, such as a movie, is transmitted once and everyone receives it. This approach works well in an environment with a small number of channels, such as in a market served by the four major television networks.
  • the foregoing advantage turns into a disadvantage because everyone gets exactly the same thing.
  • VOD video on demand
  • the consumer is able to request a particular movie or video item, whereupon the cable company is able to provide that item directly to the consumer.
  • PPV pay per view
  • a cable operator provides some number of PPV channels (from the available limited number of channels), each PPV channel being devoted to showing a schedule of certain movies that the consumer may subscribe to (or not).
  • the movies shown on the PPV channels technically are available to all cable users; however, the movies are encoded such that only the (few) users who are subscribing at that moment of broadcast may unlock the content (e.g., via a key sent to the user's set-top box).
  • PPV and (especially) NOD are not a particularly good use of available broadcast bandwidth. More recently, the Internet has been used to try to meet this broader media demand.
  • the Internet is an attractive channel since it is widely available in many homes, and at ever increasing bandwidth.
  • delivery of media content through the Internet has primarily used a "streaming" technique to a PC.
  • "Streaming" is a technique in which the consumer goes to an online video library, selects an item that he or she wants, and then a server (i.e., the computer that the consumer is communicating with on the Internet) will proceed to provide that stream of information to the consumer (e.g., using Apple QuickTime, Microsoft Windows Media Player, RealOne media player, or the like).
  • the Internet can also provide another way of delivering content. As before, the consumer selects a particular item of interest (e.g., from an online catalog or library) for viewing sometime in the future.
  • peer-to-peer Another distribution method available on the Internet is "peer-to-peer" (P2P) distribution.
  • P2P peer-to-peer
  • a peer-to-peer network is typically a cooperative environment that allows each user (i.e., node) to have a view into (i.e., access to content from) all other users (nodes) that are currently available on the network.
  • the actual content available to a given user on the network is constantly shifting, as nodes are constantly shifting in and out of the network.
  • the user also controls which specific file he or she is selecting from other specific nodes.
  • Each of the foregoing distribution methods has its own set of limitations.
  • With the cable distribution method there is a very limited supply (channel bandwidth) to begin with, so cable operators are forced to have fewer and fewer consumers served by an individual channel in order to increase variety. It is very expensive for cable operators to add the equipment to supply an increasing number of increasingly smaller market segments. NOD is also inefficient and expensive because the service provider needs to use one unique channel, from the limited supply, per user. They must also purchase and install sufficient server capacity to match peak user demand which is only used for short periods per week.
  • the system may have sufficient capacity to handle 100 simultaneous users initially, thereby serving one hundred streams of 1 Mps each.
  • the system is unable to keep up with the infrastructure required to serve increased demand.
  • the problem is exacerbated by the cyclical nature of consumer demand, which peaks at certain times.
  • a provider is required to build out infrastructure that is capable of handling peak loads. Note, however, that during off-peak times that extra capacity is underutilized (in much the same manner as described for the cable NOD operator above). Even if the foregoing limitations were solved, today Internet streaming still suffers from compromised picture quality due to the relatively low bandwidth that is available.
  • peer-to-peer solutions provide little protection for a content provider's underlying copyright rights, and in fact have served as a mechanism for rampant piracy.
  • Broadband generally refers to download upload capability that is improved over conventional "dial-up" (e.g., 56 K modem) access. Examples include cable modem, DSL, TI, T3, or the like. With cable modem broadband access, for example, consumers can typically expect download capability of approximately 1 Mps or greater and upload capability of approximately 256 Kps. This represents an existing resource that is available for distribution of media. In addition to existing broadband connectivity, consumers have access to increasingly more powerful set-top boxes (STBs).
  • STBs set-top boxes
  • a set-top box is basically a computer device (i.e., microprocessor, memory, and storage) that is usually connected directly to the television.
  • the name "set-top” refers to the fact that these devices are often placed on top of a television set.
  • Set-top boxes have typically been used in the past as decoders.
  • a set-top box receives a cable feed or satellite dish feed as input.
  • the set- top box After converting/decoding the incoming signal, the set- top box provides an output signal capable of being displayed on television (e.g., normal NTSC video).
  • DTR digital television recording
  • This feature takes advantage of the fact that incoming information can be digitized, or is already digitized, and therefore can easily be stored on a set-top box hard disk and then replayed in the future.
  • set-top boxes with hard disk storage capability are becoming very prevalent.
  • Network connectivity is another feature recently added to set-top boxes. This allows a set-top box to have access to all of the resources available on the Internet. Although an Internet- enabled set-top box could be connected directly to a DSL or cable modem, the device is more likely to be connected to a home network.
  • Internet connectivity is typically achieved by connecting the home network to a bridge/switch that has Internet connectivity (e.g., from a connected DSL or cable modem).
  • home networks include HomePNA (phone line based), HomePlug (powerline based), and WiFi (wireless based). What is needed is a solution for delivery of media content into the well-developed environment described above which provides users with a wide variety of selections and delivers high-quality content.
  • the solution should efficiently dehver media content while minimizing the total amount of network bandwidth and server infrastructure investment that the content provider needs in order to deliver media content within a reasonable period of time.
  • the solution should incorporate digital rights management technology to secure the media content against unauthorized use.
  • the present invention provides a solution for these and other needs.
  • a method of the present invention for distributing media comprises: receiving at a server a request from a first chent for a particular media item, the first chent having broadband connectivity to other chents; at the server, determining a second client who has an encrypted copy of the desired media item; transferring the encrypted copy of the desired media item from the second chent to the first client; after the encrypted copy has been transferred to the first chent, indicating at the first chent that the desired media item is now available; and in response to receiving payment authorization from the first client, decrypting the desired media item for use at the first client.
  • a distributed media distribution system of the present invention comprises: a plurality of chents having peer-to-peer connectivity to one another; at least one server for processing a request from a first chent for a particular media item, for determining a second client who has an encrypted copy of the desired media item at the server, and for arranging transfer of the encrypted copy of the desired media item from the second chent to the first chent; and a chent rendering device for decrypting the desired media item for use by an authorized user at the first chent.
  • a method of the present invention for secure delivery of media content via the Internet, the method comprises steps of: providing at a server a catalog of media items available in encrypted format from a plurality of devices having broadband connectivity to the Internet; receiving a priority list from a first device representing a prioritized list of media items requested by the first device from the catalog; scheduling delivery to the first device of a particular media item on the priority list from at least one second device having an encrypted copy of the particular media item; transferring an encrypted copy of the particular media item from the at least one second device to the first device; and in response to a request to purchase the particular media item transferred to the first device, providing a decryption key to the first device enabling the encrypted copy of the particular media item to be played at the first device.
  • a distributed media distribution system of the present invention comprises: a plurahty of clients having peer-to-peer connectivity to one another; at least one server for processing a request from a first chent for a particular media item, for determining a second chent who has a protected copy of the desired media item at the server, and for arranging transfer of the protected copy of the desired media item from the second chent to the first chent; and a chent rendering device for storing a protected copy of the desired media item at the first chent and rendering the desired media item to an authorized user at the first chent.
  • Fig. 1 is a very general block diagram of a computer system (e.g., an IBM-compatible system) in which software-implemented processes of the present invention may be embodied.
  • Fig. 2 is a block diagram of a software system for controlling the operation of the computer system.
  • Fig. 3 A is a very general block diagram of the distributed media delivery system of the present invention.
  • Fig. 3B is a high level block diagram illustrating a preferred set-top box client in further detail.
  • Fig. 3C is a high level block diagram illustrating the set-top box device of Fig. 3B in more detail.
  • Fig. 4 is a block diagram illustrating the process for a new user (i.e., new customer) to subscribe to a service for obtaining media content through the system.
  • Fig. 5 is a block diagram illustrating the process for preparing a chent device for delivery to anew chent (i.e,, new user).
  • Fig. 6 is a block diagram depicting the activation of a new client device after the user receives and installs the client device.
  • Fig. 7 is a block diagram illustrating the importation of new items of media content into the system.
  • Fig. 8A is a block diagram illustrating a user adding media to his or her priority hst.
  • Figs. 8B-E are bitmap screenshots showing an example of a user's priority list and its use.
  • Fig. 8F is a bitmap screenshot showing an example of a catalog screen for selecting movies.
  • Fig. 8A is a block diagram illustrating a user adding media to his or her priority hst.
  • Figs. 8B-E are bitmap screenshots showing an example of a user's priority list and its use.
  • Fig. 8F is a bit
  • FIG. 9 is a block diagram illustrating a user re-arranging his or her priority list.
  • Fig. 10 is a high-level block diagram illustrating a transfer of media to a chent from a media server or another chent (peer).
  • Fig. 11 is a block diagram illustrating the processing of a user request to purchase (or rent) a movie for viewing.
  • Fig. 12 is a block diagram illustrating the operations of the system in providing an authorization key to chent enabling the client to decrypt and play a movie.
  • Fig. 13 is a block diagram illustrating the secure chent boot process that is employed on a chent set-top box.
  • Fig. 14 is a block diagram illustrating the decryption and playback operations at a chent device in further detail.
  • Figs. 15A-D comprise a series of state diagrams illustrating interaction between the scheduler, a receiving client, and an originating donor/sender chent or server in transferring media files.
  • Fig. 1 is a very general block diagram of a computer system (e.g., an IBM- compatible system) in which software-implemented processes of the present invention may be embodied.
  • system 100 comprises a central processing unit(s) (CPU) or processor(s) 101 coupled to a random-access memory (RAM) 102, a read-only memory (ROM) 103, a keyboard 106, a printer 107, a pointing device 108, a display or video adapter 104 connected to a display device 105, a removable (mass) storage device 115 (e.g., floppy disk, CD-ROM, CD-R, CD-RW, DVD, or the like), a fixed (mass) storage device 116 (e.g., hard disk), a communication (COMM) port(s) or interface(s) 110, a modem 112, and a network interface card (NIC) or controller 111 (e.g., Ethernet).
  • CPU central processing unit
  • RAM random-access memory
  • ROM read-only memory
  • keyboard 106 e.g., a keyboard 106
  • printer 107 e.g., a printer 107
  • a pointing device 108
  • CPU 101 comprises a processor of the Intel Pentium family of microprocessors. However, any other suitable processor may be utilized for implementing the present invention.
  • the CPU 101 communicates with other components of the system via a bi-directional system bus (including any necessary input/output (I/O) controller circuitry and other "glue" logic).
  • the bus which includes address lines for addressing system memory, provides data transfer between and among the various components. Description of Pentium-class microprocessors and their instruction set, bus architecture, and control lines is available from Intel Corporation of Santa Clara, CA.
  • Random-access memory 102 serves as the working memory for the CPU 101.
  • RAM of sixty- four megabytes or more is employed. More or less memory may be used without departing from the scope of the present invention.
  • the read-only memory (ROM) 103 contains the basic input/output system code (BIOS) — a set of low-level routines in the ROM that application programs and the operating systems can use to interact with the hardware, including reading characters from the keyboard, outputting characters to printers, and so forth.
  • BIOS basic input/output system code
  • Mass storage devices 115, 116 provide persistent storage on fixed and removable media, such as magnetic, optical or magnetic-optical storage systems, flash memory, or any other available mass storage technology. The mass storage may be shared on a network, or it may be a dedicated mass storage. As shown in Fig.
  • fixed storage 116 stores a body of program and data for directing operation of the computer system, including an operating system, user apphcation programs, driver and other support files, as well as other data files of all sorts.
  • the fixed storage 116 serves as the main hard disk for the system.
  • program logic (including that which implements methodology of the present invention described below) is loaded from the removable storage 115 or fixed storage 116 into the main (RAM) memory 102, for execution by the CPU 101.
  • the system 100 accepts user input from a keyboard 106 and pointing device 108, as well as speech-based input from a voice recognition system (not shown).
  • the keyboard 106 permits selection of application programs, entry of keyboard-based input or data, and selection and manipulation of individual data objects displayed on the screen or display device 105.
  • the pointing device 108 such as a mouse, track ball, pen device, or the like, permits selection and manipulation of objects on the display device. In this manner, these input devices support manual user input for any process running on the system.
  • the computer system 100 displays text and/or graphic images and other data on the display device 105.
  • the video adapter 104 which is interposed between the display 105 and the system's bus, drives the display device 105.
  • the video adapter 104 which includes video memory accessible to the CPU 101, provides circuitry that converts pixel data stored in the video memory to a raster signal suitable for use by a cathode ray tube (CRT) raster or hquid crystal display (LCD) monitor.
  • CTR cathode ray tube
  • LCD hquid crystal display
  • a hard copy of the displayed information, or other information within the system 100, may be obtained from the printer 107, or other output device.
  • Printer 107 may include, for instance, an HP LaserJet printer (available from Hewlett Packard of Palo Alto, CA), for creating hard copy images of output of the system.
  • the system itself communicates with other devices (e.g., other computers) via the network interface card (NIC) 111 connected to a network (e.g., Ethernet network, Bluetooth wireless network, or the like), and/or modem 112 (e.g., 56K baud, ISDN, DSL, or cable modem), examples of which are available from 3Com of Santa Clara, CA.
  • the system 100 may also communicate with local occasionally-connected devices (e.g., serial cable-linked devices) via the communication (COMM) interface 110, which may include a RS-232 serial port, a Universal Serial Bus (USB) interface, or the like.
  • Communication communication
  • USB Universal Serial Bus
  • FIG. 2 is a block diagram of a software system for controlling the operation of the computer system 100. As shown, a computer software system 200 is provided for directing the operation of the computer system 100.
  • a computer software system 200 is provided for directing the operation of the computer system 100.
  • Software system 200 which is stored in system memory (RAM) 102 and on fixed storage (e.g., hard disk) 116, includes a kernel or operating system (OS) 210.
  • the OS 210 manages low-level aspects of computer operation, including managing execution of processes, memory allocation, file input and output (I/O), and device I/O.
  • One or more apphcation programs such as client application software or "programs" 201 (e.g., 201a, 201b, 201c, 201d) may be "loaded” (i.e., transferred from fixed storage 116 into memory 102) for execution by the system 100.
  • the applications or other software intended for use on the computer system 100 may also be stored as a set of downloadable computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., Web server).
  • Software system 200 includes a graphical user interface (GUI) 215, for receiving user commands and data in a graphical (e.g., "point-and-chck") fashion. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating system 210, and/or chent application module(s) 201.
  • the GUI 215 also serves to display the results of operation from the OS 210 and application ⁇ ) 201, whereupon the user may supply additional inputs or terminate the session.
  • OS 210 operates in conjunction with device drivers 220 (e.g., "Winsock” driver — Windows' implementation of a TCP/IP stack) and the system BIOS microcode 230 (i.e., ROM-based microcode), particularly when interfacing with peripheral devices.
  • OS 210 can be provided by a conventional operating system, such as Microsoft Windows 9x, Microsoft Windows NT, Microsoft Windows 2000, or Microsoft Windows XP, all available from Microsoft Corporation of Redmond, WA.
  • OS 210 can also be an alternative operating system, such as the previously mentioned operating systems.
  • the above-described computer hardware and software are presented for purposes of illustrating the basic underlying set-top, desktop, and server components that may be employed for implementing the present invention.
  • the present invention comprises a distributed media delivery system providing a . distributed methodology for distribution of media content (e.g., movies or other videos, music or other audio, and other media) via electronic means.
  • media content e.g., movies or other videos, music or other audio, and other media
  • the system and methodology of the present invention provides the ability to efficiently deliver digital media selected by a customer from a large catalog or library to the customer's playback device (e.g., set-top box).
  • a customer can select digital media from a large catalog offering a wide range of choices and watch it at the time of his or her choosing.
  • the delivery of the selected digital media to the consumer is performed in a manner that minimizes the total amount of electronic bandwidth and server infrastructure investment required by a supplier (e.g., content provider or service provider), while providing the supplier with the ability to dehver digital media files to its customers within a reasonable period of time.
  • the distributed media delivery system of the present invention combines the use of a client device (e.g., a set-top box or other playback device) in the customer's (user's) home or business, a home network (or LAN) having broadband access to the Internet, and server-side components for dehvery of digital media via the Internet using an efficient distributed methodology.
  • a client device e.g., a set-top box or other playback device
  • a home network or LAN
  • server-side components for dehvery of digital media via the Internet using an efficient distributed methodology.
  • the set-top box or other playback device in a customer's home (or business) provides capabilities for storage and playback of digital media (e.g., on a connected television monitor).
  • the set-top box or playback device is connected via a home network (or LAN) and a broadband connection to the Internet to facilitate electronic transmission of digital media to and from the device.
  • the server-side components of the distributed media delivery system include one or more server(s) providing access to a large catalog of digital media. Various security and encryption subsystems are also included for securing the digital media against unauthorized access.
  • Another component is a customer management subsystem which tracks customers and manages customer account information.
  • a scheduler determines how media should be sent to a customer, including how and from where it should be sent. From a customer point of view, once the customer subscribes to obtain digital media through the distributed media delivery system, he or she can select movies and other digital media from a wide range of available titles. The customer can also assign priorities to the selected media to create a prioritized list (or "priority hst") of media that he or she wishes to obtain.
  • the priority list represents a list of the media (e.g., movies) that the customer would like to receive in the future as soon as possible.
  • the list may be longer and require more storage capacity than the user's playback device or home network actually has.
  • the items on the list that cannot fit on the playback device represent the items in priority order that the user would like to see delivered in the future as room is made available on their STB. It also serves as a memory aid.
  • the priority hst plays the role of personal menu and playback is immediate.
  • the distributed media delivery system proceeds to download the content on the priority list to the customer's playback device (e.g., set- top box).
  • the system directs the content selected by the customer to be downloaded to the customer's set-top box via a broadband Internet connection to the customer's home network as hereinafter described.
  • the approach of the present invention is to deliver all media content in an encrypted format to ensure it is only used in an authorized fashion.
  • the media content that is distributed and stored by the distributed media delivery system is securely encrypted on the media servers and playback devices as well as during distribution via the Internet.
  • the transfer is also verified to guarantee that a correct and uncorrupted copy of the file is delivered.
  • a user actually wants to watch a movie on the priority list that has been delivered, he or she can simply hit a "play" button or similar control to initiate playback.
  • the customer management subsystem is queried to determine if the customer's account is in good standing and that other conditions are satisfied. If so, the system sends an authorization key to allow the media to be decrypted and played.
  • a customer generally does not have the effective abihty to access and use (i.e., play) the media until an authorization key is received.
  • the distributed media delivery system's scheduler monitors the priority lists of all customers and the media content actually present on customers' playback devices (set-top boxes).
  • the scheduler arranges for media content to be delivered to where it is needed either from the distributed media delivery system's servers (the original repository for storing media content) or from another customer that has a copy of the desired media content.
  • the scheduler determines which movies (or other content) should be dehvered to each customer and then decides the manner in which the content should be supplied.
  • the supplier's resource burden is reduced as customer nodes are used to send media files among themselves.
  • P2P peer-to-peer
  • the system makes the appropriate arrangements for delivering copies of the media on the customer's priority hst, with copies delivered either from a peer or from the central repository as determined by the system's scheduler.
  • the distributed media dehvery system of the present invention allows for the delivery of digital media files, via a digital network (wired and/or wireless) using a distributed file system that minimizes centralized server resources and maximizes the use of "peer nodes" (i.e., the customer playback devices).
  • peer nodes i.e., the customer playback devices.
  • the distribution of media files is centrally controlled by the distributed media delivery system's scheduler and presents the available items of media content to customers as a consistent catalog of available titles.
  • peer nodes typically comprise set-top boxes, although in some cases a peer node may be a file server (e.g., personal computer or Network Attached Storage (NAS)) located on a customer's home network.
  • the distributed media delivery system of the present invention is differentiated fromP2P systems in the way that the users of the service are presented with a single instance catalog of all available titles, and that when a title is selected the file distribution methodology of the system delivers the requested file from the best available resource within what is effectively its own virtual private network.
  • distribution of media files can also be optimized by the system's scheduler on a system-wide basis. Also, the system verifies that the files are correct copies and not corrupted in any way to avoid viruses and other system interruptions. In contrast, prior P2P systems require users to search for items of interest on an ever changing network of nodes and therefore do not provide users with a consistent "catalog" from which to choose.
  • the advantages of the present invention include that the total cost of running the distributed media delivery system is low since bandwidth and storage costs are shared with customers. In particular, the number of servers required is low compared to Internet downloading methods, cable or Internet server VOD, involving dehvery of copies or streaming from a central set of servers.
  • prior art systems for delivery of videos have generally provided only a limited number of titles to consumers (e.g., a limited number of broadcast or cable television channels or a limited selection of videos on demand) in large part because of bandwidth limitations.
  • consumers e.g., a limited number of broadcast or cable television channels or a limited selection of videos on demand
  • bandwidth limitations e.g., bandwidth limitations
  • the prior art approach providing for serving all media files from a centralized system is still disadvantageous as it would require a tremendous number of servers and supporting infrastructure to serve all of this media to customers.
  • the approach of the present invention in contrast, spreads a considerable portion of this burden across a large distributed network of customers, by shifting most of the burden of media dehvery away from servers and onto peer-to-peer connected consumer devices.
  • a priority hst also ensures that customers should always have a number of movies available for playback.
  • the act of choosing a movie (or list of movies) is separated from the viewing (playback) process.
  • the higher priority items on the priority hst will be available locally (i.e., already stored on the local playback device or home network).
  • the items that are in process of being dehvered will typically be those of lower priority towards the end of the priority hst. This enables the customer to watch the top priority movies on the priority hst at his or her convenience, without having to wait for delivery.
  • the present invention provides a reliable system dehvering high-quality content to customers.
  • Media e.g., movie
  • playback of high fidelity movies from a hard disk today, provides a much better viewing experience to customers than Internet streaming approaches.
  • the distributed media dehvery system is reliable because it is structured with built-in redundancy: copies of media files are available from a large number of peer nodes rather than one centralized repository.
  • the peer nodes are typically configured to be dedicated to the system and therefore provide a fault-resistant infrastructure that is available on a 24 hours per day, 7 days per week basis.
  • the priority hst behaves like a personal VOD menu, as a subset of the entire catalog. This makes playback selection much easier and manageable. It also serves as a memory aid to assist in recalling media that the user had once expressed a desire to view.
  • the distributed media delivery system of the present invention is useful both in h ited bandwidth scenarios and in situations where there is substantial available bandwidth. When there is limited bandwidth, the system provides for download and then playback of media files.
  • Fig. 3A is a very general block diagram of the distributed media delivery system 300 of the present invention. As shown at Fig.
  • the components of the distributed media delivery system 300 include a key vault/media pass (server) 310, a scheduler (server) 320, one or more customer management (server(s)) 330, one or more media server(s) 340, a media import module 350, one or more set-top box (STB) client(s) 370, and (optionally) one or more browser(s) 390.
  • a key vault/media pass server
  • server scheduler
  • customer management server(s)
  • media server(s) 330 the components of the distributed media delivery system 300
  • media import module 350 a media import module 350
  • STB client(s) 370 the components of the distributed media delivery system 300
  • STB set-top box
  • the components of the distributed media delivery system 300 communicate with each other through one or more network(s), which may include communications via one or more wide area networks (e.g., the Internet) and/or one or more local area networks (e.g., a home network or other LAN).
  • network(s) may include communications via one or more wide area networks (e.g., the Internet) and/or one or more local area networks (e.g., a home network or other LAN).
  • communications between system components are encrypted and components are authenticated before communications are exchanged.
  • the set-top box (STB) clients 370 are typically located in user (customer) home or business locations and provide media decryption and playback to users.
  • Fig. 3B is a high level block diagram illustrating a preferred set-top box "chent" 370 (i.e., STB deployment environment) in further detail.
  • the set-top box chent 370 may be deployed in an environment that includes a set-top box 375 connected to a television 378 and a home network 376.
  • the set-top box 375 is connected via the home network 376 to a router/hub (switch bridge)
  • the set-top box 375 comprises a set-top box (STB) or other playback device having a hard disk (or other permanent electronic storage such as flash memory) for storing and playing copies of media files locally at a user's home (or office).
  • STB set-top box
  • the set-top box 375 preferably includes a hard disk of 40 gigabytes or more for storing media files.
  • the set-top box 375 may or may not have storage built into it, and has access via a LAN or USB or similar high speed local connectivity (e.g., home network 376) to a storage device (e.g., home computer 374) that can feed the playback device (i.e., set-top box 375) fast enough to provide a high quality video playback.
  • a storage device e.g., home computer
  • the set-top box 375 may serve one or more playback devices connected through the home network 376 in a home or business.
  • the set-top box 375 may comprise a general purpose computer running the appropriate software.
  • the set-top box 375 is connected directly to a television or other display device 378 for rendering media as shown at Fig. 3B.
  • the set-top box 375 also includes network connections for connection to a home network 376 (e.g., HomePlug, HPNA, Ethernet, Wireless, etc.).
  • the home network 376 typically provides connectivity via a router/hub 373 (or switch/bridge) and a modem 372 (e.g., DSL, satellite, or cable modem) to the Internet via a broadband connection 371.
  • the set-top box 375 communicates through these networking components to communicate via the Internet with other components of the distributed media dehvery system 300 to obtain the authorization (decryption) key necessary to decrypt and play the video on the user's television or display device.
  • the set-top box 375 is also responsible for presenting a user interface to the user which enables the user to perform various actions including: a) searching/browsing the user's priority list of video files; b) searching/browsing the media catalog; c) selecting new media to be added to the user's priority hst and re-ordering the priority list; d) removing media from the priority hst; e) selecting media (e.g., video) from the priority list for playback; and f) system setup and maintenance.
  • the user interface typically includes a display for presenting information to the user (e.g., on-screen on a television or other display device 378) as well as an input device (e.g., remote control, mouse, keyboard, or the like not separately shown at Fig. 3B) for the user to make selections.
  • the information stored by the set-top box 375 includes current chent status, catalog of media meta data, current media transfers, status of chent media (including priority rank, decryption keys, etc.), and encrypted media available on the chent (e.g., video media).
  • the set-top box 375 also runs software that communicates via the home network and other components of the client 370 with the scheduler 320 and other components of the distributed media delivery system as hereinafter described (e.g., for obtaining an authorization key to decrypt and play media available locally).
  • Fig. 3C is a high-level block diagram illustrating the set-top box device 375 of Fig. 3B in more detail. As shown, the set-top box device 375 includes a case 380 containing a power supply 392, a hard disk drive 395, and a main board (motherboard) 385.
  • the motherboard 385 houses a CPU 386, a random access memory (RAM) 387, a front panel 388, a boot ROM (read only memory) 89, an IDE interface 390, and a power line network interface 391 which are connected via a system bus 396.
  • Other components of the set-top box 375 include a video out line 381 and an audio out hne 382 connected to the CPU 386, an AC power line 393 connected to the power supply 392, and an infrared (IR) receiver 384 and LED status indicators 383 connected to the front panel 388.
  • IR infrared
  • the case 380 houses the other components of the set-top box 375 and includes connections providing for connectivity to external devices such as a television, home stereo, and a power outlet (not shown at Fig. 3C). External connectivity is provided via a video out hne 381 for connection to an external display device (e.g., a television), an audio out hne 382 for connection to an external audio device (e.g., a television or home stereo), and an AC power hne 393 for connecting the set-top box 375 to an AC wall jack and into a home network via the powerline network interface 391. Also mounted on the case 380 is an IR receiver 384 for receiving input from an external remote control or similar device (not shown at Fig.
  • the set-top box LED status indicators 383 include one LED status indicator for indicating network connectivity and another for indicating whether the power is on.
  • the IR receiver 384 operates in conjunction with an external remote control or similar device to enable the user to issue commands to the set-top box (e.g., to request playback of a movie).
  • a conventional consumer electronic remote control device having an infrared transmitter may be used for these530poses.
  • the motherboard 385 is based on a Starfish board available from Equator Technologies, Inc. of Campbell, California. A primary component of the motherboard 385 is the CPU 386.
  • the CPU comprises an Equator BSP-15 processor, which is a programmable system-on-a-chip (SoC) processor designed for video and signal processing applications.
  • the Equator BSP-15 processor includes host processor functionalities with media processing capabilities, SDRAM and PCI interfaces, a DES engine, and a multimedia I O system.
  • the on-chip hardware DES engine provides DES and 3DES encryption or decryption. As described below, the integration of DES processing with video processing allows one-chip handhng of protected content, without clear-text streams passing chip-to-chip.
  • the Equator BSP-15 produces S-Video, composite video (CVBS), and component analog video output (e.g., for output via the video out line 381). It also produces a stereo analog audio output and digital audio output (e.g.
  • the motherboard 385 includes the boot ROM (read only memory) 390 comprising NOR flash memory. Also included is system RAM (random access memory) 387 providing working memory for the system. Additional components on the motherboard 385 include a front panel 388 and an IDE interface 390.
  • the front panel 388 comprises interface electronics which provide for communication with the LED status indicators 383 and infrared (IR) receiver 384.
  • the IDE interface provides for PCI to IDE connectivity to the hard disk drive (HDD) 395.
  • the Starfish board includes a Realtek RTL 8100 Ethernet interface, which is a standard Ethernet adapter.
  • this interface is modified to provide for a powerline network interface 391 which provides for connectivity to a home network through the power supply 392 and AC power line 393.
  • the powerline network interface 391 is implemented using an InteUon INT5130 chip set (or alternatively an InteUon INT51X1 chip set) available from InteUon Corporation of Ocala, Florida.
  • the power supply 392 is a standard power supply that is modified by creating taps (e.g., using an analog module inside the power supply) off the power that is coming in from the external power source for connecting to the motherboard through the powerline network interface 391.
  • the powerline network interface 391 then converts the signal in standard format for communication with the CPU 386 via the bus 396.
  • the RTL 8100 Ethernet adapter supplied as part of the Starfish board may present an Ethernet interface at the back of the set-top box 375 which may then be connected to an external powerline network component (e.g., aNetgear waU-plugged Ethernet bridge model XE102) for connecting into a home network via a powerline.
  • the hard disk drive 395 comprises a conventional hard disk drive for storage of encrypted media files and other information.
  • a hard disk drive with a capacity of at least 40 gigabytes or more is employed.
  • Hard disk drives suitable for use in conjunction with the present invention are available from a number of vendors, including Western Digital of Lake Forest, California and Seagate of Scotts VaUey, California.
  • the set-top box 375 in its presently preferred embodiment, runs the Linux operating system (available from several vendors) and apphcation software (not separately shown at Fig. 3C).
  • These software components include modules for display of a user interface to the user (e.g., on screen on the television) for setting priority lists, playing movies, and performing other such functions.
  • software modules are included for communication with the scheduler and other server and peer components to implement the methodology of the present invention as described below.
  • the media server(s) 340 are the suppliers of items of media content, in encrypted format, to the client(s).
  • the media server(s) 340 store encrypted video media; the scheduler stores the meta data for that media.
  • Media servers are similar to chents when considering file transfer. The main difference is that a media server is not intended to playback media and it is expected to be able to serve many more nodes than a chent would normally be expected to serve. Any node can deliver to any other node. In that regard, servers and chents are similar. This is useful for provisioning files to multiple servers.
  • the media server(s) receive media content when items are initially uploaded into the distributed media delivery system 300 through the media import module 350 (prior to any clients receiving the media content via the system).
  • the media server(s) 340 comprise at least one file server storing at least one copy of each media file that is made available through the system.
  • the media server(s) 340 are standard servers (e.g., Linux-based servers) running software for communication with STB client(s) 370 or other media servers and taking direction from the scheduler 320.
  • the media server(s)340 typically have a large storage capacity and a broadband connection to the Internet (e.g., a T3 connection).
  • Those skilled in the art wiU appreciate that the media server(s) may be implemented in a number of different ways.
  • the media server(s) 340 may be implemented as a single server with a massive array of hard disk drives (e.g., a RAID configuration).
  • An alternative implementation may include clusters of servers sharing a SAN (Storage Area Network) of massive disk storage.
  • the presently preferred embodiment includes several distributed clusters of media servers, each with a SAN (or equivalent massive hard disk capacity).
  • each cluster of media servers is located in a different physical network operations center in a different geographic location.
  • each cluster of media servers 340 stores a subset of all of the media files represented in the distributed media delivery system 300 such that a subset (m of n) of the total servers has at least one copy of each file among them.
  • the system may have a total of 5 media server clusters 340 with files distributed to each cluster such that any 3 of the 5 server clusters would provide a superset of the entire media file database (i.e., the entire set of media files).
  • This configuration provides for system-wide redundancy and uptime reliability yet reduces overall storage requirements.
  • the customer management (server(s)) 330 (CMS) handles customer interaction including initial sign-up, account management, media list management, and playback authorization.
  • the customer management server(s) 330 stores customer account information.
  • the customer management server(s) 330 is currently implemented as a Web server (e.g., an Apache web server) that dynamically creates the Web pages necessary for interaction with users (e.g., via a Web browser and/or the user interface presented by the client).
  • the customer management server(s) 330 currently includes the foUowing functions: a) new account creation, including signup by supplying name, address, credit card, and so forth; b) account management; c) display of media file database information; d) selection of media files to be added to a user's priority list; e) re-ordering of priority lists; and f) authorization of media playback.
  • Users may interact with the customer management server(s) either through the STB chents 370 or through Web browsers 390 (i.e., without using the STB clients 370).
  • a user is not required to use the set- top box to decide what selections are to be added to bis or her priority hst and so forth, and can instead interact with the customer management server(s) 330 from a different location through the Internet (e.g., using a Web browser from a home or business PC connected to the Internet).
  • the customer management server(s) 330 also keeps track of how many playback devices individual users have associated with their accounts as weU as information regarding the supplier of each playback device (STB).
  • each given server may be controUed by or hcensed to a particular entity (e.g., specific motion picture studio).
  • the scheduler can communicate with and support multiple customer management servers, each having their own URL and catalog(s).
  • the user interface on the client set-top boxes is also enhanced to include an additional screen/page to display the priority hst for a particular customer management server or catalog. This is an important capability because it aUows multiple content vendors to operate independently of each other, yet take advantage of the system's dehvery and authorization playback infrastructure.
  • the customer management module also operates in conjunction with a media file database (not separately shown at Fig.
  • the media file database is embodied using the MySQL open source database (available from MySQL AB of Uppsala, Sweden).
  • MySQL open source database available from MySQL AB of Uppsala, Sweden
  • other databases or file systems e.g., from Oracle, Sybase, IBM, and Microsoft
  • the available information is entered into the media file database. This information is used by the customer management server 330 to populate dynamically rendered Web pages when a user visits the online catalog.
  • Customers may search/browse the media catalog maintained by the customer management module using either a Web browser 390 connected to the Internet or using the user interface of the client (i.e., the chent STB 370). While browsing, a customer may select and add media files from the catalog of available titles to his or her priority hst. The customer may also assign priorities to the files on the list. For example, the customer may select a total of 20 media files and rank them in order from " 1 " (being the highest priority) to 20 (being the lowest priority). The customer may also re-order the priority of files on the priority list from time to time, as desired. The priority hst is used by the scheduler 320 to determine the order of content dehvery to the chent.
  • the priority list forms a convenient, custom menu for the user to select a video (or other media) to play.
  • an indication is provided as to whether titles on the priority list are avaUable on the STB chent 370 (i.e., have been dehvered).
  • the list and catalog may also indicate that files are immediately playable.
  • the information about media files in the media file database associated with the customer management server 330 is also used to populate a database of the same information that is copied to the STB chent(s) 370. These chent databases are usually updated shortly after the media file database is updated.
  • the media file database is replicated to the STB chent(s) 370 for the local playback environment in order to reduce server load, reduce bandwidth needed to communicate to the database server, and improve user interface performance at the client(s).
  • the database information can be distributed to the STB chent(s) 370 either item by item via the scheduler 320 through messages to the client, or in bulk through the use of the same mechanism the distributed media delivery system 300 uses to distribute the media content itself.
  • the scheduler 320 communicates with other components to perform functions relating to scheduling the actual delivery of media to client(s).
  • the scheduler 320 maintains media meta data, information regarding decrypt keys provided to STB clients 370, system-wide transfer information, information about STB clients 370, and each client's media status.
  • the scheduler 320 includes a module for communications with each client and also maintains a scheduling database (not separately shown at Fig. 3A) with entries for each STB client 370.
  • the scheduling database is embodied using the MySQL open source database (available from MySQL AB of Uppsala, Sweden).
  • MySQL open source database available from MySQL AB of Uppsala, Sweden.
  • other databases or file systems e.g., from Oracle, Sybase, IBM, and Microsoft may also be used for implementing the scheduling database of the present invention, as desired.
  • the scheduler 320 tracks each media file that is present on each STB chent 370 and stores related provisioning information.
  • the scheduler 320 provides services for the STB client(s) 370 and also controls many of the functions of the set-top boxes of the STB chents 370. The operations of the scheduler in scheduling dehvery of media files is described in more detail below.
  • Key vault/media pass servers Another component of the distributed media delivery system is the key vault/media pass server(s) ("key server(s)") 310 which is responsible for providing authorization keys to STB chents(s) 370 to enable decryption and playback of media files.
  • the information maintained by the key server(s) 310 includes media decryption keys and media passes.
  • the key server(s) 310 are currently implemented as a pair of servers using SecureMedia's Encryptonite product (available from SecureMedia of Natick, MA).
  • the Encryptonite product uses an encryption scheme based on the Diffie-Hellman cryptographic mathematics algorithm; however, those skilled in the art will appreciate that a number of other encryption algorithms may be employed for encrypting the media files.
  • obtaining access to the files involves two layers or sets of operations.
  • a client desiring access to media must gain permission to obtain a key which enables decryption and playback of a media file.
  • various business rules are evaluated by the system's customer management server(s) 330 to determine whether the STB client 370 that is requesting access should be provided with the requested access. When permission is granted, the STB client 370 is issued what is called a "media pass".
  • the STB chent 370 initiates the second set of operations by requesting the decrypt/playback key from the key vault/media pass server(s) 310 and providing a copy of the media pass.
  • the key server(s) 310 provides the actual key which enables the client to decrypt and play the media file.
  • the operations of the scheduler 320 in delivery of media to clients will next be described in greater detaU.
  • the scheduler is responsible for determining which chents should receive media and how and when it should be dehvered.
  • the scheduler refers to a user's priority hst to determine which files need to be delivered to the user.
  • the scheduler also consults the above-described scheduling database to determine where copies of the needed media files are located.
  • the scheduler will select how the media file should be delivered to a particular client (STB) based on several factors, including the availability of the needed file on other chents in the network.
  • STB client
  • the scheduler will, whenever possible, direct a client to fetch its next needed media file from another client.
  • the scheduler can be set to prioritize delivery from these sources instead.
  • the scheduler of the present invention performs these tasks in an intelligent, automated fashion.
  • the scheduler In making scheduling decisions, the scheduler also considers the measured performance of the communications between and among the media servers and the chents. This information is kept up to date (e.g., in the scheduling database associated with the scheduler) so as to provide near-real-time information concerning latency and throughput of data from the media servers to the chents and vice versa. In addition, as clients transfer files among themselves, the latency and throughput information is captured and communicated back to the scheduler from time to time by each client. In addition, the scheduler performs an analysis of the priority lists of existing users, as weU as the scheduling database of files that have already been delivered to each user's client device, to determine which files are hkely to be most needed.
  • the scheduler can also use this information to assure that there wUl be at least one copy of each file among the chent STBs in the network of users. This can be done at the initial setup (e.g., before the chent device is supplied to the user) or later after the chent has been setup and connected to the network by the user.
  • a standard disk image or possibly several different ones, can be used to initialize chent hard discs as they are being manufactured.
  • disk images can be updated from time to time based on the scheduler's analysis of most hkely needed media files (e.g., the movies most hkely to be selected by new users) by inspection of all users' current priority lists and knowledge of soon to be release new media items. Then, at final initialization before delivery of the chent STB to the customer or after initial setup of the chent, only the files that do not match the predicted set need to be replaced. In effect, there are two priority lists maintained by the scheduler for each user. The first is the visible list that is shown to the user as being the files available on their STB and immediately ready for playback.
  • the second is a "shadow priority list" which is a list created by the scheduler for its benefit for the following purposes: a) to ensure that every file stored on the media server(s) has been copied onto at least one STB in the user network; b) to make available additional copies predicted by the scheduler to be needed to perform peer to peer (chent to client) file deliveries; and c) to pre-deliver the files that are currently on a user's priority hst but have not yet been delivered so that they will perceive a high quality of delivery service (i.e., the user perceives that new files arrive quickly).
  • the scheduler could arrange for delivery of 30 items that would display as "delivered” in the priority list and leave room for 10 more items that would only display as "delivered” in the event that one of the items was on the extended user priority list and the user had discarded one of the initial 30 items.
  • This shadow hst provides the system operator caching space to make sure that adequate copies of media items are available throughout the network.
  • the scheduler can direct the dehvery of files that are hkely to be of interest to that user.
  • the scheduler is also capable of initiating transfers, in either direction between clients, where one of the clients cannot initiate the communication with the other. In that event, the client that can initiate communication contacts the other client. Once the connection has been made, a file transfer can take place in either direction.
  • the scheduler specifies to the chents which one shall initiate the communication and which client will transfer the file to the other chent. Also, in the event that there is asymmetric network bandwidth between clients, the scheduler may instruct more than one chent, up to the maximum receiving bandwidth of the receiving client, to transfer media to the receiver.
  • the scheduler dynamically determines the amount and what portion of a file should be transferred from the sending client (or server) to the receiving client and keeps track of what portions of the file have been transferred. It can use this technique to effectively "create" bandwidth. Once a portion of a file, however smaU, has been transferred from one client to another, that portion immediately becomes available for transfer to yet another client. With each new client that receives the small file portion, its outbound bandwidth to other STBs in the network becomes available for sending that file to other chents in the user network.
  • This approach significantly reduces the needed centralized server capacity in terms of network communications and outbound bandwidth, in exchange for some latency of the time for delivery of the file (based on the number of users plus the time it takes to dehver the file and to setup the dehvery process).
  • This approach allows a system operator to dehver a single file to every user node inexpensively yet within a reasonable dehvery period. Also it should be noted that as bandwidth between peer nodes increases, the network delivery time decreases.
  • the foUowing description presents method steps that may be implemented using computer- executable instructions, for directing operation of a device under processor control.
  • the computer-executable instructions may be stored on a computer-readable medium, such as CD, DVD, flash memory, or the like.
  • the computer-executable instructions may also be stored as a set of downloadable computer-executable instructions, for example, for downloading and instaUation from an Internet location (e.g., Web server).
  • Fig. 4 is a block diagram illustrating the process for a new user (i.e., new customer) to subscribe to a service for obtaining media content through the distributed media delivery system.
  • the user may subscribe by purchasing a chent device and subscription at a retah store or by signing up directly with the supplier through the Internet.
  • the user may visit a suppher (e.g., ALIO TV) Web site using a Web browser to subscribe to the service.
  • a suppher e.g., ALIO TV
  • a user creates a new account by choosing a user ID and password and entering other personal information (e.g., credit card payment information).
  • the user is supphed with an authorization code.
  • the user may select one or more catalogs and create a media hst (or priority list).
  • one catalog may include movies from a particular movie studio, whUe another catalog covers movies from a particular country (e.g., movies from China or India).
  • the user may also create an initial priority list of media content (e.g., videos) that he or she would hke to view.
  • a user may create a priority list by searching or browsing one or more catalogs (e.g., a movie catalog) avaUable via the Web site customer management system interface.
  • the catalog(s) and Web interface is implemented as a database driven, hence dynamically created, set of Web pages, driven from the information in the media file database (as described above).
  • the customer management Web server is implemented using an Apache web server available from The Apache Software Foundation. Information about each movie is available to search, browse, sort, and view.
  • the information that is searchable includes, for instance, titles, year introduced, actors, directors, producers, genre, and so forth.
  • a user can select a list of media items and assign priorities to each media item in order to express the preferred order in which the user would like the media files to be dehvered and made available for his or her viewing.
  • the user information is sent to the distributed media delivery system's scheduler.
  • the system's scheduler will use this priority list to "fill up" the user's available storage (i.e., the storage available on the client device assigned to the user).
  • a chent device e.g., set-top box or other playback device
  • a user purchasing a set-top box at a retail outlet may perform the above steps to subscribe to receive media content after purchasing the set-top box at a retail store (or even during the purchase process at the retailer).
  • a user purchasing the chent device (STB) through the supplier Web site will obviously not yet have the client device. If the user is purchasing the chent device through the supplier Web site, when the user has completed the sign up process, the user record is flagged to indicate that a set-top box needs to be prepared and sent to the user.
  • Fig. 5 is a block diagram iUustrating the process for preparing a chent device for delivery to anew chent (i.e., new user).
  • a new chent message with a customer ID is received by the scheduler at (1) at Fig. 5.
  • the scheduler attaches (i.e., assigns) a chent device to the customer and replies with a confirmation message to the chent at (2) at Fig. 5.
  • the chent device STB
  • STB the chent device
  • the scheduler sends the customer's initial media list (i.e., priority list) to the client device as shown at (3) at Fig. 5.
  • the selected media files are copied from the media server(s) to the chent device's hard disk as depicted at (4) at Fig. 5 prior to shipment of the chent device to the customer.
  • the distributed media delivery system usually copies as many of the media files on the customer's priority list as can be instaUed on the chent device before the device is shipped so that the user will aheady have these initial files when he or she receives the client device. For example, if the client device includes an 80 GB hard disk, 30 or more media files on the user's priority list may be copied to the hard disk before the set-top box is shipped to the user.
  • the scheduler will determine a "best guess" list for that user and copy those files to the client device. This enables the user to start viewing the files immediately upon installation. This is also another way in which bandwidth into the user network is conserved by the system and methodology of the present invention.
  • Another alternative possibility is a case where the user purchases a new client device (STB) from a retail outlet (e.g., Best Buy).
  • STB client device
  • the set-top box wUl be connected to the retailer's LAN and the media files wiU be transferred from a caching server located at the store. Where that is not possible, the user will take the STB home and the file transfer of then- selected files will take place later.
  • the client device already may be pre-loaded with media files selected by the scheduler during the manufacturing process.
  • the client device When the user receives the client device (STB), he or she connects the device to a television or display device and an electrical socket.
  • the STB is also connected to a home network of some sort.
  • “HomePlug” networking is recommended for incorporation of the chent device into the home network.
  • “HomePlug” is a networking technology that modulates the network signals on the home electrical wiring.
  • HomePlug products suitable for use in connection with the present invention include NetGear XE102 WaU-Plugged Ethernet Bridge, NetGear Model XA601 Powerhne USB Adapter, and NetGear Model XA602 Powerhne Ethernet Adapter (avaUable from NetGear of Santa Clara, Cahfornia.).
  • Other suitable HomePlug providers include Linksys Group, Inc., Belkin Corporation, Siemens, and ST&T Instrument Corporation.
  • the HomePlug technology is built into the client device so that when the user plugs it into the wall socket to receive electricity, the chent device is also connected to the local network.
  • the user also has a broadband networking connection to the Internet, such as a routing device and a HomePlug bridge from the router.
  • the client device may also be directly connected to a DSL modem, a Cable modem, or the like for connecting to the Internet.
  • the chent device may be connected using other networking technologies including, but not limited to, HPNA, wireless (e.g., IEEE 802.11), wireline (e.g., CAT-5 cable), and the like.
  • Fig. 6 is a block diagram depicting the activation of a new chent device after the user receives and installs the client device.
  • the user enters the authorization code received during sign-up as shown at (1) at Fig. 6.
  • the authorization code is then sent to the scheduler as illustrated at (2) at Fig. 6. If the authorization code received by the scheduler is correct, the scheduler provides the chent with a registration number which is used for secure communications as shown at (3) at Fig. 6.
  • this process ensures that the client device was received by the authorized user (i.e., the person that subscribed) before access to the network/community is provided.
  • communications between and among client and server components are encrypted (e.g., using SSL) and are on an authorized basis.
  • FIG. 7 is a block diagram illustrating the importation of new items of media content into the distributed media delivery system.
  • new media is imported into the system and encrypted by the media import module.
  • the encryption system used in the currently preferred embodiment provides for frame-by- frame encryption of media content using SecureMedia's Indexed encryption method.
  • the encrypted media is sent to the media server(s) as depicted at (2) at Fig. 7.
  • the key for decryption of the media file is also sent to the key vault as provided at (3) at Fig. 7. It should be noted that from this point until the media is decrypted for playback by a specific customer at a chent device, all copies of the media stored and transferred by the distributed media delivery system are encrypted.
  • Unencrypted copies of the media are generally not stored anywhere on the system.
  • the process for providing keys to users for decryption and playback of media files is described below.
  • the media import module also provides meta data (e.g., category, genre, title, copyright, content owner, language, and so forth) regarding newly imported media files to the scheduler as shown at (4) at Fig. 7. Users that have subscribed to the particular catalog(s) including the newly imported file are then passed the new meta data for local storage on the client device as illustrated at (5) at Fig. 7. This enables users to see on their set-top boxes that new titles are available for download and playback.
  • Fig. 8A is a block diagram Ulustrating a user adding media to his or her priority hst.
  • a particular catalog may, for example, contain more than 15,000 titles.
  • the priority list serves as a custom list, in priority, of those titles that the user may be interested in viewing.
  • a user may currently request additional media files for viewing by adding items to his or her priority list in one of two ways.
  • a user may add items to his or her priority hst either by using the client device or by using a Web browser connected via the Internet to the distributed media delivery system's customer management module. Both of these wiU now be described.
  • the client device typically stores a copy of the catalog(s) to which the user has subscribed or the client otherwise has access to these catalog(s) (e.g., via a network connection).
  • the user may browse the catalog and select items to add to his or her priority hst at the chent device as provided at (1A) at Fig. 8A.
  • the chent informs the scheduler of the new priority hst as Ulustrated at (2A) at Fig. 8A.
  • the scheduler uses this information in determining which media files are to be delivered to the client.
  • a user may add items of media content to his or her priority hst through the customer management module using a Web browser (e.g., from a computer at his or her home or office which is connected to the Internet).
  • a user may log on to the customer management Web server as provided at (IB) at Fig. 8 A with his or her customer ID and password.
  • the customer management module After the user logs on, the customer management module consults the scheduler for the user's existing priority hst as shown at (2B) at Fig. 8A. After the user adds items to his or her priority list, the customer management module informs the scheduler of the new priority list rankings as depicted at (3B). The scheduler then updates the media rankings in the user's priority list and informs the client of the updated rankings (i.e., priority hst) as provided at (4B) at Fig. 8A.
  • Fig. 8B is a bitmap screenshot showing an example of a user's priority hst. "My List" screen 800 represents an individual user's priority hst.
  • the user has specified the movie "Duck and Cover” (shown at 801) as the user's #1 priority (indicated at 803). This is followed on the list by the user's priority ranking of other movies, such as "A is for Atom” as #2 priority, "Pork People Like” as #3 priority, and so forth and so on.
  • a first set of status icons or glyphs 805 indicate whether a given movie is downloaded or not.
  • a movie that is "downloaded” is one in which an encrypted copy of the movie then resides on the user's local system (e.g., resides on the user's STB hard disk).
  • the user's priority items #l-#8 have been downloaded and now reside locally in encrypted form.
  • the "viewable” icon is a pie-shaped icon indicating that a given movie is still viewable (i.e., for some subset of time remaining for the ordered movie, such as time remaining in a 24 hour viewing period). Over time, the "viewable” icon is gradually updated to indicate less and less time available for the movie to be viewed, until finally the movie is no longer available for viewing. Once the movie is no longer viewable, the user must obtain reauthorization should he or she wish to watch the movie again. As shown in Fig. 8D, the "My List" screen (now 800b) also includes feedback to indicate the current download status of a given movie.
  • the system has now initiated downloading of the movie "Stay Safe.”
  • the screen 800b displays a "downloading" icon 809 in the form of a partially fiUed circle. As more and more of the movie is downloaded, the icon progressively fills. After downloading is complete, the icon 809 becomes a full circle. In this example, the movie “Bork Cooking” has no circle whatsoever, thus indicating that downloading has yet to commence for it.
  • the "My List" screen (now 800c) also includes a selection cursor 811 for selecting different items, and a status hne 813 for showing status information for a given selected item.
  • Fig. 8F shows a simple example of a catalog screen 850.
  • the catalog screen 850 includes an alphabetical listing 851 of aU of the movies available on the system.
  • a more complex listing of movies may include filtering, such as via genre (e.g., drama, comedies, action, etc.).
  • the catalog screen 850 includes icons or glyphs 853 for indicating the download status of the various movies shown on the hst. Additionally, the catalog screen 850 also includes priority information 855 for indicating what ranking (if any) each displayed movie has (relative to the user's own priority list). For example, the movie "A is for Atom” is indeed the #2 priority item in the user's priority list. Conversely, the movie “Animal House” does not get a priority ranking and is not downloaded, because of the user has not placed it on his or her priority list. Similarly, the user can rearrange the priority list from either the chent device or through the customer management Web server. Fig.
  • FIG. 9 is a block diagram illustrating a user rearranging bis or her priority list.
  • a user may alter the media rankings provided in his or her priority hst at the chent device as provided at (1A) at Fig. 9.
  • the customer may wish to alter the priority hst in order to obtain earlier access to particular items given that the scheduler uses the priorities assigned by the user to each item when deciding what files should be downloaded to the user's set-top box.
  • the client informs the scheduler of the new rankings as depicted at (2A).
  • the user may also log in to the customer management Web server with his or her LD and password as provided at (IB) at Fig. 9.
  • the scheduler is consulted for the user's priority list at (2B) and the altered media rankings entered by the customer are provided to the scheduler as illustrated at (3B) at Fig. 9.
  • the scheduler updates the priority hst and transfers the updated priority list to the client as provided at (4B) at Fig. 9.
  • the act of adding new items to the priority list from the catalog may be considered an alternative to rearranging the list.
  • the user has the option of adding new items to the end of the list or he or she can insert them before existing items on the list. For example, a user can browse the catalog and decide to make a new item the user's highest priority item. Fig.
  • FIG. 10 is a high-level block diagram illustrating a transfer of media to a client from a media server or another chent (peer).
  • the distributed media delivery system's scheduler knows the priority lists of all users and also knows what media files are installed on each of the media servers and the clients.
  • the scheduler also has information about items that are currently in process of being transferred between (and among) clients and servers. On the basis of this information, the scheduler determines the media file(s) that should be dehvered to a given chent as well as when and from where each file should be transferred.
  • the scheduler considers are the following: which client needs the file the most (e.g., which chent is the one least-most recently served by a download), what chent(s) and/or server(s) have a copy of the file that needs to be sent, and who should send the file (e.g., the device least-most recently originating and sending information).
  • Other factors that may be considered include the network on which the chents (peers) and/or servers that are to send and receive the file are located as weU as the geographic location of the recipient and the proposed sender as weU as measured network latency and throughput. These factors, among others, may influence the selection of the most appropriate channel for dehvery of media to a particular chent.
  • the scheduler also manages the transfer process.
  • the scheduler initiates the transfer of the media file from a media server or client (peer) by informing both the sending and receiving parties of the transfer as shown at (1) at Fig. 10.
  • peer media server or client
  • the scheduler may also instruct the parties about what portion of a particular file is to be sent at a given time. After receiving notice from the scheduler, the two systems both acknowledge that the transfer is about to start at (2) and then issue a progress message back to the scheduler as illustrated at (3) at Fig.
  • the server and/or peers transfer encrypted media to the client as provided at (4) at Fig. 10.
  • the peers and/or servers send an acknowledgment to the scheduler indicating that the transfer has been completed as depicted at (5) at Fig. 10.
  • a secure method of determining that the file has been copied correctly is performed.
  • the currently preferred embodiment calculates the SHA1 hash value of the entire file and submits it to the scheduler for verification. If the values match the scheduler acknowledges that the transfer was successful.
  • the distributed media delivery system can scale up to dehver a large volume of media content even though the bandwidth available to many of the chents may be rather hmited (e.g., 256 Kps upload capability).
  • a media file e.g., a movie
  • a user may wish to view the media. For instance, a user may browse his or her priority hst at the client device and select a movie that is available (in encrypted form) on the set-top box.
  • Fig. 11 is a block diagram Ulustrating the processing of a user request to purchase (or rent) a movie for viewing.
  • the chent sends a message to the scheduler as shown at (2) at Fig. 11.
  • the scheduler sends a message to the customer management module as provided at (3) to request authorization.
  • a number of decision factors are checked, including the foUowing: a) account status; b) geographic location (e.g., is the client device in a geographic location that is authorized for the requested movie) supplied by Quova of Mountain View, CA; and c) has the user recently paid to watch the movie and is still within the agreed upon viewing window (for example, the user is allowed to watch a video for 24 hours and is stUl within that viewing window).
  • purchasing information provided by the customer management module at (4) is returned to the chent as provided at (5) for display to the user as illustrated at (6) at Fig. 11.
  • a message may be sent back to the client set-top box to display a message to the user indicating the price that will be billed or collected from their account when they press the OK button on the remote.
  • the user can then decide whether or not to purchase (rent) the movie. If the user elects to purchase the movie, the operations described below are performed for providing the authorization (decryption) key necessary for the user to decrypt and play the movie.
  • Fig. 12 is a block diagram Ulustrating the operations of the distributed media delivery system in providing an authorization (decryption) key to a chent enabling the chent to decrypt and play a movie. After a user is presented with purchasing information, the user may elect to purchase the movie for viewing as depicted at (1) at Fig. 12.
  • the user may press "OK" in response to the purchasing information displayed by the chent device.
  • the client sends a message back to the scheduler at (2) which the scheduler passes on to the customer management module to check the user's account and record the transaction as illustrated at (3) at Fig. 12.
  • the customer management server responds to the scheduler at (4) by granting permission to the scheduler to authorize viewing of the movie.
  • the customer management server may also indicate the type of authorization to be granted to the chent.
  • a SecureMedia EncryptoniteTM System is used for supplying the chent with a "media pass" that aUows a one time play of the video as provided at (5) at Fig. 12.
  • the present invention supports the implementation of a number of business models such as the "24 hour rental", where the user may watch a media item as many times as possible within a 24 hour period.
  • the scheduler is contacted, it in turn contacts the CMS and if the play request is during the 24 hour window, the delivery of another media pass is authorized.
  • the media pass is used to coUect the decryption key and the play begins.
  • the "media pass" or ticket can be considered as a right to obtain the authorization key.
  • the approach of the currently preferred embodiment is to separate the business rules governing access to the media from the actual issuance of a physical key that enables the user to play the media.
  • the client issues a request to the key vault/media pass server for a decrypt key as provided at (6) at Fig. 12.
  • the key vault/media pass server sends the key to the client at (7) which the client uses to decrypt and play the media item as illustrated at (8) at Fig. 12.
  • the presently preferred embodiment of the present invention uses an Encryptonite security subsystem from SecureMedia for issuance of authorization (decrypt) keys.
  • the client may use the key to decrypt, frame by frame, the media available on the hard disk of the chent set-top box.
  • the key is automatically destroyed as provided at (9) at Fig. 12. For security reasons, the key is not stored on the chent but instead is essentiaUy discarded after use. If the client wanted to watch the movie again, a request is sent to the scheduler from the STB, the business rules would be consulted at the CMS, and (assuming the repeat viewing was permitted by the rules) another media pass generated to enable the chent to obtain the necessary decrypt key. As previously discussed, media files are delivered to a chent device in encrypted and compressed form (e.g., via an MPEG or Windows Media 9 style encoding).
  • Fig. 13 is a block diagram Ulustrating the secure chent boot process that is employed on a chent set-top box (i.e., chent set-top box 375 as iUustrated at Fig. 3C).
  • the secure client boot process is employed when the set-top box is powered up and provides for initialization of the client in a secure manner. This is important given that the hard disk drive is physically separate from the motherboard of the set-top box in order to provide increased security and make it more difficult for one to obtain access to decrypted, but still compressed media files.
  • the approach of the present invention provides for using a digital signature process for confirming the validity of the software on the hard disk.
  • the CPU performs an initial (first) stage boot (Bl) from the boot ROM to begin to load the operating system. In this first stage boot (Bl), enough information is obtained for the CPU to communicate with the hard disk drive and other components on the motherboard.
  • the boot process continues by initially reading in (as data) the second stage boot (B2) from the hard disk drive.
  • the secure client boot process provides at (1) with an initial stage boot (Bl) from the boot ROM.
  • the public key (PK) is then read from the boot ROM at (2) and the hard disk drive code image (B2 and App) is checked by verifying its signature with the public key at (3) as provided at Fig. 13. If the signature is correct, this verifies the vahdity of the second stage boot (B2) and the apphcation software on the hard disk drive. In this event, the second stage boot (B2) continues from the hard disk.
  • the apphcation (App) commences execution as shown at (4A) at Fig. 3.
  • the data that is on the hard disk can be executed by the CPU (rather than just read in as data).
  • the signature is not verified, this may indicate evidence of tampering with the programs (possibly in an unauthorized attempt to gain access to the media files in compressed, but unencrypted, format).
  • the second stage boot from the hard disk drive does not continue, but instead fallback code (B2') is executed from the boot ROM as illustrated at (4B) at Fig. 13, This typically will inform the user that the hard disk appears to have been compromised and will require service.
  • Fig. 14 is a block diagram illustrating the decryption and playback operations at a client device. Once the client has obtained an authorization key for decryption and playback of a particular media file, the key is used to decrypt the file as illustrated at Fig. 14. As shown, the media is decrypted frame by frame with indexed decryption keys generated on the chent. Significantly, the methodology ensures that decrypted, compressed media is not removed from the client device's CPU and is secured so that it is very difficult for one to obtain copies of the media in unencrypted, compressed form.
  • the key (K) is dehvered to the chent set- top box
  • a media file is decrypted frame by frame using indexed decryption keys (kl, k2, k3, and so forth) as provided at (4) at Fig. 14.
  • Each frame is decompressed using on- chip software and/or hardware as provided at (5) and all key information is destroyed as provided at (6) at Fig. 14 when playback ends.
  • the secure chent playback process is implemented in software that is run using the Equator BSP-15 processor.
  • the Equator BSP-15 processor includes an on-chip DES engine enabling on-chip decryption of media files.
  • the method operates as follows. At the outset, a loop is established at line 1. Next, the method scans a given chent list for high priority transfers to initiate, at hne 5. This is followed by the method scanning the chent list for low priority transfers to initiate, at line 9. Housekeeping is performed at line 13 to cancel any transfers that have timed out (pursuant to a system-configured timeout value). At line 18, the state of messages is monitored. Here, the method checks outgoing messages that have been retried too many times.
  • each function gets a list of clients at the appropriate priority level (i.e., high or low, for the respective transfer function), as shown at hne 4.
  • a loop is established at line 7, for looping through all chents needing media.
  • the function or method chooses the top-ranked media item that is not completely downloaded, at hne 11, and finds a chent or server ("donor") that can provide that particular media item at line 14, A transfer record describing the transfer event is created at line 17 and is stored at line 20.
  • the method constructs messages to instruct the donor and receiving chent to perform the transfer, as indicated at lines 24-25.
  • the method sends the messages to the respective donor and receiving chent, at lines 28-29, whereupon the actual transfer takes place.
  • the process whereby the system determines the chents that need the media may be embodied as foUows in Table 3:
  • the process encapsulates SQL statements to ensure that the best chents are selected.
  • the donor and receiving client i.e., two chents, or chent and server
  • One is set up as a listener, the other as an initiator. Then they are allocated roles of sender or receiver. From there, they must transfer in data in the appropriate direction, issuing progress reports until the transfer is complete, whereupon they sign off.
  • FIG. 15A-D comprise a series of state diagrams illustrating interaction between the scheduler, a receiving (or destination) chent, and an originating donor/sender client or server in transferring media files.
  • Fig. 15A is a state diagram detaUing interaction between the scheduler, the destination or receiving chent ("receiving client"), and the originating donor/sender chent or server (the "sender") in a transfer of a media file from the sender to the receiving client.
  • a transfer is initiated for the scheduler.
  • the scheduler sends a receive request message to the receiving client.
  • the scheduler sends a send request message to the originating sender (i.e., the donor/sender client or server) at time T2. Also, at time T2 the scheduler resets the timeout for the start of the connection. Next, the sender locks the media segment to prevent it from being deleted at time T3. At time T4 the receiving chent either opens a socket or gets ready to listen, depending on the direction of communication. Similarly, the sender either opens a socket or gets ready to hsten at time T4. The receiving chent begins to receive data at time T5. After the transfer of data commences, both the receiving chent and the sender send transfer start messages to the scheduler at time T6.
  • the originating sender i.e., the donor/sender client or server
  • the scheduler resets the timeout for the start of the connection.
  • the sender locks the media segment to prevent it from being deleted at time T3.
  • the receiving chent either opens a socket or gets ready to listen, depending on the direction of communication.
  • the scheduler receives the start messages from the receiving client and the sender at time T6 and resets the timeouts.
  • the receiving client sends a transfer progress message to the scheduler.
  • the sender also sends a transfer progress message to the scheduler at time T7.
  • the scheduler receives the transfer progress messages from both the receiving client and the sender and resets the timeouts at time T7 as Ulustrated at Fig. 15A.
  • the receiving client sends a transfer succeeded message to the scheduler.
  • the receiving client also adds the media to the local database.
  • T8 the transfer of data by the sender is complete, and the sender sends a transfer succeeded message to the scheduler.
  • the scheduler receives transfer confirmed messages from the receiving client and the sender as shown at time T8 at Fig. 15A.
  • the scheduler adds the new media segment to the receiving client's media hst.
  • the scheduler also removes the record of the transfer from the sender's upload and the receiving client's download bandwidth.
  • Fig. 15B is a state diagram illustrating a time out by one of the communicating parties (e.g., timeout status by either the receiving chent or the sender).
  • a timeout expires at the scheduler for one of the communicants (i.e., the receiving chent or the sender).
  • the scheduler adds the job status for the client to the job queue.
  • Fig. 15C is a state diagram depicting a time out by both of the communicating parties (i.e., both the receiving client and sender on timeout status). At time TI the timeout expires at the scheduler for both the receiving client and the sender. The scheduler then sends transfer cancel messages to both the receiving client and the sender at time T2. The receiving chent and the sender may (or may not) receive the cancel request message sent by the scheduler at time T2. Next, at time T3 the scheduler resets the job so that it may be re-aUocated.
  • Fig. 15D is a state diagram detaUing an example of a failed transfer.
  • the receiving client sends a transfer failed message to the scheduler.
  • the scheduler receives the transfer failed message sent by the receiving client.
  • the scheduler issues a cancel transfer message to the sender at time T2.
  • the sender also receives the cancel transfer message sent by the scheduler at time T2.
  • the scheduler then puts the job on retry and timeout status as shown at time T3 at Fig. 15D. While the invention is described in some detaU with specific reference to a single- preferred embodiment and certain alternatives, there is no intent to Umit the invention to that particular embodiment or those specific alternatives. For instance, those skUled in the art will appreciate that modifications may be made to the preferred embodiment without departing from the teachings of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Computer Graphics (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Computer Interaction (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un systEme rEparti (300) et une mEthodologie de distribution de contenu multimEdia. Dans un mode de rEalisation, par exemple, un procEdE de distribution de contenu multimEdia de la prEsente invention consiste: A recevoir, au niveau d'un serveur (330), une demande transmise par un premier client (370), concernant un article multimEdia donnE, le premier client disposant d'une connexion A large bande vers d'autres clients; au niveau du serveur (330), A dEtecter un second client possEdant une copie codEe de l'article multimEdia demandE; A transfErer la copie codEe de l'article multimEdia demandE du second client au premier client; une fois que la copie codEe a EtE transfErEe au premier client (370), A indiquer au premier client que l'article multimEdia demandE est disponible; et, en rEponse A la rEception d'une autorisation de paiement du premier client (370), A dEcoder l'article multimEdia demandE pour qu'il puisse Etre utilisE par le premier client (370).
PCT/US2005/004575 2004-02-11 2005-02-11 Systeme reparti et methodologie de distribution de contenu multimedia Ceased WO2005078623A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05713478A EP1782343A4 (fr) 2004-02-11 2005-02-11 Systeme reparti et methodologie de distribution de contenu multimedia

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US52105204P 2004-02-11 2004-02-11
US60/521,052 2004-02-11
US10/709,393 US20050177853A1 (en) 2004-02-11 2004-04-30 System and Methodology for Distributed Delivery of Online Content in Response to Client Selections from an Online Catalog
US10/709,392 2004-04-30
US10/709,391 2004-04-30
US10/709,393 2004-04-30
US10/709,391 US20050177745A1 (en) 2004-02-11 2004-04-30 Distributed System and Methodology for Delivery of Media Content
US10/709,392 US20050177624A1 (en) 2004-02-11 2004-04-30 Distributed System and Methodology for Delivery of Media Content to Clients having Peer-to-peer Connectivity

Publications (1)

Publication Number Publication Date
WO2005078623A1 true WO2005078623A1 (fr) 2005-08-25

Family

ID=34865401

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/004575 Ceased WO2005078623A1 (fr) 2004-02-11 2005-02-11 Systeme reparti et methodologie de distribution de contenu multimedia

Country Status (2)

Country Link
EP (1) EP1782343A4 (fr)
WO (1) WO2005078623A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006085205A1 (fr) * 2005-02-14 2006-08-17 William Mutual Systeme de gestion de largeur de bande
US7207633B2 (en) * 2003-10-14 2007-04-24 Astec Industries, Inc. Scaling assembly
WO2007095309A3 (fr) * 2006-02-13 2008-02-07 Tvu Networks Corp Procédés, appareil et systèmes pour fournir un contenu multimédia via un réseau de télécommunication
WO2007084937A3 (fr) * 2006-01-20 2008-03-20 Motorola Inc Distribution d'articles à contenu
EP2008455A4 (fr) * 2006-04-05 2010-10-20 At & T Ip I Lp Techniques de fourniture de vidéo à la demande poste-à-poste
EP1942424B1 (fr) * 2007-01-07 2018-10-03 Apple Inc. Transmission de données d'arrière-plan entre un dispositif média et dispositif hôte
CN111464826A (zh) * 2020-04-14 2020-07-28 北京达佳互联信息技术有限公司 虚拟资源的榜单更新方法、装置、电子设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097299A1 (en) * 2001-11-21 2003-05-22 O'kane Robert Peer-to-peer (P2P) and internet content digital acknowledgement trigger used for file transfer

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7027460B2 (en) * 2001-12-21 2006-04-11 Intel Corporation Method and system for customized television viewing using a peer-to-peer network
KR20030056701A (ko) * 2001-12-28 2003-07-04 한국전자통신연구원 Ｐ２ｐ 방식을 이용한 멀티미디어 스트리밍 장치 및 방법
US20030158958A1 (en) * 2002-02-20 2003-08-21 Koninklijke Philips Electronics N.V. Distributed storage network architecture using user devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030097299A1 (en) * 2001-11-21 2003-05-22 O'kane Robert Peer-to-peer (P2P) and internet content digital acknowledgement trigger used for file transfer

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1782343A4 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7207633B2 (en) * 2003-10-14 2007-04-24 Astec Industries, Inc. Scaling assembly
WO2006085205A1 (fr) * 2005-02-14 2006-08-17 William Mutual Systeme de gestion de largeur de bande
WO2007084937A3 (fr) * 2006-01-20 2008-03-20 Motorola Inc Distribution d'articles à contenu
US8904456B2 (en) 2006-02-13 2014-12-02 Tvu Networks Corporation Methods, apparatus, and systems for providing media content over a communications network
WO2007095309A3 (fr) * 2006-02-13 2008-02-07 Tvu Networks Corp Procédés, appareil et systèmes pour fournir un contenu multimédia via un réseau de télécommunication
US9860602B2 (en) 2006-02-13 2018-01-02 Tvu Networks Corporation Methods, apparatus, and systems for providing media content over a communications network
US10917699B2 (en) 2006-02-13 2021-02-09 Tvu Networks Corporation Methods, apparatus, and systems for providing media and advertising content over a communications network
US11317164B2 (en) 2006-02-13 2022-04-26 Tvu Networks Corporation Methods, apparatus, and systems for providing media content over a communications network
EP2008455A4 (fr) * 2006-04-05 2010-10-20 At & T Ip I Lp Techniques de fourniture de vidéo à la demande poste-à-poste
US8707375B2 (en) 2006-04-05 2014-04-22 At&T Intellectual Property I, L.P. Peer-to-peer video on demand techniques
US9462337B2 (en) 2006-04-05 2016-10-04 At&T Intellectual Property I, L.P. Peer-to-peer video on demand techniques
US9736539B2 (en) 2006-04-05 2017-08-15 At&T Intellectual Property I, L.P. Peer-to-peer video on demand techniques
US10085063B2 (en) 2006-04-05 2018-09-25 At&T Intellectual Property I, L.P. Peer-to-peer video on demand techniques
EP1942424B1 (fr) * 2007-01-07 2018-10-03 Apple Inc. Transmission de données d'arrière-plan entre un dispositif média et dispositif hôte
CN111464826A (zh) * 2020-04-14 2020-07-28 北京达佳互联信息技术有限公司 虚拟资源的榜单更新方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
EP1782343A4 (fr) 2008-08-20
EP1782343A1 (fr) 2007-05-09

Similar Documents

Publication Publication Date Title
US20050177853A1 (en) System and Methodology for Distributed Delivery of Online Content in Response to Client Selections from an Online Catalog
US20050177624A1 (en) Distributed System and Methodology for Delivery of Media Content to Clients having Peer-to-peer Connectivity
US20050177745A1 (en) Distributed System and Methodology for Delivery of Media Content
US7269854B2 (en) Transaction system for transporting media files from content provider sources to home entertainment devices
US7444306B2 (en) Method and apparatus for the rental or sale, and secure distribution of digital content
US8955020B2 (en) Transcoding and data rights management in a mobile video network with STB as a hub
US8627415B2 (en) System and method for secure commercial multimedia rental and distribution over secure connections
CA2516966C (fr) Reacheminement d'un contenu en mode continu
US20060265436A1 (en) Grid network for distribution of files
JP4563450B2 (ja) コンテンツ配信システム
US20170364885A1 (en) System for managing, storing and providing shared digital content to users in a user relationship defined group in a multi-platform environment
US20020049679A1 (en) Secure digital content licensing system and method
EP1277305A4 (fr) Systeme securise d'octroi de licence concernant un contenu numerique et procede associe
CN102665112A (zh) 用于多媒体内容的安全传输和回放的方法和设备
JP2003510706A (ja) 電子書籍のセキュリティ及び著作権保護システム
CN101878644A (zh) 通过交互式界面为所选用户设备从第一设备定购内容的方法和系统
KR20080075043A (ko) 프로그래밍 선택 대상을 배송하기 위한 방법 및 시스템
WO2012044247A1 (fr) Procédé et appareil de diffusion en flux de contenus à droits gérés directement à un dispositif cible ou dans un réseau
EP1782343A1 (fr) Systeme reparti et methodologie de distribution de contenu multimedia
JP2008546065A (ja) ファイル分配用グリッドネットワーク
WO2012029018A1 (fr) Système et procédé d'obtention de données audio/vidéo à partir d'un réseau étendu
US8707361B2 (en) Method and system for quickly recording linear content from an interactive interface
CN101459671A (zh) 内容管理系统
KR20080043814A (ko) 컨텐츠를 타겟 장치에 다운로드하는 방법 및 시스템
EP2180653A1 (fr) Système et procédé pour la fourniture d'un contenu média sur demande via un réseau

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005713478

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005713478

Country of ref document: EP