Method and system for managing digital content, including streaming media

Background of invention

1. Field of the invention

The present invention relates generally to a method and system for providing digital content via the Internet and, more particularly, to a method and system for allowing clients to up-load, manage, and deliver streaming media content via the Internet.

2. Description of related art

With the advent of the Internet and the World Wide Web, an industry has developed around the delivery of digital content, such as streaming media content. By way of example, streaming media may be used for any of a number of purposes, including entertainment, distance learning and corporate purposes. Entertainment companies stream movies and sporting events, distance learning companies stream educational content, and corporations stream training materials.

Although some streaming media content providers may have relatively few items of content to provide, some content providers have hundreds, even thousands of content files. Storing and streaming this number of content files can be costly. Furthermore, streaming content requires a level of technical expertise often not found in companies focusing on creating content. Consequently, content providers have turned to content management service providers to store and stream content on behalf of the content providers.

As more content providers turn to service providers for their streaming technology needs, service providers must manage more client accounts and greater numbers of content files. Furthermore, to maintain existing content provider clients and attract new clients, service providers must provide a content management system that not only is capable of organizing large numbers of content files, but also is easy for the content providers to use. Accordingly, there exists a need for a content management system that allows clients to easily up-load, manage, and deliver streaming media content via the Internet.

3. Summary of the Invention

The present invention solves the foregoing and other needs. In certain embodiments, a method and system is provided for allowing client content providers to upload, manage and deliver streaming media and other digital content. The system according to one embodiment receives digital content from the client, assigns a stream identifier (ID) to the content and stores the content. The client is given a playlist uniform resource locator (URL) for publishing on its web site, the URL including the stream ID. Activation of the URL by an end user causes the stream to be served to the end user, without the client receiving or providing an indication of the specifics of where the content was stored.

Another embodiment of the present invention permits clients to actively manage their content, including defining logical folders and subfolders containing item(s) of content; defining logical stream groups, containing items of content.

A system according to one embodiment of the present invention couples one or more media servers to a storage server. While the storage server has stored a copy of the content, the media servers coupled thereto do not. In operation, the media servers perform a read of the contents stored at the storage server when requested by an end user.

Another embodiment includes a system and method for facilitating access by users to digital content of one or more clients, the clients having client identifying information. Such a system includes one or more remote sites, each comprising one or more first servers configured to receive digital content from clients, the digital content to be available to users via the remote sites. The system also includes a central site geographically remote from the remote sites, the central site comprising one or more ingest queue servers to direct transfer of digital content to one or more of the first servers based on the client identifying information.

Brief description of the drawings

The following drawing figures, which form a part of this application, are illustrative of embodiments of the present invention and are not meant to limit the scope of the invention in any manner, which scope shall be based on the claims appended hereto.

FIG. 1 is a schematic illustrating the system architecture of one embodiment of the present invention;

FIG. 2 is a schematic illustrating the database of one embodiment of the present invention;

FIGS. 3a-3i, 3j-1 and 3j-2 are web pages of the Content Management client-side web site according to one embodiment of the present invention;

FIGS. 4a-b are flowcharts illustrating processes of up-loading content files into the content management system according to one embodiment of the present invention;

FIG. 5 is a flowchart illustrating the process of creating a playlist according to one embodiment of the present invention;

FIG. 6 is a schematic illustrating the system architecture of an alternate embodiment of the present invention;

FIG. 7 is a schematic illustrating a workflow of a content management system according to the alternate embodiment of FIG. 6;

FIG. 8, which comprises FIGS. 8a-8g, represents a schematic illustrating the database of the embodiment of FIG. 6;

FIG. 9 is a schematic illustrating the system architecture of an alternate embodiment of the present invention; and

FIG. 10 is a schematic illustrating a workflow of the system according to the alternate embodiment of FIG. 9.

Detailed description of certain embodiments

Certain embodiments of the present invention will now be discussed with reference to the aforementioned figures, wherein like reference numerals refer to like components. Turning first to the schematic of FIG. 1, a system 100 according to one embodiment of the present invention is shown. In general, the system 100 allow clients 102 to up-load streaming media content to the system 100, manage such content, and make the content available to end-users 104 via a web site on the Internet.

