JP6016773B2 - Push-pull based content distribution system - Google Patents

Description

  [01] The present invention relates generally to distributed networks for distributing digital content. More specifically, a dynamic content packaging and load balancing system and method is disclosed that optimizes quality of service for a variety of content delivery applications, including “video on demand”.

  [02] As computer networks have advanced, applications have become operational on that network, creating additional demand for network resources, including processing power, data storage, and network bandwidth. In addition to enabling sharing of these network resources, larger and more diverse networks such as the Internet have created a variety of applications. These applications require different architectural approaches to handle the different demands they place on available network resources.

  [03] Virtually all Internet applications are purely centralized (servers provide a large amount of network resources, and relatively “uncapable” clients require almost minimal resources) To some form of client, ranging from purely decentralized “peer-to-peer” (P2P) approaches (all nodes are “data-capable” clients and servers and share network resources equally) Use a server architecture. Certainly, most applications use an architecture that is somewhere between the two extreme approaches.

  [04] However, the Internet itself has evolved into a highly distributed network. In this network, a vast array of interconnected routers allows information to be transferred fairly quickly between virtually all network nodes. As a result, many applications (even those that seem well suited to a centralized architecture) simply leverage the inherent distributed architecture of the Internet to reduce otherwise demanding network resources.

  [05] Applications such as web browsing, for example, are a first example and may require a centralized approach. The web server must supply any content and distribute any portion of that content upon request to any web client making the request. However, by dividing the content into smaller packets and leveraging IP-based protocols, many relatively small files can be transferred to multiple clients across many different routes fairly quickly. Web servers still have to provide enough “centralized” bandwidth to handle a large number of requests, but the distributed nature of the Internet itself provides many of the solutions. In addition, using other distributed mechanisms such as replicating content across multiple strategically located web servers, caching frequently requested content “closer” or “edge servers” to requesting clients. Can “balance the load”.

  [06] Other popular applications, such as “instant messaging” (IM) and music file sharing, are more distributed by nature and have created large P2P communities. Unlike the centralized architecture where a large amount of network resources are provided by a central server “away from” its end-user clients, the P2P architecture distributes network resources among the clients that consume that network resource. This is independent of whether network resources include processing (eg, SETI project), data storage (eg, music file sharing), or network bandwidth (eg, IM).

  [07] However, certain applications, such as real-time delivery of audio and video, specifically “Video On Demand” (VOD), have so far been mainly due to their centralized nature and enormous network resource requirements. As a result, it did not allow a purely distributed P2P architectural solution. For example, VOD, by its nature, is a centralized application that resembles web browsing rather than instant messaging or music file sharing. Large amounts of content (eg movies and television broadcasts) must be delivered to any requesting client at the time of the request.

  [08] VOD demands a large amount of network resources not only on a cumulative basis (since many clients request different content simultaneously) but also for individual requests. For example, the distribution of an “on-demand” single movie to any client requires a significant amount of network bandwidth. In addition, such delivery must be stable and reliable. Such distribution must be initiated quickly and continued without degradation of audio and / or video quality over time. In short, such delivery must maintain a sufficiently high “quality of service” (QoS).

  [09] Especially because of the large demands placed on network storage and bandwidth by VOD, existing solutions have relied on high-cost enterprise-level dedicated servers. Enterprise-level dedicated servers have a large amount of storage capacity and network bandwidth sufficient to enable delivery of media content to a large number of users. Such solutions have also used relatively complex streaming and multicast protocols to reduce large network bandwidth demands. Thus, these solutions are actually relatively centralized, i.e. they attempt to allow large amounts of content to be distributed from one point (central server) to multiple points (clients). Multiple servers can be “distributed” (ie replicated) to balance the load on multiple servers. However, each of these servers must maintain a large amount of content and waste a large amount of additional network bandwidth to synchronize this content among these servers. These existing solutions simply do not scale well. This is because these solutions tend to exacerbate rather than reduce the inherent network bandwidth limitations of the Internet.

  [10] FIG. 1 illustrates certain aspects of the existing global physical infrastructure of the Internet (ie, interconnected routers and client / server computers). For example, a typical end user client node 10 is often interconnected via a local Internet service provider (local ISP) 20. The local ISP 20 has a relatively high speed connection to the regional Internet service provider (REG ISP) 30 and each other. The REG ISP 30 has a large backbone (BB) router 40 and high speed (and more stable / reliable) connections to each other. The BB router 40 is interconnected, usually via optical fiber and other extremely high speed connections, to form a relatively stable and reliable Internet core. FIG. 1 shows that a node can connect to a BB router 40 or a larger REG ISP 30 router “closer” or more directly, thereby providing faster, more stable / reliable connectivity (at higher costs). It is also shown that it is available.

  [11] Accordingly, the existing dedicated VOD server 100 is shown connected to the relatively fast REG ISP 30 and BB router 40. This provides more and more stable / reliable network bandwidth capacity to service requests from multiple end user client nodes 10. However, as alluded to above, even with hundreds of such dedicated VOD servers 100, they attempt to handle the large amount of network bandwidth demand needed to service a large number of simultaneous requests for different content. Nevertheless, complex streaming and multicast protocols are still needed.

  [12] For example, multiple clients within a given geographic area may request the same popular movie during “prime time”. However, each such request is likely to occur at slightly different times, making it extremely difficult to exploit these “common” requests to reduce overall network bandwidth. This on-demand nature of VOD applications not only exacerbates network bandwidth problems exponentially, but also makes it extremely difficult to maintain a consistently high level of QoS.

  [13] Some clients may be located closer to the REG ISP 30 and BB router 40, but many other clients are relatively slow and less stable / reliable connections And therefore experience a lower effective QoS. This is because the existing VOD architecture does not involve monitoring and managing the actual traffic, but rather complex streaming and multicast protocols that do not take into account the significant network bandwidth differences inherent in the physical infrastructure of the Internet. The use stems from the fact that by trying to provide a higher QoS.

  [14] Further, as noted above, the addition of more dedicated VOD servers 100 is due to the considerable additional network bandwidth generated to synchronize content between these additional servers. , Often inefficient. While continuing to add dedicated VOD server 100 may not be prohibitively expensive, it may eventually flood the Internet with database synchronization traffic.

  [15] Thus, VOD provides the best example of the problem of providing access to large amounts of digital content over the Internet while maintaining high QoS. To replace this issue with a perspective in the context of VOD applications, approximately 50,000 "popular" movies (less popular movies, which a VOD client may want to access on demand at any given time) Consider television broadcasting and rebroadcasting / archiving, as well as a myriad of non-commercial and other potentially desirable content). Assuming a 2 hour movie requires about 4 GB of storage (eg, at 480p standard definition resolution using MPEG2 compression, or at 720p high definition resolution using newer MPEG4 compression techniques), these 50000 A single copy of the movie should require about 200 TB of storage capacity (an expensive proposal even with the current data storage decline rate). Current estimates of the number of broadband users are already hundreds of millions (measured against a global population of 6 billion) and are expected to increase rapidly in the near term. Even with hundreds of dedicated servers strategically placed near the largest fiber optic backbone (approximately 4 or 5 dozens in the US alone), each server is 10,000 if not 100,000 Should support on-demand requests from human users. During peak hours, a significant percentage of such users (eg, thousands of users) may require different content (or the same content at slightly different times). This requires thousands of audio / video streams, each of which must maintain a consistent and reliable throughput of about 20 MB / min (ie twice the speed of a T1 line).

  [16] In short, VOD applications present a cumbersome technical challenge. This challenge can explain why existing VOD “solutions” have not yet achieved a significant level of commercial success. In fact, many commercial efforts appear to have focused on redefining the nature of VOD applications in order to make this problem seem more manageable than solving this technical problem. It is. Some solutions simply ignore QoS, others drastically reduce the area of available content, and other solutions are “time slots” rather than true on-demand functionality. I will provide a.

  [17] Nevertheless, providing access to large amounts of digital content over the Internet while maintaining high QoS is not an unmanageable problem. However, this requires the recognition that a centralized solution for applications such as VOD simply does not scale well and that IP-based protocols such as IP4 do not inherently provide QoS. To do. What is needed is an intelligent method. This method monitors and manages network traffic to provide “network-based” QoS for applications such as VOD by leveraging the inherently distributed architecture of the Internet. To do that, if true on-demand functionality must be realized within the existing infrastructure of the Internet, a huge amount of storage resources and network bandwidth resources will be consumed by the end-user client that consumes them. Must be distributed "closer".

  [18] Also, cable television networks do not use the IP protocol in both directions, but the content is delivered to the client by returning a digital signal on the carrier frequency (eg, using QAM64 modulation) and returning The path (eg, for requests) uses a protocol such as “Real Time Streaming Protocol” (RTSP). However, it should be noted that many of the same issues as for IP-based networks such as the Internet apply equally to cable television networks. CATV networks face the same limited network bandwidth and scalability issues as the Internet. In any case, CATV networks are more difficult to allow for distributed solutions without extensive changes to existing network infrastructure.

  [19] The present invention provides a plurality of dynamic content packaging and load balancing systems and methods designed to enable the delivery of large amounts of linear digital content over the Internet while maintaining high QoS. About. While various embodiments of the present invention are disclosed in the context of VOD applications, the underlying concept is that other content delivery systems and applications hosts, especially digital content, is the ultimate user of such content. Applicable to hosts that benefit from being “closer” to

  [20] In one embodiment, portions of digital content are distributed to selected network peers to increase QoS when such content is later retrieved. In a further embodiment, an index of the location of such portions of digital content is generated and maintained, and then used to further enhance QoS during the retrieval of such content. In another embodiment, communications between network peers are monitored to facilitate the process of distributing and retrieving such digital content while maintaining high QoS.

  [21] FIG. 2 illustrates a conceptual VOD system embodiment of the present invention that utilizes the Internet as a network platform. As noted above with respect to FIG. 1, the existing global physical infrastructure of the Internet includes a core of interconnected BB routers 40, and a REG ISP 30, a local ISP 20, and an end user client node 10. Rather than deploying a dedicated VOD server, this embodiment of the present invention allows a “VOD peer” 15 (eg, set-top box, PC, game console, mobile phone, and various other client devices) to end user clients. Expand to a location (eg, home as well as other destinations). In this way, the network resources (including storage, network bandwidth, and processing) necessary to implement the VOD functionality consume that network resource to access and view the content on demand. Really distributed among the VOD peers 15.

  [22] As also shown in FIG. 2, a relatively small number of “VOD support servers” 55 are not necessarily for the primary function of content distribution and distribution to end-user VOD peers 15, Note that it is provided for purposes (initialization and crash recovery, software updates, fallback communication, and optional registration). In one embodiment (described in more detail below), four or five VOD support servers 55 are sufficient to provide the “most reliable” function to VOD peers 15 throughout the global Internet.

  [23] VOD support server 55 may also be used as a “seed” server to simulate a group of VOD peers 15 within a particular area until a sufficient number of VOD peers 15 are deployed. When such VOD peers 15 are deployed, these “seed” servers are gradually becoming unnecessary and can be redeployed elsewhere or utilized for other purposes.

  [24] The publication server 16 is also provided by any entity that wishes to publish (ie, serve) content that is made available from the VOD peer 15 on demand. In one embodiment, these servers include personal computers running VOD publishing software (not shown) designed to prepare content for distribution within the VOD system.

  [25] VOD peer 15 has the ability to display various digital media “content objects” on demand, including movies, television program episodes, rebroadcast sporting events such as NFL football games, and even personal home video clips Including sex. As described below, the release of one or more content objects to the network constitutes an “event”.

  [26] In one embodiment of the VOD system of the present invention, the VOD peer 15 is given substantially immediate access to the content object. None of the systems can guarantee immediate access to all potential content objects, but various QoS levels can be established. In one embodiment, most content objects (eg, including about 50,000 most popular movies) can be accessed almost immediately (T0), eg, on average, a short number of seconds (eg, from a user request) Within a range from 1/2 second to 12 seconds). Some content objects may not be as readily available from a particular VOD peer 15 (eg, due to “proximity” to such content objects) and may be several minutes or more (T1) For example, it may not start within the range of 30 seconds to 5 minutes. Still other content objects may not be available on the system when requested (T2), but such a request may trigger a “pre-order”. The pre-order is delivered to the requesting user's VOD peer 15 and introduces a 24 hour delay before being stored there.

  [27] In one embodiment, the VOD peer 15 is a client device having 10 GB of storage. A portion of this storage (usually about 4 GB) is allocated for playback of the requested content object, and the remaining 6 GB is used to “share” the content object among other “near” VOD peers 15. Is possible. As noted above, VOD applications require a large amount of storage capacity, which is a network resource constraint that can be mitigated by distributing the storage of content objects among various VOD peers 15.

  [28] Thus, the content object is formatted into a component “package” that is optimized for immediate delivery. As described below, one goal is to place a “supply” of such content objects as “close” as possible to the VOD peer 15 that is most likely to “request” access to the content object. is there. Package size and location are dynamically adjusted to minimize access time. For example, in one embodiment, the average package size is about 30 seconds of video and a smaller package (eg, 10 seconds) is reserved for an earlier portion of the content object (ie, the user A larger package (e.g., 2 minutes) is utilized for the remainder, to allow the movie to start while subsequent packages are being removed. The package size, location, and even the number of copies can be dynamically adjusted, for example, depending on actual measured delivery times, request patterns, and other factors.

  [29] Rather than deploying hundreds of terabytes of storage to a centralized dedicated server, such storage is between tens of thousands or hundreds of thousands (possibly millions) of VOD peers 15. Distributed efficiently. By intelligently distributing packages among VOD peers 15, requests for content objects can be satisfied relatively quickly by accessing multiple packages from many different nearby VOD peers 15 simultaneously. it can.

  [30] Rather than “streaming” content objects from one node to another (eg, using standard streaming and multicast protocols), individual packages must use standard IP-based transport protocols. Via a number of different VOD peers 15 simultaneously. Therefore, rather than trying to implement QoS within the streaming protocol, QoS is made to the network itself by utilizing distributed software on the VOD peer 15 to monitor various network traffic statistics (eg, access times). Can be effectively incorporated into. Network traffic statistics can be used both for distributing packages of content objects prior to VOD peer 15 requests and for accessing these packages in response to such requests.

  [31] As will be described in more detail below, QoS is effectively incorporated into the network itself and becomes a unique integral component of this network of VOD peers. This “network-based QoS” or “NQoS” is the basis upon which VOD applications and other applications can be built.

  [32] “Push” the content object's packages during the “publication” of the content object to the network (ie, distribute them among the VOD peers 15) , Can be “pulled” (ie, removed from such VOD peer 15) upon request of any VOD peer 15. Several methods are used to implement this “push-pull” concept so that the packages can be pushed within the “neighborhood” of the VOD peer 15 that is most likely to pull the packages on demand later. To do.

  [33] Unlike prior art VOD systems where content is stored on an “edge server” waiting for a request, the content object of the present invention is from which VOD peer 15 which content (and how many copies). Pushed between VOD peers 15 by trying to predict what should be enabled. The VOD peer 15 can then make a request to pull such content based on information regarding which content objects are available and where the content objects are located. For example, the user interface has sufficient information to indicate to a particular user whether the desired movie is available “instantly” or may require some delay.

  [34] One such concept that facilitates this push-pull mechanism is the concept of a network “cluster” or group of relatively “close” VOD peers 15 that share a relatively high QoS with each other. . For example, much of the physical infrastructure of the Internet is constantly changing, but can be obtained from publicly available information. Such information can be utilized along with the IP address and geographic information obtained from standard IP location services to initially establish such a cluster of VOD peers 15. Transfer of information between VOD peers 15 in these clusters provides a less restrictive bottleneck with a lower probability of packet loss (eg, compared to a longer path). VOD peers 15 within a particular cluster can be considered “closer”, ie, within a smaller “Internet distance” from each other, as compared to VOD peers 15 across clusters.

  [35] By providing distributed “cluster controller” software on each VOD peer 15, various network traffic statistics can be dynamically monitored over time. For example, in addition to the known bandwidth and other aspects of connectivity (eg, the number of hops between nodes), ping times can be measured periodically, and the reliability of connections over long time intervals is also periodically Can be measured. Propagating this information to virtually all VOD peers 15 by maintaining such information in a distributed fashion (eg, using VOD peers 15 that know only a few neighbors) Can do. The cluster controller is essentially a content balancing distributed server.

  [36] In addition, a level of “trust” can be defined so that a VOD peer 15 whose connectivity is more reliable over time can be designated as “more reliable”. It has become. The VOD peer 15 can then communicate with a small number of more reliable VOD peers 15 as well as neighboring nodes having equal or lower “trust levels”.

  [37] These trust levels are higher, such as maintaining cluster membership and managing “inter-cluster” and “super-cluster” (ie, larger superset clusters) communications. It can be used to designate a relatively more reliable VOD peer 15 within the cluster that is responsible for the level management function. A more reliable VOD peer 15 can rely on this when, for example, no other node is available. A cluster controller in such a more reliable VOD peer 15 can be considered a virtual “super cluster controller” in that it handles problems beyond its own cluster.

  [38] The VOD peer 15 may only know to contact a very reliable node (eg, VOD support server 55) by default (or at the time of a crash), and then To join a cluster, it can be directed to a slightly less reliable VOD peer 15 (possibly after testing access time to determine the most appropriate cluster). After establishing and maintaining the various clusters of VOD peers 15, use these clusters for both pushing packages between VOD peers 15 and pulling packages from such VOD peers 15. Can do.

  [39] For example, the publication server 16 may be instructed to contact a relatively reliable VOD peer 15 in a particular cluster (eg, by a known VOD support server 55). Information about the published content object includes its genre or category (eg, comedy, sports, etc.), publisher name (eg, indicating the popularity of a major publisher, such as Disney), time zone, time cycle (eg, , When it is most likely to be required), and other information indicating not only the overall popularity but also the popularity within a certain geographic region.

  [40] In the first example, the publication server 16 can use this information to prepare a public content object. The publication server 16 can format this content object into a specific size package and make it available for a specific time interval based on predefined rules. Alternatively, it can be allowed to propagate between multiple clusters or between clusters within a particular geographic region.

  [41] A relatively reliable cluster controller in a particular cluster also pushes or propagates a certain number of copies of this content object package to a particular VOD peer 15 in the cluster based on this information. The publication server 16 can be instructed as follows. For example, a cluster controller can know that a particular genre of content objects are less popular within that cluster or geographic region (either comprehensively or from requests measured over time). Thus, fewer copies of the content object's package can be propagated among the VOD peers 15 in the cluster. This distribution can change over time as dynamic information is collected. Packages are replicated more times (or fewer times) based on changes in the frequency of requests for a particular content object (eg, when more comedy is requested).

  [42] Utilizing predetermined information as well as dynamically monitored information, the content object can be identified by "predicting" the appropriate location, size, and number of copies of a particular content object VOD peers 15 that are more likely to request and more likely to be able to access them relatively quickly can be pushed. The publication server 16 and cluster controller use this information to distribute such packages within the cluster in order to optimize access time when VOD peers 15 in the cluster request packages. In this way, content objects are distributed among various network clusters to optimize delivery time and overall QoS when later requested.

  [43] In addition, while the content object is published, the cluster controller also generates a “tracking index” and an associated “tracking file” that indicate the location of the content object's package within and between clusters. Propagate. Over time, this tracking index and associated tracking files can be updated as package popularity increases or decreases (eg, based on request patterns within a particular cluster). Less popular content objects may even disappear from the network over time and need to be republished later if requested. In one embodiment, only content objects from “private” publishers are allowed to disappear completely from the network, and content objects from commercial publishers have at least a minimum number of replicated copies somewhere on the network. Monitored to ensure it remains stored.

  [44] Publish content objects by pushing packages between VOD peers 15 across various network clusters (and generate tracking indexes and associated tracking files that identify the location of such packages; Distributed), after monitoring dynamic network traffic and changing the trust level, package size and location (and other attributes) accordingly, these content objects are now sent by the VOD peer 15 to its own system. Can be pulled or requested for display above. When making an initial request to an adjacent VOD peer 15, such request propagates until it reaches a sufficiently reliable VOD peer 15 that can access the associated tracking index or tracking file of the requested content object. Is done.

  [45] As with publication and push processes, distributed cluster controllers are often used for pull processes. When locating the tracking index, the cluster controller identifies the most appropriate (ie, “closest”) tracking file that contains the location of the group of packages for that content object, and then these groups of packages Responsible for monitoring and managing “sub-requests” for In one embodiment, the requesting VOD peer 15 uses a tracking file to direct a group of such packages directly to a nearby VOD peer 15 that stores the package of content objects in a “shared” storage space. To request.

  [46] During both the push process and the pull process, the tracking index and associated tracking file are dynamically updated and propagated between the associated VOD peers 15 to obtain each package or group of packages. Reduce the access time required. Priorities are given to earlier packages in the content object. This is because they are required sooner. For example, a special algorithm is used to maximize the transfer success probability. If problems occur with later packages, a longer recovery time can be used before such packages are “slowed down”. This provides more opportunities, for example, contacting the more reliable VOD peer 15 (or even the VOD support server 55, for example in case of an emergency).

  [47] Other algorithms balance the cost of using more “expensive” network resources against the probability and consequences of failure. For example, the more expensive VOD support server 55 may be used only for early packaging and / or emergencies.

  [48] Since multiple sub-requests can be made in parallel, and various network paths are monitored and pre-tested, the VOD peer 15 can even request any content object on demand. It is possible to ensure a high QoS. In addition, as more VOD clients request additional content objects, the package of such content objects is already on the appropriate VOD peer 15 across various clusters to maximize the QoS of subsequent requests. Distributed (ie pushed) in advance. When network conditions, request patterns, or other measurable factors change over time, the size, location, and number of packages are adjusted prior to on-demand requests, providing very high QoS. A scalable VOD system is provided.

[49] FIG. 4 illustrates a prior art IP-based VOD topology that relies on a dedicated edge server to store and distribute content in a centralized manner to its end-user clients. [50] To optimize QoS, network load is monitored using dynamic load balancing techniques, and in response, the size, number, and location of content object packages (of other attributes) FIG. 4 illustrates an embodiment of the IP-based VOD topology of the present invention in which content objects are modified and tracked (among others) stored and distributed on a distributed P2P basis among end-user clients. [51] Similar trust levels and relatives with access to higher trust level VOD peers in the event of problems such as requiring faster and / or higher reliable content delivery FIG. 6 illustrates an embodiment of a cluster or group of VOD peers sharing high QoS between each other. [52] A group of content object packages are dynamically pushed to the selected VOD peers, and these groups are subsequently viewed for on-demand viewing by any VOD peer in the cluster while maintaining high QoS. FIG. 6 illustrates an embodiment of a regular cluster of VOD peers that are enabled to be pulled. [53] Node ID used to track both static and dynamic information related to VOD peers including various dynamic descriptors such as unique identifier, net proximity information, and current trust level FIG. 6 illustrates an embodiment of a data structure. [54] Fig. 14 illustrates an embodiment of a content reference ID (CRID) data structure used to uniquely identify events published on the network. [55] FIG. 5 illustrates an embodiment of a tracking file data structure used to track the location of a group of content object packages published within a particular cluster. [56] An illustration of an embodiment of a tracking index data structure used to locate a VOD peer with a copy of an associated tracking file. [57] FIG. 5 illustrates an embodiment of an initial symmetric handshaking protocol that establishes communication between VOD peers. [58] FIG. 6 illustrates an embodiment of a dynamic communication process in which a new content object is announced on the network and then published (ie, pushed). [58] FIG. 6 illustrates an embodiment of a dynamic communication process in which a new content object is announced on the network and then published (ie, pushed). [59] Embodiments of slicing content objects into variable length packages and distributing them among different numbers of VOD peers to facilitate the “instant play” functionality of the VOD system of the present invention FIG. [60] FIG. 6 illustrates an embodiment of a trust level between VOD peers both within and between clusters of VOD peers in a network. [61] An embodiment of a dynamic communication process that locates an associated tracking index and tracking file that is subsequently used to download (ie, pull) selected content objects for viewing at a VOD peer FIG. [61] An embodiment of a dynamic communication process that locates an associated tracking index and tracking file that is subsequently used to download (ie, pull) selected content objects for viewing at a VOD peer FIG. [62] FIG. 6 illustrates an embodiment of multiple VOD peers that supply a content object package to a VOD peer that has requested viewing of a content object. [63] In order to provide network-based QoS (NQoS), network traffic and behavior are monitored between VOD peers and the resulting VOD peer and network characteristics (such as trust level and content object package distribution) FIG. 6 illustrates an embodiment of a dynamic communication process to change. [64] An embodiment of a cluster pattern of VOD peers whose configuration changes over time as a result of dynamically monitoring changes in network usage, content object consumption, and other characteristics of the system state. . [64] An embodiment of a cluster pattern of VOD peers whose configuration changes over time as a result of dynamically monitoring changes in network usage, content object consumption, and other characteristics of the system state. . [64] An embodiment of a cluster pattern of VOD peers whose configuration changes over time as a result of dynamically monitoring changes in network usage, content object consumption, and other characteristics of the system state. . [64] An embodiment of a cluster pattern of VOD peers whose configuration changes over time as a result of dynamically monitoring changes in network usage, content object consumption, and other characteristics of the system state. . [65] FIG. 7 illustrates a block diagram embodiment of a system for inserting promotional content into and between other content objects.

I. Key concepts A. Cluster and trust level

  [66] As noted above, certain aspects of the existing physical infrastructure of the Internet can be obtained from publicly available information. Such information can be utilized in one embodiment shown in FIG. 3 to create a group of VOD peers known as clusters. Standard IP address location services can be utilized in combination with IP ranges and other known physical infrastructure information to effectively translate the IP address of a VOD peer to a “cluster identifier” or cluster ID. . This cluster ID is also shown in FIG. 3 and serves to identify the cluster hierarchy. In this embodiment, these clusters are created and modified dynamically.

  [67] These clusters are initially created from known physical infrastructure information and dynamically based on network traffic statistics derived from comprehensive and actual data transfer monitoring and related test runs. Since it is updated, it represents more than a group of VOD peers. Specifically, the cluster serves to identify a group of VOD peers that generally share a particular QoS between each other.

  [68] As described in more detail below, VOD peers are able to transfer specific amounts of data from each other when they can consistently and reliably transfer (over time) an amount of data between each other within a specific time interval. Think of it within the internet distance. These VOD peers that are “close” to each other form a cluster.

  [69] By identifying these clusters of VOD peers and utilizing them for data transfer, the network is much quicker and more reliable than from a “relatively high bandwidth” VOD peer in another cluster, Information can be distributed from “relatively low bandwidth” VOD peers within the same cluster to requesting VOD peers. In other words, the performance and reliability of a “local” intra-cluster is a good estimate of QoS for subsequent on-demand requests. This is because, during the publication of the content object, the cluster information is used to identify the appropriate VOD peer where the content object package is stored (pushed).

  [70] As a practical matter, only a relatively small number of VOD peers are "near" high-performance and reliable backbone routers that exhibit a "global" ability to transfer large amounts of data quickly and reliably over long distances. There is a possibility. However, to achieve VOD functionality while maintaining a relatively high QoS among a large number of VOD peers, a cluster of relatively “close” VOD peers that can exchange data quickly and reliably between each other. It is important to identify and utilize the “local” QoS shared by.

  [71] When a VOD peer shows the ability to transfer a larger amount of data to one other VOD peer over time more quickly and reliably, the trust level of that VOD peer is increased. The trust level can reflect the ability to maintain a relatively high QoS among VOD peers in the cluster. In addition to maintaining this “local” QoS, a higher confidence level ultimately represents a more “global” QoS. More “global” QoS refers to the ability of VOD peers to manage intercluster (eg, non-intersecting clusters) and supercluster (eg, superset cluster) communications.

  [72] Such communications span not only data transfer to remote parts of the Internet, but also management and monitoring of VOD peer performance and reliability across clusters, as well as cluster membership changes and "local" cluster boundaries May also include trust level adjustment. In addition, as described in more detail below, these “very reliable” VOD peers are responsible for publishing content objects and pushing their packages over the network, as well as turning on VOD peers for content object display. It can also be used to manage certain high-level functional aspects of the removal or pulling of such packages to meet demand requirements.

  [73] VOD peers in a cluster, such as cluster 320, are informed about some neighboring VOD peers with similar trust levels and some VOD peers with higher (and possibly lower) trust levels. This propagates information “up” in a distributed manner to relatively highly reliable VOD peers within the cluster (and sometimes across clusters) and then lower confidence levels throughout the cluster. Allows a VOD peer to propagate “down” back.

  [74] Individual VOD peers or other computers (eg, VOD support servers) need not know about the particular VOD peers that make up a particular cluster (such information propagates queries in a distributed fashion) Can be generated by :) Alternatively, the clusters are created in a distributed manner and one relatively very reliable VOD peer is informed about other similar and very reliable VOD peers. Over time, when less reliable VOD peers join the network, they are assigned to a specific cluster and have a few more highly reliable VOD peers as well as their own trust level Informed about VOD peers (all of which are in the same cluster).

  [75] Referring to FIG. 3, a relatively small number of dedicated VOD support servers are positioned at strategic global locations throughout the Internet and have the highest confidence level 301 (eg, 1 on a scale from 1 to 16). Assigned. In one embodiment, these dedicated VOD support servers are very “close” to the high bandwidth fiber optic internet backbone router and are able to communicate (and transfer data) between each other very quickly. . As noted above, these VOD support servers do not need to be used directly for VOD application functionality (such as storage and retrieval of content objects), but simply VOD peers are added to the network. It may assist in performing certain auxiliary functions, including initialization of those VOD peers at times.

  [76] In one embodiment, when a VOD peer is added to the network, the VOD peer can provide some initialization service among these VOD support servers that includes the assignment of that VOD peer to a particular cluster. Know specifically about one or more VOD support servers. The distributed software within each VOD peer, known as the “cluster controller”, not only participates in this initialization process, but instead of the VOD peer, the intra-cluster service (and in some cases the VOD peer's trust level is If it is high enough, it also manages intercluster services.

  [77] These services, provided in a distributed manner by the cluster controller of each VOD peer (described in more detail below), include the main VOD functionality. These include: publication and push of content objects, generation and propagation of tracking indexes and tracking files to maintain the location of each content object's package group, and on-demand display of content objects at the requesting VOD peer. Content object package pull, as well as dynamic monitoring of network traffic to maintain NQoS (this includes VOD peer trust level, VOD peer membership in a particular cluster, and size of content object package groups And dynamic location and location and associated tracking index and tracking file contents and location).

  [78] In one embodiment, the same cluster controller software is present on all VOD peers. This software is responsible for maintaining the trust level of each VOD peer within a particular cluster. For example, when it detects that a particular VOD peer's reliability is dropping below a predetermined threshold (via dynamic monitoring of network traffic), the cluster controller will set the VOD peer's trust level accordingly. Can be lowered. Of course, the confidence level can be increased in a similar manner.

  [79] At a sufficiently high trust level, portions of this cluster controller software are also responsible for maintaining the trust level of VOD peers across the cluster, including both inter-cluster and super-cluster communications. For example, in addition to simply raising or lowering the trust level of one VOD peer, this virtual super cluster controller functionality may also include changing the membership of a VOD peer from one cluster to another. it can. When the trust level of a VOD peer increases over time, that VOD peer is part of a larger supercluster (eg, supercluster 310) that includes other clusters as well as the previous cluster (eg, cluster 320). Can be.

  [80] In one embodiment, 16 trust levels are maintained by the cluster controller. In this embodiment, the highest or “most reliable” trust level is considered trust level 1 301 and this level is reserved for dedicated VOD support servers. As the network of VOD peers grows over time, trust levels 2-5 302 should represent a relatively small number of the total number of VOD peers. In other words, there should never be a “most reliable” node that exceeds a relatively small number.

  [81] On the other hand, trust levels 6-9 303 represent a large number of VOD peers. Over time, VOD peers may move up and down periodically between these trust levels according to dynamically monitored changes in their performance and reliability. Trust levels 10-16 (none of which are shown but included in various trust levels 305 distributed throughout the network) are relatively few "unreliable" or "abnormally low bandwidth" VOD peers. Represents. Nevertheless, confidence level 16 can represent a “floor” of acceptable delivery probability for a VOD peer, such as 100 kbps, during an average network load time over a 30 minute duration.

  [82] For example, trust level 12 304, in one embodiment, is a “default” trust level that is assigned when a VOD peer is initially connected to the network (or reconnected, eg, after a hardware failure). Can be considered. When the cluster controller obtains statistical information by dynamically monitoring network traffic over time, the trust level follows the statistical information to more accurately reflect the impact of the VOD peer on QoS. Adjusted. In practice, the duration of the network connectivity itself is a reliability factor that contributes to the determination of the trust level of the VOD peer.

[83] In one embodiment, the trust level reflects four main “trust level parameters” that are themselves determined from a combination of various “trust level factors”. These four trust level parameters represent the impact of VOD peers on QoS across different domains,
(1) “Local” cluster of VOD peers,
(2) the larger “region” cluster,
(3) includes more “remote” larger areas, such as countries or continents, and (4) relatively remote portions of the core Internet where bandwidth and interconnectivity are limited.

  [84] The confidence level factors described in more detail below include various statistics derived from dynamically monitoring network traffic. These confidence level factors are combined for the region represented by each confidence level parameter to generate a confidence level parameter that reflects the QoS within that region. These trust level parameters are then combined to generate a “global” trust level that reflects not only local QoS, but also the degree to which VOD peers can be trusted for inter-cluster and super-cluster responsibilities. In one embodiment, this confidence level is determined by a weighted average of confidence level parameters.

[85] Of course, confidence level factors can be supplemented, replaced, and fine tuned over time to attempt to more accurately represent the various QoS levels across the confidence level parameter domain. In one embodiment, these confidence level factors are:
(I) Load time (eg reflecting higher traffic during early prime “prime time” time),
(Ii) Probability of “fast” service delivery to relatively local peers during high load times,
(Iii) Probability of staying online for the next 500 hours,
(Iv) Probability of “fast” service delivery to “very remote” VOD peers (reflecting good connectivity over the Internet),
Contains a myriad of attributes that can be measured dynamically over time, including (v) the maximum speed to a given ISP, and (vi) the maximum speed from a given ISP.
B. Tracking file and tracking index

  [86] Before describing the main push and pull processes of the present invention where content objects are distributed across VOD peers and retrieved on demand, it is helpful to first describe some of the main data structures. The primary data structure is used to “track” the location of a group of content object packages distributed among these VOD peers. In one embodiment, these data structures are created and updated during a publication process in which a group of newly published content object packages are pushed to various VOD peers, and then during the retrieval process Used to satisfy the on-demand requirements of VOD peers. These data structures are also updated over time in response to dynamic monitoring of network traffic by the cluster controller to maintain the relatively high QoS of subsequent requests.

  [87] Two main data structures are used to track the location of various groups of packages into which content objects are divided. That is, (1) tracking file and (2) tracking index. Before examining these data structures, it is important to distinguish content objects from events that expose one or more content objects. For example, a movie can constitute one content object, and its trailer can constitute another separate content object. The trailer publication can be an event and the movie publication can be a separate event. In addition, publications of “early release” of movies in fixed geographic areas (eg, New York and California) later than the same content object (movie), whether by the same publisher or by different publishers. It is also possible to configure separate events that are distinguishable from all the world's publications.

  [88] Thus, these data structures assist in tracking the location of a group of content object packages, but their presence is based on events that involve exposing one or more content objects. It should be noted that in one embodiment, multiple content objects can be published in a single event, but in another embodiment, each content object publication can constitute a separate event.

  [89] Furthermore, it should be noted that these data structures themselves can be “distributed” in that the entirety of these data structures need not necessarily be in any single location. These data structures can be layered, for example, so that there is a “subset version” within each cluster. A supercluster may include a “superset version” having additional entries that include additional clusters contained within the supercluster. These data structures can also be distributed in a more traditional way to include entries that contain only “neighboring” VOD peers, which can result in a larger set of entries (eg, including the entire cluster). It is necessary to communicate the request to obtain.

  [90] A first primary data structure, a tracking file, is used to track the location of a group of content object packages published within a particular cluster. In one embodiment, a separate tracking file within each “leaf” cluster (ie, a cluster that is not further divided into sub-clusters) tracks each of the events for which content objects are published within that cluster. As noted above, a superset cluster may include a “superset” tracking file that includes respective entries for that “subcluster”.

  [91] Even within a cluster, tracking files can be further “distributed”. In other words, the tracking file can contain an entry for each event for which the content object is published in that cluster, but as described further below, a copy of the tracking file at one VOD peer is instead , It can only contain entries for events that include that VOD peer.

  [92] In any case, the tracking file correlates a group of packages of content objects to the VOD peers (eg, the IP addresses of these VOD peers) where copies of that particular group of packages are stored. . For example, as noted above, a content object such as a movie can be divided into 1000 different packages, each averaging about 30 seconds of varying size, with the early part of the movie being relative Smaller packages, perhaps only 10 seconds, and other packages can be as large as 2 minutes. The tracking file can contain entries for the first six package groups for that content object, which can be related to eight different VOD peers in the cluster and these VODs. Each of the peers contains a copy of a group of six packages that together represent the first minute of the movie (for redundancy as well as high QoS, depending on the popularity of the content object).

  [93] Additional entries may describe the remaining groups of the content object package and possibly other content object packages published in the cluster. For example, as described in more detail below, when an event results in the publication of a content object, a “master” VOD peer is selected to manage the propagation of the group of packages for that content object. In addition to these “master” VOD peers (which may or may not store any of the groups of packages of that content object), other VOD peers store a group of packages of that content object. Selected.

  [94] In one embodiment, each of the VOD peers used to publish the content object (eg, a “master” VOD peer as well as a VOD peer that stores a group of the content object's packages) Each group has a tracking file with entries that correlate to all VOD peers in that cluster where that group of packages is stored. This allows any copy of the tracking file to be used to locate the entire content object without further propagation of the request.

  [95] In one embodiment, the tracking file includes one or more “master” VOD peers, regardless of whether or not the one or more “master” VOD peers themselves store groups of packages of content objects. Also includes identifying information. In other embodiments, as noted above, the tracking file can be further “distributed” (eg, to include entries for only “adjacent” VOD peers that store relevant groups of packages, Further propagation of the request to locate the VOD peer that stores all of the group of content object packages is required).

  [96] If a VOD peer is also used for another event (eg, storing a group of different content object packages exposed to the network), a separate tracking file is generated as described above. be able to. In another embodiment, the same tracking file can be utilized with an additional entry for the group of packages for that other content object. In any case, there should be some means of identifying a group of packages across events (eg, across two different content objects), as described in more detail below.

[97] In one embodiment, a cryptographic hash algorithm is used to facilitate an efficient lookup of a group of packages for a particular content object. Each package of content objects allows the package to be verified in a small block that utilizes relatively little memory (eg, for file pointers, handles, etc.) (eg, replicated or distributed to the target VOD peer) To be assigned a common hash value. This hash-based data structure is
(I) a header including the total data size of all the packages of the content object, the number of packages into which the content object has been divided, and an offset to the original content object data stream before the division into packages;
(Ii) an inter-package hash table tree that includes a root hash value of each package's internal hash tree that enables verification of a common hash value for each package;
(Iii) an in-package hash tree table that allows lookup of an offset into the data in which such a package is stored;
(Iv) Data itself (that is, the contents of each package)
Including. By combining this data integrity checking infrastructure with a public key infrastructure, the content object validity for the replication and delivery of packages to the desired VOD peers with granularity over time (eg, allow or (Cancel).

  [98] Accordingly, a tracking file is created and modified when the content object is published and pushed to the selected VOD peer in each cluster. However, in order to use these tracking files to retrieve or pull these packages to VOD peers that request content objects on demand, these tracking files must first be located.

  [99] In one embodiment, the tracking index is generated and updated when the tracking file is created to facilitate an alternative means of locating the associated tracking file. Thus, as described in more detail below, an on-demand request for a particular content object can result in a search, in which the associated tracking file can be located directly or indirectly via a tracking index. Can be determined. Typically, such a search propagates “up” (ie, to a VOD peer with a higher confidence level) until the tracking index is located, and this tracking index has a variety of “ Identify "candidate" VOD peers. The request then propagates “down” until such candidate VOD peers are sufficiently “close” VOD peers, after which the group of packages is located and delivered to the requesting VOD peer. be able to.

  [100] Thus, the tracking index correlates an event with the location of a VOD peer that has a copy of the tracking file associated with the content object published for that event. In one embodiment, the tracking index itself is a layered file, with a greater number of entries present in VOD peers with higher trust levels (eg, VOD peers that contain superclusters).

  [101] Each entry of the tracking index includes a "content reference ID" or "CRID". The CRID serves to uniquely identify an associated event (and / or distinguish between related content objects or components thereof) according to which one or more content objects have been published. In one embodiment, each event entry may occupy multiple rows of the tracking index.

  [102] For example, the first row of each entry may include a “core CRID” (described below). The core CRID identifies a particular version of a content object (eg, the movie “Aladdin” published by Disney) for each VOD peer in a particular “leaf” cluster (or, in one embodiment, each “master” VOD peer). Only) with IP addresses. A particular “leaf” cluster stores a copy of the tracking file associated with that content object. The follow-up should include the same core CRID and the IP address of a similar VOD peer in another “leaf” cluster.

  [103] Accordingly, higher confidence level VOD peers, including superclusters, can store the tracking index. The tracking index has a plurality of rows that correlate to each sub-cluster in which the event was published. In addition to these core CRID lines that identify the VOD peer that stores the copy of the associated tracking file, additional lines should include the other components of the CRID described below, along with the components of the core CRID itself. It is.

  [104] In one embodiment, the core CRID consists of two fields that together uniquely identify the version of the content object. The first field is a “publisher ID” that uniquely identifies the publisher associated with the event. The second field is an “event selector” that uniquely identifies the published content object for the publisher. For example, if Disney publishes the movie “Aladdin” on the network, the event selector should uniquely identify that version of Aladdin. This level of granularity can be correlated to, for example, the level at which a user can select content objects to be displayed on demand.

  [105] However, other components of the CRID serve to further identify the events whose content objects have been published accordingly. For example, to deal with a user who wants to see Disney's Aladdin "Trailer", the movie can be distinguished from the trailer while other fields share the same core CRID in common. Depending on the embodiment, movie and trailer publications may constitute a single event or multiple separate events.

  [106] In one embodiment, the CRID includes, in addition to the core CRID, three other “descriptors” that further describe the event. The first descriptor includes a “publication zone” field (eg, city or zip code) that identifies the area from which the publication originates, as well as a “publication rights” field that indicates where the content object can be published. (For example, a range of zip codes). This publication rights field can, of course, include multiple entries that include discontinuous areas (eg, Los Angeles and New York).

  [107] The second descriptor facilitates the ability of the system to predict the popularity of a particular event (eg, by pushing more copies of published content objects to some or all clusters) It is a “publisher descriptor” that provides information about the publisher. Publisher descriptors attempt to generally classify content published by the publisher and the “publisher priority” field, which can distinguish Disney from smaller and less popular publishers (eg, private content, live broadcasts, Including "Publisher Category" field).

  [108] Finally, an “end descriptor” includes a single field that serves to distinguish and provide supplemental information for events that include related content objects. For example, the value of this field may be a movie (“00”), its metadata (“01”, text containing information about the movie, such as title, category, release date, etc.) as well as text, graphic, video, or other It can be distinguished from other related information in the form), or “additional assets” (related to “02”, trailers, storyboards, director notes, etc.)

  [109] Depending on the embodiment, these related assets may be considered part of a single content object or separate content objects, and these related assets may be considered as a single event or as separate It can be published as an event. Thus, CRID can serve to distinguish different related events, or simply to identify related content objects (or their components) at different levels of granularity.

  [110] In one embodiment, the tracking index is maintained only by VOD peers with relatively high confidence levels (eg, associated with a super cluster). As described in more detail below, when a content object is published, the event is “up” to a VOD peer that is sufficiently reliable to maintain a tracking index (with respect to that event and other events). Initiate the propagation of "sideways" requests to other similarly highly reliable VOD peers that still maintain a copy of its tracking index (eg, managing other superclusters).

  [111] As noted above, this tracking index is also used by other less reliable VOD peers (eg, managing “lower level” superclusters) and fewer entries (only its subclusters). Can be layered in that a copy of the tracking index can be maintained. In addition, this tracking index can also contain only “distributed” IP addresses of “adjacent” VOD peers with only entries related to content objects published within that sub-cluster and possibly associated tracking files. You can also

  [112] To facilitate network communication for various functions including, for example, tracking index and tracking file search (eg, when a VOD peer makes an on-demand request to display a content object), a bit string “ “Identities” is used to identify nodes on the network (eg, IP addresses of VOD peers, publication nodes, or VOD support servers) as well as content objects. For example, when locating a tracking index using references to various VOD peers with associated tracking files, it is more desirable to locate a sufficiently “close” tracking file (and sometimes maintain a sufficiently high QoS) Is necessary for). Alternatively, a group of packages may be obtained from a VOD peer that is “too far” and not received in a timely manner sufficient to maintain the specified QoS.

  [113] For example, by utilizing these bit string Identities between two VOD peer nodes, a virtual Internet distance function that essentially represents the QoS that can be expected between the two VOD peers can be calculated. In one embodiment, Identities can be assigned based on known Internet infrastructure information along with geographic information obtained from IP addresses and standard IP location services in the first example.

