Datacast distribution system Number:7,437,549 from the United States Patent and Trademark Office (PTO) owispatent According to the present invention there is provided a datacast distribution system which allows for the distribution of movies, music, games, application software, and the like using a new or existing terrestrial digital video broadcasting (DVB-T) network or the like.<H distribution, Datacast, Datacast, distri, 7437549.html, Patent, pto, 7437549

Title: Datacast distribution system

Abstract: According to the present invention there is provided a datacast distribution system which allows for the distribution of movies, music, games, application software, and the like using a new or existing terrestrial digital video broadcasting (DVB-T) network or the like.

Patent Number: 7,437,549 Issued on 10/14/2008 to Lindqvist, et al.

Inventors: Lindqvist; Markus (Helsinki, FI), Prokki; Kai-Uwe (Espoo, FI), Soinio; Markku (Espoo, FI), Muller; Dominique (Helsinki, FI)
Assignee: Nokia Corporation (Espoo, FI)

Appl. No.: 10/268,499

Filed: October 10, 2002

Related U.S. Patent Documents


Application Number	Filing Date	Patent Number	Issue Date
09974554	Oct., 2001	7343487

Current U.S. Class: 713/153 ; 380/277; 380/280; 713/160; 713/193

Current International Class: H04L 9/00 (20060101); G06F 11/30 (20060101); H04N 7/24 (20060101); H04Q 7/22 (20060101)

Field of Search: 713/153,160,163,193 380/201,231,277

References Cited [Referenced By]

U.S. Patent Documents


4429385	January 1984	Cichelli et al.
5128776	July 1992	Scorse et al.
5717925	February 1998	Harper et al.
5729549	March 1998	Kostreski et al.
5745694	April 1998	Egawa et al.
5757907	May 1998	Cooper et al.
5761602	June 1998	Wagner et al.
5797010	August 1998	Brown
5822324	October 1998	Kostresti et al.
5830068	November 1998	Brenner et al.
5845267	December 1998	Ronen
5914712	June 1999	Sartain et al.
5935206	August 1999	Dixon et al.
5945987	August 1999	Dunn
5946326	August 1999	Rinne
6005631	December 1999	Anderson et al.
6052715	April 2000	Fukui et al.
6055543	April 2000	Christensen et al.
6115486	September 2000	Cantoni
6157377	December 2000	Shah-Nazaroff et al.
6160545	December 2000	Eyer et al.
6169843	January 2001	Lenihan et al.
6212548	April 2001	DeSimone et al.
6226618	May 2001	Downs et al.
6240416	May 2001	Immon et al.
6256509	July 2001	Tanaka et al.
6393562	May 2002	Maillard
6834110	December 2004	Marconcini et al.
2001/0025256	September 2001	Oliphant et al.
2001/0025349	September 2001	Sharood et al.
2002/0015042	February 2002	Robotham et al.
2002/0016972	February 2002	Ogawa et al.
2002/0023270	February 2002	Thomas et al.
2002/0131387	September 2002	Pitcher et al.
2003/0002862	January 2003	Rodriguez et al.
2003/0009380	January 2003	Suzuki et al.
2003/0050058	March 2003	Walsh et al.
2005/0028195	February 2005	Feinleib et al.

Foreign Patent Documents