As will become apparent from the following discussion, each of the clients 102 and end-users 104 has a processor, such as a personal computer (PC), web enabled cellular telephone or personal digital assistant (PDA) and the like, coupled to the Internet by any one of a number of known manners. Furthermore, each client 102 preferably includes an Internet browser, such as that offered by Microsoft Corporation under the tradename INTERNET EXPLORER or that offered by Netscape Corp. under the tradename NETSCAPE NAVIGATOR, as well as file transfer protocol (FTP) client software for interacting with various components of the system 100. Additionally, each end-user processor preferably includes an Internet browser, such as INTERNET EXPLORER or NETSCAPE NAVIGATOR, and a media player, such as that offered by Microsoft Corporation under the tradename WINDOWS MEDIA PLAYER or that offered by Real Networks Corp. under the tradename REALPLAYER. It is to be understood that although the present embodiment is described in terms of Windows Media content and Real Media content, it is within the scope of the present invention to utilize any media format heretofore or hereafter known. Furthermore, it is to be understood that although the present embodiment is described in the context of streaming media, the present invention is applicable to digital content other than streaming media.

As discussed in greater detail below, the client 102 up-loads streaming media content to the repository or storage server (and associated storage) 106 either directly, via an HTTP up-load, or via an FTP ingest server (and associated storage) 108. Once the client 102 has up-loaded its streaming media content, the client may manage its content via web pages on a content management web site provided by a client-side web server 110. As discussed in greater detail with reference to FIG. 3a-j, the web site serves as an interface through which the client 102 may log into its account and select any of the following exemplary functions: up-load new content; search the clients existing up-loaded content; create and edit playlists; browse the client's contents stored on the FTP server 108; and perform a batch up-load of content from the FTP server 108 to the repository server 106. Additionally, the web site serves as an interface for the client 102 to perform various administrative functions, such as setting and changing any of the client-defined account and file information described below. In alternate embodiments, clients 102 may manage their accounts programmatically, via scripts running on the web server 110 or other system service described below.

In various different embodiments, client 102 may provide various types of content through an application, such as a web application that creates and uploads content into the system, which content eventually gets provided to individual users of a web site, an application for creating a webcast and the like. This content can be any type, including, for example, music videos, television programs, distance learning, video conferences and other web broadcasts, which can be uploaded via FTP, HTTP or other ingest mechanisms as described herein. Alternatively, client 102 can refer to certain other web properties or pages, such as those directed to certain vertical markets like News, Sports, Financial, Personals, Weather and other information. In yet another embodiment, the content can be uploaded by internal users of the system who upload files on behalf of clients.

The system further includes a file management server 112, administrative staff terminals 114, and a script processor 116. In general, the file management server 112 controls the activities of the various other components to which it is coupled and the movement of content within the system. The administrative terminals 114, in turn, are coupled to the file management server 112 and database server 118 to allow the administrative staff of the content management service provider maintaining the content management system 100 to control and monitor the system 100. The script processor 116 works in conjunction with the file management server 112 to control operation of the system 100 by running various software scripts and/or components performing most of the functionality described herein. As described in greater detail below, the script processor 116 includes various software modules, including a task scheduler and program scripts and objects for batch up-loads of content files and for recovery of deleted content files. It is to be understood that such task scheduling software may be obtained by any of a number of third-party vendors. Similarly, based upon the description of the program scripts and objects herein, the program scripts and objects may be written in any programming language heretofore or hereafter known, such as PERL, Visual Basic, JavaScript, C++, and the like.

The content management system 100 also includes a Content Management (CM) Database 118. As described in greater detail below with reference to FIG. 2, the CM Database 118 includes numerous relational databases or tables in a database. In general, the CM Database 118 preferably includes account information, which identifies each clients account, stream information, which identifies and describes each item of streaming content within a clients account, playlist information, which identifies and describes each client's playlist, batch information, which defines the status of each client's batch up-load requests, and storage location information, which tracks the storage of content on the repository 106 and streaming media 120 servers.