[114] To calculate the internet distance between two VOD peers, the XOR of the Identity of those VOD peers can first be taken and the result interpreted as a binary number. This number can then be adjusted based on information previously determined from dynamic monitoring of network traffic, such as cluster IDs, confidence values, and other statistical results described in more detail below. The resulting internet distance can be calculated relatively quickly, but a candidate VOD peer is selected from this larger list (eg, from the tracking index) and an appropriate request (eg, of the requested content object's package). Can be used to propagate the tracking file used to locate the group).
C. Publication and push of content objects

  [115] As noted above, before a content object can exist on the network of VOD peers, it must first be published by a publishing node, such as the publication server 16 of FIG. Each published server includes VOD publishing software that performs a publication process with a distributed cluster controller residing at a VOD peer. As noted above, this process splits the published content objects into groups of packages and propagates a certain number of copies of these groups of packages to various VOD peers throughout the network ( Associated tracking file and tracking index generation and update).

  [116] The publishing server can be anywhere in the network (eg, its publication zone can be in Colorado) so it is not “near” the area where the content object is published Note that there may be cases (eg, publishing rights may include New York and Los Angeles). In one embodiment, the publication server first generates a CRID (described above). The CRID includes relevant information about the publisher and published content objects, including a main descriptor, publisher descriptor, and end descriptor.

  [117] Next, the publication server attempts to find a “publication announcer” that is relatively “close” (eg, at internet distance) to an area included in the publication right (eg, New York and Los Angeles). The first publication announcer “announces” the event (including the transfer of CRIDs) to other publication announcers. Other publication announcers will select a given “master” VOD peer to manage the publication process and ultimately distribute a copy of the published package of content objects to the selected VOD peers.

  [118] For example, the publication server knows a few VOD support servers by default and can contact one of these. The VOD support server can forward this “announcement” (including CRID) to a known relatively highly reliable VOD peer in New York. The New York-based VOD peer (initial publication announcer) can forward the announcement to a known and very reliable VOD peer (secondary publication announcer) in Los Angeles.

  [119] Each of the publication announcers (two in this example) selects one or more “master” VOD peers (“publication masters”) that manage the publication process. Each cluster controller of these publication announcers already has predetermined general network traffic information (eg, network “load”) as well as information about potential candidate VOD peers (eg, its cluster ID, trust level, etc.). There is a case. These candidate VOD peers can also be queried to obtain additional information (eg, the amount of “free” hard disk space that can be used to store a group of content object packages).

  [120] Using this information, the cluster controller in each publication announcer each selects one or more publication masters that manage the publication process (and forward the announcement). Typically, these publication masters have a relatively high trust level (eg, level 4 of 16 levels), but the trust level may vary from cluster to cluster. For example, some publication masters may have a trust level 3 while others may have a trust level 4 due to differences in the estimated sizes of their respective clusters. Such information can be estimated by a publication announcer based on the number of known VOD peers with similar high trust levels as well as uniquely known Internet infrastructure information (eg, known to all VOD peers). .

  [121] Each publication master is responsible for managing publications within its particular domain (eg, cluster, sub-cluster, etc.) upon receipt of the CRID. Initially, each publication master “predicts” the popularity of published content objects based on various information available from the CRID as well as information previously obtained from dynamic monitoring of network traffic over time. For example, certain behavior assumptions (e.g., based on previous requests in this cluster for similar titles and categories as well as cumulative requests), information based on certain facts (e.g., publisher, date the content object was published, As well as other information available from the CRID).

  [122] Based on this “predicted” popularity, the cluster controller in each publication master sends “requests of interest” to the publication server (or, in another embodiment, indirectly to the publication server via the publication announcer). Communicate). When accumulating these various interest requests, the publication server determines the appropriate size and number of packages that must divide the published content object.

  [123] In one embodiment, the publication master creates a tracking file that tracks the location of the VOD peers that will ultimately store the groups of packages as they are distributed during the remainder of the publication process. In addition, these publication masters also create a tracking index that correlates the CRID to the VOD peer that stores a copy of the tracking file associated with that CRID.

  [124] In one embodiment, each publication master contacts its publication announcer using a “collection” request. In response, the publication announcer communicates with each other and contacts the publication server to specify a tracking index as well as a “collector” to “collect” a package of content objects for further distribution. The collector then distributes the tracking index and package to other publication announcers. This process usually requires little optimization due to the small number of publication announcers, but distributed techniques can be used if necessary to minimize network traffic.

  [125] The publication announcer determines the first group of packages for that publication master (ie, for storage as a group on a single VOD peer) and distributes these groups of packages to the publication master . For example, in one embodiment, only four groups of packages may be necessary to achieve sufficient QoS in a regular cluster. This grouping can of course be adjusted dynamically over time by the cluster controller within a particular cluster. For example, if the popularity of a given content object decreases over time (eg, based on a tracked on-demand request pattern), groups of packages can be combined to reduce copying (eg, others over time) Can be overwritten by a group of content object packages). Similarly, when popularity increases, the group of packages can be further divided, and more copies can be generated and distributed.

  [126] Each publication master pushes "down" a copy of that group of packages to other VOD peers (usually of the same or lower confidence level) based on their determined level of interest ( Propagate further). In addition, the publication master creates and / or updates a tracking file that correlates the CRID with the VOD peers selected to store a copy of this group of packages.

  [127] Note that the remainder of this push process can be relatively centralized, but can be distributed as much as necessary to facilitate efficient communication. For example, the cluster controller in each publication master can determine the number of copies of that group of packages to be distributed, its previously determined interest requests as well as other information (eg, a group of packages can be “early” of the content object. If it occurs, it can be determined on the basis of more copies). The publication master contacts the VOD peers directly to determine which VOD peers have extra capacity to store a group of packages, and then identifies that group of packages with its updated tracking file. Can be transferred directly to each such VOD peer. Alternatively, in another embodiment, the publication master communicates with its “neighboring” VOD peers using standard distributed propagation techniques (both distribution of packages and possibly tracking files). Only a few selected “neighboring” VOD peers can communicate.

  [128] However, ultimately, one or more copies of each group of packages are distributed (pushed) across the VOD peers in each "leaf" cluster (in the area defined by the publication rights). ). In addition, a tracking file (which is replicated in its entirety for each cluster or is layered in a distributed manner), in one embodiment, on each publication master as well as one or more of the published content object packages Stored on each VOD peer that stores the group. The tracking index is maintained on the publication announcer and possibly also on the publication master.

  [129] The publication node can be turned off once the publication process is complete. In one embodiment, 24 hours is allowed for the first publication, but a normal event may only require 20 minutes.

  [130] Information related to publication events (eg, metadata contained within a CRID) can also be distributed throughout the network, eg, each VOD peer has its users to reflect the availability of published content objects. Allows updating the interface. Standard distributed propagation techniques can be used. However, depending on the embodiment, different information can be made available from different VOD peers.

  [131] For example, VOD peers outside the area defined by the publication rights may not be notified of the event (users of such VOD peers have the right to access such content objects. Because not) In another embodiment, those VOD peers may be informed of the fact within their user interface, possibly using a mechanism that acquires rights to the content object (eg, “pay per view”). .

  [132] Other VOD peers may have sufficient rights, but may not be “close” to the content object to receive the pushed content object while maintaining a relatively high QoS. That fact can also be reflected in the user interface (eg, using text, colors, or other visuals, or other identifiers). For example, an almost immediately available content object (T0, eg, within a few seconds on average ranging from 1/2 second to 12 seconds from the user's request) can be color-coded with “green”. it can. Other content objects that are not within an Internet distance sufficiently “close” to the VOD peer that stores that group of packages may not be as readily available (T1 over 1 minute, eg, 30 seconds to 5 May not start over a minute range), it can be color coded in “yellow”. Yet another content object may not be available on the network when requested (T2), but its metadata can be made available for search purposes and is probably color coded “red” The Such a request can be delivered to the requesting user's VOD peer and trigger a "pre-order" that results in a delay of as much as 24 hours before being stored there.

[133] Note that other ancillary types of content objects, such as advertisements, can be pushed to the VOD peer in a similar manner. Such advertisements (in text format, graphic format, video format, or other formats) can be related to content objects with varying degrees of granularity. For example, promotions can be associated with individual content objects, or targeted to specific categories of content objects (eg, movies with a G rating). Alternatively, even a specific geographic area can be targeted. In one embodiment, such targeting information can be “matched” with information contained in the CRID (eg, in a tracking index). Relevant promotions are similar or “related” to VOD peers requesting such targeted content objects (or, in another embodiment, for example using well-known collaborative filtering techniques). Delivered to the VOD peer requesting the content object).
D. Pull content object

  [134] After pushing various content objects to VOD peers in a cluster across the network and updating the associated VOD peer user interface, all users turn on the content objects via the VOD peer user interface. Can be selected on demand. FIG. 4 shows an embodiment of a regular cluster 450 of VOD peers. In this embodiment, a content object is published and four groups of 20 packages of that content object are dynamically pushed to the selected VOD peer, and these groups are then subsequently pushed by any VOD peer in the cluster. It can be pushed to watch on demand while maintaining high QoS.

  [135] Many of the VOD peers in cluster 450, such as VOD peer 460, of course, do not store any of the group of packages for that content object. Other VOD peers, such as VOD peer 470, store a copy of the first group “A” 410 that includes the first four packages 1-4 (eg, the first minute) of published content objects. Similarly, other VOD peers store a copy of group “B” 420 and / or group “C” 430 containing the next 12 somewhat larger packages 5-16 of the content object in an alternating fashion. (This alternating form allows higher bandwidth retrieval, as noted above, because successive packages can be pulled in parallel from multiple VOD peers).

  [136] Although a VOD peer can store multiple groups of packages of the same content object, one benefit of grouping packages is that multiple VODs for faster (parallel) retrieval. Note that it will be possible to distribute them across peers. Thus, other VOD peers in cluster 450 are likely to store a copy of the last group “D” 440 that includes the remaining four larger packages 17-20.

  [137] As noted above, the size of earlier packages of content objects, such as packages 1-4 in group "A" 410, is typically smaller than later packages. This is due to the importance of pulling these packages more quickly (eg, to start a movie immediately). In one embodiment, a larger number of copies of these initial packages are also stored, resulting in faster access times as well as higher redundancy. If the movie begins to play and the package is buffered, a longer time is available to retrieve (pull) subsequent packages of the requested content object. Thus, a relatively longer extraction time is allowed.

  [138] As also noted above, the proper sizing and grouping of content object packages and the number of copies of such packages stored throughout the VOD peers in a particular cluster can vary in various information. Based. This information includes static information from the CRID and dynamic information obtained by monitoring network traffic and tracking request patterns over time. Such information can reflect the predicted popularity of content objects (generally and within a particular cluster) as well as current network congestion, relative access times, and other related network traffic statistics.

  [139] The requesting VOD peer 475 has currently buffered groups “A” 410 and “B” 420, possibly playing the first part of the content object, and groups “C” 430 and “D” ”Is shown as waiting for 440. A cluster controller in VOD peer 475 (or a publication master assisting in the pull process) cannot arrive in time (eg, package 5 in group “B” 420, for example, group “C” 430 is delayed). If it is detected (before playback begins), an alternative arrangement may be necessary.

  [140] In one embodiment, multiple requests are made per group of packages just to provide redundancy in such cases. In another embodiment, if a problem is detected, a request can be made to an alternate VOD peer that stores other copies of the desired group of packages. In another embodiment, if an issue is not detected in sufficient time to allow delivery from such an alternate VOD peer, an “urgent” request is sent to the higher confidence level VOD peer. If an alternate VOD peer from another cluster can satisfy the request more quickly (eg due to a faster response time of a more reliable VOD peer) There is.

  [141] Now, moving on to the steps used in the pull process itself, the user of the VOD peer can select a particular content object for retrieval from the list of content objects available on demand via the user interface. You can choose. The requesting VOD peer, in one embodiment, first requests for such content objects by checking the CRID associated with the requested content object against its own tracking file for a hash value match. To start. If unsuccessful (usually unsuccessful), the request (including the CRID) is propagated to the known “neighboring” VOD peer and then “up” to the VOD peer with the next highest level of trust. "High level" (e.g., trust level 2 out of 16 trust levels) VOD that is propagated and ultimately has a tracking index that has a match for all published CRIDs (in one embodiment) Propagated to peer.

  [142] When this request is propagated to such a VOD peer, this request happens to be received by a VOD peer that stores one or more groups of packages of content objects identified by the CRID. In some cases, the CRID may match the hash value in the tracking file. In that “lucky” situation, the tracking file identifies one or more publication masters, which in one embodiment are utilized for a more efficient pull process.

  [143] In the more general case, the request is a tracking index that identifies one or more publication masters based on the publication master (also having a copy of the associated tracking file with a “hash” match) or matching CRID. Continue to propagate "up" until one of the VOD peers with a copy of is reached. If the desired content object does not exist in the same cluster as the requesting VOD peer, a “bottom-up” search followed by a “top-down” search is required to locate the “closest” tracking file. There is a case. Only when a sufficiently high confidence level is reached, a tracking index or tracking file is found ("bottom up"). In that regard, the layered nature of the tracking file allows a “top-down” search to locate a tracking file that identifies the VOD peer “relatively” (but not in the same cluster) to the requesting VOD peer. You may need it.

  [144] In any case, in this embodiment, one or more publication masters are ultimately identified, and the “closest” publication master is determined, for example, by utilizing an internet distance function for various candidates. The In another embodiment, all publication masters store a group of packages that represent at least the first part of the content object (eg, the first 15 seconds), which allows a relatively immediate initial playback. To be removed (giving additional time to spill out subsequent groups of packages).

  [145] Once the “closest” publication master is determined, the cluster controller uses the tracking file to make requests for various groups of packages to the associated VOD peers identified by the tracking file. Start. Such requests can be made in parallel or can be prioritized based on the linear progression of the content objects (eg, requesting an earlier group of packages first). Standard distributed propagation techniques can be used to offload these requests to “adjacent” VOD peers.

  [146] In another embodiment, the requesting VOD peer that identified the tracking file simply requests a copy of the tracking file (possibly starting playback) rather than using the publication master as a proxy. In order to be able to request different groups of packages on their own (after receiving the first group of packages). In this case, the requesting VOD peer can request various groups of packages directly from the VOD peer identified in the tracking file, or offload these requests to “adjacent” VOD peers. Distributed propagation techniques can be used for this purpose.

  [147] Internet distances to various VOD peers (which store a group of requested content object packages) in the same cluster as the requesting VOD peer are pre-determined to meet QoS requirements. Since (based on previous dynamic monitoring of network traffic), it is very likely that a group of packages will arrive at the requesting VOD peer in time to maintain the specified QoS. The requesting VOD peer uses its “free” storage space to buffer groups of packages and display them to the user. As noted above, in one embodiment, a predetermined amount of storage capacity (eg, 4 GB) is dedicated to this buffering / playback aspect of the pull process, and the remaining capacity (eg, 6 GB) Used for shared storage of a group of content object packages for requesting VOD peers.

  [148] If a problem occurs “on the way” (eg, due to a software or hardware failure at one of the VOD peers specified in the tracking file) Publication master (eg, when no response is received within a given time, or when receiving a response that is too late) or requesting VOD peer (eg, when the “buffer” of the received package falls below an expected threshold ). In either case, the publication master is notified and usually multiple copies of a group of packages are stored in the same cluster. As such, the publication master can initiate a request to one or more other redundant VOD peers (of course, if such a request has not yet been made). In the case of “emergency”, a VOD peer (possibly a VOD support server) that has a relatively high trust level to route requests to another cluster for faster rerouting of a given group of packages Even contact). If the problem is detected long enough, the requesting VOD peer may not even know that the problem has occurred.