199940190	Mar., 2000	AU
195 09 709	Sep., 1995	DE
0 680 185	Nov., 1995	EP
0 710 017	May., 1996	EP
0 745 412	Dec., 1996	EP
0 745 948	Dec., 1996	EP
0 752 787	Jan., 1997	EP
0 802 677	Oct., 1997	EP
0 858 225	Aug., 1998	EP
0 866 614	Sep., 1998	EP
0 873 772	Oct., 1998	EP
0 920 891	Jun., 1999	EP
0 921 657	Jun., 1999	EP
0988 876	Mar., 2000	EP
0 998 145	May., 2000	EP
0649 102	May., 2000	EP
1 005 885	Jun., 2000	EP
1 026 707	Aug., 2000	EP
1 026 886	Aug., 2000	EP
1 026 892	Aug., 2000	EP
1 026 896	Aug., 2000	EP
1 028 589	Aug., 2000	EP
1 037 461	Sep., 2000	EP
1 037 462	Sep., 2000	EP
1 041 791	Oct., 2000	EP
1 043 911	Oct., 2000	EP
1 043 924	Oct., 2000	EP
1 045 339	Oct., 2000	EP
1 045 582	Oct., 2000	EP
1 045 584	Oct., 2000	EP
1 049 276	Nov., 2000	EP
1 050 328	Nov., 2000	EP
1 052 854	Nov., 2000	EP
1 054 553	Nov., 2000	EP
1 056 279	Nov., 2000	EP
1 059 729	Dec., 2000	EP
2 343 809	May., 2000	GB
10-209987	Aug., 1998	JP
500442	Mar., 2000	NZ
WO 95/01058	Jan., 1995	WO
WO 95/13681	May., 1995	WO
WO 96/34486	Oct., 1996	WO
WO 97/23052	Jun., 1997	WO
WO 98/57718	Dec., 1998	WO
WO 99/14775	Mar., 1999	WO
WO 99/14874	Mar., 1999	WO
WO 99/22512	May., 1999	WO
WO 99/33076	Jul., 1999	WO
WO 99/37048	Jul., 1999	WO
WO 99/49663	Sep., 1999	WO
WO 99/51030	Oct., 1999	WO
WO 00/03482	Jan., 2000	WO
WO 00/07361	Feb., 2000	WO
WO 00/08848	Feb., 2000	WO
WO 00/24195	Apr., 2000	WO
WO 00/26813	May., 2000	WO
WO 00/38430	Jun., 2000	WO
WO 00/51057	Aug., 2000	WO
WO 00/64177	Oct., 2000	WO
WO 00/79831	Dec., 2000	WO
WO 01/22632	Mar., 2001	WO
WO 02/01879	Jan., 2002	WO
WO 02/03728	Jan., 2002	WO
WO 02/03729	Jan., 2002	WO
WO 2004042618	May., 2004	WO

Other References

Christoph Neumann, Vincent Roca, Rod Walsh, "Large Scale Content Distribution Protocols", Oct. 2005, ACM SIGCOMM Computer Communication Review, vol. 35 Issue 5, pp. 85-92. cited by examiner .
English language Abstract corresponding to DE 195 09 709. cited by other.

Primary Examiner: Moise; Emmanuel L
Assistant Examiner: Fields; Courtney D
Attorney, Agent or Firm: Morgan & Finnegan, L.L.P.

Parent Case Text

This application is a continuation-in-part of, and claims the benefit of U.S. application Ser. No. 09/974,554 filed on Oct. 10, 2001, which is now U.S. Pat. No. 7,343,487.

Claims

What is claimed is:

1. A method for distributing content files to a terminal, comprising: associating with each of a plurality of content files a metadata file, wherein each of the metadata files is associated with a unique identifier; receiving at the terminal a specification of content of interest to a user, said specification being in terms of metadata keywords; searching said metadata files for said keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a portion of one of said content files; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; providing individuals with software for formulating content, said software producing for each item of formulated content descriptive attributes; distributing to receiving terminals the formulated content, and descriptive attributes produced with said software; allowing users of the receiving terminals to specify attributes corresponding to content of potential interest; and allowing the users of the receiving terminals to configure the receiving terminals to only display content whose descriptive attributes match the specified attributes, wherein at least one of the content files comprises content formulated using said software, wherein chat messages are formulated using said software.

2. A method for distributing content files to a terminal, comprising: associating with each of a plurality of content files a metadata file, wherein each of the metadata files is associated with a unique identifier, and wherein the content files are selected by a content provider; receiving at the terminal a specification of content of interest to a user, said specification being in terms of metadata keywords; searching said metadata files for said keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a portion of one of said content files; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; allowing the content provider to view available bandwidth in a network of a broadcast system; allowing the content provider to, by defining a certain amount of bandwidth between a stated start time and a stated end time, allocate bandwidth for a broadcast program in one or more network areas; and allowing said content provider to view network topology.

3. The method of claim 2, wherein said network topology corresponds to a certain area of said network.

4. The method of claim 2, wherein said network topology corresponds to all of said network.

5. A terminal for receiving at least one content file, comprising: a memory having program code stored therein; a processor operatively connected to said memory for carrying out instructions in accordance with said stored program code; a unidirectional network interface; and a bidirectional network interface; wherein said program code, when executed by said processor, causes said processor to perform the steps of: receiving a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; and bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers.