Under direction of the file management server 112, the up-loaded content is eventually transferred from the repository server 106 to one or more streaming media server (and associate storage) 120, where it is available for streaming via the Internet. As described in greater detail below, the current embodiment utilizes a playlist server 122 for dynamically generating a playlist metafile (such as ASX, RAM, SMIL, and RPM files, to name a few) to be provided to the end-user's windows media player. In addition to the archived content located on the streaming media server storage 120, the present environment provides for streaming of live content acquired via encoders 124 coupled to the streaming media servers 120.

As illustrated in FIG. 1, while the clients 102 and end-users 104 are coupled to each other and to the content management system 100 via the Internet, the service provider's components are coupled to each other via a local area network (LAN). More specifically, the repository 106, FTP server 108, client web server 110, file management 112, administrative terminals 114, script processor 116, CM Database 118, streaming media server 120, and playlist server 122 are all in communication via a secure LAN. In one embodiment, the system provides additional security by using Secure Sockets Layer (SSL) connections, which is well known in the art. In alternate embodiments, components of the system are coupled differently, for example, each coupled directly to the Internet, coupled via a wide area network (WAN) and the like.

In general, the division of functionality among the web server 110, file management server 112, playlist server 122 and script processor 116 described herein is exemplary, as the functions may be segregated and grouped differently. For example, it is to be understood that although the present embodiment utilizes client web servers 110 that are separate from the playlist server 122, in alternate embodiments the functionality of the playlist server 122 described herein may be implemented in software residing on the web server 110, thereby obviating the need for a separate playlist server.

Content Management Database 118

The Content Management (CM) Database 118 will now be described in greater detail with reference to FIG. 2, and continuing reference to FIG. 1. The CM Database 118 includes several logically discrete tables of information, each of which is described below. As will be appreciated by one skilled in the art, the following logical arrangement of information in tables is exemplary, and other arrangements are within the scope of the present invention; for example; those with fewer or more tables and/or fewer or more fields. It is also to be understood that although the CM Database 118 is described as a central database, it is within the scope of the present invention to distribute the contents of the CM Database 118 throughout the system.

The CM Database 118 includes a CM Accounts Table 210. In general, the CM Accounts Table 210 includes records for each client account, as identified by a CM account ID. Each such record includes account identifying information, such as account name, account directory, username, password, contact information (such as contact name, e-mail address, and telephone number), default title and author (which are preferences used to identify items of content in the event no other title or author information is provided by the client 102), parent account ID (in the event the current account is related as a child to another account), an indication of whether or not the client has an FTP account, and maximum allowable amount size of content (e.g., in Kilo-bytes). It is within the scope of the present invention to implement security features to maintain the integrity of the content, such as those features and methods described in applicant's co-pending International Application No. PCT/US01/46726, filed Nov. 5, 2001, for SYSTEM AND METHOD FOR CONTROLLING ACCESS TO DIGITAL CONTENT, INCLUDING STREAMING MEDIA, and International Serial No. PCT/US01/18324, filed Jun. 6, 2001, for SYSTEM AND METHOD FOR CONTROLLING ACCESS TO DIGITAL CONTENT, INCLUDING STREAMING MEDIA, which are hereby incorporated by reference. As such, the table includes security related information, including default preferences indicating whether or not the content is secure (allows security), and if so, a cryptographic key used for accessing such content (default sec key) and a time period for which the key will be valid (default sec. interval).

The CM Accounts Table 210 also includes a field for a "site id," which uniquely identifies a site consisting of a group of one or more FTP servers 108 and those repository servers 106 and streaming media servers 120 to which the content on the FTP servers 108 can be up-loaded. Two representative sites are illustrated in FIG. 1, although the system 100 could have any number of sites. Although not required in the present invention, each client account is associated with a site located in the client's geography or the geography where the endorsers 104 likely to access the client's content are located so to speed delivery of the streaming media content. Furthermore, it is to be understood that logically grouping the FTP server 108, repository servers 106 and streaming media servers 120 into sites is not required. As noted below, much of the account identifying information of the present embodiment is provided by the client 102 during the registration process.

