CN102187338B - 基于相似性数据的播放列表产生系统和方法 - Google Patents

Abstract

公开了用于至少部分地基于由若干程序参与者提供的媒体库库存信息，便于实现程序参与者的媒体播放列表产生的方法和设备。个人参与的系统或程序是在线媒体商店。决定成为程序参与者的这些个人对至少部分地基于从程序的其它参与者群体得出的数据组织、维护和播放其音乐感兴趣，这些其它参与者在其库中具有相似或相同的音乐。为了成为程序参与者，个人音乐持有者必须发送，并且在线音乐商店接收，表示程序参与者的媒体库存的数据。该数据通常包含当前包含在参与者媒体库内的媒体项目个体的标识数据，而不考虑媒体项目个体的来源。系统或程序确定媒体项目个体对在不同程序参与者的媒体库内共同出现的发生率。基于该确定，基于所确定的不同程序参与者的媒体库内共同出现的发生率，在媒体项目个体对之间分配相似性评估。

Description

基于相似性数据的播放列表产生系统和方法

与相关申请的交叉参考

本申请要求全部于2008年9月30日提交的序列号为No.12/242,728、No.12/242,735、No.12/242,758和No.12/242,768的美国专利申请的优先权，并且要求于2008年9月8日提交的题为“SYSTEM AND METHODFOR PLAYLIST GENERATION BASED ON SIMILARITY DATA”的美国临时专利申请No.61/095,289的权益；通过引用将它们全部明确地全文结合在此。

技术领域

本公开涉及媒体相似性数据，并且更具体地，涉及基于媒体相似性数据产生媒体播放列表。

背景技术

定义诸如消费产品的物品之间的关系早就被认为是有价值的任务。最早的例子是商标，商标给消费者提供了这样的期望基础：即，制作消费者已经拥有的某一种产品的同一公司的另一种产品将达到类似标准。当前，相似性关系已经发展为远远超出简单的品牌名称。某些商店使用相似性数据以便建议用户购买或至少考虑新的项目。这些商店跟踪用户数据，以便确定用户倾向于在相同的购物会话内观看哪些产品或相同用户通常购买哪些产品。出于这个目的使用相似性数据的系统识别每个文件内的特征，并且将那些文件识别为是相似的。

产生相似性数据的这些方法中的每个方法在产生最可能的相似性数据或最大可能地使用这种数据方面存在不足。产生相似性数据的已有方法的一种不足是常规的相似性数据仅仅基于新的购买决策。商店不关心用户已经拥有了什么，即使该信息可能是用户将来想要什么的最可靠的指示符。

随着数字音频播放器的到来，人们正在积累大量的数字媒体库。在许多情况下，个体媒体库包括从诸如CD、SACD和DVD-A之类的物理媒体添加的歌曲。随着ITUNES商店和其它在线媒体提供商的引入，更多的人加入了数字媒体的在线购买，从2003年4月到2008年6月超过50亿歌曲的销售就证明了这一点。在数字音频播放器已经允许人们在几乎任何地方欣赏其媒体的同时，越来越难以有效地管理不断增长的媒体库。以音乐为例，播放列表是有效管理和过滤某些歌曲的一种方法。各种数字媒体播放器允许通过选择用于顺序回放的歌曲组来创建播放列表。

手工形成播放列表通常涉及搜索长的媒体列表以便找到适当的歌曲、选择所希望的歌曲以及希望忽略不希望的歌曲的烦琐处理过程。

还可以基于公共音乐轨迹属性，诸如流派、歌手、和专集等，自动产生音乐播放列表。这些自动产生的播放列表，虽然能被简单和快速地创建，但是不精细地描绘了播放列表。这种播放列表通常包括过多和/或不足。另外，这些自动方法假设所有相关轨迹属性可以获得，并且对于每段媒体都是精确的。产生自动播放列表的一种方法被称为“智能”播放列表。智能播放列表允许用户指定搜索准则，将匹配搜索准则的歌曲添加到播放列表，并且当歌曲满足或不满足该准则时自动更新播放列表。智能播放列表是管理媒体库的强有力的工具。然而，即使是智能播放列表也受到用户对音乐的熟悉程度、库和制作有效的智能播放列表查询的能力的限制。用户可能不熟悉一种音乐风格。这种不熟悉性可能导致排除相关歌手或歌曲。用户的库可能不完整，从而导致完全的智能播放列表中的空缺。用户可能不能足够宽地制作智能播放列表查询以便包括所有所希望的歌曲。验证智能播放列表包括所有预期歌曲通常可比最初手工产生播放列表更烦琐。

常规媒体播放列表产生的每种方法的主要缺点是确定哪些媒体项目彼此相似。当手工制作播放列表时，用户负责抽取一个媒体项目和另一个媒体项目之间的相似性。自动播放列表产生器依赖建立播放列表的准则，但是这些准则通常太宽泛。同一作者、歌手或甚至同一类型或流派的媒体通常没有相似到足以产生所希望的播放列表的程度。智能播放列表试图基于媒体的更详细的特征来解决这些问题中的多个问题，但是它们不考虑人的喜好，而人的喜好是不容易定义的。

随着媒体库的增长以及数字媒体播放器可以获得不断增加的容量，播放列表的这些问题可能被加剧。另外，由于用户不可能记住每个文件的内容和特性，所以较大的媒体库对给相似项目分组的系统产生了更大要求。因此，本领域需要一种产生媒体文件之间的相似性数据并且使用这种数据创建和管理播放列表的改进方法。

发明内容

在下面的描述中阐述了此处公开的概念的附加特征和优点，并且根据该描述可以部分地明白或通过实践所描述的技术可以了解这些特征和优点。可以借助所附权利要求内特别指出的手段和组合来实现和获得这些概念的特征和优点。将从下面的描述和所附权利要求中更全面地理解所述技术的这些和其它特征，或通过实践此处阐述的所公开的概念可以了解这些和其它特征。

本公开描述了至少部分地基于由若干程序参与者提供的媒体库库存(inventory)信息，便于程序参与者实现媒体播放列表产生的方法和装置。在这个上下文中，个人正在参与的示例性程序或系统是在线媒体商店，诸如销售音乐轨迹下载以收费的那些在线媒体商店。决定成为程序参与者的这些个人对至少部分地基于从程序的其它参与者群体得出的数据组织、维护和播放其音乐感兴趣，该其它参与者在其库中具有相似或相同的音乐。为了成为程序参与者，单个音乐持有者必须发送表示该程序参与者的媒体库存的数据，并且在线音乐商店接收该数据。该数据通常包含，常常尤其是，当前包含在该参与者的媒体库内的媒体项目个体(歌曲)的标识数据，而不考虑媒体项目个体的来源。也就是，项目可以是购买的、从CD添加的、或以其它方式获得且包括在收听者的库或音乐库存内的。根据该信息，系统或程序确定媒体项目个体对在不同程序参与者的媒体库内共同出现的发生率(incidence)。在此，这意味着对于若干用户所标识的各对音乐项目，该对存在于不同参与者的多少库内将被注意到(计数)。基于该确定，基于所确定的在不同程序参与者的媒体库内共同出现的发生率，在媒体项目个体(歌曲)对之间分配相似性评估。也就是，如果确定(计算)特定媒体项目(歌曲)对存在于在程序中表示的许多库中的10个库内，可以给该对的相似性评估分配某一值。

为了有意义，在包含在多个程序参与者的媒体库内的媒体项目个体的至少大部分之间汇编对相似性评估的分析和分配；也就是，系统的总库存。

然后系统或程序可以汇编单个参与者的相似性评估，该单个参与者限于包含在他或她的媒体库内的项目。然后可以使用该信息，诸如在诸如常常被称为MP3播放器的设备之类的个人数字音乐播放设备上，整理(order)作为最终用户的那个人的媒体的播放列表。以这种方式，可以基于从大量程序参与者得到的相似性数据产生各个播放列表。

在不同但是相关的方面，本公开还描述了从客户设备角度出发采取的方法和装置，该客户设备与在线商店协作以便于至少部分地基于由若干程序参与者提供的媒体库库存信息来实现媒体播放列表产生。该实施例着重于方法、装置和计算机程序，其从程序参与者的客户设备(通常向程序主机，该主机在此被示例性地描述为在线媒体商店的在线数据处理中心)发送数据，该数据表示程序参与者的媒体库内的媒体库存并且包括当前包含在媒体库的库存内的媒体项目个体的标识数据，而不考虑媒体项目个体的来源。媒体项目来源的例子包括在线购买、从购买的CD添加的轨迹和来自其它来源的下载。

在这个实施例中，程序参与者的客户设备接着接收媒体项目相似性评估，其中已经基于从多个(两个或更多个)程序参与者收集的累积数据而汇编了该媒体项目相似性评估，并且其中该累积数据包括包含在程序参与者的媒体库内的媒体项目个体的标识数据，而不考虑每个媒体项目个体的来源。就此而言，媒体项目之间的基于其来源的主要差异是与每个项目相关联的描述性的和标识元数据的数量和质量。

如前所述，对接收到的相似性评估的汇编就已经包括处理累积数据，以便确定媒体项目个体对在不同程序参与者的媒体库内共同出现的发生率，以及基于所确定的在不同程序参与者的媒体库内共同出现的发生率，在媒体项目个体对之间分配相似性评估(similarity rating)。如此处所述，如下面更详细描述的那样由程序主机的在线数据处理中心示例性地执行该处理和汇编。

程序参与者的客户设备接收包含在参与者的媒体库内的多个媒体项目个体的相似性评估。据此产生媒体播放列表，该媒体播放列表包括包含在程序参与者的媒体库内并且具有相对于从参与者的媒体库内选择的种子媒体项目的相似性评估的媒体项目个体，通常由程序参与者选择该种子媒体项目。

作为例子，可以通过操纵客户设备上的滚轮设备而呈现用于选择的种子媒体项目，以及随后通过激活选择按钮，在客户设备的显示器上选择种子媒体项目，来影响种子媒体项目的选择。

在另一个例子中，可以通过使用扫动手指姿态来操纵程序参与者的客户设备上的触摸屏以便滚动显示在触摸屏上的媒体项目列表，直到显示所希望的种子媒体项目，以及随后通过触摸和释放种子媒体项目来选择种子媒体项目，来影响种子媒体项目的选择。