[149] As noted above, in some cases, the desired content object is not only available immediately, but is not available anywhere on the network. This fact can be reflected in the user interface (eg, as a “not found” result for a search). In one embodiment, with the possible option of requesting a “pre-order” that can result in an automated (or manual) search for content objects. Upon the event of its subsequent publication to the network, the requesting user can be notified after the desired content object is available (in its entirety at the requesting VOD peer or within the cluster). Either pushed to other VOD peers).
E. Network-based QoS (NQoS) and dynamic monitoring of network traffic

  [150] Over time, this push process is repeated as new events occur and content objects are added to the network. The pull process occurs when the user initiates an on-demand request to display available content objects (perhaps much more frequently). However, the basis for both push and pull processes is performed continuously or at least on a periodic basis to maintain a relatively high QoS level with a high degree of predictability. Network traffic dynamic monitoring.

  [151] As implied above, the QoS experienced by VOD peers making on-demand requests can be determined in advance in many respects. By dynamically monitoring network traffic (on a distributed basis using standard distributed propagation techniques), a certain size within a certain amount of time from neighboring VOD peers (eg within a cluster) QoS can be effectively incorporated into the network in that the ability of the VOD peer to receive the file can be determined before any request.

  [152] The results of this dynamic network monitoring can then be used to increase the QoS level (eg, by changing the trust level and redeploying the content object package). The raised QoS levels are both within one cluster and across intercluster and supercluster boundaries (including redefining cluster and supercluster membership). Then, during the subsequent pull process (when the publishing server adds a new content object to the network) and during the push process (when an individual VOD peer makes an on-demand request to display the content object) Inform NQoS and rely on it.

  [153] The trust level of a VOD peer is one way to inform the entire network of NQoS. Another method is cluster membership of VOD peers, with neighboring VOD peers (of varying trust levels) becoming known over time, and via cluster ID. In addition, when a package of content objects is deployed (eg, during the push process as well as in response to on-demand requests), VOD peers can be at various QoS levels (eg, relatively immediately or more than 1 minute) Be informed about the availability of such content objects (with a delay).

  [154] The cluster controller in each VOD peer uses, on an ongoing basis, in one embodiment, for example, the cluster controllers of other VOD peers (both inside and outside the cluster) as well as standard distributed propagation techniques. Thus, by communicating with a known network node (eg, a well-known ISP), a given communication can, of course, be periodic or triggered by other events.

  [155] As noted above, in one embodiment, when a VOD peer is initialized (or re-initialized, eg, after a software or hardware failure), within a particular cluster Its VOD peer membership is determined based on publicly available information about the physical infrastructure of the Internet, along with geographic information obtained from IP addresses and standard IP location services. In that regard, VOD peers know about a few relatively very reliable VOD peers (possibly even one or more VOD support servers) as well as several neighboring VOD peers with similar “default” trust levels. Is done.

  [156] Since that time, the cluster controller of each VOD peer performs certain tests to monitor and detect changes in network traffic patterns (eg, the path between adjacent VOD peers is due to network congestion. Or when it becomes more reliable or less reliable over time due to VOD peers and other Internet node failures). In addition, the cluster controller also monitors and detects changes in the deployment of content object packages (eg, when a new content object is pushed to various locations or when an on-demand request is sent to a particular content object and its When done about categories).

  [157] By tracking and accumulating the results of such changes in the overall network traffic flow between VOD peers as well as the deployment of content object packages over time, the cluster controller takes advantage of such results. Thus, in one embodiment, the confidence level factors described above can be changed. Changes in these trust level factors result in changes to the trust levels of various VOD peers over time. The result is transmitted like ripples across the cluster boundary and the super cluster boundary.

  [158] For example, one common test can be a periodic “ping” to a well-known server near an Internet backbone router that should normally exhibit a high level of stable and reliable bandwidth. . The cluster controller can ping the Yahoo or VOD support server every hour. Another ping test can be performed for a few known adjacent VOD peers in that cluster, or even for VOD peers in a “remote” cluster. The results of such ping tests (eg, long, short, and average ping times and occasional ping “failures”) accumulate over time and differ due to the level of reliability as well as “network load” (E.g., a longer ping time during an early evening "prime time" time).

  [159] In other tests, actual file transfers of various sizes to various Internet distance locations can be used. The ability of a VOD peer to transfer a certain size file to one or more of its neighbors within a certain time interval is clearly important. This is because this capability is directly related to aspects of the pull process. The pull process may need to be executed in response to an on-demand request for a content object that includes a group of packages that the VOD peer is trying to store in its “shared” hard disk space.

  [160] The results of these tests are then accumulated over time. In one embodiment, maintain a confidence level factor for the VOD peer, such as the probability of “fast” delivery to a relatively local VOD peer during high load times or the probability that the VOD peer will remain online for the next 500 hours Used to. As noted above, these trust level factors (after being parameterized for various regional areas, eg intra-cluster, super-cluster, etc.) determine the trust level of each VOD peer and change over time. Used for

  [161] In one embodiment, these changes in trust level can also result in redeployment of a group of packages of content objects. For example, if the trust level of a VOD peer falls below a certain threshold, move one or more groups of packages stored in that VOD peer to neighboring VOD peers and update the associated tracking file accordingly Then you can decide.

  [162] At the supercluster level, the cluster controller, in one embodiment, extends its test across cluster boundaries and supercluster boundaries. As a result, these cluster controllers can expand the size of the cluster by adding a VOD peer to that cluster, or perhaps by combining two smaller clusters together into a single cluster. . These cluster controllers can also change the trust level of the VOD peer across the cluster, e.g., increasing the trust level of the VOD peer that has shown higher reliability over time in file transfers across cluster boundaries.

  [163] Perform “global” tests to detect dynamic changes in network traffic patterns over time and affect trust levels and cluster membership (and possibly redeploy a group of content object packages In addition to using the results of such tests, the cluster controller in each VOD peer also monitors and tracks “actual” network traffic including deployment of content object packages. For example, as noted above, the cluster controller determines which VOD peers must store a group of packages and associated tracking files when a new content object is added to the network. Rely on these updated trust levels and cluster IDs (and “free” hard disk capacity) during the push process. This dynamic network traffic is also monitored when an on-demand request is made and a group of packages is pulled from various VOD peers for delivery to the requesting VOD peer.

  [164] For example, if it is determined that an unusually large number of requests have been made for a particular content object, more copies of that content object are required to maintain the level of QoS within a particular cluster It may become. In one embodiment, the cluster controller in the publication master has an additional copy of the group of packages of its content objects stored on other VOD peers in the cluster, and the associated tracking file is updated between these VOD peers. Can be propagated. As a result, when a smaller number of such requests are encountered, the existing copy of the group of packages can be designated as “possible” to be overwritten, while the existing tracking file is updated accordingly.

  [165] Finer “tuning” can also result in a revised grouping of packages, for example. As content objects become less popular, multiple groups of the package can be merged into a single group. Conversely, a group of packages can be further divided into additional groups when the popularity of content objects increases. In addition, if certain VOD peers are determined to be substantially “weak links” (in that they do not maintain normal QoS levels during the pull process), The VOD peer's trust level can be lowered and the group of packages stored there can be redeployed.

  [166] In one embodiment, cumulative information, such as the popularity of a particular category (eg, comedy) of content objects within a cluster, may also arise from monitoring actual on-demand requests. Such information can be used, for example, during a subsequent push process associated with the publication of a new comedy content object. More copies of the content object's package can be pushed into the cluster than would otherwise be.

  [167] Even relatively local information can be used to increase bandwidth and thus QoS. For example, as shown above with respect to FIG. 4, two groups of packages can be “interleaved” between multiple adjacent VOD peers. Thus, every other package (eg, P1, P3, P5) can be stored on one VOD peer and the other package (eg, P2, P4, P6) is stored on an adjacent VOD peer. . This can result in increased bandwidth to the requesting VOD peer. Therefore, QoS within the cluster can be effectively increased at least for that particular content object.

[168] Many other attributes of network nodes and network traffic other than those mentioned above can be dynamically monitored and tracked over time. Whether implemented manually or in an automated form, the feedback loop can allow such attributes to be fine-tuned based on the impact of such attributes on QoS. In some cases, the additional network traffic imposed by the monitoring activity itself may outweigh the benefits achieved by tracking certain attributes. However, over time, the system can reach some form of homeostasis. In this state, a relatively optimal set of attributes is dynamically monitored and tracked to maximize the overall NQoS.
II. Details of the embodiment

  [169] In order to better understand how the key concepts described above can be implemented, the dynamic process used to monitor content object publishing, retrieval, and access in the VOD system of the present invention. Along with the description, the main data structure is described below and the communication protocol used by the VOD peer is also described.

  [170] For example, all VOD peers are relative to each other so that VOD peers generally identify each other, access each other, and more specifically identify relatively reliable neighboring VOD peers. Includes a unique “node ID” that allows to determine proximity and reliability. Such “trusted neighbors” can rely on accessing content objects in a distributed manner while maintaining NQoS.

  [171] Just as each VOD peer is uniquely identified via a node ID, each content object, or more specifically, each event that exposes a content object, has a "CRID" (content reference ID, Uniquely identified via). The CRID specifies the geographical and other restrictions on access to the content object and the metadata that describes the content object and metadata that allows the user to browse and search the content object. It can be so.

  [172] As noted above, when a content object is published (ie, an event occurs) and its component packages are distributed among VOD peers, the various tracking files are distributed in a distributed fashion. Generated and associates a CRID representing that content object with a VOD peer that stores a particular group of such component packages. These tracking files indicate the current location of the various copies of each content object's component package, for example when a copy is overwritten or additional copies are generated due to changes in user viewing behavior or network characteristics. Also updated to reflect. Embodiments of these tracking file data structures are described below along with their corresponding tracking index data structures.

  [173] Just as tracking files are generated and maintained to maintain the location of the content object's component packages, corresponding tracking indexes are also generated to locate the VOD peers that store copies of these tracking files. Maintain (whether centralized or distributed). For example, when a user requests access to a particular content object, the CRID representing that content object retrieves a tracking file stored in a VOD peer that is relatively close to the requesting VOD peer (directly or Used either indirectly via tracking index).

  [174] In addition to these key data structures, the manner in which VOD peers communicate with each other is also described to show how key dynamic network processes are implemented. For example, a predetermined communication protocol is used to publish content objects over the network, announce events between various VOD peers throughout the network, and then component packages and corresponding tracking files and Generate and distribute (ie, push) tracking indexes.

  [175] When a user requests access to a content object (eg, to watch a movie), other protocols are used to search and download (ie, pull) the content object's component packages. To do. The protocol is different “feeders” in a timely manner enough to allow searching of tracking indexes and tracking files, followed by relatively immediate and continuous viewing of the content object “on demand”. Initiating component package downloads from VOD peers.

  [176] In addition, these communication protocols can be combined with system architectural components to provide relative access times between VOD peers, actual user behavior (eg, one or more geographical locations during a particular time interval). NQoS is maintained by monitoring various aspects of the network, including increased demand for viewing certain content objects in the area, and other network characteristics (eg, network failures). By dynamically monitoring such factors, the user can be informed about the state of the system even before requesting access to a particular content object.

  [177] For example, when a user is browsing or searching for content, the user interface may allow one particular content object to be available substantially immediately while another content object It may reflect the fact that it may need to be downloaded (eg, by displaying the title of the respective movie with colored “green” or “red” text). This is possible because the current system state is known as a result of such monitoring and can be communicated between VOD peers in a distributed manner. In addition, another user (eg, in a different cluster) may encounter a different display. This indication is likely that both content objects are readily available (eg, relative proximity of a copy of a given component package of such content objects, or more rapid between related adjacent VOD peers. Network response time, or due to a combination of these and other factors).

[178] To implement these communication protocols, a basic set of messages is used, many of which are used for multiple different communication scenarios. For example, a basic message may contain two messages, whether the communication involves publishing a content object, searching for a tracking file to view a desired content object, monitoring network behavior, or some other purpose. Used whenever a VOD peer performs an initial “handshake” to establish further such communication. Other “extended” messages are used for certain purposes, as described in more detail below.
A. Node data structure and content data structure Node ID

  [179] Turning to FIG. 5, one embodiment of a "Node ID" data structure 500 is shown. Note that the values are listed in alphanumeric form for ease of illustration. “Position” 505 represents a byte of continuous data. The entire node ID 501 itself is shown in multiple lines as a string of consecutive bytes, each component of which is disassembled in a subsequent sequence. Of course, the actual data storage efficiency can be increased by using a more compact standard form of representation, including standard compression techniques.

  [180] Node ID 501 represents a unique VOD peer and includes various attributes of that VOD peer, such as a unique identifier and other static and dynamic components. These components of node ID 501 include two categories: a “fixed” portion 510 that includes attributes of VOD peers that are unlikely to change as often as they change, and network status or user behavior over time. It can be categorized into a set of “descriptors” 550 that include inter-network continuity that can change dynamically as it changes.

  [181] Among the fixed components 510 of the node ID 501 is a unique “box ID” 512. In the illustrated embodiment, box ID 512 is a unique 9-byte identifier that distinguishes this physical VOD peer hardware device from all other hardware devices. In addition to being a single unique identifier, the components of box ID 512 can further identify the hardware manufacturer, model, and version (not shown). In addition, by being unique, the box ID 512 remains associated with this VOD peer with an attribute (even if it is not part of the node ID 501), for example, while other attributes may change. Can be made possible. This can be useful in security, firmware upgrades, mobile applications, and various other situations.

  [182] Another fixed component is the "country" 514 where the box is located. In one embodiment, this value is illustrated as a 2-byte field, but can represent the country in which the box is deployed, as determined, for example, when the box is first powered on. This value can remain fixed by default (eg, during a subsequent “power on” event), but can be changeable, for example, if the box is transferred to another location. .

  [183] Another fixed component is the "region" 516 where the box is located. In one embodiment, this region 516 is a three-byte identifier that represents a unique region within country 514. Various standards organizations have developed standards for specific national regional identifiers. For example, within the United States, individual state identifiers can be used (although larger census territories, such as “Pacific” in California, Oregon, and Washington, can be used). Other countries may have different designations other than states, such as Canadian provinces and territories (eg, Alberta AB). In one embodiment, different standards are used across different countries, but region 516 is included in country 514 and city 520 (described below) is included in region 516.

  [184] Another fixed component is the "ISP" 518 or Internet service provider through which the box obtains Internet access. In one embodiment, ISP 518 is a 4-byte identifier that represents the current ISP being used. Although the user is unlikely to change the ISP frequently at a given location, moving the box to another location (temporarily or otherwise) may likely result in a change of the ISP 518. is there. This information can be used, for example, to identify a group of VOD peers that share a potentially faster or more reliable connection (eg, due to a common ISP or multiple clearly connected ISPs). Can be used.

  [185] As noted above, city 520 is another fixed component, which in one embodiment is a 3-byte value that identifies an area within region 516 (which is within country 514). Because the city is relatively common, the city 520 is usually unique within the region 516, but other fields may serve to further distinguish this region (eg, the zip code 522 described below). And / or longitude / latitude 524). Note that these geographic fields (country 514, region 516, city 520, zip code 522, and longitude / latitude 524) can be used with ISP 518 for a variety of purposes. As noted above, these facilitate the identification of groups of VOD peers that can share faster or more reliable connections (and thus can be part of the same cluster). In addition, such fields can be used to restrict access to specific content objects (eg, constrain to specific states within the United States) or content between VOD peers within a specific geographic area. Behavioral usage patterns that can result in altered distribution of objects can be identified (eg, comedies that are more prevalent in certain geographic areas). Virtually all network characteristics, behavioral characteristics, or other characteristics that are monitored can be used with this geographic information to re-deploy a copy of a content object (or individual group of packages), trust level, or cluster membership Adjustments can be determined.

  [186] As mentioned above, the postal code 522 (shown as a 5-byte identifier in one embodiment) further serves to identify the geographic area in which the box is currently deployed. Standard zip codes can be used for this purpose, and different standards are used if required for a particular country.

  [187] As also mentioned above, longitude / latitude 524 (illustrated as a 16-byte identifier in one embodiment) further identifies the geographic area in which the box is currently deployed with greater specificity. . These geographic fields can be used together to more accurately identify specific geographic areas, or can be used individually for separate purposes (eg, very specific content access). To enforce restrictions). As noted above, net proximity can be determined at various levels of accuracy by using a standard IP location database that relies on some or all of these geographic identifiers to varying degrees. .

  [188] The last fixed component, node type 526, is illustrated in this embodiment as a single byte identifier that distinguishes between different categories of VOD peers. For example, publishers can be distinguished from dedicated VOD support servers as well as “normal” VOD peers. These distinctions do not necessarily have to be mutually exclusive, but may prove useful, for example, to quickly include or exclude certain categories of VOD peers. For example, certain functions, such as initiating a software upgrade or providing a certain fallback service in the case of a network “emergency”, can be limited to a particular category of VOD peers, such as a VOD support server. In such a case, the node type 526 can be relied upon to quickly identify VOD peers that satisfy the criteria.

  [189] Moving to descriptor 550, IP address 552 is illustrated in one embodiment as a 12-byte field that represents a standard routable IP address. The IP address 552 can be either static or dynamic and, of course, can change relatively frequently. Still, rely on this as a convenient means of identifying VOD peers for message exchange and other forms of communication (described in more detail below) during individual sessions or relatively short time intervals. Can do.

  [190] Other descriptors 550 may even change more frequently. This is because they reflect dynamic changes in network infrastructure, bandwidth, and reliability. For example, trust level 554 indicates a measure of the relative reliability of the VOD peer. The trust level 554 implemented as a two-byte value in one embodiment is based on various trust level factors (described above) that reflect characteristics such as bandwidth and reliability that are dynamically monitored over time. 16 different levels of “trust” can be distinguished. The trust level 554 can be used for a variety of purposes, such as determining cluster membership and accessible neighboring VOD peers and affecting the distribution and access processing of content objects and their component packages.

  [191] Two additional descriptors 550 are local node accessibility 556 and global node accessibility 558 (each in one embodiment a single byte value). These two fields indicate whether the local (router) port and the global (cluster) port (for example, on the Internet router in the home where the VOD peerbox is deployed) are open or closed, respectively. . For example, if the local port is closed (eg, the local node accessibility 556 has a value of “0”), the VOD peer is not directly accessible due to the firewall / NAT router and the VOD network Special indirect communication techniques (e.g., indirectly contacting via a VOD support server or adjacent "local" VOD peer) may be required to establish communication. If the local port is not closed, the current routable IP address 552 can be relied upon for such communications. If the global port is closed (ie, the global node accessibility 558 has a value of “0”), the VOD peer is not directly accessible outside its “local” cluster, but also with special indirection. Communication techniques may be required (eg, when an ISP loses connectivity with the entire cluster, this is likely to be very rare if it occurs). Both of these fields determine the form of communication that other VOD peers may need to communicate with a particular VOD peer (the value of these fields in the node ID 501 of the target VOD peer). Provide a relatively quick mechanism for