The CM Database 118 further includes a series of tables containing content--identifying information. More specifically, the CM Assets Table 212 includes records, each of which identifies an item of streaming content by a stream ID. Furthermore, each record includes the CM account ID, creation date of the item of content, description of the content, an identification of whether the content is audio and or video, the platform or format to which the content relates, the date on which the content was last modified, any code necessary for viewing of the content, the length and size of the content, the expiration date (if any) of the content, the individual that up-loaded the content and the date on which the content was processed into the system 100. It is to be understood that each record in the CM assets Table 212 correlates an item of content, as identified by the stream ID, to a particular client account, by reference to the CM account ID.

It is to be understood that the present invention is applicable to any platform and format now known or hereinafter developed including for example, MP4, Flash COM, Real Media, MP3, MP3PRO, QuickTime, Windows Media, a GIF Image, a JPEG Image, or XML.

The Streams2 Table 214 also includes records identifying each item of content, as identified by the stream ID. Fields contained in the Streams2 Table 214 include the stream type, such as windows media player or real media player, title of the content, author of the content, status of the content, copyright notice for the content, URL prefix, bite rate of the content, file name of the content (as provided by the client 102), stream format, such as windows media player or real media player, ad tag (which specified where an advertisement is to be inserted), start time (if the Stream is a portion of the file), duration, and expiration date.

As illustrated in FIG. 2, the CM Assets Table 212 has three additional tables related thereto: the CM Stream Keywords Table 216, CM Assets Locations Table 218 and CM Archive Volume Table 220. The CM Stream Keywords Table 216 includes keywords, as provided by the client 102, for each item of content as identified by the stream ID.

The CM Assets Locations Table 218, which is also related to the CM Assets Table 212, includes records identified by location ID. The location ID is a unique identifier for each portion of storage pertaining an item of content. As such, location IDs may refer to either a repository server 106 or a streaming media server 120. A given content file may be stored at multiple location ids, for example one on a media server 120 and one on a repository server 106. More specifically, each record in the CM Asset Locations Table 218 includes a CM volume ID, for identifying the portion of the server on which the associated content resides; stream ID, for identifying the item of content stored at the location ID; and status of the item of content. The status of the file corresponding to each location is determined based on the following table.

TABLE-US-00001 Status Meaning Applicable to file located on: Available File is present on a media Streaming server server and is available for streaming Back up File has been copied to a Repository server streaming media server Copying File is being copied to a Repository server; media server repository server or media server Deleting File is being deleted Repository server; media server Failed File up-load or copy has Repository server; media server failed Moving File is being moved from Repository server; media server the current server to another server of the same type New File has recently been up- Repository server loaded and not copied

The CM Archive Volume Table 220 is also related to the CM Asset Table 212 and, more particularly, to the CM Asset Locations Table 218. CM Archive Volume Table 220 includes records for each CM volume ID. Each record includes: volume type, which indicates whether the volume ID pertains to a repository server 106, streaming media server 120, FTP server 108, script processing server 116 or web server 110; archive server name, indicating the LAN name of the particular repository server 106 or streaming media server 120, as the case may be, containing the volume ID; the server's DNS address; the platform for the content, such as Window's Media or Real Media; the status of the content associated with the volume id; the maximum storage capacity for the server continuing the volume id; and the site id of the server containing the volume id.

In one embodiment, the following values represent the following volume types:

TABLE-US-00002 Value Volume Type F FTP Server P Processing Server S Storage Server W Web Server

Also associated with each client account identified in the CM Accounts Table 210 is client playlist information. Such playlist information is contained within the CM Playlists Table 222, Content Group (CG) Table 224 and CG Streams Table 226. In general, the CM Playlist Table 222 includes records identifying each client playlist, as identified by a content group ID. Each record further includes the CM account ID and the sort order, which indicates the ordering of the items of streaming content associated with the particular playlist.

Content Group Table 224 also includes records for each playlist, and identified by the playlist or content group (CG) ID. In general, each record contains the playlist details, including the CG ad tag, the type of playlist, the CG description, the CG format, the CG label, the meta-url for the playlist, CG notes, and an indication as to whether or not the content group is shared.