6. The terminal of claim 5, wherein electronic service guide metadata is employed.

7. The terminal of claim 5, wherein said terminal is a cellular telephone.

8. A terminal for receiving at least one content file, comprising: a memory having program code stored therein; a processor operatively connected to said memory for carrying out instructions in accordance with said stored program code; and a unidirectional network interface; wherein said program code, when executed by said processor, causes said processor to perform the steps of: receiving a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; and bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers, wherein said unidirectional network interface is a terrestrial digital video broadcasting interface.

9. The terminal of claim 5, wherein said bidirectional network interface is a universal mobile telecommunications system interface.

10. The terminal of claim 5 wherein said program code further causes said processor to perform the step of: filtering received content files.

11. The terminal of claim 10, wherein said filtering includes considering metadata.

12. The terminal of claim 10, wherein said filtering includes considering identifiers.

13. The terminal of claim 10, wherein said filtering includes considering content.

14. A terminal for receiving at least one content file, comprising: a memory having program code stored therein; a processor operatively connected to said memory for carrying out instructions in accordance with said stored program code; and a unidirectional network interface; wherein said program code, when executed by said processor, causes said processor to perform the steps of: receiving a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; and filtering received content files, wherein said filtering includes performing pattern recognition.

15. An apparatus for distributing content files to a terminal, comprising: a memory having program code stored therein; and a processor operatively connected to said memory for carrying out instructions in accordance with said stored program code; wherein said program code, when executed by said processor, causes said processor to perform the steps of: associating with each of a plurality of content files a metadata file, wherein each of the metadata files is associated with a unique identifier; receiving at the terminal a specification of content of interest to a user, said specification being in terms of metadata keywords; searching said metadata files for said keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a portion of one of said content files; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; providing individuals with software for formulating content, said software producing for each item of formulated content descriptive attributes; distributing to receiving terminals the formulated content, and descriptive attributes produced with said software; allowing users of the receiving terminals to specify attributes corresponding to content of potential interest; and allowing the users of the receiving terminals to configure the receiving terminals to only display content whose descriptive attributes match the specified attributes, wherein at least one of the content files comprises content formulated using said software, wherein chat messages are formulated using said software.

16. An apparatus for distributing content files to a terminal, comprising: a memory having program code stored therein; and a processor operatively connected to said memory for carrying out instructions in accordance with said stored program code; wherein said program code, when executed by said processor, causes said processor to perform the steps of: associating with each of a plurality of content files a metadata file, wherein each of the metadata files is associated with a unique identifier, and wherein the content files are selected by a content provider; receiving at the terminal a specification of content of interest to a user, said specification being in terms of metadata keywords; searching said metadata files for said keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a portion of one of said content files; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; allowing the content provider to view available bandwidth in a network of a broadcast system; allowing the content provider to, by defining a certain amount of bandwidth between a stated start time and a stated end time, allocate bandwidth for a broadcast program in one or more network areas; and allowing said content provider to view network topology.

17. A method for receiving at least one content file, comprising: receiving, at a terminal possessing a bidirectional network interface, a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; and bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers.

18. A method for receiving at least one content file, comprising: receiving, at a terminal possessing a unidirectional network interface, a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; and bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers, wherein said unidirectional network interface is a terrestrial digital video broadcasting interface.

19. A method for receiving at least one content file, comprising: receiving a specification of content of interest to a user, said specification being in terms of metadata keywords; noting unique identifiers associated with metadata files including one or more of said keywords; monitoring incoming packets for the noted unique identifiers, each of said packets conveying a content file portion; bringing to attention of said user only content files conveyed by packets that contain one of the noted unique identifiers; and filtering received content files, wherein said filtering includes performing pattern recognition.

Description

FIELD OF INVENTION

This invention relates to systems and methods for distributing data over a wireless link.

BACKGROUND INFORMATION

Broadcast has an almost century long tradition in radio. Even with TV, the history goes back to 1930's. Broadcasting has been successful throughout the world in bringing both entertainment and information to mass audiences.

