[0147] url = ″ http://www.itunes.com/podcasts/everything/AllAboutEverythingEpisode1.mp3″
[0148] length=″4989537″type=″x-audio/mp3″/>
[0149] http://www.itunes.com/podcasts/everything/AllAboutEveryt hingEpisode1.mp3
[0150] guid>
[0151]
Wed,1 Jun 2005 10:21:04 GMT[0152]
Politics[0153] [0154] [0155]
[0156] no[0157] 3:59[0158] politics red blue state
[0159]
[0160]
[0161]
[0162] 由于表演和片段可与类别相联系,可提供改进型用户界面,以便对播客进行类别,并基于类别进行搜索或浏览。
[0163] 图3A和3B表示根据本发明的一个实施例的播客发行处理300的流程图。播客发行处理300由服务器执行,并表示出对于如图2A和2B所示的播客提交处理200的互易方处理。
[0164] 播客发行处理300最初接收302对于所要发行的特定播客的网络地址。例如,可通过客户机用户提供网络地址,然后将其发送到服务器(例如,图2A的方框206和208)。
[0165] 接收到302特定播客的网络地址后,服务器访问304播客馈送(例如,RSS馈送)以获取播客馈送元数据。换而言之,服务器使用该网络地址连接对于特定播客的播客馈送,以获取播客馈送元数据。然后,从播客馈送元数据获得306基本播客元数据。根据一个实现方式,基本播客元数据的获得可涉及对播客馈送元数据的解析。一般而言,播客馈送元数据将包括标签或标记(例如,XML元素),以区分在播客馈送元数据内提供的元数据的不同字段。
[0166] 接下来,创建308播客预览页。在一个实施方式中,播客预览页包括基本播客元数据,并请求附加播客元数据。然后,将播客预览页发送310到客户机。
[0167] 然后,判定312确定是否接收到最终播客元数据提交。当判定312确定未接收到最终播客元数据提交时,播客发行处理300等待这样的提交。另一方面,一旦判定312确定提交了最终播客元数据,则在服务器处存储314发行的播客信息。发行的播客信息至少包括网络地址和最终播客元数据,二者都与特定播客相关联。此时,将特定播客发行到服务器。此外,可对发行的播客信息做索引316,以便实现在服务器处(例如,图1的媒体商店服务器
102)的搜索和/或浏览功能。最后,在服务器(例如,媒体商店)上将发行的播客绘制318成可用。在操作318之后,完成和结束播客发行处理300。
[0168] 在另一实施例中,可将播客发行处理(例如,播客发行处理300)修改成包括认证处理。可使用认证处理对试图发行播客的人进行认证。认证可采用多种不同方式执行。在一个实施方式中,认证可将试图发行的人认证为服务器知道的人(例如,帐户持有人)。在另一实施方式中,认证可根据播客托管者、创建者等对人进行认证。
[0169] 对服务器(例如,媒体商店)上可用的媒体项的浏览或搜索可类似对其他类型媒体资产的搜索那样执行。对于关于对媒体资产进行搜索或浏览的更多细节参见于2004年4月26日
申请的题名为“GRAPHICAL USER INTERFACE FOR BROWSING,SEARCHING AND PRESENTING MEDIA ITEMS”[Att.Dkt.No.:APL1P277X1]的美国
专利申请No.10/832,984,其在此引作参考。然而,对于浏览而言,为有助于有效浏览播客,可为用户显示出具有分级列表的图形用户界面。在一个实施方式中,可选项的第一列表是流派列表。用户可选择表示为“Podcasts”的流派。一旦进行了选择,则将显示出可选项的第二列表。将在第二列表中的可选项表示为“Categories”。Categories表示可将播客分配到的不同类别。然后,根据类别选择,将显示出可选项的第三列表。将在第三列表中的可选项表示为“Subcategories”,从应用上,表示出所选类别的可用子类别。进行了多个选择之后,在媒体资产列表区域显示出与所选类别和所选子类别(如果使用的话)相匹配的那些播客。
[0170] 客户机可显示出应用程序窗口。应用程序窗口可包括第一
子窗口和第二子窗口。第一子窗口包括第一区域、第二区域和第三区域。第一区域可显示出可用流派的列表(流派列表)。当用户在第一区域中显示的流派列表内选择其中一项(即,播客项)之后,可使用与从流派列表选出的流派相关联的播客类别的列表填充第二区域。播客类别列表由远程服务器提供给呈现应用程序窗口的应用程序。当用户选择第二区域的其中一个可用类别之后,可使用与所选类别相关联的子类别的列表填充第三区域。若在第三区域内有子类别的话,则所述子类别是属于所选类别的子类别。当子类别列表具有多个项时,用户可选择其中一项。如果是子类别(如果没有子类别则为类别),一旦用户选中一项,则可使用与类别和子类别(若有的话)相关联的可用播客的列表填充第二子窗口。对于每个播客,可用播客列表可显示出描述性信息。例如,可采用行和列(例如,表格)格式呈现出可用播客列表,其中,各行涉及不同的播客,而列涉及播客名称、艺术家、描述说明和价格。此外,在价格列内,各行可包括“Subscribe”按钮,以便于用户预订特定播客。
[0171] 图4表示根据本发明的一个实施例的认证处理400的流程图。例如可使用认证处理400代替如图3A所示方框310。认证处理400最初确定402用于认证用户(例如,授权发行人)的
电子邮件地址。在一个实施例中,授权用户涉及在服务器或客户机上的帐户持有者。在另一实施例中,可从与要发行的播客相关联的RSS馈送(即,播客数据)获得授权用户。在任意情形中,确定402与授权用户相关联的电子邮件地址。当确定402出电子邮件地址后,创建404与播客预览页具有链接的发行消息。例如,发行消息可向接收者解释假定他们正发行他们的其中一个播客并选择关闭链接以继续发行处理。如果播客的发行未得到授权,则接收者能够取消发行处理。
[0172] 之后,判定408确定从授权用户是否接收到用于继续发行处理的请求。当判定408确定未接收到用于继续发行处理的请求时,认证处理400等待这样的请求。在一个实现方式中,该请求是用于访问播客预览页的请求。用户通过选择发行消息中的链接或将链接拷贝到在客户机处提供的数据输入区域中,可实现该请求。当判定408确定已接收了用于继续发行处理的请求时,将播客预览页发送410到客户机。之后,处理进行到如先前所讨论的播客发行处理300的操作312以及随后的操作。
[0173] 图5A表示根据一个示例性实施例的网络地址提交页500的屏幕快照。网络地址提交页500使用户能够输入到要在媒体商店上发行的现有播客的网络地址,即,馈送URL,在该示例中,媒体商店为iTunes Music Store。馈送URL被输入到文本框502中。在此示例中,输入的馈送URL为:
[0174] “http://www.mygarden.com/gardentalk_rss.xml”
[0175] 图5B表示根据一个示例性实施例的播客预览页520的屏幕快照。在该示例中,进行预览的播客的标题为“Garden Talk”。播客预览页520告知用户播客将如何在媒体商店处呈现。此处,得以预览的播客元数据包括:图片、名称、作者、简短描述、长篇描述、类别和语言。在该示例中,可从播客馈送本身获取进行预览的许多播客元数据。然而,不从播客馈送获取的其他元数据,例如,类别和语言,可由用户进行选择或输入。不管怎样,可允许用户对预览的播客元数据进行编辑。另外,可进行选择,以便用户(发行人)能够表示出播客是否包含明确内容。一旦用户准备好要接受预览的播客元数据,用户就选择“Publish”按钮。
[0176] 一旦发行了播客,播客就在媒体商店(在线媒体商店)上变为可得到的。媒体商店可托管或不托管播客。如果媒体商店存储了所有或大部分播客内容,则可考虑由媒体商店托管播客。另一方面,如果媒体商店仅维护播客的元数据,则媒体商店就托管播客。当媒体服务器不托管播客时,第三方服务器可托管播客,且媒体商店适当地访问播客馈送以获取它所需的任何数据。客户机将从托管服务器访问播客馈送以获取其要进行本地存储的播客数据。因此,在一种情形中,媒体商店保存有播客内容,在另一情形中,媒体商店不保存播客内容。
[0177] 可将媒体商店配置成可在媒体商店上搜索或浏览播客。搜索或浏览功能的运作可类似于在在线音乐商店上搜索唱片集。然而,在播客的情形中,搜索或浏览操作是针对发行到媒体商店的播客。一般而言,对于音乐来讲,通过包括艺术家、唱片集和歌曲的分级结构实现浏览。在播客的情形中,必然的结果是通过包括播客(或播客类别)、表演和片段的分级结构实现。
[0178] 媒体商店还可将播客组成不同的类别,以便于用户通过与媒体商店的交互找到它们。类别的示例包括:Arts&Entertainment(艺术欣赏)、Biography and Memoir(传记与回忆录)、Business(商业)、Classics(名著)、Comedy(喜剧)、Drama & Poetry(戏剧与诗歌)、Fiction(小说)、History(历史)、Kids&Young Adults(儿童&青年、成人作品)、Languages(语言)、Mystery(探秘)和News(新闻)。
[0179] 再者,发行到媒体商店的的某些播客可在媒体商店的特殊页上得以突出表示。例如,可使用诸如随机选择、分等级、最活跃下载、倡议等各种标准,将某些播客与其他相比得以突出表示。同样,可对最近媒体商店上可获得的“new shows(新表演)”或“just added(刚添加的)”表演进行突出表示。后面,图8B给出了媒体商店提供的网页示例,其中突出表示了某些播客。
[0180] 图6表示根据本发明的一个实施例的媒体商店播客交互处理600的流程图。媒体商店播客交互处理600最初访问602媒体商店。然后,在媒体商店,用户可导航604到感兴趣的播客。导航可采用多种不同形式。导航的一个示例是搜索处理。导航的另一示例是浏览处理。导航的又一示例是网络地址的人工级次输入(manual next entry)(例如,RSS馈送URL)。无论导航如何进行,一旦识别出感兴趣的播客,就绘制606出感兴趣播客的播客页。可在与客户机设备(例如,如图1所示的客户机设备104)相关联的显示器(显示屏)上,绘制606出播客页。播客页可包括关于播客的信息(例如,元数据),其包括播客、图片和片段信息的描述。播客页还可用于实现预订播客或获得特定片段。此外,播客页可允许用户分不同级别。播客页还可提供便于用户报告某种事宜的链接。
[0181] 绘制606出播客页之后,客户机设备(客户机)的用户可与播客页进行交互,从而进行多种不同选择。这些选择可启动在客户机设备处的操作。与播客相关联的两个特定操作是(1)预订播客,以及(2)下载播客的特定片段。
[0182] 判定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。
[0183] 图7表示根据本发明的一个实施例的集成播客获取处理700的流程图。集成播客获取处理700由客户机设备(例如,如图1所示的客户机设备104)执行。更具体而言,集成播客获取处理700由媒体管理应用(例如,运行在如图1所示的客户机设备104上的媒体管理应用108)执行。更一般而言,媒体管理应用可称为客户机或客户机应用。
[0184] 集成播客获取处理700最初发现702感兴趣播客。通过与媒体商店的交互,如以上参照图6所述,可发现702感兴趣的播客。当发现702了感兴趣播客后,用户或客户机可预订704播客。一旦预订704播客,客户机可至少接收706播客最近片段的数据。尽管客户机将接收其他片段的数据,假定可提交许多片段,最初仅接收最新片段可能更有效和稳健。如后面所述,如果特别需要,用户或客户机将能够请求接收其他更重要的片段。
[0185] 接下来,判定708确定客户机与媒体设备之间是否应实现同步。媒体设备通常事先与客户机相关联。当判定708确定应与媒体设备实现同步时,可将片段数据(对于最新片段)下载710到媒体设备。在一个实施例中,接收的数据包括音频文件(例如,MP3文件或MPEG4文件或AAC文件)以及其元数据。在客户机或客户机设备处,在一个实施例中,可将音频文件存储在文件系统中,并且可将元数据存储在数据库中。在方框710之后,或当不实现与媒体设备的同步时在判定708之后,可对客户机进行配置712以便为了新片段而进行更新。此处,可对于单个播客或成组播客,或对于所有播客设置更新配置。例如,一个配置参数是对于播客更新的检查多么频繁。在方框712之后,完成并结束集成播客获取处理700。
[0186] 有趣的是,在一个实施例中,运行在客户机设备上的单个客户机应用(例如,媒体管理应用)可执行如图7所示的操作。更特别是,客户机应用可发现播客、预订播客,接收播客数据(包括元数据和内容)、管理播客,以及将播客数据传输到媒体设备(例如,如媒体播放器之类的便携式媒体设备),或从该设备将其删除。此外,在另一实施例中,客户机应用还可包括播客创建或授权功能。该高度集成性使得操作得以改善,以及更易于用户使用,用户将更为满意。
[0187] 图8A表示根据本发明的一个实施例的播客更新处理800的流程图。播客更新处理800通常确定在客户机处何时以及如何对任何播客进行更新,以便获得与播客相关联的任何新片段。
[0188] 播客更新处理800开始于判定802其确定是否要执行播客更新。播客更新例如可基于对于如图7所示更新的配置712进行确定。当判定802确定不执行播客更新时,则推迟播客更新处理800。一旦判定802确定要执行播客更新,则识别804出现有播客预订。此处,假设一般对处在客户机上的一组或所有播客执行播客更新处理800。一旦识别804现有播客预订,则选择804第一个播客。访问808对于所选播客的播客托管者。播客托管者通常是提供RSS播客馈送的第三方服务器。然而,如果媒体商店托管播客的话,播客托管者还可以是媒体商店。
[0189] 接下来,接收810播客任何最新片段的数据。可从播客托管者接收播客更新片段的数据。例如,通过对RSS播客馈送的检查,可识别任何更新的现有片段,然后将其下载。客户机可维护用于表示已接收哪些片段的数据。
[0190] 之后,判定812确定是否有更多播客(即,识别出的播客)要进行更新。当判定812确定有更多播客要进行更新时,播客更新处理800返回到重复方框806以及随后的方框。当判定812确定没有更多播客进行更新时,判定814确定是否应与媒体设备实现同步。
当判定814确定应与媒体设备实现同步时,可将片段数据(新片段数据)下载816到媒体设备。在方框816之后,或在不执行同步时判定814之后,播客更新处理800结束。
[0191] 图8B,8C和8D表示与在线媒体商店上播客的呈现相关联的播客基页的屏幕快照。在该示例中,在线媒体商店为iTunes MusicStore,它还提供浏览和搜索播客的功能。
[0192] 图8B表示根据本发明的一个示例性实施例的播客基页820的屏幕快照。源指示器822表示出由在线媒体商店提供播客基页820。选择器824还表示出“podcasts”是所呈现的媒体的类型。突出区域826包含与突出的三个不同播客相关联的图片。播客基页820还包括每日首要下载区828,用于标识每日首要下载的那些播客。播客基页820还包括某些播客分组,例如,诸如New Shows(新表演)830、Just Added(刚添加)832和featured podcasts(特色播客)836的分组。这些分组可通过滚动窗口显示,滚动窗口可根据过渡效应进行过渡(例如,
水平过渡)。播客基页820还包括另一突出区域834。
[0193] 一旦选择特定播客,则呈现出播客页。图8C表示根据本发明的一个示例性实施例的播客页838的屏幕快照。播客页838包括元数据区840和片段列表区842。元数据区840包括播客图片844、播客标题846,以及其他元数据信息848(例如,全部片段、类别、语言和
版权信息)。另外,还显示出“Subscribe(预订)”按钮850。此外,元数据区840还包括对于播客的描述852。片段列表区842包含可用播客的片段的列表854。列表854中的每个片段包括“Get Episode(获得片段)”按钮856,以获得相应片段。通过选择“Subscribe”按钮850,用户能够使媒体管理应用预订播客。在该示例中,预订播客无需成本。然而,在其他实施例中,预订播客则可能要付费。通过选择“GetEpisode”按钮856,用户可使得媒体管理应用获得特定片段。
[0194] 图8D表示具有订单确认对话框858的播客页838的屏幕快照,订单确认对话框858允许用户确认他们要预订播客。
[0195] 图8E表示根据本发明的一个示例性实施例的播客可用性页860的屏幕快照。播客可用性页860包括用于表示要在媒体资产列表864中列出播客的指示器862。在媒体资产列表864中列出的播客可包括片段的子列表。在媒体资产列表864中列出的这些播客处在客户机设备上。一般而言,将这些播客事先从合适的托管服务器下载到客户机设备。指示器866可用于可视地标识出所列出的可从在线媒体商店获得的那些播客。例如,指示器866可标识出在在线媒体商店上托管的那些播客。通过选择任何片段,可为用户播放相关联的音频。选择器868表示出正在为用户播放的标题为“Additional Shopping”的片段,并显示出播客、片段或章的相关图片869。
[0196] 图8F表示根据本发明的另一示例性实施例的播客可用性页870的屏幕快照。播客可用性页870包括类似于如图8E所示的媒体资产列表864的媒体资产列表871。在该示例中,媒体资产列表包括因片段数据未下载到客户机设备而不能进行播放的片段872。在该示例中,将这些片段872增亮显示,且伴有“Get(获得)”按钮874。当选择“Get”按钮874时,将从合适的托管服务器获取相应片段872。
[0197] 一般而言,当对媒体商店提供的或客户机本地可用的播客进行列表时,可采用多种不同方式组织列表。列表组织的一个示例是根据等级将播客分类。对于关于使用媒体商店的等级的附加信息,参见(i)于2005年4月25日申请的题名为“PUBLISHING,BROWSING,RATING AND PURCHASING OF GROUPS OF MEDIA ITEMS”的美国专利申请No.11/114,914;和(ii)于2005年4月25日申请的题名为“PUBLISHING,BROWSING AND PURCHASING OFGROUPS OF MEDIA ITEMS”的美国专利申请No.11/115,090。
[0198] 图8G表示根据本发明的另一示例性实施例的播客可用性页876的屏幕快照。在播客可用性页876中列出的播客类似于如图8F所示的播客可用性页870中列出的播客。播客可用性页876示出指示符878,指示符878可视地标识正下载到客户机设备的那些播客片段。此处,所列出的正下载的片段是现有的但在客户机设备上还不存在。一旦开始对这些片段的下载,则显示出指示器878。将片段下载之后,删除指示器878以及任何增亮。
[0199] 如以上所述,在对播客的最初预订之后,需要对播客进行更新以获取新片段。为提高搜索这些更新的效率和智能化,客户机(例如,媒体管理应用)可使用偏好设置以偏重或确定何时执行更新。全局地为所有播客提供这些偏好设置或基于单个播客提供这些偏好设置。例如,偏好设置可表示定期检查新片段(例如,每小时、每天、每周)或只要启动客户机就检查。
[0200] 一旦在客户机设备处存储了播客片段,就可将其中某些或所有片段拷贝到可操作地与客户机设备相连的便携式媒体播放器。为提高执行这些拷贝(也称为同步)的效率和智能化,客户机(例如,媒体管理应用)可使用偏好设置以便偏重或确定何时执行拷贝(即,自动执行)。可全局地为所有播客提供这些偏好设置或基于单个播客提供这些偏好设置。偏好可根据实现方式而有所变化。偏好的某些示例包括:(1)当在客户机设备上已收听到片段时将其删除,(2)当在便携式媒体设备上已收听到片段时将其删除,(3)保留/下载最近n个片段,(4)保留/下载直至n个片段,以及(5)基于日期进行保留/下载。
[0201] 在一个示例性实施例中,用户可使用同步偏好屏幕。同步偏好屏幕使得用户能够设置某些同步偏好,以便将播客更新从客户机设备拷贝到便携式媒体设备。特别是,例如,用户可选择:(1)对所有播客进行自动更新,(2)仅对所选播客进行自动更新,(3)人工管理播客(即,不进行自动更新),以及(4)在播放之后从便携式媒体播放器删除播客。可使用的其他标准(未示出)包括下载直至n个片段和/或仅下载还未收听的那些片段。例如,如果用户在客户机设备处收听到特定播客,则有可能不想将该片段下载到便携式媒体设备。
[0202] 注意,通过从便携式媒体播放器删除已收听的那些播客,便携式媒体播放器可仅保留用户还未收听到的那些播客片段。此处,对于已播放播客的删除是自动进行的。在一个实施例中,如果基本播放了所有播客片段,则可认为片段被播放。例如,如果播放了95%的片段,则可认为已播放了该片段。
[0203] 本发明的另一方面关于用于实现播客预订的改进型方法。在一个实施例中,可使用称为播客预订文件的小型便携式电子文件以实现播客预订的便捷化。诚然,在一个实施方式中,通过仅选择或打开播客预订文件(例如,在其上进行双击),可以以自动方式完全实现预订。
[0204] 图9表示根据本发明的一个实施例的播客预订文件创建处理900的流程图。播客预订文件创建处理900例如通过诸如媒体管理应用之类的客户机(客户机程序)执行。播客预订文件创建处理900最初创建902便携式播客预订文件。便携式播客预订文件是包含用于实现播客预订的信息的电子文件。当创建902了便携式播客预订文件之后,则使904便携式播客预订文件为其他人可用。之后,可按照需要发布便携式播客预订文件,从而用于实现播客预订。
[0205] 在一个实施例中,便携式播客预订文件为包括用于实现播客预订的播客信息的XML文档(或其他
标记语言类型文档)。例如,在XML文档内的播客信息至少包括用于播客馈送的馈送URL。另外,播客信息可包括关于播客的其他描述性信息,如标题和描述说明。便携式播客预订文件的代表性示例如下:
[0206] [0207] [0208] My Podcast
[0209] l talk about random thlngs.[0210]
[0211] 注意,名称为“feed”的链接与指向播客馈送(例如,“myfeed”)的URL(馈送URL)相关联。该便携式播客预订文件还包括相关联播客的标题(“My Podcast”)和描述说明(“I talk about random things”)。XML格式是使用标签区分文档内不同数据项的标记语言格式。
[0212] 图10表示根据本发明的一个实施例的播客预订文件使用处理1000的流程图。播客预订文件使用处理1000例如由客户机(例如,运行在客户机设备上的媒体管理应用)执行。
[0213] 播客预订文件使用处理1000最初获得1002便携式播客预订文件(PPSF)。在播客预订文件使用处理执行其他处理之前,可获得1002便携式播客预订文件。也就是,判定1004确定是否作出对于打开便携式播客预订文件的请求。例如,打开请求可
信号传送OpenURL事件。当判定1004确定未作出对于打开便携式播客预订文件的请求时,播客预订文件使用处理1000仅等待这样的请求。
[0214] 一旦判定1004确定作出了对于打开便携式播客预订文件的请求,则判定1006确定媒体管理应用(MMA)是否正在运行。一般而言,媒体管理应用将在客户机设备上运行。当判定1006确定媒体管理应用目前未运行时,则启动1008媒体管理应用。在方框1008之后,或当确定媒体管理应用正在运行时在判定1006之后,解析1010便携式播客预订文件,以至少获取到相关联播客的馈送URL。在一个实施方式中,对于打开便携式播客预订文件的请求可为URL方案(“itpc”或“pcast”),其由媒体管理应用识别为要解析且用于预订播客的XML文档。
[0215] 接下来,播客预订文件使用处理1000预订1012相关联播客。在不具有来自媒体管理应用的用户的任何反馈或输入的条件下,可自动执行相关联播客的预订1012。然而,若需要的话,可执行附加处理以显示关于播客的描述性信息和/或询问用户他们是否要预订播客。换而言之,用户可确认他们想要预订相关播客和/或用户可接收关于他们要预订的播客的附加信息(例如,标题、描述说明等)。不管怎样,在方框1012之后,播客预订文件使用处理1000结束。
[0216] 图11表示根据本发明的一个实施例的播客预订系统1100。播客预订系统1100包括客户机设备A1102、客户机设备B1104和播客托管服务器1106,其每一个均与数据网络1008可操作地连接。客户机设备A1102包括媒体管理应用(MMA)1110,客户机设备B1104包括媒体管理应用(MMA)1112。客户机设备A1102创建或获取便携式播客预订文件1114。
可将便携式播客预订文件1114传输到一个或多个其他客户机设备。在该示例中,可假定便携式播客预订文件1114由媒体管理应用1110创建。
[0217] 一旦媒体管理应用1110具有便携式播客预订文件,媒体管理应用1110就能够通过数据网络1108传输便携式播客预订文件1114。在该示例中,假设通过数据网络1108将便携式播客预订文件1114传输到客户机设备B1104的该媒体管理应用1112。因此,如图11所示,于客户机设备B1104内的虚线框中显示便携式播客预订文件1114。
[0218] 之后,客户机设备B1104的媒体管理应用1112可使用便携式播客预订文件1114预订相关播客。更特别的是,如果客户机设备B1104的用户要“打开”便携式播客预订文件1114,如通过双击行为,则媒体管理应用1112将“打开”请求处理成向媒体管理应用1112预订播客的请求。在该示例中,播客处于播客托管服务器1106上。特别是,便携式播客预订文件1114将通过媒体管理应用1112进行解析,以获得关于处在播客托管服务器1106上的播客的播客馈送1116的馈送URL。媒体管理应用1112然后能够访问播客馈送1116,以获取以及从而在客户机设备B1104处存储特定播客信息。
[0219] 应该理解,一般而言,可采用多种不同方式将便携式播客预订文件(例如,便携式播客预订文件1114)传输到一个或多个其他客户机设备。例如,可通过电子邮件消息将便携式播客预订文件发送到与客户机设备相关联的用户。然后,用户可打开便携式播客预订文件以激活对播客的预订。在另一示例中,可将便携式播客预订文件与网页上的链接相关联。从而,当网站上的用户选择网页相关联的链接时,可将便携式播客预订文件下载到与用户相关联的客户机设备,之后由媒体管理应用进行处理以用来预订播客。在又一示例中可通过便携式计算机可读介质,如
软盘上的闪存卡或光盘,传输便携式播客预订文件。
[0220] 本发明的另一方面关于解除(deactivate)播客预订。更特别的是,本发明的该方面用于解除被认为及不活跃的预订。在一个实施例中,解除处理可自动执行。解除被认为及不活跃的预订的一个优点是,可节约网络带宽。解除被认为及不活跃的预订的另一优点可为,托管播客的托管服务器不会受到对播客很少或不感兴趣用户的客户机应用的下载请求而造成的负担。
[0221] 图12表示根据本发明的一个实施例的播客更新处理1200的流程图。播客更新处理1200例如由客户机(如,媒体管理应用)执行。
[0222] 播客更新处理1200开始于判定1202,其确定是否要执行播客更新。当判定1202确定不执行播客更新时,则播客更新处理1200等待,直至执行播客更新为止。换而言之,当要执行播客更新时,有效调用播客更新处理1200。可通过客户机或客户机用户来请求播客更新。例如,客户机可能定期地自动启动播客更新。
[0223] 另一方面,当判定1202确定要执行播客更新时,则访问1204特定播客的播客馈送(例如,RSS馈送),以获取该播客的片段信息。然后,基于获取的片段信息,判定1206播客的新片段。在一个实施方式中,获取的片段信息为包含描述特定播客的特性的元数据的XML文件,该特定播客包括播客的各个片段。可对XML文件进行解析,以获得片段信息(例如,片段元数据)。对片段信息的检查可用于识别出,与时间上更早或先前已在客户机处可用的那些片段相对而言的播客新片段。
[0224] 接下来,判定1208确定是否有要下载的播客新片段。此处,新片段可从该播客的托管服务器获得,从而可将其下载到客户机。当判定1208确定有要下载的新片段时,播客更新处理1200判定1210播客是否为不活跃的。当判定1212确定播客活跃时,则将新片段下载1214到客户机。将新片段下载1214之后,以客户机接收了播客更新来完成和结束播客更新处理1200。另一方面,当判定1208确定没有要下载的新片段时,或当判定1212确定播客不活跃时,则在不下载任何新片段的条件下完成和结束播客更新处理1200。
[0225] 图13表示根据本发明的一个实施例的播客活性处理1300的流程图。播客活性处理1300通常用于确定播客是活跃的还是不活跃的。例如,根据本发明的一个实施例,可将播客活性处理1300用作为由如图12所示的判定1210实现的处理。在该实施例中,对于每个(已预订的)播客,都保持有至少一对变量用于判定播客是活跃的还是不活跃的。在该示例性实施例中,变量为片段下载计数和最初片段下载日期。
[0226] 播客活性处理1300开始于判定1302,其确定播客下载计数是否大于整数N。当判定1302确定片段下载计数大于N时,判定1304确定自最初片段下载的日期起是否超过了M天,其中,M为整数。例如,整数M和N可等于5。当判定1304确定自最初片段下载的日期起超过了M天,则判定1306确定自最初片段下载的日期起客户机是否活跃。当判定1306确定自最初片段下载的日期起客户机就是活跃的,则将播客绘制1308成不活跃。此处,在该实施例中,由于对播客活性处理1300以编程方式确定出播客活性不足,从而将播客绘制1308成不活跃。因此,假定客户机用户很少或不对播客感兴趣。从而,将由如图12所示的播客更新处理1200进行的新片段的下载1214跳过,从而节省网络和服务器资源。
[0227] 另一方面,当判定1302确定片段下载计数不超过N时,或当判定1304确定自最初片段下载的日期起没有超过M天时,或者当判定1306确定自最初片段下载的日期起客户机就不活跃,则将播客绘制1310成活跃。在方框1308和1310之后,完成和结束播客活性处理1300。
[0228] 图14表示根据本发明的一个实施例的重置活性变量处理1400的流程图。重置活性变量处理1400例如通过运行在客户机设备上的客户机执行。客户机用于在其操作期间在合适时间重置活性变量,以便对以上参照图13所述的播客活性处理1300产生作用。换而言之,在特定时间,可重置播客活性处理1300所使用的活性变量,以便对播客活性处理1300的操作产生影响。例如,进行重置的活性变量可包括片段下载计数或最初片段下载的日期。注意,这些重置变量可直接对播客活性处理1300的判定1302,1304和1306产生影响。
[0229] 重置活性变量处理1400开始于判定1402,其确定是否建立了重置条件。重置条件可采用多种不同方式建立。重置条件可自动启动或由用户启动。在任何情形中,当判定1402确定不存在重置条件时,则重置活性变量处理1400等待这样的条件。换而言之,重置活性变量处理1400开始于当满足合适的重置条件之时。一旦判定1402确定满足合适的重置条件,则重置1404片段下载计数。此处,可将片段下载计数重置1404为零。此外,对最初片段下载的日期进行重置1406。此处,可将最初片段的日期重置1404为当前日期。在方框1406之后,完成和结束重置活性变量处理1400。
[0230] 尽管可采用多种方式建立重置条件,不管是以编程方式还是由用户启动,客户机上发生的事件能够促成重置条件。一般而言,当客户机了解到客户机或客户机用户对播客很感兴趣时以编程方式触发重置条件。表示对播客感兴趣的事件示例有:(1)用户播放播客片段,(2)客户机(或便携式媒体播放器)完成对播客片段的播放,以及(3)用户下载播客片段。
[0231] 本发明的另一方面涉及播客的章扩充(chapter enhancement)。章扩充可提供与播客一道使用的改进型用户界面。章扩充通过包含有章信息的播客启动。例如,章信息可采用多种方式显示,以提高重放体验。
[0232] 章信息可包括但不限于:标题、图片、url、描述说明(例如,采用富文本,包括嵌入链接)、影视(音频&视频)、艺术家、唱片集和播客预订。所有章信息都是可选的—例如,某些章可具有标题和图片,而其他章可能仅具有标题。
[0233] 播客可承载嵌入到文件(例如,XML文件)中或在播客馈送中承载的章信息。
[0234] 为了将章信息嵌入到文件中,可将m4a文件格式进行扩展以支持附加章信息。根据ISO文件格式对轨信息进行格式化。轨(标记为章轨(chapter track))可包含章信息。轨可为名称轨、url轨、图片轨、描述说明轨或其他元数据轨。在任何章的开始处,可改变在用户界面内包含的章信息,以便与章相对应。
[0235] 为了在播客馈送中提供章信息,可对播客(即播客的RSS馈送)进行扩充以包含章相关信息。该章相关信息可由新规定的XML元素(例如,章标签)进行规定。了解这些XML元素的客户机应用,例如,媒体管理应用,可从RSS馈送检索章相关信息,从而在客户机设备(或与客户机设备相关联的便携式媒体设备)处提供扩充用户界面。章相关信息可为文本、音频、图像和/或视频。在客户机应用不了解新规定的章元素的情形中,RSS馈送仍有用,但不具有用户界面扩充。
[0236] 在一个实施例中,新规定的XML元素为:(i)段元素,其起到容器元素的作用,用于信号发送段(即,章);(ii)链接元素—其中一个或多个用于定义与段相关联的多媒体元素(图片、辅助音频、辅助视频)。每个段都可具有多媒体元素起始时间、标题和URL。例如,在起始时间处,显示出标题和多媒体元素。每个段还可包含有用于播客段的其他元数据(例如,作者、轨、相关URL链接)。
[0237] 具有3个章的示例性RSS馈送为:
[0238] [0239] 0
[0240] lntroduction
[0241]
[0242]
[0243]
[0244] [0245] 0:30
[0246] Music segmentone
[0247]
[0248]
[0249] Some Great Band
[0250] My Great Hit
[0251]
[0252] [0253] 0:30
[0254] Muslc segment one
[0255]
[0256]
[0257]
[0258] Some Great Band
[0259] My Great Hit
[0260]
[0261] 通过提供章信息实现的用户界面扩充(对于客户机应用或便携式媒体设备而言)可包括以下任何示例。作为一个示例,可将章图片显示为与播客的章相关。在播放播客时,章图片自动变化到与当前章相符。另外,章图片还可随着用户在浏览章时从一章跳到(例如,扫过)另一章,而发生变化。另一示例是,当用户对弹出菜单进行选择而选中某一章时,弹出菜单中的每个菜单项都包含章标题以及章图片的
缩略图。作为又一示例,当用户选择(例如,点击)章图片时,客户机应用链接(超链接)到章URL。在又一示例中,章信息可随章的变化而有所不同。此处,可在用户界面的多个部分显示出章艺术家、表演、描述说明和其他信息,以便其能够随章的变化而变化。在又一示例中,可将预订链接用作为章信息。如果选择了预订链接,则客户机应用将自动预订播客馈送。在一个实施例中,预订链接能够指向便携式预订文件。
[0262] 尽管上述有数个实施例中强调的媒体资产(或媒体项)是播客,其包括音频项(例如,音频文件或音轨),但媒体资产并不限于音频项。例如,媒体资产还可涉及视频(例如,影视)或图像(例如,照片)。更普遍而言,还可将播客称为数字多媒体资产。
[0263] 本发明的多个方面、实施例、实现方式或特征可单独使用或按任何组合方式使用。
[0264] 本发明优选通过
软件实现,但也可采用
硬件或软硬件的组合来实现。还可将本发明表现为计算机可读介质上的计算机可读代码。计算机可读介质是能够存储此后可由
计算机系统进行读取的数据的任何数据存储设备。计算机可读介质的示例包括只读
存储器、
随机存取存储器、CD-ROM、DVD、磁带、光数据存储设备,以及载波。计算机可读介质还可分布在网络连接的计算机系统上,以便分布式存储和执行计算机可读代码。
[0265] 通过以上描述,本发明的许多特征和优点是显而易见的,从而,所附
权利要求意在涵盖本发明的所有这些特征和优点。此外,由于本领域技术人员可易于想到许多修改和变化,本发明不应局限于所示和描述的具体结构和操作。因此,可将所有合适修改例和等效方面视为包含在本发明的范围内。