The playlist entries are identified in a CG Stream Table 226. More specifically, the CG Stream Table 226 includes records identifying each item of content as part of a content group and further includes an indication of the order of the particular item of content within the content group. As such, each record in the table includes the content group ID, stream ID, and sort order.

The CM Database 118 also includes a table that indicates its status of client-requested batch up-loads. More specifically, the CM Batch Jobs Table 228 includes records identifying the status of each requested batch job, as identified by a CM batch job ID. Each record in the CM Batch Job Table 228 includes the CM account ID, identifying the account to which the batch job relates, the file name of the batch file (filename), the time which the client 102 submitted the batch request (submit time), the time at which the process was started (process start time), the time at which the batch process ended (process end time), and an indication as to whether or not the batch file was removed from the clients account (file removed). Because each record in the CM Batch Jobs Table 228 includes the CM account ID, each such record is related to a record in the CM Accounts Table 210.

The CM Database also includes a Stream-Servers Table 230. The records in the Stream-Servers Table 230 correlate each file, as identified by its stream ID, with the hostname (or domain name server (DNS) address) of the streaming server 120 on which it resides. While each stream ID will only have one record, a particular file will have as many records as it has copies residing on different streaming servers 120.

The Servers2 Table 232 includes a record for each streaming server 120, as identified by its server address, setting forth various metrics for the server 120, such as the weight or relative number of streams being served to end users 104.

The CM Sites Table 234 contains a record for each site, as identified by its site id. More specifically, each record identifies the name of the site, the FTP server uniform resource locator (URL) associated with the site and the processor URL associated with the site. In the present embodiment, each site only includes one FTP server 108.

As illustrated in FIG. 2, the CM Database also includes tables relating to the deletion and recovery of files, identifying each client's service level and categorizing the clients' accounts.

The Account Servicelevels Table 236 stores a description of each client's service level. As illustrated, this table 236 is keyed to the Accounts table 210 by virtue of the account service level ID (acct srvlevel id) field. Each service level generally corresponds to a different set of options, functions and/or capabilities offered to the client, for example, the amount of storage allowed, number of uploads, the number of sites provided, and the like.

The Categories Table 238 stores records identifying the category to which a particular account relates. More specifically, each record corresponds to a particular category, as identified by category ID. In general, a category is a grouping of accounts, for example, of all accounts related to a particular parent account. Thus, each record identifies the parent ID, name, and description. As illustrated, records in the Categories Table 238 are keyed to accounts in the Accounts table 210 by the category ID field.

The CM database 118 also tracks deleted accounts and deleted content. To this end, the Deleted Accounts Table 240 keeps a record for each account, identified by account ID, that is removed from the system 100. By keeping such records, the system administrator is able to provide accurate record keeping and report generation.

The Deferred Delete Table 242, Deleted Assets Table 244 and the Recovery Jobs Table 246 are used in the deletion of content. More specifically, a Stream may be deleted either upon request of the client 102 or based on the content expiring. As noted above, the Streams2 Table 214 includes an expiration date field for each Stream ID. A script running on the system periodically scans the Streams2 Table 214 for records having an expiration date equal to or greater than (i.e., after) the then current time. For each record containing such an expiration date, the system proceeds to delete the content. The process of deletion of the present embodiment includes changing the status field in the Asset Locations Table 218 to expired and, in the Streams-Servers Table 230 changing the hostname for the stream being deleted to another system server that hosts a default message, indicating to the end user 104 that the requested content is not available. The system also replaces the stream's actual filename, as stored in the Streams2 Table 214, with the filename of such default message.

In an alternate embodiment, a script or other item of software running on the system generates an email that informs the client of the impending expiration date. For example, an email message warning can be sent to the client a certain period (e.g., 7 or 30 days) before the expiration date, so as to avoid an unanticipated expiration of the client's content. In such an embodiment, the system repeatedly searches the database (e.g., CM Assets Table 212) to identify streams having an expiration date within the set period, places a corresponding entry in a queue or otherwise flags the content and, for each such stream, generates the email message.

Upon deletion of a stream, a record is also created in the Deleted Assets Table 244, specifying various stream information, as well as the expiration date and deletion date of the content.