The latest step in broadcasting is the digitalization of both radio and TV. Digital radio has not gained much acceptance on the market. However, many hope that digital TV will bring new benefits and services to the consumer and, as a result, generate new revenue streams for the broadcasting industry. The basic concept of the TV service itself has, however, not changed much. Rather, the TV lives on as before even if it has become digital.

In later half of 1990's we saw the boom of the Internet. A whole set new of services and content became available to the consumers during a short, revolutionary and hype intense period. That period introduced e-commerce, Internet Service Providers (ISPs), Portals, eyeballs game, dotcom companies and even the new economy. The developments in both access technologies (e.g. ADSL) and coding technologies (e.g. MPEG4 streaming) has made it possible to bring rich media content like video content to homes via the Internet. Despite of these technology and market breakthroughs media houses have been reluctant to distribute their content via the Internet due to its "free-of-charge" nature and the direct threat of piracy. Internet has also not been able to challenge the role of traditional media as the primary advertisement platform despite is great popularity.

Another development marking major shifts in the 1990's has been the rapid growth of mobile telecommunications globally. Through out the world voice telephony has moved from fixed wireline to mobile wireless. Consumers have an urge for new, mobile non-voice services that operators hope to fulfill with latest developments of technology like GPRS and 3rd Generation UMTS. In Japan DoCoMo by orchestrating the iMode business system and technology platform managed to boost the market with new services, new benefits to both consumers and content providers, and, consequently, with new revenue streams.

SUMMARY OF THE INVENTION

According to the present invention there is provided a datacast distribution system which allows for the distribution of movies, music, games, application software, and the like using a new or existing terrestrial digital video broadcasting (DVB-T) network or the like.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram showing the establishment of network areas according to embodiments of the invention.

FIG. 2 is a diagram showing the mapping of calendar dates to day-profiles according to embodiments the invention.

FIG. 3 is a diagram showing an exemplary graphical representation of the recording of the free bandwidth in network area according to embodiments the invention.

FIG. 4 shows an exemplary preliminary local bandwidth availability for day-type "weekday" in a network area according to embodiments of the invention.

FIG. 5 shows an exemplary global network availability for the day-type "weekday" according to embodiments of the invention.

FIG. 6 shows an exemplary final local network availability for day-type weekday in a particular network area according to embodiments of the invention.

FIG. 7 shows an exemplary partitioning of bandwidth according to embodiments of the invention.

FIG. 8 software module view of an exemplary datacast distribution system according to embodiments of the invention.

FIG. 9 shows exemplary scope of three access keys according to embodiments of the invention.

FIG. 10 shows the use of the standard IPSEC protocol.

FIG. 11 shows the use of the custom IPSEC protocol of embodiments of the invention.

FIG. 12 shows an example of scalability of the DDS according to embodiments of the invention.

FIG. 13 shows an exemplary selection of bandwidth blocks by a content provider according to embodiments of the invention.

FIG. 14 shows an exemplary general purpose computer.

DETAILED DESCRIPTION OF THE INVENTION

According to the present invention there is provided a datacast distribution system (DDS) which allows for the distribution to reception terminals of content such as movies, music, games, software, and the like using a new or existing DVB-T (terrestrial digital video broadcasting) network or the like.

Bandwidth Partitioning and Allocation

DVB-T offers a high bandwidth transmission channel wherein delivery is typically multicast. Planning is necessary to make optimum use of this bandwidth.

Bandwidth partitioning and allocation according to one embodiment of the present invention will now be described. A first step may be to define network areas in the DVB-T broadcast network into which the DDS is to be deployed. A network area comprises one or more cells and/or broadcast areas of the DVB-T network. In the example of FIG. 1, network area 1 is comprised of cells 1-4 while network area 2 is comprised of cells 5-8. As will be described in detail below, some content will be designated for "global" distribution, while other content will be designated for distribution to a single network area. All network areas will receive content designated for "global" distribution, whereas content will be designated for transmission only to a certain network area will be received only in that area.

A second step may be to define day-type profiles. Day-types are defined such that any date on the calendar can be assigned to one of the defined day-types. For example, four day-types may be defined: "weekday," "Saturday," "Sunday," and "holiday." In other embodiments more or less day-types may be defined. In certain embodiments a date on the calendar may be assigned to more than one day-type.