可以在程序参与者的客户设备上产生媒体播放列表，该客户设备尤其是可以采取便携式个人媒体播放设备或个人计算机的形式。

还构想了程序参与者可以传输表示程序参与者的媒体库内的当前媒体库存的更新数据，该更新数据包括从参与者最近的前一次数据上传以来添加到参与者的媒体库的附加媒体项目的标识数据。类似地，更新数据可以指示从最近的前一次数据上传以来，从参与者的媒体库中去除的媒体项目的缺失。更新数据还可以包括关于媒体项目的使用的信息，诸如但不限于，给予媒体项目的评估、播放计数和跳过计数。据此程序参与者接收考虑到这种更新数据而汇编的更新相似性评估。以这种方式，当前产生的播放列表可以包括新获得的媒体项目，并且不考虑最近已被删除的媒体项目。

在其它相关方面中，本公开还描述了集成系统、方法和计算机程序，其包括与程序主机的在线数据处理中心协作以便产生至少部分地基于由若干程序参与者提供的媒体库库存信息的媒体播放列表的一个或多个客户设备。因此，数据被从程序参与者的客户设备传输到程序主机的在线数据处理中心。该数据表示客户设备上的媒体库内的媒体库存，并且包括当前包含在客户设备上的媒体库的库存内的媒体项目个体的标识数据。在程序主机的在线数据处理中心，还从多个程序参与者接收如下数据：该数据表示每个相应程序参与者的媒体库存，并且包括当前包含在相应参与者的媒体库内的媒体项目个体的标识数据，而不考虑媒体项目个体的来源，如上所述。确定媒体项目个体对在不同程序参与者的媒体库中共同出现的发生率，并且基于所确定的在不同程序参与者的媒体库中共同出现的发生率，在媒体项目个体对之间分配相似性评估。从程序主机的在线数据处理中心向程序参与者的客户设备传输包含在客户设备上的媒体库的库存内的多个媒体项目个体的相似性评估。产生媒体播放列表，其包括包含在客户设备上的媒体库的库存内并且具有相对于从客户设备上的媒体项目的库存内选择的种子媒体项目的相似性评估的媒体项目个体。

典型地，在程序主机的在线数据处理中心处确定不同程序参与者的媒体库内的媒体项目个体对共同出现的发生率，并且还在程序主机的在线数据处理中心处分配媒体项目个体对之间的相似性评估。

单个程序参与者的相似性评估数据的汇编局限于包含在该程序参与者的媒体库内的媒体项目个体之间的相似性评估数据。以这种方式，数据集合局限于可被使用的数据集合；即，产生仅包括实际包含在程序参与者的库内的媒体项目的播放列表。

作为在允许包含在不同参与者的媒体库内的大体相同的媒体项目之间的直接相关时的一种辅助手段，给包含在参与者的媒体库内的每个媒体项目个体分配源自程序的标识符。也就是，使用音乐轨迹作为例子，给美国的“Horse With No name”的所有演播室版本实例分配可快速、有效处理的短的基于系统的ID。为了更进一步地便于相似性评估的计算，还可以给相似的媒体项目分配相同的标识符；例如，可以给美国歌唱的“Horse With No name”的现场录音分配相同的基于系统的ID，以便在确定其与总数据库内的其它媒体项目的相似性时进行处理。

另外，可以通过关联从第三方数据来源获得的附加数据，丰富与特定媒体项目相关联的信息。再次使用音乐作为例子，“流派”是常常与特定音乐项目相关联的特性。在从程序参与者接收到某个音乐标题的标识数据，但是该数据不包括流派类型的情况下，可以咨询具有这种相关信息的第三方，并且可以将第三方提供的该特定音乐项目的流派类型与其相关联，以便以后在播放列表产生处理中使用。

应当理解，该整个程序或系统的独特方面发生在媒体提供商(在线音乐商店)的服务器、参与者的媒体播放设备上，以及常常发生在中间设备上，所述中间设备诸如是适于播放设备和在线商店的计算机系统之间的通信的用户的个人计算机。

附图说明

为了最好地描述实现上述实施例的方式，以及定义本公开的其它优点和特征，下面提供并且在附图中示出更具体的描述。应当理解，这些附图仅描绘了本发明的示例性实施例，因此不被认为是范围限制，通过使用附图，将以附加特性和细节描述和解释这些例子，其中：

图1示出了示例系统实施例；

图2示出了示例方法实施例；

图3示出了确定相关数据的方法；

图4示出了样本购买矩阵；

图5示出了主相似性表内的列；

图6示出了单个相似性表；

图7示出了示例系统实施例；

图8示出了示例方法实施例；

图9示出了示例系统实施例；

图10示出了用于与数字媒体播放器同步媒体和相似性表的示例系统；

图11示出了用于启动播放列表产生的示例软件界面；

图12示出了示例方法实施例；

图13示出了示例用户界面；

图14示出了示例用户界面；

图15示出了示例方法实施例；

图16示出了推荐购买项目的示例方法实施例；

图17示出了用于选择加入的示例用户界面；

图18示出了示例用户界面；和

图19示出了用于显示推荐数据的示例用户界面。

具体实施方式

下面详细讨论公开的方法和装置的各种实施例。虽然讨论了特定实施方式，但是应当理解，这样做仅是出于说明目的。相关领域技术人员将认识到可以使用其它组件、配置和步骤，而不脱离本公开的精神和范围。

参考图1，示例性系统包括通用计算设备100，包括处理单元(CPU)120和系统总线110，系统总线110将包括系统存储器——诸如，只读存储器(ROM)140和随机访问存储器(RAM)150——的各种系统组件耦接到处理单元120。还可以使用其它系统存储器130。可以理解，该系统可以在具有多于一个CPU 120的计算设备或联网在一起的一组计算设备或计算设备集群上操作，以便提供更大的处理能力。系统总线110可以为若干类型的总线结构中的任一种，所述总线结构包括存储器总线或存储器控制器、外设总线和使用各种总线体系结构中的任意一种的本地总线。存储在ROM 140等内的基本输入/输出(BIOS)可以提供诸如在启动过程中帮助在计算设备100内的元件之间传送信息的基本例程。计算设备100还包括存储设备，诸如硬盘驱动器160、磁盘驱动器、光盘驱动器或磁带驱动器等。存储设备160由驱动接口连接到系统总线110。驱动器和相关联的计算机可读介质提供计算机可读指令、数据结构、程序模块和/或用于计算设备100的其它数据的非易失性存储。在一个方面，执行特定功能的硬件模块包括存储在有形计算机可读介质内的软件组件，其与必需的硬件组件，诸如CPU、总线、和显示器等相结合来执行该功能。这些基本组件是本领域技术人员已知的，并且根据设备类型，诸如设备是小型的、手持型计算设备、台式计算机还是大的计算机服务器，可以构想适当的变体。

虽然此处描述的示例性环境采用硬盘，本领域技术人员应当理解，还可以在示例性操作环境中使用可以存储计算机可访问的数据的其它类型的计算机可读介质，诸如磁带盒(magnetic cassette)、闪存卡、数字通用盘、盒式磁带(cartridge)、随机访问存储器(RAM)、只读存储器(ROM)、和包含比特流的缆线或无线信号等。

为了能够与计算设备100进行用户交互，输入设备190表示任意数目的输入机构，诸如用于语音的麦克风、用于手势或图形输入的触敏屏、键盘、鼠标、运动输入、和语音等。提出者可以使用输入来指示语音搜索查询的开始。设备输出170也可以是本领域技术人员已知的若干输出机构中的一种或多种。在某些情况下，多种方式的系统使得用户能够提供多种类型的输入以便与计算设备100通信。通信接口180总地支配并且管理用户输入和系统输出。对所公开的在任意特定的硬件装置上操作的方法和设备没有限制，并且因此，可以用开发出的改进的硬件或固件装置容易地取代这些基本特征。

为了解释清楚，说明性系统实施例被呈现为包括各个功能块(包括标记为“处理器”的功能块)。可以使用共享或专用的硬件提供这些块代表的功能，所述硬件包括但不限于，能够执行软件的硬件。例如，可由单个共享处理器或多个处理器提供图1中给出的一个或多个处理器的功能(术语“处理器”的使用不应被认为仅仅指的是能够执行软件的硬件)。说明性实施例可以包括微处理器和/或数字信号处理器(DSP)硬件、用于存储执行下面讨论的操作的软件的只读存储器(ROM)和用于存储结果的随机访问存储器(RAM)。还可以提供超大规模集成(VLSI)硬件实施例，以及与通用DSP电路相结合的定制VLSI电路。

各种实施例的逻辑操作被实现为：(1)运行在通用计算机内的可编程电路上的一系列计算机实现的步骤、操作或过程，(2)运行在专用可编程电路上的一系列计算机实现的步骤、操作或过程；和/或(3)可编程电路内的互连的机器模块或程序引擎。

上面描述的计算设备特别适用于产生和使用从大量样本用户得到的相似性数据。基于用于确定两个或更多个歌曲在多个用户的库中发生相关的发生率的数学分析，可以确定统计相似性。该相似性数据可用于各种有帮助的功能，尤其是包括产生高质量的播放列表、确定向用户推荐购买的建议产品、通过歌曲的新近选择使用户的媒体设备保持最新。在一个例子中，用户可以将关于他们的整个媒体数据库的内容的信息上传到用户的大量听众可访问的服务器。基于两个或更多个媒体项目在用户的全部听众的库中同时出现的频繁程度，媒体项目变为彼此相关并且被标注为相似。基于这种相似性，服务器可以基于对种子轨迹的选择创建播放列表以便包括一个或多个相似歌曲，或服务器可以推荐购买用户的库内没有的类似歌曲。下面将更详细地描述该系统的这些和其它特征。虽然参考在线音乐商店，诸如苹果公司的ITUNES商店，将描述所描述的技术和产品的许多特征，但是应当理解，该系统不需要任何媒体销售来执行该系统的优选实施例。另外，虽然某些描述可以仅涉及一种特定形式的媒体，但是此处描述的原理可被应用于任意媒体，诸如音频、视频、静态图片、文档和其它类型的数据文件。

服务器

上传