In the event the stream to be deleted is currently being provided to an end-user 104, the system will be unable to delete the content. In such an instance, the system creates a record in the Deferred Delete Table 242, specifying the server name, file name and share information for the content to be deleted. As illustrated, for each unique combination of server name, share information and file name, the Deferred Delete Table 242 also stores the site ID, stream ID, the date on which the delete request was submitted to the system, the date of the last attempted deletion, and the number of failed deletion attempts. A script running on the system periodically searches the Deferred Delete Table 242 for entry and, upon the finding a populated record, proceeds to attempt to delete the content specified by the entry. Upon successful deletion, an entry is created in a Deleted Assets Table 244 and a status is changed in the Asset Locations Table 218.

Registration Process

Having described the components of the present embodiment, the operation thereof will now be described. As an initial matter, each client 102 must register with the service provider. In general, such registration includes the client 102 providing the service provider with account identifying information, a subset of which includes client identifying information. More specifically, the client provides the account identifying and client identifying information contained within the CM Accounts Table 210. The client may also select the designed service level. In one embodiment of the present invention, the client 102 provides such information via a secure web page generated by the client web server 110. The client web server 110 receives the information and by executing a common gateway interface (CGI) script, writes the information via the LAN to the CM Database 118. In an alternate embodiment, the client 102 manually provides the information to the service provider, who, in turn, manually enters the information into the CM Database 118 via the administration terminals 114. In either embodiment, once the service provider receives the account identifying and client identifying information, a CM account ID is assigned and the corresponding record in the CM Accounts Table 210 is populated.

Client-Side Content Management Web Site

As noted above, the client web server 110 provides a content management web site that serves as an interface between the client 104 and the content management system. While the present embodiment utilizes such interactive web site for allowing the client 102 to interface with the system and to manage the client's content, it is to be understood that other interface devices may be used, including voice recognition devices, text-based systems, or by passing variables on a query string and running a script, or any other interface means. Furthermore, although the present embodiment passes data between the web server 110 and the script processor 116 in XML format, it is to be understood that other formats may be utilized. The content management web site of the present embodiment will now be discussed with reference to FIGS. 3a-j.

Once a client 102 logs into the system by submitting its username and password, the client is presented with the option to perform content management functions or administrative functions. As shown in FIG. 3a, when the client 102 selects administrative functions from a high level menu 302, the web page presents the client 102 with the ability to set account preferences, including default title, default author, default security key, and default security interval. As with the other web pages discussed herein, entry of information via the client 102 is received by the client web server 110 and placed in the appropriate fields in the CM database 118. With the account preferences web page of FIG. 3a, the default preferences are stored in the CM Accounts Table 210. In alternate embodiments, the web page also displays account settings such as maximum allowable storage (max content Kb), actual storage used (e.g., sum of Kb size fields in Assets Table 212), and any other information stored in the database 118.

As shown in FIG. 3b, when the client 102 selects the manage content option in the high level menu, the web site presents the client with six options: "Upload New Content", "Browse FTP Content", "Batch Uploads", "Playlists", "Search" and "Recycle". When the "Upload New Content" option is selected, the system presents the client 102 with the web page shown in FIG. 3b. As discussed in greater detail below, the client 102 is able to identify a content file residing on its local machine, and upload the file to a repository server 106. In general, the client 102 specifies the file name and file details in an upload content form 306. These file details are then stored in the CM Assets Table 212 and the Streams2 Table 214. Notably, the account preferences set by the client 102 on the web page of FIG. 3a are provided as default entries in the upload content form 306.

When the client 102 selects the "browse FTP content" option, the system presents the client with the web page shown in FIG. 3c. As the name indicates, this option provides the client 102 with a listing of all content files previously uploaded by the client 102 to the client's FTP account on the FTP ingest server 108. The system first identifies the FTP ingest server 108 containing the client's FTP account. A call is made to the particular FTP ingest server 108, which in turn executes a script to read all file directories and files within the client's account. The FTP server 108 returns a listing of such file directories and files in XML format to the web server 110. The web server 110, in turn, converts the XML information into HTML, which is displayed to the client 102. As shown in FIG. 3e, the client 102 is presented with the name of its FTP account 308, as well as a listing of the client's file directories 310 and the client's content files 312.

