HK1180782A - Techniques and systems for supporting podcasting - Google Patents

Description

Techniques and systems for supporting podcasting

The present application is a divisional application of an invention patent application having an application date of 8/5 2006, an application number of 200680022102.7, and an invention name of "techniques and systems for supporting podcasting".

Technical Field

The present invention relates to podcasts (podcasts), and more particularly to acquiring and playing podcasts on portable media devices.

Background

The media player stores media assets, such as audio tracks, that can be played or displayed on the media player. One example of a portable media player is the iPod media player available from Apple Computer, inc. Typically, a media player obtains its media assets from a host computer, which serves to enable a user to manage the media assets. In managing media assets, a user can generate playlists for audio tracks. These playlists may be generated on the host. The media assets in the playlist may then be copied to the media player. As one example, a host computer may execute a media management application to generate and manage media assets. One example of a media management application is iTunes manufactured by Applecomputer, Inc。

Podcasts are commonly used to share content from websites. Podcasts are associated with a Really Simple Synchronization (RSS) feed (feed) using a lightweight XML format. Podcasts may be organized into segments more like broadcast or television programs. Interested persons may subscribe to receive podcast episodes that are subsequently disclosed. This is achieved by the interested person using their computer to access a podcast website that supports RSS feeds. Interested persons may then subscribe to the RSS feed so that their computers revisit the podcast website from time to check for any new podcast episodes. Typically, if a new podcast episode exists, it is downloaded to the computer. The interested user may then play the podcast episode on their computer in the same manner as other audio files (e.g., MP3 files). A utility may be used to download audio files to a portable media player (e.g., MP3 player). An example of such a conventional utility is "ipoder," which is an applet that runs on its computer to download audio files to its portable media player.

Unfortunately, podcasts are not typically easy to manage on a host. Podcasts often change dynamically as new episodes are published. The management of such dynamic media assets is complex. In addition, to the extent that the host wishes to support a portable media player, the host needs to manage the transfer of podcast data to the portable media player.

Accordingly, there is a need for techniques for managing and using podcasts on computers.

Disclosure of Invention

The present invention relates to improved podcasts and techniques for facilitating the use thereof. The improved techniques may relate to generating, publishing, hosting, accessing, subscribing, managing, transmitting, and/or playing podcasts.

According to one aspect, a client application may subscribe to a podcast and then automatically monitor the podcast for updates. When there is an update (e.g., a new episode) to the podcast, the update can be downloaded to the client application. However, in the event that the user is unduly interested in the podcast, the download of further updates may be limited. According to another aspect, podcasts may be ordered by using a portable subscription file. The portable subscription file is portable and can be transmitted over a network, thereby providing a convenient way of facilitating subscription to podcasts. According to another aspect, podcast feeds can be enhanced to include segment elements (segment elements) and other metadata. A client application that presents podcasts to users may provide an improved graphical user interface through the use of segment elements and other metadata.

The invention can be implemented in numerous ways, including as a method, system, apparatus, device (including graphical user interface), or computer readable medium. Several embodiments of the invention are discussed below.

As a method for subscribing to a podcast, one embodiment of the invention includes at least the following operations: receiving a portable subscription file to facilitate subscription to the podcast; accessing the portable subscription file to obtain podcast information; and subscribing to the podcast using the podcast information.

As a computer readable medium including at least a computer program for subscribing to podcasts, one embodiment of the invention includes at least: computer program code for receiving a user selection of a portable subscription file to facilitate subscription to the podcast; computer program code for parsing the portable subscription file to obtain podcast information; and computer program code for subscribing to the podcast through the media management application using the podcast information.

As a portable subscription file, one embodiment of the invention includes at least: an application identifier; and a network address for the podcast feed.

As a method for obtaining podcast information on a client application, the podcast information obtained from a podcast hosting server over a network, one embodiment of the invention includes at least the following operations: accessing a podcast feed (podcast) from a podcast host server over a network to obtain episode information for the podcast; determining one or more new segments based on the obtained segment information; determining whether the podcast is still active at the client application; and receiving the one or more new episodes over the network from the podcast host server on the client application as long as it is determined that the podcast is still active at the client application.

As a computer readable medium including at least a computer program for obtaining digital multimedia asset information at a client application, the digital multimedia asset information being obtained from a digital multimedia asset hosting server over a network, one embodiment of the invention includes at least: computer program code for accessing a digital multimedia asset feed (asset feed) from the digital multimedia asset host server over a network to obtain fragment information about the digital multimedia asset; computer program code for determining one or more new sequences based on the acquired sequence information; computer program code for determining whether the client application or a user thereof exhibits sufficient interest in the digital multimedia asset; and computer program code for receiving said one or more new segments at said client application from said digital multimedia asset hosting server over a network, provided that it is determined that said client application or a user thereof exhibits sufficient interest in said digital multimedia asset.

As a podcast feed, embodiments of the present invention include a plurality of segment elements, each of which includes a segment link (segment link) for a multimedia element and a time indication associated with the segment link.

Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

Drawings

The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:

fig. 1 is a block diagram of a media system according to one embodiment of the invention.

Fig. 2A and 2B are flow diagrams of a podcast submission process according to one embodiment of the invention.

Fig. 3A and 3B are flow diagrams of podcast disclosure processes according to one embodiment of the present invention.

Fig. 4 is a flow diagram of an authentication process according to one embodiment of the invention.

FIG. 5A is a screen shot of a network address submission page, according to an example embodiment.

Fig. 5B is a screen shot of a podcast preview page according to an example embodiment.

Fig. 6 is a flow diagram of a media storage podcast interaction process according to one embodiment of the present invention.

Fig. 7 is a flow diagram of an integrated podcast acquisition process according to one embodiment of the present invention.

Fig. 8A is a flow diagram of a podcast update process according to one embodiment of the present invention.

Fig. 8B is a screen shot of a podcast base page according to an example embodiment of the present invention.

Fig. 8C is a screen shot of a podcast page according to an example embodiment of the present invention.

Fig. 8D is a screen shot of a podcast page having a subscription determination dialog according to an example embodiment of the invention.

Fig. 8E is a screen shot of an available podcast page (availability page) according to an example embodiment of the present invention.

Fig. 8F is a screen shot of a podcast available page according to another example embodiment of the present invention.

Fig. 8G is a screen shot of a podcast available page according to another example embodiment of the present invention.

Fig. 9 is a flow diagram of a podcast subscription file creation process according to one embodiment of the present invention.

