+

WO2001089150A2 - Systeme et procede de diffusion selective de donnees - Google Patents

Systeme et procede de diffusion selective de donnees Download PDF

Info

Publication number
WO2001089150A2
WO2001089150A2 PCT/US2001/016156 US0116156W WO0189150A2 WO 2001089150 A2 WO2001089150 A2 WO 2001089150A2 US 0116156 W US0116156 W US 0116156W WO 0189150 A2 WO0189150 A2 WO 0189150A2
Authority
WO
WIPO (PCT)
Prior art keywords
participant
manager
event
level
ticket
Prior art date
Application number
PCT/US2001/016156
Other languages
English (en)
Other versions
WO2001089150A3 (fr
Inventor
James Mcnabb
Ben Battle
Original Assignee
Reliacast, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Reliacast, Inc. filed Critical Reliacast, Inc.
Priority to AU2001263273A priority Critical patent/AU2001263273A1/en
Publication of WO2001089150A2 publication Critical patent/WO2001089150A2/fr
Publication of WO2001089150A3 publication Critical patent/WO2001089150A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1432—Metric aspects
    • H04L12/1439—Metric aspects time-based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/146—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network using digital cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1471—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network splitting of costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1845—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast broadcast or multicast in a specific location, e.g. geocast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments

Definitions

  • the present invention relates generally to network communications systems and more particularly to managing data multicasting over a network where recipients of that data can be authorized, authenticated, and billed for receiving that data.
  • Today's user of a network communication system is demanding that large amounts of content (i.e. data, voice, images, video, etc.) be delivered to their network receiving device ⁇ e.g., computer, set-top, PDA, cellular phone, etc.) in real-time.
  • content i.e. data, voice, images, video, etc.
  • network receiving device e.g., computer, set-top, PDA, cellular phone, etc.
  • One conventional mechanism for delivering content over a network communication system is referred to as a unicast.
  • a source of the content sends the content to each of the users or "recipients" of the content within the network communication system. This is referred to as a "one to one" delivery of content.
  • Unicasting to N recipients involves sending N copies of the content over the network communication system, one copy to each recipient. For large numbers of recipients, these multiple copies have a deleterious effect on the performance of the network communication system, particularly for content requiring a high amount of bandwidth for delivery ⁇ e.g., video streams).
  • Another mechanism for delivering content over the network communication system is to simply broadcast the content to every user on the ⁇ network communication system regardless of whether the user desires to receive the content or not. This is referred to as a "one to all" delivery of content. With broadcasting, one copy of the content, addressed to every user on the network, is transmitted over the network communication system. While broadcasting reduces the amount of the network bandwidth consumed by the delivery of the content, not all users desire or should receive the content. Furthermore, the source of the content has no mechanism for determining which of the recipients received the content.
  • Another mechanism for delivering content over the network communication system is a referred to as a multicast.
  • multicasting the source of the content sends one copy of the content addressed to only those recipients who should receive the content. This is referred to as a "one to many" delivery of content.
  • the content is replicated at key points in the network communication system so that each recipient receives the content quickly and efficiently without the problems associated with other forms of delivery.
  • conventional delivery of content via multicast still has many problems that heretofore have hindered its adoption as a content delivery standard.
  • One problem associated with multicasting not found with unicasting is that the originator of the content does not know which, if any, of the recipients actually received the content.
  • the originator can measure network bandwidth and determine the recipients of the content.
  • the number of recipients is bound by the resources available to support the replication of each content stream.
  • Another problem with multicasting is that the originator of the multicast content is unable to measure the amount and quality of the content delivered to any particular recipient. Originators that bill recipients based on bandwidth usage are reluctant to provide a service for which they cannot effectively measure that usage. Furthermore, in network communication systems employing unicasts, there is a direct relationship between the number of servers in the system and the number of recipients able to be serviced by the system. Thus, billing for those services is relatively straightforward. This same relationship is not available in a network communication system employing multicasts.
  • the present invention is directed toward a system and method for multicasting data in a network communication system.
  • the present invention provides a system and method for managing, measuring, and controlling how information is delivered across a multicast-enabled network communication system ⁇ i.e., "multicast environment").
  • the present invention is described in terms of a stadium analogy where participants receive an "event,” or the information, from a "stadium.” Prior to entering the stadium, participants present a "ticket” at a “turnstile.” The turnstile prevents those participants without a proper ticket from entering the event.
  • the turnstile also provides information via a hierarchy of participant managers to the "director" of the event regarding when the participant entered the event, when the participant exited the event, and/or information regarding the delivery of the event to the participant.
  • the hierarchy of participant managers aggregates this information thereby providing an indication of the stadium's "use” to the director.
  • This aggregated information may be provided to an event sponsor ⁇ i.e., a content provider) for purposes of billing, advertising, and/or determining levels of participation in the event and among events.
  • the hierarchy of participant managers is self-organizing and self-healing.
  • Each of the participant managers automatically locates its position in the hierarchy based on a predetermined level.
  • the participant manager multicasts its level to other participant managers, some of which respond and identify their own level. Based on the responses, the participant manager determines to which of the other participant managers it should be attached. If, at any point, one of the participant managers fails, participant managers attached beneath the failing participant manager are able to relocate themselves within the hierarchy to prevent "blackouts" among particular participants.
  • participant managers preferably organize themselves on a geographical basis with the lowest level participant managers attached to participants in close physical proximity thereto. Higher level participant managers are similarly attached to the lower level participant managers. In this manner, each subsequently higher level of participant manager represents a greater number of participants in a larger geographic area until the highest level of participant manager represents all the participants of the event.
  • This feature allows the director and/or the content providers to determine the geographic areas of the participants participating in a particular event. The enables the director to properly allocate resources among the geographic areas for future events. This also provides opportunities for targeting advertisements to the participants on a geographic basis.
  • Still another feature of the present invention collects demographic information associated with the participant in exchange the ticket. Preferably, this demographic information is incorporated into the ticket so that during the event, the director and/or the content provider can identify and classify any of the participants or groups of participants receiving in the event. The demographic information also provides opportunities for targeting advertisements to the participants on a demographic basis.
  • Yet still another feature of the present invention presents statistics associated with the delivery of the event to participants in a tree structure in a graphic user interface.
  • the tree structure includes the director at the root, various levels of participant managers forming the branches, and participants at the leaves. Each level of participant managers corresponds to a level indicator in the tree structure. Each level indicator identifies the participant manager and provides information about the participant managers or participant connected beneath it in the tree structure.
  • this information represents aggregate delivery statistics pertaining to all of the participants connected beneath it in the tree structure.
  • a user is able to navigate the tree structure and "drill down" to particular levels to access these aggregate delivery statistics associated with a particular participant manager or the delivery statistics and/or demographic information pertaining to an individual participant.
  • FIG. 1 illustrates a multicast environment according to the present invention.
  • FIG. 2 illustrates a stadium analogy useful for describing the present invention.
  • FIG. 3 illustrates an exemplary hierarchy of participant managers.
  • FIG. 4 illustrates a director according to a preferred embodiment of the present invention.
  • FIG. 5 illustrates a graphical user interface for monitoring delivery of an event.
  • FIG. 6 illustrates an operation of a participant attempting to access an event according to one embodiment of the present invention.
  • FIG. 7 illustrates a stadium according to one embodiment of the present invention.
  • FIG. 8 illustrates a relationship among participants, participant managers, and content providers.
  • FIG. 9 illustrates a cast transaction according to one embodiment of the present invention.
  • FIG. 10 illustrates an operation of an autodiscovery algorithm from the perspective of a new participant manager according to a preferred embodiment of the present invention.
  • FIG. 11 illustrates an operation of the present invention from a perspective of a participant.
  • FIG. 12 illustrates an operation of the present invention from a perspective of a turnstile.
  • FIG. 13 illustrates an operation of the present invention from a perspective of participant manager.
  • FIG. 14 illustrates an operation of the present invention from a perspective of director server.
  • FIG. 15 illustrates an operation of the present invention from a perspective of director server gathering delivery statistics from a particular participant manager.
  • FIG. 16 illustrates an operation of the present invention from a perspective of director client.
  • FIG. 17 illustrates an operation of an autodiscovery algorithm from the perspective of an existing participant manager according to a preferred embodiment of the present invention.
  • the present invention is directed toward a system and method for multicasting data in a network communication system.
  • the present invention provides a system and method for managing, measuring, and controlling how information is delivered across a multicast-enabled network communication system ⁇ i.e., "multicast environment"). While the present invention is described herein using a “stadium analogy,” it will be apparent from the following discussion how the present invention contemplates delivery of any form of data to multiple recipients in a multicast environment in an authenticated, reliable and controlled manner.
  • FIG. 1 illustrates a multicast environment 100 according to the present invention, includes a multicast-enabled network communication system 105.
  • Multicast environment 100 may include at least one content provider 110 (illustrated as a content provider 110A and a content provider 110B), a plurality of participants 120 (illustrated as a participant 120A, a participant 120B, and a participant 120C), one or more participant managers 130 (illustrated as a participant manager 130A and a participant manager 130B), a director 140 and/or a ticket provider 150.
  • content provider 110 illustrated as a content provider 110A and a content provider 110B
  • participants 120 illustrated as a participant 120A, a participant 120B, and a participant 120C
  • participant managers 130 illustrated as a participant manager 130A and a participant manager 130B
  • director 140 and/or a ticket provider 150.
  • FIG. 2 illustrates a stadium analogy 200 useful for describing multicast environment 100, particularly for describing its use to deliver an event 220.
  • Content providers 110 provide event 220 to stadium 210 for delivery to participants 120.
  • Participants 120 acquire a ticket 240 to event 220 from ticket provider 150.
  • Participants 120 present ticket 240 at a turnstile 230 to enter stadium 210 whereby they begin participating in event 220.
  • Participant managers 130 located at strategic points within network communication system 105 manage the delivery of event 220 to the participants 120.
  • Director 140 oversees the delivery of event 220 by supervising participant managers 130, ensuring that event 220 is delivered to each participant 120.
  • participant managers 130 can determine which and how many of participants 120 participated in event 220 and can determine the duration of that participation. This information is collected and aggregated by participant managers 13 * 0 and maintained by director 140 for billing purposes or for evaluating demographic information associated with participants 120 of event 220.
  • Multicast environment 100 includes network communication system 105 that is configured for multicasting content ⁇ i.e. events 220) from a single source ⁇ i.e., stadium 210) to multiple recipients ⁇ i.e., participants 120).
  • multicast environment 100 operates on the Internet using well-established protocols, including various protocols for communicating via one or more wireless connections.
  • multicast environment 100 operates on an entity's intranet using similar well-established network protocols. This entity may include, but is not limited to a company, a government, a government agency, an organization or any other entity that operates a private intranet or similar communication network.
  • event 220 is a time-sensitive delivery of an information stream to multiple recipients.
  • event 220 is intended to arrive virtually simultaneously at each participant 120.
  • Event 220 may comprise a continuous information stream such as a video stream, an audio stream, or other form of continuous data stream, that is either "live" or pre-recorded.
  • the information stream may also comprise one or more data files such as an image file, an application program, an application program update, a database, or other form of data file destined to multiple recipients.
  • the information stream may also comprise a conferencing information stream such as video teleconferencing, audio teleconferencing, collaborative working environments or other form of conferencing information stream; a news information stream such as various wire service information streams including UPI, API, etc.; equity and/or commodity ticker information streams such as NYSE, NASDAQ, CBOE, etc.; and a gaming information stream for interactive multi-player network games.
  • a conferencing information stream such as video teleconferencing, audio teleconferencing, collaborative working environments or other form of conferencing information stream
  • a news information stream such as various wire service information streams including UPI, API, etc.
  • equity and/or commodity ticker information streams such as NYSE, NASDAQ, CBOE, etc.
  • gaming information stream for interactive multi-player network games.
  • Content providers 110 provide the content that is to be delivered to participants 120 in multicast environment 100, preferably from stadium 210 in the form of event 220. More particularly, content providers 110 provide an information stream that is to be multicasted to participants 120. In general, content providers 110 may provide any form of information stream that may benefit from delivery in a multicast environment 110, particularly where identical or similar information is to be simultaneously (or virtually simultaneously) delivered to multiple participants 120.
  • Content providers 110 may include commercial webcasting companies as well as enterprises.
  • Examples of commercial company information streams include, but are not limited to, financial and technical community briefings and conferences, sporting events, music concerts, movie premieres, news services and on-line learning.
  • Examples of enterprise information streams include, but are not limited to, all-hands briefings and announcements, management communications, employee training, and customer service communications.
  • content providers 110 establish a web page for the information stream that can be accessed via a web browser.
  • the information stream is accessed as event 220 through stadium 210.
  • Content provider 110 provides director 140 with an address (preferably a URL address) for the web page associated with event 220 discussed above to accomplish this aspect of the invention.
  • Director 140 reformats this URL address as a Stadium URL address ("SURL") for operation with multicast environment 100 and returns the SURL to content provider 110 to be included in the web page.
  • SURL Stadium URL address
  • FIG. 7 illustrates stadium 210 according to one embodiment of the present invention.
  • stadium 210 is a virtual stadium.
  • Stadium 210 may include one or more sections 710 (illustrated as a first section 710A, a second section 710B, a third section 710C, and a fourth section 710D).
  • each section 710 is associated with a different event 220 being offered in stadium 210 at that particular time.
  • each section 710 is associated with a different class of service associated with the delivery of a particular event 220.
  • Such classes of service may include, for example, encoding data at different bit rates for delivery via a cable modem so that a lower class of service might receive data at 56kbps and a higher class of service might receive data at 300kbps.
  • Other forms of discriminating classes of service are available as would be apparent.
  • Events 220 offered in stadium 210 offered at any particular time may all originate from a particular content provider 110. Alternately, events 220 offered in stadium 210 may originate from different content providers 110.
  • the present invention also contemplates multiple stadiums 210 each offering multiple events 220 or multiple classes of service for a particular event 220 at any particular time. For example, one stadium 210 may offer various live baseball games, while another stadium 210 may offer various inspirational speakers. Events offered via various stadiums 210 and within particular stadiums are numerous and may be organized in various manners as would be apparent.
  • Participants 120 are those users that receive event 220 ⁇ i.e., recipients of the information stream) via network communication system 105. Participants 120 may be consumers in the event that content provider 110 is a commercial company, or employees in the event that content provider 110 is an enterprise. Preferably, participants 120 perceive that they receive event 220 from stadium 210. In a preferred embodiment of the present invention, participants 120, upon accessing stadium 210 to participate in event 220, are redirected to content provider 110, or more particularly, to a multicast-enabled URL address from which event 220 is delivered. In some embodiments of the present invention, content providers 110 provide event 220 to stadium 210 a priori, and stadium 210 subsequently directs participants 120 to the multicast enabled URL address.
  • Participants 120 generally receive the information stream via a suitable receiving device such as, but not limited to, a computer workstation, a PDA, a memory device ⁇ e.g., an MP3 player, a memory stick, etc.), a cellular telephone, a set-top box, or any other form of electronic device capable of receiving information from network communication system 105, including those employing one or more wireless connections to network communication system 105.
  • the receiving device includes a web browser that operates in conjunction with an event renderer such as a media player ⁇ e.g., Real PlayerTM, Microsoft Windows' Media PlayerTM, etc.) to render event 220 for use by participant 120.
  • an event renderer such as a media player ⁇ e.g., Real PlayerTM, Microsoft Windows' Media PlayerTM, etc.
  • the event renderer is delivered prior to or as part of event 220.
  • event 220 may also include or be accompanied by a self-installing event renderer that installs the upgrade on participants' receiving device.
  • a self-installing event renderer that installs the upgrade on participants' receiving device.
  • Participants 120 are managed and organized in multicast environment 100 by one or more participant managers 130 located at various strategic points within the network communication system.
  • participant managers 130 are organized within multicast environment 100 in a hierarchy 300 as illustrated in FIG. 3.
  • Hierarchy 300 includes one or more levels of participant managers 130. Each level may organize and manage one or more lower levels of participant managers 130 and/or one or more participants 120.
  • multicast environment 100 includes up to 255 levels of participant managers 130 with any number of participant managers 130 resident at each level. Other embodiments include fewer or more levels of participant managers 130 as would be apparent.
  • Hierarchy 300 forms a tree topology with participants 120 at the "leaves,” various levels of participant managers 130 forming the "branches" and director 140 forming the "root.”
  • Hierarchy 300 of participant managers 130 manage and organize participants 120 in multicast environment 100 by directing network commands and control information downward from director 140, through the levels of participant managers 130, and ultimately to participants 120. Likewise, information associated with the delivery of the event is directed upward from participants 120, through the levels of participant managers 130, which aggregate the information, to director 140 which monitors the delivery of the event. This process is discussed in further detail below.
  • hierarchy 300 is formed on a geographic basis. As illustrated in FIG. 3, hierarchy 300 includes a regional ⁇ e.g., West Coast) participant manager 310 that manages and organizes three state participant managers 320 within that region, namely a California participant manager 320A, an Oregon participant manager 320B, and a Washington participant manager 320C. Each of these state participant managers 320 may include one or more district participant managers 330. As illustrated in FIG. 3, California participant manager 320 includes at least a Central California participant manager 330. Other district participant managers 330 may be included but are not illustrated for purposes of clarity.
  • Each district participant manager 330 may further include one or more locality participant managers 340.
  • Central California participant manager 330 includes a San Francisco participant manager 340A, a San Jose participant manager 340B, and an Oakland participant manager 340C.
  • Various additional lower levels of granularity may be included in hierarchy 300.
  • each locality participant manager includes one or more participants 120.
  • San Francisco participant manager 340A includes a participant 350A, a participant 350B, and a participant 350C
  • San Jose participant manager 340B includes a participant 350D
  • Oakland participant manager 340C includes a participant 350E and a participant 350F.
  • participant managers 130 are located at various strategic points within the network communication system 105.
  • these strategic locations may include various points-of-presence ("POPs") within the Internet, preferably located near participants 120.
  • POPs points-of-presence
  • these strategic locations may include various subnets, departments, buildings, or geographic locations within the intranet.
  • these locations may also include a combination of strategic points within various intranets operating within the overall framework of the Internet as would be apparent.
  • each stadium 210 in multicast environment 100 is associated with a director 140.
  • director 140 may be associated with several stadiums 210.
  • Director 140 oversees and manages the delivery of event 220 from stadium 210 to participants 120.
  • Director 140 also provisions tickets 240 for events 220 in stadium 210.
  • director 140 is comprised of two components: a director server 410 and a director client 420 as illustrated in FIG. 4. Each of these is now described in further detail.
  • director client 420 is one component of director 140.
  • Director client 420 preferably comprises a web-based monitoring tool that provides dynamic, real-time views of the delivery of event 220 within multicast environment 100.
  • director client 420 provides information regarding participants 120 as well as delivery statistics associated with participants 120 at various levels within hierarchy 300.
  • Director client 420 also provides interactive control over participant managers 130 and participants 120 within hierarchy 300, including the ability to delete a particular participant 120 from event 220.
  • Director client 420 also operates as an interface to create event 220, edit event 220, remove event 220 and other management operations associated with event 220. Preferably, either content provider 110 or a system operator may access director client 420 to perform these operations.
  • FIG. 5 illustrates ah exemplary graphical user interface ("GUI") 500 associated with director client 420 for providing information regarding the delivery of event 220. More particularly, FIG. 5 illustrates a GUI 500 that represents various performance and information aspects of the delivery of event 220 (referred to herein as delivery statistics) to one or more participants 120 arranged in a left GUI portion 510 and a right GUI portion 570.
  • GUI graphical user interface
  • Left GUI portion 510 includes a GUI tree structure 515 corresponding to hierarchy 300.
  • GUI tree structure 515 represents the various levels of hierarchy 300 in a familiar "directory tree structure" such as that employed in various "file manager” applications.
  • GUI tree structure 515 corresponds to hierarchy 300 for West Coast participant manager 310.
  • a first level structure indicator 520A corresponds to California participant manager 320A
  • a first level structure indicator 520B corresponds to Oregon participant manager 320B
  • first level structure indicator 520C corresponds to Washington participant manager 320C.
  • Each first level structure indicator 520 may include information 521 (such as information 521A) that identifies its corresponding participant manager 130 and/or that summarizes aggregate delivery statistics corresponding to participants managers 130 attached beneath it.
  • Each first level structure indicator 520 may include one or more second level structure indicators 525.
  • a second level structure indicator 525A corresponds to Central California participant manager 330.
  • Each second level structure indicator 525 may include information 526 that identifies its corresponding participant manager 130 and/or that summarizes aggregate delivery statistics corresponding to participants managers 130 attached beneath it.
  • each second level structure indicator 525 may include one or more third level structure indicators 530.
  • second level structure indicator 525A includes a third level structure indicator 530A corresponding to San Jose participant manager 340BA, a third level structure indicator 530B corresponding to San Francisco participant manager 340A, and a third level structure indicator 530C corresponding to Oakland participant manager 340C.
  • each third level structure indicator may include information 531 that identifies its corresponding participant manager 130 and/or that summarizes aggregate delivery statistics corresponding to participant managers 130 attached beneath it.
  • any of structure indicators 520, 525, 530 may correspond to a particular participant 120.
  • each of structure indicators 520, 525, 530 may include information that identifies its corresponding participant 120 and/or that provides delivery statistics corresponding to participant 120.
  • third level structure indicator 530B and its information 53 IB are highlighted.
  • information associated with the corresponding participant manager 130 is presented in right GUI portion 570.
  • right GUI portion 570 includes information corresponding to San Francisco participant manager 340A.
  • right GUI portion 570 provides information associated with participants 120 organized below the corresponding participant manager 130 associated with the highlighted structure indicator in left GUI portion 510.
  • right GUI portion 570 includes information corresponding to participants 350A, 350B and 350C organized below San Francisco participant manager 340A. If structure indicator 525A were highlighted in FIG. 5, right GUI portion 570 would include information corresponding to participants 350A-F.
  • the information corresponding to participants 120 displayed in right GUI portion 570 includes a ticket ID 540 and a duration 545.
  • Ticket ID 540 corresponds to an identification number of ticket 240 granted to a particular participant 120 whereby the particular participant was granted access to event 220 as will be discussed in further detail.
  • Duration 545 corresponds to an amount of time that the particular participant 120 participated in the event ⁇ i.e., received the information stream). In some embodiments of the present invention, duration 545 may correspond to an amount of data (expressed in bytes or other suitable measure of data) delivered to the particular participant 120. Other information corresponding to participants 120 may be included as would be apparent.
  • further information 565 is displayed in right GUI portion 570, for highlighted ticket I-D's such as ticket ID 550.
  • further information 565 includes demographic data 560 associated with the particular participant 120. This demographic information may include name, address, age, gender, household income, occupation, telephone number, and various other demographic information as would be apparent, hi a preferred embodiment of the present invention, the particular participant 120, in exchange for ticket 240 to event 220, may have provided this demographic information.
  • System operators and content providers 110 may access director client 420 to monitor the delivery of event 220. Likewise, system operators and content providers 110 may access director client 420 after delivery of event 220 to conduct pre-processing or post-processing on the delivery of event 220.
  • director client 420 is used to determine demographic information associated with the delivery of a particular event 220. This demographic information may be used to target a direct advertising campaign or provide special offers to a subset of participants 120 on a demographic and/or geographic basis. Additional aspects of this embodiment are described in further detail below.
  • Director server 410 provides various organizational and management functions of director 140, namely provisioning event 220, controlling delivery of event 220, logging delivery of event 220, and reporting delivery of event 220. Each of these are now described in further detail.
  • Director server 410 provides management tools to provision stadium 210 for events 220. Provisioning stadium 210 for events includes allocating, dispensing, and tracking tickets 240. I-n this regard, director server 410 may determine a maximum number of tickets 240 that can be dispensed by a particular content provider 110. This controls an amount of access the particular content provider 110 has to stadium 210. Director server 410 may also determine a maximum number of tickets 240 that can be dispensed for a particular event 220 in stadium 210. This controls a number of participants 120 to the particular event 220 and limits their attendant system requirements imposed on network communication system 105 ⁇ e.g., server capacity, bandwidth, etc.).
  • Director server 140 may also determine a maximum number of tickets 240 that can be dispensed for any particular point in time per participant manager 130. This controls an amount of participants 120 accessing a particular point of presence in network communication system 105 to again limit the burden imposed on that particular point of presence ⁇ e.g., server capacity, number of modems, network bandwidth, etc.). Director server 140 may also determine a maximum number of tickets 240 that may be dispensed to participants 120 organized below any particular participant manager 130.
  • the director server 410 may control a geographic region ⁇ e.g., a country, a state, a county, a city, etc.) in which participants 120 can access event 220.
  • director server 410 maintains a database of all tickets 240 that have been dispensed in multicast environment 100 and used within stadium 210.
  • This database may include information associated with the particular participant 120 to which each ticket 240 is dispensed.
  • These tickets 240 are maintained on a per event as well as a per participant manager for purposes of planning and provisioning addition resources in multicast environment 100. Controlling Delivery of Event
  • Director server 410 also controls delivery of event 220 using a delivery method referred to as the SURL.
  • the SURL is generated by director server 410 and resides on the web page provided by content provider 110 for a particular event 220.
  • the SURL is implemented using a Java Applet, Servlet, HTML, or a combination of any of these or similar code scripting languages.
  • FIG. 6 illustrates an operation of this delivery method as it delivers the particular event 220 to participant 120.
  • participant 120 invokes the SURL by attempting to access the particular event on the web page.
  • the delivery method determines whether participant 120 has turnstile 230. In a preferred embodiment of the present invention, the delivery method determines whether a particular directory is present on the receiving device of participant 120 and that files associated with turnstile 230 reside therein. Other mechanisms for determining whether participant 120 has turnstile 230 are available as would be apparent. If participant 120 has a turnstile, processing continues at a step 635; otherwise, in a step 630, turnstile 240 is downloaded and installed at participant 120.
  • turnstile 230 is invoked.
  • turnstile 230 determines whether participant 120 has ticket 240 corresponding to the particular event 220. I-n a preferred embodiment of the present invention, turnstile 230 determines whether a registry (such as a WindowsTM registry) includes ticket 240 corresponding to the particular event 220. In addition, turnstile 230 authenticates ticket 240 to determine whether ticket 240 is a valid one. If participant 120 has ticket 240 corresponding to the particular event 220, processing continues at a step 660. Otherwise, if participant 120 does not have ticket 240, in a step 650, turnstile 230 directs participant 120 to an appropriate location where ticket 240 can be acquired such as director server 410, content provider 110, ticket provider 150, or some other source of ticket 240.
  • a registry such as a WindowsTM registry
  • turnstile 230 may direct participant 120 to access a multicast source associated with event 220.
  • this access launches an event renderer thereby initiating delivery of event 220.
  • Director server 410 also logs delivery of event 220.
  • director server 410 collects log information from each participant manager 130 and mediates them, preferably into an XML file referred to as a Content Delivery Log, for each event 220 delivered.
  • Content Delivery Log includes information associated with the delivery of event 220 to each participant 120. Preferably, this information includes an event identification, a ticket identification, a user identification for billing, a time on event, a time off event, a duration of event, and a reason for leaving event ⁇ e.g., system failure, voluntary departure, etc.). Other information may be included in the Content Delivery Log as would be apparent. Reporting on Delivery of Event
  • Director server 410 also provides various reports regarding event 220 to either system operators ⁇ e.g., stadium owners) or content providers 110. As would be apparent, various reports may be generated from data and delivery statistics associated with event 220, stadium 210, participants 120, participant managers 130, and/or content provider 110.
  • one such report may provide information regarding ticket allocation with respect to a particular content provider 110 operating multiple events 220 in stadium 210.
  • This report may provide: a number of tickets available to be distributed for all future events; a number of tickets allocated for current or pending events; a number of tickets to past or current events that were allocated but not dispensed to participants; a number of tickets that were dispensed to and actually used by participants; and a number of tickets that were dispensed to but not used by participants.
  • Another report may provide post-event information on the allocation of tickets to an individual event with the stadium. This report may provide: a number of tickets that were allocated to the event but were not dispensed; the number of tickets that were dispensed to and used by participants; and the number of tickets that were dispensed to but not used by participants.
  • Another report may provide pre-event information on the number of tickets that have been allocated and dispensed for a single event within a particular geographic region ⁇ i.e., within the domain of a particular participant manager). Still another report may provide pre-event statistics on the number of tickets that have been allocated and dispensed for all events within a particular geographic region.
  • Yet still another report may provide post-event information on the number of participants that actually used their ticket to participate in the event by geographic region. Another report may provide post-event information on the duration of participation for each participant by geographic region. Still another report may provide a number of tickets allocated and used based on the classification of the ticket.
  • Tickets 240 provide a mechanism in multicast environment 100 for identifying, authenticating, measuring, and controlling participants 120 participating in events 220 within stadium 210.
  • Each ticket 240 includes a unique identifier, preferably encrypted by itself or with other information, that is used to authenticate ticket 240, to provide security to event 220, and to associate any demographic or other participant information gathered by the system.
  • Tickets 240 may be of different types including, but not limited to, a single event ticket, a multi-event ticket ⁇ e.g., a season ticket), a time-based ticket ⁇ e.g., a three day pass), or a subscription ticket ⁇ e.g. weekly or monthly access).
  • Different types of tickets 240 may specify different manners of delivery such as delivery at a regularly scheduled time versus delivery "on demand”.
  • Different types of tickets 240 may also specify one or more different classes of service ⁇ e.g. gold or platinum levels).
  • ticket 240 includes first authentication information and second authentication information.
  • First authentication is used by turnstile 230 to locally determine whether ticket 240 is a valid ticket ⁇ i.e., one provided by director server 410).
  • Second authentication is used by participant managers 130 to actually authenticate that ticket 240 was provided to the particular participant 120 in possession of ticket 240.
  • Ticket 240 may also include information associated with participant 120, information regarding a class of service, an address of participant managers 130 to which turnstile 230 should attach, and/or an address associated with advertising information to be provided to participant 120 during event 220.
  • Ticket 240 may be acquired at various locations within multicast environment 100 including ticket provider 150, content provider 110, and/or stadium 210. Ticket 240 may be acquired "in advance" or "at the door.” Preferably, tickets 240 are acquired at a director server 410 associated with stadium 210 hosting event 220. Alternately, any of these locations may direct participant 120 to a single source of tickets 240 such as ticket provider 150. According to the present invention, ticket provider 150 includes any source of tickets 240 including commercial "bricks and mortar" sources. Participant 120 may acquire a ticket 240 in various manners. In one embodiment of the present invention, participant 120 acquires ticket 240 by providing various demographic or survey information associated with participant 120. In exchange for this information, ticket provider 150 provides participant 120 with ticket 240.
  • participant 120 acquires ticket 240 by providing payment information in exchange for ticket 240.
  • Payment information may include billing information or an actual form of monetary compensation ⁇ e.g., cash, e-currency, etc.).
  • participant 120 acquires ticket 240 by providing both demographic information and payment information.
  • the payment information may entitle participant 120 to a higher class of service over those participants 120 only providing demographic information.
  • ticket 240 is distributed to participant 120 with no payment information or demographic information required.
  • Turnstile 230 functions as a gatekeeper to stadium 210 and event 220. Only those participants 120 with an appropriate ticket 240 are allowed to enter stadium 210 and participate in event 220.
  • turnstile 230 operates as an interface between participant 120 and content provider 110 (or other source of event 220). Turnstile 230 also operates as an interface between participant 120 and participant manager 130. Preferably, turnstile 230 is a plug-in (or similar code portion) that is downloaded from director server 410 and installed at participant 120.
  • FIG. 8 illustrates a relationship among participants 120, turnstiles 230, participant managers 130, and content providers 110.
  • participants 120 receive event 220 from content provider 110 via a multicast- enabled network communication system 105 (illustrated as solid lines in FIG .8).
  • Turnstiles 230 resident at each participant 120 monitor the delivery of event 220 and communicate delivery statistics upstream through a hierarchy 300 of participant managers 130 to director 140 via a separate protocol layer on network communication system 105 referred as a LEAP protocol (illustrated as dashed lines in FIG .8).
  • Turnstile 230 identifies, authenticates, classifies, and controls participants 120 and their ability to access events 220. Turnstile 230 also monitors use by measuring a duration of time participant 120 accessed event 220 and/or an amount of data participant 120 received from event 220.
  • the LEAP protocol implements a signaling and transport protocol for managing events 220 in stadium 210.
  • the LEAP protocol is a light-weight transaction protocol built on top of a User Datagram Protocol ("UDP").
  • UDP User Datagram Protocol
  • the LEAP protocol enables unicast as well as multicast transactions. Most transactions within the LEAP protocol are reliable transactions. That is, each transaction is verified as successful or failed. This may be accomplished in various manners as would be apparent.
  • the LEAP facilitates many of the communications between components of multicast environment 100. More particularly, the LEAP protocol operates on turnstile 230, participant managers 130, and director server 410 to provide autodiscovery, self-organization, and communication among these components.
  • turnstile 230 notifies multicast environment 100 of its desire to participate in event 220 by sending a "JOIN" message within the LEAP protocol to a particular participant manager 130 identified in ticket 240.
  • the particular participant manager 130 determines whether ticket 240 is valid. If ticket 240 is a valid ticket, participant manager 130 responds with a "JOIN REPLY" message within the LEAP protocol indicating a successful joining of participant 120 to event 220. If ticket 240 is an invalid ticket, participant manager 130 responds with a JOIN REPLY message indicating that the joining failed and participant 120 is unable to gain access to event 220.
  • turnstile 230 sends a "LEAVE" message to the particular participant manager 130. Participant manager 130 responds with a "LEAVE ACKNOWLEDGEMENT" message.
  • the LEAP protocol is also used between and among participant managers
  • a lower level participant manager 130 (also referred to as a "downstream” participant manager 130) associates itself with a higher level participant manager 130 (also referred to as an "upstream” participant manager 130) by sending an "ATTACH” message within the LEAP protocol to the upstream participant manager 130.
  • the upstream participant manager 130 responds by sending an "ATTACH ACKNOWLEDGEMENT” message within the LEAP protocol to the lower level participant manager 130.
  • a participant manager 130 disassociates itself with another participant manager 130 by sending a "DETACH” message within the LEAP protocol.
  • the participant manager 130 being disassociated responds by sending a "DETACH ACKNOWLEDGEMENT" message within the LEAP protocol.
  • Data is exchanged between components by using a "DATA" message.
  • a requestor sends the "DATA" message to a requestee for data.
  • the requestee responds with the requested data in a "REPLY" message back to the requestor.
  • Many information exchanges are used in multicast environment 100. Examples of these include: director server 410 requesting that a particular participant manager 130 provide a list of all participants 120 attached to it; a downstream participant manager 130 requests that an upstream participant manager provide a list of all events 220 it has defined; and a participant manager 130 requests that a particular participant 120 provide statistics about itself.
  • Some information exchanges in the LEAP protocol are not transactions but controlled messages that flow upstream. These messages flow upstream at some requested configurable rate from a downstream entity such as a participant 120 or lower level participant manager 130 to a upstream entity such as a higher level participant manager 130 or director server 410. Examples of these messages include: aggregate participant statistic messages, dynamic topology messages indicating changes in hierarchy 300, and event specific statistic messages.
  • FIG. 9 illustrates a participant manager hierarchy 900 operating with a cast transaction.
  • Hierarchy includes a root participant manager 910, one or more internal participant managers 920, and one or more edge participant managers 930.
  • Root participant manager 910 is the highest level participant manager in hierarchy 900.
  • Internal participant managers 920 represent one or more levels of mid-level participant managers.
  • Edge participant managers 930 represent the lowest level participant managers in hierarchy 900. Attached to edge participant managers 930 are participants 120.
  • root participant manager 910 multicasts a "DATA" message to all other participant managers in hierarchy 900.
  • Edge participant managers 930 that received the multicasted DATA message respond by sending an affirmative "REPLY" message upstream, in this example, to one or internal participant managers 920.
  • edge participant manager 930B receives the multicasted DATA message, it sends an affirmative "REPLY” message to internal participant manager 920A.
  • edge participant manager 930F receives the multicasted DATA message, it sends an affirmative "REPLY" message to internal participant manager 920B.
  • Internal participant managers 920 only respond to the multicasted DATA message if and when all their downstream participant managers have responded.
  • internal participant manager 920A sends an affirmative "REPLY" message to root participant manager 910 only after receiving affirmative REPLY messages from each of participant managers 930A-C.
  • internal participant manager 920B sends an affirmative "REPLY” message to root participant manager 910 only after receiving affirmative REPLY messages from each of participant managers 930D-F.
  • the cast transaction is complete when a REPLY message has been received from all participant managers.
  • the cast fails, preferably via a timeout waiting on the REPLY message.
  • a localized retransmission of the DATA message is sent.
  • an upstream participant manager that received the DATA message and that has not received a REPLY from a downstream participant manager sends the DATA message directly to that downstream participant manager.
  • participant managers 130 form themselves into hierarchy 300 using an autodiscovery algorithm 1000 illustrated in FIG. 10 and FIG. 17.
  • Autodiscovery algorithm defines the process by which participant managers 130 discover their relationships to other participant managers in hierarchy 300.
  • Each participant manager 130 is assigned a level within hierarchy 300. As discussed above, this level preferably varies between 0 (the lowest level) and 255 (the highest level). These levels are assigned during system design and implementation so that the lowest level participant managers 130 preferably reside near participants 130 both logically (in terms of network address or number of "hops”) and geographically (in terms of physical location). Higher level participant managers 130 are similarly organized around the lower level participant managers 130. One example of such organization was described above with respect to FIG. 3.
  • Each participant manager 130 is likewise assigned a network address. While it would seem simple to merely arrange hierarchy 300 by having various lower level participant managers 130 report directly to a particular higher level participant manager 130 via this address, such an arrangement does not provide the self-organizing or self-healing features of the present invention. For example, if the particular higher level participant manager 130 fails, the lower level participant managers 130 assigned to it have no mechanism for reestablishing themselves in hierarchy 300. Similarly, the addition of a new participant manager 130 to hierarchy 300 would require that at least some of the lower level participant managers 130 be manually reassigned.
  • Autodiscovery algorithm 1000 provides both self-organizing and self-healing features by allowing participant managers 130 to locate one another and arrange themselves in hierarchy 300.
  • a preferred embodiment of autodiscovery algorithm 1000 with respect to a new participant manager 130 joining hierarchy 300 is now described with reference to FIG. 10.
  • the new participant manager 130 casts an "ANNOUNCE" message on a multicast address within multicast environment 100.
  • this multicast address is associated with a particular stadium 210 to which the new participant manager 130 is assigned.
  • the new participant manager 130 is "new” in the sense that it is not yet a member of hierarchy 300 and is desirous of discovering its place therein.
  • the ANNOUNCE message includes a unicast address and a level associated with the new participant manager 130 to which other participant managers 130 should respond.
  • the new participant manager 130 receives an "ANNOUNCE ACKNOWLEDGE" message from a replying participant manager 130.
  • the ANNOUNCE ACKNOWLEDGE message includes a unicast address and a level associated with the replying participant manager 130.
  • the new participant manager 130 determines whether the level of the replying participant manager 130 is less than its own level. If so, the response is ignored, and processing continues at step 1020 to evaluate responses from other participant managers 130. Otherwise, processing continues at a step 1040.
  • the new participant manager 130 determines whether the level of the replying participant manager 130 is greater than the level of an upstream participant manager 130 that the new participant manager 130 believes is the next higher level above his. This participant manager 130 is referred to as a current upstream participant manager and identifies the participant manager 130 to which the new participant manager is attached in hierarchy 300. If the level of the replying participant manager 130 is greater than the level of the current upstream participant manager, then the response is ignored, and processing continues at step 1020 to evaluate responses from other participant managers 130. Otherwise, processing continues at a step 1050.
  • step 1050 the new participant manager 130 determines whether the level of the replying participant manager 130 is less than the level of the current upstream participant manager 130. If so, processing continues at a step 1070.
  • Step 1070 is arrived at when the replying participant manager 130 has a level in between that of the new participant manager 130 and that of the current participant manager 130. This would indicate that the replying participant manager 130 should be identified as the current participant manager 130.
  • the replying participant manager is identified as the current participant manager 130. In a preferred embodiment, this is accomplished by sending an ATTACH message to the replying participant manager 130 and a DETACH message to the current participant manager 130.
  • step 1020 processing continues at step 1020 to evaluate responses from other participant managers 130.
  • Step 1060 is arrived at when the level of the replying participant manager 130 and that of the current upstream participant manager 130 are the same. When this occurs, the new participant manager 130 preferably attaches itself to the closest of the two same level participant managers 130.
  • the new participant manager 130 determines whether the replying participant manager 130 is closer than the current upstream participant manager 130. This may be accomplished by determining a number of hops between the new participant manager and each of the same level participant managers assuming that participant managers with fewer hops between one another are located physically closer to one another than those with more hops. Ties in the number of hops are resolved in favor of the participant manager with the closest network address.
  • step 1060 if the replying participant manager 130 is closer than the current upstream participant manager, then processing continues at step 1070 where the replying participant manager is identified as the current participant manager as described above. Otherwise, processing continues at step 1020 to evaluate responses from other participant managers 130. Autodiscovery algorithm 1000 is repeated until the new participant manager no longer receives further ANNOUNCE ACKNOWLEDGE messages. This portion of autodiscovery algorithm 1000 establishes the upstream connections of the new participant manager 130 within hierarchy 300.
  • FIG. 17 illustrates autodiscovery algorithm 1000 from the perspective of a participant manager 130 already existing in hierarchy 130.
  • This portion of autodiscovery algorithm 1000 now described establishes the downstream connections of the new participant manager 130 within hierarchy 300.
  • an existing participant manager 130 receives an ANNOUNCE message from the new participant manager 130.
  • the participant manager 130 is "existing" in the sense that it is already attached in hierarchy 300.
  • the existing participant manager 130 determines whether the level of the new participant manager 130 is less than its own level. If so, in a step 1720, the existing participant manager 130 responds by sending an ANNOUNCE ACKNOWLEDGEMENT message as discussed above. Otherwise processing continues at a step 1740.
  • step 1740 the existing participant manager 130 determines whether the level of the new participant manager 130 is less than the level of the current upstream participant manager 130. If so, the new participant manager 130 is closer than the current upstream participant manager 130, and processing continues at a step 1750. Otherwise, the ANNOUNCE message from the new participant manager 130 is ignored.
  • step 1750 because the new participant manager 130 is closer than the current upstream participant manager 130, the existing participant manager 130 detaches from the current upstream participant manager 130.
  • step 1760 the existing participant manager 130 restarts autodiscovery algorithm 1000 by casting an ANNOUNCE message in step 1010.
  • multicast environment The operation of multicast environment is now described from a perspective of each of the following components: participant 120, turnstile 230, participant manager 130, director server 410, and finally, director client 420.
  • FIG. 11 illustrates an operation 1100 of multicast environment 100 from a perspective of a participant 120 according to one embodiment of the present invention.
  • participant 120 preferably selects an event 220 from either a web page provided by content provider 110 or from stadium 210.
  • participant 120 may be delivered a link to event 220 via an e-mail, a URL address or other mechanism.
  • a step 1120 after selecting event 220, director server 410 determines whether participant 120 has turnstile 230 installed. In a preferred embodiment of the present invention, this accomplished using the SURL delivery method as described above. If the SURL determines that turnstile 230 is installed processing continues at a step 1140. Otherwise, in a step 1130, participant 120 receives a turnstile 230 from director server 410. In step 1140, in one embodiment, turnstile 230 determines whether participant 120 has a valid ticket 240 to event 220. In an alternate embodiment, the SURL determines if participant 120 has a valid ticket 240 to event 220. If turnstile 230 determines that participant 120 has a valid ticket, processing continues at a step 1160. Otherwise, in a step 1150, participant 120 acquires a ticket 240 to event 220. In a preferred embodiment of the present invention, turnstile 230 directs participant 120 to a location where participant 120 may acquire ticket 240.
  • participant 120 accesses event 220, or more particularly, accesses a multicast address associated with event 220 as provided by the SURL delivery method from director server 410. This access initiates delivery of event 220.
  • this access invokes turnstile 230 at participant 120 if not already invoked.
  • this access also preferably launches an event renderer at participant 120.
  • participant's 120 participation in event 220 ends.
  • participant 120 closes the event renderer thereby ending participation in event 220.
  • the delivery of event 220 is completed thereby ending participation in event 220.
  • FIG. 12 illustrates an operation 1200 of multicast environment 100 from a perspective of turnstile 230 according to the present invention.
  • turnstile 230 is installed onto participant 120.
  • turnstile 230 is invoked when participant 120 accesses event 220.
  • turnstile 230 is invoked when participant 120 attempts to access a multicast address associated with event 220.
  • turnstile 230 prohibits participant 120 from joining the multicast until various requirements ⁇ e.g. authorization from participant manager 130) are met.
  • turnstile 230 is a wrapper ⁇ e.g., Java applet) around the event renderer that intercepts signaling to the event renderer thereby prohibiting its launch, until the various requirements are met.
  • wrapper e.g., Java applet
  • turnstile 230 locates its corresponding participant manager
  • turnstile 230 invokes autodiscovery algorithm 1000 as described above to seek out its corresponding participant manager.
  • turnstile 230 determines an address to its corresponding participant manager 130 from ticket 240.
  • turnstile 230 is pre-assigned an address of the corresponding participant manager 130.
  • turnstile 230 determines if participant 120 has a valid ticket 240. If not, in a step 1260, turnstile 230 directs participant 120 to ticket provider 150. Otherwise, processing continues at a step 1240. In step 1240, turnstile 230 forwards ticket 240 corresponding to event 220 to participant manager 130. In a preferred embodiment of the present invention, turnstile 230 forwards ticket 240 to participant manager 130 in conjunction with a JOJ-N message to participant manager 130.
  • turnstile 230 receives a message from participant manager
  • step 1260 turnstile 230 directs participant 120 to ticket provider 150 where ticket 240 can be acquired.
  • the event renderer at participant 120 is launched as discussed above to render event 220.
  • turnstile 230 directs the event renderer to a source of the information stream associated with event 220, from which the event renderer collects the information stream and renders if for participant 120.
  • turnstile 230 periodically gathers delivery statistics associated with the delivery of event 220 to participant 120 and forwards them to participant manager 130. In one embodiment, turnstile 230 gathers and forwards delivery statistics at a start and end of event 220. In another embodiment, turnstile 230 gathers and forwards delivery statistic at a particular rate (e.g. once every two seconds). In yet another embodiment, turnstile 230 gathers and forwards delivery statistics when queried by director server 410 or one of participant managers 130. Participant Manager's Perspective
  • FIG. 13 illustrates an operation 1300 of multicast environment 100 from a perspective of participant manager 130 according to the present invention.
  • participant manager 130 locates itself with hierarchy 300. Preferably, participant manager 130 does so using autodiscovery algorithm 100 as described above. Once so located, at some point in time, participant manager 130 receives a ticket 240 from turnstile 230 accompanied by a request to authenticate ticket 240.
  • participant manager 130 attempts to authenticate ticket 240. As discussed above, participant manager 130 uses second authentication information included in ticket 240 to verify that ticket 240 was provided to participant 120. In a step 1340, participant manager 130 notifies turnstile 230 of the results of the authentication.
  • participant manager 130 collects delivery statistics from turnstile 230.
  • participant manager 130 collects delivery statistics from each of turnstiles 230 below it in hierarchy 300.
  • participant manager 130 aggregates the delivery statistics from each of turnstiles 230.
  • participant manager 130 forwards the aggregated delivery statistics to the upstream participant manager 130.
  • each level of participant managers 130 aggregate the delivery statistics so that they are correlated from root to leaf at any point in time within hierarchy 300. For example, San Francisco participant manager 340A aggregates delivery statistics from participants 350A-C and forwards them to Central California participant manager 330.
  • Central California participant manager 310 aggregates delivery statistics from San Francisco participant manager 340A, San Jose participant manager 340B, and Oakland participant manager 340C and forwards them to California participant manager 320A.
  • Each higher level participant manager 130 aggregates and forwards delivery statistics from those participant managers immediately beneath it until director server 410 receives the aggregated delivery statistics representing all participants 120 of a particular event 220.
  • the delivery statistics may include: an identification of event 220, an identification of participant manager 130 forwarding the statistics, a number of participants 120 directly attached to the participant manager 130, and an aggregate number of participants 120 indirectly attached to the participant manager 130 through lower level participant managers 130. Delivery statistics may also include a time a particular participant 120 joined particular event 220, and/or a time the particular participant 120 left the particular event 220
  • FIG. 14 illustrates an operation 1400 of multicast environment 100 from a perspective of director server 410 according to the present invention.
  • director server 410 locates the highest level participant managers 130 in hierarchy 300.
  • director server 410 locates the highest level participant managers 130 using autodiscovery algorithm 1000. For example, as illustrated in FIG. 3, director 140 ⁇ i.e., director server portion 410) discovers West Coast participant manager 310 as well as any other participant managers 130 sharing the same level (not illustrated).
  • director server 410 knows ahead of time the address of the highest level participant managers 130.
  • a step 1420 content provider 110 creates event 220 at director server 410 using director client 420.
  • director server 410 creates and allocates tickets 240 for event 220.
  • creating event 220 includes describing all properties of event 220 including, but not limited to, advertisements associated with event 220 and to the provisioning of tickets 240 for event 220.
  • director server 410 notifies its participant managers 130 of event 220.
  • director server 410 preferably supplies its participant managers 130 with an identification of event 220, a duration of event 220, and a duration during which participants 120 are allowed to join.
  • director server 410 provides a ticket 240 to participant 120 to access event 220.
  • director server 410 In a step 1450, director server 410 periodically receives delivery statistics associated with event 220 from its participant managers 130. In a step 1460, director server 410 logs these delivery statistics as discussed above. In a step 1470, director server 410 provides director client 420 with the delivery statistics so that content provider 110 or a system operator can view the delivery statistics.
  • FIG. 15 illustrates an operation 1500 of director server 410 responding to a query from director client 420 with respect to delivery statistics associated with a particular participant manager 130 in hierarchy 300. In a step 1510, director server 410 receives a request from director client 420 regarding the delivery statistics associated with one of participant managers 130 in hierarchy 300. Preferably, this request can be made for any of participant managers 310, 320, 330, and 340, or participants 350 in hierarchy 300.
  • director server 410 queries the particular participant manager 130 directly.
  • director server 410 receives delivery statistics directly from the queried participant manager 130.
  • director server 410 provides director client 420 with the requested delivery statistics associated with the particular participant manager 130 in hierarchy 300.
  • FIG. 16 illustrates an operation 1600 of multicast environment 100 from a perspective of director client 420 according to the present invention. Operation 1600 is now described with reference to FIG. 5.
  • a step 1610 after being installed at a user ⁇ i.e., either content provider 110 or a system operator) director client 420 requests information regarding hierarchy 300 and delivery statistics associated therewith for a particular event 220 from director server 410.
  • director client 420 receives the requested information from director server 410.
  • director client 420 presents the user with a graphic user interface such as GUI 500 illustrated in FIG. 5.
  • GUI 500 illustrated in FIG. 5.
  • an initial presentation of hierarchy 300 in GUI 500 includes director server 410 and its participant managers 130 i.e. the highest level participant managers 130 in hierarchy 300 directly connected to director server 410 such as West Coast participant manager 310).
  • the aggregated delivery information associated with event 220 is preferably presented in GUI 500 with respect to director server 410 with its constituent components broken down for each of participant managers 130.
  • director client 420 receives a request from the user for delivery statistics with respect to a particular participant manager 130.
  • director client 420 forwards the request directly to the particular participant manager 130.
  • the director client 420 receives the requested delivery statistics directly from the particular participant manager 130.
  • director client 420 presents the user with an updated GUI 500 with the delivery statistics for the particular participant manager 130.
  • Director client 420 provides the user with several mechanisms for selecting the particular participant manager 130 for which delivery statistics are desired.
  • the user may expand GUI tree structure 515 by "clicking on” structure indicators 520, 525.
  • the GUI aspect of the present invention operates in a familiar manner to the "directory structure" of a typical "file manager.” In doing so, director client 420 requests more specific information with respect to each lower level participant manager 130 appearing in the expanded GUI tree structure 515.
  • delivery statistics are requested for each corresponding lower level participant manager 130 until GUI tree structure 515 is fully expanded at which time delivery statistics are requested for individual participants 120.
  • the user may also select a particular participant manager 130 or participant 120 within GUI tree structure 515 to obtain delivery statistics for that particular entity as described above.
  • participants 120 acquire ticket 240 at least in part, by providing demographic information to ticket provider 150.
  • demographic information may include, but is not limited to, a name, a geographic location, an address, an age, a gender, a household income, an occupation, a telephone number, an email address, a product preference, and various other demographic or marketing information as would be apparent.
  • such demographic information is gathered by ticket providers 150 and collected at director server 410 and preferably organized using an identification of ticket 240 that was issued in exchange for the demographic information.
  • This demographic information may be used to provide targeted advertising to participants 120 that correspond to a particular demographic profile.
  • Such a demographic profile may be generated at director client 420 and forwarded to director server 410 to obtain a list of participants 120 that match the demographic profile for a particular event 220 or group of events 220 so that a particular advertisement maybe sent to the list of participants 120.
  • one or more URL addresses are included with ticket 240 for delivering advertising information to participant 120 during event 220.
  • One URL address may deliver a "stadium banner" that is delivered to all participants of event 220.
  • Another URL address may deliver an advertising stream only to those participants 120 of event 220 that match a particular demographic profile.
  • a particular advertiser may wish to target an advertisement towards 18-25 year old males living within a particular geographic area (e.g., San Francisco) during a particular event or type of event.
  • the advertiser would access the present invention through director client 420 to create an appropriate demographic profile corresponding to this group of individuals and forward it to director server 410.
  • Director server 410 subsequently includes a URL address corresponding to the advertisement in tickets 240 for the particular event 220 or type of event provided to participants 120 that the match the advertiser's demographic profile.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un système et un procédé permettant de diffuser de manière sélective des données sur un réseau, lequel système comprend un administrateur, une hiérarchie de gestionnaires de participants, et un tourniquet installé chez chaque participant auquel les données sont envoyées. Des fournisseurs de contenu fournissent des informations associées à un événement (c'est-à-dire des données) à l'administrateur. L'administrateur supervise la délivrance de l'événement à un participant. En particulier, l'administrateur attribue et fournit un ticket pour l'événement au participant. Le participant acquiert le ticket de l'administrateur, directement ou indirectement. Lorsque le participant tente d'accéder à l'événement, le tourniquet installé localement authentifie le ticket, octroyant de la sorte l'accès à l'événement. Le tourniquet fournit également à l'administrateur des statistiques de délivrance associées à la délivrance de l'événement via la hiérarchie des gestionnaires de participants.