A next step may be to map dates to day-types. FIG. 2 continues the above example by showing an exemplary mapping for the second-to-last week of December 2002 wherein each day is mapped to one of the defined day-types. Thus, for example, December 22 is mapped to "Sunday," December 23 to "weekday," and December 25 to "holiday." Mapping may be done for any amount of time into the future. For example, mapping may be done for each date occurring within the next five years.

Mapping may be done for both a monitoring period and an deployment period. The monitoring period is the period of time during which measurements of free bandwidth are made in the network for the purpose of allocating and partitioning bandwidth, whereas the deployment period is the period of time during which the DDS operates on the network according to the allocations and partitions. For example, when the DDS is deployed in an existing terrestrial DVB broadcast network, there might be a monitoring period of three months. Thus a next stop in bandwidth partition and allocation may be to measure and record free bandwidth in each network area for the monitoring period. FIG. 3, for example, shows an exemplary graphical representation of the recording of the free bandwidth in network area 1 on Jan. 3, 2001.

Next, a preliminary local network availability may be defined for each day-type in each network area. According to one embodiment, this may be done by choosing a number of days of the monitoring period that were mapped to a particular day-type, overlapping the graphical representations of free bandwidth corresponding to those chosen days, and performing an mathematical operation. For example, in FIG. 4 the preliminary local bandwidth availability for day-type "weekday" in network area 1 is defined by overlaying graphs of the free bandwidth recordings for three days of the monitoring period that were defined as weekdays, plotting the mathematical minimum of the three graphs, and defining that minimum to be the preliminary bandwidth availability for day-type weekday in network area 1.

After defining the preliminary local network availability for each day-time in each network area, a final global network availability may be defined for each day-type. According to one embodiment, the final global network availability is defined for a particular day-type by overlaying graphs of the preliminary network availabilites for that day-type from the various network areas, performing a mathematical operation, and plotting the result. For example, in FIG. 5 the global network availability for the day-type "weekday" is defined in a DDS with two network areas by overlaying the graphs of the network area 1 and network area 2 preliminary network availabilities for day-type weekday, and considering the mathematical minimum of the overlaid graphs to define the global network availability for day-type "weekday."

As a next step, a final local network availability may be defined for each day-type in each network area. The final local network availability for a particular network area and day-type may be defined by taking the preliminary local network availability for that network area and day-type, and subtracting from it the final global network availability for that day-type. This is shown by example in FIG. 6 where the final local network availability for network area 1 and day-type weekday was defined by graphically subtracting the final global network availability graph for day-type weekday from the preliminary local network availability graph for day-type weekday in network area 1.

With the final local and final global network availabilites defined, a next step may to be to perform partitioning of the available bandwidth into several quality of service (QoS) classes. According to one embodiment of the present invention, six QoS classes are used. The first of the six classes is "global/constant" (GC). This class provides a constant bandwidth that is available 24 hours a day, 7 days a week. This class could be used for purposes such as delivering streaming content, service announcements, access keys, or the like to all network areas.

The second of the six classes is "global/time bound" (GT). This class is used for distribution of content to all network areas, and provides blocks of various bandwidths and time durations. Particular GT blocks are offered to service providers who wish for scheduled delivery. For example, a particular GT block might be offered that provides 12 Mbit/s for 12 minutes starting at 6 p.m. on Nov. 12, 2003.

The third of the six classes is "global/dynamic priority" (GD). Like GT, GD is used for distribution to all network areas and provides blocks of various bandwidths and time durations. However, particular GD blocks are not offered to content providers. Because the content provider cannot choose a particular GD block, although these blocks are employed to offer delivery before a specified date, they tend not to be employed to offer delivery at a specific time. Instead, a content provider may be offered transmission before a stated date using a block offering a particular bandwidth. If the content provider accepts, the DDS or an employee thereof decides which of the blocks matching the criteria will be given to the content provider. Thus, unlike GT blocks, the content provider does not choose a particular block; instead the choice is made by for the content provider.

For example, there might be seven GD blocks offering 12 Mbit/s for 12 minutes between Oct. 12, 2002 and Oct. 13, 2002, each of the blocks providing for transmission over the wireless link at a different particular time. A content provider seeking GD blocks might accept an offering of 12 Mbit/s for 12 minutes between Oct. 12, 2002 and Oct. 13, 2002. However the content provider would not know which of the seven blocks he would actually be assigned. Instead this decision would be made by an employee and/or computer of the DDS. For example, a DDS computer could be programmed to make this decision in a way that optimizes the use of available bandwidth. Thus while the content provider would know that his distribution would occur before October 13.sup.th, he would not know the actual time of distribution.