Fig. 10 is a flow diagram of a podcast subscription file usage process according to one embodiment of the present invention.

Fig. 11 is a podcast subscription system according to one embodiment of the present invention.

Fig. 12 is a flow diagram of a podcast update process according to one embodiment of the present invention.

Fig. 13 is a flow diagram of a podcasting activity process according to one embodiment of the invention.

FIG. 14 is a flow diagram of a process for resetting an activation variable according to one embodiment of the invention.

Detailed Description

The present invention relates to improved podcasts and techniques for facilitating the use thereof. The improved techniques may relate to generating, publishing, hosting, accessing, subscribing, managing, transmitting, and/or playing podcasts.

According to one aspect, a client application may subscribe to a podcast and then automatically monitor for podcast updates. When a podcast update (e.g., a new episode) exists, the update can be downloaded to the client application. However, in the event that the user's interest in the podcast is insufficient, the download of further updates may be limited. According to another aspect, podcasts may be ordered by using a portable subscription file. The portable subscription file is portable and can be transmitted over a network, thereby providing a means for facilitating subscription to podcasts. According to another aspect, a podcast feed can be enhanced to include segment elements and other metadata. A client application displaying podcasts to users may provide an improved graphical user interface through the use of segment elements and other metadata.

Embodiments of the present invention are described below with reference to fig. 1-4. However, those skilled in the art will readily appreciate that the detailed description given herein with respect to these figures is for explanatory purposes as the invention extends beyond these limited embodiments.

Fig. 1 is a block diagram of a media system 100 according to one embodiment of the invention. The media system 100 includes a media store server 102 that is an online media store. The media store server 102 can offload starting transactions and/or transfer purchased digital media assets to other servers, if desired. As shown in fig. 1, the media system 100 includes one or more client devices 104 used by end users. The client device 104 is coupled with a data network 106. In addition, the media store server 102 is also coupled to a data network 106. In one embodiment, the data network 106 may refer to one or more data networks, typically high data bandwidth networks, i.e., wired networks such as the Internet, Ethernet, gigabit Ethernet and fiber optics, and wireless networks such as IEEE 802.11(a), (b) or (g) (WiFi), IEEE 802.16(WiMax), and Ultra Wideband (UWB).

A computer program 108 (client or client application), typically a Media Management Application (MMA) or other media player application, runs on the client device 104. One example of a media management application is iTunes manufactured by Apple Computer, incAn application program. Client device 104 is typically a computing device. As one example, the client device 104 is a special purpose or general purpose personal computer (or even a portable media player). The client device 104 may be associated with a portable media device 109 (portable media player). One example of a portable media player suitable for use with the present invention is an iPod, also manufactured by Apple Computer, incThe computer program 108 may be used by consumers for a variety of purposes, including, but not limited to, from a website provided by the media store server 102The online media store browses, searches, acquires, and/or purchases media assets (including podcasts), creates and shares groups of media assets (e.g., playlists), organizes media assets, displays/plays media assets, transmits media assets between client devices 104, and synchronizes with portable media devices 109.

The media system 100 may also include one or more client devices 110 used by the media programmer. The client device 110 also runs a computer program 112, typically a Media Management Application (MMA) or other media player application. Computer program 112 may be the same as computer program 108, although computer program 112 may provide additional functionality to support media programmers. As an example, a media programmer using the computer program 102 may provide additional functionality for creating and publishing podcasts.

The media system 100 also includes a digital resource manager 114. The digital resource manager 114 is coupled to a media resource database 116. The media asset database 116 stores media asset information including metadata about digital media assets that are available from online media stores. The metadata may belong to an individual media asset (digital media asset) or a group of media assets (group of digital media assets). Media assets can include, but are not limited to, music, video, text, and/or graphics files. One particular category of media assets or media resource groups is podcasts, which typically include audio, graphics, and text (but may also include video). In the case of music, the set of media resources may be a playlist of music. One specific example of a category of digital media resource groups is called iMix^TMWhich is currently in Apple Computer's iTunesMusic stores may be used to browse and/or purchase public playlists. Another specific example of a category of digital media resource groups is known as iEssential^TMWhich is a public playlist created by a media programmer and is currently available for use on Apple Computer's iTunesBrowsing and/or purchasing at a music store. Another specific example of a category of digital media resource groups is called Celebrity playlist, which is a public playlist produced by Celebrity and can be found in Apple Computer's iTunesMusic stores are used for browsing and/or purchasing.

The media store server 102 enables a user of a particular client device 104 to obtain a media asset (e.g., a podcast). The client device 104 may then download the media asset from the media store server 102 or some other server over the data network 106. Other network architectures are possible, as will be appreciated by those familiar with data networks. Further, while the media store server 102 and the digital resource manager 114 are shown as separate distinct devices, those skilled in the art will appreciate that other configurations are possible. As an example, each device may be implemented such that it is distributed over a plurality of server computers. As another example, these different servers and/or managers may be implemented by a single physical server computer.

Fig. 2A and 2B are flow diagrams of a podcast submission process 200 according to one embodiment of the invention. For example, the podcast submission process 200 is performed by a client (e.g., an application). One example of a client is a media management application operating on a client device.

The podcast submission process 200 begins with the generation of a podcast 202. The podcast may be generated during the podcast submission process 200 or may have been previously generated. In one embodiment, the podcast submission process 200 is performed by a single application (e.g., a media management application). In another embodiment, podcast generation may occur in one application and podcast disclosure may occur in another application.

After podcast generation 202, a decision 204 determines whether disclosure is requested. When the decision 204 determines that a publication request has not been made, the podcast submission process 200 awaits such a request. On the other hand, once the decision 204 determines that a publication request has been made, a network address to the podcast (e.g., a podcast feed URL) is received 206. In one embodiment, the user of the client will enter the appropriate network address into a text entry box of a graphical user interface displayed to the user by the client. The network address to the podcast is then sent 208 to the server. The server may be, for example, a media store or some other server. A decision 210 then determines whether a podcast preview page has been received. When the decision 210 determines that a podcast preview page has not been received, the podcast submission process 210 awaits receipt of the podcast preview page. Alternatively, when the decision 210 determines that a podcast preview page has been received, the podcast preview page is displayed. Typically, the podcast preview page includes at least the basic podcast metadata pertaining to the podcast. Once the podcast preview page 212 is displayed, the basic podcast data can be changed (i.e., edited). Additionally, the podcast preview page can include one or more data entry fields that facilitate data entry regarding additional (supplemental) podcast metadata that can be provided by the user.