[192] Finally, the remaining descriptors or “net measurements” 560 are implemented in one embodiment as a two-byte field reflecting the current results of certain dynamically monitored factors. As noted above (as described in more detail below), each VOD peer's cluster controller (in one embodiment) is responsible for the overall network traffic and the deployment and use of content objects and their component packages. Behavior "Various tests are performed to monitor and detect changes in traffic patterns. These values reflect the results of such tests. For example, the cluster controller can maintain an average over time of a periodic hourly “ping” to a known stable server (eg, a VOD support server) close to the Internet backbone router. Such an average value can be used as one measure of reliability reflected in the net measurement 560 value.
2. CRID

  [193] As described above, each event that exposes a content object is uniquely identified by a content reference ID or CRID 600, just as each VOD peer is uniquely identified by a node ID. The data structure of this CRID 600 is shown in FIG. In one embodiment, CRID 600 is used, for example, in a tracking file to associate a published content object with a VOD peer that stores a copy of the component package of that content object. The CRID 600 is also used in the tracking index to associate a published content object with a certain VOD peer that stores a copy of such tracking file.

  [194] Similar to the node ID data structure 500 shown in FIG. 5, the CRID data structure 600 lists values in alphanumeric form for ease of illustration, but the “position” 605 is continuous. Represents a byte of data (which can, of course, be more efficiently represented using standard compression techniques and other data representation techniques). Again, the entire CRID 601 is shown in multiple rows as a string of consecutive bytes, and then each of its components is disassembled in a subsequent sequence.

  [195] CRID 601 represents a unique published event, for example, not only distinguishing one movie from another, but also distinguishing specific versions of that movie from different publishers, from the same publisher Even different forms of the movie can be distinguished (eg, a trailer, or perhaps even a widescreen version relative to a standard aspect ratio version, or a version with subtitles or a different first language, among other variations). The CRID 601 components are also a "core" CRID 610 that uniquely identifies two categories: publisher and event, and a set of "descriptors" 620 that contain metadata about access constraints and publisher and published content objects. And can be classified.

  [196] In one embodiment, the core CRID 610 has two fields: a “Publisher ID” 612 (identified as a 10-byte value in one embodiment) that uniquely identifies the publisher of the event, and an event from that publisher. An “event selector” 614 (shown as a 6-byte value in one embodiment) that uniquely identifies it. In another embodiment, the event selector 614 itself can be unique even across publishers. This core CRID 610 provides a relatively compact unique identifier for each event published on the network.

  [197] In addition to the core CRID 610, a set of descriptors 620 provides further information about the event. In one embodiment shown in FIG. 6, there are three descriptors: a “primary descriptor” 625 that outlines access restrictions associated with an event, and a “publisher descriptor” that further provides attributes associated with the publisher of the event. 635 and an “Exit Descriptor” 645 that provides predetermined attributes for the published content object associated with the event.

  [198] In the illustrated embodiment, the main descriptor 625 includes two fields: a “publication zone” 626 (eg, a 5 byte zip code) that identifies the area from which the publication originates, and a published content object. And “publication right” 628 (for example, a 10-byte range of the postal code) indicating that the user can access the URL. In other embodiments, multiple zip code ranges or other means of specifying one or more contiguous or non-contiguous geographic areas may be used. In addition, additional restrictions other than geographical restrictions can be utilized, such as access restrictions based on the user's profile, behavior, or substantially all other static or dynamic attributes.

  [199] In this embodiment shown in FIG. 6, publisher descriptor 635 includes two fields. The first of these is “Publisher Priority” 636, shown as a single byte that reflects not only the different types of publishers, but also the prioritized order within each such type. For example, most movie publishers can be assigned a default level of “2”, and “top publishers” (eg, of the most popular movies based on average demand) can be assigned a value of “1”. . Also, lower priority values can be assigned not only to “lower priority” movie publishers, but also to completely different types or classes of publishers, eg assigning a value of “9” to streaming content publishers be able to. In one embodiment, a “private” publisher can be assigned a value of “0” (eg, not low but high but considered unique) to allow a simple means of relatively quickly distinguishing publisher categories. You can even do it. In another embodiment, these different types of prioritization can be combined. The publisher descriptor 635 may also include a “publisher category” 638 (shown as a 2-byte field in FIG. 6) that can be used to identify the main genre of the content object normally associated with a given publisher. In an alternative embodiment (not shown), rather than using a “event category” field (eg, in a separate “event descriptor”) to categorize publishers, the content object genre is more distinct (eg, , "Per movie") can be distinguished on a basis. Such information is also stored (or exclusively) in a separate centralized “metadata DB” as described in more detail below and via CRID 601 (or core CRID 610). Can be associated.

[200] Finally, the “end descriptor” 645, in one embodiment, provides a single field or “content object type” 646 (eg, a 2-byte value) that distinguishes between different forms or types of content objects. It is accompanied by illustration. For example, a movie can be distinguished from its trailer or from other types of “extra” content normally found on many current DVDs. As noted above, the aspect ratio (eg, wide screen) or a different first language can also be a distinguishing factor. In addition, completely different types of content (eg, documentary, training video, educational video, user-generated streaming clips, etc.) can be the source of distinguishable categories of content objects. As noted above, additional “event related” information may be included in the “event descriptor” and / or separately in a centralized “metadata DB” accessible from VOD peers on the network. Can be maintained.
3. Tracking file

  [201] Turning to FIG. 7, some embodiments of a tracking file data structure 700 are shown. This tracking file data structure 700 maintains the location of a given VOD peer that stores a particular group of packages of published content objects (ie events), and such VOD peer location is the corresponding CRID that represents the event. Associate with. In one embodiment, a separate tracking file 700 is generated for each CRID representing an event, but in other embodiments (not shown), a single tracking file can contain multiple CRIDs (events). . Each entry may identify various VOD peers that store the component package of the content object associated with that CRID for a particular CRID.

  [202] As noted above, the tracking file 700 is generated and maintained in a distributed fashion. Thus, a copy of the tracking file 700 stored at a particular VOD peer is a subset of the VOD peer that stores a group of packages of published content objects (represented by the corresponding CRID) (eg, within a “leaf” cluster). , Only adjacent VOD peers). Other versions of tracking file 700 (eg, stored on a more reliable VOD peer) can represent a larger domain of VOD peers that store such groups of component packages. A group of component packages includes, for example, VOD peers in a larger “superset” cluster in addition to VOD peers in a “subset” leaf cluster. In one embodiment shown in FIG. 7, all of the component packages of a content object are described in each tracking file. As a result, there is no need to locate multiple tracking files in order to gain access to a particular content object.

  [203] Although shown in tabular form, the data in tracking file 700 is in a more efficient format including compressed hash tables, linked lists, and other standard low-level data structures and formats. Can be represented. In one embodiment, the first field of tracking file 700 identifies the number of groups of component packages (“package groups”) stored in separate VOD peers. For example, a content object may be divided into 100 separate component packages (fixed size in one embodiment, different sizes in other embodiments), and four separate package groups (eg, the first 10 "Package Group 1" containing one package, "Package Group 2" and "Package Group 3" each containing 20 subsequent packages, and "Package Group 4" containing the remaining 50 packages) Can be

  [204] In the embodiment shown in FIG. 7, in this field 710, the content object associated with the CRID that identifies the tracking file 700 includes three separate package groups, copies of which are stored in individual VOD peers. “3” is included. Following field 710 is, for each such VOD peer, the node ID of the VOD peer (or simply an IP address in one embodiment) followed by whether the VOD peer contains a copy of each package group. Entry. For example, following field 710 is an IP address 720 for “Node 1” followed by a value 725 for each of the three package groups indicating whether Node 1 stores a copy of that package group. For each remaining VOD peer that stores one or more of these package groups, a subsequent entry follows (up to the “final” entry 730). The number of such VOD peers can be specified by various means (not shown), such as separate fields or null values in the linked list.

[205] As noted above, the querying VOD peer initially performs a search for neighboring VOD peers based on the CRID corresponding to the desired published content object (event), and to that desired CRID. It may fail to locate the VOD peer that stores a copy of the associated tracking file directly. As described in more detail below, such a search first results in a VOD peer that includes a “tracking index” that indirectly references one or more VOD peers that store copies of such tracking files. There is a case. Furthermore, even when an associated tracking file is found, one or more of the VOD peers referenced in that tracking file cannot complete the download request (eg, device failure, network failure, overload bandwidth). Or due to some other problem), additional searches may be required.
4). Tracking index

  [206] As noted above, if a tracking index is identified before the associated tracking file is located, that tracking index is utilized to locate one or more associated tracking files. This tracking file is based on the CRID corresponding to the published content object (event) that the requesting VOD peer wants to download and view. As also noted above, the tracking index and the corresponding tracking file are generated when the event first occurs (ie, when the associated content object is first published). These files are generated in a distributed fashion, for example across clusters, from a “superset” down to a “subset” cluster, but not necessarily (for efficiency) to the level of each “leaf” cluster. It is not generated below. When changes are made in the deployment of content objects that contain component packages (and their groups), corresponding changes may also be required in these files (achieved in a similar distributed manner). . Such changes may come from a variety of different network-related causes and behavioral causes. For example, such changes may result from device failures, network failures, measured changes in network bandwidth, and increased and / or decreased demand for specific content objects within a general or specific cluster. There is.

  [207] One embodiment of a tracking index data structure 800 is shown in FIG. Similar to the tracking file 700 described above, a table format is used. The tabular format has data that can also be represented in a more efficient format including compressed hash tables, linked lists, and other standard low-level data structures and formats. As noted above, a separate tracking index can be generated for each CRID (event). Alternatively, as shown in FIG. 8, a single tracking index can include an entry for each such CRID (eg, for each event published within a particular cluster).

  [208] In FIG. 8, each row represents a particular event, starting with row 810 representing "Event A". Each subsequent row represents another event (up to a “final” row 820 representing “event N”). For each event, the first field identifies the CRID 815 corresponding to that event. This field is of course unnecessary if, for example, a separate tracking index is generated for each CRID, in which case the CRID can be used to locate that separate tracking index file (eg, Through a hash table). Each CRID entry includes a list of IP addresses (or node IDs) of VOD peers that store a copy of the tracking file corresponding to that CRID. The IP address of the VOD peer listed first is indicated by column 818, followed by the IP address of the subsequent VOD peer up to column 819, which represents the IP address of the “final” VOD peer. .

[209] Note that the number of VOD peers storing copies of the tracking file corresponding to a particular CRID (event) may vary from CRID to CRID. Also, if a particular VOD peer stores a copy of a tracking file, possibly associated with multiple CRIDs (stored as separate tracking files or as a single tracking file with multiple CRID entries) There is. Further, as noted above, in one embodiment, the number of different CRID entries in a tracking index may be higher with tracking indexes stored at more reliable VOD peers (eg, Identify additional VOD peers in various “subset” clusters).
B. Inter-node communication

[210] The node ID of the VOD peer, the content reference ID (CRID) of the event to which the content object is published, and a tracking index generated to maintain the distributed position of the group of component packages of such content object Described certain important data structures, including tracking files. Attention is now directed to the communication protocols and other means by which VOD peers communicate with each other (as well as with the VOD support server).
1. Initial handshake

  [211] In one embodiment, whenever two VOD peers communicate directly with each other (eg, via TCP without an intermediary acting as an application level relay), one acts as the “initiator” and the other as “ Work as a "responder". Then, if an initial connection is established, many of the remaining communication architectures can be symmetric.

  [212] This establishment of a TCP stream connection (TCP connection is used as an overlay network) is divided into separate phases. The initial phase or “Phase A” includes the preliminary activities necessary to discover the IP address and port used to establish the initial TCP connection. This is followed by “Phase B”, where a raw TCP connection is usually established according to published standards.

  [213] For example, in the “normal” case, exactly three TCP protocol data units (PDUs or packets) are exchanged to set up a connection. The first exchanged packet has the “SYN” flag set, the second packet has both the “SYN” flag and the “ACK” flag set, and the third packet has only the “ACK” flag set. Set. In this embodiment, the VOD peers that transmit the first and third packets are considered “initiators” and the VOD peers that transmit the second packets are considered “responders”.