图2示出了用于产生相似性数据的示例方法实施例。该方法包括由服务器接收与程序参与者的个体媒体库存相关的用户数据(202)。用户数据包括通常为元数据形式的关于用户的库内的媒体项目个体的标识信息。用户的库内的媒体项目的起源与该系统无关。即使音乐内容商店采用所描述的方法，由于服务器不基于来源区分文件信息，所有媒体项目被同等地对待，所以本实施例不需要用户的文件源自于音乐商店。该方法等同地适用于物理媒体，诸如，CD、DVD或HD-DVD，以及物理媒体被代码转换为数字格式并且输入到用户媒体库中的情况。在优选实施例中，服务器不需要用户上传关于其库内的所有媒体项目的信息；服务器也接受仅关于有限数目的媒体项目的信息，或关于媒体项目的仅仅部分信息。

识别用户数据

该方法还包括将用户数据识别为特定媒体项目203。该步骤可通过若干方式中的任意一种完成，包括检查文件名、元数据或通过对文件的一部分进行详细分析。在音乐轨迹的例子中，服务器可以通过各种机制识别音乐轨迹。例如，给定轨迹，诸如具有大约8分钟长度的Led Zepplin的Stairway to Heaven，可以具有与该文件相关联的各种数据，包括文件名或标识歌手、歌曲名、流派、轨迹长度、专集名、轨迹号等的元数据。这些数据中的一部分可能足以使服务器将该文件识别为专集LedZepplin IV中的Led Zepplin的Stairway to Heaven。可替换地，可以使用商业歌曲识别服务识别该文件。还可以通过对音乐轨迹的一部分采样，或通过识别来自购买商店的唯一标识符，或通过识别歌曲的数字指纹，来识别轨迹。例如，服务器或服务可以识别出歌曲购买自ITUNES商店，并且文件的元数据包含专用于ITUNES商店的唯一标识符。服务器可以通过该标识符识别媒体项目。应当理解，识别媒体项目的许多其它可能方法是公知的，并且所有这些方法包括在公开的方法和装置内。

相关

在步骤204，每个媒体项目与唯一标识符相关联，并且在步骤205被存储在表内。如果服务器以前从没遇到过该歌曲，服务器给该轨迹分配新的标识符。然而，对于大部分媒体项目，以前已经分配了标识符，并且媒体仅需要与该标识符相关联。继续Stairway To Heaven的例子，一旦媒体项目已被识别为该轨迹，服务器可以查看该轨迹的唯一标识数据。针对服务器接收到的每个媒体项目重复该处理。

虽然服务器已经将标识符与大部分歌曲相关联，在某些情况下，媒体项目对于服务器是全新的，或至少被识别为如此。在这些情况下，服务器将发出新的标识符，并且将其分配给该媒体项目。例如，服务器可能不认识新的歌手或garage band。然而，服务器将为该歌手的轨迹发出新的标识符，并且当服务器在不同用户的库内遇到相同轨迹时，它将给该轨迹分配与以前发出的标识符相同的标识符。

在某些情况下，服务器可能不给对于服务器来说是新的媒体项目提供新的标识符。例如，媒体项目可能是一个用户库所独有的，并且因此由于不会有该项目的同时出现的发生率，所以提供标识符没有任何价值。因此，系统不需要给所有新项目提供唯一标识符。其后，如果其它用户也在其库内具有该媒体项目，则系统可以给该轨迹提供唯一标识符，并且提供该项目的相似性数据。

主购买矩阵

在步骤205每个媒体项目被存储在主购买矩阵内。图4示出了主购买矩阵的图示。购买矩阵402是一个表，其包含相应于表内的每个唯一媒体项目的列404。在该表由音乐内容销售商，诸如ITUNES商店，托管的实施例中，购买矩阵还将包括可从ITUNES商店购买获得的所有媒体项目。主购买矩阵402的行与唯一用户标识号406相关联。该标识码以用户可能知道但是系统不知道的匿名标识码表示用户。因此，主购买矩阵包含程序服务器从每个参与用户接收到的每个文件的记录。

由于购买矩阵容纳有所有程序参与者和每个程序参与者的库内的所有媒体，购买矩阵402可能大得惊人。例如，如果音乐商店具有近似2.25百万个用户以及多于5百万的歌曲。这种在线商店的购买矩阵是近似2.25百万行和5百万列，或11,250亿个单个单元格的表。ITUNES商店具有5千万注册用户，并且包含超过1千万歌曲。这种在线商店的购买矩阵是近似5千万行和1千万列，或5,000,000亿个单个单元格的表。

对于用户库内的歌曲，标记矩阵内相应于该用户和该歌曲的单元格。可以用如同布尔那样简单的数据类型进行标记，1用于已购买408，而0用于未购买410。当必须存储比布尔数据类型所允许的更多的数据时，可以使用其它数据类型。虽然矩阵可能非常大，由于大部分用户在其库中具有相对少的歌曲(与5百万相比)，该矩阵被非常稀疏地填充。每个用户行可能仅包含少数表项，而每个歌曲列可能包含几十个、几百个、几千个、或对于更流行的歌曲甚至几百万个表项，但是购买矩阵的绝大多数是空的。

应当理解，当用户库改变——通过向他们的库中增加新歌曲、改变文件元数据或删除文件——时，主购买矩阵或表需要更新。购买矩阵可被实时更新，或可对事务进行排队以便以后插入。一种排队装置规则地，诸如每天晚上11:30，在购买矩阵中插入事务。另一种排队装置在准备好某个最小数目的事务用于插入时才向购买矩阵中插入事务。

更新购买表不需要针对所有媒体项目重复步骤203和204。由于在用户的数据最初填充该表时已经执行过，所以已经被识别并且与基于程序的识别号相关的媒体项目不需要识别和相关步骤。在一个实施例中，一旦服务器已经将媒体项目和其标识数据相关，服务器可以将标识数据发送回用户以便存储在元数据内。在与服务器的将来通信中，服务器可以接收对具有相关联的标识数据的媒体项目的更新，从而避免需要重做步骤204。

在某些实施例中，购买矩阵可以是包括关于每个事务的附加信息，诸如销售时间和日期、媒体是什么格式、媒体是高清晰度还是标准清晰度、事务是赠品还是收费的、哪些设备被授权回放等，的更大表或矩阵的一部分。购买矩阵可以是离散的不同的表，或可被完整地结合在更大的表或矩阵内。

在另一个实施例中，主购买矩阵不需要包含关于用户媒体库存的上传信息。主购买矩阵可以本质上由购买信息构成。购买信息可以仅是用户从在线商店购买的项目，或可以包括附加信息。在这个实施例中，该表可以包括每个用户购买的所有项目的列表。另外，主购买矩阵很可能至少包括与用户的媒体库存的内容有关的相似性数据的有限集合。

协同过滤引擎

图2所示的方法接着包括在步骤206对主购买矩阵运行协同过滤引擎以便产生相似性数据，并且在步骤207在主相似性表内存储相似性数据。可以根据媒体项目在主表内与某个其它媒体项目共同出现的发生率，得出相似性数据。当用户具有相同的两个媒体项目时，它们被称为共同出现。多个用户的库内的这种共同出现是两个媒体项目“类似”的指示。两个媒体项目在程序参与者的库内共同出现得越频繁，媒体项目被称为越相似。

协同过滤引擎308计算主购买表内的媒体项目个体之间的相似性。在一个实施例中，协同过滤引擎可以简单地是记录数据库内的各对歌曲在程序参与者的库内共同出现的次数的程序。

在一个实施例中，协同过滤引擎可以通过将每个项目表示为多维矢量空间内的矢量，计算两个不同媒体项目之间的相似性。维数等于购买矩阵306内的用户数目。通过计算矢量之间的距离获得项目之间的相关性。可以使用纯的或修改后的三角函数(例如，余弦或正弦函数)计算矢量之间的距离。如果两个矢量具有小夹角，它们被认为是相似的，并且如果两个矢量具有大夹角，它们被认为不太相似。通过对主购买矩阵内的每个歌曲和主购买矩阵内的每个其它歌曲进行比较，执行这个处理。

在另一个实施例中，协同过滤引擎可以考虑比共同出现发生率数据更多的内容。例如，整体出现的发生率可被作为相似性评估的因素。例如，歌曲A和B可以与歌曲A和C同等频繁地共同出现，但是如果歌曲B总体上更为流行，则歌曲A和B可以比歌曲A和C具有更高的相似性得分(即，被认为更相似)。一种确定不同歌曲的流行度的方法是测量每个歌曲在整个数据集合中出现的频繁程度。

类似地，协同过滤引擎可以有影响相似性得分的其它输入，诸如使用率输入。例如，给予媒体项目的评估、播放计数以及跳过计数全部可被输入到协同过滤引擎中，以便确定媒体项目之间的相似性。

图3示出了将每个歌曲表示为矢量的概念。在图3a中，基于歌曲在用户库2,899、1,343和2,000中的存在，已经制订了主表内的媒体ID 629的矢量。类似地，基于歌曲在用户库2、12、444、1,343中的存在，已经映射了主表中的媒体ID 1,263,999的矢量。经测量这两个矢量之间的夹角是20度，并且计算出近似为0.939的余弦值。该余弦值表示媒体ID 629和媒体ID 1,263,999之间的相关值。图3b表示用于确定媒体ID 629和媒体ID 15之间的相关性的另一个相关性计算。在这个例子中，没有一个用户在其库中有媒体ID 629和媒体ID 15两者，并且因此这两个矢量之间的余弦值近似为-0.707。较低的得分指示媒体ID 629和15彼此不紧密相关。

在另一个实施例中，可以使用其它函数计算项目之间的相似性得分。作为例子，可以用考虑了特定项目所占一项目的总体共同出现的百分比的方法计算相似性得分。例如，项目A与项目1-5共同出现，并且项目A的总体共同出现是与项目1-5的全部共同出现的总和。例如，如果项目A与项目1共同出现2次，与项目2共同出现2次，与项目3共同出现2次，与项目4共同出现10次并且与项目5共同出现2次，则项目A具有总体共同出现18。了解共同出现总数由特定对所导致的百分比可能是有价值的。例如，项目4代表项目A的全部共同出现的近似55％，并且因此，与任意其它项目相比，与项目A更强地相关，每个其它项目仅仅代表A的全部共同出现中的大约11％。该数据还可以用于确定相似性数据。虽然上面图示了计算相似性数据的两个特定方法，但是应当理解，可以使用计算两个项目之间的相似性的任意数目的其它方法。