Next, a decision 214 determines whether the user of the client wishes to edit (change) the base podcast metadata or provide additional podcast metadata relative to the podcast preview page. When the decision 214 determines that the user wishes to edit the podcast metadata, the podcast metadata 216 can be changed. As an example, the user may edit the basic podcast metadata or may enter additional podcast metadata using the data entry fields. One example of additional metadata is to provide category classification for podcasts. The additional podcast metadata may also be referred to as supplemental podcast metadata. Following the block 216, or following the decision 214 that no changes are made, a decision 218 determines whether the user submitted the podcast metadata. Here, submission of the podcast metadata indicates receipt of the podcast metadata by the user, whether the basic podcast metadata or the additional podcast metadata, after any data changes. Such podcast metadata submitted may be referred to as final podcast metadata. Here, when the decision 218 determines that the podcast metadata is to be submitted, the final podcast metadata is submitted 220. Typically, the final podcast metadata is submitted to a server, such as the media store server 220 shown in fig. 1.

An example RSS feed for podcasts is provided immediately below. Note that as discussed in more detail below, the RSS feed provides a category for the channel (i.e., show) and a category for each item (i.e., chapter). For each item, the audio file (e.g., MP3 or AAC format is determined by the URL.

Exemplary RSS Feed

Because the programs (show) and episodes (episode) may be associated with categories, an improved user interface may be provided so that podcasts may be sorted, searched, or browsed based on the categories.

Fig. 3A and 3B are flow diagrams of a podcast disclosure process 300 according to one embodiment of the present invention. The podcast disclosure process 300 is performed by a server and represents processing corresponding to that of the podcast submission process 200 shown in fig. 2A and 2B.

The podcast disclosure process 300 initially receives 302 a network address of a particular podcast to be disclosed. For example, the network address may be provided by a user of the client and then sent to the server (e.g., blocks 206 and 208 of fig. 2A).

After receiving 302 a network address to a particular podcast, the server accesses 304 a podcast feed (e.g., an RSS feed) to obtain podcast feed metadata. In other words, using the network address, the server connects to the podcast feed for a particular podcast to obtain the podcast feed metadata. Basic podcast metadata is then obtained 306 from the podcast feed metadata. According to one embodiment, obtaining basic podcast metadata may involve parsing of the podcast feed metadata. Typically, the podcast feed metadata will include tags or other tags (e.g., XML elements) to distinguish the different metadata fields provided within the podcast feed metadata.

Next, a podcast preview page 308 is created. In one embodiment, the podcast preview page includes basic podcast metadata and requests additional podcast metadata. And then, sending the podcast preview page to the client.

A decision 312 then determines whether a final podcast metadata submission has been received. When the decision 312 determines that a final podcast metadata submission has not been received, the podcast publishing process 300 awaits such submission. On the other hand, once the decision 312 determines that a final podcast metadata submission has been received, the published podcast information is stored 314 at the server. The disclosed podcast information includes at least a network address and final podcast metadata, both of which are associated with the particular podcast. At this point, the particular podcast has been disclosed to the server. Additionally, the published podcast information can be indexed 316 to facilitate the capacity of a search and/or browse server (e.g., the media store server 102 of fig. 1). Finally, the published podcasts are available 318 on the server (e.g., media store). After operation 318, the podcast disclosure process 300 is complete and ends.

In another embodiment, the podcast publication process (e.g., the podcast publication process 300) may be modified to include an authentication process. An authentication process may be utilized to authenticate a person attempting to disclose a podcast. Authentication may be performed in a variety of different ways. In one embodiment, the authentication may authenticate the person attempting to disclose as a person known to the server (e.g., an account holder). In another embodiment, the authentication may authenticate the person on the podcast host, creator, etc.

Media items available on a server (e.g., a media store) may be browsed or searched as other categories of media assets are searched. For additional details regarding SEARCHING or BROWSING media assets, see U.S. patent application No.10/832,984 entitled "GRAPHICAL USERINTERFACE FOR browse, search AND presence media item," filed on 26.4.2004, attorney docket No. APL 1P 277X1, which is incorporated herein by reference. With respect to browsing, however, to facilitate efficient browsing of podcasts, a graphical user interface with a hierarchical list may be displayed for the user. In one embodiment, the first list of selectable items is a list of topics. The user will select the material representing "podcast". A second list of selectable items is displayed upon selection. The selectable items in the second list represent "categories". The categories may be different categories to which the podcast is assigned. Then, in response to the category selection, a third list of selectable items will be displayed. The selectable items in the third list represent "subcategories" and represent available subcategories of the selected category, to the extent that utilization is not exceeded. After various selections are made, those podcasts that match the selected category and the selected subcategory (if used) are displayed in the media asset list area.

The application window may be displayed by the client. The application window may include a first sub-window and a second sub-window. The first sub-window includes a first region, a second region, and a third region. The first area may display a list of available subjects (subject list). When the user selects one of the items (i.e., podcast items) in the material list displayed in the first area, the second area may be formed of a podcast category list associated with the material selected from the material list. The podcast category list is provided by the remote server to an application that displays an application window. After the user selects one of the available categories of the second region, the third region may be comprised of a list of sub-categories associated with the selected category. The sub-categories within the third region (if any) are those belonging to the selected category. When the sub-category list has multiple items, the user will select one of the items. Once the user selects one of the sub-categories (or categories, if there are no sub-categories), a second sub-window may be made up of a list of available podcasts associated with the category and the sub-category (if any). For each podcast, a list of available podcasts may display descriptive information. For example, a list of available podcasts may be displayed in rows and columns (e.g., a table), where each row belongs to a different podcast and the columns belong to the podcast name, artist, description, and price. Also, in the price column, each row may include a "subscribe" button that facilitates a user to subscribe to a particular podcast.

Fig. 4 is a flow diagram of an authentication process 400 according to one embodiment of the invention. For example, the authentication process 400 may be used in place of block 310 shown in FIG. 3A. The authentication process 400 begins by determining 402 an email address for an authenticated user (e.g., an authorized publisher). In one embodiment, the authorized user belongs to an account holder on a server or client. In another embodiment, authorized users may obtain from RSS feeds (i.e., podcast data) associated with podcasts to be disclosed. In either case, an email address associated with the authorized user is determined 402. After the email address is determined 402, a public message with a link to a podcast preview page is created 404. As an example, the publish message may explain to the recipient that they are supposed to be in the process of publishing one of their podcasts and select a closed link to continue the publishing process. In the event that the podcast disclosure is not authorized, the recipient may delete the disclosure process.

A decision 408 then determines whether a request to continue the disclosure process is received from an authorized user. When the decision 408 determines that a request to continue the disclosure process has not been received, the authentication process 400 awaits such a request. In one embodiment, the request is a request to access a podcast preview page. The request may be made by the user by selecting a link in the public message or copying the link to a data entry area provided on the client. When the decision 408 determines that a request to continue the disclosure process is received, a podcast preview page is sent 410 to the client. The process then continues with operation 312 and subsequent operations of the podcast disclosure process 300, as previously described.

Fig. 5A is a screen shot of a network address submission page 500, according to an example embodiment. The network address submission page 500 enables the user to enter a network address, i.e., a feed URL, of an existing podcast to be published at a media store, in this example iTunesA music store. The feed URL is entered into text box 502. In this example, the feed URL entered is:http://www.mygarden.com/gardentalk_rss.xm。

fig. 5B is a screen shot of a podcast preview page 520 according to an example embodiment. In this example, the podcast title being previewed is "Garden Talk". The podcast preview page 520 informs the user how the podcast is displayed at the media store. Here, the podcast metadata being previewed includes: composition, name, author, short description, long description, category, and language. In this example, many of the podcast metadata being previewed may be obtained from the podcast feed itself. However, other metadata not obtained from the podcast feed, such as category and language, may be selected or entered by the user. Regardless, the user may be allowed to edit the podcast metadata being previewed. Additionally, a selection can be made to enable a user (publisher) to indicate whether the podcast contains explicit content. Once the user is ready to receive the podcast metadata being previewed, the user selects the "publish" button.

Once the podcast is disclosed, the podcast is available at a media store (online media store). The media store may or may not host the podcast. If the media store stores all or a substantial portion of the podcast content, the podcast may be considered hosted by the media store. On the other hand, if the media store only holds metadata about the podcast, the media store does not host the podcast. When the media server is not hosting a podcast, the third party server may host the podcast and the media store appropriately accesses the podcast feed to obtain any data needed. The client will access the podcast feed from the host server to obtain the podcast data that needs to be stored locally. Here, the media store retains the content of the podcast in one case and does not retain the content of the podcast in another case.

The media store may be configured such that podcasts may be searched or browsed at the media store. The search or browse function may operate in a similar manner to searching albums at an online music store. However, in the case of podcasts, the search or browse operation is for podcasts that have been published to the media store. Generally, in the case of music, browsing is implemented by hierarchical levels including artists, albums, and songs. By analogy, in the case of podcasts, the hierarchical levels of podcasts (or podcast categories), programs, and episodes are included.

The media store may also organize podcasts into different categories to facilitate their discovery by users interacting with the media store. Examples of categories include: art and entertainment, biographical and memory records, businesses, celebrities, comedies, dramas and poems, novels, history, children and young people, language, mystery drama and news.

In addition, certain podcasts that have been published at the media store may be emphasized on a particular page of the media store. For example, certain podcasts may be emphasized over other podcasts using various criteria (e.g., random selection, rating, most active downloads, sponsorship, etc.). Similarly, "new programs" or "just added" programs that are recently available on the media store may be emphasized. Fig. 8B, discussed below, provides an example of a web page provided by a media store with emphasis on certain podcasts.

Fig. 6 is a flow diagram of a media store podcast interaction process 600 according to one embodiment of the invention. The media store podcast interaction process 600 begins accessing 602 a media store. Then, at the media store, the user can navigate 604 to the podcast of interest. Navigation may take a variety of different forms. One example of navigation is a search process. Another example of navigation is a browsing process. Another example of navigation is manually entering the next network address (e.g., RSS feed URL). Regardless of how the navigation is performed, once the podcast of interest is determined, podcast pages are presented 606 for the podcast of interest. The podcast page can appear on a display (display screen) associated with a client device (e.g., client device 104 shown in fig. 1). The podcast page can include information (e.g., metadata) pertaining to the podcast including description, composition, and episode information for the podcast. The podcast page can also help subscribe to podcasts or get specific episodes. Additionally, the podcast page may allow the user to rate. Podcast pages may also provide links to help users report certain types of events of interest.

After the podcast page is presented 606, a user of the client device (client) can interact with the podcast page to make any of a number of different selections. These selections may initiate operations on the client device. Two particular operations associated with a podcast are (1) subscribing to the podcast and (2) downloading a particular episode of the podcast.

A decision 608 determines whether to make a subscription selection. When the decision 608 determines to make a subscription selection, a subscription process 610 occurs. The subscription process 610 operates with a client device (client) subscribing to a podcast of interest from a host device. Alternatively, when the decision 608 determines that a subscription selection has not been made, a decision 612 determines whether a snippet selection has been made. When the decision 612 determines to make a snippet, snippet data related to the snippet selection is downloaded 614. Here, the clip data is downloaded 614 to the client device. In one embodiment, the clip data includes at least an audio file and database content. The database content may be part of an audio file or another file, or otherwise provided. On the other hand, when the decision 612 determines that no segment selection has been made, a decision 616 determines whether other selections have been made. When the decision 616 determines that other selections are to be made, other processing 616 can occur. Following the blocks 610, 614, and 618 and following the decision 616 when there are no other selections, a decision 620 determines whether the media store podcast interaction process 600 should end. When the decision 620 determines that the media store podcast interaction process 600 should not end, the process returns to and repeats block 604 and subsequent blocks. Alternatively, when the decision 620 determines that the media store podcast interaction process 600 should end, the media store podcast interaction process 600 is complete and ends.

Fig. 7 is a multi-flow diagram of an integrated podcast acquisition process 700, the integrated podcast acquisition process 700 being performed by a client device (e.g., the client device 104 shown in fig. 1) according to one embodiment of the present invention. More specifically, the integrated podcast acquisition process 700 is performed by a media management application (e.g., the media management application 108 running on the client device 104 shown in fig. 1). More generally, a media management application may refer to a client or client application.

The integrated podcast acquisition process 700 initially discovers 702 podcasts of interest. Podcasts of interest may be discovered 702 through interactions with the media store (e.g., the interactions discussed above with respect to fig. 6). After discovering 702 the podcast of interest, a user or client can subscribe 704 to the podcast. Once the podcast is subscribed 704, the client can receive 706 at least data regarding the most recent episode of the podcast. Although the client may receive data about other segments, it may be more efficient and intelligent to receive only the most recent segment initially, assuming a large number of segments can be displayed. As discussed below, the user or client can request to receive other previous segments if desired.

Next, a decision 708 determines whether to synchronize between the client and the media device. The media device is typically previously associated with the client. When the decision 708 determines that synchronization with the media device should be performed, the segment data (for the most recent segment) can be downloaded 710 to the media device. In one embodiment, the received data includes an audio file (e.g., an MP3 file or an MPEG4 file or an AAC file) and metadata pertaining thereto. On the client or client device, in one embodiment, the audio files may be stored in a file system and the metadata may be stored in a database. After block 710, or after the decision 708 to synchronize with the media device is not performed, the client can be configured 712 to update the new segment. Here, a configuration for updating may be established for a single podcast or groups of podcasts or all podcasts. As an example, one configuration parameter is how often updates to the podcast are checked. After block 712, the integrated podcast acquisition process 700 is complete and ends.

Interestingly, in one embodiment, a single client application (e.g., a media management application) running on the client device may perform the operations in FIG. 7. More specifically, the client application may discover podcasts, order podcasts, receive podcast data (including metadata and content), manage podcasts, and transmit (or remove) podcast data to (or from) a media device (e.g., a portable media device such as a media player). In addition, in another embodiment, the client application may also include podcast creation or authoring capabilities. Such a high degree of integration can improve operation and be more user friendly and pleasing.

Fig. 8A is a flow diagram of a podcast update process 800 according to one embodiment of the invention. The podcast update process 800 generally determines when and how any podcast is updated at the client to obtain any new episodes associated with the podcast.

The podcast update process 800 begins with a decision 802 that determines whether a podcast update is to be performed. For example, podcast updates may be determined based on the updated configuration 712 provided in fig. 7. When the decision 802 determines that a podcast update has not been performed, the podcast update process 800 is deferred. Once the decision 802 determines to perform a podcast update, an existing podcast subscription is determined 804. Here, it is assumed that the podcast update process 800 is typically performed on all podcasts or a group of podcasts residing on the client. Once the existing podcast subscription is determined 804. The podcast host is typically a third party server that provides RSS podcast feeds. However, if the media store can also host a podcast, the podcast host can also be the media store.

Next, data is received 810 regarding any newer episodes of the podcast. Data regarding newer episodes of the podcast may be received from the podcast host. For example, by examining the RSS podcast feed, any newer existing episodes can be determined and then downloaded. The client may maintain data indicating that segments have been received.

A decision 812 then determines whether more podcasts (i.e., the determined podcasts) are to be updated. When the decision 812 determines that more podcasts are needed for updating, the podcast update process 800 returns and repeats block 806 and subsequent blocks. When the decision 812 determines that no more podcasts are updated, a decision 814 determines whether synchronization with the media device should be performed. When the decision 814 determines that synchronization with the media device should be performed, the segment data (new segment data) can be downloaded 816 to the media device. After block 816, or after the determination 814 that synchronization is not being performed, the podcast update process 800 ends.

Fig. 8B, 8C, and 8D are screenshots associated with displaying a podcast on an online media store. In this example, the online media store is iTunesMusic stores, which also have the ability to browse and search podcasts.

Fig. 8B is a screen shot of a podcast base page 820 according to an example embodiment of the present invention. The source indicator 822 indicates that the podcast base page 820 is provided by an online media store. The selector 824 also indicates that "podcast" is the media category being displayed. The focus area 826 contains the works associated with the three different podcasts being emphasized. The podcast base page 820 also contains the highest daily download fields 828, with the highest daily download fields 828 determining those highest downloading podcasts for that day. The podcast base page 820 also includes groupings of podcasts, for example, as a new program 830, a just-added podcast 832, and a podcast 836. These groupings may be displayed with a rolling window that may transition (e.g., horizontally) according to a transition effect. The podcast base page 820 also includes another focus area 834.

The podcast page is displayed upon selection of a particular podcast. Fig. 8C is a screen shot of a podcast page 838 according to an example embodiment of the invention. The podcast page 838 includes a metadata area 840 and a episode list area 842. The metadata area 840 includes podcast works 844, podcast titles 846, and other metadata information 848 (e.g., total episode, category, language, and copyright information). A "order" button 850 is also displayed. In addition, the metadata region 840 also includes a description 852 regarding the podcast. The episode list area 842 contains a list of available podcast episodes 854. Each clip in the list 854 includes a "get clip" button 856 to get the corresponding clip. By selecting the "subscribe" button 850, the user can cause the media management application to subscribe to the podcast. In this example, there is no subscription fee for the podcast. However, in other embodiments, the subscription to the podcast may be required for a fee. By selecting the "get fragment" button 856, the user can cause the media management application to get a particular fragment.

Fig. 8D is a screen shot of a podcast page 838 having a subscription confirmation dialog 858 that allows the user to confirm that they wish to subscribe to a podcast.

Fig. 8E is a screen shot of a podcast available page 860 according to an example embodiment of the present invention. The podcast available page 860 includes an indicator 862 indicating that the podcast is listed in the media resource list 864. The podcasts listed in media assets list 864 may include a sub-list of the episodes. These podcasts listed in the media resource list 864 reside on the client device. Typically, these podcasts were previously downloaded to the client device from an appropriate host server. Indicators 866 can be used to visually determine those podcasts listed that are available to the online media store. For example, the indicator 866 can determine those podcast hosts that are on-line media stores. By selecting any of the clips, the associated audio can be played for the user. The selector 868 indicates that a snippet titled "Additional Shopping" is being played for the user, wherein a related work 869, snippet or chapter of the podcast is displayed.

Fig. 8F is a screen shot of a podcast available page 870 according to another example embodiment of the present invention. Podcast available page 870 includes media resource list 871 which is similar to media resource list 864 of fig. 8E. In this example, the media asset list includes a non-playable clip 872 because the clip data has not yet been downloaded to the client device. In this example, these snippets 872 are highlighted with a "get" button 874. Upon selection of the "get" button 874, the corresponding episode 872 is retrieved from the appropriate host server.

Generally, when podcast listings are provided by a media store or are available locally through a client, the listings may be organized in a variety of different ways. One example of list organization is sorting podcasts according to rating. For additional information used in RATING media stores, see (i) U.S. patent application No.11/114,914 entitled "PUBLISHING, BROWSING, RATING AND PUBLISHING OF group OF GROUPS MEDIA ITEMS," filed 4, 25.2005; AND (ii) U.S. patent application No.11/115,090 entitled "PUBLISHING, BROWSING AND PURCHASING OFGROUPS OF MEDIA ITEMS," filed 4/25/2005.

Fig. 8G is a screen shot of a podcast available page 876 according to another example embodiment of the present invention. The podcasts listed in the podcast available page 876 are similar to those listed in the podcast available page 870 illustrated in fig. 8F. The podcast may show an indicator 878 with a page 876 that visually identifies those episodes of the podcast that are in the process of being downloaded to the client device 878. Here, the clip being downloaded is listed as being present but not yet present on the client device. Once downloading of the segments begins, an indicator 878 is displayed. After downloading the clip, the indicator 878 and any highlighting is removed.

As noted above, after the subscription to the podcast begins, the podcast needs to be updated to obtain a new episode. To provide efficiency and intelligence in the way that updates are sought, a client (e.g., a media management application) may use preference settings preferences or determine when to update. Such a preferred setting may be provided for all podcasts worldwide or on a single podcast basis. For example, the preferred settings may indicate that the new episode is checked periodically (e.g., hourly, daily, weekly), or when the client is started.

Once the podcast episodes have been stored on the client device, some or all of the episodes may be copied to a portable media player that may be operatively connected to the client device. To provide efficiency and intelligence in the manner in which such copying (also referred to as synchronization) is performed, a client (e.g., a media management application) may use preference settings preferences or determine when to perform the copying (i.e., automatically perform). Such a preferred setting may be provided for all podcasts worldwide or on a single podcast basis. The preference may vary from embodiment to embodiment. Some preferred examples include: (1) removing the segment after listening to the segment on the client device; (2) removing the segments after listening to the segments on the portable media device; (3) keep/download n most recent segments; (4) hold/download at most n; and (5) keep/download based on date.

In one example embodiment, the user may use the synchronized preferences screen. The synchronization preference screen enables a user to set certain synchronization preferences for copying podcast updates from the client device to the portable media device. Specifically, as an example, the user may select: (1) automatically updating all podcasts; (2) automatically updating only the selected podcast; (3) manually managing podcasts (i.e., without automatic updates); and (4) deleting the podcast from the portable media player after the podcast is displayed. Other criteria (not shown) that may be used include downloading up to n clips and/or downloading only those clips that have not yet been listened to. For example, if a particular clip is listened to on a client device, it is likely that the user may not want to download the clip to the portable media player.

Note that by deleting those episodes that were listened to from the portable media player, the portable media player can retain only those podcast episodes that the user has not listened to. Here, the clips that have already been played are automatically removed. In one embodiment, a podcast episode can be considered played if substantially all of the episode is played. For example, if 95% of a clip is played, the clip can be considered to be played.

Another aspect of the invention relates to improving a method of enabling subscription to podcasts. In one embodiment, ordering podcasts may be facilitated using portable electronic files known as podcast subscription files. Indeed, in one embodiment, the subscription may be completed in an automated manner by simply selecting or opening the podcast subscription file (e.g., double-clicking on the file).

Fig. 9 is a flow diagram of a podcast subscription file creation process 900 according to one embodiment of the present invention. For example, the podcast subscription file creation process 900 is performed by a client (client program), such as a media management application. The podcast subscription file creation process 900 begins to create 902 a portable podcast subscription file. A portable podcast subscription file is an electronic file that contains information that facilitates subscription to a podcast. After the portable podcast subscription file is created 902, the portable podcast subscription file is made available 904 to others. The portable podcast subscription file can then be disseminated as needed and then used to assist in subscribing to the podcast.

In one embodiment, the portable podcast subscription file is an XML document (or other markup language category document) that contains podcast information that facilitates subscription to the podcast. As an example, the podcast information with XML documents includes at least a feed URL for the podcast feed. Additionally, the podcast information may include other descriptive information about the podcast, such as a title and description. Representative examples of portable podcast subscription files are as follows:

note that the link named "feed" is associated with a URL (feed URL) that points to a podcast feed (e.g., "myfeed"). The portable Podcast subscription file also includes a title ("My Podcast") and a description ("l talk about random pages") for the associated Podcast. The XML format is a markup language format that uses tags that distinguish different data items within the document.

Fig. 10 is a flow diagram of a podcast subscription file usage process 1000 according to one embodiment of the present invention. For example, the podcast subscription file usage process 1000 is performed by a client (e.g., a media management application running on a client device).

The podcast subscription file usage process 1000 initially obtains 1002 a Portable Podcast Subscription File (PPSF). The portable podcast subscription file may be obtained 1000 prior to other processing performed by the podcast subscription file usage process. That is, the decision 1004 determines whether to request opening of the portable podcast subscription file. For example, a request to open may send an OpenURL event signal. When the decision 1004 determines that the portable podcast subscription file has not been requested to be opened, the podcast subscription file usage process 1000 simply waits for such a request.

Once the decision 1004 determines that the portable podcast subscription file is requested to be opened, a decision 1006 determines whether a Media Management Application (MMA) is running. Typically, a media management application is running on a client device. When the decision 1006 determines that a media management application is not currently running, the media management application is launched 1008. Following block 1008, or following the decision 1006 that the media management application is determined to be running, the portable podcast subscription file is parsed 1010 to retrieve at least the feed URL for the associated podcast. In one embodiment, the request to open the portable podcast subscription file may be a URL scheme ("itpc" or "pcast") that is recognized by the media management application as an XML document to be parsed and used to subscribe to the podcast.

Next, the podcast subscription file usage process 1000 subscribes 1012 to the relevant podcast. The subscription 1012 to the associated podcast may be performed automatically without any feedback or input from the user of the media management application. However, if desired, additional processing may be performed to display descriptive information about the podcast and/or to ask the user if the user wants to subscribe. In other words, the user can confirm that they want to subscribe to the relevant podcast and/or the user can receive additional information (e.g., title, description, etc.) about the podcast to which they will subscribe. Regardless, after block 1012, the podcast subscription file usage process 1000 ends.

Fig. 11 is a podcast subscription system 1100 according to one embodiment of the present invention. The podcast subscription system 1100 includes a client device a1102, a client device B1104, and a client hosting server 1106, each of which is operatively connected to a data network 1008. Client device a1102 includes a Media Management Application (MMA) 1110 and client device B1104 includes a Media Management Application (MMA) 1112. The client device a1102 creates or obtains a portable podcast subscription file 1114. The portable podcast subscription file 1114 may be transmitted to one or more other client devices. In this example, the portable podcast subscription file 1114 can be assumed to be created by the media management application 1110.

Once the media management application 1110 has the portable podcast subscription file, the media management application 1110 may transmit the portable podcast subscription file 1114 over the data network 1108. In this example, assume that a portable podcast subscription file 1114 is transmitted to the media management application 1112 of client device B1104 over the data network 1108. Here, as shown in fig. 11, the portable podcast subscription file 1114 is shown in dashed boxes within the client device B1104.

The media management application 1112 of client device B1104 may then subscribe to the associated podcast using the portable podcast subscription file 1114. More specifically, if the user of client device B1104 were to "open" the portable podcast subscription file 1114, such as by a double-click operation, the media management application 1112 processes the "open" request as a request to subscribe to a podcast through the media management application 1112. In this example, the podcast resides on a podcast host server 1106. In particular, the portable podcast subscription file 1114 is parsed by the media management application 1112 to obtain the feed URL of the podcast feed 1116 for the podcast residing on the podcast host server 1106. The media management application 1112 may then access the podcast feed 1116 to obtain certain podcast information and then store it at the client device B1104.

It should be appreciated that, in general, a portable podcast subscription file (e.g., the portable podcast subscription file 1114) can be transmitted to one or more other client devices in a variety of different manners. For example, the portable podcast subscription file may be sent via an email message to a user associated with the client device. The user may then open the portable podcast subscription file to activate the subscription podcast. In another example, the portable podcast subscription file may be associated with a link on a web page. Then, when a user on the website selects a link to a web page, the portable podcast subscription file may be downloaded to a client device associated with the user and then processed by the media management application to subscribe to the podcast. In another example, the portable podcast subscription file can be transmitted via a portable computer-readable medium (e.g., a flash memory card on a floppy disk or a compact disk).

Another aspect of the invention relates to deactivating a subscription to a podcast. More specifically, this aspect of the invention deactivates subscriptions that are deemed not to be in effect. In one embodiment, the deactivation process may be performed automatically. One advantage of deactivating subscriptions that are deemed not to be in effect is that network bandwidth may be preserved. Another advantage of deactivating subscriptions that are deemed not to be in effect is that the host server hosting the podcast is not burdened with download requests from client applications of users who have little or no interest in the podcast.

Fig. 12 is a flow diagram of a podcast update process 1200 according to one embodiment of the present invention. For example, the podcast update process 1200 is performed by a client, such as a media management application.

The podcast update process 1200 begins with a decision 1202 that determines whether to perform a podcast update. When the decision 1202 determines that a podcast update has not been performed, the podcast update process 1200 waits until a podcast update is performed. In other words, the podcast update process 1200 is effectively activated when a podcast update is to be performed. The podcast update may be requested by the client or a user of the client. For example, the client may automatically initiate podcast updates periodically.

On the other hand, when the decision 1202 determines that a podcast update is to be performed, a podcast feed (e.g., an RSS feed) is accessed 1204 with respect to the particular podcast to obtain episode information regarding the podcast. A new episode for the podcast is then determined 1206 based on the acquired episode information. In one embodiment, the retrieved episode information is an XML file that contains metadata describing the characteristics of a particular podcast (including the individual episodes of the podcast). The XML file can be parsed to obtain fragment information (e.g., fragment metadata). The review of the episode information may serve to determine new episodes of the podcast as compared to those episodes that are earlier in time or have previously been available on the client.

Next, a decision 1208 determines whether there is a new episode of the podcast to download. Here, the new episode may be obtained from a host server of the podcast and thus available for download to the client. When the decision 1208 determines that there is a new episode to download, the podcast update process 1200 determines 1210 whether the podcast is inactive. When the decision 1212 determines that the podcast is not inactive, the new episode 1200 is downloaded 1214 to the client. After downloading 1214 the new episode, the podcast update process 1200 is complete and ends, and the client receives the podcast update. On the other hand, when the decision 1208 determines that there are no new episodes to download or when the decision 1212 determines that the podcast is inactive, the podcast update process 1200 is complete and ends without downloading any new episodes.

Fig. 13 is a flow diagram of a podcasting activity process 1300 according to one embodiment of the present invention. The podcast activity process 1300 is generally used to determine whether a podcast is active or inactive. As an example, the podcasting activity process 1300 may be used as the process performed by the determination 1210 shown in fig. 12, in accordance with an embodiment of the present invention. In this embodiment, at least one pair of variables is maintained for each podcast (that has been subscribed to) to help determine whether the podcast is active or inactive. In this exemplary embodiment, the variables are the segment download count and the date of initial segment download.

The podcast activity process 1300 begins with a decision 1302 determining whether the podcast download count is greater than an integer N. When the decision 1302 determines that the episode download count is greater than N, a decision 1304 determines whether more than M days have elapsed since the date the initial podcast was downloaded, where M is an integer. For example, the integers M and N may equal five (5). When the decision 1304 determines that more than M days have elapsed since the date of the initial podcast download, a decision 1306 determines whether the client is active since the date of the initial podcast download. When the decision 1306 determines that the client is active since the date the initial podcast was downloaded, the podcast is made 1308 inactive. Here, in this embodiment, the podcast is rendered 1308 inactive because the podcast activity process 1300 programmatically determines that there is insufficient activity with respect to the podcast. Thus, it is assumed that the user of the client has little or no interest in the podcast. As a result, the podcast update process 1200 of fig. 12 bypasses the download 1214 of the new episode, thereby conserving network and server resources.

On the other hand, the podcast is made 1310 active when the decision 1302 determines that the episode download count is not greater than N, or when the decision 1304 determines that there are not more than M days since the date of the initial podcast download, or when the decision 1306 determines that the client is not active since the date of the initial podcast download. After blocks 1308 and 1310, the podcasting activity process 1300 is complete and ends.

FIG. 14 is a flow diagram of a reset activation variable process 1400 according to one embodiment of the invention. For example, the reset activation variable process 1400 is performed by a client running on a client device. The client operates to reset the activation variable at the appropriate time during its operation to affect the podcasting activity process 1300 described above with respect to fig. 13. In other words, at certain times, the activation variables utilized by the podcasting activity process 1300 may be reset to affect the operation of the podcasting activity process 1300. For example, the activation variable that is reset may include a segment download count or a date of the initial segment download. Note that these reset variables may directly affect the decisions 1302, 1304, and 1306 of the podcast activity process 1300.

The reset activation variables process 1400 begins with decision 1402, which determines whether a reset condition is established. The reset condition may be established in a variety of different ways. The resetting of the condition may be initiated automatically or by a user. In any event, when the decision 1402 determines that a reset condition does not exist, the reset active variable process 1400 waits for such a condition. In other words, the reset active variables process 1400 begins when the appropriate reset conditions are reached. The episode download count is reset 1404 once the decision 1402 determines that the appropriate reset conditions have been met. Here, the episode download count can be reset 1404 to zero. In addition, the date of the initial segment download is reset 1406. Here, the date of the clip download can be reset 1406 to the current date. After block 1406, the reset activate variable process 1400 is complete and ends.

While the reset condition may be established in a variety of ways, events occurring on the client may result in a reset condition when initiated programmatically or by a user. Generally, the reset condition is programmatically triggered when the client recognizes that the client or client user is interested in podcasting. Examples of events that express interest in podcasts are: (1) playing the podcast clip by the user; (2) the client (or the portable media player) completes playing of the podcast clip; and (3) the user downloads the podcast episode.

Another aspect of the invention relates to enhancements to podcast chapters. Chapter enhancements can provide an improved user interface for using podcasts. Chapter enhancements are enabled by podcasts containing chapter information. For example, chapter information may be displayed in various ways to enhance the playing experience.

Chapter information may include, but is not limited to: titles, pictures, urls, descriptions (e.g., in the form of a large amount of text, including embedded links), movies (audio and video), works, albums, and podcast subscriptions. All chapter information is optional, e.g., some chapters may have titles and pictures, and other chapters may have titles only.

Podcasts may carry chapter information, either embedded in a file (e.g., an XML file), or carried in a podcast feed.

To embed chapter information into a file, the m4a file format may be extended to support additional chapter information. The track information is formatted according to the ISO file format. Tracks marked as chapter tracks may contain chapter information. A track may be named track, url track, picture track, description track, or other metadata track. At the beginning of any chapter, the chapter information contained within the user interface may be changed to correspond to that chapter.

In order to provide chapter information in a podcast feed, the podcast, i.e., the RSS feed of the podcast, may be enhanced to contain chapter related information. The chapter related information may be specified by a newly specified XML event (e.g., chapter marker). A client application, such as a media management application, that infers these XML elements may retrieve chapter related information from the RSS feed, thereby providing an enhanced user interface on the client device (or a portable media device associated with the client device). The chapter related information may be text, audio, images, and/or video. In the event that the client application does not understand the newly specified chapter elements, the RSS feed may still be used, but without user interface enhancements.

In one embodiment, the newly specified XML element is (i) a segment element (segment element) signaling identifying a segment (i.e., chapter) signal that acts as a container element (container element); and (ii) a link element-one or more of these defined multimedia elements (picture, auxiliary audio, auxiliary video) associated with the segment. Each segment may have a start time, a title, and a URL to a multimedia element. For example, at the beginning, a title and multimedia elements are displayed. Each segment may also contain other metadata about the segment of the podcast (e.g., author, track, related URL link).

An example RSS feed with three (3) sections is:

facilitating user interface enhancements (client applications or portable media devices) through the presence of chapter information may include any of the following examples. As one example, a chapter picture may be displayed in association with a chapter of a podcast. When the podcast is played, the chapter picture is automatically changed to correspond to the current chapter. Chapter pictures may also change as a user jumps from chapter to chapter (e.g., wipes). As another example, when a user selects a pop-up menu to select a chapter, each menu item in the pop-up menu contains a chapter title and also contains a thumbnail of the chapter picture. As another example, when a user selects (e.g., clicks on) a chapter picture, the client application links (hyperlinks) to the chapter URL. In another example, the chapter information may change as the chapter changes. Here, the chapter artist, program, description, and other information may be displayed in various portions of the user interface, so that it may change as the chapter changes. In another example, the subscription link may be used as chapter information. If the subscription link is selected, the client application automatically subscribes to the podcast feed. In one embodiment, the subscription link may point to a portable subscription file.

Although the media assets (or media items) highlighted in the several embodiments above are podcasts that include audio items (e.g., audio files or audio tracks), the media assets are not limited to audio items. For example, the media asset may alternatively relate to a video (movie) or an image (e.g., a photo). More specifically, podcasts may also be referred to as digital multimedia assets.

The various aspects, embodiments and implementations or features of the invention may be used independently or in any combination.

The invention is preferably implemented by software, but can also be implemented in hardware or a combination of hardware and software. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storage devices, and carrier waves. Examples of the computer readable medium may also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The many features and advantages of the invention are apparent from the written description. It is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, the invention should not be limited to the exact construction and operation as illustrated and described. All suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims (15)

1. A portable media player comprising:

a communication port adapted to communicate with an external device other than the portable media player; and

a processor coupled to the communication port, the processor adapted to update the podcast by accessing episode information for a podcast having episodes and then updating the podcast with a new episode for the podcast if it is determined that the new episode exists.

2. A portable media player as recited in claim 1, further comprising a storage device that stores said podcast having episodes.

3. A portable media player as recited in claim 1 or 2, wherein said processor is further adapted to determine whether said podcast is active.

4. A portable media player as recited in claim 3, wherein said determining whether said podcast is active comprises:

determining whether a user of the portable media player is interested in the podcast.

5. A portable media player as recited in claim 3, wherein said determining whether said podcast is active comprises:

it is determined whether the segment download count is greater than a threshold amount.

6. A portable media player as recited in claim 3, wherein said determining whether said podcast is active comprises:

it is determined whether a threshold number of days has elapsed since the date the first episode was downloaded.

7. A portable media player as recited in claim 1 or 2, wherein the communication port is further adapted for bi-directional communication with the external device.

8. A portable media player as recited in claim 1 or 2, wherein the clip information is included in a portable subscription file stored at the client device.

9. A method of automatically updating a podcast, comprising the steps of:

accessing, at a client device, episode information for the podcast; and

updating, at the client device, the podcast with a new episode of the podcast if it is determined from the episode information that the new episode exists.

10. The method of claim 9, further comprising the step of:

determining whether the podcast is active.

11. A method as recited in claim 10, wherein said determining whether the podcast is active comprises:

it is determined whether the podcast is of interest to the user.

12. A method as recited in claim 10, wherein said step of determining whether said podcast is active comprises the steps of:

it is determined whether the segment download count is greater than a threshold amount.

13. The method according to any of claims 9-12, wherein the clip information is included in a portable subscription file stored at the client device.

14. The method according to any of claims 9-12, further comprising the step of:

transmitting subscription information from the client device to at least one other client device over a data network without interacting with a host device, thereby allowing the other client device to subscribe to the podcast.

15. An apparatus for automatically updating a podcast comprising means for performing each step of the method of any of claims 9-14.