[214] Upon completion of “Phase B”, the symmetric handshaking phase shown in FIG. 9 may begin. In the initial handshake phase or “Phase H1” 930, each of the initiator or “Node A” 910 and the responder or “Node B” 920 has established a TCP connection (as intended) with the VOD peer, or another Attempts to determine whether a TCP connection with a type of Internet-based entity has been erroneously established. Accordingly, this initial handshake phase, phase H1 930, is a symmetric phase. Each VOD peer sends a single octet (byte), sets a timer, and attempts to read another octet (byte) from the other VOD peer before the timer expires. In one embodiment, node A 910 or initiator sends a message “H1 _i ” that includes ASCII “6” (0x36). Node B 920 or responder sends a message “H1 _r ” containing ASCII “9” (0x39). If either side times out waiting to receive an octet from the other side (or receives an unexpected value), that side closes the connection. Synchronization of the incoming or outgoing stream with the other VOD peer is not necessary. Shutting down these send and receive streams is actually implicit (eg, when an application uses “close (...)” or similar API elements to detach itself from the connection). . Otherwise, if everything goes as planned (ie, the expected octets are received in time), the process proceeds to the next phase, “Phase H2” 940.

  [215] Phase H2 940 ensures that each of the VOD peers is actually communicating with the other VOD peer that it is a legitimate VOD peer (not the node attempting to "crack" the system) It is still symmetric in that it tries to do. In one embodiment, an “H2X” message is used to perform this secure verification, but a simpler “H2B” message is used for development and debugging purposes (eg preventing encryption of communications during debugging). In order to be usable (and possibly needed). In this development / debug scenario, phase H2 940 allows both Node A 910 and Node B 920 to exchange “H2B” messages that in one embodiment consist of a single octet (eg, dot or period ASCII code). Including that.

  [216] In a normal product scenario, both Node A 910 and Node B 920 exchange “H2X” messages to achieve secure verification. These “H2X” messages, in one embodiment, are encoded so that they can be quickly and easily parsed to locate the end of the message (eg, between 2 and 62 octets, the last An octet is the only octet encoded with a period ASCII code). These usually include well-seeded pseudo-random data mixed with various parameters related to security option negotiation. In one embodiment, when both sides send an “H2X” message as a phase H2 940 message, an additional phase or “H3” 950 is required to complete the initial security setup handshaking.

  [217] On the other hand, in a development / debug scenario, handshake phase H2 940 adds additional security to the connection when one side sends an "H2X" message and the other side sends an "H2B" message. Therefore, phase H3 950 is completed without requiring it. After the handshake is complete, the side that received the “H2B” message is that the side that sent the “H2B” message is using an older version of the protocol or an earlier version of the protocol, is operating in debug mode, or Sense that you may be trying to “crack” the system and feel anxious about this connection. Thus, the party receiving the “H2B” message may simply initiate a disconnect without providing any service (eg, by sending a “DiscWithReason” message with an appropriate payload, described below). . If a VOD peer does not support phase H3 950 for any reason, then phase H2 940 will simply send an “H2B” message and then enter until the last ASCII “period” is encountered. It may consist of reading up to 62 octets from the stream.

  [218] The initial message of the phase H3 950 exchange is, in one embodiment, a value that functionally depends at least in a predefined order on both the “H2X” message and another value (eg, encryption key). including. Each side first verifies that the received “H2X” message is different from the transmitted “H2X” message (and can “crack” the system if it receives the same message that it sent) You can also disconnect). Multiple messages can be exchanged for additional security, possibly including a node ID exchange (even before the “normal” node ID exchange following this handshake phase) until verification is achieved. .

[219] As a result of these handshake phases, use a relatively small buffer that can store a maximum size "H2X" message (eg, 62 octets / byte) and find a terminator value (eg, an ASCII period) "H2B" and "H2X" messages can be received by simply reading into the buffer from the input stream until the buffer is full. If the first octet is a terminator value, the message is an “H2B” message. Otherwise, the message is an “H2X” message.
2. Message encoding

  [220] After the initial handshake shown in FIG. 9 is completed, various other “basic” and “extended” messages can be exchanged depending on the situation. For example, in one embodiment, the VOD peer first exchanges the node ID (which is just an IP address in one embodiment, but in other embodiments is the box ID or the entire node ID) and trust level. Other scenarios include VOD peer's initial “bootstrap” process or subsequent startup / boot process, updates and other management services, push related processes (such as announcements and publications), pull related processes (such as file search and download) ), Dynamic monitoring testing and data exchange, and other scenarios described in more detail below.

[221] In one embodiment, the message is encoded starting with a 6-byte header. The string is value encoded using a 2-byte length. An additional 2 bytes are allocated for the protocol version used and another 2 bytes are allocated for the payload size and payload type, respectively. Empty payloads are allowed in this embodiment. Examples of payload types include:
・ 01 search index (payload is always CRID)
・ 02 Request Tracking (Payload is always CRID)
-03 Requested content package (payload is CRID and package number)
・ 66 No socket connection left

[222] In one embodiment, the message payload may consist of n elements of the same type (each element has a fixed size or different elements have different sizes) or different types. . When the payload consists of multiple elements that all have the same type of known fixed size, the first two bytes define the number of elements, and then are fixed to make up each element, as shown below Followed by the number of bytes.
Example This payload consists of three elements (a, b, and c) that all have the same type of known fixed size.

[223] When the payload consists of n elements of the same type but of different sizes, the first two bytes define the number of elements, as shown below, and then for each element Two bytes that define the size of the element, followed by the bytes that make up the element.
Example This payload consists of three elements (a, b and c) all of the same type but of different sizes (3 bytes, 4 bytes and 5 bytes respectively).

[224] When the payload consists of n elements of different types, various combinations of element types and sizes are possible, as shown below, each type of element (either the same fixed size or a different size) Are specified together.
Example This payload consists of various numbers of three types of elements. The first and second type elements (type A and type B) have a fixed size. The third type of element (type C) has variable size elements.

3. Basic message

  [225] The following are various general purposes that are not necessarily constrained to specific purposes, such as the main push, pull, and network monitoring functionality of the present invention (which are invoked by the "extended messages" described below) Is a description of an embodiment of a “basic message” used by a VOD peer. Such general objectives include initial handshaking and login messages to establish and verify a connection, display of “idle” time, and request cancellation and disconnection of an existing connection, as described below.

  [226] In one embodiment, the "basic message" includes:

[227] Initial handshaking

[228] Second handshake

[229] Login (LSTR) Connect to another node (including the node ID of the initiator)

[230] Confirmation of Login (ACK) handshaking verification (sent after accepting Login)
Subsequent disconnects that include the responder's node ID are not an error during the handshake phase, but are considered an unexpected disconnection of the “handshaked” connection

[231] Idle It may be necessary to send a message even when a substantive message is not needed

[232] Canceling a CancelRequest request

[233] RequestClosed This response is usually returned whenever a request is finally responded or canceled.

[234] A "WTDiscRspGranted" message is sent in response before a proper shutdown is initiated to ensure a proper shutdown of the connection before closing the WTDiscRequest socket

[235] WTDiscRspGranted Response to WTDiscRequest message to initiate a proper shutdown After receiving this message, the sender of the "WTDiscRequest" message initiates a proper shutdown to close the socket

[236] Sent in case of disagreement regarding WTDiscRspDoNot connection

[237] Disconnecting This message instead of exchanging the "WTDiscRequest" message and the "WTDiscRspGranted" message instead of first "disconnecting without asking" (essentially "requesting permission" to close the socket) Can be shut down to send and unilaterally close the socket

[238] DiscWithReason Same as “Disconnect”, but the payload can include the reason for disconnection in plaintext or encoded form in the payload containing the reason for disconnection

4). Extended message

  [239] As noted above, “extended messages” include more substantial messages regarding the primary push, pull, and network monitoring functionality of the present invention. In one embodiment, these extended messages include:

[240] Alive_List_Req Contains an “alive list” of initiators sent to share an “alive list” with another VOD peer

[241] Alive_List_Resp Contains “responder's“ alive list ”to Alive_List_Req

[242] Buddy_Download_Request The message payload to the VOD peer that has agreed to become a “buddy” includes the CRID, the package group from which the package group is downloaded, and the node ID of the VOD peer from which the package group is downloaded

[243] Buddy_Download_Response A payload sent in response to one or more responses to a Buddy_Download_Request message indicates that an empty payload that currently contains a package group ready for download cannot act as a “buddy”. Indicate (eg due to broken or slow connection)

[244] Buddy_Function_Request Notify VOD peers requesting to act as a “buddy” to prepare a prioritized download connection (and expect the current download connection to be broken) The payload contains the CRID and node ID of the currently downloaded VOD peer

[245] Buddy_Function_Response Response to Buddy_Function_Request message VOD peer confirms that it is ready to use “buddy” for alternate download An empty payload is ready for VOD peer to accept download requests from “buddy” Indicate that

[246] The payload sent by the VOD peer that needs a “buddy” to assist with the Buddy_Request download includes the CRID of the event and the node ID of the VOD peer from which the package group was first downloaded.

[247] The payload sent in response to the Buddy_Response Buddy_Request message identifies the conditions under which the VOD peer can act as a “buddy” and whether the requester wishes to use this “buddy” function An empty payload that allows you to determine if the VOD peer is currently unable to act as a “buddy”

[248] Cluster_Download_Complete After a VOD peer that is part of the “Supplying Cluster” completes the download of the specified package group, the payload sent from that VOD peer is an empty payload containing the event's CRID: Indicates that the download failed and the package group is not stored on the requesting VOD peer

[249] Sent from the VOD peer responsible for publishing events in the Cluster_Download_Start cluster (instructs the receiving VOD peer to download the specified package group from the node ID of the specified VOD peer)

[250] Sent from a VOD peer that is part of the Content_Retrieval_Ready provisioning cluster to indicate that the package group is ready to be downloaded to the requesting VOD peer

[251] Content_Retrieval_Help_Downloaded Indicates that the specified package group is ready for download, sent from a VOD peer that was asked to help as an alternate “feeder” node

[252] Content_Retrieval_Help_Request Sent only to VOD peers that have a good connection to the requesting VOD peer from the VOD peer seeking to help download the package group. The help is that the payload requested due to poor or lost connection to the original “feeder” node is the CRID of the event, the node ID of the VOD peer from which the package group is currently being downloaded, and Similar to a Buddy_Request message consisting of the ID of the package group for which the requesting VOD peer needs download assistance, but this message does not replace the existing connection, but requests a completely new connection.

[253] Content_Retrieval_Help_Response Confirms downloading part or all of the requested package group. The response payload for the Content_Retrieval_Help_Request consists of the CRID of the event and the ID of the package group to which the download was agreed.

[254] The payload sent from the VOD peer waiting for Feed_Cluster_Start and other VOD peers to participate in the “ Providing Cluster” content push is derived from the CRID of the event and the node ID of the server from which the content is published Become

[255] Feed_Cluster_Response The response payload for the Feed_Cluster_Start message that confirms participation in the “supply cluster” consists of the node ID of the public server from which the content is downloaded.

[256] File_Check_Request The request payload for one or more download connections to another VOD peer consists of the CRID of the event and the ID of the desired package group.

[257] File_Check_Response Returns the status of the VOD peer in response to the File_Check_Request, ie the number of download connections that the VOD peer can accept, or required before the VOD peer can accept the connection. The time length payload consists of the number of available connections (including the estimated time until a connection is available if no connection is available). An empty payload indicates that the request cannot be satisfied.

[258] Global_Message_Request Requests all "global messages" from another VOD peer

[259] Global_Message_Response A response to Global_Message_Request that returns all global messages (if there is no global message, the payload is empty)

[260] Index_File_Keeping Notifies another VOD peer that this VOD peer has a new / updated tracking index

[261] Index_File_Keeping_Response Response to an Index_File_Keeping request that acknowledges the knowledge of the new / updated tracking index

[262] The request payload for seeking the tracking index from another VOD peer with Index_Request consists of the CRID of the event associated with the desired tracking index.

[263] Index_Response The response payload for Index_Request that returns the requested tracking index consists of the requested tracking index (empty if not present).

[264] Peer_Casting_Client The payload that informs another VOD peer that it must act as a client in a “peer casting” scenario consists of the node ID of the VOD peer that must act as a server

[265] Peer_Casting_Client_Response Response to Peer_Casting_Client message An empty payload indicates that the peer casting server has been contacted and the “peer casting” scenario has been accepted.

[266] Peer_Casting_Download_Setup Sent from “Client” to “Server” in “Peer Casting” scenario to verify that the connection can be set up correctly

[267] Peer_Casting_Download_Setup_Response Response to Peer_Casting_Download_Setup message

[268] The Published_List_Request message payload from the publisher to the VOD support server, indicating that the publisher wishes to announce a new event (ie, a newly published content object), is the event associated with the published content object. Consists of CRID

[269] The message payload in response to the Published_List_Request from the Published_List_Response VOD support server to the publisher is an empty payload containing a list of node IDs that the publisher must contact to announce new events. Indicates that the VOD peer of “2” (or less) has decided that it should not be able to access the published content object for that event

[270] Published_Announcement The announcement payload of a new event (a publicly available content object available for download) to another VOD peer consists of the CRID of the new event

[271] Published_Announcement_Response The response payload acknowledging receipt of Published_Announcement consists of the CRID of the new event

[272] The entire content object associated with the Publishing_Complete event is sent to the publishing server when downloaded to a specific cluster

[273] QUE_Request Sent to a VOD peer that does not have an available download slot (including information about the requested package group)
An empty payload cancels all pending queues for that VOD peer

[274] Que_Response Response to Que_Request

[275] Message to VOD peer with trust level “2” warning that requester connection with VOD peer less reliable than Rescue_Preparation can request help in case of failure

[276] Rescue_Preparation_Response Response that acknowledges Rescue_Preparement message

[277] Tracking_File_Request The payload requesting a tracking file from another VOD peer consists of the CRID of the event associated with the desired tracking file.

[278] Tracking_File_Response The response payload for Tracking_File_Request consists of the requested tracking file.

C. Dynamic communication process

[279] Certain basic and extended messages have been described that are used in one embodiment for communication between VOD peers. Attention is now directed to the high level of functionality implemented by using such messages. Such functionality includes initial startup (and restart) of VOD peers, push processes (including announcements and publications of new content objects), pull processes (tracking index and tracking file search, and content object package downloads). As well as network, behavior, and other attributes of the system (including changes to the trust level, cluster membership, and distribution of copies of content object packages, including the results of such dynamic monitoring) Including the main dynamic process of the present invention.
1. Node startup

  [280] In one embodiment, VOD peers perform certain initial housekeeping tasks when they first join the network. Initially, a VOD peer communicates with other network devices depending on its default node ID as well as the node ID of a known VOD support server. Such information is stored when the VOD peer device is manufactured. For example, the unique box ID field is predetermined when the device is manufactured, while other fields are written by the user (via the user interface of the VOD peer) and / or the VOD support server ( Or other VOD peers).

  [281] The internal software of the VOD peer initially determines whether a network connection existed by default (eg, via a local DHCP server), and if not, the network establishing such a connection Call the setup routine. Furthermore, in one embodiment, direct internet connectivity is not required. For example, a VOD peer has a direct connection (or a further indirect connection or possibly a “proxy” connection) with a VOD peer that has access to the Internet. In that case, the latter VOD peer is responsible for enabling full or partial network functionality and VOD functionality by relaying messages to and from VOD peers that do not have direct Internet access. The following steps are described assuming direct Internet connectivity, but these can be performed indirectly or via a “proxy” VOD peer.

  [282] When setting up network connectivity and Internet access, the VOD server then accesses its internal memory (eg, ROM) to obtain one node ID of a known VOD support server and the VOD server. Proceed to communication with the support server to establish a connection and perform these initial housekeeping tasks. Such tasks include software updates (to obtain the latest VOD peer client software or firmware) and time synchronization (in one embodiment, which can then be maintained on a periodic basis). it can. It may also include a “creation process” that serves to fill and / or update the remaining node ID fields along with other initial profile information.

  [283] For example, in one embodiment, the VOD peer's box ID may be utilized by the VOD support server to check for new software or firmware updates. Upon verification of the box ID, the VOD support server can respond by returning a CRID containing the updated software specified for the device model and version number of the VOD peer. The VOD peer can then download the updated software and invoke a client-side update process or installation process. In other words, such update software can be considered as just another content object on the network, in which case the CRID “content object type” is the update software that requested the installation (eg, , Identify that content object (not the movie specified for VOD viewing).

  [284] In addition, the VOD support server accesses the standard IP location database (instead of the VOD peer being initialized) and has some geographic information (the ISP field of the node ID, the country field described above). , Regional fields, and other related fields). Such information is passed to the VOD peer, which updates its own internal memory.

  [285] Data from an additional node ID field (eg, IP address) can be obtained directly from the VOD peer to generate the full node ID of the VOD peer, and other data can be It can be determined indirectly via “test” communication. For example, the “Local Node Accessibility” field value and the “Global Node Accessibility” field value for a VOD peer may indicate whether direct access to that VOD peer is normally blocked by a firewall / NAT router, or a wider cluster (eg, By exchanging certain messages to determine if a wider set of IP addresses is accessible (eg, in one embodiment, by pinging a specific IP address and waiting for an acknowledgment) ) Can be set. Additional fields, such as the “Net Measurement” field, can be obtained by performing a set of standard network measurements (eg, ping test and traceroute test), or simply by defaulting some value This can be determined by relying on subsequent tests to maintain the current state. Other fields (eg, trust level) are set by default in this embodiment and are maintained over time as additional network measurements are obtained via the cluster controller of the VOD peer.

  [286] Further, in one embodiment, a user registration process is performed to register the user and optionally authenticate and verify the user's permissions for the network. For example, a given user can be given restricted or filtered access to a given content object and / or network functionality. Such constraints can be enforced at startup via this initial registration process (and subsequently verified over time and / or at subsequent restarts). During this registration process, the VOD support server obtains certain user profiles and related information via user interface software (at the time of manufacture and / or via software or firmware updates) stored on the VOD peer itself. , Such information can be stored in a database accessible from a central location on the network.

  [287] In one embodiment, whether a VOD peer is starting up for the first time or restarting (eg, due to a device failure, network failure, power outage, etc.), the VOD peer is updated, for example VOD support server (and / or possibly indirect) with certain information, including a “live list” (to determine a known adjacent VOD peer known to be “alive”, ie, recently active) To other VOD peers). At initial startup, a VOD peer is very reliable, such as a VOD support server (eg, a VOD support server in the same IP range as the VOD peer based on information obtained from a standard IP location database). Obtain a “high standard” alive list that includes high VOD peers. Furthermore, the node IDs of VOD peers that are less reliable but still relatively highly reliable (eg, “cluster level”) can be included in this (or separate) alive list.

  [288] Subsequent exchange of alive lists (eg, performed during a periodic network monitoring process, described in more detail below), in one embodiment, is performed at a rate determined by the trust level of the VOD peer. Is done. In this embodiment, less reliable VOD peers are “updated” more frequently (ie, exchange alive lists with their neighbors) than more reliable VOD peers. For example, a VOD peer with a default trust level can be updated every minute, and a VOD support server or a VOD peer with a trust level of 2 can be updated only once per hour. As described in more detail below, the confidence level (along with other factors) can also be used to determine the frequency of other network monitoring tests.

[289] Additional metadata, such as information specific to one or more superset clusters of which the VOD peer is a member, may also be exchanged at the initial or subsequent startup of the VOD peer. For example, an updated tracking index or tracking file can be exchanged. This can of course also be triggered and exchanged thereafter on a periodic basis and / or by changes to such files.
2. Publication and push of content objects

  [290] As noted above, when a new content object is published on the network (ie, an event occurs), there are two main functions: (1) a “announcement” of the publication of the content object; Subsequent (2) the actual “publication” of the content object itself (ie, distributed push of the content object package to the various VOD peers) is performed.

  [291] As also noted above, in one embodiment, the initial publication server generates a CRID for an event and a publication announcer (eg, a region where content objects must be published) to further announce the event. Look for a more reliable VOD peer). Each of the publication announcers selects one or more publication masters (relatively very reliable VOD peers) that manage the process of publishing content objects.

  [292] The publication master determines the “expected” level of popularity of the content object (as described in more detail below) and issues a request for interest to the publication server (directly or indirectly through a publication announcer). The publication server uses this interest request to determine the appropriate size and number of packages into which the content object should be divided. The publication master correlates the tracking index (correlating the VOD peer storing the tracking file with the CRID) and the tracking file (the group of content object packages are pushed and stored, correlating the VOD peer and the CRID. ) Is also generated and updated.

  [293] In one embodiment, the publication master then issues a collection request to the publication announcer, which specifies (among itself) a collector that obtains the tracking index and group of packages from the publication server. To do. Each publication master identifies candidate VOD peers (eg, among VOD peers in a particular cluster or sub-cluster) where groups of packages are further pushed and stored, and makes such packages available to these VOD peers. Responsible for downloading.

  [294] Accordingly, in one embodiment, the publication server "announces" an event to one or more publication announcers (which further announce the event to one or more publication masters). A communication protocol 1000 that implements these announcements is shown in FIG. 10a, which illustrates the process by which the publication server 1005 announces events to one or more publication announcers (using the various extended messages described above). )It is shown.

  [295] In this embodiment, the publication server 1005 first contacts the VOD support server 1010 to obtain a list of publication announcers that are very reliable (eg, trust level “2”). In the first communication 1032, the publication server sends a published_list_request message (including the event CRID) to the VOD support server 1010. The VOD support server 1010 responds with a published_list_response message (including the node ID of the candidate publication announcer) via communication 1033.

  [296] Using the node ID obtained in the response message, the publication server then makes these two promising publication announcers ("Node F" 1015, each of which is a VOD peer of trust level "2" and "Node A" 1020) and send a published_announcement message (again including the event CRID) to each of these via communications 1036 and 1038, respectively. In this example, node F 1015 determines that the content object identified by the CRID must not exist in the cluster (eg, because the geographic area is excluded based on the publication rights field of the CRID), Therefore, it does not respond to the published_announcement of the communication 1036.

  [297] In other embodiments, of course, negative response messages or other acknowledgment messages can be utilized to distinguish other reasons for lack of response, such as device failure or network failure, for example. In addition, as noted above, various handshaking protocols can be used to obtain reliable and reliable connections (with appropriate acknowledgments), which can eliminate the need for such additional messages. it can.

  [298] However, Node A 1020 responds with a published_announcement_response in communication 1039, indicating that the publication of the event can proceed within the cluster. As noted above, in one embodiment, a similar announcement phase (not shown) occurs to identify the publication master responsible for the publication phase of this event.

  [299] After this announcement phase, the publication master is responsible for the actual publication (push) of the content object package (and associated tracking file) to the candidate VOD peer. This includes, in one embodiment, determining which content object package is pushed to which VOD peer. In other embodiments, a publication server (or other “helper” VOD peer) can assist (or replace) exclusively in this process.

  [300] One embodiment of a communication protocol 1050 that implements a distributed download of this content object package is shown in FIG. 10b. In FIG. 10b, the publication master acts as a “feeder node” and other (usually slightly less reliable, eg trust level X, where X can be equal to “4”) A process (using an additional extended message not described above) that results in pushing the content object package to the peer is shown. Such VOD peers continue this distribution process until the content object package is sufficiently distributed between and within the candidate clusters to allow the desired NQoS level for subsequent VOD requests (see FIG. Not shown).

  [301] Turning to FIG. 10b, "Node A" 1060 (one of the publication masters) is the two of these candidate VOD peers ("Node A" B ”1065 and“ Node C ”1070), and initiates communication to effect the download of such a content object package. In communication 1071, Node A 1060 sends a feed_cluster_start message to Node B 1065 (indicating the intention to include Node A 1060 in the “Supply Cluster”) and confirms Node A's consent (eg, Node B can use it). Wait for a feed_cluster_response message (communication 1072) from Node B 1065). Similarly, node A 1060 sends a feed_cluster_start message to node C 1070 (at communication 1074) and waits for a fed_cluster_response message (from communication 1075) to confirm from node C.

  [302] In this embodiment, upon receiving responses to these messages, Publication Master Node A 1060 will publish for a list of candidate VOD peers (ie, Node B 1065 and Node C 1070) in this “serving cluster”. The server 1055 is notified. As a result, if the publication server 1055 decides to undertake content object package downloads to these VOD peers, the cluster_download_list message will be able to prioritize and schedule its work on its own. Is transmitted to the publication server 1055 (by communication 1077). In this embodiment, no response is required, but communication 1078 indicates a negative cluster_download_list_response message.

  [303] Node A 1060 then schedules the download of such a content object package to Node B 1065 and Node C 1070 (named communications 1082 and 1086, including similar feed_cluster_start and feed_cluster_response messages). Via responses 1083 and 1087). Next, the actual file transfer download (not shown in detail) of the content object package is initiated. Although not shown, this distribution process continues until the relevant content object packages are pushed to all of the candidate VOD peers in the target cluster, not just Node B 1065 and Node C 1070.