以某个规则的时间间隔在每个项目和每个其它项目之间计算上面的处理。由于这个处理可能花费过多的时间量，它通常离线执行。其可每月执行一次、一个星期执行一次、一天执行一次、或以计算能力允许的频繁程度执行。

相似性表

在图2的步骤207内使用协同过滤引擎汇编的相关数据产生主相似性表。图5示出了存储在主相似性表502内的数据。对于给定媒体项目，在主相似性表中存在以其基于程序的标识数据504识别该媒体项目的表项。被认为与该媒体项目类似或相关的每个其它媒体项目也可被列在表508内。以这种方式，表502维护与主购买矩阵402内的每个媒体项目相似的所有媒体的列表。

如果项目具有足以被认为与该媒体项目相似或相关的得分，则这些项目被包括在主相似性表内。对于任意给定项目，大部分其它项目根本不相似。当相似性得分足够低时，其不包括在相似性表内。确定相似性得分足够低或高的阈值可以是动态的或静态的。例如，如果相似性得分的范围为-1到+1，-1为完全不相似，而1为极其相似，该阈值可被静态地设置为0.5。可以基于主购买表内歌曲的出现次数，动态地设置该阈值，诸如出现次数小于100的歌曲的阈值为0.9，出现次数小于5,000的歌曲的阈值为0.7，出现次数小于25,000的歌曲的阈值为0.6，出现次数等于或大于25,000的歌曲的阈值为0.5。该阈值还可以基于可获得的存储量或任意其它参数。

换言之，主相似性表502可以包含所有或某些相似性得分。如果必须约束主相似性表以符合某个存储大小，则仅包括最好或最强的相似性，并且摒弃其余相似性。类似地，如果没有足够的程序参与者在其媒体库存中具有某一项目，其可被排除。这种方法的一种变型是在项目有资格被包括在主相似性表内之前，要求在用户的库内出现最小次数。例如，如果两个项目具有5或更小的共同出现，即，如果5个或更少的人具有这两个项目，则系统不计算其余得分。

在另一个实施例中，主相似性表还可以存储等同关系。例如，表502中的媒体ID 17可以相应于Luciano Pavarotti 1990年表演的“O SoleMio”。在线商店中可以获得诸如Enrico Caruso和Mario Lanza的歌手对“O Sole Mio”的多种表演，并且这些表演被认为是等同媒体506。其它显著类型的等同媒体包括正式专集轨迹、原声轨迹、现场音乐会轨迹、其它乐队的翻唱轨迹和甚至相同歌曲的外语轨迹。单个歌曲可以以所有所列形式或更多形式存在。可以手工执行或可以基于实际媒体内容、元数据和/或其它可获得数据自动执行等同确定。可以在媒体ID 504旁边给出每个的等同媒体ID，以便标识它们中的每一个被认为是相同的，并且它们可一起计数。

主相似性表内的ID可以与购买矩阵306内用于索引媒体的ID相同，或它们可以基于完全不同的方案。如果两者不一致，可以提供变换器函数或参考变换表，以便将一个ID转换为另一个ID或反之亦然。两者之间共享的公共ID空间的维护可能最容易并且最简单而没有性能损失。用户相似性表

虽然主相似性表包含全体相似媒体，个体媒体库几乎必定包括全体相似媒体的较小子集。因此，产生约束集合或个体相似性表。约束适合于给定库内的媒体可获得性。约束集合还可以包括对未在媒体库内发现的相似媒体的引用。可以这样做以便将用户作为建议媒体购买的目标。由于具有某些共同媒体品味的其它人在其库中已经具有了该建议的购买，这种定向的建议购买很可能对用户更有吸引力。

一旦计算并且填充了主相似性表502，产生个体相似性表602。图6示出了个体相似性表。个体相似性表602包括包含在个体媒体库内的每个歌曲的媒体ID 604和与该媒体ID相关的媒体。在括号中示出了相关媒体606。个体相似性表内的相关媒体是位于项目的主相似性表内的分类相似媒体508的整个列表的子集。基于哪些媒体出现在个体媒体库内，选择该子集。换言之，为位于个人的库内的每个歌曲，产生也包含在个人的库内的相似媒体的列表。

个体相似性表可由服务器在服务器处产生并且被客户设备下载，或可由客户端通过仅下载用户媒体库存内的项目的相似性数据而创建个体相似性表。不论在何处创建相似性表，处理是相同的。按照该项目的基于程序的相似性标识数据在主相似性表内查找媒体项目。接着，系统可以按索引查找媒体项目的相似性数据的位置。基于查找操作的结果，系统可以检索相似项目。将这些项目与用户媒体库内的那些媒体项目进一步比较，并且仅仅出现在用户媒体库内的那些项目被存储在个体相似性表内。在另外的实施例中，某些高度相似的轨迹也可被记录在个体相似性表内，以便用于向用户建议购买。

在优选实施例中，可由服务器为每个库产生至少一个个体相似性表。客户端可将库数据发送给服务器，服务器可以识别库内的项目，并且通过从主相似性表中提取属于该库内项目的相似性数据，为该库产生个体相似性表。然后，所得到的个体相似性表可被下载到客户端以便用于产生播放列表。客户端还可以使用相同的个体相似性表来创建外设的个体相似性表。

使用这些个体相似性表，用户可以受益于从整个用户群体得出的数据。用户可以使用相似性数据创建播放列表、接收新媒体购买建议以及用于各种其它可能。

用户数据影响协同过滤

在基于相似性数据产生播放列表的实施例中，用户可以提供，或系统可以请求，通过跳过播放列表中他们不希望听的歌曲的反馈，或他们可以给播放列表内他们喜欢听的媒体项目以正面评估。这种数据可从客户设备上传，并且被服务器接收。可以以任意数目的不同模式，诸如以主购买索引或以不同的表，存储反馈数据。还可以从诸如ITUNES商店的在线音乐商店得到反馈。在这个实施例中，用户在在线商店304上的活动产生反馈数据。用户在在线商店上的活动可以包括：购买媒体项目、预览媒体项目、搜索特定媒体项目标题、搜索特定媒体项目歌手或搜索特定媒体项目流派。协同过滤引擎可以使用反馈数据修改项目之间的相关得分。

来自群体的反馈数据可能潜在地消除可能存在的相关。例如，Simon和Garfunkel的歌曲Mrs.Robinson可能与Lemonheads或Frank Sinatra的相同歌曲强相关，但是旨在基于Simon和Garfunkel版本产生播放列表的用户可能不喜欢不同版本-也许是由于翻唱歌曲的不同流派。经过一段时间，诸如跳过歌曲或从播放列表中去除该项目的反馈数据可被用于从相关项目列表中去除一个或两个翻唱版本。

在其它实施例中，用户反馈还可用于在客户设备处直接修改相似性数据，而不用首先将反馈发送给服务器以供协同过滤引擎使用。在这些实施例中，用户反馈数据可以直接影响存储在客户设备上的个体相似性表内的关系，而无需首先与服务器同步。可替换地，相似性表可以保持相同，但是可以基于用户反馈数据产生约束。例如，如果用户经常跳过一个类似项目，通过从个体相似性表中去除该项目，客户端本身可以不再认为该项目是相似的，或可以通过其它手段，诸如播放列表算法中的约束，防止添加频繁跳过的项目从而不会包括在播放列表内。

更新相似性表

经过一段时间，当歌手创建新音乐和新歌手出现时，新媒体项目可被添加到在线商店内，甚至于被添加到主购买表内。因此，可能形成在线商店304内已有项目和在线商店内新增加项目之间的相关。例如，如果用户在他/她的媒体库内具有歌曲A，并且随后购买了最近被引入在线商店304内的新增加的歌曲B，则可以形成歌曲A和新增加的歌曲B之间的新相关。当用户购买新增加的歌曲B时，该事务被记录在购买矩阵306内，并且产生更新的购买矩阵306。可替换地，歌曲B可能已通过从CD拷贝轨迹而被添加到用户库中。在这种情况下，结果是相同的。只要歌曲A和歌曲B两者都在用户的媒体库内，这种共同出现被记录在更新的主购买矩阵内。

协同过滤引擎308使用来自更新的购买矩阵306的信息，如上所述产生项目的更新的主相似性表316。此后，通过仅提取更新的主相似性表316内的已经改变的那些项目，可以为每个用户产生更新的个体相似性表322。可替换地，可以基于新数据创建全新的个体相似性表。

系统概述

图7示出了可以执行上述实施例的一个这种系统300的例子。购买矩阵306存储关于来自每个用户的库的所有媒体项目的数据。协同过滤引擎308使用购买矩阵306内的数据，确定每个媒体项目相对于每个其他媒体项目的共同出现的发生率。协同过滤引擎308可以有选择地使用存储在对象324和326内的反馈数据，以根据程序参与者群体上的用户偏好来调整相似性得分。通过存储被认为类似于给定媒体项目318的所有媒体项目320，协同过滤引擎的输出存储在主相似性表内。相似媒体项目320可被分类为按从最相关项目到最不相关项目的顺序呈现。

在线管理工具304用作客户端侧302和服务器侧301的接口。在优选实施例中，在线管理工具304可以与在线商店相关联。在一个实施例中，在线商店可以产生数据310，数据310还可被协同过滤引擎308用于产生相似性数据。无论如何，客户端302用于上传关于存储在客户端302上的媒体项目的信息，以及从服务器301下载相似性数据。可以通过在线管理工具304直接从主相似性表316下载特定于客户端的相似性数据，而在客户设备302上产生个体相似性表322，或可由服务器301产生个体相似性表，并且将该表下载到客户设备302。客户设备还可以将反馈数据通过在线管理工具304传递给协同过滤308以便帮助产生更好的相似性数据。

客户端