The fourth through sixth QoS types are "local/constant" (LC), "local/time-bound" (LT), and "local/dynamic priority" (LD). These QoS types analogous to the GC, GT, and GD types described above but are used for distribution within specific network areas rather than for global distribution. FIG. 7 shows an exemplary partitioning of final network availability into the GC, GT, and GD classes described above.

According to embodiments of the present invention, bandwidth of a certain QoS class that remains unassigned by a certain deadline might be reassigned so as to become bandwidth of another QoS class. For example, GC bandwidth that remains unassigned might be reassigned to become GT and/or LC bandwidth, GT bandwidth that remains unassigned might be reassigned to become GT and/or LT bandwidth, GD bandwidth which remains unassigned may be reassigned to become LD bandwidth, LC bandwidth which remains unassigned may be reassigned to become LT bandwidth, and LT bandwidth which remains unassigned may be reassigned to come LD bandwidth. The deadlines will generally be expressed in terms of time before transmission over the wireless link of the bandwidth in question. For example, the deadline for the reassignment of GC bandwidth might be 10 days before that bandwidth will be transmitted over the wireless link. As a further example, the deadlines for the reassignment of GT, GD, LC, and LT bandwidth might respectively be five days, two days, five weeks, and 1 day.

According to certain embodiments of the present invention, a network administrator or the like could define topics with which content to be distributed could be associated. These topics could be defined with a desired level of specificity. Topics defined in a less specific manner could include, for instance, "news", "sports", "business", "children's", "educational", "entertainment", and/or the like. Topics defined in a more specific manner could include, for instance, "international news", "national news", "local news", "national sports", "regional sports", "children's educational", "adult educational", "children's entertainment", "comedic entertainment", "action entertainment", "dramatic entertainment", and/or the like.

With a number of topics defined, the available bandwidth indicated by the final local network availability corresponding to a particular network area and day type could be divided into a number of partition blocks. Such a partition block could be similar to an above-noted LT block, but be additionally associated with a topic. Similarly, with a number of topics defined the available bandwidth indicated by the final local network availability corresponding to a particular day-type could be divided into a number of partition blocks. Such a partition block could be similar to an above-noted GT block, but be additionally associated with a topic. Thus, partition blocks could have varying start times, have varying end times, offer varying transmission bandwidths, and be associated with varying topics.

Having defined a number of partition blocks, the defined partition blocks could be assigned to content to be distributed. More specifically, content to be distributed that is associated with a particular topic could be assigned to a partition block that is associated with the same topic, and that is of sufficient time duration and/or offers sufficient bandwidth. The topics associated with content to be distributed could be determined in a number of ways. For example, the topics could be indicated by content providers that create and/or aggregate the content. As another example, the topics could be indicated by network administrators or the like. As yet another example, the topics could be indicated by experts such as media experts.

In certain embodiments of the present invention, a hierarchical tree structure could be formulated that related content to be distributed with categories, subcategories, and the like, and with topics of the sort noted above. Branches of the tree that gave rise to other branches could correspond to categories, subcategories, and the like. Branches of the tree that gave rise to leaves instead of other branches could correspond to topics of the sort noted above. Leaves could correspond to content to be distributed. Accordingly, by tracing a path from a leaf to the trunk of such a tree, one could determine the topic, categories, subcategories, and the like associated with the content corresponding to the leaf. In a like manner, one could navigate such a tree by category, subcategory, and the like to find leaves corresponding to content items of interest. Such trees could be browsable, for instance, by end users via the GUIs of their receiving terminals.