[304] Once this distributed push of the content object package to all candidate VOD peers in the target cluster is complete, each of Node B 1065 and Node C 1070 sends a cluster_download_complete message to Node A 1060. Via communications 1091 and 1092). Node A 1060 notifies publication server 1055 that the portion of Node A 1060 of this distributed push process has been completed by sending a publishing_complete message via communication 1094.
3. "Instant play" and pull of content objects

  [305] Once a content object has been published and its component package has been pushed to various cluster-wide VOD peers, the user invokes the VOD functionality of the present invention and provides various features (many of which are detailed above). Such content objects can be viewed (often immediately) with a consistent NQoS enabled by

  [306] One such feature that facilitates the "instant play" aspect of the present invention is the division of content objects into component packages and such packages between clusters of VOD peers throughout the network. Is the distribution of groups. This distribution of the content object 1100 packages is shown in FIG.

  [307] As noted above, in one embodiment, a content object (eg, a movie) typically has a linear progression from start to finish. Group content object packages into smaller groups toward the beginning 1100 of the content object 1100 and gradually larger groups toward the end 1120 of the content object 1100, with these smaller and earlier groups being relatively more numerous. VOD peers requesting VOD viewing of content object 1100 can obtain such earlier groups relatively quickly (i.e., they are smaller, Because it is more likely to be nearby due to storage at more other VOD peers). Subsequent groups of packages of content objects 1100 will have longer time required to download such groups (due to the fact that there are relatively fewer copies of such groups of packages and their larger size). ) Can be downloaded in parallel by taking advantage of the additional time required to view the content object 1100 in a sequential manner.

  [308] In one embodiment, this is accomplished by dividing the content object 1100 into variable length packages (eg, earlier packages are smaller and subsequent packages are gradually larger). In other embodiments, the package of content object 1100 may be a fixed size. Size variability is achieved by grouping fewer or more such packages for storage at the VOD peer 1150. The use of gradually increasing variable size packages (or increasingly larger fixed size packages) is, of course, only one of many different possible implementations of the same basic principle. For example, the size of a variable-size package (or the number of fixed-size packages) at the beginning 1110 or end 1120 of the content object 1100 only, or as a result of facilitating “instant play” and package consistency consistent with VOD functionality Can be modified in other patterns that effectively result in reliable downloads.

  [309] Furthermore, this feature is further facilitated by careful selection of specific VOD peers both between and within the cluster for the storage of specific groups of content object packages. FIG. 12 shows a relatively natural distribution 1200 of trust levels that exists primarily due to the existing infrastructure of the Internet, rather than just a cluster of VOD peers. FIG. 12 is utilized for the purposes of the present invention to provide a mechanism for forming clusters (and sub-clusters) of VOD peers that can store content object packages based on their relative proximity or internet distance from each other. it can.

  [310] There are a relatively small number of VOD support servers 1260 in the most reliable trust level 1270 of the embodiment shown in FIG. The least reliable trust level 1280 has a high bandwidth broadband router in the “core” of the Internet and a number of “leaf node” VOD peers at the far end of the Internet distance from the ISP. Between these two ends, there is a relatively modest number of VOD peers with an “intermediate” confidence level 1250 (eg, 6-9 on a scale of 1 to 16).

  [311] This inverse correlation of the number of VOD peers with the “trust level” of such VOD peers indicates that the Internet's physical infrastructure facilitates a relatively uniform set of adjacent VOD peers. Providing a mechanism for forming clusters (and sub-clusters). For example, if FIG. 12 represents a regular cluster, within any trust level, there is a set of VOD peers with relatively similar Internet distances from the Internet backbone or “core”. The VOD support server 1260 at the most reliable trust level 1270 is relatively close to this Internet core. At the other end of the spectrum, a number of “leaf nodes” VOD peers with the least reliable trust level 1280 are relatively far from the Internet core. However, looking at the overall trust level, there is a relatively uniform distribution of VOD peers that are close to each other (at internet distance).

  [312] In other words, by working outward from the Internet core, these sets of VOD peers at each trust level can be effectively "sliced" and slices of VOD peers across trust levels can be passed to each other. Will be combined based on their relative proximity (in internet distance). The result of this “inter-trust level” slice is a cluster of VOD peers that have various trust levels but share relatively close internet distances to each other. However, as will be discussed in more detail below, this inverse correlation of the number of such VOD peers to the “level of trust” of the VOD peers is due to behavior and other network-based considerations over time. It can evolve into a variety of different configurations.

  [313] Having described this static “post-push” distribution of content packages across clusters and between VOD peers of various trust levels within the cluster, we now have some major implementations of the pull aspect of the present invention. Focus on dynamic communication protocols.

  [314] Similar to its public content object push, pulling such content objects for "on-demand" viewing by VOD peers includes two main functions. (1) search for VOD peers that store the associated tracking index and tracking file (ie, the file that contains the selected CRID), and (2) content object packages from the VOD peers identified in these tracking files. Download.

  [315] In one embodiment, whenever available content is informed (in a distributed manner) to VOD peers, such information is included in the CRID of each published content object (event) as well as various meta-data. Includes data (eg, title, genre, etc.). The metadata is made available to the user via the VOD peer user interface for the event. When a VOD peer user selects a content object for VOD viewing via the VOD peer's user interface, the client software accesses its internal memory and extracts the CRID associated with the content object. To do.

  [316] FIG. 13a shows an embodiment of a communication protocol 1300 that utilizes its CRID to locate a corresponding tracking index and tracking file. The tracking index and tracking file identify the various VOD peers where the component package of the desired content object is stored, and such packages from these VOD peers for “on-demand” viewing of that content object. Will be used later to download. In this embodiment, the requesting VOD peer “Node A” 1305 (assuming a trust level of “4”) first has a known neighbor VOD peer with the same trust level (eg, in its alive list). The tracking index corresponding to the CRID is retrieved by sending an index_request message (described above).

  [317] If the tracking index is not successfully found among VOD peers with the same trust level, Node A proceeds to search for a higher trust level VOD peer until a tracking index is found. It should also be noted that in other embodiments, a tracking file can be identified (eg, by sending a request for both the corresponding tracking index and the tracking file) before the tracking index is found.

  [318] Returning to FIG. 13a, Node A 1305 sends an index_request message to "Node B" 1310 (also having a trust level of "4") via communication 1322. Node A 1305 may also send an index_response message via communication 1323 that includes an associated tracking index (in this example, or an associated entry in the tracking index corresponding to the requested CRID in another embodiment). Receive. Node A 1305 then sets the node ID of the VOD peer with the corresponding tracking file copy (identifying the VOD peer that actually stores the component package of the content object corresponding to the requested CRID). Extract from entries.

  [319] According to this scenario, one of the entries storing the tracking file is “Node C” 1315 (Node C of course has a trust level “X” different from either Node A 1305 or Node B 1310). Can have). Node A 1305 then proceeds to send tracking_file_request (also described above) to node C 1315 via communication 1325 and receives tracking_file_response including the tracking file corresponding to the requested CRID via communication 1326. To do. Node A 1305 then extracts from the tracking file the node IDs of the various VOD peers that actually store the content object component package corresponding to the requested CRID. These node IDs provide the information necessary to initiate the next phase of downloading the content object package for VOD viewing.

  [320] This next phase is shown in FIG. 13b. FIG. 13b shows an embodiment of a communication protocol 1350 for downloading a content object package. Note that in this embodiment, there are typically multiple VOD peers (and thus multiple node ID entries in the corresponding tracking file) that store different groups of packages of the desired content object. Although communication with one such VOD peer is shown in FIG. 13b, multiple similar communications can be performed in parallel. In this embodiment, the VOD peer that stores the “earlier” package (ie, the package containing the earlier part of the movie, for example) is contacted first. This is because these files are needed earlier for viewing. However, even in the case of real-time playback speed, the length of time required to initiate multiple such requests can occur without significant delay in download (as described in more detail both above and below). Relatively small if NQoS is useful). Furthermore, as described below, multiple files can be downloaded from each such VOD peer (also in parallel).

  [321] Having identified "Node B" 1360 as one of the VOD peers that stores a particular package of the desired content object, "Node A" 1355 sends a file_check_request message to Node B 1360 via communication 1372. (Also mentioned above). The message includes a desired number of connections for downloading one or more files (ie, a group of packages of desired content objects). Node B 1360 responds with a file_check_response (also described above) via communication 1373. This response includes either the number of connections currently available or the latency if the connection is not currently available (along with the number of files in the queue).

  [322] In the example shown in FIG. 13b, file_check_response from Node B 1360 in communication 1373 indicates that two connections are available and reserved for file download. Node A 1355 then proceeds to send a “file_feed_request” message (not previously described) via communication 1376. This message triggers the download of the file (including the package of the desired content object specified in the tracking file) using the two reserved channels specified in the file_check_response message from Node B 1360. Node B 1360 then sends a content_package_feed message (not previously described) containing the actual file via its respective communications 1377 and 1378 (corresponding to two designated communication channels). Send to.

  [323] Upon receiving these files, the requesting VOD peer, Node A 1355, may initiate queuing of these packages of content objects for display via its user interface. The initial group of packages can be viewed immediately, and subsequent groups of packages are typically queued for “just-in-time” viewing until needed immediately. This process is somewhat similar to point-to-point streaming download, but critical intelligence (NQoS, push process, pull- Inherent on various features of the present invention including processes etc.) and achieved on a multipoint basis.

  [324] In addition to the normal pull download scenario described above, several supplemental features are included in one embodiment. The feature takes into account even the relatively rare case to further minimize the probability that playback of the requested content object is delayed and / or interrupted. For example, in one embodiment shown in FIG. 14, a pull download scenario 1400 is shown in which a VOD peer 1410 is requesting package downloads (in parallel) from two major “feeder” VOD peers 1420 and 1430. Yes. As noted above, VOD peer 1410 may assume that it has received one group of packages from VOD peer 1420 and a different group of packages (of the same content object) from VOD peer 1430.

  [325] However, there are scenarios in which one or both of these “feeder” VOD peers 1420 and 1430 suffer interruption during the process of transferring files to the VOD peer 1410. For example, one VOD peer may suffer from a local device failure, or the network failure may be a VOD peer or other network node (eg, two that are not otherwise part of the VOD network of the present invention) This may occur due to the simple disappearance of intermediate routers between VOD peers.

  [326] In that case, the VOD peer 1410 needs to rely on a “fallback” VOD peer (eg, a secondary of the main or primary VOD peer 1420 or a fallback VOD peer 1425 and a secondary VOD peer 1435 of the primary VOD peer 1430). There may be. There are a number of different ways in which such “collapse handling” functionality can be implemented. For example, in one embodiment, VOD peer 1410 may utilize additional available connections to initiate downloads from such secondary VOD peers before an error occurs. The VOD peer 1410 selects the secondary VOD peer towards the earlier group of packages of the desired content object that will be needed sooner than the later group of packages (from the node ID domain present in the incoming tracking file entry). )) Can be given priority (to prevent interruption of content object playback).

  [327] In one embodiment, such collapse handling functionality is performed by an initial exchange of "rescue_preparation" and "rescue_preparation_response" messages with a very reliable (eg, trust level "2") peer. (After the VOD peer recognizes that its connection with its main “feeder” VOD peer is slowing, has failed, or may soon fail). In the event that the main connection fails (or slows down beyond a certain threshold), the VOD peer will revert to its very reliable VOD peer (due to the prior notification it received) The remaining package group downloads can be requested via (which is likely to be ready to handle such requests without NQoS degradation).

  [328] In addition to proactively attempting to handle or avoid interrupting the download (pull) of a package to the requesting VOD peer, other scenarios have potential “feeder” VOD peers Recognize that there is not enough connections available to complete the requested download with the requested or desired NQoS (eg due to request overload, existing download connections, etc.) (E.g., upon receipt of a "file_check_request" message).

  [329] In one embodiment, the potential “feeder” VOD peer queues (ie, delays) the request to the requesting VOD peer (above the “file_check_request” message and the “que_request” message and its Options can be given (as described with respect to responses) or relying on another (secondary or fallback) VOD peer to complete the request (or in another embodiment both).

  [330] In another embodiment, the requesting VOD peer (or possibly a potential “feeder” VOD peer) is sufficient to download the requested content object (or possibly the content object in general). Does not have bandwidth in that cluster. However, it can be appreciated that the requesting VOD peer has a good connection with a neighboring VOD peer (“buddy”) that has significantly better intra-cluster (and / or inter-cluster) connectivity. In this embodiment, the requesting VOD peer can delegate the task of downloading one or more content objects (or component package groups) to its “buddy”. This “buddy” forwards such a content object for viewing at the requesting VOD peer (the “buddy_request” message, the “buddy_function_request” message, and the “buddy_download_request” message and their responses, as described above. Using). This “buddy function” can be used on a “per request” basis, or in other embodiments on a less temporary basis. Also, as noted above, even potential “feeder” VOD peers can take advantage of this buddy function, ie delegate the download of the requested group of packages to the requesting VOD peer. Can be used.

  [331] All of the above scenarios use a “client-server” approach to downloading content object packages. However, another option for requesting (and “feeder”) VOD peers facing insufficient bandwidth and / or connectivity to complete the request is such download until the intended recipient is reached. Is an alternative method known as “peer casting” that involves multicasting downloads to a chain of peers (eg within a cluster). The use of such techniques in one embodiment can overcome the overload of a particular VOD peer (eg, in an “emergency” scenario, or a particular content object is very popular, When a VOD peer wants to see it almost simultaneously).

  [332] However, this technique is only recommended as a temporary measure due to the negative impact on QoS (and thus NQoS in the context of the present invention) as a result of the lack of tracking index and tracking file updates in this scenario. Is done. Instead, the VOD peer is informed directly which other VOD peers must contact to obtain the desired package group.

[333] For example, VOD peers “serving” multiple other VOD peers can recognize “peer casting” opportunities (eg, “feeding” these multiple VOD peers directly to each other) To save bandwidth by letting you). That VOD peer may then designate one VOD peer (eg, the most trusted VOD peer) as a “server” and another VOD peer as a “client” (eg, designated “server”). (Via the “peer_casting_client” message described above, including identification of the node ID). In this embodiment, the VOD peer mentioned above until a “peer casting” scenario is confirmed (eg, indicating that “client” has contacted “server” and accepted this “peer casting” scenario). (Via the “peer_casting_client_response” message), continue to download the package group to both. The VOD peer further continues to download package groups to the “server” VOD peer, and the “server” VOD peer downloads them to the “client” VOD peer (eg, the “peer_casting_download_setup” message described above). In response to)).
4). Dynamic monitoring of NQoS and network traffic

  [334] Now that the communication protocols and messaging have been described in general terms and with respect to the main push and pull functionality of the present invention, it is now possible for the VOD peer to communicate with network traffic (VOD functionality behavior and bandwidth). And perform various "content balancing" functions and related functions to provide NQoS to VOD applications in network situations that rely on existing Internet infrastructure (including network attributes such as reliability) Pay attention to the means.

  [335] As noted above and in the embodiment shown in FIG. 15, the cluster controller of each VOD peer is primarily responsible for this distributed dynamic monitoring functionality. In addition to monitoring network and behavior activity, these cluster controllers also change various network attributes and content distribution attributes as a result of such monitoring, effectively resulting in a “distributed closed loop feedback” system 1500.

  [336] This system 1500 allows a VOD peer to have a specific content object (distributed in a package among its neighboring VOD peers) within that VOD peer within a predetermined time prior to every request. By enabling the ability of the network to deliver to be identified, QoS (NQoS) is effectively incorporated into the network.

  [337] having a trust level of “5” and a cluster controller 1520 that enables communication (in one embodiment, both within and across clusters) with cluster controllers of other known VOD peers. A VOD peer 1510 is shown in FIG. These other VOD peers have the same trust level (eg, VOD peer 1510a), have a lower trust level (eg, VOD peer 1510b), and have a higher trust level (eg, VOD) Peer 1510c). For ease of reference in future examples, VOD peer 1510a is also referred to herein as a particular VOD peer (initially having a trust level of “5”).

  [338] Dynamic network monitoring 1525 is a distributed process that includes communication between the cluster controllers of each VOD peer in system 1500 (as described in more detail above). Individual VOD peers can run tests for themselves and maintain the statistical results of such tests. For example, in one embodiment, VOD peer 1510 performs a periodic ping test with three of its known neighbors, and the results of such a test (eg, long, short, and average ping time, failure) Can be recorded in the net measurement value field of the node ID. In one embodiment, relatively small file transfers using files of varying sizes may be performed (eg, for neighbors as well as remote VOD peers of varying trust levels).

  [339] Further, in one embodiment, a relatively highly reliable VOD peer can perform such tests on behalf of the cluster and maintain the results (potentially interfacing). Including cluster activity and intra-cluster activity). For example, a relatively highly reliable VOD peer (eg, trust level “3”) in the same cluster as VOD peer 1510 was executed by all VOD peers (or some subset) in that cluster Similar values that reflect the cumulative results of the ping test can be maintained (eg, extracted from distributed messages that query the VOD peer for the value of its net measurement field).

  [340] Performing “comprehensive” network traffic tests (ping, traceroute, file transfer of varying sizes, etc.) between adjacent VOD peers and remote VOD peers (individually or on intracluster or intercluster basis) In addition to whatever is maintained, the cluster controller may also monitor actual VOD network traffic in one embodiment. For example, requests for specific content objects or requests for content objects in general are detected by the cluster controllers of VOD peers of various trust levels (eg, a predetermined message associated with these requests will identify such VOD peers). "Because it passes").

  [341] This VOD network traffic should be maintained “globally” (eg, for the entire VOD network) or at an intercluster level, an intracluster level, or even a purely “local” level (eg, individual VOD peers). Can do. In one embodiment, such information includes requests within a particular daily time slot for all content objects and / or content objects included in a particular genre or content objects that exceed a predetermined maximum or minimum threshold of requests. Can be included. In addition, information regarding distribution of content object packages within and between VOD peers within a cluster can be maintained. For example, the number of copies of a content object or content object included in a particular genre can be maintained over time, and the number of copies of a particular group of content object packages (eg, within a particular cluster) It can also be maintained over time.

  [342] In one embodiment, some or all of these dynamic network monitoring 1525 tests are performed on a periodic basis as well as various activations (eg, device failures, network failures, VOD requests for specific content objects, or specific Note that it can be performed in response to detection of a VOD request, etc., for a content object accessed within a certain time interval. Furthermore, the results of such tests can reflect a minimum or maximum score, as well as an average value or other cumulative value accumulated over time. As noted above, in order to avoid overloading the network with such “monitoring” traffic, a balance is maintained (eg, a significant loss of NQoS on the actual VOD network traffic itself). Not to).

  [343] By maintaining such statistics over time, the cluster controller of the VOD peer can take action based on these statistics (in one embodiment). As noted above and shown in FIG. 15, the results obtained by dynamic network monitoring 1525 are stored in the dynamic network monitoring results database 1532 (in one embodiment, centrally by VOD peers of various trust levels). As well as in the net measurement field (not shown) of their own node IDs. Thus, this information can be used not only for “feedback” 1534 to individual VOD peers, such as VOD peer 1510, but also for feedback to other VOD peers via distributed communication between the cluster controllers of each VOD peer. is there.

  [344] This feedback 1534, as described above and shown in FIG. 15, is attributed to individual VOD peer attributes and VOD network infrastructure (eg, cluster membership and such intra-cluster and inter-cluster). Reflected in various changes 1530 to the distribution of groups of content objects and their component packages between VOD peers. For example, the trust level of a particular VOD peer can be changed over time, as a result of a comprehensive network traffic test or even as a result of an actual response to a request for a content object. These “trust level changes” 1536 are one important means by which NQoS is affected, as described below.

  [345] “Package Distribution Change” 1538 (also described below) is another important means of affecting NQoS. This may include, in one embodiment, changing the deployment of a content object and its package component groups. For example, the number of copies of a particular content object (and / or its package component group) can be increased or decreased (eg, for content objects monitored over time within a particular cluster or between particular clusters). As a result of popularity or popularity of the content object genre). The size and number of component packages of a content object (or content object in general) can also be changed.

  [346] In addition to the trust level change 1536 and the package distribution change 1538, there are various other changes 1539 that can be used to affect NQoS. For example, in one embodiment, cluster membership can be changed based on the results of dynamic network monitoring 1525 (eg, a set of known adjacent VOD peers is a VOD indicating a sufficiently short adjacent ping time). By constraining to peers). Other changes can include changing the number of VOD peers from which requests (or other messages) are initially sent (eg, based on previous success rates or response times for similar messages). Apart from certain types of changes, virtually all changes to node or network attributes that can be monitored dynamically over time and subsequently changed via feedback 1534 play a role in affecting NQoS. Note that you can. Some changes and dynamically monitored tests are simply more effective and efficient (individually and in combination) than other changes and tests.

  [347] In one embodiment, the result of a “comprehensive” network traffic test by individual VOD peers 1510 can trigger a change in the trust level of VOD peer 1510a (eg, ping test failure for VOD peer 1510a). Due to exceeding the threshold number). As detailed above, various confidence level parameters are determined from component confidence level factors that are maintained over time (in one embodiment). The cumulative result of these component confidence level factors is the current calculated confidence level. Thus, changing the confidence level factor as a result of a particular dynamic network monitoring 1525 test will result in a relatively immediate change in the trust level parameter and eventually a relatively immediate change in the trust level itself (this Is reflected in the trust level field of the node ID of the VOD peer).

  [348] It is important to understand how these dynamic confidence level changes 1536 (shown via dynamic feedback 1534) affect NQoS. As noted above, existing Internet infrastructure does not inherently provide QoS.

  [349] A VOD request initiated by a VOD peer 1510 is not limited to communication between other VOD peers, but also existing Internet hosts, routers, and other nodes [all of them (individually or collectively)] At all times, allowing device failures and bandwidth and reliability changes. There is no central or distributed mechanism that globally monitors global Internet traffic and maintains a consistent and reliable QoS level.

  [350] Nevertheless, the “distributed closed-loop feedback” system 1500 of the present invention is such a mechanism (ie, NQoS) between networks of VOD peers that exist “on” or as part of the existing infrastructure of the Internet. I will provide a.

  [351] For example, VOD peer 1510a indicates a trust level of “5”. However, the VOD peer 1510a responds to requests from the VOD peer 1510 and provides, for example, substantially “immediate playback” as well as consistent and reliable playback of the requested content object, relatively quickly and reliably. The component package of that content object that was previously distributed among adjacent VOD peers (including VOD peer 1510a) can be "provisioned" to VOD peer 1510. Therefore, the user of VOD peer 1510 may be satisfied with this level of service during a certain time interval.

  [352] Nevertheless, as noted above, failures of other devices (VOD peers, Internet routers, Internet hosts, etc.) may possibly affect the level of service. For example, if the trust level of VOD peer 1510a is changed from “5” to “6” (less reliable) as a result of a periodic ping test failure or other test from dynamic network monitoring 1525. Assume. The cluster controller in VOD peer 1510a detects this change in trust level and informs neighboring VOD peers that they may need to rely on another (more reliable) neighbor. Thus, one or more messages can be sent automatically (or in another embodiment, only if a predetermined threshold is exceeded, eg, “trust level> 5”).

  [353] In one embodiment, this can be achieved more comprehensively by daily exchange of updated alive lists (performed periodically and / or triggered by a change in trust level). VOD peer 1510 can now know to rely on another trust level “5” neighbor (or a more reliable neighbor) rather than VOD peer 1510a (eg, for subsequent requests), This can improve the NQoS of such subsequent requests.

  [354] In one embodiment, periodic updates of the alive list are performed, and less reliable VOD peers are relatively more frequent than more reliable VOD peers (eg, once every hour). (Eg, once every minute) to perform such an update. This routine periodic process (in a distributed manner) that automatically updates the alive list of VOD peers is necessary to allow the VOD peers to bring about changes to improve NQoS. Significantly reduce the amount (ie, because VOD peers are effectively informed of dynamic network changes via this “distributed broadcast” mechanism).

  [355] It should also be noted that changes to VOD peer attributes and network attributes made as a result of dynamic network monitoring 1525 can often be related to each other. For example, the trust level change 1536 described in the specific example above may trigger the package distribution change 1538. For example, when the trust level of VOD peer 1510a changes from “5” to “6”, such a change can also be detected by the VOD peer managing the cluster in one embodiment (eg, also periodic Either via a distributed update of the alive list, either automatically or triggered by this change in trust level). As a result, additional copies of the group of packages (or a subset thereof) currently stored on the VOD peer 1510a can be redeployed. For example, another VOD peer (eg, a VOD peer with a trust level of “5”) can be selected to receive a copy of such a group of packages. In one embodiment, this can be achieved by having its “replacement” VOD peer communicate directly with VOD peer 1510a to obtain such a copy (but in other embodiments, more You can rely on a reliable VOD peer, or perhaps contact the original public server). In any case, the tracking file and tracking index are updated accordingly (as described above).

  [356] With respect to package distribution changes 1538 in general, these can be performed in a variety of different scenarios. For example, a relatively reliable VOD peer may be responsible for managing requests in the cluster (in one embodiment, through the cluster controller). When it detects a request for a particular content object (eg, via the distributed message described above), its VOD peer updates the dynamic network monitoring results database 1532 to a predefined threshold, eg, a particular time. It can be notified that the maximum number of requests for the same content object within the interval has been exceeded.

  [357] As a result, this “manager” VOD peer may in one embodiment contact one of the “feeder” VOD peers (such as the VOD peer 1420 of FIG. 14 described above). This “feeder” VOD peer adds the requesting VOD peer to the tracking file (ie, converts the requesting VOD peer to a future “feeder” VOD peer). In another embodiment, the VOD peer 1420 effectively becomes a publisher and publishes (pushes) additional copies of the content object within the cluster (as described above with respect to the overall publication process).

  [358] Thus, NQoS is affected as a result of this “distributed closed loop feedback” system 1500 of the present invention (ie, QoS is effectively incorporated into the VOD network). Here, dynamically monitored changes in network attributes and VOD behavior trigger “feedback” of changes to these VOD peer attributes and network attributes as well as changes in the deployment of content objects across the VOD network. Thus, a VOD peer has the ability of the network to deliver a specific content object (distributed in a package among its neighboring VOD peers) to its VOD peer within a predetermined time prior to every request. Can be identified.

  [359] It should also be noted that a cluster of VOD peers facilitates NQoS by providing an infrastructure that allows content to be placed “close to” consumers of that content. As noted above, the cluster is initially based on the existing Internet infrastructure (eg, based on that provided by the standard IP location service, and in part based on IP address similarity), but then , Dynamically updated to reflect actual network traffic and behavioral traffic. This infrastructure allows content objects to be distributed among groups of adjacent VOD peers and then dynamically redeployed to maintain their “closeness” as the network evolves (changes). Either “inclusive” in nature, such as device failure and network congestion, or behavioral in nature, eg, increased demand for some or all content during peak hours).

  [360] Regardless of the reason, the composition of clusters within the VOD network of the present invention evolves over time. Figures 16a-16d illustrate four different general pattern or configuration embodiments of clusters of VOD peers (grouped by trust level) that may result from different generic network and behavior scenarios.

  FIG. 16 a shows a “cone” pattern 1600. The “cone” pattern 1600 reflects what is likely to be a general scenario. In that scenario, a relatively small number of VOD peers in the cluster are very highly trusted VOD peers 1602 (eg, trust level “2”), and increasingly less reliable VODs in the cluster. Peers are found and the least reliable VOD peer 1604 (eg, trust level “10”) is the most numerous of these “trust level groups” in this cluster.

  [362] As noted above with respect to FIG. 12, similar to this, this relatively natural distribution of trust levels exists primarily due to the existing infrastructure of the Internet, but makes the content object package a relative proximity. Alternatively, it can be leveraged in the present invention to provide a mechanism for forming clusters (and sub-clusters) of VOD peers that can be stored based on internet distance from each other.

  [363] In addition, this inverse correlation of the number of VOD peers to their relative “trust level” indicates that a number of VOD peers (eg, the least reliable VOD) that are far from the Internet “core” but relatively close to each other. Facilitates grouping of peers 1604) into clusters. As a result, the VOD peers of FIG. 16a commonly share relatively close internet distances to each other despite the internet distance from the internet core.

  [364] Nevertheless, the existence of a large number of very highly unreliable VOD peers is unfortunately realistic but not always desirable. However, in the light of the present invention, this shortcoming is due to pushing more relatively copies of the content object to this large number of relatively unreliable VOD peers and more of this “equilibrium” management. Can be offset by delegating to a relatively reliable VOD peer.

  [365] Turning to FIG. 16b, this “cylindrical” pattern 1610 reflects a scenario where the cluster includes approximately the same number of VOD peers at each confidence level. Given the existing infrastructure of the Internet, it is unclear whether such a scenario is likely to occur naturally. This scenario is not desirable in that it is less concentrated in the least reliable VOD peer 1614 (eg, trust level “10”) as was present in FIG. Still, there are some problems in that there are VOD peers that are unreliable. On the other hand, there is a concentration of the most reliable VOD peers 1612 (eg, trust level “2”) as well as relatively more reliable VOD peers than those present in FIG. 16a.

  [366] However, having a large number of very reliable VOD peers is undesirable, but may not fully offset a large number of less reliable VOD peers. In other words, there is still a need to push content “close” to a number of less reliable VOD peers that consume that content. The fact that there are a large number of very reliable VOD peers requires pushing more copies of the content object down to these relatively large numbers of less reliable VOD peers.

  [367] Turning to FIG. 16c, this "sphere" pattern 1620 reflects the scenario. In that scenario, the majority of VOD peers have a reasonable level of trust (eg trust levels “4” to “8”) and a relatively small number of VOD peers are either very highly trusted or very low trusted. , The fewest VOD peers are either the most reliable VOD peer 1622 or the least reliable VOD peer 1624. Without some external mechanism (eg, a significant increase in fiber optic lines to the home) that allows a large number of otherwise unreliable VOD peers to become relatively very reliable, It is still unclear whether this scenario is very likely to occur naturally.

  [368] Nevertheless, this scenario is an extremely desirable scenario for NQoS (and even for QoS in general). Pushing copies to these many reasonably trusted VOD peers should be more efficient if fewer copies are needed (since these VOD peers are generally more reliable) It is. Moreover, higher overall reliability should require less adjustment to maintain NQoS.

  [369] Finally, the “polygon” pattern 1630 of FIG. 16d reflects a scenario in the cluster where there is substantially no correlation between the number of VOD peers and their relative “level of trust”. The distribution between confidence levels is inherently random. Also, it is unlikely that this scenario exists either naturally or through any external mechanism that is likely to be devised by someone.