如图7所示，客户设备302可以采取各种形式中的任意一种。客户设备302包括诸如便携式数字音频播放器、便携式数字视频播放器、智能电话、台式和膝上计算机、电视机顶盒和能够播放媒体的任意其它设备之类的设备。客户设备可以包括离线便携式设备，其通过台式计算机或其它中间设备与在线商店304同步，诸如通过与台式计算机的缆线连接同步的IPOD数字音频播放器、通过无线路由器无线同步的IPODTOUCH数字音频播放器、或通过蜂窝连接无线同步的智能电话。根据上面的讨论将会明了，客户设备包含各种媒体项目的库存。如果客户设备的用户希望从相似性数据的使用中受益，用户通过在线接口访问该服务。可替换地，客户设备可以通过基于客户端的应用，诸如通过Internet与远程服务器通信的ITUNES桌面应用，访问相似性数据服务。

在线商店304可以是允许客户设备购买数字媒体的单个服务器或服务器集群。在线商店还可以准许访问其它辅助媒体管理特征。

图15示出了将相似性数据下载到客户端的方法实施例。如果这是客户端首次访问协同程序842，客户端必须通过选择加入程序844来选择参与。在步骤846给客户端提供私有用户识别码。虽然服务器使用该码关联客户的库，但仅有客户端包含附加的标识信息。服务器不知道关于客户设备或用户(程序参与者)的个人或识别信息。一旦分配了私有识别码，客户设备可以上传关于其媒体库848的信息。在优选实施例中，用户可以选择与服务器共享哪些媒体项目。

如果步骤842的结果指示用户已经参与了协同程序，在步骤850客户端可以使用其私有识别码登录服务器。在步骤852，服务器可以向客户端请求关于媒体库的改变的信息，或可替换地，客户端可以共享这种信息，而不用首先被请求。如果库已经发生了改变，客户端上传关于该改变的信息854。改变可以采取经编辑的元数据、新项目、删除的项目等的形式。一旦关于客户端的媒体库的最新信息已被发送到服务器，在步骤856客户端可以向服务器请求新的相似性数据。可替换地，服务器可以启动新的或更新的相似性数据的传输。

在可替换实施例中，客户端可以跳过上面的步骤，并且简单地向主相似性表请求更新结果，而无需识别库。例如，客户端可以请求特定项目或项目列表的更新，而不用以标识号标识自己，并且不需要将客户端媒体库库存的改变通知给服务器。

在步骤858下载相似性数据。可以用服务器以前创建的表的形式下载相似性数据，或该信息可被实时下载和格式化为个体相似性数据表。

基于个体相似性表产生播放列表。可以在客户端侧302、在在线商店304中或在协同过滤引擎308中产生播放列表。可以基于与一个歌曲或多个歌曲的统计相似性产生播放列表。当客户设备采用基于个体相似性表的播放列表时，某些歌曲可能不是用户期望的，或可能不是用户喜欢的。当用户经常跳过基于统计相似性被置于播放列表内的歌曲时，系统“惩罚”该歌曲，降低其相似性值，将其包括在较不频繁播放的播放列表内，并且最终可以将其从播放列表中完全丢弃。当用户跳过歌曲时，这通过报告来实现。该动作被记录在客户设备上，并且作为反馈传输到在线商店。在线商店将这种反馈发送给协同过滤引擎，协同过滤引擎将其存储在负相关表326中。负相关表存储相似性的负指示。以这种方式，在将一个歌曲排除出相似性表之前，每个用户不必多次单独跳过该歌曲。累积的负反馈将基于组行为为该组用户滤除不流行的歌曲。这样，这些播放列表作为不断发展以便适合用户群体的不断改变的媒体品味的生命有机体。

例如，如果许多用户总是跳过播放列表内的特定歌曲，或如果许多用户从其播放列表中删除该歌曲，该信息被记录并且被分配以影响主相似性表的产生的权重。该权重可以基于所报告的负相关的数目，或用户交互的其它方面。相反，与特定歌曲的正用户交互提供正相关。例如，如果许多用户向已有播放列表中增加相同歌曲，或如果许多用户在特定歌曲期间调大音量，这些正相关可通过在线接口被报告给服务器，并且被存储在正相关表内。

除了与服务器交互之外，客户端还可以与其它客户端或外设交互。在一个优选实施例中，客户端可以是与便携式音乐播放器，诸如IPOD便携式音乐播放器，交互的个人计算机。在这种情况下，客户设备还可以准备在外设上使用的个体相似性表。如同服务器可以为客户端准备仅包括客户端的库内的那些媒体项目的信息的个体相似性表，客户端可以为外设准备仅包括外设的库内的那些媒体项目的信息的个体相似性表。客户端可将个体相似性表如同任意其它数据项目那样装入外设中。

外设

外设是要与客户端一起工作，就如同客户端与服务器一起工作那样。例如，外设可以将其内容的改变通知给客户端，并且请求这些内容的相似性数据。在更优选的实施例中，如同运行ITUNES桌面应用的个人计算机管理IPOD便携式媒体设备，客户端管理外设。在这个实施例中，通常不需要以外设内容的改变来更新客户端，这是由于通过作为实施这些改变的工具，客户端已经知道了这些改变。在这个实施例中，客户端还可以基于客户端的个体相似性表中的可用数据，保持外设的相似性表是最新的。另外，外设可将反馈数据传递给客户端，以便以后传输给服务器。

在另一个实施例中，外设可以如同客户端自身那样与服务器直接交互。随着越来越多的便携式媒体播放器具有访问Internet的能力，便携式设备可以与服务器直接交互，以便下载最新的相似性数据或更新主购买矩阵。在这种实施例中，外设可具有客户端的所有能力。

产生播放列表

如上面讨论的，以此处描述的方法产生的相似性数据的一种用途是要使用相似性数据产生播放列表。虽然产生播放列表可以与播放个体相似性表内的所有类似项目一样简单，但通过使用播放列表产生模块可能获得最好的结果。图8展示了用于产生播放列表的方法实施例。在步骤802，选择一个或多个种子轨迹，并且在步骤804将其添加到播放列表。在步骤806，在个体相似性表中查找种子轨迹(一个或多个)的相似性数据，并且在步骤808将相似轨迹添加到候选列表。候选是将被添加到播放列表的潜在轨迹的列表。通过根据一系列约束估计候选，确定是否将候选添加到播放列表。

约束用作为歌曲是否可被添加到播放列表的限制。在大部分情况下，约束用于增强播放列表的品质。一个约束可以要求播放列表内的特定间隔。例如，如果歌手间隔约束是活动的，则不紧接着播放Radiohead的两个歌曲。在类似例子中，约束可以防止来自相同专集或歌曲标题的歌曲在播放列表中的给定数目的歌曲内彼此出现。另一个约束将防止不兼容流派的歌曲在相同播放列表中被播放。另一个可以是“抖动”功能。抖动可以随机地防止否则将被接受的歌曲被添加到播放列表中。抖动给播放列表提供随机性以防止每次基于对相同种子轨迹的选择而产生相同的播放列表。另一个约束是跳过计数约束，其中已被跳过多于给定次数的任何歌曲不满足该约束，并且不被包括在播放列表内。

应当理解，约束取决于可以容易地改变的某些参数或变量。例如，可以改变相同专集或歌手的两个歌曲之间的间隔歌曲的所需数目。类似地，可以改变排除轨迹或兼容流派成员所需的跳过计数数目。在一个实施例中，可由用户配置这种变量设置。在另一个实施例中，可由服务器选择并且从服务器发出这种设置，并且只要客户端连接以便下载更新的相似性数据，就可由服务器调整这种设置。

还应当理解，还可以构想正约束。具有高播放率或高评估的歌曲可在播放列表中被向上移动，或可以具有对抖动功能或某些其它负约束的影响的免疫力。通过增加更多限制、去除约束、使得约束更严格或更不严格，可以有许多变型，可以根据此处描述的方法构想变型中的每一个。

在步骤810选择将要考虑的下一个候选，并且在步骤812检索其元数据。元数据提供估计约束所需的关于候选的信息。在步骤814、815和816，按照约束估计轨迹。虽然图8仅示出了3个约束，可以构想可以存在任意数目的可能约束。如果歌曲通过一个约束，其被传递给下一个约束，直到在步骤818通过所有约束，并且将该轨迹被添加到播放列表。此后，方法进入步骤820，并且取得播放列表内的新歌曲的相似性数据。该相似性数据可被附加到候选列表以便考虑包括在播放列表内。

如果轨迹没有通过约束，方法跳到步骤830，并且如果列表中存在将要估计的另外候选，返回步骤810。然而，如果列表中没有其它候选，意味着所有候选或是没有通过约束或是被加入播放列表中，步骤832检查约束以便确定它们是否被设置为其默认值。如果是这样，在步骤828放松约束，以期放松一个或多个约束允许在步骤826在重新考虑之后将以前拒绝的候选添加到播放列表。如果所有候选再次没有通过约束，步骤832确定约束已被放松并且结束处理。

放松约束可以采取各种形式中的任意一种。在某些情况下，仅有一个约束变得较不严格。在其它情况下，放松多个约束。例如，如果第一个约束需要相同歌手的两个歌曲彼此不会在4个歌曲内播放，约束可被放松为仅需要一个间隔歌曲，或该约束可被完全消除。在某些实施例中，不是所有约束都可被放松。一个例子是流派约束。某些流派可能从不兼容，并且因此将不放松流派约束以包括附加流派。

返回步骤826，在候选轨迹没有通过约束并且没有另外候选可用的情况下，约束可被放松。如果由于放松的约束而使候选通过了所有约束并且被添加到播放列表内，约束在步骤822和824返回正常。步骤822检查约束以便确定它们被放松还是处于其默认设置。如果它们处于其默认设置，方法返回步骤810，并且考虑列表内的下一个轨迹。然而，如果步骤822确定约束被放松了，方法进入步骤824，步骤824将约束返回正常，然后回到步骤810以便考虑列表内的下一个候选。该处理继续直到没有候选通过放松的约束，并且例程在步骤834结束。

不必以最相似到最不相似的顺序将歌曲添加到播放列表内；可使用随机算法或其它逻辑以任意顺序添加歌曲。

所产生的播放列表可以是静态的或动态的。随着相似性数据发展和新项目被添加到用户库，动态播放列表可被随时间被更新。可替换地，当产生了用户喜欢并且希望保持不变的播放列表时，用户可将播放列表保存为单独的静态播放列表，该播放列表不再受相似性数据的影响。以这种方式，当用户觉得产生的特定播放列表是“完美的”时，其可被保持为不受通过服务器在相似性表中反映出的大众的变化的品味的影响。

