(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0061305 A1
`Copley et al.
`(43) Pub. Date:
`Mar. 27, 2003
`
`US 20030061305A1
`
`(54) SYSTEM AND METHOD FOR ENHANCING
`STREAMING MEDIA DELIVERY AND
`REPORTING
`
`(75) Inventors: Devon Copley, New York, NY (US);
`Elango Chidambaram, Jersey City, NJ
`(US); Chris Sokol, Weehawken, NJ
`(US); Alexander Henderson, Stroud
`(GB)
`
`Correspondence Address:
`LERNER, DAVID, LITTENBERG,
`KRUMHOLZ & MENTLIK
`600 SOUTHAVENUE WEST
`WESTFIELD, NJ 07090 (US)
`
`(73) Assignee: Chyron Corporation, Melville, NY
`(21) Appl. No.:
`10/107,228
`
`(22) Filed:
`
`Mar. 26, 2002
`
`Related U.S. Application Data
`(60) Provisional application No. 60/280,702, filed on Mar.
`30, 2001.
`
`Publication Classification
`
`G06F 15/16
`(51) Int. Cl."
`(52) U.S. Cl. ............................................ 709/217; 709/231
`(57)
`ABSTRACT
`A content distribution system provides the ability for a user
`to Select content from one location and, if problems develop
`in Streaming the content to the user, to automatically fallback
`to a Second location for the content. In particular, the System
`comprises a client-side computer, a management Server, a
`reporting Server, and an asset Server. The client-side com
`puter comprises a player for playing content to a user. The
`player initially Selects a provider for providing the content as
`a function of previous Service data associated with the
`provider, via the management Server. If problems are
`encountered with providing the content from the Selected
`provider, the player dynamically falls back to another pro
`vider of the content.
`
`106
`
`108
`
`Preferences f
`Demographics
`
`CLIENT-SOE
`los?
`
`107
`
`
`
`132
`
`
`
`13
`
`130 N-
`
`Real-Time
`Reporting
`Applet/Page
`
`Historical
`Reporting
`Applet/Page
`
`
`
`
`
`144
`
`143
`
`142
`141
`
`40 -
`
`(web interface)
`
`t Java interface
`Native Client App
`Plug-in for Media Assef
`Management System
`
`
`
`16
`
`7
`
`Playlist Generator
`
`Historica
`Reporting
`Engine
`
`146
`
`
`
`Maintenance
`145
`
`seRVer-Side
`
`N
`110
`
`190
`
`
`
`Distributor
`
`
`
`
`
`Assorted
`Hosting
`Providers
`
`too
`
`-1-
`
`Amazon v. Audio Pod
`US Patent 9,729,907
`Amazon EX-1009
`
`

`

`Patent Application Publication Mar. 27, 2003. Sheet 1 of 6
`
`US 2003/0061305 A1
`
`
`
`
`
`
`
`
`
`-2-
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 2 of 6
`
`può
`
`
`
`
`
`
`
`
`
`-3-
`
`

`

`Patent Application Publication Mar. 27,2003 Sheet 3 of 6
`
`US 2003/0061305 Al
`
`3dIS-uaANaS
`
`oll
`
`S61
`
`Jonquysig
`
`popossy
`
`SUOPIAOIg
`
`Buysopy
`
`
` [e]eee[a]
`
`souaUE}Ueyy
`
`jesoiny
`
`awyjeeymi
`J0s8yBpeyyJo}ULB|
`
`
`/WaISkSWewWaheuayy
`
`Ll.—_—eeaaoeoe
`=eeteeeeeeey
`
` eoBpe}U}Baer}{eoepew)gem)
`
`ddyqualiaanen
`
`
`sojydasBowieg/Se0UeIOJO1Yaentantennnnr
`ebegnaiddy
`obeynoiddy
`SU]-[BOY
`
`Buyioday
`Bupiodey
`[B9103S/H
`
`LilOlt
`
`
`
`uwog€‘OLg
`
`901
`
`Buyiodey
`
`Joyasaues)
`
`Indu
`
`cel
`
`801
`
`Sol
`
`SdIS-LNAMND
`
`-4-
`
`-4-
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 4 of 6
`
`US 2003/0061305 A1
`
`
`
`-5-
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 5 of 6
`
`US 2003/0061305 A1
`
`
`
`
`
`
`
`-6-
`
`

`

`Patent Application Publication Mar. 27, 2003 Sheet 6 of 6
`
`US 2003/0061305 A1
`
`
`
`LTZ - FULL DE
`
`
`
`
`
`(Meu wosº) zsgºw T : suesn que uno
`
`-7-
`
`

`

`US 2003/0061305 A1
`
`Mar. 27, 2003
`
`SYSTEMAND METHOD FOR ENHANCING
`STREAMING MEDIA DELIVERY AND
`REPORTING
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`0001. The present application claims the benefit of U.S.
`Provisional Application No. 60/280,702, filed Mar. 30,
`2001, the disclosure of which is hereby incorporated by
`reference herein.
`
`BACKGROUND OF THE INVENTION
`0002 The invention relates generally to systems and
`methods for delivering Streaming media and more particu
`larly to Systems and methods for enhancing Streaming media
`delivery and reporting in a content distribution network
`(CDN).
`Current streaming media delivery systems and
`0.003
`methods are unreliable due in part to distribution network
`failures, varying delivery quality Standards, and multiple
`media format Standards. Distribution networkS Such as the
`Internet often fail to maintain adequate connections between
`media delivery Servers and end user computers, causing
`media delivery Sessions to end prior to completion, or to
`experience undesirable delays during delivery. Varying qual
`ity standards for delivery reduce reliability of media delivery
`acroSS different Systems. The popularity of multiple media
`format Standards causes duplication of effort in the deploy
`ment of media Selections, increases development costs,
`complicates media asset hosting and management arrange
`ments, and makes unified reporting difficult.
`0004.
`In addition, current streaming media delivery sys
`tems and methods are unable to provide extensive and
`accurate real-time and historical reporting of media delivery
`demand and performance. Nor are they able to provide
`conditional delivery of media content, for example, for
`advertising purposes, on the basis of user or player prefer
`ences, demographics, or other relevant information. Nor are
`they adapted to integrate with media asset management
`Systems to ease publishing.
`
`SUMMARY OF THE INVENTION
`0005. In accordance with the invention, a content distri
`bution System provides the ability for a user to Select content
`from one location and, if problems develop in Streaming the
`content to the user, to automatically fallback to a Second
`location for the content.
`0006. In accordance with an embodiment of the inven
`tion, a System comprises a client-side computer, a manage
`ment Server, a reporting Server, and an asset Server. The
`client-side computer comprises a player for playing content
`to a user. The player initially Selects a provider for providing
`the content as a function of previous Service data associated
`with the provider, via the management Server. If problems
`are encountered with providing the content from the Selected
`provider, the player dynamically falls back to another pro
`vider of the content.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0007 FIG. 1 shows an illustrative block diagram of a
`System in accordance with the principles of the invention;
`
`0008 FIG. 2 shows an illustrative flow chart, in accor
`dance with the principles of the invention, for use in the
`system of FIG. 1;
`0009 FIG.3 shows another illustrative block diagram of
`a System in accordance with the principles of the invention;
`0010 FIG. 4 shows an illustrative structure for a media
`group and mediaballs;
`0011 FIG. 5 shows another illustrative flow chart in
`accordance with the principles of the invention; and
`0012 FIG. 6 shows an illustrative report for use in the
`system of FIG. 3.
`
`DETAILED DESCRIPTION
`0013 AS described further below, the invention over
`comes the above-described limitations by providing an
`end-to-end solution for the deployment of live and archived
`Streaming media assets. It provides a high quality of Service,
`extensive and accurate real-time and historical reporting,
`low development costs, and rapid time to market for both
`turnkey and customized media delivery Solutions.
`0014. The inventive concept provides a high quality of
`Service by using the Streaming media deployment networks
`of a plurality of streaming media providers. (AS used herein,
`a provider hosts content.) By leveraging the strengths of a
`number of providers, the invention achieves better perfor
`mance than any Single provider could achieve.
`0015. In addition, the inventive concept further provides
`for a high quality of Service by using an intelligent network
`Selection process to determine the optimum Streaming media
`provider, and rank the remaining available providers, for
`each client. The intelligent network Selection process
`involves collecting usage and performance data relevant to
`each provider, Storing the data, and using the data to rank the
`providers.
`0016. The inventive concept further provides a high
`quality of Service by employing client-side performance
`monitoring to automatically detect and correct connection
`failures or performance problems. When such difficulties are
`encountered, a System in accordance with the invention
`automatically Switches the Streaming activity to the next
`optimum provider to minimize disruption to the media
`delivery.
`0017. The inventive concept provides for extensive and
`accurate real-time and historical reporting by employing
`client-side collection of performance and user activity data.
`The collection of the data enables and provides unified
`reporting acroSS multiple Streaming media providers and for
`multiple media formats.
`0018. The inventive concept provides low development
`costs and rapid time to market by providing a media player
`that can accommodate a plurality of different media formats,
`including future formats. In addition, the inventive concept
`further provides for low development costs and rapid time to
`market by providing media asset management and distribu
`tion Systems that make it easier for customers, or distribu
`tors, to transfer and publish content.
`0019. Thus, a system in accordance with the principles of
`the invention enables a user to experience a media Selection
`authored by others (e.g., any entity that authors one or more
`
`-8-
`
`

`

`US 2003/0061305 A1
`
`Mar. 27, 2003
`
`media Selections that are published So that the media Selec
`tions can be experienced by the user). (AS used herein, a
`media Selection comprises audio Selections and/or video
`Selections and are also referred to as “content.)
`0020. An illustrative system 10 in accordance with the
`principles of the invention is shown in FIG. 1. Other than
`the inventive concept, the elements shown in FIG. 1 are well
`known and not described further herein. For example, a
`Server (e.g., management server 110) is typically a high
`performance, multi-processor based computer System as
`known in the art. In addition, elements of the inventive
`concept are implemented using conventional programming
`techniques (including, e.g., HTML, etc.), which, as Such,
`will not be described herein. As described further below,
`system 10 is a combination of server side and client side
`technologies designed to enhance the reliability of Streaming
`media (e.g., Real Media, Windows Media, MPEG, Quick
`time, DIVX, etc.).
`0021) System 10 of FIG. 1 comprises a distributed net
`work comprising at least one client (user, or end-user)
`computer-based platform 105 (client-side 105), and a plu
`rality of other Servers—e.g., provider 1, provider 2, media
`management (management) server 110, reporting server 130
`and asset server 140 (all described further below). It is
`assumed that the various elements shown in FIG. 1 are
`coupled together via a network 11. For the purposes of this
`description it is assumed that network 11 is representative of
`the Internet, although the inventive concept is not So limited
`and may apply, e.g., to internal networks, etc. In this context,
`the various elements of system 10 communicate with one
`another through common communication protocols includ
`ing transmission control protocol/Internet protocol (TCP/IP)
`and hypertext transfer protocol (HTTP).
`0022 Client-side 105 comprises for example, a personal
`computer with all of the components normally found in a
`personal computer, running an operating System upon which
`Software applications can run, including networking Soft
`ware and a Web browser for visiting Web sites, viewing Web
`pages, running Web applications and transferring files. In
`accordance with the invention, one of the Software applica
`tions is client 108 (described below).
`0023. Each server of FIG. 1 comprises, for example, a
`Server computer with all of the components normally found
`in a Server computer, running a server operating System upon
`which Software applications can run, including networking
`Software and server Software for serving Web pages, Web
`applications, and files, and Soliciting and receiving data from
`the user client and other Servers.
`0024.
`For the purposes of this example, it is assumed that
`a number of host providers 196 (also referred to herein as
`simply “providers”, or “media delivery servers”), exist for
`providing content, as represented by provider Server 1 and
`provider server 2 of FIG. 1. Provider server 1 hosts a first
`media file (not shown in FIG. 1) (e.g., at a first location),
`while provider server 2 hosts a second media file (not shown
`in FIG. 1) at a second location.
`0.025
`Illustratively, each of the first and second media
`files represent the same type of media Selection (e.g., the
`same Video clip of a recent news event) and both are capable
`of being played by client 108. As will be discussed below,
`and in accordance with the invention, the Second media file
`
`Serves as a backup file if the Streaming of the first media file
`fails. In this regard, and in accordance with the invention,
`client 108 is adapted to play the first media file from the first
`location, and, when the Streaming of the first media file fails,
`to detect the failure and play the second media file from the
`second location (described below). It should be understood
`that each provider Server is adapted to Stream its media file
`to the player on demand in a manner known in the art.
`0026. An illustrative flow chart of a method for use in
`accordance with the principles of the invention is shown in
`FIG. 2. It should be understood that the method of the
`invention can be practiced without regard to the Specific
`System that is used to practice the invention. The flow chart
`of FIG. 2 provides a method for enabling a user to experi
`ence a media selection. In step 205, a first media file is stored
`at a first location. In Step 210, a Second media file is Stored
`at a second location. Steps 205 and 210 are illustratively
`performed on the server-side of, e.g., system 10 of FIG. 1
`by, e.g., management Server 110 and/or provider Servers 1
`and 2. In step 215, client-side 105 downloads and executes
`a streaming media player for execution. (It should be noted
`that although the inventive concept is illustrated in the
`Simple context of two media files (a first and a Second), it is
`applicable to N media files, N>1.)
`0027. For example, a user associated with client-side 105,
`via a browser, accesses a link (not shown) displayed on a
`page provided by another server (not shown) (e.g., a dis
`tributor of the inventive concept). This link fetches a page
`(also from the distributor's server), and renders it in a popup
`browser window on client-side 105. This new page includes
`(via the SRC attribute of SCRIPT tags) at least the client 108
`(comprising the streaming media player) (described below)
`codebase and a call to management Server 110, which Sets
`JavaScript variables with all the data that client 108 requires.
`0028. This streaming media player begins execution in
`step 220 and loads, or retrieves, the first media file, which is
`played in step 225. (Preferably, prior to the streaming of the
`first file, the first location has been determined to be more
`optimum for Streaming than the Second location.) In Step
`230, the Streaming media player checks for a failure condi
`tion or an end condition (e.g., end-of-file). If no failure
`condition occurs, the first media file continues to play.
`However, if a predefined failure condition is detected (e.g.,
`disconnect), then the Streaming media player loads, or
`retrieves, the second media file in step 235 and plays this
`media file in Step 225. Regardless, upon detection of a
`predefined end condition (e.g., end-of-file), playing termi
`nates. Thus, as described above, automatic fallback occurs to
`a Second media file upon detection of a failure in playing the
`first media file.
`0029) Turning now to FIG. 3 a more detailed block
`diagram of system 10 is shown. Client 108 further comprises
`a streaming media player 107 (player 107) and preference/
`demographics/input component 106 (input 106). Player 107
`comprises, e.g., a Windows Media Player component and/or
`a Real Player component, as known in the art. Input 106 is
`for displaying a Screen for collecting preference and/or
`demographic information from the user (described below).
`0030 Management server 110 is a server-side system that
`supplies client 108 with data to locate content to play.
`Management Server 110 further comprises a playlist genera
`tor 115, which comprises a provider determination element,
`
`-9-
`
`

`

`US 2003/0061305 A1
`
`Mar. 27, 2003
`
`a ruleset resolver element, and SMIL/ASX elements
`(described below). In addition management sever 110 com
`prises form generator 116 and form processor 117 (described
`below).
`Further in this aspect, client 108 is adapted to send
`0.031
`a request to playlist generator 115, of management Server
`110, for a first media play list and to receive this first playlist
`from playlist generator 115. (A playlist is a SMIL or ASX
`file, which comprises one or more URLS (uniform resource
`locaters) associated with media clips.) Correspondingly,
`playlist generator 115 is adapted to receive the request from
`client 108, generate the playlist, and provide the playlist to
`client 108. Illustratively, the above-described requests are
`achieved via client 108 by entering a network address of
`playlist generator 115 (e.g., an associated URL). Client 108
`is further adapted to use the first playlist to determine the
`first location (here, of provider server 1) and play the first
`media file therefrom. Preferably, as described below, pro
`vider server 1 has associated therewith a URL address that
`client 108 uses to access, and play, the first media file.
`0032. As mentioned above, client 108 may encounter
`connection failures and/or performance problems (all of
`which are to be understood as failures in that the Streaming
`experience is disrupted or undesirable) when playing the
`first media file. In this event, and in accordance with the
`invention, client 108 automatically Switches the streaming
`activity to another provider to minimize disruption to the
`media delivery. The types of failures encountered by client
`108 can comprise any type of failure (e.g., a disconnect,
`etc.). Accordingly, client 108 is adapted to, when the stream
`ing of the first media file fails, to Send a request to playlist
`generator 115 for a Second media playlist, receive the Second
`playlist from playlist generator 115, use the Second playlist
`to determine a second location (here, represented by pro
`vider server 2) and play the second media file from the
`Second location. Preferably, provider Server 2 has associated
`therewith a URL address that client 108 uses to access the
`Second media file and play the Second media file. Thus, in
`this particular embodiment of the invention, fallback to the
`Second file is accomplished by retrieving the Second playlist.
`0033. In another aspect of the invention, playlist genera
`tor 115 receives an indication of the failure of the streaming
`of the first file prior to providing the Second playlist.
`Illustratively, client 108 provides, in the request for the
`Second playlist, an indication of the failure and the associ
`ated provider. Preferably, the first playlist references the first
`file location and the Second file location, and the Second
`playlist references the second file location but not the first
`file location. Therefore in Such embodiments, client 108
`cannot use the Second list to determine the first file location.
`0034.
`In another aspect of the invention, each play list
`generated by the playlist generator 115 references at least
`one media group. In accordance with the invention, each
`media group comprises a “mediaball.” In particular, each
`media group represents a media Selection associated with the
`media group. A media Selection comprises “content.” Fur
`ther, each media group references at least one media clip,
`which represents a “media file', in a particular format, e.g.,
`a single Real Media or Windows Media file (note, other
`formats may also be used, e.g., MPEG, Quicktime, DIVX,
`etc.). AS Such, each Such media clip represents the group
`asSociated media Selection in a particular format. Further,
`
`each Such media clip references at least one media file that
`is in the clip-associated format and that presents the group
`asSociated media Selection when played. Further, each Such
`media clip references, for each media file referenced by the
`media clip, a media file location from which the media file
`can be accessed. (AS Such, a clip file is simply a specific
`media file from a specific provider.) AS discussed above,
`each media file location can be on one of the plurality media
`delivery servers (provider servers). Thus, a media ball is a
`collection of clips which represent the same content, possi
`bly in multiple formats, bit rates, display sizes, etc. The
`above-described Structure for a mediagroup and mediaballs
`is shown in FIG. 4.
`0035. Accordingly, each provider discussed above is ref
`erenced by a media clip referenced by a media group that
`represents the media Selection that is presented when the
`asSociated files are played.
`0036 Client 108 accommodates one, or more, of the
`formats Specified in one or more clips of each media group
`(e.g., Windows Media, or Real Media, etc.). In this manner,
`as noted above, the invention provides a media player that
`can accommodate a plurality of different media formats.
`0037. In yet another aspect of the invention, to assist the
`playlist generator 115 in the generation of the playlist,
`management Server 110 comprises Selection criteria and
`information, which describes each media Selection associ
`ated with each group, each format associated with each clip,
`and each media file location.
`0.038. The information comprises data associated with the
`media groups, media clips, and media file locations. Each
`media group has associated there with a group metadata Set
`describing the media Selection associated with the group.
`Similarly, each media clip has associated therewith a clip
`metadata Set describing the format associated with the clip.
`Further, each media file location has associated there with a
`media file location address. Accordingly, the information in
`this aspect comprises each group metadata Set, each clip
`metadata Set, and each media file location address.
`0039 Each group metadata set comprises at least one of
`a value identifying a title of the media Selection, a value
`identifying a publisher of the media Selection, and a value
`identifying content of the media Selection. Similarly, each
`clip metadata Set comprises at least one of a value identi
`fying a media file format, a value identifying a media file
`color depth, a value identifying a media file display size, a
`value identifying a media file bit rate, and a value identifying
`a media file resolution. In addition, each media file location
`address comprises a URL address.
`0040. The selection criteria comprises criteria established
`by, e.g., content providers, the user, etc. In addition, as
`described below, the Selection criteria comprises player
`performance data. Playlist generator 115, in response to each
`playlist request, evaluates the information against the crite
`ria to generate a respective playlist.
`0041. In particular, the selection criteria, comprises at
`least one of a ruleset, player preference data and user
`demographic data. Each ruleset comprises at least one rule.
`A rule is a Set of filter expressions, which may, or may not,
`cause a specific mediaball to be included in a playlist. AS an
`example, a rule can be that if a particular user indicates in
`provided demographic data that he or she is younger than 25
`
`-10-
`
`

`

`US 2003/0061305 A1
`
`Mar. 27, 2003
`
`years old, the media play list Shall include a media group that
`references a media Selection that is an advertisement pre
`pared for presentation to perSons under the age of 25. AS
`another example, a rule can be if the time is before 1:00 EST
`on a given day, the media play list shall include a media
`group that references a media Selection that is a promotion
`for an upcoming live broadcast; but if the time is between
`1:00 EST and 3:00 EST on that day, the media play list shall
`include a media group that references a media Selection that
`is the live feed for the live broadcast; and if the time is after
`3:00 EST on that day, the media play list shall include a
`media group that references a media Selection that is an
`archived copy of the live broadcast. Thus, a ruleset is a
`number of rules collected together and evaluated en masse
`to produce a playlist. This is the basic data type provided to
`the player for playback of any content. The rules and rule
`Sets comprises one, or more, of the rules and/or rule Sets
`described under the heading “Rule/Ruleset Specification,”
`described below. It should be understood that the rules
`and/or rules Set can be combined and/or nested as desired.
`0042. In still another aspect of the invention, the ruleset
`is provided by a customer of System 10, e.g., another user,
`or distributor. Accordingly, in this aspect, the System further
`comprises, as part of the distributed network, a customer
`client. The customer client can comprise, for example, a
`personal computer with all of the components normally
`found in a personal computer, running an operating System
`upon which Software applications can run, including net
`working software and a Web browser for visiting Web sites,
`Viewing Web pages, running Web applications, and trans
`ferring files via the network.
`0.043
`Further in this aspect, system 10 comprises a media
`asset manager server (asset server) 140 adapted to Solicit and
`receive the rule Set from the customer client and Store the
`rule Set in a storage medium in a manner associated with the
`customer. Asset server 140 is a collection of systems that the
`customer uses to do asset management. Using a web-based
`front end, asset Server 140 manages the upload of content
`and distribution across the multiple provider networks. (It
`should be noted that Such a management function could be
`integrated with other forms of management-type Systems
`already available from third party vendors.) Asset manager
`140 comprises the elements shown in FIG. 3 and includes
`web interface 144, Java interface 143, native client app 142,
`plug-in for media asset management System 141 (e.g., for
`use in a browser), ruleset maintenance element 145 and
`Clipfile and Metadata element 146. It should be observed
`that although shown as Separate elements, asset Server 140
`can be a part of server 110. The solicitation and receipt of the
`rule Set from the customer client is accomplished as
`described below. The Storage of the rule Set in a manner
`asSociated with the customer can be accomplished by reg
`istering each customer and providing a customer record and
`customer identifier for each customer, that can be used to
`access the customer's rule Set or rule Sets.
`0044 Preferably in this aspect, asset server 140 is
`adapted to associate a rule Set identifier with the rule Set.
`Also in this regard, playlist generator 115 Selects the rule Set
`during the evaluation (of the information against the Selec
`tion criteria) using the rule set identifier. Further in this
`regard, the rule Set identifier is Stored on a hypertext markup
`language (HTML) page authored by the customer.
`
`0045. In still another aspect of the invention, the player
`preference data and the user demographic data are provided
`by the user client. Accordingly, in this aspect, management
`Server 110 comprises a registrar adapted to Solicit and
`receive, from client 108, and store in a storage medium (e.g.,
`database 190) in a manner associated with the user, at least
`one of the player preference data and the user demographic
`data. The registrar comprises form generator 116 and form
`processor 117 (also described further below). The solicita
`tion and receipt of the data from client 108 can be accom
`plished as described below. The Storage of the data in a
`manner associated with the user can be accomplished, for
`example, by the registrar being adapted to associate a user
`identifier with the stored data. To further ensure that the data
`is Stored So as to be associated with the user, the Storage
`medium can comprise a cookie on a hard drive of client-side
`105.
`0046. Further in this aspect, the preference data com
`prises at least one of a connection Speed, a media player
`type, and a media file format. The demographic data com
`prises at least one of contact information, biological infor
`mation, and interest information. For example, the demo
`graphic data comprises the demographic data discussed
`under the heading “Demographics Reference.” The prefer
`ence data and the demographic data can be used by the
`playlist generator 115 to generate the playlist.
`0047 As noted above, the invention employs client-side
`performance monitoring to automatically detect and correct
`connection failures or performance problems. Also as noted
`above, the invention also provides extensive and accurate
`real-time and historical reporting by employing client-side
`collection of performance and user activity data. The col
`lection of the data enables system 10 to provide unified
`reporting acroSS multiple Streaming media providers and for
`multiple media formats.
`0048. Accordingly, in still another aspect of the inven
`tion, the management Server comprises a performance data
`reporting server (reporting server) 130. Client 108 is adapted
`to report to reporting Server 130 performance data describ
`ing at least one performance aspect of client 108, and
`reporting Server 130 is adapted to receive the performance
`data. Reporting server 130 is a server-side system, which
`collects information about executing client 108 sessions and
`provides reporting capabilities. Reporting Server 130 com
`priseS real-time reporting applet 132, historical reporting
`applet 131, collector 133, and a reporting engine, compris
`ing real-time reporting engine 134 and historical reporting
`engine 135. Preferably in this aspect, the performance data
`comprises at least one of Session Start time, Session end time,
`failure information, latency information, clip viewed infor
`mation, and transport activity.
`0049. The reporting engine of reporting server 130 is
`adapted to receive the performance data, process the per
`formance data for real-time, or historical, reporting, and
`provide the processed performance data to a respective
`report viewer (e.g., applet 132). Real-time report viewer 132
`is adapted to request and receive the processed performance
`data from the reporting application. Therefore, by using the
`real-time report viewer 132, performance data during the
`media delivery can be reviewed by, e.g., customers, dis
`tributors, etc.
`0050. When providing a historical reporting feature, the
`reporting engine of reporting Server 130 is adapted to Store
`
`-11-
`
`

`

`US 2003/0061305 A1
`
`Mar. 27, 2003
`
`the performance data in a storage medium So that the
`performance data can be retrieved (e.g., database 190),
`analyzed for historical trends and provide the processed
`performance data to a historical report viewer 131 for
`Viewing by, e.g., a customer. Therefore, by using the his
`torical report viewer, the customer can review the historical
`reports for trends and other information.
`0051. In another aspect of the invention, prior to the
`Streaming of the first file, it is assumed that provider Server
`1 has been determined to be more optimum to the user than
`provider Server 2. This determination can be made, for
`example, using the above-mentioned Selection criteria. AS
`noted above, the Selection criteria comprises, e.g., a rule Set,
`player preference data, user demographic data, and player
`performance data. The Selection criteria can be used to rank
`providers, for example, according to how well they are
`anticipated to deliver requested media files to the client 108
`through the Streaming process. The various ways in which
`this ranking can be accomplished is described further below.
`0.052
`In still another aspect of the invention, system 10
`further comprises asset server 140. A customer client (not
`shown) is adapted to transfer to asset server 140, and asset
`server 140 is adapted to receive from the customer client, the
`following items: (1) at least one media group; (2) each media
`clip referenced by each media group; (3) each media file
`referenced by each media clip; (4) a group metadata set for
`each media group, describing the media Selection associated
`with the group; and (5) a clip meta