PCT/US2001/016156 2000-05-18 2001-05-18 Systeme et procede de diffusion selective de donnees WO2001089150A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001263273A AU2001263273A1 (en) 2000-05-18 2001-05-18 System and method for multicasting data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US57285300A 2000-05-18 2000-05-18
US09/572,853 2000-05-18

Publications (2)

Publication Number Publication Date
WO2001089150A2 true WO2001089150A2 (fr) 2001-11-22
WO2001089150A3 WO2001089150A3 (fr) 2002-05-02

Family

ID=24289626

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/016156 WO2001089150A2 (fr) 2000-05-18 2001-05-18 Systeme et procede de diffusion selective de donnees

Country Status (2)

Country Link
AU (1) AU2001263273A1 (fr)
WO (1) WO2001089150A2 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7031945B1 (en) * 2000-07-24 2006-04-18 Donner Irah H System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services
US7216109B1 (en) * 2000-07-24 2007-05-08 Donner Irah H System and method for reallocating and/or upgrading and/or selling tickets, other event admittance means, goods and/or services
WO2007062017A2 (fr) 2005-11-23 2007-05-31 Envisionit Llc Systeme et procede de facturation de la radiodiffusion d'un message
US7693938B2 (en) 2004-02-13 2010-04-06 Envisionit Llc Message broadcasting admission control system and method
US7752259B2 (en) 2004-02-13 2010-07-06 Envisionit Llc Public service message broadcasting system and method
US7801538B2 (en) 2004-02-13 2010-09-21 Envisionit Llc Message broadcasting geo-fencing system and method
US8438212B2 (en) 2004-02-13 2013-05-07 Envisionit Llc Message broadcasting control system and method
WO2013064796A1 (fr) * 2011-11-04 2013-05-10 Music Glue Ltd Gestion d'accès
US10917760B1 (en) 2020-06-02 2021-02-09 Envisionit Llc Point-to-multipoint non-addressed message processing system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2094410C (fr) * 1992-06-18 1998-05-05 Joshua Seth Auerbach Reseau de communication a gestion repartie

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7031945B1 (en) * 2000-07-24 2006-04-18 Donner Irah H System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services
US7216109B1 (en) * 2000-07-24 2007-05-08 Donner Irah H System and method for reallocating and/or upgrading and/or selling tickets, other event admittance means, goods and/or services
US8438212B2 (en) 2004-02-13 2013-05-07 Envisionit Llc Message broadcasting control system and method
US9224161B2 (en) 2004-02-13 2015-12-29 Envisionit Llc System and method for verifying message delivery integrity in a wireless mobile message broadcasting system
US7693938B2 (en) 2004-02-13 2010-04-06 Envisionit Llc Message broadcasting admission control system and method
US7752259B2 (en) 2004-02-13 2010-07-06 Envisionit Llc Public service message broadcasting system and method
US7801538B2 (en) 2004-02-13 2010-09-21 Envisionit Llc Message broadcasting geo-fencing system and method
US10674322B2 (en) 2004-02-13 2020-06-02 Envisionit Llc Point-to-multipoint message processing system and method
US8073903B2 (en) 2004-02-13 2011-12-06 Envisionit, Llc Message alert broadcast broker system and method
US8103719B2 (en) 2004-02-13 2012-01-24 Envisionit, Llc Message broadcasting control system and method
US9924328B2 (en) 2004-02-13 2018-03-20 Envisionit Llc Geotargeted broadcast message aggregator/gateway system and method
US8438221B2 (en) 2004-02-13 2013-05-07 Envisionit, Llc Broadcast alerting message aggregator/gateway system and method
US9224160B2 (en) 2004-02-13 2015-12-29 Envisionit Llc System and method for message receipt verification in a wireless mobile message broadcasting system
US9136954B2 (en) 2004-02-13 2015-09-15 Envisionit Llc Broadcast alerting message aggregator/gateway system and method
US8583519B2 (en) 2005-11-23 2013-11-12 Envisionit, Llc Message broadcasting network usage billing system and method
WO2007062017A3 (fr) * 2005-11-23 2007-10-04 Envisionit Llc Systeme et procede de facturation de la radiodiffusion d'un message
WO2007062017A2 (fr) 2005-11-23 2007-05-31 Envisionit Llc Systeme et procede de facturation de la radiodiffusion d'un message
US7917413B2 (en) 2005-11-23 2011-03-29 Envisionit Llc Message broadcasting billing system and method
WO2013064796A1 (fr) * 2011-11-04 2013-05-10 Music Glue Ltd Gestion d'accès
US10917760B1 (en) 2020-06-02 2021-02-09 Envisionit Llc Point-to-multipoint non-addressed message processing system