[370] Nevertheless, the present invention provides a solution to this scenario that is at least as effective as the much more likely scenario shown in Figure 16a. Simply put, there is a lower concentration of the least reliable 1634 “problem” VOD peers. Furthermore, there is a higher concentration of the most trusted VOD peer 1632, though less important. The same cancellation mechanism, which involves pushing more copies of the content object to these “problem” VOD peers, is in NQoS despite the “pocket” of multiple VOD peers of other random trust levels. Should have the same benefit of affecting.
III. Integration of advertising content Advertising insertion architecture and features

  [371] Having described the main features of the various embodiments of the present invention that provide NQoS in the context of the VOD system, attention is now directed to one particular type of context object, the advertisement. A promotion is a special type of content object in one embodiment. Promotions can include text, images, audio, video, and virtually any combination of media elements that can be listened to and / or displayed.

  [372] In one respect, a promotion is just another content object in that it is delivered in much the same way as other content objects. Promotions are split into content object packages, pushed in VOD peers within and across clusters of networks, redeployed based on dynamically monitored network and behavior attributes, and their composition It is pulled in a distributed manner from a plurality of VOD peers in which element packages are stored.

  [373] However, in another respect, promotions can be displayed in and between other content objects and in other aspects of the user interface of the VOD system of the present invention. Is a content object. Promotions are also special in that they are not usually required by VOD peer users like other content objects. Alternatively, the promotion is in accordance with the parameters imposed by the publisher of the promotion, according to the rules imposed by the VOD system of the present invention (in one embodiment, via a "promotion server" which can be a separate server or a VOD support server). Is displayed.

  [374] FIG. 17 illustrates a block diagram embodiment of an advertisement insertion mechanism 1700. As shown in FIG. The advertisement insertion mechanism 1700 inserts advertisements as content objects in and between other content objects and within the user interface of the VOD system of the present invention. Promotion publisher 1710 is a VOD peer that, in one embodiment, is also a server that publishes “advertise” type content objects, such as promotion 1715.

  [375] In one embodiment, the advertisement 1715 can be inserted into a variety of different “target locations” 1720 including within and between content objects, such as the target content object 1722, as noted above. Further, advertisements 1715 can be inserted in one embodiment into a BARKER channel 1724, which is a permanently operating channel accessible from VOD peer users via the user interface of the VOD system of the present invention. Finally, advertisements 1715 can be inserted into various aspects of the user interface that appear on the target GUI area 1726, ie, the user's display, depending on the status of the system. For example, in one embodiment, the “VOD Portal” channel includes promotions that were seen in the previous week, and the user browses or searches for the promotions that were seen in the previous week, and then plays them. (Also by clicking on a link to a site containing commercial opportunities and / or additional information). Various embodiments of the method used to insert the advertisement 1715 into the target location 1720 are described in more detail below.

  [376] In one embodiment, the advertising publisher 1710 publishes its content object (advertisement 1715) in the same manner as other publishing servers, as described above. Further, the advertising publisher 1710 can rely on an “advertisement insertion tool” (in VOD publishing software available from all publishing servers) to simplify the advertising publishing process. In another embodiment, the promotion publisher 1710 may use various system resources (system database 1730 and system server) to facilitate the specification of parameters under which the advertisement 1715 is displayed to users of the VOD system of the present invention. 1740) may be accessed directly or indirectly. The rules for displaying the advertisement 1715 are determined by the advertisement server 1750 according to parameters specified by the advertisement publisher 1710 (directly specified or indirectly through the advertisement insertion tool) in one embodiment. Imposed.

  [377] In one embodiment, the advertising publisher 1710 accesses the system database 1730 to obtain information that affects the parameters that it specifies to the advertising server 1750. For example, the content object metadata 1732 database includes information related to each content object, such as title, genre, and description, and in one embodiment, various other metadata specifically related to the content object (text, image, Information in the form of video and other media. Promotion publisher 1710 may desire to display promotion 1715 in a content object that satisfies certain criteria, such as “comedy”, for example.

  [378] The advertising publisher 1710 specifies criteria such as parameters directly to the advertising server 1750 or searches the content object metadata 1732 database based on such criteria, and then the same or possibly some Can specify to the advertising server 1750 a parameter that can be specific (eg, the CRID of a specific content object). The advertising publisher 1710 can also combine the search results of the content object metadata 1732 database (or its original criteria) with other information such as data from other system databases 1730.

  [379] For example, the advertising publisher 1710 may access the user profile data 1734 database to name, gender, address, age, occupation, marital status, and various others specific to the user (and possibly the user's family). Information about VOD peer users, such as related data, can be obtained. The advertising publisher 1710 searches the content object metadata 1732 database for “comedy”, searches the user profile data 1734 database for users between the ages of 20 and 35, and possibly “dynamic behavior and other data. “A user can watch at least 5 movies per month from the 1736 database (allowing“ behavioral targeting ”of advertisements in a form based on the user's previous behavior in the VOD system). The advertising publisher 1710 can then present the combined results of such searches to the advertising server 1750 as a parameter.

  [380] In addition to relying on system database 1730 for information that facilitates targeting of advertisement 1715, advertisement publisher 1710 may also rely on various system servers 1740 to assist in this task in one embodiment. For example, as noted above, in addition to publishing the promotion 1715 (as with all other content objects), the promotion publisher 1710 can present parameters to the promotion server 1750, which (Promotion 1715 is usually required “on demand” like other content objects to trigger the display of promotion 1715 at the appropriate location of a particular VOD peer at the appropriate time according to the rules it enforces. So, such parameters are integrated into such rules.

  [381] In addition, promotional publisher 1710 implements "Digital Rights Management" (DRM) protection for promotional 1715 and user authentication and other related security measures to protect against unauthorized use of promotional 1715. Can rely on the license server 1742 to do this (as well as all other publishers). For example, in addition to general protection against unauthorized copying and distribution of such content, the license server 1742 may also use rules (eg, a limited number of times) to restrict the use of content objects according to parameters specified by the publisher. (Allow playback). Promotion publishers are usually not interested in limiting the exposure of their promotions. For example, the license server 1742 allows an unlimited number of playbacks of the advertisement 1715, but the advertisement publisher 1710 may have different advertisements (not shown) for all requested playbacks (eg, by the user requesting playback). If expressed interest, it may be required to be replaced by a more “forced sale” advertisement, possibly with a link to a commerce website.

  [382] The advertising publisher 1710 may rely on the metadata server 1744 to assist in accessing the content object metadata database 1732, for example. For example, rather than requiring the advertising publisher 1710 to query the content object metadata database 1732 itself, the metadata server 1744 provides a simpler higher level interface that allows indirect access to this data. It can be provided to the advertising publisher 1710.

  [383] In addition, the advertising publisher 1710 can rely on the payment / billing server 1746. Payment / billing server 1746 provides various “customer relationship management” (CRM) models for content objects, such as “pay per view” (PPV), subscription, prepaid access, free and paid promotions. The use of such functionality is more common with respect to publishers of other types of content objects, but the promotion publisher 1710 may, for example, promote a promotion 1715 that is displayed with a particular PPV movie on an optional basis ( For example, the payment / billing server 1746 can be used to launch a PPV movie for free when the user agrees to view a promotion, such as a promotion 1715.

  [384] The report server 1748 may have high value for the advertising publisher 1710 (as well as for publishers of other types of content objects). By specifying the report parameters, the advertising publisher 1710 can receive a variety of different types of reports from the report server 1748 regarding user behavior regarding the display of the advertisement, including the advertisement 1715. For example, such a report may include a profile of a user viewing a promotion at a specific date and time, the content object (or type of content object) they were viewing (the user is allowed to publish such aggregate information) ), And various other behavioral information (eg, click-through statistics for promotions, related purchases, etc.).

  [385] Finally, the promotional publisher 1710 can access a “direct purchase” promotion (eg, via a link in a promotion 1715 to a commercial website), a “video promotion window” (eg, other possibly relevant) Commercials related to Promotions 1715, including “In-Video Promotions” (to facilitate the insertion of Promotions 1715 into specific video content), and other commerce opportunities hosts A commercial transaction server 1749 can be relied upon to facilitate sales promotion.

[386] Note that access to the system server 1740, the system database 1730, and the target location 1720 is not restricted to the publisher of the advertisement. These resources are centrally located in one embodiment, from the publishing server, and from the VOD peers in general to a much more limited and indirect range (eg, accessing additional information about the content object via the system user interface) Is accessible. Publishers of other types of content objects may also limit which promotions (or types of promotions or publishers) can be viewed with their own content objects in one embodiment. For example, a family movie publisher may not allow promotions involving certain types of products (eg, tobacco or alcohol). Alternatively, family movie publishers may exclude certain promotional publishers that are known to promote such products.
B. Implementation of advertisement insertion

  [387] As noted above, in order to simplify the work of advertising publishers, this system (in one embodiment) is part of the VOD publishing software that is available from all public servers. "Insert tool" is provided. This advertisement insertion tool provides an interface that allows advertisement publishers to eliminate the need to communicate directly with system server 1740, system database 1730, and target location 1720. Instead, promotional publishers can take advantage of higher-level interfaces to accomplish their tasks more easily and more specifically targeting promotional publications.

  [388] In one embodiment, the promotional insertion tool provides a simplified user interface. This interface allows the promotion publisher to select a predefined choice from a drop-down list to specify parameters that define the way the publisher's promotion is targeted and presented to the VOD peer user. The advertisement insertion tool generates a “playlist” that selects advertisements from the advertisement publisher's “advertisement package” displayed on the VOD peer that matches the specified targeted profile during the specified time slot.

  [389] Promotions are usually published with a “leading” and “ending” part, which is a relatively short sequence (“start”) followed by (“end”) prior to the rest of the promotion being played. The promotion publisher can specify the promotion and the desired beginning and end IDs along with the promotion duration (eg, 30 seconds) and the desired target media into which the promotion is inserted. This desired target mediation may be, in one embodiment, an event (with or without a VOD browser), a “Barker” channel, a VOD messaging service (eg, for pure text promotion), “interactive advertising” (eg, Includes options to include additional information, promotions, special links, etc. via a VOD browser to the site), as well as promotional “printing” (outside of the VOD system).

  [390] In one embodiment, the basic promotion type is: (1) a single promotion independent promotion event, (2) a serial promotion, a sequence of up to five promotion repetitions inserted into one or more events, ( 3) Promotions with tagging Promotions with different end sequences (eg to “localize” promotions for different geographical zones), (4) Parallel promotions Multiple different promotions from the same promotion publisher with different end sequences, And (5) having interactive promotional links and / or other forms of “user response” functionality. Furthermore, in another embodiment, such promotional types can be provided in combination.

  [391] Serial promotions increase the interest of an entire publisher (as well as multiple events) by repeating the promotion over time (or slightly different promotions in one embodiment) over time. to enable. Different promotional tails can be of incremental interest, for example by announcing contest details or other information towards the end of the sequence. Tagged promotions allow local offers, and parallel promotions facilitate the desire of advertising publishers to provide promotions that promote certain product lines, for example using different advertising tails. Interactive advertising provides information to the user incrementally and can be used dynamically to further promote the product of the advertising publisher in one embodiment (in one embodiment, specific targeted feedback about the user's interests). ) To provide additional opportunities to obtain.

  [392] In another embodiment, some form of "direct publishing" can be enabled. This greatly simplifies the ability of non-professional publishers to publish content objects and promotions from handheld devices and other devices that are not normally part of the VOD network. For example, in the light of sidestream sports, sports events (e.g., possibly horse racing with local promotions) may be uploaded that provide opportunities that would otherwise require huge advertising budgets. Similarly, a small retail store can publish a “speak and sell” promotion of a specific product, combined with advertising from the store via a cell phone with video capabilities.

  [393] The targeting method utilized by the promotional insertion tool, in one embodiment, uses various statistics related to VOD peer users (eg, stored in the user profile data 1734 database). Such statistics provide a mechanism for targeting promotions to various aspects of the user profile. For example, such statistics can include the total number of users and the average number of events seen per user (also divided by geographic zone) over a time interval (eg, a week). In addition, such statistics include gender percentage (male vs female), age (eg, 18-25, 25-54, over 55), household income (eg, over $ 50,000, over $ 75,000, $ 100,000 or more, $ 150,000 or more), education (eg, university graduate, graduate), marital status, children, and behavioral VOD usage (eg, consumer category, previous week system usage, last 30 days or Traditional online shopping habits).

  [394] Further, in one embodiment, a “VOD user profile category” is defined by combining user profile data. For example, defining “couples”, “family”, “single”, and “children” as VOD user profile categories divided into fixed age ranges, countries, geographic zones, and specific areas of interest. it can. In addition, the promotional publisher can specify certain constraints on the promotional campaign (eg, start date, stop date, effective date, government constraints on geographic zones, categories, hours, etc.).

  [395] Finally, promotional publishers can select from a variety of demographic information to target their promotions to a particular set of VOD peer users. Such demographic information can then be cross-referenced (as described below) with the actual VOD peer user profile statistics described above. For example, in one embodiment, the following demographic categories are included: gender (male and female), age (18-24, 18-34, 18-49, 25-34, 25-44, 25-54, 45-54. 45-64, 21 or more, 25 or more, 35 or more, 45 or more, 55 or more, 65 or more), marital status (married, single), children (yes / no), education (high school, university graduate, graduate, university graduate) Above), occupation (profession / manager, sales / retail, secretary / office work, service / labor, student, retirement, self-employed), income (currency type, over $ 35,000, over $ 50,000, over 70,000) $ 5,000 or more, $ 100,000 or more, $ 150,000 or more), geographical zones, etc.

  [396] To better understand how promotions are inserted within and between events (and within the Barker channel and other target locations), the metadata associated with such promotions is This will be described below. In one embodiment, such promotional metadata includes: “comprehensive promotional metadata” (describing promotions), “event promotional handling metadata” (describing constraints on promotions presented within events), “promotional XML tags for "targeted user profile metadata" (which describes the VOD peer user profile data to which the promotion is targeted) and "advertisement insertion list metadata" (including the block in the event where the promotion is inserted).

[397] In one embodiment, the generic promotion metadata includes the following tags that describe a data structure that stores data describing each promotion.

[398] Event promotion handling metadata includes the following tags that describe a data structure that describes the location within the event where the promotion can be inserted.

[399] The promotion targeted user profile metadata includes the following tags that describe the data structure that describes the user profile to which the promotion is targeted.

[400] The advertisement insertion list metadata includes the following tags that describe a data structure that describes the location within the event where the advertisement can be inserted.

  [401] In one embodiment, a promotional publisher can “sponsor” an event as well as other aspects of the user interface of the system. For example, a “sponsored theme” can include a commercial “skin” created by an advertising publisher and available for selection by VOD peer users. This skin can encompass substantially all of the user interface elements accessible to the user. A viewer can download these skins, which then appear in the main menu of the user interface. Skins include existing system elements such as background images, icons, logos, and other elements that integrate the advertising publisher's logo (or other form of representation or style) (eg, play and stop buttons) ) Can be included.

  [402] Such sponsored themes can provide additional interactive elements that allow users to obtain additional information that promotes products offered by promotional publishers. In addition to including promotions in the Barker channel, other promotions such as games, contests, and lotteries can also be provided.

  [403] In one embodiment, a "sponsored event" is a case where a promotional publisher is exposed to a free viewing of an event (eg, published by another publisher, for example, in exchange for viewing the promotion of that promotional publisher). It is possible to provide popular movies that will be released soon. For example, a content object that would otherwise be available only as a PPV movie on the VOD network could be offered as a sponsored event from a particular advertising publisher, allowing the user to accept the promotion himself. In exchange for that, the event can be viewed free of charge. In one embodiment, the promotion includes an on-screen logo, insertion of “infotainment” material, interactive questions to the user, links to further promotions or business opportunities, and possibly user activity. Agreement to receive follow-up advertising viewing, emails, etc. can be included.

  [404] In addition to sponsored events, an advertising publisher is a single criterion in which a group of events (eg, sharing a relationship in common with an advertising publisher's product or service) also includes advertising or possibly skins. A “branded channel” can also be generated, available from a point (eg, a channel logo).

  [405] In other embodiments, over time, the user may accept advertisements and related promotional events (eg, advertisements for products or services that the user may otherwise be interested in). Additional promotions are possible, including longer-term promotional campaigns that can increase “points”. Such points can be considered for free viewing on the VOD network as well as prizes, discounts, etc. Such promotions provide advertising publishers with highly targeted opportunities to promote their products and services, while at the same time “selecting” whether the user accepts advertisements and other promotions. Enable.

[406] By integrating promotions into a VOD network as a type of content object, the advertising publisher's products and services are highly targeted and efficient without obstructing the user's ability to view the content object on the system. There is a virtually unlimited number of possibilities to promote in form (including a wide range of targeted tracking and reporting capabilities). Users are provided with the opportunity to “leave” from promotional activities, but (more importantly) are motivated to “subscribe” to such activities in exchange for free viewing. Product and service discounts, as well as a host of other creative opportunities, are devised for their highly targeted customers by advertising publishers.
wrap up

  [407] The present invention uses multiple dynamic content packaging and load balancing systems and methods designed to enable the distribution of large volumes of digital content over the Internet while maintaining high QoS. The present invention is applicable not only to VOD applications, but also to many other content distribution applications and related applications, especially applications that benefit from digital content being “closer” to the end user of such content. is there.

  [408] The content objects are divided into groups of component packages, which are grouped into adjacent network peer clusters to increase QoS when such content is later retrieved (ie, pulled). Distributed (ie, pushed). Tracking files (maintaining a list of network peers that store groups of such packages) and tracking indexes (maintaining a list of network peers that store tracking files) are “on demand” ( And is maintained and updated to facilitate retrieval).

  [409] In addition, general and application specific network traffic is dynamically monitored (eg, including behavioral aspects of VOD functionality as well as bandwidth and reliability), and the results are fed back to the system for effectiveness. A “distributed closed-loop feedback” system. In response to such distributed dynamic monitoring, attributes of individual network peers (such as peer trust level and membership within a particular cluster of neighboring peers) have been changed and various "content balancing" functions Are performed (such as redistribution of groups of packages of content objects among various network peers).

[410] The result is to effectively incorporate QoS into a peer network that relies on an existing Internet infrastructure that itself does not provide QoS. Such network QoS (NQoS) allows network peers to have specific content objects (distributed in groups of component packages among their neighboring VOD peers) prior to every request to that peer. It makes it possible to identify the network's ability to distribute within a predetermined time.
Example

[Example 1]
A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); A content pusher that distributes a first group of component packages to a first network node and distributes a second group of component packages to a second network node;
(B) in response to a request by a third network node relating to the reproduction of the first content object, searching for a first group and a second group of the component package, and the first group on the first network node Identifying the location of each of the second groups on the second network node and retrieving the first group and the second group for ordered playback of the first content objects on the third network node; Content puller,
With
(C) This allows the digital content distribution system to allow the third network node to start playing the first content object before receiving the second group of component packages.
Digital content distribution system.
[Example 2]
A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); ) Distributing a first group of component packages to a first network node and distributing a second group of component packages to a second network node (the first network node and the second network node are Located in a first cluster of relatively adjacent network nodes), a content pusher;
(B) in response to a request by a third network node (the third network node is also located in the first cluster) for playback of the first content object, the first group and the second of the component packages Search for a group, identify a location of each of the first group on the first network node and the second group on the second network node in the first cluster, and at the third network node A content puller that retrieves the first group and the second group for ordered playback of a first content object;
With
(C) Thereby, in the digital content distribution system, the third network node is
(I) start playing the first content object before receiving the second group of the component packages;
(Ii) retrieving the first content object for substantially immediate and continuous playback (the playback is the first content object in the first cluster prior to the playback request by the third network node) Partial due to the presence of)
Make it possible,
Digital content distribution system.
[Example 3]
A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); A content pusher that distributes a first group of component packages to a first network node and distributes a second group of component packages to a second network node;
(B) a first tracking file including the location of each of the first group of component packages on the first network node and the second group of component packages on the second network node; A content tracker that generates a first tracking index that includes the location of one or more network nodes where the tracking file is stored;
(C) in response to a request by a third network node relating to playback of the first content object, to search for a first group and a second group of the component package; Identifying the location of each of the second groups on a second network node (the identification being made by locating the first tracking file, either directly or indirectly via the first tracking index), and A content puller that retrieves the first group and the second group for ordered playback of the first content objects on three network nodes;
With
(D) This allows the digital content distribution system to allow the third network node to start playing the first content object before receiving the second group of component packages.
Digital content distribution system.
[Example 4]
A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); A content pusher that distributes a first group of component packages to a first network node and distributes a second group of component packages to a second network node;
(B) in response to a request by a third network node relating to the reproduction of the first content object, searching for a first group and a second group of the component package, and the first group on the first network node Identifying the location of each of the second groups on the second network node and retrieving the first group and the second group for ordered playback of the first content objects on the third network node; Content puller,
(C) a network monitor observing communications involving the third network node (the communications include behavioral application specific network traffic and general network bandwidth and connection reliability tests);
(D) in response to information verified by the network monitor;
(I) updating a first set of attributes of the third network node, including a trust level that reflects the reliability of the third network node over time;
(Ii) a task of redistributing the first content object among the network nodes by changing the number and location of copies of one or more packages of the first content object;
A dynamic feedback controller that executes one or more of:
With
(E) Thereby, in the digital content distribution system, the third network node sends the first content object to the third network node at a predetermined time interval prior to the request for reproduction of the first content object. Providing network quality of service (NQoS) by allowing identification of the system's ability to deliver within
Digital content distribution system.
[Example 5]
A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) Dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages) A content pusher that distributes the first group of packages to a first network node and distributes the second group of component packages to a second network node;
(B) in response to a request by a third network node relating to playback of the first content object, to search a first group and a second group of the component package of the first content object, on the first network node Identifying the location of each of the first group and the second group on the second network node, and for the ordered playback of the first content object on the third network node, the first group and the Take out the second group, content puller,
With
(C) The content pusher also divides the second linear content object that is an advertisement into a first group and a second group of component packages (the first group of the second content object package is the second group Distribution of the first group of the second content object packages to the fourth network node and the second group of the second content object packages to the second Distributed to 5 network nodes,
(D) The content puller also searches the first group and the second group of packages of the second content object in response to the request by the third network node relating to playback of the first content object. Identifying a location of each of the first group of packages of the second content object on the fourth network node and a second group of packages of the second content object on a fifth network node; Taking out the first group and the second group of packages of the second content object for ordered playback of the second content object on three network nodes;
(E) This allows the digital content distribution system to allow the third network node to automatically receive the advertisement in response to its request for playback of the first content object;
The advertisement is itself a linear content object (the second content object), is distributed by the content pusher in substantially the same manner as the first content object, and is played back on the third network node. To be retrieved by the content puller,
Digital content distribution system.
[Example 6]
(A) the first network node and the second network node are arranged in a first cluster of network nodes relatively close to each other;
(B) the content puller determines a position of each of the first group of the component packages on the first network node in the first cluster and the second group of the component packages on the second network node; Identify and
(C) Thereby, in the digital content distribution system, the third network node is
(I) start playing the first content object before receiving the second group of the component packages;
(Ii) retrieving the first content object for substantially immediate and continuous playback (the playback is the first content object in the first cluster prior to the playback request by the third network node) Partial due to the presence of)
Make it possible,
The digital content distribution system described in the third embodiment.
[Example 7]
The digital content delivery system of embodiment 1, wherein the first group of component packages is smaller than the second group of component packages.
[Example 8]
The digital content distribution system according to the seventh embodiment, wherein the component package of the first content object is a variable-size package.
[Example 9]
8. The embodiment of example 7, wherein the component package of the first content object is a fixed size package, and the first group of component packages includes fewer packages than the second group of component packages. Digital content distribution system.
[Example 10]
The digital content distribution system according to embodiment 2, wherein each of the network nodes includes a cluster controller that performs substantially the same function as that performed by both the content pusher and the content puller.
[Example 11]
The digital content of embodiment 4, wherein the third network node includes a graphical user interface that displays to the user of the third network node an indicator of the relative time required to start playing the first content object. Distribution system.
[Example 12]
The digital content distribution system according to the fourth embodiment, wherein the network monitor starts and observes ping communication and traceroute communication from the third network node over time.
[Example 13]
5. The digital content delivery system of embodiment 4, wherein the behavioral application specific network traffic observed by the network monitor includes a request for playback of a content object initiated by the third network node over time.
[Example 14]
The digital content distribution system according to embodiment 5, wherein the reproduction of the second content object occurs during the reproduction of the first content object.
[Example 15]
The third network node graphically displays to the user of the third network node a link that the user can click to activate playback of the second content object during the playback of the first content object. The digital content distribution system according to embodiment 5, including a user interface.
[Example 16]
A method of retrieving a linear content object on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); ) Distributing the first group of component packages to a first network node and distributing the second group of component packages to a second network node;
(B) in response to a request by a third network node relating to the reproduction of the first content object, searching for a first group and a second group of the component package, and the first group on the first network node Identify the location of each of the second groups on the second network node and retrieve the first group and the second group for ordered playback of the first content objects on the third network node Including steps,
(C) Thereby, the method for retrieving a linear content object allows the third network node to start playing the first content object before receiving the second group of packages;
Method.
[Example 17]
A method of retrieving a linear content object on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); ) Distributing a first group of component packages to a first network node and distributing a second group of component packages to a second network node (the first network node and the second network node are Placed in a first cluster of relatively adjacent network nodes;
(B) in response to a request by a third network node relating to playback of the first content object, to search for a first group and a second group of the component package, on the first network node in the first cluster Identifying the location of each of the first group and the second group on the second network node, and for the ordered playback of the first content object on the third network node, the first group and the Retrieving a second group;
Including
(C) Thereby, in the method for retrieving a linear content object, the third network node
(I) start playing the first content object before receiving the second group of the component packages;
(Ii) retrieving the first content object for substantially immediate and continuous playback (the playback is the first content object in the first cluster prior to the playback request by the third network node) Partial due to the presence of)
Make it possible,
Method.
[Example 18]
A method of retrieving a linear content object on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); ) Distributing a first group of component packages to a first network node and distributing a second group of component packages to a second network node;
(B) a first tracking file including the location of each of the first group of component packages on the first network node and the second group of component packages on the second network node; and the first tracking Generating a first tracking index that includes the location of one or more network nodes where the file is stored;
(C) in response to a request by a third network node relating to playback of the first content object, to search for a first group and a second group of the component package; Identifying the location of each of the second groups on the second network node (the identification being made by locating the first tracking file, either directly or indirectly through the first tracking index), and Retrieving the first group and the second group for ordered playback of the first content object at a third network node;
Including
(D) This allows the method of retrieving a linear content object to allow the third network node to start playing the first content object before receiving the second group of component packages.
Method.
[Example 19]
A method of retrieving a linear content object on demand for ordered playback on a network node,
(A) dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages); ) Distributing the first group of component packages to a first network node and distributing the second group of component packages to a second network node;
(B) in response to a request by a third network node relating to the reproduction of the first content object, searching for a first group and a second group of the component package, and the first group on the first network node; Identifying the location of each of the second groups on the second network node and retrieving the first group and the second group for ordered playback of the first content objects on the third network node When,
(C) observing communications involving the third network node (the communications include behavioral application specific network traffic and general network bandwidth and connection reliability testing);
(D) in response to information ascertained by the observation of communications involving the third network node;
(I) updating a first set of attributes of the third network node, including a trust level that reflects the reliability of the third network node over time;
(Ii) a task of redistributing the first content object among the network nodes by changing the number and location of copies of one or more packages of the first content object;
Performing one or more of:
Including
(E) Thereby, in the method for retrieving a linear content object, the third network node sends the first content object to the third network node in advance of the request for reproduction of the first content object. Providing network quality of service (NQoS) by allowing identification of the system's ability to deliver within a time interval;
Method.
[Example 20]
A method of retrieving a linear content object on demand for ordered playback on a network node,
(A) Dividing the first linear content object into a first group and a second group of component packages (the first group of component packages occurs in an order before the second group of component packages) Distributing and distributing a first group of the component packages to a first network node and a second group of the component packages to a second network node;
(B) in response to a request by a third network node relating to playback of the first content object, to search a first group and a second group of the component package of the first content object, on the first network node Identifying the location of each of the first group and the second group on the second network node, and for the ordered playback of the first content object on the third network node, the first group and the Retrieving a second group;
(C) dividing the second linear content object, which is an advertisement, into a first group and a second group of component packages (the first group of the second content object package is the second of the second content object package); Distributing a first group of packages of the second content object to a fourth network node and distributing a second group of packages of the second content object to a fifth network node, which occur in an order prior to the group) When,
(D) in response to the request by the third network node relating to the reproduction of the first content object, searching the first group and the second group of the package of the second content object; Identifying a location of each of the first group of packages of the second content object on and the second group of packages of the second content object on the fifth network node; Retrieving the first group and the second group of packages of the second content object for ordered playback of the second content object;
Including
(E) Thereby, the method of retrieving a linear content object enables the third network node to automatically receive the advertisement in response to its request for playback of the first content object;
The advertisement is itself a linear content object (the second content object), distributed in substantially the same manner as the first content object, and retrieved for playback on the third network node. ,
Method.
[Example 21]
(A) placing the first network node and the second network node in a first cluster of network nodes relatively close to each other;
(B) identifying a location of each of the first group of component packages on the first network node in the first cluster and the second group of component packages on the second network node;
Further including
(C) Thereby, in the method for retrieving a linear content object, the third network node
(I) start playing the first content object before receiving the second group of the component packages;
(Ii) retrieving the first content object for substantially immediate and continuous playback (the playback is the first content object in the first cluster prior to the playback request by the third network node) Partial due to the presence of)
Make it possible,
The method described in Example 18.
[Example 22]
17. The method of retrieving linear content objects according to example 16, wherein the first group of component packages is smaller than the second group of component packages.