使用相似性数据同步设备

如同可以产生播放列表，还可以使用相似性数据来保持以来自用户的媒体库的新的或不同的音乐更新外设，诸如便携式音乐播放器。许多便携式媒体播放器受到有限容量的困扰，从而不是能够将用户媒体库全部存储在便携式设备上，诸如在IPOD便携式媒体播放器上。在这些情况下，用户通常必须选择其一部分媒体项目存储在其便携式设备上。某些用户可能认为这个过程很烦琐，并且可能发现他们厌倦了当前存储在其便携式设备上的媒体项目。

对上面指出的问题的一种解决方案是使用相似性数据保持以新的媒体项目更新便携式设备。在这个实施例中，用户选择其便携式设备上表示他们喜欢的音乐类型的某个数量的种子轨迹。如同可以根据种子轨迹产生播放列表，还可以选择用户库中的数据项目以包括在便携式媒体播放器中。当相似性数据改变时，并且当新歌曲被添加到用户库时，可以使用相似性数据保持以新轨迹更新便携式设备到最新。

购买推荐

还可以使用相似性数据向用户推荐新项目以便购买。系统可以推荐购买出现在主相似性表内但是未出现在用户库内的项目。在一个实施例中，在线商店可以基于用户库或对种子轨迹的选择做出购买推荐。在线商店还可以使用最近的购买作为种子轨迹，来推荐购买项目。在另一个实施例中，播放列表模块可以通过向用户通知如果歌曲是用户库的一部分，其将被包括在播放列表的什么位置来推荐用于购买的歌曲。购买推荐可以发生在从服务器到客户端到便携式媒体播放器的任意级别。

在某些实施例中，要推荐的项目可能是尚没有与其相关联的相似性数据的新项目。在这种情况下，可由在线商店的管理员提供相似性得分，从而向用户推荐购买该新项目。可以保持所提供的相似性得分，直到可获得基于共同出现的相似性数据或其它具体体现。

类似地，还可以推荐电影租借或购买。虽然根据歌曲描述了大部分实施例，但是媒体项目还可以是包括视频或电影的任意文件。在这个实施例中，基于对种子项目的选择，用户可以请求相似的电影。可替换地，系统可以基于以前的租借推荐电影。甚至可以构想可以使用相似性数据将新电影自动下载到客户端或便携式媒体播放器，以便用户以后观看。该实施例可以是预订服务的一部分，或用户可以选择不观看电影并且不发生租借费用。

图16示出了可以使用相似性数据推荐用于购买的媒体项目的一个方法实施例。在步骤1002，选择种子轨迹。如同基于种子轨迹产生播放列表，购买推荐不基于种子轨迹。然而，在至少一个实施例中，购买推荐可以基于与用户的整个库最相似的内容。

一旦选择了种子轨迹，示出的方法接着在步骤1004从个体相似性表中查找该种子轨迹的相似性数据。在这个实施例中，应当理解，个体相似性表还包含不在用户库内但是通过相似性数据与存在于用户媒体库内的项目有关的媒体项目。在另一个实施例中，购买推荐可以直接来自于服务器，而不是本地存储的相似性表。来自主相似性表的相似性列表可以提供相似性数据，并且服务器或客户端可以去除从用户库中识别出的轨迹。由于不需要包括购买推荐，并且为了推荐目的所有用户共享主表，该实施例具有产生最小的可能的个体相似性表的益处。

为了防止推荐购买已经在用户库内的项目，步骤1006从在步骤1004检索到的相似性数据中滤除已经在用户媒体库内的项目。在某些情况下，媒体项目已被用户购买，但是这些项目未被包括在用户的媒体库内。这可能是出于任意数目的原因，诸如：用户不喜欢该歌曲并且已经将其删除，或用户将该媒体项目存储在另一个库内，或用户可以购买了该媒体项目但是还未下载它。至少在这些情况下，不希望推荐购买这些媒体项目，从而它们都在步骤1008被滤除。步骤1010显示推荐购买的项目。

当然，可以针对用户当前选择的每个歌曲重复该方法。在某些实施例中，用户不需要积极地寻求购买推荐。在这些实施例中，每当选择媒体项目以便回放时，购买推荐可被显示在媒体组织器或媒体商店内。当播放媒体项目时，图形用户界面可以显示其它推荐购买的媒体项目，或媒体项目组，诸如专集。在优选实施例中，可以通过以输入设备选择推荐本身，直接购买媒体项目，或至少该推荐可被超链接到在线商店，从而可以从那里购买该媒体项目。

在另一个实施例中，在选择不可获得的情况下，还可以使用这种方法显示购买推荐。例如，在显示听众也已购买的指定歌手的排名靠前歌曲的View An Artist页面中，系统可以显示滤除了对于已经在用户库内的项目的推荐的推荐。

服务器＞客户端＞IPOD

在一个特别优选的实施例中，可用于一个位置的方法可等同地应用于系统内的每个位置。图9示出了这种概念。在线音乐商店902被示出为包括相似性表908和播放列表模块914。相似性表908包含服务器媒体库存内的每个项目的所有关系。播放列表模块914基于相似性表内的数据进行操作，如同其在系统内的任意其它客户端或便携式媒体播放器上操作一样。类似地，客户端904被示出为包括比服务器所包括的媒体库存小的媒体库存，并且客户端媒体库存内的每个项目的相似性数据被存储在其相似性表910内。播放列表模块916基于本地相似性表910内的数据进行操作，就如同其在便携式媒体播放器906或音乐商店902上操作一样。最后，便携式媒体播放器906被示出为包括比客户端904的媒体库存少的媒体库存。相似性表912存储关于便携式媒体播放器906的媒体库存内的项目的信息，并且播放列表模块918基于该数据操作。

图9示出了对于一组便携式媒体播放器，客户端可以如同服务器那样运作，或者对于较小的客户端，较大的客户端可以作为服务器运作的概念；此处设想了所有这些情况。

在大部分实施例中，服务器是保持主购买矩阵和主相似性表的唯一位置，但是本地相似性表的产生可以基于从服务器得到的数据发生在任意设备上。很可能由服务器执行的另一个功能是更新。在大部分实施例中，服务器不仅是相似性表更新的来源，而且服务器还可以更新系统的播放列表模块或软件组件。

应当理解，不是此处描述的所有处理都必须实时发生。在许多情况下，可能希望节省处理资源，并且离线执行某些任务。例如，可以仅在预定时间运行协同过滤引擎以便产生主相似性数据表。还可以设想随着技术的进步，可以缓解对离线处理的需要。在这些情况下，现在优选为离线执行的那些处理可被实时执行。

在另一个实施例中，虽然每个设备能够本地执行某些功能，但是可能希望服务器执行特定任务。例如，服务器可以为客户端产生个体相似性表或为客户端产生播放列表。客户端为便携式媒体播放器执行这些任务可能更有用，便携式媒体播放器通常缺少大量处理所希望的处理资源。在另一个例子中，服务器执行用于播放列表产生的某些约束，并且将结果结合在相似性表数据中可能是有益的。例如，在从不放松的流派约束的情况下，服务器可以从项目的相似性数据中排除不兼容流派的媒体项目。以这种方式，由于服务器已经从个体相似性表中排除了未通过该约束的项目，所以在产生播放列表时，播放列表模块将不必运行约束。

图10示出了用于向数字媒体播放器同步媒体和相似性表的示例系统。通信介质920最可能是Internet，但是可以包括允许设备彼此通信的任何通道(一个或多个)。在线商店922与客户端924通信，客户端924通常是个人计算机，其安装有特殊软件以便与在线商店通信和交互。便携式媒体播放器926，诸如，APPle IPOD媒体播放器，通常通过30针USB连接器与连接到在线商店922的个人计算机924同步。将便携式媒体播放器926连接到个人计算机924的其它方法包括USB、Firewire、802.11系列或Bluetooth无线连接。在线商店具有媒体主库930和主相似性表932。当同步便携式媒体播放器926时，本地媒体934元数据和本地子集相似性表936通过个人计算机924和通信介质920被传输到在线商店922。重要的是要注意，仅传输元数据而不传输实际媒体。在线商店不需要媒体拷贝，它仅需要足以肯定地识别哪些媒体位于便携式媒体播放器926上的足够信息。在线商店能够产生和/或检索适当信息，并且将其发送回设备，从而以相应于本地存储的媒体934的新数据更新本地子集相似性表936。然后在在线商店级别，在计算机级别和/或在设备本身上使用本地子集相似性表产生个体播放列表。

在另一个实施例中，便携式媒体播放器926可以直接从服务器922获得数据。在这种实施例中，便携式媒体播放器可以配备有诸如通过802.11系列通信(Wi-Fi)或通过移动电话网络连接在线商店的各种能力。便携式媒体播放器可以直接连接到服务器，并且如同上面例子中的客户设备那样执行。可以给便携式媒体分配唯一标识号，或如果库也与客户设备相关联，便携式媒体播放器可以使用与客户设备使用的相同的标识号。不论如何，便携式媒体播放器可以上传关于存储在其库内的媒体项目的信息，并且下载关于这些相同项目的相似性数据。应当理解，便携式媒体播放器可以具有多于一种连接到服务器的方法。便携式媒体播放器不仅可以具有用于连接到在线商店的多种机制，而且便携式媒体播放器还可以具有与客户设备同步和直接与在线商店通信的能力。

用户接口-概要

图11示出了用于启动播放列表产生的示例软件接口。示出了播放媒体、管理媒体和媒体播放列表，允许从在线商店购买媒体，并且执行其它与媒体相关的功能的应用的软件接口702。软件接口702可以显示媒体列表704和某些或全部相关元数据。为了使用通过在线商店接收到的个体相似性表产生播放列表，用户选择一段或多段媒体，并且点击按钮或以其它方式向计算机给出基于所选择的种子轨迹产生播放列表的命令。所构想的适当用户界面包括诸如键盘上的按键序列、鼠标手势、基于触摸的输入、语音命令或这些和其它适合的人机接口的任意组合的特征。一旦被启动，软件应用检索所选择的媒体种子轨迹的相似性表，并且基于该相似性表产生播放列表。该应用可以向用户显示或不显示播放列表的内容。应用可以仅显示当前播放的轨迹或播放列表内容的某个其它子集，诸如紧接的前一个媒体、当前播放的媒体和排队在下一个的媒体。