Also Published As

Publication number Publication date
AU2001263273A1 (en) 2001-11-26
WO2001089150A3 (fr) 2002-05-02

Similar Documents

Publication Publication Date Title
US6625643B1 (en) System and method for resource management on a data network
US10171846B2 (en) System and method for routing media
US7680912B1 (en) System and method for managing and provisioning streamed data
KR100877012B1 (ko) 그룹 통신 시스템 내에서 쿠폰을 사용하는 쿠폰 시스템 및방법
US6801936B1 (en) Systems and methods for generating customized bundles of information
CN1606751B (zh) 用于组播的计费机制
US8527347B2 (en) Integration architecture for mobile advertisement campaign management, marketplace and service provider interface
US6516341B2 (en) Electronic mail system with advertising
CA2352207C (fr) Annonce de description de session
CN101127767B (zh) 一种创建网络聊天平台的方法及系统
US20080196092A1 (en) Method and system for reducing the proliferation of electronic messages
JP2004513431A (ja) 分散型ネットワークキャッシュの協同管理
AU756725B2 (en) Announced session control
EP1956777A2 (fr) Procédé et système pour la réduction de la prolifération de messages électroniques
US20140149587A1 (en) Techniques for measuring peer-to-peer (p2p) networks
JP2002140309A (ja) サービスシステム
WO2001089150A2 (fr) Systeme et procede de diffusion selective de donnees
KR100801069B1 (ko) 피투피 컨텐츠 공유/유통 시스템 및 그 처리 방법
US7478172B1 (en) Supporting communication applications between enterprises in a secure manner
US7768945B2 (en) Method and access apparatus for accessing broadband video service
US20230137114A1 (en) System and method for matching and collecting user data and/or user device data
KR100378760B1 (ko) 인터넷 서비스 시스템들의 통합 방법
KR20020085651A (ko) 웹사이트의 페이지 일부 또는 특정 프레임 임대 서비스방법 및 시스템
CA2443592A1 (fr) Systemes de coupons et procedes d'utilisation de coupons au sein d'un systeme de communications par groupe
RU2764159C1 (ru) Система и способ сопоставления и сбора данных пользователя и/или пользовательского устройства

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载