The categories, subcategories, and the like could be established by a network administrator or the like. Similarly, content to be distributed could be appropriately placed in such a tree by a network administrator or the like. For instance, a tree structure could be formulated whose trunk had main branches for the categories "video", "audio", and "data". The exemplary main branch corresponding to "video" could split into smaller branches corresponding to the subcategories "movies", "serials", and "informational". The branch corresponding to the subcategory "informational" could give rise to terminal branches corresponding to the topics "international news", "national news", and "local news". Each of these topic branches could give rise to leaves that corresponded to content to be distributed. Thus the leaf corresponding to a New York morning news program to be distributed could placed in the just-described exemplary tree so as to sprout from the "local news" terminal branch. The "local news" terminal branch sprouts in the exemplary tree from the "informational" subcategory branch, which in turn sprouts from the category branch "video". Accordingly, the tree shows the New York morning news program to be associated with the topic "local news", the subcategory "informational", and the category "video".

In certain embodiments, partition blocks corresponding to particular network areas may be used instead of partition blocks corresponding to global bandwidth. In such embodiments, content to be distributed to a multitude of network areas could, for instance, be assigned to a multitude of appropriate partition blocks, with there being a partition block corresponding to each network area in which distribution was sought.

Bandwidth Selection by Content Providers

A content provider wishing to distribute content such as files, software, media, or the like using the distribution system of the present invention must first secure bandwidth for the distribution. As was described above, the total transmission bandwidth available in the DDS is split into a number of blocks of varying lengths and bandwidths. According to certain embodiments of the present invention running on one or more computers of the DDS will be a scheduling intelligence module 1217, and a content provider may secure blocks for a particular distribution using content provider software that interfaces with that module.

In one embodiment of the present invention, the interface may be custom software running on a computer used by the content provider. For example, the software could be written in Java and interface with the scheduling intelligence module using a technique such as SOAP (Simple Object Access Protocol), RMI (remote method invocation), or JMS (Java Messaging Service) over a data link between the content provider and the DDS. This link could be, for example, the internet or a private network. Alternately, the software could be written in Objective-C or Java and could interface with the scheduling intelligence module using the Distributed Objects functionality provided by Apple Computer's Cocoa frameworks. In another embodiment, a web browser could be used to interface with the scheduling intelligence module.

The web interface may be implemented as is known in the art using, for example, Java Server Pages (JSP) to update the web interface in accordance with the interaction with the scheduling system. In certain embodiments, the software or web browser interface may be constructed using Apple Computer's Web Objects.

The interface could allow a content provider to browse among available partition, GC, LC, GT, and/or LT blocks, and non-specific offerings of GD and/or LD blocks. In addition to selecting single blocks or GD or LD offerings, multiple blocks or offerings could be selected at a time. For example, a content provider could request blocks for a weekly distribution of a movie every Friday at 8 p.m. For such repeating distributions, the content provider could indicate whether the same content was to be distributed each time (such as a repeating infomercial) or if different content was to be distributed each time (such as new episode of a soap opera each week). If the same content is to be used each time, in some embodiments the content provider may only need to upload it once. In certain embodiments, services may be defined. A service may, for example, comprise one or more repeating or non-repeating distributions of content.

The scheduling intelligence module maintains a datastore noting all blocks and information concerning their assignment statues. Once blocks have been chosen by or on behalf of a content provider, the scheduling intelligence module's datastore is updated to reflect this by marking them as "reserved." For example, the datastore may have a "reserved bit" corresponding to each block, where the bit is set to "0" if the block is free and "1" if the block is reserved. The scheduling intelligence module next assigns and forwards to the content provider a unique identifier for each block. Thus for repeating distributions, only a single unique identifier will be forwarded.

Shown in the following table are a number of exemplary actions performable by a content provider or the like via the interface.

TABLE-US-00001 Action Description View account info A content provider can view, and perhaps modify, account information (e.g., service information, datacast logs, billing data). Modify service A content provider can modify service attributes. attributes Add or cancel service For each service, system resources may be allocated (e.g., upload directory, media store directory, and respective program in the program hierarchy). A content provider can create new services and/or specify how content associated with services should be delivered. A content provider may change associations between content and services. A content provider can cancel services. Add/modify/remove Content information describing content associated with a service can be information added, modified or removed. corresponding to In modifying content information, new content associated with a service content associated may be uploaded to replace existing content associated with a service. with a service If the information concerning content associated with a service is removed, the content itself may be removed as well. View available A content provider may view network topology and the available bandwidth bandwidth for services. Such a view may be for an entire network and/or a certain network area. Schedule Service A session related to a previously defined service can be defined for the Session whole network or a network area, within the limits of the available bandwidth for the topic of the service. A session can consist of one or many items of a service (e.g., scheduled files, carouseled files, instant files, streams, and IP forwarding). Schedule Repeating A repeating session can be defined so that not every session needs to be Service Session scheduled "manually". Such may be useful for distributions such as newspaper or magazine distributions. Options include: Same item each time (e.g., the same file(s) are distributed, protected with the same content protection key). New item is distributed each time (e.g., content items, each protected with a new content protection key, are uploaded and distributed). View Upload The content provider can view the upload schedule and location information Schedule and for the scheduled content associated with a service. Location Content Tracking The content provider can view the status of content as it is processed by the system.