当选择多于一个歌曲，诸如图11中以阴影示出的条目，以便产生播放列表时，可以通过简单地组合两个条目的相应个体相似性数据，产生播放列表。可替换地，可以使用更复杂的算法来合并两者；例如，给所选歌曲之间共有的媒体分配较高的重要性，并且给看上去不类似所选歌曲两者的歌曲分配较低的重要性或甚至丢弃该歌曲。用户可以控制或可以在应用中事先设置该算法和/或应用在处理多个所选歌曲以便产生播放列表时的行为。

在还可以刷新或重新创建播放列表的实施例中，可以提供以时间先后顺序逐步通过所产生的每个播放列表的向后和向前功能。例如，如果用户形成了播放列表，然后形成了另一个播放列表，用户可以回到前一个播放列表，包括内容和顺序，然后跳回新创建的播放列表-如同浏览器的后退和前进按钮。

还可以创建播放列表而不选择任何歌曲。用户可以简单地选择“Choose For Me(为我选择)”类型按钮706，其可以导致系统为用户选择种子轨迹。在一个实施例中，可以随机选择种子轨迹。在另一个实施例中，系统可以根据当前播放项目的列表、最多播放项目的列表、最高评估项目、最近添加或购买的项目、流派或用于选择项目的任意其它属性选择轨迹。不论如何选择种子轨迹，然后可以基于相似性数据创建播放列表。

用户界面-IPOD/IPHONE/IPOD TOUCH

图12示出了从用户角度根据相似性数据产生播放列表的方法。图12示出了两个可能的开始点720和731。用户可以在步骤720选择媒体项目作为播放列表模块的种子轨迹，或用户可以决定基于用户当前正在听的项目731创建播放列表。用户输入使得菜单被显示724的命令722。可以通过任意用户接口对象，诸如按钮、触摸屏或指针，来输入命令。一旦显示了菜单，在步骤726，用户导航光标以便选择播放列表产生器选项727(参见图13A)并且选择它。在步骤728显示确认屏幕，并且在用户确认之后，在步骤730产生播放列表。

图13A和13B示出了用于开始播放列表产生程序的两个不同上下文菜单。当用户在媒体项目(例如，歌曲列表或现在播放的屏幕内的歌曲)上按压中心按钮723达延长的时间段时，显示上下文菜单。上下文菜单可以包括，尤其是，启动播放列表产生器命令。用户可以通过使用滚轮719顺时针或逆时针移动其手指来进行导航，以便高亮显示播放列表产生器项目，并且按压中心按钮723以便选择高亮显示的区域。

图13C示出了可以在用户在上下文菜单中选择播放列表产生器程序时或在用户例如在媒体回放期间按压中心按钮723达预定次数时出现的屏幕。通过等待将箭头729移动到开始位置的滚轮输入719，该屏幕需要用户对播放列表产生器的激活。用户可以通过按压菜单按钮退出。

图13D示出了说明性的播放列表。能量符号325表示为其创建播放列表的种子(轨迹)。刷新327基于种子创建新播放列表。保存播放列表329保存播放列表，其可从音乐(在最高层菜单结构中)下的播放列表子菜单中或通过选择播放列表产生器程序(在最高层菜单结构中)被检索到。

图14示出了使用播放列表产生器的可替换界面。图14A示出了播放列表菜单，其中可以使用触摸屏选择播放列表产生器模块。用户可以通过以其手指敲击菜单项目，或在菜单项目上移动其手指并且将其手指抬离触摸屏，选择播放列表产生器程序(或任意其它菜单项目)。

图14B示出了种子轨迹选择屏幕，其中用户可以选择播放列表模块将为其创建播放列表的媒体项目。用户可以通过使用手指触摸进行滚动，在媒体项目列表中导航。用户可以使用向下和向上扫动手指的手势使得列表分别按照字母降序或升序的顺序滚动。可替换地，用户可以通过选择对应于字母列表的所希望部分的字母，跳到字母列表的所希望部分。

图14C示出了基于歌曲“Abram”产生的样本播放列表，并且图14D示出了正被播放的该播放列表的第一个轨迹。再次参考图14C，可以使用刷新按钮740根据相似性表中的新数据创建新播放列表，并且图14E示出了刷新后的播放列表播放。

图14F示出了保存按钮742，可以选择该按钮以便将刷新后的列表保存为静态播放列表。可以在图14G中的播放列表菜单中看到保存的播放列表。即使是保存的播放列表也可被编辑。图14H示出了样本播放列表编辑屏幕。在其它实施例中，例如，如果用户希望结束当前种子轨迹的播放列表并且基于当前播放的轨迹创建新播放列表，可以选择播放列表内的歌曲作为种子轨迹。

在另一个实施例中，可以使用遥控器控制客户设备购买歌曲并且创建播放列表。

用户界面-ITUNES

图17A和17B示出了用户选择加入页面的两种可能实施方式。用户选择加入屏幕通知用户关于其个人音乐库的数据将被发送给一个服务，并且需要用户通过点击选择加入按钮1026而选择加入该程序。

图17B示出的图形用户界面还示出了可以启动播放列表产生程序的可选择项目1020和1024。可选择项目1020可以启动媒体项目推荐特征。在优选实施例中，项目1022可以在用于呈现推荐用户购买的项目的图形用户界面内打开图框1025。

图18一般地示出了在上传关于用户媒体库的信息以及接收本地媒体库内容的相似性数据的同时显示的一种可能的图形用户界面。图18A示出了程序收集关于用户媒体库的信息的可能屏幕，该信息在显示图18B所示的屏幕时被传输给服务器。图18C示出了在下载将被存储在这个客户设备的个体相似性表内的信息时所示的可能屏幕。图18D示出了指出用户现在可以使用此处描述的播放列表产生处理和媒体推荐处理的处理完成屏幕。用户在收集、上传和下载信息过程中不必观看这些屏幕-在至少一个优选实施例中，在该处理期间用户可以继续使用图形用户界面的其它特征。

用户界面-ITUNES/工具条

图19一般地示出了用于显示基于相似性数据的媒体项目购买推荐的一个图形用户界面。参考图19A，该图示出了图形用户界面1038，图形用户界面1038可被结合到更大的图形用户界面中，或它可以是独立的界面。在界面1038中，示出了关于一个专集的相似性数据。在这个例子中，选择了White Stripes专辑中的歌曲，并且界面1038显示关于这个媒体项目的相似性数据。模块1040包含一种类型的购买推荐。模块1040内的项目表示相同歌手的专集，包括包含指定媒体项目的专集。在某些实施例中，在该界面中选择专集将展开显示该专集上的所有轨迹的列表。推荐的专集可能尚不能下载，但是可在其发行之前被购买。重要的是，如果用户已经在其库或购买历史中具有一个专集中的所有歌曲，即使该专集是最相关的专集也不显示该专集。然而，如果用户仅拥有专集中的某些歌曲，可以显示该专集，并且将已经拥有的歌曲标出。界面1038仅显示不在用户库或购买历史内的媒体项目。

模块1042显示不在用户媒体库或购买历史内的相同歌手的歌曲。模块1044基于所选择的歌曲的相似性数据推荐媒体项目。预期对于某些歌曲，系统可能不能提供相关推荐，但是在这些情况下，可以向用户给出仍然符合用户收听和购买习惯并且针对他们已经具有的歌曲进行了过滤的更宽推荐。

每个模块1040、1042和1044可以包含任意数目的项目，不必仅是附图中表示的数目。在某些情况下，可能出现比界面一次能够显示的推荐更多的推荐。在这种情况下，界面可以包含滚动条或链接以便观看附加推荐项目。

还可以通过选择图标1041预览每个媒体项目个体。通过选择这个图标，用户可以预览媒体项目个体以便确定他/她是否喜欢该推荐。在某些实施例中，图标1041可以改变为播放按钮，以便更好地指示该项目可被预览。如果用户希望购买该媒体项目，用户可以选择图标1043，这允许用户购买并且获得所选择的项目。一旦购买了该项目，可以显示表示购买的图标或其它工具。在另一个实施例中，一旦项目被购买，它可以成为附加推荐的种子轨迹。

图19B示出了界面1038的可替换布局。在这个布局中，仅显示了框1040和1044。为了占据界面内的附加可用空间，附加媒体项目已被添加到推荐框1044。在至少一个实施例中，由于对于用户来说具有空白的浪费的空间可能令人讨厌，希望以推荐填充所有可用空间。

图19C示出了一个实施例，其中对于所选的媒体项目没有可用的相似性数据。在这个实施例中，框1048指示用户没有匹配可用，并且使用模块1043和1046推荐与选择的媒体项目相同或类似流派的排名靠前的专集。

图19D示出了一个实施例，其中没有相似性数据可用并且也没有流派信息可用(或没有基于流派的推荐)。同样，在框1048中显示向用户通知没有针对所选媒体项目返回的匹配的消息。模块1045可以显示所选媒体项目的排名靠前的相似媒体项目。模块1046可以显示在线商店的排名靠前的专集。

图19E也示出了一个实施例，其中由于用户未选择加入程序或服务器不能发出相似性数据，所以不可获得推荐。可以在模块1048中显示指示没有匹配可用的消息。代替相似性数据，模块1050可以显示相同歌手的其它歌曲和专集作为种子轨迹。在这个实施例中，可以显示在用户的媒体库内的项目。模块1052显示从商店购买信息得出的商店项目。

图19F示出了一个实施例，其中不可获得推荐，并且可以在模块1048中显示指示不可获得推荐的消息。代替推荐，界面在模块1054和1046中示出了来自在线商店的排名靠前的销售表。