The browse FTP content web page allows the client 102 to either delete a content file or cause a content file to be ingested from the FTP server 108 to a repository server 106. Such operations will be discussed in greater detail below.

The "batch uploads" option is shown in FIG. 3d. As shown therein, the batch upload web page of the current embodiment is divided into two sections: one illustrating the batch files which have been uploaded to the client's FTP account, but not processed; and one identifying the client's batch files for which processing has begun 316. By way of example, batch file "1-100.bul" has been uploaded but not processed, while batch file "BillDefault.txt" was previously uploaded and processed.

It should also be noted that the batch upload web page may display any file detail stored in the CM database 118 corresponding to each batch file. More specifically, for each batch file listed as having been processed, information may be extracted from the submit time, process start time and process end time fields of the CM Batch Jobs Table 228.

The listing of available batch files 314 is generated by the system browsing the clients FTP content and extracting all pure text files. The listing of processed batch files is created by the system by searching the CM Batch Jobs Table 228 for all records identified by the client's CM account ID. The client 102 may select one of the available batch files for either deletion or processing.

The web page displayed when the client 102 selects the "playlists" option is illustrated in FIG. 3e. In general, this web page provides the client 102 with the ability to edit playlists. To this end, the web page presents the client 102 with a list of current playlists 318. The system generates the list of playlists by searching the CM Playlists Table 222 for all entries corresponding to the client's CM account ID, thereby resulting in a list of playlist or content group (CG) IDs, each of which identifies a different playlist for the client 102. For each CG ID, the system retrieves the CG description and format in the Content Group Table 224. The information is transferred in XML format and displayed in the playlist list 318 in HTML format.

The system also provides the user with a search form 320, whereby the client 102 can enter playlist details, such as playlist/CG ID, CG description and CG format, in which the system uses in searching the Content Group Table 224 in order to return a list of matching playlists.

The client 102 may also select a current playlist to manage. As shown in FIG. 3f, when the client 102 chooses to manage a playlist, the system retrieves from the CM database 318 the CG id 322, various playlist details 324 as stored in the Content Group Table 224, and a list of streams or content files making up the identified playlist 326 as retrieved from the Content Group Streams Table 226 based on the CG ID. From the list of streams, the client 102 may select any number for deletion from the playlist, in which case the system removes the stream's id from the corresponding record in the Content Group Streams Table 226.

Notably, the web page also provides the client 102 with the uniform resource locator (URL) for the playlist 328. In general, the playlist URL 328 is incorporated into the clients web page as a link, and when activated by an end user 104, causes the playlist identified by the embedded playlist/CG ID to be played. The process of generating the playlist URL 328 and playing the streams associated with the playlist is described in greater detail with reference to FIG. 5.

The web page displayed when the client 102 selects the "search" option is shown in FIG. 3g. The system provides the client 102 with a search form 330 that enables the client 102 to enter the file details, including title, author, keywords, stream id, creation date, and duration, as search criteria. The web server 110 passes the file details entered by the client 102 to the script processor 116, which uses the values to search the CM Assets Table 212, CM Stream Keywords Table 216 and the Streams2 Table 214. The script processor 116, in return, returns various file details of the clients content files meeting the search criteria. Such results are shown in FIG. 3h. The search form 330 also includes an option to display the results in XML format (as received from the script processor 116) and to search not only the client's current account, but also all child accounts (as indicated by the parent id field in the CM Accounts Table 210).

As an alternative to using the search form 330, the client 102 may simply browse all content in its content management account by clicking the "Browse" button. Once the client 102 clicks the browse button, the web server calls a script on the script processor 116 that retrieves all files associated with the client's username and password (and, thus, account id).

Exemplary search results are illustrated in FIG. 3h. Each content file may be identified by any of the file details stored in the CM Database 118. In the present embodiment, each file is identified by the stream ID, title, stream type, stream description, creation date, file size, and status, all of which are stored in the CM Assets Table 212 and Streams2 Table 214.

The description continues in the full USPTO document.