[Example 23]
The method of retrieving a linear content object according to embodiment 22, wherein the component package of the first content object is a variable size package.

[Example 24]
23. The embodiment of example 22, wherein the component package of the first content object is a fixed size package, and the first group of component packages includes fewer packages than the second group of component packages. How to retrieve a linear content object.
[Example 25]
Each of the network nodes performs a linear content object according to example 17 that performs substantially the same functions as those performed to divide, distribute, place, and retrieve the first content object. How to take out.
[Example 26]
The method of retrieving a linear content object according to embodiment 19, further comprising displaying an indicator of a relative time required to start playback of the first content object to a user of the third network node.
[Example 27]
20. The method of retrieving linear content objects as described in embodiment 19, wherein the observed communications include ping communications and traceroute communications initiated from the third network node over time.
[Example 28]
20. The method of retrieving a linear content object as described in embodiment 19, wherein the behavior application specific network traffic includes a request for playback of a content object initiated by the third network node over time.
[Example 29]
21. The method of retrieving a linear content object according to embodiment 20, wherein the reproduction of the second content object occurs during the reproduction of the first content object.
[Example 30]
The third network node displays to the user of the third network node during the playback of the first content object a link that the user can click to activate playback of the second content object; A method for extracting a linear content object described in the twentieth embodiment.

10 ... end user client node,
16 ... Publication server,
15 ... VOD peer,
20 ... Local Internet service provider (local ISP),
30 ... Regional Internet Service Provider (REG ISP),
40 ... Backbone (BB) router,
55 ... VOD support server,
100 ... dedicated VOD server,
301 ... highest confidence level,
302 ... trust level 2-5,
303 ... trust level 6-9,
304: Trust level 12,
305 ... trust level,
310 ... super cluster,
320 ... cluster,
410 ... The first group “A”,
420 ... Group "B"
430 ... Group "C"
440 ... Last group "D"
450 ... Cluster,
460 ... VOD peer,
470 ... VOD peer,
475 ... requesting VOD peer,
500 ... Node ID data structure,
501 ... Node ID,
505 ... position,
510 ... fixed part,
512 ... Box ID,
514 ... country,
516… Region,
518 ... ISP,
520 ... City,
522 ... Zip code,
524 ... longitude / latitude,
526 ... Node type,
550 ... descriptor,
552 ... IP address,
554 ... trust level,
556 ... Local node accessibility,
558 ... Global node accessibility,
560 ... Net measurement,
600 ... CRID,
601 ... CRID,
605 ... position,
610: Core CRID,
612 ... Publisher ID,
614 ... event selector,
620 ... descriptor,
625 ... main descriptor,
626 ... Publication zone,
628 ... Publication rights,
635 ... Publisher descriptor,
636: Publisher priority,
638 ... Publisher category,
645 ... end descriptor,
646 ... Content object type,
710 ... field,
720 ... "Node 1" IP address,
725 ... Value for each package group,
730 ... "Last" entry,
800 ... Tracking index data structure,
810 ... row,
815 ... CRID,
820 ... "Final" line,
910 ... Node A,
920 ... Node B,
930 ... Phase H1,
940 ... Phase H2,
950 ... Phase H3,
1005 ... Publication server,
1010 ... VOD support server,
1015 ... Node F,
1020 ... Node A,
1032 ... first communication,
1033 ... communication,
1036 ... communication,
1038 ... communication,
1039 Communication,
1050 ... communication protocol,
1055 ... Publication server,
1060 ... Node A,
1065 ... Node B,
1070 ... Node C,
1071 ... communication,
1072 ... communication,
1074 ... communication,
1075 ... communication,
1077 ... communication,
1078 ... communication,
1082 ... communication,
1083 ... response,
1086 ... communication,
1087 ... response,
1091 ... communication,
1092 ... communication,
1094 ... communication,
1100 ... Content object,
1110 ...
1120 ... End,
1150 ... VOD peer,
1200 ... relatively natural distribution of confidence levels,
1250: Intermediate confidence level,
1260: VOD support server,
1270 ... the most reliable level of trust,
1280 ... the least reliable level of confidence,
1300: Communication protocol,
1305 ... Node A,
1310 ... Node B,
1315 ... Node C,
1322 ... communication,
1323 ... communication,
1325 ... communication,
1326 Communication,
1350: communication protocol,
1355 ... Node A,
1360 ... Node B,
1372 ... communication,
1373 ... communication,
1376 ... communication,
1377 ... communication,
1378 ... communication,
1400 ... Pull download scenario,
1410 ... VOD peer,
1420 ... Feeder VOD peer,
1425 ... Deputy or fallback VOD peer,
1430: Feeder VOD peer,
1435 ... Deputy VOD peer,
1500 ... distributed closed loop feedback system,
1510 ... VOD peer,
1510a ... VOD peer,
1510b ... VOD peer,
1510c ... VOD peer,
1520 ... Cluster controller,
1525 ... Dynamic network monitoring,
1530 ... change,
1532 ... Dynamic network monitoring result database,
1534 ... feedback,
1536 ... Trust level change,
1538 ... package distribution change,
1539 ... other changes,
1600 ... "conical" pattern,
1602 ... very reliable VOD peer,
1604 ... the most unreliable VOD peer,
1610 ... "Cylinder" pattern,
1612 ... The most reliable VOD peer,
1614 ... the most unreliable VOD peer,
1620 ... "sphere" pattern,
1622 ... The most reliable VOD peer,
1624 ... the most unreliable VOD peer,
1630 ... "polygon" pattern,
1632 ... The most trusted VOD peer,
1634 ... the most unreliable VOD peer,
1700 ... Advertising insertion mechanism,
1710 ... Advertising publisher,
1715 ... advertising,
1720 ... target position,
1722 ... Target content object,
1724 ... Barker Channel,
1726: Target GUI area,
1730 ... System database,
1732 ... Content object metadata,
1734: User profile data,
1736 ... Dynamic behavior and other data,
1740: System server,
1742: License server,
1744: metadata server,
1746 ... payment / billing server,
1748: Report server,
1749 ... commerce server,
1750 advertising server

Claims (2)

A method implemented by a digital content distribution system that retrieves linear content objects on demand for ordered playback on a network node, comprising:
(A) dividing the first linear content object into first and second groups of components the package, a first group of said component package is generated in the second than the group before the order of the previous SL component package is intended to distribute the second group of the component package as well as distributing the first group of the component package to the first network node to a second network node, the steps,
(B) in response to a request by a third network node relating to playback of the first linear content object, searching for a first group and a second group of the component package, and the first group on the first network node and the second identifying the respective positions of the second group of nodes on the network, the third the first and second groups for ordered playback of the first linear content object at the network node A step of taking out
Comprising the steps of: observing communications comprising (c) the third network node, wherein the communication includes behavior application-specific network traffic and general network bandwidth and connection reliability of the test, the steps,
(D) in response to information ascertained by the observation of communications involving the third network node;
(I) a task to update a trust level reflecting a temporal trust level factor of the third network node;
(Ii) by changing the number and position of one or more packages of copies of the first linear content object, redistributing the first linear content object between said first network node and the second network node Task and
Performing one or more of:
(E) Thus, the method of retrieving linear content objects, the third network node, prior to the request for reproduction of the first linear content object, the first linear content object to the third network node A method of providing network quality of service (NQoS) by enabling identification of a network capability of the digital content delivery system to deliver within a predetermined time interval. A digital content delivery system that retrieves linear content objects on demand for ordered playback on a network node,
(A) is divided into first and second groups of first linear content object components package, the first group of packages occurs prior order than said second group of packages is intended to distribute the first group of packages to a first network node, distributing the second group of packages to a second network node, and content pusher,
(B) in response to a request by a third network node seeking to play the first linear content object, the first and second groups of packages are searched and the first network node on the first network node Identifying the position of each of the first group and the second group on the second network node, and for the ordered playback of the first linear content object on the third network node A content puller for retrieving the second group and the second group;
(C) a network monitor for observing the communication including the third network node, said communication includes behavior application-specific network traffic and general network bandwidth and connection reliability test, and a network monitor,
(D) in response to the information confirmed by the network monitor,
(I) a task to update a trust level that reflects a trust level factor over time of the third network node;
(Ii) the first linear content the first linear content object between one or more packages of the first by changing the number and location of the copy of the network node and the second network node for the object A dynamic feedback controller that performs one or more of the tasks to be redistributed ,
(E) Thereby, in the digital content distribution system, the third network node sends the first linear content object to the third network prior to the request for reproduction of the first linear content object. A digital content delivery system that provides network quality of service (NQoS) by enabling identification of the network 's ability of the digital content delivery system to deliver to a network node within a predetermined time interval.