本发明范围内的实施例还可以包括用于承载或其上存储有计算机可执行指令或数据结构的计算机可读介质。这种计算机可读介质可以是可被通用或专用计算机访问的任何可获得的介质。作为例子并且不是作为限制，这种计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储设备或其它磁存储设备、或可用于承载或存储计算机可执行指令或数据结构形式的所希望的程序代码工具的任意其它介质。当信息通过网络或另一种通信连接(硬布线的、无线的或其组合)被传输或提供给计算机时，计算机适当地将该连接视为计算机可读介质。因此，任何这种连接可被适当地称为计算机可读介质。上述的组合也被包括在计算机可读介质的范围内。

计算机可执行指令包括例如使得通用计算机、专用计算机或专用处理设备执行某种功能或一组功能的指令和数据。计算机可执行指令还包括由独立环境或网络环境中的计算机执行的程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件和数据结构。计算机可执行指令、相关联的数据结构和程序模块代表用于执行此处公开的方法的各步骤的程序代码工具的例子。这些可执行指令或相关联数据结构的特定序列代表用于执行这些步骤中描述的功能的相应动作的例子。

本领域技术人员将明了，可以在具有许多类型的计算机系统配置的网络计算环境中实践本发明的其它实施例，所述计算机系统配置包括个人计算机、手持设备、多处理器系统、基于微处理器或可编程消费电子设备、网络PC、微型计算机、和大型计算机等。这些实施例还可在分布式计算环境中被实践，其中由通过通信网络链接(通过硬布线链接、无线链接或其组合)的本地和远程处理设备执行任务。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备内。

可以通过网络云328，诸如局域网、令牌环网络、Internet、公司内联网、802.11系列无线信号、光纤网络、无线电或微波传输等执行所描述系统的各个阶段的通信。虽然底层通信技术可能改变，此处描述的基本原理仍然适用。

仅以示例方式提供上述各个实施例，并且这些实施例不应被认为限制本发明。例如，此处的原理可适用于可由便携式媒体播放设备无线访问的或可由物理连接到网络的个人计算机无线访问的在线商店。本领域技术人员容易认识到可以对本发明做出各种修改和改变，而无需遵从此处示出和描述的示例实施例和应用，并且不脱离本公开的真实精神和范围。

Claims (24)

1.一种用于建立程序参与者的媒体库内的媒体项目的相对相似性以便于媒体播放列表产生的计算机实现的方法，所述方法包括：

由服务器从多个程序参与者接收表示相应程序参与者的媒体库库存的数据，所述数据包括当前包含在每个程序参与者的媒体库内的媒体项目个体的标识数据；

确定一对媒体项目个体在不同程序参与者的媒体库中共同出现的发生率；

基于所确定的共同出现的发生率，分配在所述一对媒体项目个体之间的相似性评估；

基于所分配的相似性评估，汇编包含在程序参与者的媒体库内的多个媒体项目个体相对于包含在所述程序参与者的媒体库内的其它媒体项目的相似性评估；和

向程序参与者的设备发送包括包含在所述程序参与者的媒体库内的所述多个媒体项目个体的相似性评估的数据，从而便于从所述程序参与者的媒体库产生相似媒体库项目的播放列表。

2.如权利要求1所述的方法，其中包含在程序参与者的媒体库内的多个媒体项目个体的相似性评估中的每一个相似性评估都具有程序参与者的媒体库内的类似于所述程序参与者的媒体库内的种子媒体项目的媒体项目的列表的形式。

3.如权利要求1-2中任意一个所述的方法，其中由在线媒体提供源收集从所述多个程序参与者接收的累积数据，在所述在线媒体提供源处汇编所述相似性评估。

4.如权利要求3所述的方法，其中在线媒体提供源是在线音乐商店，程序参与者从在线音乐商店购买各个音乐轨迹。

5.如权利要求1-2中任意一个所述的方法，还包括：

基于对相应标识数据的分析，给当前包含在程序参与者的媒体库内的每个媒体项目个体分配源自程序的标识符，从而允许包含在不同程序参与者的媒体库内的大体相同的媒体项目之间的直接相关。

6.如权利要求1-2中任意一个所述的方法，还包括：

从服务器向程序参与者的设备传输至少一个推荐购买的媒体项目的标识，其中基于被评估为类似于当前包含在程序参与者的媒体库库存内的指定媒体项目的推荐购买的媒体项目来选择所述至少一个推荐购买的媒体项目，所述评估表示一对推荐购买的媒体项目与指定媒体项目在不同程序参与者的媒体库内共同出现的频率。

7.一种用于产生媒体播放列表的系统，包括：

用于存储从多个程序参与者的客户设备接收的表示数据的装置，其中所述表示数据来自多个程序参与者的相应媒体库库存，并且包括当前包含在相应参与者的媒体库内的媒体库项目个体的标识数据，而不考虑媒体项目个体的来源；

用于执行相似性数据产生程序的装置，所述相似性数据产生程序从用于存储从所述多个程序参与者的客户设备接收的数据的装置接收表示数据，并且确定媒体项目个体对在不同程序参与者的媒体库内的共同出现的发生率；及

用于发送基于所确定的共同出现的发生率的相似性评估数据给所述多个程序参与者的客户设备的装置。

8.如权利要求7所述的系统，其中客户设备中的至少一个上的存储介质存储相应程序参与者的媒体项目个体的媒体库，并且相似性表包括标识存储在相应客户设备上的媒体项目个体的数据，以及与这些项目中的类似于也存储在同一相应客户设备上的其它媒体项目个体的子集的至少一些项目有关的数据。

9.如权利要求7-8中任意一个所述的系统，还包括：用于产生客户设备上的播放列表的装置，所述播放列表被填充有被识别为类似于所选种子轨迹的媒体项目。

10.一种媒体播放列表产生设备，包括：

用于存储关于媒体项目相似性评估的相似性数据的装置，所述媒体项目相似性评估是基于从多个程序参与者收集的累积数据汇编的，其中累积数据包括包含在所述多个程序参与者的媒体库内的媒体项目个体的标识数据，而不考虑每个媒体项目个体的来源，并且其中所述相似性数据是基于对于一对媒体项目个体在不同程序参与者的媒体库内共同出现的发生率的确定；以及

用于执行播放列表产生程序的装置，所述播放列表产生程序从用于存储的装置接收相似性评估数据，并且根据从在相似性评估数据中标识的媒体项目中选择的候选媒体项目产生播放列表。

11.如权利要求10所述的设备，其中所述用于存储的装置还包含存储在其上的媒体项目个体。

12.如权利要求10所述的设备，其中相似性数据限于属于在各个程序参与者的媒体库中的媒体项目个体的相似性数据。

13.如权利要求11所述的设备，其中包含在用于存储的装置上的多个媒体项目个体的相似性数据中的每一个相似性数据都具有在用于存储的装置上的类似于在所述用于存储的装置上的种子媒体项目的媒体项目的列表的形式。

14.如权利要求10-13中任意一个所述的设备，其中汇编所述相似性数据还包括：基于所确定的共同出现的发生率，在媒体项目个体对之间分配相似性评估。

15.如权利要求12所述的设备，其中所述用于执行的装置还被配置为产生媒体播放列表，所述媒体播放列表仅仅包括包含在程序参与者的媒体库内的并且具有相对于从程序参与者的媒体库中选择的种子媒体项目的相似性评估的媒体项目个体。

16.如权利要求12所述的设备，其中所述用于执行的装置还被配置为产生媒体播放列表，所述媒体播放列表包括包含在程序参与者的媒体库内的并且具有相对于从程序参与者的媒体库中选择的种子媒体项目的相似性评估的媒体项目个体。

17.如权利要求10-13中任意一个所述的设备，其中在媒体播放列表产生设备上产生媒体播放列表，所述设备采取便携式个人媒体播放设备或个人计算机的形式。

18.如权利要求12所述的设备，还包括：

用于接收至少一个推荐购买的媒体项目的标识的装置，其中基于被评估为类似于当前包含在程序参与者的媒体库库存内的指定媒体项目的推荐购买的媒体项目来选择所述至少一个推荐购买的媒体项目，所述评估表示一对推荐购买的媒体项目与指定媒体项目在其它程序参与者的媒体库内共同出现的频率。

19.一种用于建立程序参与者的媒体库内的媒体项目的相对相似性以便于媒体播放列表产生的设备，所述设备包括：

用于由服务器从多个程序参与者接收表示相应程序参与者的媒体库库存的数据的装置，所述数据包括当前包含在每个程序参与者的媒体库内的媒体项目个体的标识数据；

用于确定一对媒体项目个体在不同程序参与者的媒体库中共同出现的发生率的装置；

用于基于所确定的共同出现的发生率，分配在所述一对媒体项目个体之间的相似性评估的装置；

用于基于所分配的相似性评估，汇编包含在程序参与者的媒体库内的多个媒体项目个体相对于包含在所述程序参与者的媒体库内的其它媒体项目的相似性评估的装置；和

用于向程序参与者的设备发送包括包含在所述程序参与者的媒体库内的所述多个媒体项目个体的相似性评估的数据，从而便于从所述程序参与者的媒体库产生相似媒体库项目的播放列表的装置。

20.如权利要求19所述的设备，其中包含在程序参与者的媒体库内的所述多个媒体项目个体的相似性评估中的每一个相似性评估都具有程序参与者的媒体库内的类似于所述程序参与者的媒体库内的种子媒体项目的媒体项目的列表的形式。

21.如权利要求19-20中任意一个所述的设备，其中由在线媒体提供源收集从所述多个程序参与者接收的累积数据，在所述在线媒体提供源处汇编所述相似性评估。

22.如权利要求21所述的设备，其中在线媒体提供源是在线音乐商店，程序参与者从在线音乐商店购买各个音乐轨迹。

23.如权利要求19-20中任意一个所述的设备，还包括：

用于基于对相应标识数据的分析，给当前包含在程序参与者的媒体库内的每个媒体项目个体分配源自程序的标识符，从而允许包含在不同程序参与者的媒体库内的大体相同的媒体项目之间的直接相关的装置。

24.如权利要求19-20中任意一个所述的设备，还包括：

用于从服务器向程序参与者的设备传输至少一个推荐购买的媒体项目的标识的装置，其中基于被评估为类似于当前包含在程序参与者的媒体库库存内的指定媒体项目的推荐购买的媒体项目来选择所述至少一个推荐购买的媒体项目，所述评估表示一对推荐购买的媒体项目与指定媒体项目在不同程序参与者的媒体库内共同出现的频率。

Images