Upload, Processing, and Distribution

After allocating scheduling blocks for distribution of the specified content, the scheduling intelligence module will request from the content provider the content to be distributed and metadata describing that content. The request may further include deadlines by which the metadata and content must be submitted. Generally speaking, the deadline for the submission of the metadata will be prior to the deadline for the submission of content.

The metadata may comprise a wide variety of information describing the content. For example, the metadata may include the unique identifier assigned by the scheduling intelligence module, the content type (e.g., film, application software, classified ad, video game, or music), whether a subscription is required for viewing, the running time, whether the content is for global distribution or distribution to a specified network area, the author, the transmission start time, the transmission end time, the expiration date, the genre, and/or the intended viewer or user age group of the content. In some embodiments the metadata may further include a summary or synopsis of the content. As will be explained in more detail below, this metadata is used for purposes such as compilation of a broadcast schedule and content filtering.

The scheduling intelligence module may request the upload of metadata in a number of ways. In one embodiment, metadata upload could be manual rather than automatic. For example, a dialog box reading: "Begin upload of metadata for distribution #123456 when ready. Metadata MUST be uploaded before Aug. 12, 2001 @23:12:00."

may appear on the software of the content provider, where "#123456" is the above-noted "unique number" identifying the distribution. In some embodiments, when ready the content provider could select from the software's interface the command "enter metadata". In response the interface might display the query: "Enter metadata for which distribution #?"

In response to which the content provider could enter the appropriate unique identifier (e.g., 123456). After content provider has entered the number, the interface might display a dialog box with two buttons, each representing a choice: "Enter metadata by band or load from file? [By Hand] [From File]"

If the content provider selected "by hand," the interface could present a form listing various metadata fields (e.g. "type" and "running time") for the content provider to fill out. If the content provider selected "from file", the interface could present a file browser from which the content provider could select from local and/or remote storage he file containing the desired metadata. The file might be, for example, in XML format.

After filling out the form or selecting the file, the content provider could select the command "Upload Now" from the interface. In response to this, the metadata could be transmitted to the scheduling intelligence module. In certain embodiments, instead of or in addition to the command "Upload Now" could be the command "Upload at specified time". By selecting this command, the content provider could select a specific time for the metadata to be transmitted.

Transmission of metadata to the scheduling intelligence module could be done in a number of ways. For example, a virtual private network (VPN) might connect the content provider to the DDS. In such a case, for example, a module of the software of the content provider might send a message to the scheduling intelligence module 1217 including the metadata, a specified "unique number", and a request that the included metadata be saved on the scheduling intelligence module's associated store with reference to the specified unique number. In some embodiments, this message could be sent using SOAP. In response, the scheduling intelligence module could appropriately store the sent metadata.

In cases where there is no VPN connection between the content provider and the DDS, additional steps might be necessary. For example, it might be necessary to configure a firewall 801 to allow entry of the message directed to the scheduling intelligence module. In such a case there might be a gatekeeper module 801 which would be capable of configuring the firewall to allow entry of the message. Accordingly, prior to sending the message specifying the metadata, a module of content provider software might send to the gatekeeper object a message requesting passage of a second message to the scheduling intelligence module. In some embodiments, the first message may further include an encrypted or unencrypted password and/or identification number relating to the content provider.

In one embodiment, in response to the message the gatekeeper module could configure the firewall to allow entry, wait for a message from the scheduling intelligence module indicating that the message including metadata had been successfully received, and then reconfigure the firewall to disallow further entry. Configuration of the firewall could be done, for example, by having the gatekeeper object make use of the Unix IPFW command or equivalents. In embodiments where the message to the gatekeeper included a password and/or ident