专利名称：：播客的获取、管理和同步的制作方法
技术领域：
：本发明涉及播客(podcast)，更具体而言，涉及在便携式媒体设备上获取和播放播客。
背景技术：
：媒体播放器存储有可在媒体播放器上播放或显示的媒体资产，例如，音轨。便携式媒体播放器的一个示例为iPod⑧媒体播放器，它可从Cupertino，CA的苹果计算机公司获得。一般而言，媒体播放器需要从用于使用户能够管理媒体资产的托管计算机获取其媒体资产。在对媒体资产进行管理时，用户能够为音轨创建播放列表。这些播放列表可在托管计算机处创建。然后，可将播放列表内的媒体资产拷贝到媒体播放器。例如，托管计算机可执行媒体管理应用以创建和管理媒体资产。媒体管理应用的一个示例是由苹果计算机公司生产的iTunes。播客通常用于共享来自网站的内容。播客与使用简易XML格式的真简易信息聚合(RSS，ReallySimpleSyndication)馈送相关联。可将播客构成很像收音机或电视节目的片段。感兴趣人士可预订接收随后发行的播客片段。这通过感兴趣人士使用其计算机访问托管RSS馈送的播客站点来实现。然后，感兴趣人士能够预订RSS馈送，以便其计算机有时会再访问播客站点以检查是否有任何新的播客片段。一般而言，如果有新播客片段可用，则将其下载到计算机。之后，感兴趣人士能够在其计算机处按照与其他音频文件(例如，MP3文件)的同样方式播放播客片段。可使用应用程序将音频文件下载到便携式媒体播放器(例如，MP3播放器)。这样传统应用程序的一个示例为"iPodder"，它是在人们的计算机上运行的用于将音频文件下栽到其便携式媒体播放器的小程序。遗憾的是，在托管计算机上通常不易对播客进行管理。当发布新片段时，播客经常会动态变化。对这样动态变化的媒体资产进行管理很复杂。另外，对于托管计算机需支持便携式媒体播放器的方面而言，托管计算机需要对播客数据到便携式媒体播放器的传输进行管理。从而，需要用于在计算机上管理和使用播客的技术。
发明内容本发明涉及便于使用播客的改进型技术。该改进型技术可涉及创建、发行、托管、访问、预订、管理、传输和/或播放播客。根据一个方面，客户机应用能够用于实现，从多个播客中发现感兴趣的播客，预订感兴趣的播客，以及对感兴趣的播客进行随后的管理。对感兴趣播客的管理可包括在很少需要或不需要与用户交互的条件下获取更新的播客数据。根据另一方面，对客户机应用而言本地可用的某些或全部播客可通过便携式媒体设备进行拷贝(例如，同步化)，以便使播客方便可用，并可通过客户机应用或便携式媒体设备播放。可采用多种方式实现本发明，这些实现方式包括作为方法、系统、设备、装置(包括图形用户界面)，或计算机可读介质。下面，将描述本发明的数个实施例。作为用于从运行在个人计算机上的客户机应用预订播客的方法，本发明的一个实施例至少包括以下行为通过客户机应用从在线媒体商店处可获得的多个播客发现特定播客；由客户机应用预订特定播客；以及随后通过客户机应用获取特定播客的播客元数据和播客媒体内容。、作为至少包括用于预订播客的计算机程序代码的计算机可读介质，本发明的一个实施例至少包括用于从在线媒体商店处可获得的多个播客发现特定播客的计算机程序代码；用于预订特定播客的计算机程序代码；以及用于获取特定播客的播客元数据和播客媒体内容的计算机程序代码。作为用于访问播客的系统，本发明的一个实施例至少包括运行媒体管理应用的客户机设备，所述媒体管理应用用于从具有关于多个播客的描述性信息和访问信息的在线媒体商店发现至少一个播客，用于从在线媒体商店获取至少一个播客，以及用于将至少一个播客拷贝到便携式媒体播放器。作为用于维护播客的方法，本发明的一个实施例至少包括这样的行为，即，更新客户机设备处的播客数据，以及将播客数据的合适部分拷贝到便携式计算设备。结合示例性示出本发明原理的附图，通过后面的详细描述，本发明的其他方面和优点将变得显而易见。结合附图，通过后面的详细描述，本发明将变得易于理解，其中，相同的附图标记表示相同的结构元件，且其中图l表示根据本发明的一个实施例的媒体系统的框图；图2A和2B表示根据本发明的一个实施例的播客提交处理的流程图；图3A和3B表示根据本发明的一个实施例的播客发行处理的流程图；图4表示根据本发明的一个实施例的认证处理的流程图；图5A表示根据一个示例性实施例的网络地址提交页的屏幕快昭，,、、、，图5B表示根据一个示例性实施例的播客预览页的屏幕快照；图6表示根据本发明的一个实施例的媒体商店播客交互处理的流程图；图7表示根据本发明的一个实施例的集成播客获取处理的流程图8A表示根据本发明的一个实施例的播客更新处理的流程图；图8B表示根据本发明的一个示例性实施例的播客基页的屏幕快照；图8C表示根据本发明的一个示例性实施例的播客页的屏幕快照；图8D表示根据本发明的一个示例性实施例的具有订单确认对话框的播客页的屏幕快照；图8E表示根据本发明的一个示例性实施例的播客可用性页的屏幕快照；图8F表示根据本发明的另一示例性实施例的播客可用性页的屏幕快照；图8G表示根据本发明的另一示例性实施例的播客可用性页的屏幕快照；图9表示根据本发明的一个实施例的播客预订文件创建处理的流程图；图IO表示根据本发明的一个实施例的播客预订文件使用处理的流程图；图ll表示根据本发明的一个实施例的播客预订系统；图12表示根据本发明的一个实施例的播客更新处理的流程图；图13表示根据本发明的一个实施例的播客活性(activity)处理的流程图；以及图14表示根据本发明的一个实施例的重置活性变量处理的流程图。具体实施方式本发明涉及便于使用播客的改进型技术。改进型技术可涉及创建、发行、托管、访问、预订、管理、传输和/或播放播客。根据一个方面，客户机应用能够用于从多个播客发现感兴趣的播客，预订感兴趣播客，和对感兴趣播客提供随后的管理。对感兴趣播客的管理可包括，很少需要或不需要用户交互就可获取更新的播客数据。根据另一方面，对客户机应用而言本地可用的某些或全部播客可通过便携式媒体设备进行拷贝(例如，同步化)，以便使播客方便可用，并可通过客户机应用或便携式媒体设备播放。下面，将参照图1-14描述本发明的实施例。然而，本领域技术人员将易于理解，此处参照这些附图给出的详细描述是用于解释说明的目的，因为本发明超出这些限定性实施例的范围。图l表示根据本发明的一个实施例的媒体系统100的框图。媒体系统100包括用于托管在线媒体商店的媒体商店服务器102。如果需要，媒体商店服务器102能够卸载(off-load)商业交易和/或购买的数字媒体资产到其他服务器的传递。如图1所示，媒体系统100包括为终端用户使用的一个或多个客户机设备104。客户机设备104与数据网络106相连。另外，媒体商店服务器102还与数据网络106相连。在一个实施方式中，数据网络106可表示一个或多个数据网络，通常为高数据带宽网络，即，有线网络，如Internet,以太网、吉比特以太网和光纤网络，以及无线网络，如IEEE802.il(a)，(b)或(g)(WiFi)、IEEE802,16(WiMax)和超宽带(UWB)。计算机程序108(客户机或客户机应用)通常是媒体管理应用(MMA)或其他媒体播放器应用，其运行在客户机设备104上。媒体管理应用的一个示例为iTunes⑧应用(由Cupertino,CA的苹果计算机公司生产)。客户机设备104通常为计算设备。例如，客户机设备104可为专用或通用个人计算机(或甚至是便携式媒体播放器)。客户机设备104能够连接便携式媒体设备109(便携式媒体播放器)。适于本发明使用的便携式媒体播放器的一个示例是iPod，它也是由苹果计算机公司生产。计算机程序108可被用户用于多个目的，包括但不限于从媒体商店服务器102提供的在线媒体商店浏览、搜索、获取和/或购买媒体资产(包括播客)；创建和分享媒体资产组(例如，播放列表)；对媒体资产进行组合；呈现/播放媒体资产；在客户机设备104之间传输媒体资产；以及与便携式媒体设备109进行同步。媒体系统100还可包括一个或多个客户机设备110以《更为媒体编程者使用。客户机设备IIO还运行计算机程序112，通常是媒体管理应用(MMA)或其他媒体播放器应用。计算机程序112可与计算机程序108相同，但计算机程序112可提供用于支持媒体编程者的附加功能。例如，使用计算机程序112的媒体编程者可提供用于创建和发行播客的附加功能。媒体系统IOO还包括数字资产管理器114。数字资产管理器114与媒体资产数据库116相连接。媒体资产数据库116存储有媒体资产信息，包括与在线媒体商店处可购买的数字媒体资产相关的元数据。元数据可涉及单个媒体资产(数字媒体资产)或媒体资产组(数字媒体资产组)。媒体资产可包括但不限于音乐、视频、文本和/或图形文件。媒体资产或媒体资产组的一种特殊类型是播客，其通常包括音频、图形和文本(不过还可包括视频)。在音乐情形中，媒体资产组可为音乐播放列表。数字媒体资产组类型的一个具体示例称为iMixTM，它是目前可用于在苹果计算机公司的iTunes⑧MusicStore上进行浏览和/或购买的发行的播放列表。数字媒体资产组类型的另一具体示例称为iEssentialTM，它是媒体编程者创建的发行的播放列表，目前可用于在苹果计算机公司的iTunes⑧MusicStore上进行浏览和/或购买。数字媒体资产组类型的另一具体示例称为CelebrityPlaylist，它是由名人创建的发行的播放列表，可用于在苹果计算机公司的iTunesMusicStore上进行浏览和/或购买。媒体商店服务器102使特定客户机设备104的用户能够获取媒体资产(例如，播客)。随后，客户机设备104能够通过数据网络106从媒体商店服务器102或某些其他服务器下载媒体资产。熟悉数据网络的人们应能理解，也可能存在其他网络配置。此外，尽管将媒体商店服务器102和数字资产管理器114显示为单个且不同的设备，熟悉本领域技术的人们应该理解有可能存在其他配置。作为一个示例，每个设备可被实现为分布在多个服务器计算机上。作为另一示例，可通过单个物理服务器计算机实现这些不同服务器和/或管理器。图2A和2B表示根据本发明的一个实施例的播客提交处理200的流程图。播客提交处理200例如由客户机(例如，应用程序)执行。客户机的一个示例是运行在客户机设备上的媒体管理应用。播客提交处理200开始于创建202播客。播客可在播客提交处理200期间创建或者可在先前已进行了创建。在一个实施方式中，播客提交处理200由单个应用(例如，媒体管理应用)执行。在另一实施方式中，可在一个应用中实现播客创建，而在另一应用中可实现播客发行。创建202播客后，判定204确定是否已请求发行。当判定204确定未作出发行请求时，播客提交处理200等待这样的请求。另一方面，一旦判定204确定已作出发行请求，则接收206到播客的网络地址(例如，播客馈送URL)。在一个实现方式中，客户机用户将把合适网络地址输入到客户机呈现给用户的图形用户界面的文本输入框中。然后，将到播客的网络地址发送208到服务器。服务器例如可为媒体商店或某些其他服务器。之后，判定210确定是否已接收到播客预览页。当判定210确定未接收到播客预览页时，播客提交处理200等待播客预览页的接收。或者，当判定210确定已接收到播客预览页时，显示出212播客预览页。一般而言，播客预览页至少包括关于播客的基本播客元数据。一旦显示出212播客预览页，则可改变(即，编辑)基本播客数据。此外，播客预览页可包括一个或多个数据输入字段，其有助于关于可由用户提供的附加(或补充)播客元数据的数据输入。接下来，判定214确定客户机用户是否想对播客预览页的基本播客元数据进行编辑(改变)或提供附加播客元数据。当判定214确定用户确实要编辑播客元数据时，则可修改216播客元数据。例如，用户能够编辑基本播客元数据或能够使用数据输入字段输入附加播客元数据。一个示例性附加元数据是为播客提供类别分类。附加播客元数据还可称为追加播客元数据。在方框216之后，或者当未执行修改时直接在判定214之后，判定218确定用户是否提交了播客元数据。此处，在任何数据修改之后，播客元数据的提交表示出用户接受播客元数据，无论是基本播客元数据还是附加播客元数据。提交的这样的播客元数据可称之为最终播客元数据。因此，当判定218确定要提交播客元数据时，提交220最终播客元数据。一般而言，要将最终播客元数据提交220给服务器，例如，如图1所示的媒体商店服务器。下面就给出了播客的示例性RSS馈送(feed)。注意，如之后将更详细讨论的那样，RSS馈送提供了对于频道(即，表演)以及对于每个项(即，章)的分类。对于每个项，通过URL识別音频文件(例如，MP3或AAC格式)。示例性RSS馈送<7xmlversion="1.0"encoding="UTFD<l-mustIncludexmlns:itunestag—><rssxmlns:itunes="http://www.rtunes.com/DTDs/Podcast-1.0.dtd"version="2.0"><channel><title>AIIAboutEverything</title><rtunes:author>JohnDoe<itunes:author><link>http:〃www.itunes.com/podcasts/everything/index.html</link><description>AllAboutEverythingisashowabouteverytWng.Eachweekwediveintoeverysubjectknowntomanandtalkabouteverythingasmuchaswecan,</description><itunes:subtitle>AllAboutEverythingisashowabouteverything</itunes:subtitle><ltunes:summary>A"AboutEverythingisashowabouteverything-EachweekwediveIntoeverysubjectknowntomanandtalkabouteverythingasmuchaswecan.LookforourPodcastintheiTunesMusicStore</itunes:summary><language>en-us</language><copyright>AcmeNewsCorp-2005</copyright><itunes:owner><itunes:name>JohnDoe</itunes:name><ltunes:email>johndoe@mac.com</rtimes:em3il></itunes:owner><im3gB><url>http:〃www.itunes.com/podcasts/everythlng/AIIAbou尼verything.jpg</urt><trtle>AllAboutEverything<rtitle><llnk>http:〃www,-.com/podcasts/everythlng/index.html</link></image><!--themaxsizeforrssimageis144x400<l—iTunesallowsimageslargerthanthat<ltunes:linkrel-"image"type="video/jpeg"href="http:〃www.itunes,com/podcasts/everything/AIIAboutEverythlng.jpg":>AllAboutEverything</ltunes:link><category>Technology</category:<!--categoriescanbenestedforcategory/subcategory--><!一therecanbemultipleitunescategories,thefirstsetistheprimarycategory/subcategory—><itunes:categorytext=、'Technology，>.<itunes:categorytext="Gadgets7></ituries:c3tegory:><itunes:categorytext="Politics"/><itunes:categorytext='Technology"><itunes:categorytext="News7></itunes:category:><item><title>ShakeShakeShakeYourSpices</title><{tunes:3Uthor>JohnDoe</itunes:3Uthor><descrlptlon>Thisweekwetalkaboutsaltandpeppershakers,comparingandcontrastingpourrates,constructionmaterials,andoverallaesthetlcs.</description><itunes:subtitle>Ashortprimerontablespices</itunes:subtitle><itunes:summary>Thisweekwetalkaboutsaltandpeppershakers,comparingandcontrastingpourrates,constructionmaterials,andoverallaesthetics.ComeandJointheparty!</itunes:summary>enclosureurt-"http:〃www,itunes,com/podcasts/everything/AIIAboutEverythingEpisode3.mp3"length-"8727310"type-"x-audio/mp3"/><guid>http:〃www.itunes.com/podcasts/everything/AIIAboutEverythingEpisode3.mp3</guid><pubDate>Wed,15Jun200511:39:59GMT</pubDate><category>Technology</category><itunes:categorytext-'Technology"><itunes:categorytext="Gadgets7></itunes:category><itunes:explicit>no</itunes:explicit><itLfnes:duration>7:04</ihjnes:diiration><itunes:keywords>saltpeppershakerexcithg</itunes:keywords></item><item><title>SocketWrenchShootout</tttle><itunes';airthor>Jane.Doe</itunes;author><description>Thisweekwetalkaboutmetricvs.oldenglishsocketwrenches.WhichoneisbetterDoyoureallyneedboth</description><ltunes:subtitle>Comparingsocketwrenchesisfun!</ltunes:subtitle><itunes:summary>ThisweekWetalkaboutmetricvs.oldenglishsocketwrenches.WhichoneisbetterDoyoure別yneedboth7Getofyouranswershere.</Kunes:summary><enclosureurl="http:〃www.itunes.com/podcasts/everything/AllAboutEverythingEpisode2.mp3"length-"5650889"type="x-audio/mp3"/><guW>http://www.itunes.com/podcasts/everything/AllAboutEverythingEpisocle2.mp3《<pubDate>Wed,8Jun2005":20:59GMT</pubDate><category>Politics</category:><itunes:categorytext='Technology"><itunes:categorytext-"Gadgets"/></itunes:category><itunes:expllcrt>no</rtunes:expllcit><itunes:duration>4:34</itunes:duration:><itunes:keywords>metricsocketwrenchestool</itunes:keywords></item><item><title>Red,Whine,andBlue</title><itunes:author>Vartous</itunes:3uthor><description>Thisweekwetalkaboutsurvivingin3Redstateifyou'reaBlueperson.Orviceversa.</description><rtunes:subtitle>Red+Blue!=Purple</rtunes:subtitle><itunes:summary:>ThisweekwetalkaboutsurvivinginaRedstateifyou'reaBlueperson.Orviceversa.OrmovingtoCanada.</rtimes:summary><endosureurl="http://www.itunes.com/podcasts/everything/AllAboutEverythingEpisode1.nnp3"length-"4989537"type="x-audio/mp3"/><guld>http:〃www,itunes，com/podc3sts/everything/AllAboutEverythlngEpisocie1.mp3</guid><pubDate>Wed,1Jun200510:21:04GMT</pubDate><category>Polrtics</category><itunes:categorytext="Technology"><itunes:categorytext="Gadgete'V></itunes:category><itunes:explicit>no</rtunes:explicit><itunes:duration>3:59</itunes:duration><ttunes:keywords>politicsredbluestate</itunes:keywords></ltem></ch3nnsl></rss>由于表演和片段可与类别相联系，可提供改进型用户界面，以便对播客进行类别，并基于类别进行搜索或浏览。图3A和3B表示根据本发明的一个实施例的播客发行处理300的流程图。播客发行处理300由服务器执行，并表示出对于如图2A和2B所示的播客提交处理200的互易方处理。播客发行处理300最初接收302对于所要发行的特定播客的网络地址。例如，可通过客户机用户提供网络地址，然后将其发送到服务器(例如，图2A的方框206和208)。接收到302特定播客的网络地址后，服务器访问304播客馈送(例如，RSS馈送)以获取播客馈送元数据。换而言之，服务器使用该网络地址连接对于特定播客的播客馈送，以获取播客馈送元数据。然后，从播客馈送元数据获得306基本播客元数据。根据一个实现方式，基本播客元数据的获得可涉及对播客馈送元数据的解析。一般而言，播客馈送元数据将包括标签或标记(例如，XML元素)，以区分在播客馈送元数据内提供的元数据的不同字段。接下来，创建308播客预览页。在一个实施方式中，播客预览页包括基本播客元数据，并请求附加播客元数据。然后，将播客预览页发送310到客户才几。然后，判定312确定是否接收到最终播客元数据提交。当判定312确定未接收到最终播客元数据提交时，播客发行处理300等待这样的提交。另一方面，一旦判定312确定提交了最终播客元数据，则在服务器处存储314发行的播客信息。发行的播客信息至少包括网络地址和最终播客元数据，二者都与特定播客相关联。此时，将特定播客发行到服务器。此外，可对发行的播客信息做索引316，以便实现在服务器处(例如，图1的媒体商店服务器102)的搜索和/或浏览功能。最后，在服务器(例如，媒体商店)上将发行的播客绘制318成可用。在操作318之后，完成和结束播客发行处理300。在另一实施例中，可将播客发行处理(例如，播客发行处理300)修改成包括认证处理。可使用认证处理对试图发行播客的人进行认证。认证可采用多种不同方式执行。在一个实施方式中，认证可将试图发行的人认证为服务器知道的人(例如，帐户持有人)。在另一实施方式中，认证可根据播客托管者、创建者等对人进行认证。对服务器(例如，媒体商店)上可用的媒体项的浏览或搜索可类似对其他类型媒体资产的搜索那样执行。对于关于对媒体资产进行搜索或浏览的更多细节参见于2004年4月26日申请的题名为"GRAPHICALUSERINTERFACEFORBROWSING,SEARCHINGANDPRESENTINGMEDIAITEMS"[Att.Dkt.No.:APLlP277Xl]的美国专利申请No.10/832，984,其在此引作参考。然而，对于浏览而言，为有助于有效浏览播客，可为用户显示出具有分级列表的图形用户界面。在一个实施方式中，可选项的第一列表是流派列表。用户可选择表示为"Podcasts"的流派。一旦进行了选择，则将显示出可选项的第二列表。将在第二列表中的可选项表示为"Categories"。Categories表示可将播客分配到的不同类别。然后，根据类别选择，将显示出可选项的第三列表。将在第三列表中的可选项表示为"Subcategories"，从应用上，表示出所选类别的可用子类别。进行了多个选择之后，在媒体资产列表区域显示出与所选类别和所选子类别(如果使用的话)相匹配的那些播客。客户机可显示出应用程序窗口。应用程序窗口可包括第一子窗口和第二子窗口。第一子窗口包括第一区域、第二区域和第三区域。第一区域可显示出可用流派的列表(流派列表)。当用户在第一区域中显示的流派列表内选择其中一项(即，播客项)之后，可使用与从流派列表选出的流派相关联的播客类别的列表填充第二区域。播客类别列表由远程服务器提供给呈现应用程序窗口的应用程序。当用户选择第二区域的其中一个可用类别之后，可使用与所选类别相关联的子类别的列表填充第三区域。若在第三区域内有子类别的话，则所述子类别是属于所选类别的子类别。当子类别列表具有多个项时，用户可选择其中一项。如果是子类别(如果没有子类别则为类别)，一旦用户选中一项，则可使用与类别和子类别(若有的话)相关联的可用播客的列表填充第二子窗口。对于每个播客，可用播客列表可显示出描述性信息。例如，可釆用行和列(例如，表格)格式呈现出可用播客列表，其中，各行涉及不同的播客，而列涉及播客名称、艺术家、描述说明和价格。此外，在价格列内，各行可包括"Subscribe"按钮，以便于用户预订特定播客。图4表示根据本发明的一个实施例的认证处理400的流程图。例如可使用认证处理400代替如图3A所示方框310。认证处理400最初确定402用于认证用户(例如，授权发行人)的电子邮件地址。在一个实施例中，授权用户涉及在服务器或客户机上的帐户持有者。在另一实施例中，可从与要发行的播客相关联的RSS馈送(即，播客数据)获得授权用户。在任意情形中，确定402与授权用户相关联的电子邮件地址。当确定402出电子邮件地址后，创建404与播客预览页具有链接的发行消息。例如，发行消息可向接收者解释假定他们正发行他们的其中一个播客并选择关闭链接以继续发行处理。如果播客的发行未得到授权，则接收者能够取消发行处理。之后，判定408确定从授权用户是否接收到用于继续发行处理的请求。当判定408确定未接收到用于继续发行处理的请求时，认证处理400等待这样的请求。在一个实现方式中，该请求是用于访问播客预览页的请求。用户通过选择发行消息中的链接或将链接拷贝到在客户机处提供的数据输入区域中，可实现该请求。当判定408确定已接收了用于继续发行处理的请求时，将播客预览页发送410到客户机。之后，处理进行到如先前所讨论的播客发行处理300的操作312以及随后的操作。图5A表示根据一个示例性实施例的网络地址提交页500的屏幕快照。网络地址提交页500使用户能够输入到要在媒体商店上发行的现有播客的网络地址，即，馈送URL，在该示例中，媒体商店为iTunes⑧MusicStore。馈送URL被输入到文本框502中。在此示例中，输入的馈送URL为"http:〃www.inygarden.com/gardentalk—rss.xml"图5B表示根据一个示例性实施例的播客预览页520的屏幕快照。在该示例中，进行预览的播客的标题为"GardenTalk"。播客预览页520告知用户播客将如何在媒体商店处呈现。此处，得以预览的播客元数据包括图片、名称、作者、简短描述、长篇描述、类别和语言。在该示例中，可从播客馈送本身获取进行预览的许多播客元数据。然而，不从播客馈送获取的其他元数据，例如，类别和语言，可由用户进行选择或输入。不管怎样，可允许用户对预览的播客元数据进行编辑。另外，可进行选择，以便用户(发行人)能够表示出播客是否包含明确内容。一旦用户准备好要接受预览的播客元数据，用户就选择"Publish"按钮。一旦发行了播客，播客就在媒体商店(在线媒体商店)上变为可得到的。媒体商店可托管或不托管播客。如果媒体商店存储了所有或大部分播客内容，则可考虑由媒体商店托管播客。另一方面，如果媒体商店仅维护播客的元数据，则媒体商店就托管播客。当媒体服务器不托管播客时，第三方服务器可托管播客，且媒体商店适当地访问播客馈送以获取它所需的任何数据。客户机将从托管服务器访问播客馈送以获取其要进行本地存储的播客数据。因此，在一种情形中，媒体商店保存有播客内容，在另一情形中，媒体商店不保存播客内容。可将媒体商店配置成可在媒体商店上搜索或浏览播客。搜索或浏览功能的运作可类似于在在线音乐商店上搜索唱片集。然而，在播客的情形中，搜索或浏览操作是针对发行到媒体商店的播客。一般而言，对于音乐来讲，通过包括艺术家、唱片集和歌曲的分级结构实现浏览。在播客的情形中，必然的结果是通过包括播客(或播客类别)、表演和片段的分级结构实现。媒体商店还可将播客组成不同的类别，以便于用户通过与媒体商店的交互找到它们。类别的示例包括Arts&Entertainment(艺术欣赏)、BiographyandMemoir(传记与回忆录)、Business(商业)、Classics(名著)、Comedy(喜剧)、Drama&Poetry(戏剧与诗歌)、Fiction(小说)、History(历史)、Kids&YoungAdults(儿童&青年、成人作品)、Languages(语言)、Mystery(探秘)和News(新闻)。再者，发行到媒体商店的的某些播客可在媒体商店的特殊页上得以突出表示。例如，可使用诸如随机选择、分等级、最活跃下载、倡议等各种标准，将某些播客与其他相比得以突出表示。同样，可对最近媒体商店上可获得的"newshows(新表演)"或"justadded(刚添加的)"表演进行突出表示。后面，图8B给出了媒体商店提供的网页示例，其中突出表示了某些播客。图6表示根据本发明的一个实施例的媒体商店播客交互处理600的流程图。媒体商店播客交互处理600最初访问602媒体商店。然后，在媒体商店，用户可导航604到感兴趣的播客。导航可采用多种不同形式。导航的一个示例是搜索处理。导航的另一示例是浏览处理。导航的又一示例是网络地址的人工级次输入(manualnextentry)(例如，RSS馈送URL)。无论导航如何进行，一旦识别出感兴趣的播客，就绘制606出感兴趣播客的播客页。可在与客户机设备(例如，如图1所示的客户机设备104)相关联的显示器(显示屏)上，绘制606出播客页。播客页可包括关于播客的信息(例如，元数据)，其包括播客、图片和片段信息的描述。播客页还可用于实现预订播客或获得特定片段。此外，播客页可允许用户分不同级别。播客页还可提供便于用户报告某种事宜的链接。绘制606出播客页之后，客户机设备(客户机)的用户可与播客页进行交互，从而进行多种不同选择。这些选择可启动在客户机设备处的操作。与播客相关联的两个特定操作是(l)预订播客，以及(2)下载播客的特定片段。判定608确定是否进行了预订选择。当判定608确定作出预订选择时，执行预订处理610。预订处理610用于使客户机设备(或客户机)通过托管设备预订感兴趣的播客。或者，当判定608确定未进行预订选择时，判定612确定是否进行了片段选择。当判定612确定作出了片段选择时，下载614关于片段选择的片段数据。此处，片段数据将被下载614到客户机设备。在一个实施方式中，片段数据至少包括音频文件和数据库内容。数据库内容可作为音频文件的一部分文件或不同文件。另一方面，当判定612确定未进行片段选择时，则判定616确定是否进行了另一选择。当判定616确定进行了另一选择时，可执行其他处理618。在方框610,614和618之后，以及当没有其他选择时则在判定616之后，判定620确定媒体商店播客交互处理600是否应结束。当判定620确定媒体商店播客交互处理600不应结束时，处理返回到重复方框604以及随后的方框。或者，当判定620确定媒体商店播客交互处理600应结束时，则完成并结束媒体商店播客交互处理600。图7表示根据本发明的一个实施例的集成播客获取处理700的流程图。集成播客获取处理700由客户机设备(例如，如图1所示的客户机设备104)执行。更具体而言，集成播客获取处理700由媒体管理应用(例如，运行在如图1所示的客户机设备104上的媒体管理应用108)执行。更一般而言，媒体管理应用可称为客户机或客户机应用。集成播客获取处理700最初发现702感兴趣播客。通过与媒体商店的交互，如以上参照图6所述，可发现702感兴趣的播客。当发现702了感兴趣播客后，用户或客户机可预订704播客。一旦预订704播客，客户机可至少接收706播客最近片段的数据。尽管客户机将接收其他片段的数据，假定可提交许多片段，最初仅接收最新片段可能更有效和稳健。如后面所述，如果特别需要，用户或客户机将能够请求接收其他更重要的片段。接下来，判定708确定客户机与媒体设备之间是否应实现同步。媒体设备通常事先与客户机相关联。当判定708确定应与媒体设备实现同步时，可将片段数据(对于最新片段)下载710到媒体设备。在一个实施例中，接收的数据包括音频文件(例如，MP3文件或MPEG4文件或AAC文件)以及其元数据。在客户机或客户机设备处，在一个实施例中，可将音频文件存储在文件系统中，并且可将元数据存储在数据库中。在方框710之后，或当不实现与媒体设备的同步时在判定708之后，可对客户机进行配置712以便为了新片段而进行更新。此处，可对于单个播客或成组播客，或对于所有播客设置更新配置。例如，一个配置参数是对于播客更新的检查多么频繁。在方框712之后，完成并结束集成播客获取处理700。有趣的是，在一个实施例中，运行在客户机设备上的单个客户机应用(例如，媒体管理应用)可执行如图7所示的操作。更特别是，客户机应用可发现播客、预订播客，接收播客数据(包括元数据和内容)、管理播客，以及将播客数据传输到媒体设备(例如，如媒体播放器之类的便携式媒体设备)，或从该设备将其删除。此外，在另一实施例中，客户机应用还可包括播客创建或授权功能。该高度集成性使得操作得以改善，以及更易于用户使用，用户将更为满意。图8A表示根据本发明的一个实施例的播客更新处理800的流程图。播客更新处理800通常确定在客户机处何时以及如何对任何播客进行更新，以便获得与播客相关联的任何新片段。播客更新处理800开始于判定802其确定是否要执行播客更新。播客更新例如可基于对于如图7所示更新的配置712进行确定。当判定802确定不执行播客更新时，则推迟播客更新处理800。一旦判定802确定要执行播客更新，则识别804出现有播客预订。此处，假设一般对处在客户机上的一组或所有播客执行播客更新处理800。一旦识别804现有播客预订，则选择804第一个播客。访问808对于所选播客的播客托管者。播客托管者通常是提供RSS播客馈送的第三方服务器。然而，如果媒体商店托管播客的话，播客托管者还可以是媒体商店。接下来，接收810播客任何最新片段的数据。可从播客托管者接收播客更新片段的数据。例如，通过对RSS播客馈送的检查，可识别任何更新的现有片段，然后将其下载。客户机可维护用于表示已接收哪些片段的数据。之后，判定812确定是否有更多播客(即，识别出的播客)要进行更新。当判定812确定有更多播客要进行更新时，播客更新处理800返回到重复方框806以及随后的方框。当判定812确定没有更多播客进行更新时，判定814确定是否应与媒体设备实现同步。当判定814确定应与媒体设备实现同步时，可将片段数据(新片段数据)下载816到媒体设备。在方框816之后，或在不执行同步时判定814之后，播客更新处理800结束。图8B，8C和8D表示与在线媒体商店上播客的呈现相关联的播客基页的屏幕快照。在该示例中，在线媒体商店为iTunes⑧MusicStore,它还提供浏览和搜索播客的功能。图8B表示根据本发明的一个示例性实施例的播客基页820的屏幕快照。源指示器822表示出由在线媒体商店提供播客基页820。选择器824还表示出"podcasts"是所呈现的媒体的类型。突出区域826包含与突出的三个不同播客相关联的图片。播客基页820还包括每日首要下载区828，用于标识每日首要下载的那些播客。播客基页820还包括某些播客分组，例如，诸如NewShows(新表演)830、JustAdded(刚添加)832和featuredpodcasts(特色播客)836的分组。这些分组可通过滚动窗口显示，滚动窗口可根据过渡效应进行过渡(例如，水平过渡)。播客基页820还包括另一突出区域834。一旦选择特定播客，则呈现出播客页。图8C表示根据本发明的一个示例性实施例的播客页838的屏幕快照。播客页838包括元数据区840和片段列表区842。元数据区840包括播客图片844、播客标题846,以及其他元数据信息848(例如，全部片段、类别、语言和版权信息)。另外，还显示出"Subscribe(预订)"按钮850。此外，元数据区840还包括对于播客的描述852。片段列表区842包含可用播客的片段的列表854。列表854中的每个片段包括"GetEpisode(获得片段)"按钮856，以获得相应片段。通过选择"Subscribe"按钮850,用户能够使媒体管理应用预订播客。在该示例中，预订播客无需成本。然而，在其他实施例中，预订播客则可能要付费。通过选择"GetEpisode"按钮856，用户可使得媒体管理应用获得特定片段。图8D表示具有订单确认对话框858的播客页838的屏幕快照，订单确认对话框858允许用户确认他们要预订播客。图8E表示根据本发明的一个示例性实施例的播客可用性页860的屏幕快照。播客可用性页860包括用于表示要在媒体资产列表864中列出播客的指示器862。在媒体资产列表864中列出的播客可包括片段的子列表。在媒体资产列表864中列出的这些播客处在客户机设备上。一般而言，将这些播客事先从合适的托管服务器下载到客户机设备。指示器866可用于可视地标识出所列出的可从在线媒体商店获得的那些播客。例如，指示器866可标识出在在线媒体商店上托管的那些播客。通过选择任何片段，可为用户播放相关联的音频。选择器868表示出正在为用户播放的标题为"AdditionalShopping"的片段，并显示出播客、片段或章的相关图片869。图8F表示根据本发明的另一示例性实施例的播客可用性页870的屏幕快照。播客可用性页870包括类似于如图8E所示的媒体资产列表864的媒体资产列表871。在该示例中，媒体资产列表包括因片段数据未下载到客户机设备而不能进行播放的片段872。在该示例中，将这些片段872增亮显示，且伴有"Get(获得)"按钮874。当选择"Get"按钮874时，将从合适的托管服务器获取相应片段872。一般而言，当对媒体商店提供的或客户机本地可用的播客进行列表时，可采用多种不同方式组织列表。列表组织的一个示例是根据等级将播客分类。对于关于使用媒体商店的等级的附加信息，参见(i)于2005年4月25日申请的题名为"PUBLISHING,BROWSING,RATINGANDPURCHASINGOFGROUPSOFMEDIAITEMS"的美国专利申请No.11/114,914;和(ii)于2005年4月25日申请的题名为"PUBLISHING，BROWSINGANDPURCHASINGOFGROUPSOFMEDIAITEMS，，的美国专利申请No.11/115，0卯。图8G表示根据本发明的另一示例性实施例的播客可用性页876的屏幕快照。在播客可用性页876中列出的播客类似于如图8F所示的播客可用性页870中列出的播客。播客可用性页876示出指示符878,指示符878可视地标识正下载到客户机设备的那些播客片段。此处，所列出的正下载的片段是现有的但在客户机设备上还不存在。一旦开始对这些片段的下载，则显示出指示器878。将片段下载之后，删除指示器878以及任何增亮。如以上所述，在对播客的最初预订之后，需要对播客进行更新以获取新片段。为提高搜索这些更新的效率和智能化，客户机(例如，媒体管理应用)可使用偏好设置以偏重或确定何时执行更新。全局地为所有播客提供这些偏好设置或基于单个播客提供这些偏好设置。例如，偏好设置可表示定期检查新片段(例如，每小时、每天、每周)或只要启动客户机就检查。一旦在客户机设^^处存储了播客片段，就可将其中某些或所有片段拷贝到可操作地与客户机设备相连的便携式媒体播放器。为提高执行这些拷贝(也称为同步)的效率和智能化，客户机(例如，媒体管理应用)可使用偏好设置以便偏重或确定何时执行拷贝(即，自动执行)。可全局地为所有播客提供这些偏好设置或基于单个播客提供这些偏好设置。偏好可根据实现方式而有所变化。偏好的某些示例包括(1)当在客户机设备上已收听到片段时将其删除，(2)当在便携式媒体设备上已收听到片段时将其删除，(3)保留/下栽最近n个片段，(4)保留/下载直至ii个片段，以及(5)基于日期进行保留/下载。在一个示例性实施例中，用户可使用同步偏好屏幕。同步偏好屏幕使得用户能够设置某些同步偏好，以便将播客更新从客户机设备拷贝到便携式媒体设备。特别是，例如，用户可选择(l)对所有播客进行自动更新，(2)仅对所选播客进行自动更新，(3)人工管理播客(即，不进行自动更新)，以及(4)在播放之后从便携式媒体播放器删除播客。可使用的其他标准(未示出)包括下载直至n个片段和/或仅下载还未收听的那些片段。例如，如果用户在客户机设备处收听到特定播客，则有可能不想将该片段下载到便携式媒体设备。注意，通过从便携式媒体播放器删除已收听的那些播客，便携式媒体播放器可仅保留用户还未收听到的那些播客片段。此处，对于已播放播客的删除是自动进行的。在一个实施例中，如果基本播放了所有播客片段，则可认为片段被播放。例如，如果播放了95%的片段，则可认为已播放了该片段。本发明的另一方面关于用于实现播客预订的改进型方法。在一个实施例中，可使用称为播客预订文件的小型便携式电子文件以实现播客预订的便捷化。诚然，在一个实施方式中，通过仅选择或打开播客预订文件(例如，在其上进行双击)，可以以自动方式完全实现预订。图9表示根据本发明的一个实施例的播客预订文件创建处理900的流程图。播客预订文件创建处理900例如通过诸如媒体管理应用之类的客户机(客户机程序)执行。播客预订文件创建处理900最初创建902便携式播客预订文件。便携式播客预订文件是包含用于实现播客预订的信息的电子文件。当创建902了便携式播客预订文件之后，则使904便携式播客预订文件为其他人可用。之后，可按照需要发布便携式播客预订文件，从而用于实现播客预订。在一个实施例中，便携式播客预订文件为包括用于实现播客预订的播客信息的XML文档(或其他标记语言类型文档)。例如，在XML文档内的播客信息至少包括用于播客馈送的馈送URL。另外，播客信息可包括关于播客的其他描述性信息，如标题和描述说明。便携式播客预订文件的代表性示例如下<feedxmlns:it="http://www.ltunes.com/ext/chapters/1.0><ilnkrel=nfeed"href-"itpc:〃foo.com/podcasts/myfeedxmr/>《rtle,Podcast</title><descriptlon>ltalkaboutrandomthlngs.</descriptton></feed>注意，名称为"feed"的链接与指向播客馈送(例如，"myfeed")的URL(馈送URL)相关联。该便携式播客预订文件还包括相关联播客的标题("MyPodcast")和描述说明("Italkaboutrandomthings")。XML格式是使用标签区分文档内不同数据项的标记语言格式。图10表示根据本发明的一个实施例的播客预订文件使用处理1000的流程图。播客预订文件使用处理1000例如由客户机(例如，运行在客户机设备上的媒体管理应用)执行。播客预订文件使用处理1000最初获得1002便携式播客预订文件(PPSF)。在播客预订文件使用处理执行其他处理之前，可获得1002便携式播客预订文件。也就是，判定1004确定是否作出对于打开便携式播客预订文件的请求。例如，打开请求可信号传送OpenURL事件。当判定1004确定未作出对于打开便携式播客预订文件的请求时，播客预订文件使用处理1000仅等待这样的请求。一旦判定1004确定作出了对于打开便携式播客预订文件的请求，则判定1006确定媒体管理应用(MMA)是否正在运行。一般而言，媒体管理应用将在客户机设备上运行。当判定1006确定媒体管理应用目前未运行时，则启动1008媒体管理应用。在方框1008之后，或当确定媒体管理应用正在运行时在判定1006之后，解析1010便携式播客预订文件，以至少获取到相关联播客的馈送URL。在一个实施方式中，对于打开便携式播客预订文件的请求可为URL方案("itpc"或"pcast，，)，其由媒体管理应用识别为要解析且用于预订播客的XML文档。接下来，播客预订文件使用处理1000预订1012相关联播客。在不具有来自媒体管理应用的用户的任何反馈或输入的条件下，可自动执行相关联播客的预订1012。然而，若需要的话，可执行附加处理以显示关于播客的描述性信息和/或询问用户他们是否要预订播客。换而言之，用户可确认他们想要预订相关播客和/或用户可接收关于他们要预订的播客的附加信息(例如，标题、描述说明等)。不管怎样，在方框1012之后，播客预订文件使用处理1000结束。图ll表示根据本发明的一个实施例的播客预订系统1100。播客预订系统IIOO包括客户机设备A1102、客户机设备B1104和播客托管服务器1106，其每一个均与数据网络1008可操作地连接。客户机设备A1102包括媒体管理应用(MMA)1110,客户机设备B1104包括媒体管理应用(MMA)1112。客户机设备A1102创建或获取便携式播客预订文件1114。可将便携式播客预订文件1114传输到一个或多个其他客户机设备。在该示例中，可假定便携式播客预订文件1114由媒体管理应用1110创建。一旦媒体管理应用1110具有便携式播客预订文件，媒体管理应用1110就能够通过数据网络1108传输便携式播客预订文件1114。在该示例中，假设通过数据网络1108将便携式播客预订文件1114传输到客户机设备B1104的该媒体管理应用1112。因此，如图11所示，于客户机设备B1104内的虚线框中显示便携式播客预订文件1114。之后，客户机设备B1104的媒体管理应用1112可使用便携式播客预订文件1114预订相关播客。更特别的是，如果客户机设备B1104的用户要"打开"便携式播客预订文件1114，如通过双击行为，则媒体管理应用1112将"打开"请求处理成向媒体管理应用1112预订播客的请求。在该示例中，播客处于播客托管服务器1106上。特别是，便携式播客预订文件1114将通过媒体管理应用1112进行解析，以获得关于处在播客托管服务器1106上的播客的播客馈送1116的馈送URL。媒体管理应用1112然后能够访问播客馈送1116，以获取以及从而在客户机设备B1104处存储特定播客信息。应该理解，一般而言，可采用多种不同方式将便携式播客预订文件(例如，便携式播客预订文件1114)传输到一个或多个其他客户机设备。例如，可通过电子邮件消息将便携式播客预订文件发送到与客户机设备相关联的用户。然后，用户可打开便携式播客预订文件以激活对播客的预订。在另一示例中，可将便携式播客预订文件与网页上的链接相关联。从而，当网站上的用户选择网页相关联的链接时，可将便携式播客预订文件下载到与用户相关联的客户机设备，之后由媒体管理应用进行处理以用来预订播客。在又一示例中可通过便携式计算机可读介质，如软盘上的闪存卡或光盘，传输便携式播客预订文件。本发明的另一方面关于解除(deactivate)播客预订。更特别的是，本发明的该方面用于解除被认为及不活跃的预订。在一个实施例中，解除处理可自动执行。解除被认为及不活跃的预订的一个优点是，可节约网络带宽。解除被认为及不活跃的预订的另一优点可为，托管播客的托管服务器不会受到对播客很少或不感兴趣用户的客户机应用的下载请求而造成的负担。图12表示根据本发明的一个实施例的播客更新处理1200的流程图。播客更新处理1200例如由客户机(如，媒体管理应用)执行。播客更新处理1200开始于判定1202，其确定是否要执行播客更新。当判定1202确定不执行播客更新时，则播客更新处理1200等待，直至执行播客更新为止。换而言之，当要执行播客更新时，有效调用播客更新处理1200。可通过客户机或客户机用户来请求播客更新。例如，客户机可能定期地自动启动播客更新。另一方面，当判定1202确定要执行播客更新时，则访问1204特定播客的播客馈送(例如，RSS馈送)，以获取该播客的片段信息。然后，基于获取的片段信息，判定1206播客的新片段。在一个实施方式中，获取的片段信息为包含描述特定播客的特性的元数据的XML文件，该特定播客包括播客的各个片段。可对XML文件进行解析，以获得片段信息(例如，片段元数据)。对片段信息的检查可用于识别出，与时间上更早或先前已在客户机处可用的那些片段相对而言的播客新片段。接下来，判定1208确定是否有要下载的播客新片段。此处，新片段可从该播客的托管服务器获得，从而可将其下载到客户机。当判定1208确定有要下载的新片段时，播客更新处理1200判定1210播客是否为不活跃的。当判定1212确定播客活跃时，则将新片段下载1214到客户机。将新片段下载1214之后，以客户机接收了播客更新来完成和结束播客更新处理1200。另一方面，当判定1208确定没有要下载的新片段时，或当判定1212确定播客不活跃时，则在不下载任何新片段的条件下完成和结束播客更新处理1200。图13表示根据本发明的一个实施例的播客活性处理1300的流程图。播客活性处理1300通常用于确定播客是活跃的还是不活跃的。例如，根据本发明的一个实施例，可将播客活性处理1300用作为由如图12所示的判定1210实现的处理。在该实施例中，对于每个(已预订的)播客，都保持有至少一对变量用于判定播客是活跃的还是不活跃的。在该示例性实施例中，变量为片段下载计数和最初片段下载曰期。播客活性处理1300开始于判定1302,其确定播客下载计数是否大于整数N。当判定1302确定片段下载计数大于N时，判定1304确定自最初片段下载的日期起是否超过了M天，其中，M为整数。例如，整数M和N可等于5。当判定1304确定自最初片段下载的日期起超过了M天，则判定1306确定自最初片段下载的日期起客户机是否活跃。当判定1306确定自最初片段下载的日期起客户机就是活跃的，则将播客绘制1308成不活跃。此处，在该实施例中，由于对播客活性处理1300以编程方式确定出播客活性不足，从而将播客绘制1308成不活跃。因此，假定客户机用户很少或不对播客感兴趣。从而，将由如图12所示的播客更新处理1200进行的新片段的下载1214跳过，从而节省网络和服务器资源。另一方面，当判定1302确定片段下载计数不超过N时，或当判定1304确定自最初片段下载的日期起没有超过M天时，或者当判定1306确定自最初片段下载的日期起客户机就不活跃，则将播客绘制1310成活跃。在方框1308和1310之后，完成和结束4番客活性处理1300。图14表示根据本发明的一个实施例的重置活性变量处理1400的流程图。重置活性变量处理1400例如通过运行在客户机设备上的客户机执行。客户机用于在其操作期间在合适时间重置活性变量，以便对以上参照图13所述的播客活性处理1300产生作用。换而言之，在特定时间，可重置播客活性处理1300所使用的活性变量，以便对播客活性处理1300的操作产生影响。例如，进行重置的活性变量可包括片段下载计数或最初片段下载的日期。注意，这些重置变量可直接对播客活性处理1300的判定1302,1304和1306产生影响。重置活性变量处理1400开始于判定1402，其确定是否建立了重置条件。重置条件可采用多种不同方式建立。重置条件可自动启动或由用户启动。在任何情形中，当判定1402确定不存在重置条件时，则重置活性变量处理1400等待这样的条件。换而言之，重置活性变量处理1400开始于当满足合适的重置条件之时。一旦判定1402确定满足合适的重置条件，则重置1404片段下载计数。此处，可将片段下载计数重置1404为零。此外，对最初片段下载的日期进行重置1406。此处，可将最初片段的日期重置1404为当前日期。在方框1406之后，完成和结束重置活性变量处理1400。尽管可采用多种方式建立重置条件，不管是以编程方式还是由用户启动，客户机上发生的事件能够促成重置条件。一般而言，当客户机了解到客户机或客户机用户对播客很感兴趣时以编程方式触发重置条件。表示对播客感兴趣的事件示例有(l)用户播放播客片段，(2)客户机(或便携式媒体播放器)完成对播客片段的播放，以及(3)用户下载播客片段。本发明的另一方面涉及播客的章扩充(chapterenhancement)。章扩充可提供与播客一道使用的改进型用户界面。章扩充通过包含有章信息的播客启动。例如，章信息可采用多种方式显示，以提高重放体验。章信息可包括但不限于标题、图片、url、描述说明(例如，采用富文本，包括嵌入链接)、影视(音频&视频)、艺术家、唱片集和播客预订。所有章信息都是可选的一例如，某些章可具有标题和图片，而其他章可能仅具有标题。播客可承载嵌入到文件(例如，XML文件)中或在播客馈送中承载的章信息。为了将章信息嵌入到文件中，可将m4a文件格式进行扩展以支持附加章信息。根据ISO文件格式对轨信息进行格式化。轨(标记为章轨(chaptertrack))可包含章信息。轨可为名称轨、url轨、图片轨、描述说明轨或其他元数据轨。在任何章的开始处，可改变在用户界面内包含的章信息，以便与章相对应。为了在播客馈送中提供章信息，可对播客(即播客的RSS馈送)进行扩充以包含章相关信息。该章相关信息可由新规定的XML元素(例如，章标签)进行规定。了解这些XML元素的客户机应用，例如，媒体管理应用，可从RSS馈送检索章相关信息，从而在客户机设备(或与客户机设备相关联的便携式媒体设备)处提供扩充用户界面。章相关信息可为文本、音频、图像和/或视频。在客户机应用不了解新规定的章元素的情形中，RSS馈送仍有用，但不具有用户界面扩充。在一个实施例中，新规定的XML元素为(i)段元素，其起到容器元素的作用，用于信号发送段(即，章)；(ii)链接元素一其中一个或多个用于定义与段相关联的多媒体元素(图片、辅助音频、辅助视频)。每个段都可具有多媒体元素起始时间、标题和URL。例如，在起始时间处，显示出标题和多媒体元素。每个段还可包含有用于播客段的其他元数据(例如，作者、轨、相关URL链接)。具有3个章的示例性RSS馈送为<segmentxmlns:it="http:〃www,itunes.com/ext/chapters/1.0><it:starttime:>0</'rt:starttlme><it:tltle:>lntroduction</it:mie><'rt:linkrel-"enclosure"type-"vldeo/JPEG"href="http:〃foo.com/chapter1picture.jpg"/><it:llnkrel-"related"href="http:〃foo.com/infoAt)outChapter1.htmj"/></segm6nt><segmentxm、ns="http://www.itunes.com/ext/podcasts/1.0<it:starttime>0:30</it:starttirne>it:miejMiis.tosegcnent.90e^it.:柳？〉<it:linkrel="enclosure"type-"video"PEG"href="http:〃foo.com,chapter2plcture.jpg"/><it:linkrel-"related"Href="http://foo.com/infoAbouichapter2.htmr/><it:author>SomeGreatB曰nd歌author^<it:track>MyGreatHit</it:track></segment><segmentxmlns="http:〃www.itunes,com/ext/poclcasts/1.0><it:starttlme>0:30</it:starttime><it:title>Muslcsegmentone</it:Htle><it:"nkrel-"enclosure"type=V'deo/JPEG"href="http://foo.com/chapter2picture.jpg"/><it:linkrel-"related"href="http://foo.com/infoAboutChapter2.htmr/><it:linkrel-"feetf'hrefs"itpc:〃foo.com/podcaste〖myfeecl.xmr/><it:author>SomeGreatBand</ft:author><it:track>WlyGreatHit<rt:track></segment>通过提供章信息实现的用户界面扩充(对于客户机应用或便携式媒体设备而言)可包括以下任何示例。作为一个示例，可将章图片显示为与播客的章相关。在播放播客时，章图片自动变化到与当前章相符。另外，章图片还可随着用户在浏览章时从一章跳到(例如，扫过)另一章，而发生变化。另一示例是，当用户对弹出菜单进行选择而选中某一章时，弹出菜单中的每个菜单项都包含章标题以及章图片的缩略图。作为又一示例，当用户选择(例如，点击)章图片时，客户机应用链接(超链接)到章URL。在又一示例中，章信息可随章的变化而有所不同。此处，可在用户界面的多个部分显示出章艺术家、表演、描述说明和其他信息，以便其能够随章的变化而变化。在又一示例中，可将预订链接用作为章信息。如果选择了预订链接，则客户机应用将自动预订播客馈送。在一个实施例中，预订链接能够指向便携式预订文件。尽管上述有数个实施例中强调的媒体资产(或媒体项)是播客，其包括音频项(例如，音频文件或音轨)，但媒体资产并不限于音频项。例如，媒体资产还可涉及视频(例如，影视)或图像(例如，照片)。更普遍而言，还可将播客称为数字多媒体资产。本发明的多个方面、实施例、实现方式或特征可单独使用或按任何组合方式使用。本发明优选通过软件实现，但也可采用硬件或软硬件的组合来实现。还可将本发明表现为计算机可读介质上的计算机可读代码。计算机可读介质是能够存储此后可由计算机系统进行读取的数据的任何数据存储设备。计算机可读介质的示例包括只读存储器、随机存取存储器、CD-ROM、DVD、磁带、光数据存储设备，以及载波。计算机可读介质还可分布在网络连接的计算机系统上，以便分布式存储和执行计算机可读代码。通过以上描述，本发明的许多特征和优点是显而易见的，从而，所附权利要求意在涵盖本发明的所有这些特征和优点。此外，由于本领域技术人员可易于想到许多修改和变化，本发明不应局限于所示和描述的具体结构和操作。因此，可将所有合适修改例和等效方面视为包含在本发明的范围内。权利要求1.一种用于从运行在个人计算机上的客户机应用预订播客的方法，所述方法包括(a)通过客户机应用，从在线媒体商店处可用的多个播客中发现特定播客；(b)从客户机应用预订特定播客；以及(c)随后通过客户机应用获取特定播客的播客元数据和播客媒体内容。2.根据权利要求l所述的方法，其中，客户机应用为媒体管理应用。3.根据权利要求1所述的方法，其中，播客媒体内容涉及特定播客的至少一个片段。4.根据权利要求3所述的方法，其中，所述方法还包括(d)将至少一个片段存储在播客库文件夹中。5.根据权利要求1所述的方法，其中，在线媒体商店具有对于多个播客的描述性信息和访问信息。6.根据权利要求5所述的方法，其中，在所述发现(a)期间可显示出对于一个或多个播客的描述性信息。7.根据权利要求5所述的方法，其中，所述发现(a)包括搜索和浏览中的至少一个。8.根据权利要求5所述的方法，其中，所述发现(a)至少包括浏览在线媒体商店上可用的多个播客。9.根据权利要求8所述的方法，其中，所述浏览包括显示出可进行浏览的流派的列表，其中一个流派为播客流派；接收对播客流派的选择；显示出可用于播客的类别列表；以及接收从类别列表中对类别之一的选择。10.根据权利要去9所述的方法，其中，所述浏览还包括显示出与所选类别相匹配的可用播客的列表。11.根据权利要求9所述的方法，其中，所述浏览还包括显示出对于所选类别可用的子类别的列表；接收从子类别的列表中对子类别之一的选择；以及显示出与所选类别和所选子类别相匹配的可用播客的列表。12.根据权利要求5-11中任一项所述的方法，其中，所述预订(b)使用对于特定播客的访问信息。13.根据权利要求12所述的方法，其中，访问信息至少包括到特定播客的RSS馈送的网络地址。14.根据权利要求l所述的方法，其中，所述方法还包括(d)显示出播客元数据的至少一部分。15.根据权利要求1所述的方法，其中，播客媒体内容涉及特定播客的至少一个片段，以及其中，所述显示(d)显示出使得可获取各片段的至少一个用户界面控制。16.根据权利要求16所述的方法，其中，所述显示(d)显示出多个播客的播客元数据的至少一部分，以及其中，所述显示(d)区分性地显示出本地可用的那些片段和需要下载以便播放的那些片段。17.根据权利要求1-16中任一项所述的方法，其中，在在线媒体商店处可用的多个播客包括由在线媒体商店托管的托管播客，和在线媒体商店未托管的非托管播客，但在线媒体商店存储有涉及非托管播客的元数据。18.根据权利要求l所述的方法，其中，所述方法还包括(d)随后将播客媒体内容的至少一部分和播客元数据的至少一部分拷贝到可操作地连接到个人计算机的便携式媒体设备。19.根据权利要求18所述的方法，其中，播客媒体内容涉及特定播客的至少一个片段，并且其中，将至少一个片段提供作为音频文件。20.根据权利要求18所述的方法，其中，所述拷贝(d)由客户机应用自动执行。21.根据权利要求18所述的方法，其中，所述拷贝(d)是客户机应用与便携式媒体设备之间的同步操作的一部分。22.根据权利要求1-16中任一项所述的方法，其中，当用户对显示给客户机应用的用户的用户界面元素进行了选择时，启动对特定播客的所述预订(b)。23.根据权利要求l所述的方法，其中，播客媒体内容涉及特定播客的至少一个片段，以及其中，所述方法还包括(d)接收特定播客的至少一个片段的播放选择；以及(e)播放特定播客的片段。24.—种计算机可读介质，至少包括用于预订播客的计算机程序代码，所述方法包括用于从在线媒体商店处可用的多个播客中发现特定播客的计算机程序代码；用于预订特定播客的计算机程序代码；以及用于获取特定播客的播客元数据和播客媒体内容的计算机程序代码。25.根据权利要求24所述的计算机可读介质，其中，将播客元数据存储在在线媒体商店处，而不将播客媒体内容存储在媒体商店处。26.—种用于访问播客的系统，包括客户机设备，运行媒体管理应用，所述媒体管理应用用于从具有多个播客的描述性信息和访问信息的在线媒体商店中发现至少一个播客，从在线媒体商店获取至少一个播客，以及将至少一个播客拷贝到便携式媒体播放器。27.根据权利要求26所述的系统，其中，所述媒体管理应用为单个计算机程序。28.根据权利要求27所述的系统，其中，在线媒体商店可托管播客或托管具有可从远程服务器检索的媒体内容的播客的元数据。29.—种用于维护播客的方法，包括更新在客户机设备处的播客数据，以及将播客数据的合适部分拷贝到便携式计算设备。30.根据权利要求29所述的方法，其中，所述更新和拷贝步骤是自动执行的。全文摘要本发明披露了便于使用播客的改进型技术。该改进型技术可涉及创建、发行、托管、访问、预订、管理、传输和/或播放播客。根据一个方面，客户机应用能够用于实现，从多个播客中发现感兴趣的播客，预订感兴趣的播客，以及对感兴趣的播客进行随后的管理。对感兴趣播客的管理可包括在很少需要或不需要与用户交互的条件下获取更新的播客数据。根据另一方面，对客户机应用而言本地可用的某些或全部播客可通过便携式媒体设备进行拷贝(例如，同步化)，以便使播客方便可用，并可通过客户机应用或便携式媒体设备播放。文档编号G06F17/30GK101268460SQ200680021898公开日2008年9月17日申请日期2006年5月8日优先权日2005年5月21日发明者乔纳森·莱福特,伊利斯·M·维罗萨伯,帕亚姆·米拉施迪,戴维·L·纽曼,马克·米勒申请人:苹果公司