CN101438286A - 一种通过按时计价订购为音乐内容提供数字权限管理的方法 - Google Patents

Abstract

本发明能使数字音乐内容下载到便携式无线计算装置并在其上使用。在无线装置上运行的应用程序无需终端用户输入而自动适应与无线装置相关联的参数(例如，应用程序已经根据装置的OS和固件、相关缺陷、屏幕大小、像素数、安全模式、连接处理、内存等进行了配置)。该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容。该应用程序还包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

Description

一种通过按时计价订购为音乐内容提供数字权限管理的方法

一种能使数字音乐内容下载到便携式无线计算装置并在其上使用的方法。

发明背景

1.技术领域

本发明涉及一种能使数字音乐内容下载到便携式无线计算装置并在其上使用的方法。本专利说明书中使用的术语“便携式无线计算装置”应扩展性地解释为覆盖所有类型的具有双向无线通信性能的便携式装置，无限止地包括无线电话、移动电话、智能电话、通信机、个人计算机、计算机以及专用设备。其包括能够在任何类型的网络，例如GSM或UMTS、CDMA及WCDMA移动式无线电通信、蓝牙、IrDA等之中以任何方式通信的装置。

2.背景技术

过去几年中，音乐发行和消费方式已经发生了极大变化。消费者在商店中购买物理产品在家里聆听的传统方法已经衰落，全世界音乐产业的总收入已经从2000年的接近400亿英镑($40bn)下降到2005年的31亿英镑($31bn)。同时数字音乐在互联网上的发行有了极大的增长，最初是非法文件共享的形式，但到后来付费下载越来越多。便携式数字音频播放器(Portable digital audio players，DAP)，例如苹果公司的iPod^TM，已经对全球音乐市场产生了戏剧性的影响。仅仅在第一个数字音频播放器推出五年之后，全球数字音乐销售在2005年就已经增长到了50亿英镑($5bn)以上。

为了逆转这些趋势，音乐厂牌现在将它们的注意力转向经营移动市场，这里音乐通过移动电话(或其它类型的便携式无线装置)进行销售并在蜂窝无线网络中发行。潜在价值从手机铃声市场的迅速增长中已经清楚，音乐厂牌和移动网络运营商(mobile network operator)MNO都相信，移动全轨音乐与PC上的数字音乐相比，可以带来更多的收入、更好的安全性以及更高的定价。

移动电话比iPod和其它DAP有一些独特的优势。移动电话不但播放音乐，而且连结至日益快速、安全的无线网络，用户可以在该网络中在移动中找到并共享音乐并且利用MNO内置的便捷记账设备对内容进行支付。移动手机制造商日益增长的创新有助于推动市场。

但是，前面仍然存在巨大的挑战。依靠移动互联技术WAP(WirelessApplication Protocol，无线应用协议)作为销售完整音乐内容的主要手段有一定的限制。该技术对用户来说不友好、速度慢并且烦琐。实际上，世界上最大的移动电话集团—沃达丰全球(Vodafone Global)已经因为与WAP相关的终端用户窘境而取消了在除顶尖的3G电话之外的所有产品上销售完整音乐的下载。许多其它运营商也不得不采取了同样的措施。这已经限制了完整音乐下载服务的提升—仅有少数移动电话用户可以使用或可以访问3G。在相对成熟的2005年的英国市场，沃达丰1440万消费者中只有不到50万具有3G—市场渗透约为3％。许多其它运营商没有或仅有很有限的3G渗透。

MNO也关注贫乏的可用音乐播放体验，即使在顶尖的3G手机上。即使装置作为顶尖的音乐手机进行销售，它们通常也难以提供与普通的MP3播放器类似的用户体验。

目前有两种基于WAP获取完整音乐内容的备选方案受到青睐：

·流服务，其向用户提供流向他们的手机的个性化无线电业务。

·在移动电话机上本地运行的音乐购买应用软件，其向用户提供直接从移动电话机购买乐曲和专辑的能力。

但是，流无线电方案是一种特定领域的市场。持续数据连接的要求和用户对其所听内容缺乏完全的控制意味着消费者主张和要求受到限制。流方案还受到有限的手机所及范围和高速(通常为3G)数据连接的要求的影响。运营商执行这样的服务还必须计划和投资显著的网络负担—所有的乐曲在每次播放时都必须重新下载。

音乐购买应用软件提供更有强制力的用户主张，但也受到有限的手机所及范围的影响，集中在3G和特定领域的Symbian手机。这种装置的用户体验目前也受限于竞争产品仅提供每首乐曲支付服务的限制器以及难以接近高质量DAP的丰富程度的有限功能。该有限功能加上相对较小的音乐目录，至今严重限制了这些方案的吸引力。

发明内容

本发明提供一种成熟、可靠和方便的解决方案，其能够使用户在便携式无线计算装置上容易地获取、收听和管理音乐。

一种实施方式称为MusicStation^TM(音乐站)。MusicStation提供一种能使数字音乐内容下载到便携式无线计算装置并在其上使用的方法，该方法包含以下步骤：

(a)在无线装置上运行软件应用程序，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

本发明有希望彻底改变人们获取和收听数字音乐的途径。它首次集合了大量互相促进运行的技术，以提供总体解决方案，其明显大于各部分的加和。例如，因为应用程序可以无需终端用户输入而自动适应与无线装置相关联的参数，所以，向非常大量的便携式无线装置自动提供应用程序就变得可能(在销售之前或允许用户下载并安装应用程序—例如，通过简单地向远程服务器给出正确的便携式无线装置的制造号和型号)。因此，移动电话机的安装基础例如可以很容易地达到如果不是上亿也有上千万—远大于任何DAP。应用程序还能使终端用户利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；因此，不但安装基础远超过任何DAP方案，功能也要强于任何DAP，因为通过无线网络直接从装置搜索并获取新音乐成为可能(这相对于利用台式机器通过基于web的在线目录获取音乐然后使DAP与台式机器同步来说，是自然得多的过程)。最后，应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。这就使得用户能够比以前更有效地查看新音乐，以急剧降低的存储器成本甚至在中等装置上存储上千首乐曲。音乐公司因为耐用的DRM模式、巨大的安装用户基础以及易于查看和获取新音乐而将会乐于制作可用音乐的完整目录。这就产生了一个正反馈，更多更好的内容吸引更多的用户，然后又吸引更多的内容。

MusicStation相对于竞争者来说具有很多关键优势：

·内容广泛并且直观的用户体验，其覆盖了所有的音乐功能；

·由于装置自适应体系(Device Adaptive Architecture，DAA—详见下述)，其比任何竞争者兼容的手机范围都广，装置自适应体系保证软件应用程序能在几乎所有的音乐手机上运行(不管型号或制造厂商)，并且在所有这些手机上看起来是实质上相同的风格并且以实质上相同的风格运行。

MusicStation使移动电话的益处最大化。不同于仅能从室内获取音乐的DAP，MusicStation的用户可以随处发现和获取新音乐；

·MusicStation不需要个人计算机、宽带、iTune或信用卡来工作。

·MusicStation支持创新的新模式、例如：尽你吃够(AYCE)(all-you-can-eat，—也就是不限量下载)以及用户社区特征、例如交友和共享播放列表。

MusicStation产品

MusicStation设计成能使作为不连接的数字音频播放器(DAP)的继承者的移动电话大量采用的关键可行技术。为了保证成功，设计和开发团队致力于跟随关键需求，以交付下一代大量销售的音乐产品：

·超过最好的DAP的用户体验

移动电话上的传统国产播放器与最好的DAP相比时是二流的。MusicStation提供的界面与任何市场领先的DAP一样完备，但其还为联接装置的益处进行了优化。

·最大化连通性益处

移动电话是一种“几乎总是连接”(Almost Always Connected，AAC)的装置，因此，基于手机的音乐产品可以使移动中、而非仅仅在其物理连接至联网的个人计算机时直接购买音乐成为可能。

·确保不依赖于个人计算机

集成的手机产品应该根本不需要用户拥有宽带连接的个人计算机。这在开发市场中格外重要，其中移动电话用户通常不能使用这样的技术，实际上也不能使用信用卡。在用户能够使用个人计算机的情况下，无论他们在书桌前还是在移动中他们都应该能够访问音乐和播放列表—但是不应该依赖个人计算机、宽带或信用卡技术。

·实现直接记账

移动音乐应用程序应该能够平衡消费者和MNO之间的账务关系。通过提供非常方便的用于内容购买的一键记账(one-touch billing)方法—无论位置何处—音乐销售可以真正地最大化，特别是与具有烦琐的还需要很难的与便携式装置同步需求的注册过程的桌前、基于web的信用卡应用相比。

·实现无线收听

手机上的音乐应用程序必须能够使用在许多手机上都可以利用的蓝牙功能，以允许播放音乐以及与其它能使用蓝牙的装置、例如无线耳机、车载立体声和高保真系统共享音乐。

·具有24x7可用度的优势

移动电话是极有可能有24/7用户的电子装置，其给出消费者极其广阔的互动机会，收听、购买和管理音乐。因此，重要的是，音乐应用程序设计成有吸引力，并且，即使对于偶然发现它同时第一次查找手机功能的用户来说也易于使用。

·向用户提供社区特征

作为几乎总是连接(AAC)的装置，移动电话可以在移动中提供社区互动特征，这是通过共享播放列表和用户生成的播放列表图来实现改进的消费者音乐发现的关键。这是相比未连接DAP的关键优势。

·充分利用不规则的手机路标

绝大多数手机在2007年第一季度之前将会有音乐功能—即使它们没有被MNO或制造商积极地推销或标榜作为音乐电话。为了使潜在收入最大化，任何音乐应用程序对每一个音乐功能手机，无论是哪一个制造商的2.5G或3G手机来说，都应该是可用的，以使MNO能够第一次认为完整音乐下载是一个极大的市场机会。

MusicStation就是围绕这些需求进行设计的。最终结果确实能够将绝大部分音乐功能手机变成“超级DAP”。严格地说，MusicStation给出DAP的所有性能和用户体验质量(在音乐播放和管理方面)，同时还提供基于领先个人计算机的在线音乐储库的所有浏览、搜索、获取、播放列表和知名播放列表特征。另外，它还提供音乐用户部落社区特征，这可以提高其音乐发现过程—以及个性化新闻和观点(这些在任何DAP上都是不可用的)。

其它关键特征包括：

·单个用户直观界面，其覆盖所有音乐播放/播放列表管理/内容获取/新闻/社区功能；

·在音乐回放过程中可以获取所有的可用功能(新闻获取、搜索/浏览等等)；

·智能平行下载技术，其允许智能超高速缓存喜欢的内容；

·内置网络识别(特征和界面根据可用网络连通性水平—3G/2.5G/0G—智能调整)；

·直接记账集成(能够极其方便地一键记账而无需信用卡或账号)—用于订购服务的支付基础结构是由控制无线网络的运营商提供的记账基础结构的一部分；

·行业标准音乐文件的DRM保护，DRM还能够实现乐曲的购买，使得乐曲在订购服务终止时仍然可以播放。

不同于DAP，作为连接应用程序的MusicStation第一次能够直接从手机提供每周或每天不限量(All-You-Can-Eat，AYCE)订购包。很多证据表明，每个AYCE订户的平均音乐收入实质上高于传统的PPT(每首支付)用户。目前为止，多数AYCE实施方式是基于桌面的订购，而不是在连接的移动装置上销售。

装置自适应体系(Device Adaptive Architecture，DAA)

移动应用程序目前最大的问题之一就是，将应用程序入栈到新手机上并交付在多个手机制造商和型号中运行的应用程序的难度。解决该挑战是MusicStation所致力于最重要的技术难题之一。装置自适应体系(DAA)就是解决方案。

总体上，相比任何竞争者来说，DAA能使MusicStation应用于更多的移动电话上。它还能使MusicStation在数小时内入栈至新手机，而不是数周或数月—在每种情况下都要有制造商的创新和应用程序的手机型号专用版本。

一直到DAA为止，所有的移动应用程序—无论是音乐专用还是更加通用的—都受到有限的手机所及范围的影响。典型的阻碍包括：

·制造商改变手机设计/存储能力；

·OS和固件发布和相关缺陷(bug)；

·屏幕尺寸、像素数、颜色深度、键区控制以及软键变化；

·物理尺寸；

·媒体文件和格式支持(例如音频、图片、视频、动画)；

·Java版本和平台执行差异；

·手机专用安全模式；

·连接处理和性能；

·无法粘贴到印刷的说明书；

·计算马力和其它计算资源；

·存储器；

·物理性能和终止的处理，包括CSD，GPRS，2G，2.5G，3G，WAP，SMS，蓝牙，红外，Wi-Fi，WiMAX中的一个或多个。

实质上，特征因手机和制造厂商的品牌以及网络运行商而有很大的变化，并且很多手机在使用中可能还会遭遇程序缺陷(bug)。装置自适应体系(DAA)解决了这些问题，并且在本记录的时间内能使产品自动入栈到所有具有音乐功能的2.5G和3G手机中的绝大多数中。DAA获取与这些不同特征相关联的参数，并允许自动为特定手机/网络运行商组合量身定制应用程序而不需要终端用户输入。DAA的进一步详情可以在WO2006/061595号专利文献中找到，改文献的内容以参考引用的方式引用于此。

非常重要的是，要注意MusicStation的基准平台是Java。少数有竞争力的产品建立在易寻址的Symbian平台上。同时为此平台建立应用程序相对容易，其不提供用于主张大量市售音乐的机会。全球少于10％的手机主板具有Symbian，其中许多是商务手机。Java是最为广泛采用的移动平台并且对手机所及范围很关键。其中几乎所有的媒介和高端手机上都可以得到。Java和DAA技术的结合意味着MusicStation可以比任何其他技术交付给更多的消费者，并且，不管制造商或型号都可以严格地执行，看起来和感觉几乎都相同。MusicStation可以在Java、Symbian、Windows Mobile、Linux和BREW中生效。

其他特征包括以下各项：

●应用程序表现为图形用户界面，在其中显示多个用户可选标签，每个标签都与应用程序的核心功能相关联。

○每个标签在应用程序运行的任何时间都可以看到。

○一个标签与主功能相关联，该主功能提供所有可用内容和搜索功能的入口。

○如果选择，一个标签给出当前播放的乐曲的详细资料。

○如果选择，一个标签提供社区和新闻特征的入口。

○如果选择，一个标签显示用于收听和/或下载的乐曲的当前队列。

●应用程序表现为图形用户界面，在其中多个屏幕显示上下文有关的“更多”菜单项，如果选择，即提供更多与当前选项和/或当前显示屏幕有关的功能的入口。

●应用程序利用多任务上下文有关操纵杆进行控制；操纵杆的特定功能由其上的屏幕上的图标表示。操纵杆的操作由键区上的数字键复制，例如，数字键5为上；0为下；7为左；9为右。

●应用程序提供上下文适当获取功能，其中，相当于“获得新艺术家”的功能在菜单中与“艺术家”在同一水平上。相当于“获得新乐曲”的功能在菜单中与艺术家乐曲列表在同一水平上。

●应用程序能使一个装置作为主回放装置，以使其他无线连接的便携式无线装置同时回放相同的乐曲。无线连接可以是短距离的无线连接，例如蓝牙。

●应用程序提供专用的“播放”数字键，其总是触发返回到显示当前播放乐曲的播放屏幕。

●应用程序提供可变的超时设定，不同的屏幕具有不同的超时设定，例如，搜索屏幕从不跳回，但新闻屏幕在20秒之后跳回，与标准的导航屏幕比起来，这可能在7秒之后跳回。

●应用程序显示根据终端用户回放习惯过滤的目标新闻。

●应用程序跟踪并向远程服务器反馈详细的终端用户数据。该数据包括乐曲已经被收听了多久、什么乐曲被跳过、什么时候跳过的。数据可以本地高速缓存到装置并随后作为背负式传输通过无论如何发生的通信发回服务器。装置优先将数据发回，不等待期望无论如何发生的通信，除非用户超过设定时间未下载。该数据可以用于丰富音乐建议引擎，该音乐建议引擎提供用于显示在装置上的乐曲建议。

●应用程序显示共享播放列表。

●应用程序显示用户生成的播放列表图表。

●应用程序的所有功能在音乐回放过程中都有效。

●回放过程中有效的功能包括新闻获取，以及乐曲搜索、浏览和获取。

另一方面是一种便携式无线计算装置，其能够使数字音乐内容被下载和使用，该装置包括：

(a)在无线装置上运行的软件应用程序，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；其中：

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；以及

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

第三方面是一种软件应用程序，其能使数字音乐内容下载到便携式无线计算装置并在其上使用；

(a)应用程序在无线装置上运行，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；其中：

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；以及

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

最后一个方面是利用第三方面所定义的软件应用程序下载的乐曲。

定义

移动电话机：一种通过无线技术经无线电而非经物理接线或其他物理连接或电缆的形式链接到电话网络的电话。

移动电话、电话、移动、移动手机或手机：一种移动电话机。

移动网络：一种为无线电话机提供无线连通性从而使它们可以运行、并提供例如打电话或访问网络常驻数据或服务功能的网络。

移动网络运营商(MNO)：运营移动网络以及使用该网络中的移动电话机的订户或用户的公司或组织。

全球移动网络或移动电话网络：世界上移动网络运营商所运营的所有移动网络的总和。

无线网络：向客户机计算装置提供无线连通性的网络。这样的网络包括Wi-Fi、WiMAX和全球移动网络。

服务器：一种网络化的计算装置，其提供网络化的应用服务、特征和功能，例如信息提供、数据搜索以及向一个或多个与其连接并向其请求服务的计算装置进行交易。通常每个服务器有很多客户机，每个客户机通常比服务器小、并且计算能力小。

服务：网络化的计算服务、特征和功能，典型地由服务器向一个或多个联网的客户机计算装置提供。服务包括信息提供、数据搜索以及交易。这种服务在结构上实用于配置在网络中心，由于客户机的尺寸和能力，典型地不实用于配置在客户机计算机上。

客户机：连接至向应用的用户或消费者交付网络中心应用的特征和功能的网络的计算装置。客户机典型地连接至服务器并请求服务器。

网络应用：一种网络中心的应用或服务，在其中，其由在执行应用界面功能的客户机上运行的软件的组合交付给终端用户或消费者，由服务器上的软件提供的服务支持和补充，改服务器由客户机通过网络访问。

无线计算装置：一种通过无线网络连接至网络的客户机。这种装置包括移动电话机、个人数字助理(PDA)、游戏机(例如Sony的PSP)或其他无线联网客户机计算装置。无线计算装置的类型进一步由其制造厂商、制作、版本、操作系统、固件版本确定。

无线装置或无线客户机：一种无线计算装置。

软件应用程序：通过无线电交付给无线计算装置或预装在无线计算装置上的客户机软件应用程序。

软件构件：软件的个别单元，其形成软件应用程序的构件，为无线计算装置定制，并且是装置自适应体系(DAA)软件库的一部分。

移动内容：表示由移动电话使用、消费、播放、观看或表现的电子产品的数字文件和数据。实例包括铃声/彩铃、墙纸/图片、屏保/动画、原声(realtones)/真声(truetones)、全音乐下载、视频、SMS和MMS警报、移动游戏以及许多其它目前的和新兴的移动电话可以消费的娱乐和信息产品。

元数据：数据或数据集的单个项，潜在地等级相关，其表示无线计算装置、无线网络、软件构件、网络应用或移动内容的属性或性质。

附图说明

图1为调度程序级别图。

图2为客户机对任务进行调度。

图3为UI线程向队列添加任务。

图4为二进制堆的实例。

图5为存储在阵列中的二进制堆。

图6为任务状态图。

图7为每种类型数据对象的高速缓存的上、下限。

图8为用于配置异常的数据对象。

图9为装置特定异常。

图10为屏幕抓图—“获得新...(Get new...)”选项。

图11为个性化菜单项和包含的建议。

图12为屏幕抓图—对项估级。

图13为屏幕抓图—新闻。

图14为屏幕抓图—Buzz会员建议。

图15为个性化菜单项和包含的Cool会员和Buzz播放列表建议。

图16为乐曲之间相互关系的矩阵。

图17为权重矩阵。

图18为一组0到1之间的标准化权重。

图19为关联的艺术家矩阵，其是表示系统中成对的艺术家基于估级相关有多强，并由消费者播放的相关性矩阵。

图20为关联的消费者矩阵，其是表示系统中成对的消费者基于估级相关有多强，并由消费者播放的相关性矩阵。

图21为相关矩阵特性、输入建议和结果机制表的一部分。

图22为相关矩阵特性、输入建议和结果机制表的一部分。

图23为相关矩阵特性、输入建议和结果机制表的一部分。

图24为相关矩阵特性、输入建议和结果机制表的一部分。

图25为相关矩阵特性、输入建议和结果机制表的一部分。

图26为计算隐含估级值。

图27为讯息的特性。

图28为图像的特性。

图29为客户机版本的特性。

图30为翻译的讯息。

图31为装置讯息特性。

图32为装置讯息/帮助讯息特性。

图33为服务讯息。

图34为服务和装置特定讯息。

图35为客户机编译讯息。

图36为屏幕抓图—漫游选项。

图37为用于MusicStation的漫游性质的配置。

图38为屏幕抓图—漫游警告。

图39为屏幕抓图—漫游警告—询问提示。

图40为屏幕抓图—漫游警告—询问提示。

图41为屏幕抓图—漫游选项设置为开。

图42为屏幕抓图—漫游选项设置为关。

图43为标题、内容和反应结果的显示。

图44为客户机与服务器之间请求/反应的流程。

图45为服务器向客户机发送请求。

图46为[主要].[次要].[微]、别名和平台标识符的详细资料。

图47为错误数据的详细资料。

图48是客户机向服务器发送错误数据的实例。

图49是客户机向服务器发送错误数据和照片的实例。

图50是服务器发送具有单一参数的Jpeg照片的实例。

图51为状态编码。

图52表示服务器发送news1.data文件。

图53表示服务器发送news2.data和news3.data文件。

图54为服务器反应，其表示数据已发送到多大的范围。

图55为服务器发送发送线，客户机在请求中未发送相应的收到线。

图56表示包含发布集的艺术家数据对象。而发布又包含乐曲集。

图57表示一种可选方法将每个对象集存储到其自身文件中。因此在我们“我的艺术家”实例中，艺术家列表存储在文件中(userartists.data)而每个艺术家的专辑列表不在。专辑列表存储在单独的艺术家文件中，每个艺术家一个(例如artist.123.data)。每个专辑之后存储在其包含乐曲的自身文件(release.4567.data)中。

图58表示对象组如何可以利用相同的数据对象而不必重复数据。

图59表示一个可以将艺术家名称以及id存储到“我的艺术家”数据文件中。

图60为客户机设置对象及获得所有修改的对象。

图61是客户机请求对象及获得所有修改的对象。

图62是客户机在离线模式中发送修改的对象。

图63是对象变更日志。

图64是消费者对象。

图65是消费者对象变更日志。

图66是变更日志记录对象。

图67是对象_变更_日志(object_change_log)表。

图68是消费者_对象_变更_日志(customer_object_change_log)表。

图69是包含用于每个客户机日志的日志记录(LogRecord)的记录器。

图70是消费者_记录器(customer_logger)表。

图71是DRM概览。

图72是服务注册请求参数。

图73是MNO增加的元数据。

图74是服务注册响应参数。

图75是MusiStation RI注册请求参数。

图76是RI注册响应参数。

图77是MusiStation RO获取请求参数。

图78是MusiStation RO获取响应参数。

图79是内容获取请求参数。

图80-164是MusicStation实施的截屏。

图165是系统总图。

具体实施方式

架构

1.1.多线程

播放器的一个关键方面是就是同时执行多线程。有3个主要的线程：

·用户界面(UI)线程

·动画线程

·调度程序线程

还有HTTP连接线程，该线程实际上下载数据并将其载入缓冲器中，同时调度程序线程从该缓冲器读取，以免被连接阻碍。

典型地，UI线程通过显示新屏幕并调度任务以将数据从本地文件系统或通过HTTP连接远程载向屏幕之后来迅速响应定位到该新屏幕的用户。

载入的任务添加到任务队列。队列由任务优先权、任务类型和调度的执行时间排序。大部分任务都被调度以立即执行，在这种情况下，执行时间设定为任务添加到队列中的时间。某些任务被调度成很短的延迟，例如播放乐曲被调度成一秒钟延迟，以允许快速跳过播放列表中的乐曲。

当新任务添加到任务队列中时，我们将其优先权与当前执行的任务(如果有的话)进行比较。如果其优先权高于当前任务，我们则试图取消当前任务。只有那些要花过多时间完成的任务才可以被取消。这是要避免任务扰乱执行线程而其它的更高优先权的任务在等待。时间的过多量超过几秒钟。取消的任务接着被重新调度。执行时间被设定成任务最初添加到队列中的时间。

1.1.1.调度程序

调度程序是一种为线程调度任务立即或将来在背景线程中执行的机制。任务可以调度成一次执行或以规则的间隔反复执行。

调度程序对象具有用于依次执行所有调度线程的任务的单一背景线程。如果调度程序任务花费过多时间完成，其“占着(hog)”计时器的任务执行线程。这会进而延迟后续任务的执行，这就会“聚成一团(bunchup)”。任何会花费大于几秒钟执行的任务都必须执行中断()。

中断()方法在具有较高优先权的任务被加到任务队列中时被调用调用，并且会被添加任务的线程调用到当前执行的任务。调度程序线程调用的运行()方法必须在最早的机会中发出中断异常(InterruptedException)。调度程序获取该异常然后重新调度中断的任务，以基于其优先权和其最初被加到队列中的时间来执行。最新添加的任务然后被挑选并执行。

本级是线程安全的：多线程可以共享单一调度程序对象而无需外同步。见图1：调度程序级别图和图2：客户机调度任务。

1.1.1.1.任务队列

本级代表调度程序任务队列：按优先权、任务类型和执行时间排序的任务优先权队列。

任务优先权基于CLDC线程优先权。因而，有3种确定的优先权：

●MAX_PRIORITY是任务能具有的最大的优先权。

●NORM_PRIORITY是分配给任务的默认优先权。

●MIN_PRIORITY是任务能具有的最小的优先权。

具有相同优先权的任务进一步被按照任务类型进行细分。例如，这允许我们为图像前的屏幕调度数据。这可以通过使用不同的优先权实现，然而我们很可能想要降低任务的优先权(例如，用户导航到不同的屏幕)而不改变类型。通过将优先权和任务类型的概念分离，该设计更有灵活性，并且我认为更易于理解，3种类型通过重要性最初排序为：

●DATA用于请求对象数据文件的任务。

●AUDIO用于请求音频文件的任务。

●IMAGE用于请求图像文件的任务。

执行时间确保具有相同优先权和任务类型的任务以它们加入队列时的顺序执行。见图3：UI线程向队列添加任务。

在内部，队列作为二进制堆存储，所以调度任务的成本为log n，其中n为当前调度的任务数。存在大量(成千)调度的任务应该没有问题。检索下一个调度的任务是没有成本的，下一个调度的任务总是处于根上。见图4：二进制堆的实例。

我们总是向堆的底部添加元素，然后调用固定(fixUp)()方法在堆中寻找其位置。固定()方法将添加的元素与其父代进行比较，如果它们处于不正确的顺序则将它们进行交换。

利用阵列来存储堆，因为堆总是完整的(绝不会有任何裂隙在树中)，所以其可以压缩存储。指针不需要空间；相反，对于每个索引i，元素a[i]是两个子代a[2i+1]和a[2i+2]的父代。见图5：存储在阵列中的二进制堆。

1.1.1.2.任务

任务可以调度成依次或反复执行。任务可以是以下3种状态中的一种：

●SCHEDULED任务调度成执行。如果其为非重复任务，则其尚未执行。

●EXECUTED：该非重复任务已执行(或者当前正在执行)并且尚未取消。

●CANELLED：该任务已取消(调用Task.cancel)。

见图6：任务状态图。

MusicStation客户机使用单一的调度程序从本地文件系统或通过HTTP连接远程调度所有的文件连接。调度程序使用单一的线程，所以所有文件连接连续处理。任务必须确保在其处于执行状态时只有一个开放连接。由于只有一个任务处于执行状态，所以我们可以保证我们只有一个连接开口。而且，任何支持中断()方法的任务都必须能够重新开始而不存储任何有关其写入的文件的状态信息。这很重要，因为另一任务可以修改文件，由于任务被中断了。

1.1.2.使用情况

1.1.2.1.用户打开播放列表

用户打开应用程序并立即打开播放列表菜单。播放列表菜单显示“我的播放列表(My Playlists)”播放列表组(PlaylistSet)，该播放列表组使用两个过滤器“我私人的播放列表(My Private Playlists)”和“我公共的播放列表”进行过滤。

当屏幕显示载入任务(LoadTask)已加入任务队列(TaskQueue)以载入“我的播放列表(My Playlists)”。LoadTask.taskType为DATA，LoadTask.priority为MAX_PRIORITY。

当载入任务加入到任务队列中时，通知在队列中等待的调度程序线程。其从队列获得任务并通过调用任务.运行(Task.run)()方法执行。任务进行检查以了解“我的播放列表(My Playlists)”对象数据文件是否在文件系统中存在。这种情况下，其不存在，所以HTTP连接(HttpConnection)打开，文件通过流读取。文件被读取到缓冲器(65k)中，并且在缓冲器每次被填满时将其写入存储卡中，用于占据部分或全部数据对象(注意，很少数据文件会大于缓冲器)。

由于播放列表组(PlaylistSet)数据对象被播放列表占据，所以这些播放列表包含图像基准。由于这些图像基准每个都被读取，所以生成图像载入任务(ImageLoadTask)并将其添加到任务队列中。图像载入任务.任务类型(ImageLoadTask.taskType)为IMAGE，图像载入任务.优先权(ImageLoadTask.priority)为MAX_PRIORITY。

一旦“我的播放列表(My Playlists)”完成载入，调度程序从队列中获取第一个图像载入任务(ImageLoadTask)。因为图像在本地文件系统中不存在，所以其通过HTTP载入。这一直持续到所有的图像都已被载入。

1.1.2.2.用户打开播放列表并立即选择新播放列表

用户打开应用程序并随后打开播放列表菜单。在载入“我的播放列表(My Playlists)”之前，用户选择“获取新播放列表(Get New Playlists)”。

如上所述，用户打开播放列表时，载入任务(LoadTask)立即加入任务队列(TaskQueue)以载入“我的播放列表(My Playlists)”。LoadTask.taskType为DATA，LoadTask.priority为MAX_PRIORITY。

在载入任务完成之前，用户选择“获取新播放列表(Get NewPlaylists)”。这立即调用任务队列.变更优先权(TaskQueue.changePriority)()以将所有的MAX_PRIORITY任务降级到NORM_PRIORITY，因为我们正在变更屏幕。最后屏幕的任何未完成的任务需要具有比新屏幕任务低的优先权。

然后将载入任务添加至任务队列以载入“新播放列表(NewPlaylists)”。载入任务.任务类型(LoadTask.taskType)为DATA，载入任务.优先权(LoadTask.priority)为MAX_PRIORITY。添加新任务导致中断()被调用到“我的播放列表(My Playlists)”载入任务。由于数据对象典型地很小(小于4k)，所以中断被忽略不计。然而，因为“我的播放列表(MyPlaylists)”载入任务已经使其优先权低于NORM_PRIORITY，所以其生成的任何图像载入任务(ImageLoadTasks)也生成NORM_PRIORITY。

一旦“我的播放列表(My Playlists)”载入任务完成载入，调度程序从队列中获取“新播放列表(New Playlists)”载入任务并执行。一旦“新播放列表(New Playlists)”已经载入，用于“我的播放列表(My Playlists)”屏幕的图像就载入到背景中。

1.1.2.3.用户开始播放列表

用户从“我的播放列表(My Playlists)”选择播放列表并选择播放选项。

播放列表中的所有乐曲都添加到播放队列中。开始任务(StartTask)为第一首乐曲添加到任务队列中。开始任务.任务类型(StartTask.taskType)为AUDIO，开始任务.优先权(StartTask.priority)为MAX_PRIORITY。我们然后为每个乐曲向任务队列添加存取任务(FetchTask)。存取任务.任务类型(FetchTask.taskType)为AUDIO，存取任务.优先权(FetchTask.priority)为MIN_PRIORITY。注意，存取任务为每首乐曲添加，包括第一首乐曲。这是因为，开始任务(StartTask)在完成之前可以被用户选择下一个(Next)而取消。存取任务(FetchTask)将首先检查以了解文件是否存在以及是否在实现Http连接之前已经完全下载。

当开始任务(StartTask)已经完成(并且开始播放乐曲)时，为第二首乐曲添加预取任务(PrefetchTask)。预取任务.任务类型(PrefetchTask.taskType)为AUDIO，预取任务.优先权(PrefetchTask.priority)为MAX_PRIORITY。根据连接速率，在第一首乐曲结束之前第二首乐曲就应该已经预取了。在这种情况下，第一和第二预取任务被放弃(文件已经存在)，开始下载第三首乐曲的预取任务。

1.1.2.4.用户开始播放列表并打开收件箱(Inbox)

用户从“我的播放列表(My Playlists)”选择播放列表并选择播放选项。下载第一首乐曲的中途用户打开收件箱标签。

如上所述，为第一首乐曲添加开始任务(StartTask)，为每首乐曲添加存取任务(FetchTask)。当用户打开收件箱时，为“收件箱(Inbox)”历史组(StorySet)生成载入任务(LoadTask)。载入任务.任务类型(LoadTask.taskType)为DATA，载入任务.优先权(LoadTask.priority)为MAX_PRIORITY。

将开始任务的优先权从MAX_PRORITY变成NORM_PRIORITY，并且将“收件箱(Inbox)”载入任务(LoadTask)添加到任务队列中。中断()方法被调用到开始任务，这导致开始任务.运行(StartTask.run)()方法发出中断异常(InterruptedException)，下一次读取()返回(当65k的缓冲器填满时)。调度程序获取该中断异常并重新调度开始任务，以在“收件箱(Inbox)”载入任务(LoadTask)之后运行。

执行“收件箱(Inbox)”载入任务(LoadTask)，其为每个故事生成图像载入任务(ImageLoadTasks)。其生成具有MAX_PRIORITY并在重新开始开始任务之前全部被执行。

一旦图像载入，通过首先检查文件是否存在及已经读取了多少来重新开始开始任务。然后任务将请求其余音频文件。一旦文件已经被下载，乐曲将播放，并且将为下一首乐曲添加预取任务(PrefetchTask)。

1.1.3.背景下载

1.1.4.动态播放列表管理

1.2.智能存储管理

MusicStation智能化管理每个手机上可利用的存储和/或存储卡。

●在下载对象之前，MusicStation将确保有足够的可用存储用于对象。

●如果没有足够的空间，MusicStation在删除对象之前将执行一系列检查。

●MusicStation将删除具有最后修改时间最长的数据的对象，确保删除的对象是不重要的或根本不用的文件。

1.2.1.下载对象

在MusicStation内有三种类型的可下载对象。这包括：

●数据—任何需要更新的数据，例如菜单项、图表、新闻文章内的文本等等。

●图像—MusicStation内的任何图像。这包括关于艺术家的图像以及专辑外观和与新闻文章相关的图像。

●音频—音频文件。

高速缓存(Caches)

利用选项菜单上的最大存储卡使用选项，用户可以确定MusicStation将用于存储的存储卡的最大百分比。此设定确定分配给MusicStation的存储。分配的存储随后被分成用于各类型数据对象的高速缓存。

高速缓存为每种可下载的对象而存在。每个高速缓存具有上限和下限：

●上限是高速缓存可以利用的存储的最大量。它用于确保用户不超过分配的存储。

●下限是高速缓存可以利用的存储的最小量。它用于确保存储始终分布在不同的数据对象之间。

上限和下限定义为分配的存储的百分比。用于各种类型数据对象的高速缓存的上、下限如图7所示定义。

1.2.2.下载对象

在下载对象之前，MusicStation将运行一系列检查，以确保下载文件之前上、下限未被突破。MusicStation保持各种类型对象的列表，其按照最后使用的顺序分类。最近使用的对象处于列表的顶部，有最早使用的数据的对象位于列表的最低部。

如果对象的下载超过该对象高速缓存的上限，则出现以下过程：

●删除_而不_检查(DELETE_WITHOUT_CHECK)—MusicStation将删除同种类型具有最早“最后使用的”数据的数据对象。

如果没有可用的存储来下载对象，在出现以下过程：

●删除_有_检查(DELETE_WITH_CHECK)—

删除_有_检查(DELETE_WITH_CHECK)将定位同种类型具有最早“最后使用的”数据的数据对象并试图删除该对象。如果其不带来低于下限的高速缓存，则进行删除。

如果删除带来有低于下限的高速缓存，删除_有_检查(DELETE_WITH_CHECK)将定位具有最早“最后使用的”数据的音频对象并删除音频对象。

如果删除_有_检查(DELETE_WITH_CHECK)不能删除音频对象，其将进行步骤1.定位同种类型具有最早“最后使用的”数据的数据对象并删除该对象。

1.3.装置特定媒体发送

每块内容“标记(tag)”有容器、格式、比特率和取样速率(例如m4a，acc+，48kbps，44.1kHz)。内容的回放在装置上利用一块基本内容(粉红噪声)进行测试，该基本内容以容器、格式、比特率、取样速率和多用途的网络邮件扩充协议类型的所有变量编码。这些测试的结果通过测试客户机发送回服务器并存储。容器、格式、比特率、取样速率和多用途的网络邮件扩充协议类型中的每个与其它存储在服务器中的相比时都有优选项。当客户机随后请求附加的内容块时，服务器或者返回：连接到该块内容的列表，该块内容以回放的容器、格式、比特率、取样速率和多用途的网络邮件扩充协议类型的所有变量编码。这通过将回放内容的“标签”匹配到附加内容块的可用“标签上来完成。该列表按照优选项排序。连接到该块内容的链接编码成最高编码优选项。音频回放质量测试在该自动选择项上执行，以确认其质量是可接受的。如果不是，则审查第二优选项，诸如此类沿列表向下。音频质量测试利用音频软件来分析电话耳机插口的输出。

2.用户体验特征

2.1.客户机异常处理

MusicStation客户机有规律地在背景中下载和上载文件，同时客户机使用应用程序。当出现错误时，根据正在执行的任务和所出现的错误，我们可能会想重试、通知用户或什么也不做。本文件说明当错误出现时我们如何决定采取什么行动。

2.1.1.异常收听者

控制MusicStation客户机的有3个主要线程。UI线程处理所有键按压，涂画线程处理所有的屏幕刷新，任务线程处理载入数据。异常可以发生在所有这些线程中，但它们总是通向异常收听者异常出现(ExceptionListenerexceptionThrown)()方法。

异常收听者(ExceptionListener)随后基于以下各项确定如何处理异常：

发生的异常

引起异常的事件

事件的优先权

异常的超类

这些参数用于为该异常查找异常配置(ExceptionConfig)。异常配置(ExceptionConfig)包含确定如何处理异常所需的所有信息。

2.1.2.异常配置(Exception Config)

异常配置(ExceptionConfig)用于确定是否自动重试引起异常的事件或是否向用户显示错误讯息。

以下对象用于配置异常：

异常配置(ExceptionConfig)：包含用于该异常的默认性质。

异常事件(ExceptionEvent)：重置用于特定事件和优先权的默认性质。

异常语言(ExceptionLang)：包含装置支持的各种语言的错误信息。

见图8用于配置异常的数据对象。

只有出现在任务线程中的异常才引起重试。以下属性用于确定是否及如何重试任务：

第一次重试间隔(firstRetryInterval)：我们可能会想快速一开始重试请求

第一次重试计数(firstRetryCount)：重试次数或0不重试

第二次重试间隔(secondRetryInterval)：我们可能会想后退并在重试之间留下一个更长的周期

第二次重试计数(secondRetryCount)：重试次数或0不重试

允许一段时间重试(allowSessionRetry)：如果有服务器错误或者文件未找到，我们可能会想在这段时间不允许向服务器提出相同的请求。

删除本地文件(deleteLocalFile)：如果文件有错误，我们可能会想删除本地文件并从服务器重试载入文件。

任何异常都可以向用户显示错误讯息。以下属性用于确定是否向用户显示及显示什么。

显示警告(showAlert)：如果是真的，向用户显示错误讯息，以及一个或多个选项

继续选项(continueOption)：回到上一屏幕

重试选项(retryOption)：重试任务

升级选项(upgradeOption)：安装应用程序新的版本

关闭选项(closeOption)：关闭应用程序

打开浏览器选项(openBrowserOption)：在移动WAP浏览器中重试请求

异常语言(exceptionLangs)：各支持语言的错误讯息

对于任何异常，这些值都可以为特殊的事件而超越，或者我们可以后退到为异常的超类而确定的值。

2.1.3.装置特定异常

某些装置不发生预期的异常。例如诺基亚N70在服务器不响应时以讯息“-34”发出IO异常(IOException)，而不是更特定的“连接未发现异常(ConnectionNotFoundException)”。装置异常配置(DeviceExceptionConfig)对象允许我们指定装置特定异常和预期异常之间的映射。

以下字段将装置特定异常映射至预期异常：

异常类名(exceptionClassName)：装置产生的异常。

异常串(exceptionString)：异常.至串(Exception.toString)()方法的结果。

异常Id(exceptionId)：要映射向的已知的异常。

见图9装置特定异常。

2.1.4.数据库要求

client_build

event_type_set_idFKnumber(10)not NULL

exception_set_idFKnumber(10)not NULL

事件和异常设置在编译时生成，索引在运行时使用，以映射在客户机和服务器之间发送的事件和异常。

event_type

priorityvarchar(12)DEFAULT NORMAL，in(MIN，NORMAL，MAX)

优先权用于确定哪些事件首先从客户机发送到服务器。优先权和重要程度都可以由服务器更新到客户机上。

event_type_set

idPKnumber(10)

automaticnumber(1)not NULL，default 0

countnumber(12)not NULL，default0

guidvarchar(32)not NULL

namevarchar(96)not NULL

data_classification

created

inserted

modified

事件的设置为客户机编译而生成。该设置在运行时使用，以将客户机发送的事件映射到数据库中的事件类型。

event_type_set_item

event_type_set_idPKnumber(10)not NULL

event_type_idPKnumber(10)not NULL

event_type_namevarchar(96)not NULL

event_type_indexnumber(10)not NULL，UNIQUE INDEX

data_classification

created

inserted

modified

索引是客户机事件和服务器上的事件类型之间的映射。索引将在事件类型(EventType)数据库对象中定义为常数。客户机代码中事件的所有引用位置将使用该常数。

exception_set

idPKnumber(10)

automaticnumber(1)not NULL，DEFAULT 0

countnumber(12)not NULL，DEFAULT 0

guidvarchar(32)not NULL

namevarchar(96)not NULL

data_classification

created

inserted

modified

异常的设置为客户机编译而生成。该设置在运行时使用，以将客户机发送的异常映射到数据库中的异常。

exception_set_item

exception_set_id PKnumber(10)not NULL

exception_idPKnumber(10)not NULL

exception_namevarchar(96)not NULL

exception_indexnumber(10)not NULL，UNIQUE INDEX

data_classification

created

inserted

modified

索引是客户机异常和服务器上的异常之间的映射。索引将在异常配置(ExceptionConfig)数据库对象中定义为常数。客户机代码中事件的所有引用位置将使用该常数。

exception

idPK number(10)not NULL

guidvarchar(32)not NULL

namevarchar(96)not NULL

event_type_idFKnumber(10)not NULL

class_namevarchar(128)not NULL

superclass_namevarchar(128)

first_retry_intervalnumber(10)

first_retry_countnumber(10)

second_retry_intervalnumber(10)

second_retry_countnumber(10)

allow_session_retrynumber(1)

delete_local_filenumber(1)

show_alertnumber(1)

continue_optionnumber(1)

retry_optionnumber(1)

upgrade_optionnumber(1)

close_optionnumber(1)

open_browser_optionnumber(1)

message_key_idFKnumber(1)

descriptionvarchar(256)

commentsvarchar(256)

data_classification

created

inserted

modified

包含控制如何处理客户机上发生的异常的字段。异常配置在编译时包括在JAR中，并且可以在运行时由服务器在客户机上更新。

exception_event

exception_idPKnumber(10)

caused_by_event_type_idPKnumber(10)

event_priorityPKnumber(10)in(ALL，MIN，NORMAL or MAX)

first_retry_intervalnumber(10)

first_retry_countnumber(10)

second_retry_intervalnumber(10)

second_retry_countnumber(10)

allow_session_retrynumber(1)

delete_local_filenumber(1)

show_alertnumber(1)

continue_optionnumber(1)

retry_optionnumber(1)

upgrade_optionnumber(1)

close_optionnumber(1)

open_browser_optionnumber(1)

message_key_idFKnumber(1)

event_indexnumber(10)

descriptionvarchar(256)

commentsvarchar(256)

data_classification

created

inserted

modified

异常处理可以为特定事件和特定事件优先权超越。

device_exception

device_idPKnumber(10)

exception_class_namePKvarchar(128)

exception_stringPKvarchar(256)

exception_idFKnumber(10)

automaticnumber(1)not NULL，DEFAULT 0

data_classification

created

inserted

modified

将装置特定异常映射到已知异常上。该表格在装置试运行过程中通过侦测占据。

2.2.建议

本文件说明了采用从MusicStation应用程序内向消费者提建议的方法。奥沐尼芬(Omnifone)将提出不断变化、关联的和最新的建议的能力视作对MusicStation应用程序产生忠诚度策略的关键。真确实施的建议鼓励探索和发现，这又导向对新音乐更多的购买。它们另外又允许我们在有限的移动环境中优化MusicStation体验。

2.2.1.MusicStation内的建议

MusicStation包含多种用于向消费者提出个性化建议的特征。这些特征遍布在主页(Home)、收件箱(Inbox)和Buzz标签中，并在以下部分中详细说明。

2.2.1.1.主页标签上的建议

见图10屏幕抓图—“获得新...(Get new...)”选项。

无论何时，只要消费者从“主页(Home)”标签选择了“获得新播放列表(Get new playlists)”、“获得新艺术家(Get new artists)”、“获得新专辑(Get new albums)”或“获得新乐曲(Get new tracks)”选项，就向他们显示菜单选项的列表，其中某些是基于消费者最近的收听习惯向他们提出的个性化建议。

包含个性化建议的菜单项示于图11。

2.2.1.2.影响音乐建议的信息

用于主页标签的音乐建议基于两个只有消费者才有的因素的互动生成。

隐含因素：这基于消费者的收听习惯(即，他们收听的音乐的类型以及他们收听的频率)。

外在因素：消费者如何实际估级他们所收听的音乐。

另外计算隐含因素就是任何在消费者制作的收件箱内容上的点击(详细信息请参见2.2.1.4部分—Buzz标签上的建议)。

见图12屏幕抓图—对项估级。对于隐含因素，向消费者提出类似于他们已估级为喜欢的其它音乐的音乐的建议，不向他们建议任何类似于他们已估级为讨厌的音乐的内容。

2.2.1.3.生成音乐建议

这些用于每个消费者的隐含因素和外在因素结合起来，并且与艺术家和其它艺术家之间、乐曲与其它乐曲之间的已知关系等等混合起来。结果就是向消费者提出的个性化建议列表。

随着时间的流逝，由于我们收集了有关哪个艺术家、专辑、乐曲和播放列表受欢迎(或不受欢迎)的信息，这些建议将变得非常贴合于消费者最想要寻找的是什么。系统将自动向消费者推出与消费者收听或购买的顶尖艺术家/专辑和乐曲具有直接关系的最受欢迎的艺术家、专辑或乐曲。

2.2.1.3.1.“最近(recency)”的重要性

建议仅在消费者最近收听习惯的基础上而不是他们在所有时间里的收听习惯的基础上生成，这一点非常重要。这确保建议在生成时与消费者最相关，并且不是由受到可能言行变化非常大并且品味有变化的消费者影响的非常宽泛的建议的含糊不清的包装组成。

对于MusicStation，最近(recency)由消费者已经收听或购买的最后N个艺术家/专辑/乐曲或播放列表定义。N的实际值可基于观察配置，以使建议过程能够随时间精细调节。

2.2.1.4.Buzz标签上的建议

2.2.1.4.1.对新闻的建议

见图13屏幕抓图—新闻。所有新闻内容(新闻故事、时间通知、特殊艺术家的宣传等等)都基于主页标签中说明的相同的隐含因素和外在因素对消费者个性化。另外，如前所述，用户点击新闻内容时，例如连接到艺术家主页的宣传，该事件就会被追踪，然后在整个建议过程中用作对该艺术家的“正向选举”。

2.2.1.4.2.对Buzz会员的建议

见图14屏幕抓图—Buzz会员建议。

Buzz标签包含两个主要的要素，这两个要素包含导向每个单个消费者的建议。这在图15的表中进行说明。

对成员的建议(即MusicStation消费者)通过将音乐收听和估级历史类似的消费者链接起来完成(系统在中心计算消费者对所有其它消费者的“亲和力(affinity)”，并选择那些对消费者亲和力水平最高的)。

如果消费者选择了建议的成员，他们就可以收听并估级共享的播放列表。

2.2.2.做出建议的支持逻辑结构

我们有三种主要的结构来支持做出这些建议

■关联乐曲矩阵(Associated Tracks Matrix)

■关联艺术家矩阵(Associated Artists Matrix)

■关联消费者矩阵(Associated Customers Matrix)

我们将在后面的部分讨论系统的物理基础结构。目前足以考虑这些结构会频繁刷新(每24小时一次)。

2.2.2.1.支持结构1-关联乐曲矩阵

关联乐曲矩阵是表示乐曲对基于估级和消费者播放在系统中关联性有多强的相关性的矩阵。

2.2.2.1.1.阶段1-生成乐曲关联的计数

对乐曲我们将建立类似于上一个的矩阵，代表：

将对中的乐曲已经或者/或全部播放或已经估级为喜欢的消费者的计数。

重要注解和规则

图16中的矩阵仅考虑了5首乐曲的域。我们可预期考虑500,000个来加入生产环境许可(go-live)。

为了作为计数包括在1)中，所述的用户必须完整听过(如许可协议所定义的)至少两遍。这之后的基本原理就是，如果消费者听过乐曲多于一遍，那么他们可能就会喜欢上它。如果他们仅听过一遍乐曲，那么他们可能只会探查新音乐，而不会有足够深刻的印象来回到该乐曲。

如果消费者将两个乐曲对高度估级，并且每个都听过两遍以上，那么这将具有向矩阵中相应交点加2的效果。这就是一个用户对乐曲交点对所能施加的最大影响。

被估级为喜欢、但从未播放的乐曲仍朝向关联计数。

该矩阵覆盖全球MusicStation提供之内的所有的乐曲以及所有服务中的所有估级和播放。这些同样还施加给以下说明的艺术家关联矩阵。

你将注意到，矩阵的一半沿对角线重复。因此，理论上，只需要一半矩阵。

2.2.2.1.2.阶段2-加权乐曲关联

我们现在需要从阶段1中拿出矩阵并应用权重，考虑到某些乐曲仅仅只是受到所有消费者的欢迎生成相关性(因此对单独的关联对不需要高度相关)。

我们应用的完成此的公式公知为TF·IDF公式

有关TF·IDF公式在属于文件或网络搜索的关键词的上下文中如何起作用的说明，在这里进行概括说明：

TF＝检索词频率(Term Frequency)

对术语在文件集中每隔多久就能发现的测定。TF与作为确定哪个文件与询问最相关的手段的逆向文件频率(inverse document frequency，IDF)相结合。TF有时也用于测定单词在特定文件中每隔多久就会出现。

IDF＝逆向文件频率(inverse document frequency)

对术语在收集中如何稀少的测定，通过总收集大小除以包含该词语的文件的数目进行计算。非常常用的术语(＂the＂，＂和＂等等)具有非常低的IDF，因此往往被排除在搜索结果之外。这些低IDF的单词通常称为“无用词(stop words)”。

在此方程中注意：

■TF＝频率(或者阶段1矩阵中的交点值)

■IDF由方程的后部分(log)表示，并且是以2为底的对数

■P(T₁)代表乐曲1在矩阵中的不同配对中至少出现一次的全部可能性(即，仅仅是其有多少次在不同配对中至少出现一次，除以乐曲的总数)

■IDF升到3次方。其不是固定的常数，但是是可以进行试验的，以改进建议。公知的在线音乐推荐者使用值为3的该常数，所以我们最好跟随他们的知识和指导。

作为该公式应用的一个实例，如果我们希望从阶段1矩阵为乐曲1和乐曲2计算权重，那么我们将进行以下计算

这给出乐曲1和乐曲2的权重为34。我们现在可以生成一个新的权重矩阵，如图17所示，其包括每行和每列最后的所有权重之和。

2.2.2.1.3.阶段3-标准化权重

我们现在需要标准化权重。实质上这意味着我们制作一个新的矩阵，其中矩阵中每个加权的相关性都除以该行或该列中相关性的总和。

再次利用乐曲1和乐曲2的实例，我们将会简单地将34除以110.5，得到标准化的权重0.31。

这样的结果就是，我们现在有了一组处于0到1之间的标准权重，如图18所示。

在最终的表格中，值越接近1，则乐曲之间的相关性越高。

在建议领域中，表格中的值由于它们相关的事实，并且它们是在规则的基础上重新得到的，所以现在称作预计算关联(Pre-ComputedAssociations，PCA)(但是因为包含的捣弄数字的量，总体上不以正在进行的方式更新)。

2.2.2.2.支持结构2-关联艺术家矩阵

关联艺术家矩阵是表示艺术家对基于估级和消费者播放在系统中关联性有多强的相关性矩阵，例如，如图19所示。

PCA关联艺术家矩阵实质上完全以和用于乐曲相同的方法建立。

包含在艺术家播放矩阵中的标准是，消费者必须至少两次全部播放来自该艺术家的至少一首乐曲。并且，单个消费者对矩阵可以具有的最大影响是附加值2(在以下情况下：他们已经将一对艺术家估级为喜欢，并且至少两次全部收听了来自这两个艺术家每个的至少一首乐曲)。

N.B.对这个艺术家的乐曲或专辑的估级对关联艺术家矩阵没有影响。

2.2.2.3.支持结构3-关联消费者矩阵

关联消费者矩阵是表示消费者对基于估级和消费者播放在系统中关联性有多强的相关性矩阵，例如，见图20。

PCA关联消费者矩阵可以部分地像用于生成关联艺术家矩阵一样的方法建立。

包含在消费者播放矩阵中的标准是，消费者必须至少两次全部播放来自同一艺术家*的至少一首乐曲。并且，单个消费者对矩阵可以具有的最大影响是附加值2(在以下情况下：他们已经将同一对艺术家估级为喜欢，并且至少两次全部收听了来自这两个艺术家每个的至少一首乐曲)。

N.B.这里选择共同的艺术家可能要比选择共同的乐曲有好处，因为用于计算和处理能力的蕴涵将会降低。

2.2.2.制作建议

本部分说明上述说明的结构如何用于来回地生成建议：

■“更喜欢这个”乐曲、专辑或艺术家

■“你可能喜欢的”乐曲

■“你可能喜欢的”专辑

■“你可能喜欢的”艺术家

■“你可能喜欢的”播放列表

■列在Buzz Cool会员屏幕上的“建议的成员”

■列在Buzz Cool播放列表屏幕上的建议的播放列表—这是否是与你可能喜欢的播放列表相同的列表？

■“在播放列表中寻找？”

■收件箱—编辑的和宣传的

所有上述功能基于计算的PCAs在预先请求的基础上^*在运行时间运行。

见图21、22、23、24和25。

2.2.4.生成星级估级

本部分解释我们如何为艺术家/专辑/乐曲/播放列表生成5星估级。

2.2.4.1.向估计系统的输入

向星级估级系统的输入有两种—外在估级(即喜欢和讨厌)，以及隐含估级(即，收听艺术家/专辑/乐曲的数目，特别是消费者至少两次全部收听该艺术家/专辑或乐曲的次数)。

建议在可能的情况下，估级由50/50分成的外在和隐含测定组成。^*

*这还有这样的优点，即消费者不能简单地滥用地估级材料使其显示具有更高或更低的星级。

2.2.4.2.为艺术家/专辑/乐曲/播放列表计算5星估级。

2.2.4.2.1.计算外在估计值

用于艺术家/专辑/乐曲/播放列表的外在估级简单地基于将艺术家/专辑/乐曲估级为喜欢的消费者与那些将其估级为讨厌的消费者的比例。其如下计算：

1)获得将艺术家/专辑/乐曲/播放列表估级为喜欢的消费者的数目

2)将(1)中的值除以对艺术家/专辑/乐曲/播放列表进行估级(即估级为喜欢或讨厌)的消费者的总数

3)乘以5，得出5中的估计值。

例如，设想天使(Angels)—罗宾·威廉姆斯(Robbie Williams)，我们有45个喜欢估级和18个讨厌估级。估级值则为：

2.2.4.2.2.调整估级值以处理较低的估级数

为了避免滥用并且防止大量0或5星级出现在系统中，在仅有少数消费者对艺术家/专辑/乐曲/播放列表估级的情况下，我们在计算中应该始终包括喜欢和讨厌的两个虚幻估级。因此，最终的计算就变成：

2.2.4.2.3.计算隐含估级值

为了计算隐含估级值，我们需要制作用于比较的基线。

最切合实际的基线就是表示对所有已经被单个消费者完整播放至少一次的艺术家/专辑/乐曲/播放列表来说每个消费者播放的平均数(即，将那些在计算中从未被收听过的艺术家/专辑/乐曲/播放列表包括在内是不公平的)。我们就可以用这个基线在系统内来表示2.5估级，并因此通过将分布标准化到2.5估级值周围来将其它估级向上或向下调整。

作为实例，如果对于乐曲：天使(Angels)—罗宾·威廉姆斯(RobbieWilliams)每个消费者的播放平均数为12.90，并且每个消费者对于所有(已经至少完整播放一遍的)乐曲的播放平均数为4.66，标准偏差为4.23，则我们可以如下操作：

对于天使(Angels)—罗宾·威廉姆斯(Robbie Williams)每个消费者的播放平均数＝12.90

标准化的播放(约平均为0)＝(平均播放—整个平均播放)/(标准偏差)

因此，标准化的播放(大约平均为0)＝(12.90—4.66)/4.23＝1.95

因此，标准化的播放(大约平均为2.5颗星)＝2.5+1.95＝4.45

(N.B.在极端环境下，这些值为<0，或>5也是可能的。在这种情况下，我们因此要将值封在0或5。)

在6首乐曲的域中如何工作的整体表现示于图26。

^*N.B.最初使用平均数，但是我们应该还试验中位数，因为后者具有消除以着迷的方式只播放一个艺术家/专辑/乐曲/播放列表的个别消费者的影响的效果(！)

2.2.4.2.4.计算总估级值

总的5星估级通过简单取隐含的外在估级的平均值、并上舍入至最近的半星而计算(上舍入是因为我们想积极面对我们展现的)。

因此，天使(Angels)—罗宾·威廉姆斯(Robbie Williams)的总估级＝(3.53+4.45)/2＝3.99

因此，天使(Angels)—罗宾·威廉姆斯(Robbie Williams)得到4星的估级。

2.2.4.3.为消费者计算估级

为消费者计算估级基于以下50/50的平均值：

消费者向他们的共享播放列表贡献的收听的估级和数量。

成员具有的朋友的数量。

前者以类似2.2.4.2.部分所述的方式进行计算，类似地，对于隐含部分，仅考虑已被其他消费者至少收听两次的播放列表。一旦我们有了所有消费者播放列表的总估级，我们就简单地取所有这些估级的平均值，以得出最终估级(5星或其它更想要的表示法)。

第二部分作为相对于整个服务数据集的朋友平均数的朋友的平均数进行计算，即：

标准化的朋友(约平均为2.5)＝2.5+(平均播放—整个平均播放)/(标准偏差)

2.3.搜索功能

本文件说明了组成MusicStation音乐搜索的搜索界面、过程和结果集合。由于移动工作环境的本质属性，MusicStation内的搜索机制设计成使用简单并直观，同时又有极强大的特征。重点是将向MusicStation消费者快速提供相关和精确的结果作为基础。

与此同时，应该记住，很多正在进行的自动化的工作在背景中完成，以将相关的艺术家、专辑、乐曲和播放列表在你可能喜欢、最近添加和特征化的艺术家/专辑/乐曲/播放列表菜单选项下推向消费者。这些菜单选项的内容不断更新，并以消费者独特的品味和他们的购买及收听习惯为基础。

2.3.1.搜索界面

2.3.1.1.基本搜索

基本搜索提供快速但强大的访问MusicStation音乐数据库的途径。通过消费者输入关键词(或一组关键词)进行搜索，并通过以下各项中的一项进一步改进他们的搜索：

●艺术家

●专辑

●乐曲

另外，还可能默认之前使用的选择，将搜索进一步仅限定为非古典音乐或仅限定为古典音乐。否则系统将会两种都搜索。

2.3.1.2.高级搜索

高级搜索屏幕允许广泛和精密的控制能用于整个搜索过程。利用高级搜索屏幕，可以通过以下各项过滤结果集合：

●艺术家、专辑或乐曲

●流派

●图表位置(最高)

●最小消费者估级

●语言

●国家

另外，还可以为古典音乐搜索以下领域：

●作品名称

●专辑名称

●作曲家

●独奏者/表演者

●指挥者

●管弦乐队/全体演出者

●记录标记

2.3.2.支持在MusicStation中搜索的普遍原理

附有十个基本原理来增强MusicStation搜索。这些原理与何适的实例一起提供于此。

2.3.2.1.不依赖于非字母数字字符

不同的消费者会以不同的方式使用非字母数字字符。例如，某些人会在艺术家名称中使用连字符作为间隔。其他人可能仅仅使用空格。在移动环境中输入非字母数字字符有时会比较复杂，并且易于出错。因此，为了搜索，对非字母数字字符没有依赖性，举例来说，以下各项被认为都是相同的：

●s club 7

●s-club-7

●sclub7

2.3.2.2.不依赖于字符字形

这简单地意味着，例如，以下各项被认为是相同的：

●s club 7

●S CLUB 7

●S Club 7

2.3.2.3.字符的国别间变型被视为是相同的

不同的消费者会以不同的方式使用非英文字符。例如，英国人可能会搜索：

●Bjork

而实际上要搜索的应该是

●

在MusicStation中，这种差异无关紧要，因为搜索系统将英文的国别间变型与其等同英文字母匹配(反之亦然)。

2.3.2.4.数字被视为与其书面等同体(大写)是相同的(反之亦然)

在艺术家搜索过程中，消费者可能会输入，例如，“50分(50 Cent)”或“伍拾分(Fifty Cent)”。这两种情况都能被系统处理。

2.3.2.5.缩写和书写单词的不同方式无关紧要

内部映射表确保通用的缩写和相等的表示法都能够被理解。因此系统认为以下关键词都是相同的：

●Boys to Men

●Boys 2 Men

●Boys II Men

类似地，“和”与“&”被认为是一样的。

2.3.2.6.应该不依赖于“The”的正确位置

我们不关心“The”是如何使用的。例如系统认为以下关键词都是相同的，并且都会得到正确的结果：

●The Rolling Stones

●Rolling Stones，The，或者简单的：

●Rolling Stones

2.3.2.7.消费者并不总是输入全部关键词组

某人搜索“Rage Against the Machine”时可能仅输入“Rage”作为关键词，并希望MusicStation给出合理的结果集合来选择。

2.3.2.9.如果他们知道他们想要什么，就将他们带到那里

如果消费者搜索“rage against the machine”，并且得到的结果只有一个，则他们将会自动指向“Rage Against the Machine”艺术家的主页。我们不会向他们显示只含一个艺术家的结果集合，那样他们必须还要再点击。

2.3.2.10.我们将会从系统的使用中学习并因此而对其进行优化

消费者搜索的艺术家、专辑或乐曲的名称可能会有变化，其与数据库中存储的非常不一样。结构的存在确保我们看到搜索关键词的新变化时我们能够将其与想要的艺术家、专辑或乐曲名称相匹配，从而确保所有未来使用该变化的搜索都能成功。

类似地，当对搜索结果进行归类时，将会利用对结果的受欢迎程度的了解(如消费者所部分的)确保最受欢迎的(因而是想要搜索的最可能的结果)最接近顶部。当这偶尔不正确时，消费者可以改为选择按字母顺序归类的意见。

2.3.3.搜索过程

以下是对从消费者输入用于搜索艺术家的搜索关键词开始的搜索过程的说明。

N.B.以下原理同样也适用于专辑或乐曲搜索。

1)搜索输入的搜索关键词的精确匹配，但基于2.3.2部分-支持在MusicStation中搜索的普遍原理中所描述的优先原理。

2)然后我们在艺术家名称内搜索搜索关键词的例子。例如，给出了搜索关键词“BOB MARLEY”，有效的匹配有：

a)“BOB MARLEY^＊”

b)“^＊BOB MARLEY^＊”，以及：

c)“^＊BOB MARLEY”

(其中^＊为“通配符”，表示任何字符排列)

(a)类匹配被看做是在给出的结果列表中比(b)和(c)类结果更优先。

如果(1)和(2)仅给出1个匹配，则我们直接到达艺术家主页(以及对专辑是专辑主页，对乐曲是现在播放屏幕)。

否则我们从1)列出匹配，随后从2)，其按受欢迎程度分级，之后是按字母顺序。

如果我们已经从上述发现了匹配，那么我们离开搜索程序。否则我们继续进行精确匹配。

我们重复步骤1)到4)，但这次使用语音和模糊逻辑匹配来发现听起来类似与关键词的匹配或拼写稍有不同的匹配。本过程得到的任何匹配前都加上标题(header)：“未发现精确匹配。你是否想要：(No exact matchesfound.Did you mean：)”，从而使消费者清楚该搜索结果不是准确的匹配。结果集合也按受欢迎程度分级，之后是按字母顺序。

2.3.4.在结果中寻找

在结果列表很大的情况下，消费者可以通过使用“更多弹出(Morepopup)”菜单中的“寻找”选项搜索更特定的项，以通过列表导航寻找特定的串。当消费者提交时，发现其第一次出现。下一个结果通过使用左手软键盘上的“下一个”选项可以很快被移动。

2.3.5.改进搜索

可以利用“更多弹出(More popup)”菜单中的选项从结果集合页面改进搜索。这意味着，用户可以再次搜索(以基础或高级搜索)但用保留的搜索关键词盒和所有预选过滤器来允许他们快速改进。

2.3.6.搜索结果集合的格式

当搜索结果集合中的搜索结果给出时，集合中要素的计数将显示在页面的右上方。

实际结果本身的格式根据搜索的是艺术家、专辑还是乐曲而有所不同。这些格式在本部分中更详细地说明。

2.3.6.1.艺术家搜索

给出最高的艺术家名称匹配，按系统测定的艺术家受欢迎程度进行归类。随后是进一步的按字母顺序排列的受欢迎程度类似(但较低)的匹配。

2.3.6.2.专辑搜索

专辑搜索将给出以下格式的结果：

专辑名称—艺术家名称(发行年份)

有“发行年份”确保例如可以很容易地将再次发行的(其可能包含奉送品或更新的乐曲)与最初的区别开来。

最高的匹配按系统测定的专辑受欢迎程度归类给出。随后是进一步的按字母顺序排列的受欢迎程度类似(但较低)的匹配。

2.3.6.3.搜索乐曲

乐曲搜索将给出以下格式的结果：

乐曲名称—艺术家名称(乐曲长度)

有“乐曲长度”(分:秒)确保具有相同名称的乐曲(但长度不同)可以被区分开来。这往往会在不同专辑重新混合时出现。

N.B.这里拥有专辑名称被认为是不必要和不合需要的，因为串的整个长度会导致严格受限的环境。而且，如果相同的乐曲出现在不同的专辑中，则其将会仅给出一次。

最高的匹配按系统测定的乐曲受欢迎程度归类给出。随后是进一步的按字母顺序排列的受欢迎程度类似(但较低)的匹配。

2.3.7.在播放列表中寻找

在系统中合适的点上，当引用乐曲时，消费者可以利用“更多弹出”选项在播放列表内搜索该乐曲。按受欢迎程度归类给出由其它MusicStation消费者共享的播放列表的列表(或者包含在其它系统发布的播放列表中)。

2.4.多语言支持

本文件说明我们如何管理和利用讯息为特定的装置、服务和客户机版本建立客户机编译。

2.4.1.发展

通过发展发布的每个客户机版本具有一组客户机使用的默认讯息。该讯息组在开发者发布的发展过程中保留。讯息组中的每个讯息是在客户机的某个地方显示的文本或标记。见图27讯息的特性。

讯息通过将记录加入具有下一可用讯息_索引(message_index)的讯息_组_项(message_set_item)中而被加入到默认讯息组中。讯息索引用于源代码中，以访问讯息组中的讯息。索引定义为讯息对象中的常数：

public static int OPEN_LABEL_INDEX＝104；

该常数之后可以用于得到当前选择的语言的讯息：

openCommand.setLabel(messageSet.getMessage(OPEN_LABEL_INDEX))；

该讯息组设置成用于客户机版本的默认讯息组。

在编译中打包的图像在默认图像组中定义。图像基于图像任务从该组中选择。见图28图像的特性。

客户机版本与默认讯息和图像组一起发布。见图29客户机版本特性。

2.4.2.客户机版本发布

以下记录与客户机版本发布一起从发展向编译系统打包：

●默认讯息组和讯息组项

●讯息和默认讯息组使用的讯息密钥

●英文或其它任何测试语言的讯息语言

●默认图像组和图像组项

●默认图像组使用的图像

2.4.3.讯息翻译

翻译的讯息可以在任何时间载入编译系统。当默认讯息组中的每个讯息具有用于该语言的讯息语言时，对编译用户的选择来说该语言是可用的。见图30翻译的讯息。

在向服务讯息添加讯息时，我们强行使讯息语言记录为所有的服务所支持的语言而存在。类似地，如果编译用户选择装置来与该服务一起使用，我们确保所有装置的讯息具有用于所有的服务所支持的语言的讯息语言。

因为客户机编译为多语言建立，但我们只能在包括一种jar格式的图标、标志和闪屏(splash screen)，所以不需要翻译图像。为服务定义的图像为用于该服务的默认语言。

2.4.4.装置讯息

可以为装置确定讯息组。这允许我们为选择的装置重置默认讯息组中的讯息。见图31装置讯息特性。

例如，帮助讯息可以特定用于特殊的装置：见图32装置讯息/帮助讯息特性。

在编译的时候，为选择的装置所定义的讯息重置默认讯息组中具有相同讯息密钥的讯息。

2.4.5.服务讯息

讯息也可以为装置定义。这些讯息重置默认和装置讯息组，尽管实际上讯息应该要么是装置特定的要么是服务特定的以及都不是。见图33服务讯息。

服务也具有默认语言和一组服务语言。这些设置为默认语言和支持客户机编译的语言，但是，如果编译需要不同的默认语言或仅仅是语言的子集，编译客户机就可以在编译之前编辑这些

2.4.6.服务和装置特定讯息和图像

在某些情况下，我们想要指定讯息或图像特定用于特殊的装置或特殊的服务。例如，我们会想在一组装置上使用已经手动重设大小的服务图标。见图34服务和装置特定讯息。

2.4.7.讯息替换

任何在数据库中可以引用的服务或装置特性可用于替换到默认讯息组中。例如，替换消费者支持电话号码：

需要帮助请拨

${service.company.companyAddress.customerSupportTelephone}

默认讯息组支持替换，这对编译用户是隐藏的。当他们看到默认讯息时，电话号码已经替换到里面了。

装置和服务讯息也支持替换。管理装置和服务讯息的工具应该对编译用户隐藏语法。

如果替换的值未对装置或服务定义，就要求编译用户在可以进行编译之前设置值。

2.4.8.客户机编译

客户机已经选择了客户机版本、装置和服务。用于版本的默认讯息组为选择用于编译的讯息提供基础。这些讯息随后由装置和服务讯息组分别重置。这些随后由任何指定到服务_装置(service_device)讯息组中的讯息重置。

为此编译选择的语言然后用于为支持的语言过滤讯息语言记录。

客户机编译讯息为各种语言的每个讯息创建，并复制到用于该编译的客户机编译讯息表中。见图35客户机编译讯息。

在编译时有讯息的副本可以允许我们：

●保留任何做出的替换的记录

●不必复制锁定的讯息而更新信息

为默认图像组中的每个图像创建客户机编译图像并随后用服务图像组中的任何图像进行重置。这些随后由指定到服务_装置(service_device)图像组中的图像重置。这些图像随后被重设大小并重新命名并以jar打包。

客户机编译讯息和图像形成客户机编译定义的一部分，并且在该客户机编译公布到产品服务手册上时被公布到其上。

2.4.9.公布客户机编译

对于每个客户机编译，将以下讯息相关表格发布至产品系统：

●客户机_编译(Client_build)：用于该客户机编译的记录

●客户机_编译_讯息(Client_build_message)：用于该客户机编译的记录

●讯息(Message)：客户机_编译_讯息(Client_build_message)中引用的每个讯息

●讯息_密钥(Message_key)：用于每个讯息的密钥

●讯息_语言(Message_lang)：用于各种支持语言的每个讯息的讯息_语言(message_lang)

●客户机_编译_图像(Client_build_image)：用于该客户机编译的记录

●源图像文件(Source image files)：客户机_编译_图像(client_build_image)中引用的每个图像文件

2.5.漫游网络选择

当电话“漫游(Roaming)”时，用户使用MusicStation时就会经历附加的费用。这些费用在电话漫游时用户下载乐曲或MusicStation更新菜单项和图像时产生。用户可以为MusicStation配置漫游特性。

2.5.1.配置漫游特性

见图36屏幕抓图—漫游选项

在MusicStation内，用户可以为MusicStation配置漫游特性。见图37。

如果菜单和图片更新(Menu & picture updates)特性设置成询问(Ask)，在漫游时将会向他们显示一个警告讯息，该讯息将询问他们同意/拒绝下载、更新以及给定通话的附加费用。见图38屏幕抓图—漫游警告。

当用户在漫游时试图下载乐曲时，并且用于乐曲的漫游特性设置成了询问，在漫游时，将会向他们显示一个警告讯息，该讯息将询问他们同意/拒绝下载、更新和附加费用。该行为，同意/拒绝，将配置用于当前通话的设置。见图39屏幕抓图—漫游警告—询问提示。

2.5.2.漫游警告和错误

会产生费用的行为可以分成两类：

●乐曲下载—音频文件的下载。

●菜单和图片更新—菜单的更新包括例如以下的项：图表列表、你可能喜欢的建议、Cool会员和Buzz播放列表。更新图片，例如Bozz外形上变化了的图像，或者下载新的用于艺术家和专辑外形的图像。

以下过程将为MusicStation的各个新通话的每个连接的会产生费用的行为出现。

●服务器将检查来自客户机的所有请求的响应标题。

●当检测到漫游、并且用户选择了会产生费用的行为时，接着检查选项菜单上该类行为的漫游选项设置。

●如果该行为在漫游选项菜单上标记为开(允许)，则正常完成该行为。

●如果该行为在漫游选项菜单上标记为关(不允许)，则显示弹出式菜单解释其已被阻拦。

●如果该类行为在漫游选项上标记为询问，则在通话中第一次选择该类行为时将显示漫游警告。随后的行为就基于用户提供的答案进行处理。

2.5.3.漫游警告

2.5.3.1.漫游选项设置成询问

当会产生费用的行为在漫游选项菜单上设置为询问时，显示以下漫游警告。将提示用户选择漫游时对该会产生费用的行为的设置。见图40屏幕抓图—漫游警告—询问提示。

●如果用户选择不允许，则该区域中的所有后续行为在本通话的其余时间里将显示漫游错误，或者直到选择了重置位置(Reset Location)。

●如果用户选择了允许，则该区域中的所有后续行为在本通话的其余时间里将继续而没有进一步的提示，或者直到选择了重置位置(ResetLocation)。

●如果用户选择了条件(Terms & Conditions)，则WAP页面显示供MusicStation使用的条件。关闭WAP浏览器返回上一提示的MusicStation。

只要用户一回到他们的本地网络，该警告将不再显示。

2.5.3.2.漫游选项设置成开

当会产生费用的行为在漫游选项菜单上标记为开时，则用户在漫游通话中第一次实施会产生费用的行为时将显示以下漫游警告。用户有时可能已经在过去设置了漫游参数选择并且已经忘记了他们已经允许了这些会产生费用的行为。见图41屏幕抓图—漫游选项设置成开。

用户被警告他们将为乐曲下载或菜单和图片更新支付费用。乐曲下载和/或菜单和图片更新将继续。这些选项可以在漫游选项菜单上改变。

2.5.3.3.漫游选项设置成关

当会产生费用的行为在漫游选项菜单上标记为关时，则用户在漫游通话中第一次实施会产生费用的行为时将显示以下漫游警告。见图42屏幕抓图—漫游选项设置成关。

用户被警告乐曲下载和/或菜单和图片更新将不会继续。这些选项可以在漫游选项菜单上改变。

2.5.4.检测漫游

以下过程描述MusicStation如何检测电话正在漫游：

●每个从MusicStation客户机到我们的服务器的HTTP请求都经过MNO的网关

●他们已将网关配置成向标题添加一定的信息。例如：

X-WSB-Identity:$(MSISDN)；

X-TELENOR-SGSN:$(RADIUS:SGSN-IP-Address)；X-bearer:$(BEARER_TYPE)

●这里的第二字段为SGSN的IP地址。这是手机通信所通过的网关的IP地址。

●我们将该IP地址与MNO网络上的网关IP地址列表对比。

●如果IP地址不在该列表中，则意味着该手机正在漫游

服务器通过在列表中查找IP地址完成该评估，如果其确定其在漫游，则其将状态返给客户机，客户机接着经过2.5.2.漫游警告和错误中所述规则和用户提示。

3.社区特征

除了终端用户性能以与服务器互动之外，在单个性能中，客户机和服务器还提供一定的社区功能，用户可以通过其与另一个用户互动。每个用户都可以创建个人外形、向其他用户发送“交友”请求，并且之后向确定的“朋友”发送他们按照艺术家、专辑或单个乐曲的播放列表或建议。

3.1.注册

参加社区特征的第一步就是在社区环境(也公知为Buzz)内请求用户注册唯一的外形。

3.1.1.未确定成员名字

当用户试图访问社区特征但该用户未注册Buzz用户名时，Buzz主页就向用户显示一个邀请，邀请注册Buzz。成员名字只是强制字段：

·customer_preference.nickname

此外，用户可以选择输入醒目广告语(catchphrase)和/或选择图像作为他们的化身：

·customer_preference.catchphrase

·customer_preference.avatar_image_id

如果成员名字在该服务中是唯一的，并且通过了誓词过滤，则Buzz主页为该成员显示重新限定的详细资料。

如果成员名字在该服务中不是唯一的，客户机返回到屏幕，用向用户建议的要么接受要么修改的成员名字替换输入的成员名字

当用户已经提供了成员名字时，Buzz主页向该用户显示之前的详细资料，以及用户确认的朋友的计数和收听他们共享播放列表的数目。

·Customer_count.friend_count

·playlist_count.play_count

3.1.2.确定了成员名字

当用户已经提供了成员名字时，Buzz主页就向该用户显示详细资料

·customer_preference.nickname

·customer_preference.avatar_image_id

·customer_preference.catchphrase

·customer_data.calculated_rating

·Customer_count.friend_count(count of customer_to_customer wherecustomer_id＝${customerId}and customer_to_customer.friend_status＝APPROVED)

·play_count_otherplaylist(sum of playlist_count.play_count whereplaylist.owning_customer_id＝${customerId})

从他们受欢迎的程度计算估级。算法包括在2.2建议中。

菜单选项给出通向共享播放列表和分级的对该成员会感兴趣的社区成员(3.4 Buzz Cool会员)的入口。他们还给出通向用户自己的播放列表和他们的朋友(3.6.1Buzz朋友)的入口。

3.2.编辑我的外形

一个选项借助于允许用户编辑他们的外形的上下文有关的菜单存在，其外形显示在他们的Buzz外形屏幕上，并且如果设置了合适的选项就可以被其他成员看到。其在用户从Buzz主屏幕中的上下文有关的菜单中选择“编辑我的外形(Edit My Profile)”选项时显示。用户可以编辑他们的成员名字、他们的醒目广告语、他们的图像和观看选项：

·显示外形—控制其他成员是否可以看到该成员的外形。默认为是。

·显示我的最佳乐曲—控制该成员最喜欢的艺术家是否列在其成员外形屏幕上。默认为是。

3.3.共享播放列表

一个菜单选项给出通向该用户会感兴趣的共享播放列表的入口。

“你可能会喜欢(You Might Like)”播放列表是其他用户的共享列表，其由建议引擎为该用户选择。见2.2建议。

对于每个共享列表，客户机显示共享列表名称、星级和创建该播放列表的成员：

·playlist.name

·playlist.owning_customer_id

·customer_info.recommend_playlist_set_id

·playlist.image_set_id

·playlist_data.calculated_rating

3.4.Buzz Cool成员

一个菜单选项给出通向该用户会感兴趣的成员的入口。“你可能会喜欢(You Might Like)”的成员是其他与该成员类似的成员。见2.2建议详细了解该列表如何创建。只有在编辑我的外形(Edit My Profile)菜单上具有“显示外形”选项设置、并且尚不是用户确认的朋友的成员才在这里列出以下详细资料：

·customer_preference.nickname

·customer_preference.avatar_image_id

·customer_info.recommend_customer_set_id

·customer_data.calculated_rating

·count of playlist where owning customer_id＝${recommendedCustomerId}

3.5.另一成员外形

用户可以察看MusicStation服务从另一成员的详细资料。当从成员列表(例如从3.4Cool会员屏幕)中打开成员时，就显示其外形的特征。该屏幕不会向尚未登入Buzz并至少建立其成员名字的成员显示。该视图包括该成员共享的所有播放列表的列表。打开其中的一个就显示播放列表。

对于每个播放列表，屏幕显示估级和该播放列表中乐曲被有质量地播放收听的次数。如果没有共享播放列表，则在共享播放列表标题下方的部分显示讯息“该成员尚未共享任何播放列表”。

此外，还显示其他成员的最佳乐曲。该部分(包括名称)仅在该屏幕上显示的成员在3.2编辑我的外形屏幕上具有“显示我的最佳乐曲”标志设置时才显示。列表显示该成员的最佳的5首乐曲。这是在最顶端列有最受欢迎的该成员全部时间播放最多的5首乐曲。用户可以任意选择这些乐曲进行播放。包括的字段为：

·customer_preference.nickname

·customer_preference.avatar_image_id

·customer_preference.catchphrase

·customer_data.calculated_rating

·play_count_otherplaylist(sum of playlist_count.play_count whereplaylist.owning_customer_id＝${customerId})

·Customer_count.friend_count(count of customer_to_customer wherecustomer_id＝${customerId}and customer_to_customer.friend_status＝APPROVED)

·playlist.name

·playlist_data.calculated_rating

·playlist_count.play_count

·playlist.image_set_id

3.6.Buzz添加为朋友

该屏幕在用户从选择成员的上下文有关菜单中选择“添加为朋友(Add as Friend)”选项时显示。用户可以发送讯息作为交友请求的一部分。

当针对一个成员选择添加为朋友选项、并且该成员尚不是该用户的朋友时，显示交友请求，其具有交友请求要发向的成员名字的字段和成员可以输入某些文本的文本主体，其将发送给其他成员作为自我介绍。字段包括：

·customer_preference.nickname

·customer_to_customer_request.body

3.6.1.我的朋友

“我的朋友(My Friends)”菜单选项显示该成员的朋友列表。如果用户没有朋友，则显示讯息“这里将显示你的朋友列表”。此外，还显示该成员的待处理请求的朋友列表。如果没有待处理的请求，则该标题和列表不显示。字段包括：

·count of customer_to_customer where customer_id＝${customerId}and customer_to_customer.friend_status＝APPROVED

·from customer_to_customer_request where friend_status＝REQUESTED

3.6.2.通过名字添加朋友

用户可以选择“通过名字添加朋友(Add Friend by Nam)”菜单选项通过其外形名称添加其他用户。该讯息只有在该用户已经完成了Buzz注册并注册了成员名字后才可以使用。用户需要输入朋友的成员名字来发送交友请求。字段包括：

·customer_preference.nickname

·customer_to_customer_request.body

当成员选择了“发送”、并且找到了该名字的成员时(无论该成员是否设置了其显示外形选项)，显示确认讯息。当成员选择了“发送”、并且未找到该名字的成员时，通知用户并要求其重新输入成员名字。

当成员选择了“发送”、并且该成员已经是该用户的朋友时，再次通知用户此结果。

3.6.3.通过电话号码添加朋友

当用户选择“通过号码添加朋友(Add Friend by Number)”选项时显示该屏幕。用户需要输入朋友的电话号码来发送交友请求。我们假定他们不输入国家代码，默认的国家代码是服务所关联的国家的代码。字段包括：

·customer_person.mobile_msisdn

·customer_to_customer_request.body

当成员选择了“发送”、并且找到了该名字的成员时(无论该成员是否设置了其显示外形选项)，显示确认讯息。当成员选择了“发送”、并且未找到该名字的成员时，通知用户并要求其重新输入成员名字。

当成员选择了“发送”、并且该成员已经是该用户的朋友时，再次通知用户此结果。

3.7.发送乐曲或播放列表

当用户选择上下文有关菜单中的乐曲或播放列表上的“发送至朋友(Send to Friend)”选项时显示该屏幕。用户可以选择一个或多个朋友发送乐曲或播放列表。用户必须具有他们自己的成员名字设置和至少一个朋友来使发送至朋友选项发挥作用。字段包括：

·mail_attachment.track_id

·customer_preference.nickname

·customer_mail.customer_id

·mail.body

显示该成员朋友的列表。用户点击朋友进行选择并再次点击取消选定。可以选择任何数量的朋友。为每个朋友显示他们的估级、朋友数量和收听的数量。

显示选择发送确认讯息，用户返回到初始屏幕。

3.8.发送讯息

客户机能够不附加识别内容发送讯息。讯息屏幕显示以下字段：

customer_mail.customer_id

customer_preference.nickname

mail.body

3.9.谁在收听

当用户从菜单中乐曲、专辑、艺术家或播放列表上的更多(More)菜单中选择“谁在收听(Who’s Listening)”选项时显示该屏幕。该屏幕显示最近十个注册到Buzz、播放该用户选择谁在收听选项打开的主题的成员。播放什么取决于对象的类型，选项针对以下各项进行选择：

·乐曲—播放该乐曲的最近的10个成员

·专辑—播放该专辑中的乐曲的10个成员

·艺术家—播放该艺术家的乐曲的最近的10个成员

·播放列表—播放该播放列表中的乐曲的最近的10个成员

字段为：

·customer_track order by last_play_date

·customer_release order by last_play_date

·customer_artist order by last_play_date

·customer_playlist order by last_play_date

3.10.收件箱

包括在社区视图中的有“收件箱”，其显示其他用户向用户发送的所有讯息，包括讯息和建议。

3.10.1.收件箱收到乐曲建议讯息

当成员向该用户发送乐曲时，在收件箱中将出现有以下确定的字段的讯息：

·mail.kind＝MESSAGE

·mail.from_customer_id

·mail.sent_date

·mail.kind＝TRACK RECOMMENDATION

·mail.from_customer_id

如果用户通过选择讯息而将其打开，则讯息屏幕显示如下字段：

·mail.from_customer_id

·customer_preference.avatar_image_id

·mail.sent_date

·mail_attachment.track_id

建议的乐曲、专辑、艺术家或播放列表的名字在讯息中高亮显示，并且随着用户滚动过讯息每个接下来的讯息都高亮显示。

点击乐曲名字与用户选择乐曲列表中的乐曲上的添加至播放具有相同的效果。也就是说，该乐曲将添加至当前播放列表的后部，并且显示弹出式菜单向用户通知该事项。

3.10.2.收件箱收到播放列表建议讯息

当成员向该用户发送播放列表时，将在收件箱中出现具有以下字段的讯息：

mail.from_customer_id

mail.kind＝PLAYLIST RECOMMENDATION

mail_attachment.playlist_id

如果用户通过选择讯息而将其打开，则讯息屏幕显示如下字段：

·mail.from_customer_id

·customer_preference.avatar_image_id

·mail.sent_date

·mail.body

·mail_attachment.playlist_id

3.10.3.收件箱收到交友请求讯息

当另一成员向该成员发出交友请求时，在该成员的收件箱中将出现讯息。当打开时，他们有机会同意或拒绝。我们在弹出式菜单中完成此过程是因为用户被请求互动。讯息标题显示：

·customer_to_customer_request.to_customer_id

·customer_to_customer_request.fiend_status＝REQUESTED

打开讯息显示：

customer_to_customer_request.to_customer_id

customer_to_customer_request.body

选择继续显示具有如下选项的弹出式菜单：

·同意—只在交友请求高亮显示时才显示(不用灰色显示(grey out)是因为对于绝大多数收件箱项该选项并不相关)

·拒绝—只在交友请求高亮显示时才显示

·阻止—只在交友请求高亮显示时才显示

·报告滥用—只在交友请求高亮显示时才显示

用户的反应存储在：

·customer_to_customer_request.response(APPROVED，DENIED，BLOCKED，ABUSED)

3.10.4.收件箱收到交友响应讯息

当成员向该用户发出的交友请求做出响应时，在该成员的收件箱中将出现该响应。根据其他成员接受、拒绝还是阻止该交友请求，该成员将会看到三种可能的响应：

·customer_to_customer_request.friend_status

图43中的表格显示了响应的标题、内容和结果。

3.10.5.收件箱收到文本讯息

文本讯息在收件箱中类似地显示，相关的字段为：

·mail.from_customer_id

·customer_preference.avatar_image_id

·mail.sent_date

·mail.body

3.11.普通讯息警告和满期

3.11.1.讯息警告

当讯息到达成员时，我们在屏幕底部显示一个小的弹出式菜单。该弹出式菜单为每组到达的讯息显示一次，并且在服务器将这些讯息一转给客户机就可以显示。在客户机很快恢复到现在播放屏幕之后2秒将检查并显示下一个讯息，以免中断用户流程。如果本来有当前播放列表，在客户机很快恢复2秒钟之后，如果没有当前播放列表，则显示弹出式菜单。

弹出式菜单被阅读并了解之后，如果在该通话过程中还有讯息抵达，则显示另一个弹出式菜单。

该成员离线时发送的讯息因此很可能会在他们开始应用程序之后显示。

3.11.2.讯息满期

读取的讯息在被读取1天之后期满。

未读取的讯息在用户被警告其存在的5天之后期满。

未读取的讯息在用户不在应用程序中因而用户未被警告其存在的30天之后期满。

期满的讯息将在方便时从收件箱中移除。这里所附的满期时间段不必是精确的。例如，它们可以在其满期之后的下一个通话开始时从收件箱中移除。因此为邮件收到日期确定附加字段：

·customer_mail.received_date

4.图形用户界面(GUI)特征

附录1对GUI进行说明。

5.通信体系结构

5.1.mCom

5.1.1.综述

MusicStation客户机应用程序需要连接至MusicStation服务器来下载和上载各种数据。MusicStation用来连接至服务器的协议必须能够在多种客户机技术，例如Java、Symbian和Windows Mobile上实施。其还必须解决文件“连接的MusicStation问题和要求(Connected MusicStation Issuesand Requirements)”中记载的问题。

5.1.1.1.协议历史

MyFone利用HTTP传送数据。这个经验显露出HTTP请求和响应不得不通过运行商网关所带来的各种问题。运行商网关和不同移动电话通常规律地被发送失败以HTTP标题干扰。这是导致创建本协议的关键因素之一。

为了在一个响应中传送多个文件，本协议从MIME中获取灵感。本文件的早期修订将MIME像边界一样使用，来分离响应中的不同文件。这变成在标题中使用偏移和长度标记。这允许客户机快速访问数据对象。只有标题需要解析，主体内容不需要。(见3.2.7部分)

状态码之前使用二进制表示法，以允许它们在可扩展的同时仍能被老客户机理解。这已经简化为使用整数值，其可以被人和客户机很容易地理解。向客户机发送最合适的状态码的服务器用于引入新状态码的问题。服务器只发送连接客户机版本能理解的状态码。

之前，如果相同的文件在一个通话中被请求了多次，或者如果确收在不同于数据文件在其中被发送的通话中被发送，是不可能唯一识别确收的。用于发送和送出行(Sent and Put lines)中的确收id原理解决了该问题。

5.1.1.2.协议综述

因为移动电话连接到互联网中的方式，客户机必须启动所有的通信。由于移动电话没有静态的IP地址，并且因为其通常通过移动运营商网关连接，所以没有途径使服务器开启通信。MIDP2.0手机可以利用进栈注册(Push Registry)功能向应用程序发送SMS请求客户机向服务器做出请求，但是该功能不能在所有目标手机和客户机平台上使用，因此，MusicStation协议应该以客户机开启通信为基础。

协议必须能够在HTTP和TCP/IP插口连接上运行。这是两个最常用的我们可用于客户机平台的可用连接。

协议假定有可靠的运输层。协议不需要能够重新请求特殊响应的单个包。因此UDP插口连接不是支持的传输机制。为了支持不稳定的传输层，需要MusicStation协议和TCP中大量的额外功能在所有具有UDP的客户机上都能使用。

协议必须能够支持客户机将数据传送到服务器，并且能够支持客户机做出从服务器请求数据的请求。这样要求以使得错误数据、存入数据、用法数据、播放列表信息和用户相关数据可以从客户机传送到服务器。

由于MusicStation是请求/响应协议，所以其仿照HTTP的模式，借用了多种HTTP的特征。

MusicStation协议基于文本仅利用ASCII字符集，所以其可以在很多不同的客户机平台上实施而没有任何与二进制数据关联的编码问题。

以下的图表表示了客户机和服务器之间的请求/响应流程。这是由服务器完成来自客户机的简单请求的一个实例。所有的客户机/服务器通信都以与此相同的基本方式发生。见图44客户机和服务器之间的请求/响应流程。

下一个图表表示服务器如何向客户机发送请求。由于客户机/服务器通信必须始终由客户机请求触发，所以，服务器要从客户机做出请求的唯一方式就是服务器将请求背负在其发送到客户机的响应上。见图45服务器向客户机发送请求。

注意，在正常的运行中，服务器将始终响应客户机的请求，即使在响应中没有数据。响应可以只包括状态码(见“服务器“响应”协议”部分)。

每分钟请求超过阈值的自动机械客户机和请求是不正常的运行，服务器没有义务响应这些请求。未接收到服务器响应的真实客户机应该在合理的时间后重试请求。

像HTTP一样，MusicStation协议利用标题来保持关于讯息主体的元数据，其包含传送的实质数据。本文件说明仅牵涉到这些标题的协议。讯息的主体可以因不同的客户机实施而有所不同。像HTTP一样，标题和主体由空行(empty line)分开。

5.1.2.客户机请求协议

5.1.2.1.标题

5.1.2.1.1.协议标识符

任何请求的第一部分为协议标识符。这使得接收该请求的服务器可以确认其收到的数据确实来自客户机。协议标识符应该简短，以使其不在请求上投入内务操作。MusicStation使用的标识符为：

MSTP

这支持MusicStation传送协议(MusicStation Transfer Protocol)。

5.1.2.1.2.协议版本号

连同协议标识符一起的是协议版本号。该协议标识符完全从客户机版本号、服务器版本号和客户机版本号使用的数据对象分离。

可以有许多不同的客户机应用程序版本，其全部使用相同的协议版本号。

协议版本号的形式为主要.次要(major.minor)。

次要号码应该对于协议的递增变化增加，主要号码应该随协议的明显变化增加。协议最初开发的版本的主要号码为0。其在协议第一次产品发布时递增到1。

服务器软件应该始终能够处理每种发布的协议版本，以使其向后兼容所有的老客户机版本。

协议版本号与协议标识符处于同一行，并且与协议标识符用正斜杠分开。

MSTP/0.1

该行表示这是MusicStation协议的0.1版本。

5.1.2.1.3.请求标识符

MusicStation客户机发送的每个请求都包括标识符。该标识符必须在当前通话中对该请求是唯一的。不需要请求标识符是全球唯一的。该请求标识符可以是任何直达32个字符长度的串。

这可以实施为从1开始、并且为客户机做出的每个请求增加的整数。

需要该请求标识符以使得服务器可以识别来自的客户机重复请求。MyFone的经验已经显示移动电话客户机请求有时可以非常不稳定。这就意味着客户机如果未在合理的时间内收到响应，必须能够自动重试请求。

当客户机未收到响应时，这可能是因为请求从未到达服务器，或者可能是因为服务器的响应在其返回客户机的途中在运营商网关中丢失。

通过包括请求的标识符，服务器识别重复的请求就是直接了当的了。

客户机必须发送同样的请求标识符用于任何重试的请求。

请求标识符可以在请求标识符和请求版本号的下面的任何点。

MSTP/0.1

请求Id(RequestId)：123456

这就通过该客户机识别了请求。如果客户机重试该请求，则重试中请求id必须为123456。

5.1.2.1.4.客户机名称和版本号

每个请求都必须包括客户机名称和版本号。该信息之后可以用于服务器上执行该客户机能力的查找。这意味着新的能力可以在任何时间添加到客户机中，而不必改变协议中给定的信息。

例如，如果客户机识别其自身为MIDP版本0.4.6的客户机，则服务器就知道其需要返回的数据对象是什么格式。服务器还知道该客户机支持的音乐编码是什么。并且服务器知道该客户机不支持加密的音乐文件。

MSTP/0.1

请求Id(RequestId)：123457

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

这识别客户机为在诺基亚N70手机上运行的Java客户机版本。服务器之后就可以查找该客户机具有什么能力。

该串的格式为：

“MusicStation”[主要].[次要].[微]“别名””平台标识符”

详见图46。

5.1.2.1.5.用户的全球唯一标识符

每个请求都必须包括用户的全球唯一标识符。一个例外是最初注册请求。如果请求不包括用户的全球唯一标识符，则服务器用要求客户机注册的通知来响应。

该全球唯一的标识符允许服务器查找关于用户的各种信息。

用户不应建立全球唯一标识符(globally unique identifier，GUID)。标识符由服务器在注册过程中创建，并随后分配给客户机。客户机之后在每个随后的请求中必须包括该标识符。

MSTP/0.1

请求Id(RequestId)：123458

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

这就用全球唯一标识符AB12YZ识别了该用户。服务器可以利用该信息查找用户的详细资料，例如首选语言、地域、运营商和标记。

5.1.2.2.数据请求

5.1.2.2.1.基本数据请求

大部分来自客户机的请求是来自客户机的数据请求。例如客户机会从服务器请求最新的新闻。

MSTP/0.1

请求Id(RequestId)：123459

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：inbox.data

这是个请求收件箱.数据(inbox.data)数据对象文件的例子。

5.1.2.2.2.有路径信息的数据请求

数据请求还可以具有与其结合的路径信息。这使用类似于HTTP URLs的语法。/(正斜杠)字符用作目录分隔。

MSTP/0.1

请求Id(RequestId)：123459

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：games/namethattune/question.data

这是个请求具有路径games/namethattune的问题.数据(question.data)数据对象文件的例子。

5.1.2.2.3.有询问的数据请求

数据请求可选择地包括服务器将用于创建要返回客户机的数据对象的参数。该请求数据通过使用HTTP询问串语法而包括在内。

MSTP/0.1

请求Id(RequestId)：123460

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：

advncedSearch.data？type＝artist&query＝artist％20name&country＝uk&language＝en

这是一个请求高级搜索结果的例子。该被请求的资源具有？(问号)字符，将被请求的资源的名字和用于该资源的参数分隔开。参数为名字/值对。每个名字/值对由&(和号)字符分隔，名字和值部分由＝(等号)分开。

该值已被URL编码，因此搜索词“艺术家名字(artist name)”已由URL编码文本％20替换。

5.1.2.2.4.具有多个请求的请求

客户机可以同时从服务器请求多个资源。为此，客户机发送多个GET行，移行用于每一个请求的资源。

MSTP/0.1

请求Id(RequestId)：123461

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：inbox.data

获取(Get)：charts.data

这是个请求收件箱.数据(inbox.data)文件和请求图表.数据(charts.data)文件的例子。这样的情况可以出现在客户机做出其立刻就需要的请求(本例中为inbox.data)、并且还需要在背景中更新资源(本例中为charts.data)。

GET行应该以客户机想要在服务器响应中接收资源的优先权的顺序排列。

有时候客户机可能具有高速缓存的部分响应，并且仅需要从服务器返回部分数据。在这样的情况下，客户机可能想要做出数据的仅特定部分的请求。

客户机可以通过在GET行使用范围参数完成此操作。范围参数用；(分号)字符从被请求的资源分隔开来。

如果有多于一个的范围参数，则范围参数由；(分号)字符分隔。

范围参数为从和至(from and to)。它们都应该跟有＝(等号)字符，然后是字节的整数。

5.1.2.2.5.部分数据请求

以下是一个收件箱.数据(inbox.data)文件的部分请求的例子。客户机请求从第34字节向前的所有收件箱.数据(inbox.data)文件。

MSTP/0.1

请求Id(RequestId)：123462

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：inbox.data；from＝34

以下是一个收件箱.数据(inbox.data)文件的部分请求的例子。客户机请求从第128字节起到第256字节的所有收件箱.数据(inbox.data)文件。

MSTP/0.1

请求Id(RequestId)：123463

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

获取(Get)：charts.data；from＝128；to＝256

在做出范围请求时，客户机不应期待返回的数据就是所要求的范围。服务器的响应会包括返回的范围的详细资料，客户机应该利用服务器响应中的范围信息，而不是其自身进一步处理的请求中的范围信息。这是因为，服务器可能有一定的原音返回数据的不同范围。例如，如果数据由于客户机最后请求而已经发生了变化。

5.1.2.3.向服务器发送数据

有时客户机可能需要向服务器发送数据。例如，向服务器发送错误信息。客户机可以通过使用送出行(put line)来完成此操作。

送出行具有多个部分。每个部分由；(分号)隔开。

Put：error.data；ackId＝1；offset＝0；length＝160；type＝＂application/octet-stream＂

其中，错误数据详见图47。

这是客户机向服务器发送错误数据的一个例子。见图48。

零和一的组块表示了讯息的主体。这是通过本协议传送的二进制数据。该数据的格式超过了本协议的范围，是因为格式会因客户机实施技术而不同。

主体中的数据以0位开始，长度为160字节。送出行中的偏移和长度值反映了这个信息。

送出行中的内容类型告知服务器如何解释该数据。

5.1.2.3.1.发送具有多个送出的数据

客户机可能需要同时向服务器发送多个资源。以类似于使用多个获取(Get)行的方式，客户机可以发送多个送出行。

见图49，为客户机向服务器发送错误数据和照片的例子。

在请求的主体中，错误数据相对照片数据以粗体文本显示。请求中的长度和偏移位告知服务器该数据的偏移和数据的长度。

5.1.2.3.2.发送具有参数的数据

以类似于获取行的方式，送出行也支持送出上的参数。

用于此的语法与获取行语法相同，其仿照HTTP询问串语法。

图50中是服务器发送具有单个参数(name＝“Fave Tracks”)的Jpeg照片的例子。

注意，尽管送出行非常像获取行，但是送出行不支持从和至(From andTo)的范围值。失败的送出将会要求数据全部重新发送。客户机将会了解送出是否失败，因为其不会接收到来自服务器的确收(见“服务器“响应”协议”部分)。

5.1.2.3.3.客户机确认

未来服务器始终可以很清楚地了解每个客户机上存在什么样的数据，要求客户机确认收到服务器发送给其的每段数据。这通过为每个成功接收和存储的数据文件发送一个确认(Ack)行来完成。

确认(Ack)行参数为服务器发送文件时分配的ackID。

MSTP/0.1

请求Id(RequestId)：123466

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

Ack：2006061911030001CHARTS

该请求显示客户机确认其已经成功收到并存储了具有分配的2006061911030001CHARTS确认id的数据文件。

客户机必须仅确认完全接收的文件。其绝对不能确认部分接收的文件。如果客户机部分接收了文件，就应该为数据的其余部分做出获取范围请求。一旦所有的数据已经接收和存储，客户机就可以发送对该数据的确认。

5.1.2.3.4.具有多个ack的客户机确认

请求可以包括多个确认行。

MSTP/0.1

请求Id(RequestId)：123466

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

Ack：2006061911030001CHARTS

Ack：2006061911030001INBOX

该请求显示客户机确认其已成功接收并存储了具有2006061911030001CHARTS和2006061911030001INBOX确认id的数据文件。

5.1.2.3.5.未确认的通知(Not acknowledged notification，Nak)

如果客户机未成功接收并存储其请求的数据文件，其应该向服务器发送未确认的通知。

MSTP/0.1

请求Id(RequestId)：123466

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

Nak：2006061911030001CHARTS

该请求显示客户机告知服务器在接收或存储具有2006061911030001CHARTS确认id的数据文件时有问题。服务器就会知道在客户机上不存在该文件。

通常当客户机发送Nak时，其很可能具有某些随附的解释Nak原因的错误数据。如果服务器接收了Nak，而没有错误数据，其可能就会想要要求客户机发送日志文件的细节。如果客户机持续向服务器发送Nak，则服务器可能会增加客户机上的记录水平，以帮助识别原因。

5.1.2.4.通话标识符

客户机发送到服务器的每个请求应该包括通话标识符。客户机在重启之间不应该记得该通话标识符。在开机之后的第一次请求中，客户机不应该包括通话标识符。服务器将通过发回新的通话标识符来进行响应。客户机之后在每个后续请求中就应该包括该标识符，直到用户关闭客户机。

MSTP/0.1

请求Id(RequestId)：123467

客户机(Client)：MusicStation 0.4.6 MIDP 诺基亚/N70

用户GUID(UserGUID)：AB12YZ

通话Id(SessionId)：FJSKNBKSKSDKFLSH

获取(Get)：inbox.data

改请求显示客户机之前已经被分配了一个通话标识符FJSKNBKSKSDKFLSH。

要详细了解客户机如何获取该通话标识符，请见“服务器“响应”协议”部分。

5.1.3.服务器响应协议

5.1.3.1.标题

5.1.3.1.1.协议标识符

用于服务器响应中的协议标识符应该与客户机请求协议标识符相同。客户机应该检查该标识符以便其了解响应是否是MusicStation协议格式。

MusicStation使用的协议标识符为：

MSTP

5.1.3.1.2.协议版本号

服务器可以同时支持很多不同的协议版本。服务器应该始终以与客户机在请求中所使用的相同协议版本号进行响应。这是因为这是服务器能够确信客户机支持的唯一协议版本号。

连同协议标识符一起，客户机应该检查响应中的协议版本号，以便他们了解正在使用的协议版本是他们理解的版本。

MSTP/0.1

这是服务器发送MusicStation传送协议标识符并使用协议版本号0.1的例子。

5.1.3.1.3.响应状态码

对每个响应服务器都会发送状态码。状态码示于图51中。

状态码始终是4个数字。这是为了允许有足够的代码以允许未来的扩展。不用3个数字的代码是为了避免与HTTP代码混淆。

状态码可扩展，新代码可以在任何时间添加。服务器将确保客户机永远只发送客户机理解的状态码。

状态码集合成2部分。以数字1开头的代码(即1000-1999)用于与成功操作相关的代码。以数字2开头的代码(即4000-5999)用于与失败操作相关的代码。

在失败的代码范围内，还有两个组。以数字4开头的代码(即4000-4999)用于客户机故障的失败。以数字5开头的代码(即5000-5999)用于服务器机故障的失败。

一下例子表示成功的来自服务器的响应。

MSTP/0.1

状态码(StatusCode)：1000

5.1.3.1.4.响应标识符

为了客户机可以验证其接收到响应是对其做出的请求的响应，每个来自服务器的响应都要回送客户机的请求标识符。

MSTP/0.1

状态码(StatusCode)：1000

响应Id(ResponseId)：234567

这个例子表示服务器响应具有请求id为234567的客户机请求。

5.1.3.2.设置通话标识符

客户机每次开机时来自客户机的第一个请求将不包含电话标识符。服务器应该用重新分配的通话标识符响应该请求。

MSTP/0.1

状态码(StatusCode)：1000

响应Id(ResponseId)：234568

设置通话Id(SetSessionId)：FJSKNBKSKSDKFLSR

这个响应表示服务器将通话id设置成FJSKNBKSKSDKFLSR。

如果客户机收到任何具有设置通话Id(SetSessionId)行的响应，则客户机必须立即开始使用新的通话id。可能会有服务器向已经有通话id的客户机分配新通话id的情况。例如，这在通话在服务器上已经超时(timed-out)的时候就会发生。

5.1.3.3.发送数据

大部分来自服务器的响应很可能包括至少一个数据对象文件。这些数据文件在响应的主体中发送。

对于每个由客户机发送的请求中的获取行，服务器都返回发送行。

服务器必须生成与数据一起发送的确认id。这是为了在服务器接收Ack行时期知道那个数据被确认了。以唯一地识别发送的数据文件的方式生成这些确认id是服务器的职责。

发送行必须包括字节偏移到数据主体中的位置，在该位置客户机可以发现数据，其还必须包括数据的长度和数据的内容类型。字节偏移和长度用于MusicStation协议中是因为它们有助于相对直接的处理。这已经像用于几部分的MIME中一样优先用于边界参数。

图52中的该响应表示服务器发送news1.data文件。

5.1.3.3.1.在请求中发送多个数据文件

服务器还可以在单个响应中发送多个数据文件。这以客户机用多个送出行向服务器发送资源一样的方式用多个发送行完成。

图53中的响应表示服务器发送news2.data和news3.data文件。

在响应的主体中该数据以粗体文本显示。因为发送行上的偏移和长度参数，客户机知道哪个主体数据用于哪个数据文件。

5.1.3.3.2.部分数据请求

如果客户请求数据的特定范围，并且服务器仅发送该数据范围，则服务器响应必须指出发送了数据的哪一范围，见图54。

该响应表示所返回的数据是从160字节到结尾的数据。该数据有40字节，并且它们在0字节定位到数据主体中(即，在主体的开头)。

注意，偏移值是到数据主体内的索引，与范围值没有关系。

范围的中止值可以用于发送行中，表示响应中的数据未到达数据文件的结尾。

客户机应该始终读取响应标题并利用其处理数据，而不是客户机发送请求标题。这是因为，如果服务器有理由返回整个数据文件，请求的范围可能不是返回的范围。

5.1.3.3.3.向客户机的数据入栈

服务器还可以发送用于其想要进栈到客户机上的数据的发送行。这通过服务器发送客户机尚未在请求中发送相应获取行的发送行来完成。见图55。

该响应表示服务器发送news1.data和command.data文件。任何入栈的数据都应该始终跟随响应主体中请求的数据。

5.1.3.4.确认

5.1.3.4.1.确认收到数据

当客户机向服务器发送数据时(例如错误数据)，服务器必须确认收到该数据，以使客户机知道服务器已经成功收到了该数据。

MSTP/0.1

状态码(StatusCode)：1000

响应Id(ResponseId)：234569

Ack：3

该响应表示服务器确认收到客户机在送出行中发送、并且客户机分配的确认id为3的数据文件。

5.1.3.4.2.发送未确认通知

同样地，如果存在接收或存储数据的问题，服务器可以否定地确认收到数据。这将允许客户机重新发送数据。

MSTP/0.1

状态码(StatusCode)：1000

响应Id(ResponseId)：234569

Ack：4

该响应表示服务器确认未收到客户机分配的确认id为4的数据文件。

5.1.3.4.3.确认请求

如果服务器已经向客户机发送了数据，并且之后在下一个来自客户机的具有不同请求id的请求中，服务器未收到该数据的确认，则服务器可以要求客户机确认其是否已经收到了数据。

这通过服务器在请求中发送要求确认行(AckRequired line)来完成。

MSTP/0.1

状态码(StatusCode)：1000

响应Id(ResponseId)：234574

AckRequired：20060619111230NEWS2

这是一个服务器要求客户机确认之前发送的确认id为20060619111230NEWS2的数据文件的例子。

注意，不需要服务器要求确认数据文件，客户机应该自动发送。要求确认行(AckRequired line)用于连接不是很好并且由于某些原因之前由客户机发送的确认未到达服务器时。

5.1.4.连接水平

客户机具有不同水平的连接速度、可靠性。带宽和等待时间。

每个客户机数据对象请求具有与其关联的预先确定的优先权水平。

客户基于可用带宽和成功连接的数目动态改变其连通性水平阈值。

优先权水平为

●立即(IMMEDIATE)—客户必须立即发送该请求，不排队等待该请求。这用于请求那些需要显示用户请求的屏幕的数据对象。

●不久(SOON)—如果网络速度/带宽可用，该客户机可以立即发送该请求。该信息对于服务器决定哪个数据要入栈到客户机上有用。

●无论何时(WHENEVER)—不需要客户机必须在任何时间临界期向服务器发送该信息。需要通知服务器该信息，但数据可以与下一个请求一起发送。

客户机可以基于其传送大量数据所花费的时间计算其带宽。这也许最好在传送音频文件时进行。

客户机可以基于带宽和成功连接数、以及发送较高优先权请求被中断的连接数来计算连通性阈值。

具有良好连通性的客户机具有允许所有优先权为“不久”或以上的讯息立即发送的连通性阈值。

具有较差连通性的客户机具有仅允许优先权为“立即”的讯息立即发送的连通性阈值。

5.1.5.指令数据对象

在MusicStation MIDP 0.4.6中，存在的唯一数据对象为内容数据对象。在连接的MusicStation版本中需要数据对象的新类型。需要这些以便服务器可以向客户机请求或发送各种数据。这些数据对象通过MusicStation传送协议发送，而不是MusicStation传送协议的一部分。它们不是协议的一部分是因为不同的指令对象用于不同的客户机实施，但是同一传送协议用于所有的实施。

5.1.5.1.服务器指令数据对象

除了内容数据对象和图像文件之外，服务器还要能够向客户机发送以下指令

●请向服务器发送总的文件空间大小

●请向服务器发送剩余文件空间大小

●请向服务器发送日志文件

●请向服务器发送错误

●请改变客户机记录水平

●设置特性

●获取特性

●请删除文件

●请发送你所拥有的文件的详细资料

●请发送带宽的详细资料

●请改变连接水平

●请请求数据文件

●请请求音频文件

●注册数据

在客户机和服务器增加新功能时，很可能会向本列表中添加项目。

服务器经常比客户机更注意客户机的连接详细资料是没有意义的。例如，诺基亚N80上的MIDP客户机无法知道HTTP连接是通过营运商网关还是通过无线LAN。服务器要了解客户机是否通过营运商网关连接是因为连接将来自公知的运营商IP地址范围。

5.1.5.2.客户机指令数据对象

客户机要能够向服务器发送以下指令

●播放列表数据

●图像文件

●总文件空间

●可用文件空间

·日志文件数据

●当前记录水平

●错误信息

●哪些文件已经被删除来为其它文件腾出空间的信息

●当前带宽水平

●使用的数据文件

●显示的屏幕

●特性值

●当前客户机时间

●注册数据

5.1.5.3.计时

服务器将一直记录各种客户机事件发生的时间。

客户机应该将从格林尼治标准时间(GMT)1970年1月1日午夜开始以秒计数的时间报告给服务器。

例如，在MIDP1.0中，这可以通过以下得到：

Calendar.getInstance(TimeZone.getTimeZone(＂GMT＂)).getTime().getTime()

MIDP说明书指出必须支持GMT时区，但是如果因为某些原因其未得到支持，则手机可以简单地使用

(new Date()).getTime()以得到客户机时间。

每个客户机利用其自身的时间设置存储时间数据。当该数据传送到服务器时，服务器可以将这些事件计时以其自身的格式转换并存储。

服务器通过将客户机本地时间与其自身的时间进行对比完成此操作。客户机报告的时间与服务器时间的△就可以算出。

当前客户机时间指令对象必须包含数据发送到服务器的时间，以便服务器尽可能精确地计算时间。

5.2.客户机数据同步

1.1.1.1 Introduction

5.2.1.简介

MusicStation中大部分屏幕被数据占据。该数据传送自服务器，并且本地存贮在客户机的文件中。当服务器上的数据改变时，客户机上的文件需要更新以反映这些变化。而且，用户能够创建并修改客户机上的文件，例如向播放列表中添加乐曲。这些改变需要可靠地传回服务器。

用户开可以通过MusicMate对数据进行改变。这些改变可能会与装置上所做的变化发生冲突。客户机和服务器需要能够将它们的数据同步，并且服务器将处理所有的冲突解决。

5.2.2.数据对象

数据对象是在服务器和客户机以及客户机和服务器之间进行交换的对象的基本单位。它们包封客户机界面内显示的、以及需要发回服务器(例如用户定义的播放列表)的某些实体(例如艺术家、专辑等等)的表达或者数据。它们在服务器和客户机之间进行交换，并且安全地存储在电话上。数据对象可以由服务器在任何需要更新客户机上的某些事项时发送到客户机。

数据对象能够将自身写入文件，并且其用于在客户机和服务器之间传送数据。文件标题包含用于写入文件的数据对象版本。数据对象的最新版本能够在所有支持版本中读取和写入文件。版本传给每个读取和写入方法，这允许我们基于版本转换什么是在读取和写入。

服务器利用该方法就能够为客户机的老版本写入数据对象文件。目标版本被设置在文件标题中，然后每个写入方法确保输出是该版本的格式。

服务器还能利用同样的方法读取老客户机写入的文件。当文件读入数据对象中时，读取方法利用版本来转换从文件读取什么属性。

数据对象包含用于占据MusicStation屏幕的数据。它们利用允许它们自身写入到文件或流中以及从文件或流中读取的方法。它们用于在客户机与服务器之间传送数据，并且将数据载入和本地存储到存储卡上的文件中。

5.2.2.1.数据对象组

数据对象可以包含其他数据对象的集合，例如“艺术家”数据对象包含“发行(Releases)”的集合。而“发行”又包含“乐曲”的集合。见图56。

数据对象还可以存储对象的列表，例如“艺术家组(ArtistGroup)”存储“艺术家”列表。“我的艺术家(My Artists)”屏幕使用“艺术家组”数据对象显示用户拥有的所有艺术家。因为“艺术家”包含“发行”而“发行”又包含“乐曲”，所以“艺术家”和“发行”也是数据对象组。

5.2.2.2.数据对象视图

数据对象视图提供存储和过滤的数据对象组视图。MusicStation中由数据占据的所有屏幕被一个或多个视图退回。对数据对象组的任何改变都传播到视图上，其负责更新屏幕以反映这些变化。

这允许我们在载入数据对象之前立即显示屏幕。由于数据对象载入到背景中，所以这些改变引起屏幕的更新，例如“我的艺术家”屏幕上的“艺术家”列表随着每个“艺术家”被载入而增长。

5.2.3.数据对象文件

每个数据对象组都本地存储在文件中。例如，“我的艺术家”艺术家组存储在其自身文件中。如果用户拥有100个艺术家，平均每个艺术家有包含10首乐曲的2张专辑^·，那么这个数据对象很快就会变得非常大。当写入该艺术家组对象时，将创建一个很大的文件，当其从文件中被读取回时，将会花费一段时间来占据。

一个可选的方法是将对象的每个集合都存储在其自身文件中。所以在我们的“我的艺术家”的例子中，艺术家列表存储在一个文件中(userartists.data)而每个艺术家的专辑列表不存储。专辑列表存储在独立的艺术家文件中，每个艺术家一个(例如artist.123.data)。然后将每个专辑存储在其包含乐曲的自身文件中(release.4567.data)。见图57。

因为每个数据对象都存储在其自身文件中，对象组可以利用同一数据对象而不必复制数据。例如，“Snow Patrol”处在“我的艺术家”组和“流行艺术家”组。如果用户从“Eyes Open”专辑购买“Chasing Cars”，我们仅仅需要更新“Eyes Open”专辑数据文件。当用户导航到“流行艺术家”时，则“SnowPatrol”屏幕将显示用户已经购买了“Chasing Cars”。见图58。

然而，该方法也显示出其自身的问题。因为“我的艺术家”数据文件仅包含艺术家id列表，所以我们需要打开每个艺术家文件并读取每个艺术家的名字，以占据“我的艺术家”屏幕。该方法有多个主要的问题。首先，我们需要将每个艺术家文件本地存储，所以任何遗失文件需要从服务器下载。没有这些文件我们就不能显示艺术家名字。第二，为列表中的每个艺术家打开新的文件连接成本相对较高，所以该方法比较慢。

^·用户不必两张专辑都拥有，但两张专辑都存在于艺术家数据对象中。

为了避免这些问题，我们可以将艺术家名字以及id一起存储在“我的艺术家”数据文件中。这就意味着我们可以很快建立“我的艺术家”列表。然而，我们这样就引入了冗余，因为名字现在既存储在艺术家组数据文件中又存储在艺术家数据文件中。见图59。

我们可能还想以另一特性归类和过滤列表。例如“搜索结果”在列表的顶部显示用户拥有的艺术家。为此，我们需要拥有者特性以及名字一起来显示列表。这是我们加入组数据文件中的更冗余的数据。

因为对象可以可以存储在许多组中，所以我们需要注意该冗余并且确保客户机或服务器负责更新。总体上，服务器将负责此更新，并且它们将响应请求被传送到客户机。无论何时，这些改变都有可能发生，当客户离线时，客户机将负责传播这些改变。在这些情况下，无论是在线还是离线，客户机将更新本地文件。例如，当消费者修改播放列表图像时，任何包含该播放列表的播放列表组都必须更新。

5.2.4.数据对象传送

数据对象在客户机和服务器之间利用连接MusicStation协议传送。可以预期大部分与客户机的通信将通过HTTP，因此客户机将负责做出出示请求。

5.2.4.1.客户机请求

客户机不总是知道对象占据在存储卡上的何处。例如，“流行艺术家”组被入栈到客户机上，但是客户机从未打开过“流行艺术家”并且不知道在用户购买了“Snow Patrol”的“Chasing Cars”时需要更新“流行艺术家”数据文件以反映此情况。然而，服务器知道此情况，因为其建立了“流行艺术家”数据文件并将该文件发送给了客户机。

为此，当服务器上的记录修改时，服务器负责更新客户机上的文件。当消费者购买了“Chasing Cars”时，服务器将计算客户机上的哪个数据文件包含“Chasing Cars”并且因此而需要更新。服务器之后将这些更新对象以购买响应入栈到客户机或者向客户机发送指令，以在可以的时候更新这些文件。最好该响应包含已经作为请求的结果修改了的所有数据对象。见图60：客户机设置对象并获取所有修改的对象。

5.2.4.2.数据对象入栈

当记录在服务器上更新而客户机离线、并且这些改变需要传播到客户机时，服务器将在下一个请求的基础上将这些入栈到客户机。例如，如果消费者从MusicMate购买“Chasing Cars”，当客户机下一次连接到服务器时，任何需要更新的对象就会入栈到客户机上。见图61客户机请求对象及获取所有修改的对象。

5.2.4.3.离线模式

当客户机离线时，消费者被阻止执行大部分可以修改数据的行为。例如，他们不能购买乐曲。

然而，他们应该可以创建、编辑和共享播放列表。客户机需要保留已经在客户机上编辑但未发送至服务器的文件列表。当客户机下一次连接时，其必须将这些文件发送给服务器。在客户机下一次连接时，客户机做出的所有改变都被发送到服务器。服务器然后向客户机返回任何的修改文件。见图62客户机发送离线模式下修改的对象。

5.2.5.改变日志

服务器保留已发送至客户机的对象的列表。但这些对象中的一个或多个在服务器上修改时，修改的对象必须尽快发给客户机。类似地，客户机保留已在客户机上创建或修改并且悬哟在服务器上更新的对象的列表。

对象_改变_日志(object_change_log)是不需要立即发送的改变所存储的地方的表格。这用于总的系统范围的改变，例如添加新艺术家。该表格还处理多个数据库做出的合并改变。在下一次创建用户通话时这些改变被通信。

消费者特定的改变在消费者_对象_改变_日志(customer_object_change_log)中出现。这些改变立即通信给客户机。

5.2.5.1.服务器对象

服务器上对象的改变存储在对象_改变_日志(object_change_log)表格中。只要可能会影响一个或多个对象数据文件的记录插入、更新或删除，就向该表格中插入一个或多个记录。该表格还允许在独立数据库中做出改变，例如在分级服务器上，然后在改变被输入时，对象_改变_日志(object_change_log)也被输入。见图63对象改变记录。

客户机上存在在数据对象的列表存储在服务器上消费者_对象(customer_object)表格中。只要为客户机创建了通话，我们就询问消费者_对象(customer_object)和对象_改变_日志(object_change_log)表格确定哪个对象为该消费者做出了改变。该询问会为单个对象返回多个改变记录也是可能的。在这种情况下，我们仅需要考虑最后的改变记录。改变的对象需要返回到客户机。见图64消费者对象。

需要返回到客户机的对象被插入到消费者_对象_改变_日志(customer_object_change_log)表格中。当改变为仅影响一个消费者的对象出现时，记录也可以插入到该表格中。例如，当消费者购买乐曲时，我们需要更新引用该乐曲的对象数据文件。见图65消费者对象改变日志。

只要我们从客户机收到请求，我们就想在响应中返回所有修改的对象。在某些情况下(带宽受限或对象很大)，我们可以随后向客户机发送指令来请求修改的对象。在需要向客户机返回许多对象的情况下，优先权字段用于确定先发送哪个对象。

为了为客户机获取修改的对象的列表，我们从消费者_对象_改变_日志(customer_object_change_log)表格中选择确认_数据(acknowledgement_date)在何处为零。

粗略看来，对象_修改_数据(object_modified_date)会为每个对象_guid(object_guid)复制并且可以分离到另一表格中。然而，为了性能的原因，客户机上的对象数据文件包含来自多于一个表格的数据，并且对象可能需要在一个客户机上更新而不是另一个。例如，艺术家列表包含每个艺术家的所有权信息，以使得他们可以被归类，用户拥有的艺术家在顶部。当消费者购买某个艺术家的乐曲时，仅有该消费者的艺术家列表被修改并需要更新。

以下的一个或多个方法可以用于更新对象_改变_日志(object_change_log)和消费者_对象_改变_日志(customer_object_change_log)表格：

●当添加、更新或删除数据时，表格上的数据库触发器可以占据对象_改变_日志(object_change_log)表格。

●例如输入新内容数据时，批处理占据对象_改变_日志(object_change_log)表格。

●实体收听者或回叫法用于EJB持续、更新和移除事件。

在多数情况下，回叫法是最适合的，但是对于较大的插入，例如数据载入，使用另一种方法可能会更有效。

5.2.5.2.客户机对象

客户机还必须保留悬哟发送给服务器的改变日志。客户机将该列表保持在RMS中。每个改变都存储在改变日志记录(ChangeLogRecord)对象中。见图66。

对象GUID(objectGUID)与用于识别服务器上的对象的GUID一样，除非客户机已经添加了该对象。在该情况下，客户机将分配临时的GUID，该GUID将一直使用到服务器用其新服务器生成的GUID更新了对象。

只要客户机连接至服务器，其就发送所有改变日志中的对象。服务器用确认响应每个对象。当客户机接收到确认时，其就删除相应的改变日志记录(ChangeLogRecord)。

5.2.6.冲突解决

当出现冲突时，因为相同的对象已经在客户机和服务器上修改，所以服务器负责解决冲突。服务器通过向客户机发送更新的对象而将解决方案通信至客户机。

我们将试图通过使服务器负责大部分更新而将可以出现冲突的状况的数量最小化。只有在少数情况下客户机能够修改对象及向服务器发送改变。

在原型中，客户机修改限于：

1.创建播放列表

2.编辑播放列表

3.删除播放列表

4.编辑消费者外形(醒目广告语，图标)

5.估级乐曲

在设计冲突解决策略时，我们需要记住以下类型的冲突：

●更新冲突 发生在记录的更新与其它更新冲突时。

●唯一性冲突 发生在记录的更新与冲突记录违反唯一性约束。

●删除冲突 发生在更新已被删除的记录时。

5.2.7.使用情况

只要对象被更新或删除，就必须更新对象_改变_日志(object_change_log)或消费者_对象_改变_日志(customer_object_change_log)表格以反映该改变。因为客户机上的对象数据文件包含冗余数据，所以改变很可能会影响不止一个对象。

5.2.7.1.服务器改变

5.2.7.1.1.艺术家发行新专辑

艺术家“Snow Patrol”发行专辑“Eyes Open”。每个包含用于“SnowPatrol”的艺术家数据文件的客户机都需要更新。

首先我们将用于“Snow Patrol”和“Eyes Open”的记录插入对象_改变_日志(object_change_log)表格。见图67。

当具有“Snow Patrol”艺术家文件的消费者连接至服务器并且创建通话时，消费者_数据_对象(customer_data_object)表格与对象_改变_日志(object_change_log)表格结合在一起以找出任何已经为该消费者修改的对象。

SELECT FROM customer_object，object_change_log

     WHERE customer_object.object_guid＝object_change_log.object_guidAND

     customer_object.deleted_date IS NOT NULL AND

     customer_object.object_modified_date                           <

object_change_log.object_modified_date；

询问返回“Snow Patrol”对象_改变_日志(object_change_log)记录。该记录被插入消费者_对象_改变_日志(customer_object_change_log)表格。见图68。

消费者_对象.修改_数据(customer_object.modified_date)字段也更新到“18/07/2006 13:16:33”。

“Snow Patrol”数据文件随后被发送到客户机，并设置customer_object_change_log.acknowledgement_id字段。当客户机确认文件时，设置customer_object_change_log.acknowledgement_date字段。

5.2.7.1.2.艺术家被移除

艺术家“Cliff Richard”被从MusicStation中移除。每个已经存储了“CliffRichard”数据文件或具有包含“CliffRichard”的列表的客户机需要更新。

对象_改变_日志(object_change_log)表格被更新，并且为以下对象插入删除的记录：

Artist

Artist.getAlbums()

Artist.getLists()

Artist.getAlbums().getLists()

Artist.getPlaylists()

5.2.7.1.3.消费者共享播放列表

消费者决定创建并共享新的播放列表“Sunday Stroll“。客户机向服务器发送新的播放列表。任何改变在下一个请求中都发送给服务器。由于你在浏览乐曲以添加至播放列表中，所以很可能你正在与服务器通信，并且每次改变都会被发送。

当播放列表对象被创建时，对象_改变_日志(object_change_log)表格被更新，并且为每个具有消费者数据对象文件的客户机向消费者_对象_改变_日志(customer_object_change_log)表格中插入记录。

5.2.7.1.4.消费者改变1消费者共享播放列表

消费者决定创建并共享新的播放列表“Sunday Stroll“。客户机向服务器发送新的播放列表。任何改变在下一个请求中都发送给服务器。由于你在浏览乐曲以添加至播放列表中，所以很可能你正在与服务器通信，并且每次改变都会被发送。

当播放列表对象被创建时，对象_改变_日志(object_change_log)表格被更新，并且为每个具有消费者数据对象文件的客户机向消费者_对象_改变_日志(customer_object_change_log)表格中插入记录。

5.2.7.1.5.定制消费者共享播放列表

消费者决定创建并共享新的播放列表“Sunday Stroll“。客户机向服务器发送新的播放列表。任何改变在下一个请求中都发送给服务器。由于你在浏览乐曲以添加至播放列表中，所以很可能你正在与服务器通信，并且每次改变都会被发送。

当播放列表对象被创建时，对象_改变_日志(object_change_log)表格被更新，并且为每个具有消费者数据对象文件的客户机向消费者_对象_改变_日志(customer_object_change_log)表格中插入记录。

5.2.7.1.6.消费者改变语言

消费者选择不同的语言。我们希望所有包含语言特定数据数据的文件被更新。

讯息特性文件和编辑器字幕都需要更新，以反映该改变。只有播放列表在客户机上显示编辑器字幕，因此对于具有编辑器字幕的客户机上的任何播放列表，向消费者_对象_改变_日志(customer_object_change_log)表格中插入记录。

5.2.7.1.7.消费者向播放列表中添加乐曲而服务器删除了乐曲

用户在离线时将乐曲T添加到播放列表。同时服务器删除了乐曲T。

当T被删除时，向对象_改变_日志(object_change_log)中插入记录。当客户机发送更新的播放列表时，我们对比改变和对象_改变_日志(object_change_log)中的记录，从播放列表中删除乐曲并将其发回。这不会向消费者通知，只是乐曲消失。

5.2.7.1.8.消费者向播放列表中添加乐曲而服务器重命名了乐曲

用户在离线时将乐曲T添加到播放列表。同时服务器重命名了乐曲T。

当T被重命名时，向对象_改变_日志(object_change_log)中插入记录。当客户机发送更新的播放列表时，我们对比改变和对象_改变_日志(object_change_log)中的记录，重命名播放列表中的乐曲并将其发回。

5.2.8.装置内存管理

装置能够向服务器通报还剩下多少内存用来存储。服务器将利用该信息决定是否应该在发出更新时将一些文件从客户机删除。

消费者_对象表格中的对象_最后_使用(object_last_used)字段存储客户机最后使用特定对象的数据。该字段从由客户机发送到服务器的日志数据占据。服务器利用该数据确定应该删除哪些文件。服务器还可以利用其它方法预测哪些文件应该被删除，例如已经不再存在于任何列表中的故事。

客户机还保留最后使用的文件的列表，并且能够在它们用完内存之前其本身删除。该列表存储在RMS中，并且用相对路径和文件名引用文件。路径和文件名比较短，因为我们想从名字中去掉任何含义。这在服务器上的删除逻辑有问题的情况下作为安全阀。

5.3.未完成的下载

5.4.客户机记录

我们需要记录客户机上的用户的行为、事件和异常并将这些发送到服务器，用来：

●在测试过程中调试信息

●提供用于消费者支持的信息

●收集使用数据用于报告和建议

5.4.1.记录器

记录器对象用于在客户机上控制记录。其为数据对象组(DataObjectSet)并且可以利用MSTP与服务器同步。

记录器包含以下属性：

●水平：日志在何水平上被存储，较低水平的事件被放弃

○调试(DEBUG)：对调试应用程序有用的事件

○信息(INFO)：突出显示应用程序的进步的信息性讯息

○警报(WARN)：表示存在潜在问题

○错误(ERROR)：出现错误但应用程序设法继续

○关闭(OFF)：未记录

●优先权：控制日志发送到服务器的频率

○最小(MIN)：客户机下一次向服务器做出请求时或达到了最大大小时。

○正常(NORMAL)：每5分钟(或者像MIN一样)

○最大(MAX)：每30秒钟(或者像MIN一样)

该性质由特性控制并且可以调整。

●最大大小(MaxSize)：在客户机上存储的记录的最大数。

●事件偏移(TimeOffset)：服务器和客户机之间的时间差

●日志记录(LogRecords)：日志本身

记录器包含用于每个客户机记录的日志记录(LogRecord)。日志记录包含以下属性：

●讯息(Message)：发生了什么的可读说明

●水平(Level)该日志的水平

●日期(Date)：利用客户机时间和时间偏移计算的服务器时间

●通话Id(SessionId)：该事件(如果有的话)发生时的服务器通话Id

●事件类型Guid(EventTypeGuid)：事件_类型表格中用于该事件(如果有的话)的标识符

●参数(Parameters)：与该事件相关的参数

见图69。

5.4.2.客户机调试

在客户机调试时，我们需要允许测试者很容易地观察客户机日志，以使得他们可以理解错误出现时发生了什么，并且可以将这些包括在Mantis故障报告中。

客户机将记录以下各项：

●任务，包括所有运行任务所需的参数

●指令，包括所有运行指令所需的参数

●异常，包括所有的相关信息

每个日志记录(LogRecord)都为作为意外事件被记录，并且可以由测试者利用意外事件监控者的web界面进行观察。因为每个记录都利用服务器时间进行记录，所以意外事件可以以日期排序，以按照发生顺序给出客户机和服务器动作的列表。

5.4.3.客户支持

当客户联系客户支持时，我们需要将记录器对象从客户机入栈到服务器，以使得客户支持可以看到客户机生成的最后的日志记录。客户机需要开启入栈，如果日志优先权设置成MIN，则其可能在一段时间不会执行。因此我们需要一种用于指示客户机投递(post)记录器对象的方法。

我们需要记录足够的信息重建用户状态。该信息将存储在日志记录.参数无用信息表格(LogRecord.parameters Hashtable)中。如果设置了事件类型Guid(eventTypeGuid)属性，记录将插入消费者_事件(customer_event)表格中，并且参数插入消费者_事件_值(customer_event_val)中。我们将使用队列插入到消费者_事件(customer_event)和消费者_事件_值(customer_event_val)中，以使事件记录不会延迟对客户机的响应。例外是消费者_记录器.优先权(customer_logger.priority)设置成了MAX。在这种情况下，我们想要在事件发生时看到它们，并且这些记录将直接插入数据库中。

5.4.4.使用数据

客户机使用数据利用触发器占据到事件表格上。因此例如当我们接收到消费者播放乐曲的事件时，消费者_乐曲.播放_计数(customer_track.play_count)增加。

5.4.5.数据库要求

客户支持需要能够控制客户机生成的记录以及其被发送给服务器的频率。这利用消费者_记录器(customer_logger)表格进行控制。见图70。

只要该表格变化，就向消费者_对象_日志(customer_object_log)中插入记录，以使得更新的记录器对象可以被入栈到客户机。

6.DRM

6.1.简介

MusicStation是基于移动电话的软件应用程序，其允许用户在移动中利用移动网络在他们的电话上发现、管理和收听音乐。奥沐尼芬(Omnifone)首先与移动网络运营商(Mobile Network Operators，MNO)合作将MusicStation推向市场，同时与音乐工业密切合作以确保MusicStation用户可以使用最广泛和最佳范围的音乐。如此巨大的数字音乐媒体库非常有价值，并且需要保护被盗用和滥用，与此同时要能使有效付费用户无缝访问。数字权限管理(Digital Rights Management，DRM)提供了一种控制和方便数字音乐合法发布和使用的方法。

最初用于MusicStation的手机技术平台是Java 2平台Micro版(Java 2Platform Micro Edition，J2ME)。选择该平台是因为其提供了最广泛的移动电话手机范围。本文件说明奥沐尼芬的J2ME MusicStation手机应用程序使用的方法以及相关的发布受保护的内容以及安全地发放使用该内容的权利的网络服务。

MusicStation的DRM是开放移动联盟(Open Mobile Alliance，OMA)DRM v2规范的实施。该规范已经被移动和音乐工业广泛采用，作为他们保护用于移动装置的内容的首选方法。虽然OMA DRM v1已经被手机厂商广泛采用，但是在本申请撰写时，只有极少数的手机支持OMA DRM v2。因此，本文件中讨论的OMA DRM v2实施已经由奥沐尼芬创建到MusicStation手机应用程序和相关的MusicStation网络服务中了。

6.1.1.DRM综述

在内容送出之前，其被打包以保护其免受未授权的访问。内容服务器(Content Server，CS)发出DRM内容，权限发放器(Rights Issuer，RI)生成并发出相关的权限对象。内容服务器和权限发放器在系统中使规则具体化。依据安排，它们可以由相同或不同的施动者提供，并且由相同或不同的网络节点实施。例如，预先打包的受保护的内容可以通过多个内容服务器分配，以高效发出内容。见图71DRM概览。

权限对象管理DRM内容可以如何使用。它是一种指定与一段DRM内容有关的许可和约束的文件。DRM内容没有相关的权限对象就无法使用，只能根据权限对象中指定的许可和约束才可以使用。

像所有的OMA v2系统一样，MusicStation DRM使DRM内容与权限对象逻辑分离，即公知的“分离发出(separate delivery)”。可以单独或一起要求DRM内容和权限对象，它们可以独立或同时发出。例如，用户可以选择一段内容，为其支付，并在同一事务处理中接收DRM内容和权限对象。之后，如果权限对象期满，用户可以返回要求新的权限对象而不必再次下载DRM内容。

与DRM内容相关的权限对象必须在消费点强制实施。MusicStation手机应用程序内的DRM代理(DRM Agent)使应用程序的信任构件具体化，负责装置上DRM内容的许可和约束、控制装置上DRM内容的访问等等。

权限对象与特定的DRM代理密码结合，因此只有DRM代理可以对其进行访问。DRM内容只能由合法权限对象访问，并因此而可以自由地分布。这使得，例如，“超分布(super-distribution)”，由于用户可以自由地在他们之间传递DRM内容。为了访问新装置上的DRM内容，必须请求新的权限对象并将其发到该装置上的DRM代理。

6.1.1.1.内容对象的保护

DRM内容格式是用于DRM内容的安全内容包，具有其自身的MIME内容类型。除了加密的内容之外，其还包含附加的信息，例如内容描述(最初内容类型、厂商、版本等等)、权限发放器URI(可以获得权限对象的位置)等等。该附加信息不加密，并且可以在重新得到权限对象之前显示给用户。在DCF文件中只有媒体内容(例如音乐文件)加密。

需要解锁DCF内的DRM内容的内容加密密钥(Content EncryptionKey，CEK)与相关的权限对象包含在一起。因此，没有权限对象就不可能访问DRM内容。DRM内容只有在权限对象中指定时才可使用。MusicStation DRM包括允许DRM代理验证DCF完整性、保护内容不被某些未授权实体修改的机制。

6.1.1.2.权限对象的保护

权限对象利用权限加密密钥(Rights Encryption Key，REK)进行保护。REK用于加密权限对象的敏感部分，例如内容加密密钥。在发出过程中，REK加密结合到目标DRM代理。这样，只有目标DRM代理可以访问权限对象，以及因此的CEK。权限对象因此固有地是安全的。

6.2.手机上的MusicStation

无论使用何种提供的方法，MusicStation最终要驻留在用户的移动电话手机上。每个MusicStation手机应用程序的安装是潜在地对每个不同的手机型号和手机固件版本唯一的软件的订购建立。软件的建立由奥沐尼芬的专利装置自适应体系(Device Adaptive Architecture，DAA)创建和管理，利用奥沐尼芬改进的提供以下说明的软件的应用程序发到正确的手机上。

6.2.1.MusicStation供应

与MNO合作，有两种方式将MusicStation移动手机应用程序“提供”到电话上，这两种方式都在本节中详细讨论。优选的将MusicStation应用程序分配到手机上的方法是在装置到达终端用户之前将应用程序预载入(预装)到装置上。发布这种类型的应用程序的经验表明，当以最想要的方式用手机上开启服务的硬键(音乐按钮)预载入时，高达93％的终端用户会发现。由MNO以OTA提供这种类型的应用程序的类似经验表明，成功率(即成功将用户连接到请求者的比率)比预载入应用程序时低一个数量级。

6.2.1.1.应用程序预载入(预装)

典型地，这种类型的装置订购由手机厂商应MNO的请求做出，并且在手机离开厂商的厂房之前完成。其也可以由手机经销商完成，例如Mobiltron，其在供应链中具有订购能力，或者在MNO仓库的房间里完成同样的工作。

无论在何处完成此预载入，其都由奥沐尼芬的预载入供应工具(Preload Provisioning tool)—预载器(Preloader)支持。预载器是预载入车间员工使用的联网桌面应用程序。对预载器的访问由软件许可证、用户id和密码控制，由授权的IP地址列表过滤。对预载器的访问可以随时被用户、软件许可证或由组织撤销。

预载器向授权的一方提供访问最新和最合适的MusicStation客户机软件建立的权利。奥沐尼芬可以控制预载器可以由厂商和型号使用何种软件建立。预载器能够实现当前MusicStation客户机软件建立的简易定位、下载和本地存储，以整合到手机订购工具以及安装方的处理中。

内建入预载器中的有一个通知系统，其可以警示安装者新软件建立对下载可用的事实。

6.2.1.2.空中发出(Over-The-Air Delivery，OTA)

由于开放的OTA API，奥沐尼芬支持大量的用户通过其可以获取MusicStation OTA的触点和机制。这包括但不限于：

●(MNO)WAP接入请求

●请求中的SMS文本

●基于Web的请求

●IVR获取

●Web服务链接

●深的(Deep)MNO网络集成，例如在SIM在网络中第一次被看见时。

不管请求的机制，MusicStation应用程序通过向终端用户提供直接在他们已经网络冲浪的WAP入口内的WAP下载页面发出，或者如果应用程序经另一种方法请求时通过WAP入栈发出。

6.2.1.3.应用程序重新安装

MusicStation应用程序包含这样的性能，即，如果服务器指示，其强制应用程序全部重新安装。在这种情况下，MusicStation应用程序利用OTAWAP下载重新下载。如果应用程序的重新安装被服务器托管，则老版本的应用程序将不运行。

6.2.2.嵌入元数据的MusicStation手机应用程序

在每个MusicStation手机应用程序中有一组信息和此处所述的自动插入并用于各种目的的元数据。

6.2.2.2.手机厂商、型号、版本和固件的修订

每个MusicStation手机应用程序都为特定的手机厂商、型号、版本和固件修订的结合建立。识别该结合的元数据嵌入在每个每个MusicStation应用程序建立中。因而服务器准确地知道各MusicStation应用程序在何种类型的手机配置上运行。即使服务器之前从未与该特定的MusicStation应用程序通信也是这样。

6.2.2.2.软件许可证

每个MusicStation手机应用程序都特别为特定的MusicStation服务建立。为此，每个MusicStation手机应用程序都具有嵌入到其中的“软件许可证(Software License)”。软件许可证是一个512位的随机数字，当其显示给服务器时，用于将该应用程序实例关联到特定的MusicStation服务。每个服务都是锁定的或未锁定的，只有未锁定的服务才能被终端用户使用。

6.2.2.3.MusicStation根CA证书(MusicStation Root CA Certificate)

每个MusicStation应用程序都具有嵌入到应用程序中的MusicStation根CA证书(MusicStation Root CA Certificate)。在本文件随后的部分中将更详细地说明的该证书用于签署和验证在MusicStation手机应用程序和服务器之间发送的讯息。

6.2.3.应用程序许可和签署

J2ME实现了安全模式，这意味着某些你通常期望在软件应用程序中能够使用的功能(例如访问内存/文件系统或访问网络)实际上是受到限制的。很清楚地，像MusicStation的应用程序使得这些特征广泛使用，因而需要访问这些普通但安全性受到保护的手机特征。

为了向MusicStation应用程序提供访问这些受限功能的能力，对应用程序进行“签署(sign)”。签名人的签名和最终的PKI证书存储在应用程序的JAD文件中。当MusicStation应用程序运行时，检验该签名并将该证书认证成已经为此目的存在于手机上的受保护域根证书中的一个。如果应用程序被正确签署，受限的功能就变得可用。

已经在电话上的根证书通常要么是来自电话制造厂商、移动网络的根证书，要么是认证授权，例如Verisign。

6.2.4.与MusicStation应用程序自身有关的DRM

黑客试图破坏DRM系统有很多方法。这些方法中的一个就是对实施DRM的软件代码实施反向工程。为此，MusicStation手机应用程序始终利用驻留在电话上的DRM进行安装，以保护软件不被移除。

尽管改进的DRM，例如OMA v2在许多手机上不存在，但是支持必需的“转发锁定(forward-lock)”内容控制机制的OMA v1在大部分手机上都存在。转发锁定就像其所暗示的一样工作，在MusicStation手机应用程序的情况下，其禁止内容项从电话转发或传送。无论MusicStation是预载入还是OTA安装的，其都安装成OMA v1转发锁定保护文件。

为了进一步保护MusicStation应用程序的OTA发送，只有已确认是从MNO网络网关发出的应用程序下载请求能得到支持。这确保应用程序代码仅从特定的MNO的移动互联网上下载到手机，而不是从普通互联网上发布。这通过确认在网络通信标题和元数据中发现的源或路由IP地址是那些存储在数据库中以及MNO已知的地址来实施。

6.2.5.预载入音乐

音乐内容可以在安装应用程序的同时预载入到电话上。该内容或者是用于宣传而免费、并且可能不是DRM的，或者是用于购买、承受与如果音乐是经MusicStation下载OTA的话而会被施加的DRM相同的DRM。预载入的内容能使MusicStation从框播放(box playing)中出来。

6.3.第一次使用MusicStation

在MusicStation应用程序可以被它的主人使用之前，其必须首先连接到MusicStation服务器，以使其可以向适当的MusicStation服务注册并被发放给客户机证书(以及关联的客户机私钥)，以便其可以访问其下载的受保护的音乐内容。为了被发放给权限对象(包含访问DRM受保护内容的访问规则和密钥)，MusicStation应用程序必须还向权限发放器注册，此两步注册过程在本节进行说明。

6.3.1.MusicStation服务注册

MusicStation第一次启动时，其就知道需要连接到MusicStation服务器以向服务注册并装上客户机证书和客户机私钥，以便其可以访问DRM受保护内容。为了发生注册，服务器需要能够唯一地识别装置。“双向(2-pass)”MusicStation服务注册协议就是实现这个目的的协议。该协议包括装置和订户的识别，随后是从MusicStation服务器(认证授权)返回到装置的客户机证书和关联的客户机私钥的安全传送。由于只有该MusicStation装置可以访问客户机私钥是强制的，所以注册协议使用HTTPS进行安全通信。

6.3.1.1.服务注册请求

MusicStation应用程序试图访问手机的IMEI、蓝牙地址、IMSI和订户的MSISDN，以使得其可以向服务器提供信息，以唯一地识别装置和用户。发送到服务器的请求参数在图72的表格中说明：服务注册请求参数。

必须提供IMEI、蓝牙地址或IMSI中的一个，以在服务器上识别装置或SIM卡。

6.3.1.2.添加元数据的MNO

由于从MusicStation手机应用程序到MusicStation服务器的通信通过MNO的连网设备路由，所以随后的订户以及潜在地还有手机标识符被添加到HTTP请求的标题中。该信息从这些标题中提取，被MusicStation服务器用于添加识别的目的。见图73。

必须提供MSISDN或当事人ID，以在服务器上识别订户。

6.3.1.3.服务注册过程

当MusicStation服务器收到服务注册请求讯息时，随后进行这些步骤。

6.3.1.3.1.从MNO本地网络注册？

当服务器收到注册请求时，其检查当前正在其上使用MusicStation手机应用程序的移动数据网络是MNO的本地网络。这利用一组存储MNO本地网络网关的IP地址的记录的数据库和互联网流量路由设备完成。

正常的设置是，仅允许装置在MNO的本地网络上或其他特定网络、例如具有漫游协定的第三方MNO的本地网络上注册。

6.3.1.3.2.消费者凭证验证

收到向MusicStation服务注册新MusicStation手机应用程序的请求后，服务器将执行以下测试：

●确认软件许可证是用于有效和活动的MusicStation服务。

●确认订户已经被识别，例如通过MSISDN或当事者ID。

●确认MSISDN或当事者ID是该MNO的消费者(如果API在MNO上存在)。

一旦确认了这些凭证，服务器继续进行以下PKI阶段。

6.3.1.3.3.MusicStation和公钥基础结构(MusicStation & Public KeyInfrastructure，PKI)

在MusicStation服务注册成功完成之后，装置需要向权限发放器注册，以使得其可以请求权限对象并进而访问DRM内容。然而，权限发放器仅注册其可以肯定地识别的装置。该识别由用作PKI认证授权(CA)、并为每个注册的MusicStation手机应用程序产生公钥证书、客户机证书并进而证实每个装置的确实性和同一性的MusicStation服务器促进。MusicStation权限发放器信任CA，其具有MusicStation根CA证书的副本，所以其可以通过MusicStation手机应用程序确认显示给其的客户机证书实际上是由CA发出的。

公钥基础结构(PKI)是用来为信任的第三方检查和担保用户的标识，或者，在本文的上下文中是MusicStation手机应用程序的标识做准备。其允许将公钥接合到用户。这通常在中心位置由软件实施，在这种情况下，是MusicStation服务器以及其他分布位置上的协同软件，即MusicStation手机应用程序。

PKI配置能使用户(MusicStation应用程序、MusicStation服务器、MusicStation权限发放器等等)被确认，并使用PKI证书中的信息(即每个其它公钥)加密和解密在系统中各方之间移动的讯息。总体上，PKI包含客户机软件(MusicStation手机应用程序)、服务器软件(MusicStation服务器)例如认证授权和操作程序。用户可以利用其私钥数字签署讯息，另一用户可以检查该签名(利用PKI内的CA发布的用户证书中包含的公钥)。这使两个(或更多)通信方不必预先交换任何秘密信息就能够建立机密性、讯息完整性和用户确认。

CA的签名的真实性、以及CA是否可以信赖，都可以通过检测其证书来确定。然而，该链必须在某处结束，这在MusicStation CA根证书处完成，这样叫是由于其在树形图的根部。根证书被隐含地信任(它们有时被称为信任锚(Trust Anchor))并包括在许多应用程序中，例如web浏览器，或者在这种情况下是MusicStation权限发放器和MusicStation手机应用程序。

6.3.1.3.4.客户机证书和客户机私钥的生成

发放新客户机证书的第一步是为正注册的MusicStation手机应用程序生成新的公钥和私钥对。PKI的该实施利用RSA 1024位公钥算法。

一旦密钥对已经生成，公钥就被MusicStation CA用于建立、然后发放客户机证书。客户机证书表明CA证实包含在客户机证书中的公钥属于证书中注明的MusicStation手机应用程序。CA的义务是验证请求者的凭证，以使用户(依赖方，例如MusicStation权限发放器)可以信任CA证书中的信息。理念是如果用户信任CA并且可以验证CA的签名，则他们就也可以验证某个公钥实际上确实属于在客户机证书中认证的任何人。

客户机私钥不存储在MusicStation服务器上，只有客户机公钥是，因此服务器可以创建只有该装置可以打开的讯息。

X.509标准用于所有的MusicStation证书。X.509是一种用于公钥基础结构(PKI)的ITU-T标准。X.509在其它事物中为公钥证书指定标准格式和证书路径确认算法。

6.3.1.3.5.客户机GUID

客户机GUID为唯一的号码(全球唯一ID，Globally Unique ID)，其每次在新MusicStation手机应用程序向服务器注册时生成。客户机GUID返回到MusicStation手机应用程序，因此其存储并返回到所有发往MusicStation服务器或MusicStation RI的后续通信和请求。

6.3.1.4.服务注册响应

服务注册响应讯息响应MusicStation服务注册请求讯息从CA发送到装置。其在HTTPS上承载受保护的客户机证书和客户机私钥。见图74：服务注册响应参数。

只有状态(Status)＝“成功(Success)”时才强制。

6.3.1.5.后服务注册过程

在为服务注册成功返回结果后，MusicStation手机应用程序执行随后的任务。

6.3.1.6.客户机证书存储

用于装置的客户机证书存储在应用程序的记录管理系统(RMS)内存存储器中。J2ME中的RMS提供这样一种机制，通过该机制应用程序可以持续存储数据并随后重新得到。在面向记录的方法中，J2ME RMS包含多记录存储。

6.3.1.6.1.客户机GUID存储

客户机GUID被加密、编码并存储在应用程序的RMS中。这用于所有未来的发往MusicStation服务器和MusicStation RI的请求中。

6.3.1.6.2.客户机私钥存储

MusicStation手机应用程序利用J2ME专用RMS特征。这意味着只有创建RMS记录存储的MusicStation应用程序可以使用它。

然而，MusicStation在确保客户机私钥方面走得更远。MusicStation手机应用程序仅在加密客户机私钥之后对其进行存储，作为不大可能的RMS泄密的情况下的额外安全措施。此外，应用程序还利用某些技术在客户机私钥存储到RMS之前或在其存储过程中扰乱客户机私钥。

6.3.2.权限发放器注册

紧接着装置获取其客户机证书之后，其试图向权限发放器(RI)注册。装置在其可以注册及从RI获取权限对象之前必须向MusicStation服务注册。RI注册程序的成功完成允许装置获取域密钥(Domain Key，DK)。DK是128位的AES对称密钥，用于保护发送到装置的权限对象的权限加密密钥(Rights Encryption Key，REK)。

RI注册协议是完全安全的装置和RI之间的信息交换和信号交换。RI注册响应讯息响应RI注册请求讯息从权限发放器发送到装置。该讯息完成注册协议，如果成功，能使装置为该RI建立RI上下文。RI上下文包含在双向(2-pass)RI注册协议过程中与权限发放器谈判的信息。该RI上下文对于装置成功获取权限对象来说是必需的。

6.3.2.1.DRM域

域是一组一至多个的装置，其拥有共同的由权限发放器发放的域密钥。同一域中的装置都可以访问同一域权限对象(RO)，并潜在地之后是由这些RO保护的音乐。

在MusicStation中，DRM域为网络中心的。RI定义域、管理域密钥并控制包括多个装置中的哪些以及如何包括以及从域中排除哪些及如何排除。典型地，每个MusicStation手机应用程序具有其自身的DK，并且在每个域中只有一个MusicStatio装置。

6.3.2.2.RI注册请求

RI注册请求讯息从装置发送到权限发放器，以启动双向(2-pass)RI注册协议。见图75 MusiStation RI注册请求参数。

6.3.2.3.RI注册响应

RI注册响应响应RI注册请求讯息从权限发放器发送到装置。当成功注册时，其得出发到MusicStation手机应用程序的域密钥。该DK利用在请求中发送到RI的客户机证书中发现的客户机公钥加密。该方法DK可以被安全地传送到装置，因为只有装置能够使用其客户机私钥，该客户机私钥对解密和访问DK来说是必需的。见图76：RI注册响应参数。

只有状态(Status)＝“成功(Success)”时才强制。

6.3.2.4.后RI注册过程

在成功接收RI注册响应之后，MusicStation加密并扰乱返回的域密钥，并将其存储在应用程序的专用RMS中。DK随后被MusicStation用来访问DK加密的权限加密密钥(Rights Encryption Keys，REKs)，以访问权限对象(RO)的敏感部分。

6.4.收听音乐

为了收听音乐，MusicStation装置需要作为DRM受保护内容的DRM内容格式的音乐文件以及包含内容加密密钥以解锁DRM的RO。

DCF或相应的RO在某一时间都不在装置上是可能的。RO包含用于DCF的URL，DCF包含用于RO的URL，这样，如果你有了一个的话，你就可以获得另一个。如果两个都不在装置上，则MusicStation应用程序中显示的乐曲收听还包含用于RO和DCF的URL，因此，通常在乐曲已经在搜索中定位后或者在浏览时同时请求两个文件。

6.4.1.权限对象获取

双向(2-pass)RO获取协议是一种装置通过其获取权限对象的协议。该协议包括装置和RI、完整性受到保护的请求和RO的发出、以及处理RO所必需的密钥材料的安全传送的相互确认。

6.4.1.1.RO获取请求

RO获取请求讯息从装置发送到RI以请求权限对象。该讯息是双向(2-pass)RO获取协议的第一个讯息。见图77：MusicStation RO获取请求参数。

6.4.1.2.RO获取响应

RO获取响应从RI发送到装置以响应RO获取请求讯息。其承载包含所述用于音乐DCF的受保护的内容加密密钥(CEK)的RO。见图78：MusicStation RO获取响应参数。

只有状态(Status)＝“成功(Success)”时才强制。

6.4.1.3.客户机证书废除

RI在每个装置通话中核对一次CA以确定装置的客户机证书仍然有效。CA保留证书废除清单(CRL)，该清单是已经被撤销并且不会再信赖的客户机证书的清单。只要使用证书，就必须核查该清单以检查废除状态。如果CA不适当地发放了证书、私钥泄密、用户违反CA的使用策略或者MusicStation管理员已经因为某些原因拒绝访问该装置，证书就要被撤销。

6.4.2.内容下载

本部分说明如何准备、保护音乐内容以及如何从MusicStation内容服务器将音乐内容下载到MusicStation装置。

6.4.2.1.内容准备

在音乐内容能从MusicStation内容服务器(CS)下载之前，其通过加密被保护免于未授权的访问。加密音乐文件产生新的公知为DRM内容格式(DRM Content Format，DCF)的文件。

在MusicStation中，对音乐内容的加密利用128位RC4对称内容加密密钥(CEK)完成。每个DCF具有不同的128位RC4 CEK。因此，如果音乐库中有1,000,000首乐曲，并且每个乐曲可以以10个不同的文件格式获取(为了迎合不同的手机要求和音乐能力/代码)，那么就有10,000,000个不同的CEK，每个物理文件一个。这就意味着，即使CEK对一个DCF泄密，其它的DCF也不会因此而泄密。

6.4.2.2.内容获取请求

由于每个DCF本身是安全的，所以DCF可以利用不安全的传输协议传输。因此，MusicStation装置利用HTTP请求音乐内容。见图79内容获取请求参数。

6.4.2.3.内容获取响应

来自MusicStation内容服务器的响应典型地是通过HTTP请求的DCF文件的二进制流。这在整个文件中占主流，但是有时文件传送会被损坏的移动网络覆盖所中断。在这种情况下，MusicStation手机应用程序做出后续的内容获取请求，但是这次，其利用范围参数仅请求其尚未拥有的DCF部分。

随着DCF字节流到达装置，MusicStation应用程序逐渐将文件写入手机的文件系统。内部和外部(移动媒体)存储器都可利用。当MusicStation的结合了内部和外部存储器的分配填满时，MusicStation移除未播放时间最长的乐曲。这一直重复到有足够的空间用于新请求的乐曲。

所有的音乐内容都以其下载时的初始的受保护DCF格式存储。为了访问任何DCF内的音乐，需要相应的RO，以使得可以访问CEK。

6.4.3.播放音乐内容

为了通过MusicStation应用程序播放音乐，需要在电话上有乐曲DCF和相应的RO。首先检查RO，以确定用户是否有权播放音乐。如果有，从RO中提取CEK并用于解密DCF，以访问接下来要通过电话的媒体播放器播放的乐曲。

6.4.3.1.评估权限表达语言(Rights Expression Language，REL)

一旦做出了播放乐曲的请求，而用于该乐曲的相关RO和DCF都在电话上存在，则由MusicStation DRM代理分析包含在RO中的权限表达语言。REL定义与该RO关联的DCF中的内容可以被用户消费和使用的方式。REL表达的权限可以非常丰富，例如包括：

●内容免费无限制地回放。

●内容可以播放一次然后就必须购买。

●内容可以免费播放一周然后就必须购买。

●内容可以免费播放一月但不能超过5次。

●如果购买，内容可以播放无限次。

●如果用户当前处于有效的AYCE预定期，内容可以播放无限次。

6.4.3.2.加密内容

如果DRM代理从REL确定用户能够播放音乐，则使用128位AESREK为关联的DCF获取访问加密的CEK的入口。然后利用128位RC4CEK解密DCF以访问初始的乐曲。该解密的乐曲依据特定手机的特性，或者在乐曲回放的整个时段内存储在非永久性时间内存中，或者其逐渐地作为解密流发送到手机媒体播放器。解密的乐曲绝不会永久存储在手机上。

6.5.不限量(All-You-Can-Eat)服务

由于MusicStation的复杂DRM实施，支持高级的内容访问模式，例如不限量(All-You-Can-Eat，AYCE)，是可能的。这允许有效预定期内的用户可以在每当他们想要的时候不限制地有权下载和播放每个乐曲。

6.5.1.预定期

MusicStation支持很大范围的预定期，例如每天、每周、每月或其它任何所需的周期。预定期从MusicStation服务器与MNO记账系统通信并成功地支付了用户的电话费用，而且为预定期适当支付的时候开始。

MusicStation服务器通过记录用户账单成功支付(预付费或后付费)的日期/时间和用户所支付的预定期的周期长度来保持用户的预定期状态。该信息与MusicStation手机应用程序上的DRM代理共享，因此装置知道用户是否拥有有效的预定。

6.5.2.预定过期

实施AYCE预定的优选方法是滚动预定法。在该方法中，当当前预定期用完时，MusicStation服务器自动购买新的预定。用户具有删除预定的选项，这会引起自动重新预定暂停。如果用户在最后有效预定期的有效期限之后试图访问内容(无论是否是装置上的)，就会询问用户他们是否想要重新开始其预定。如果是，则再次开始滚动预定。

在预定模式不是滚动预定时，每次当前周期终止时用户需要确认他们希望预定另一个AYCE周期。

6.5.3.父权限对象

权限对象可以从另一个权限对象继承许可。该机制例如用于作为AYCE预定的一部分要求的内容指定权限。继承许可的RO称为子权限对象(Child Rights Object，C-RO)。包含被继承的许可的权限对象被称为父权限对象(Parent Rights Object，P-RO)。

客户机装置验证同一权限发放器发放C-RO及其相关的P-RO，在关联内容对用户可用之前它们都属于同一域。P-RO不直接引用任何DRM内容。

6.5.4.DRM时间

电话上的DRM代理理想地永久有权使用用户不能改变的精确时期/时间(DRM时间)。但对移动电话来说情况不是这样的，因此MusicStation必须使用各种方法确保可靠的DRM时间对DRM可用，以使得可以向合法改变它们电话日期/时间的用户提供公平的访问权利，同时抵抗那些试图欺骗系统、在预定服务内获取非法访问权利的用户。

虽然电话可以合法地具有在任何点改变的其日期/时间(例如，最初其已经被设定，改变时区或日光节约时制)，MusicStation服务器始终保持可靠的日期/时间。因此，虽然有网络连接，DRM代理还是可以始终访问可靠的日期/时间数据。

因为MusicStation服务器日期/时间潜在地不同于装置的本地日期/时间，所以DRM代理使用相对于本地日期/时间的计时器而不是绝对的日期/时间。然而，其还监控相对于其了解本地日期/时间应该基于其保持的计时器的本地日期/时间。这允许不需要网络连接就能使预定期满，并且还能识别本地电话日期/时间的改变。只要网络连接出现，则重置所有的计时器和实际日期/时间知识。

当用户试图通过将其日期/时间设定到过去的某一时间来欺骗系统时，就会潜在地出现问题。利用以下逻辑成功地解决了这些问题：

●当MusicStation手机应用程序开启时，其将本地日期/时间与应用程序上次关闭的日期/时间进行对比。如果应用程序打开日期/时间在应用程序上次关闭的日期/时间之前，则从相对计时器中减去这两个日期/时间之间的差。

●最终结果就是，确定的用户可以为他们没有网络连接时使用MusicStation的最长时间就是等于已支付的预定周期(例如一周)的时间的长度的总计应用程序使用时间。为了完成此操作，他们需要记下他们每次关闭MusicStation的时间并在每次打开MusicStation之前将他们的电话日期/时间重置到该时间。显然，有限的奖励看起来不值得付出。

●在应用程序运行的时候每分钟检查一次日期/时间，以保护用户在应用程序打开的时候不改变日期/时间。如果当前日期/时间在上次日期/时间之前，则从相对计时器中减去这两个日期/时间之间的差。

如果用户合法地将他们的本地日期/时间改变到了一个未来的日期/时间，并且装置能连接到服务器，则期满时间与服务器重新同步。如果连接不可用：

●如果未来的时间仍在有效预定期之内，在播放乐曲。

●如果未来的时间大于许可的期满时间，在系统的可配置阈值之外，则乐曲不能播放，知道装置连接至服务器。不可能区分用户将其时钟向前拨动(MusicStation不运行)还是用户很长时间未使用MusicStation。通过数据网络连接到服务器需要重新激活用户或更新预定。

6.5.5.AYCE记账

为AYCE系统记账需要每个终端用户的每个乐曲的播放的绝对记账。因此乐曲消费信息需要被传回服务器，其中所有MusicStation装置的所有有质量的播放被合计到一起。这些合计的播放记账用于确定对于每个权利所有人的特许付款额，该权利所有人的音乐已经在记账周期中播放。播放小于预览阈值周期，例如30秒钟的乐曲被认为是免费预览，不包括在特许付款额计算中。

因此，MusicStation不会引起不必要的网络流量，播放记账在装置上缓冲，直到应用程序需要自然网络连接。该缓冲在播放记账可以缓冲延伸的时间段的情况下还延伸到0G(飞行和隧道等等)，并在最终实现连接时发送到服务器。

6.5.6.混合的模式

MusicStation提供混合的商业模式，该模式中AYCE中的用户还可以做出乐曲的超权限购买(outright purchase)。如果预定期终止而没有更新，那些用户已经购买的乐曲还可以使用。

6.6.附录A：密钥管理

这是对权限发放器利用只有装置上的MusicStation手机应用程序中的DRM知道的公钥向装置发放域密钥(DK)的加密方法的说明。一起说明的还有RI通过利用REK保护RO中的CEK的方法，其中所述REK利用先前发给装置的KD向已经第一次被加密的装置。

6.6.1.在装置公钥下分配K_D

本部分在向装置提供域密钥K_D时应用。

K_D是对称的密钥封装(key-wrapping)密钥，用于保护K_REK(“权限对象加密密钥”)发放到域D中时。K_D是128位长的AES密钥，由发送者随机生成，并且应该对每个域D是唯一的。K_REK是用于权限对象中内容加密密钥K_CEK的封装(wrapping)密钥。

对称加密方案RSA应该用于利用装置的RSA客户机公钥安全地将K_D传输到接收装置。

C＝RSA.ENCRYPT(ClientPubKey，K_D)

收到C之后，装置利用其客户机私钥解密C：

K_D＝RSA.DECRYPT(ClientPrivKey，C)

6.6.2.在域密钥K_D下分配K_REK

本部分在为域保护权限对象时应用。

应该利用密钥封装方案AES-WRAP。RI利用K_D加密K_REK：

C＝AES-WRAP(K_D，K_REK)

收到C之后，装置利用K_D解密C：

K_REK＝AES-UNWRAP(K_D，C)

附录1：屏幕流程

7.简介

本附件提供MusicStation客户机的屏幕和用户界面的说明。其包括全部特征的清单，以及用于每个特征的用户体验和适当的屏幕截图的说明。

特征分到应用程序的主要功能组中，通常跟随在应用程序的菜单结构之后。

7.屏幕布局和用户对话

7.1.注册

见图80。当第一次开启MusicStation时，用户将看到一个讯息，同时客户机向服务器注册，向用户提供唯一的标识符或GUID。

7.2.加入MusicStation

见图81。当用户第一次试图使用MusicStation的任何会产生费用的特征时，他们被要求加入任意的免费试用期。接着他们被要求确认并给出选择以通过wap链接察看条件。之后预定被确认，他们被要求选择确认继续。成功预定了的用户被认为是MusicStation的会员。

7.3.标签和菜单

见图82。用户界面被分成四个标签。每个标签集中在MusicStation的一个特定的核心功能。

●主页(Home)—向用户提供访问MusicStation中所有可使用的内容，包括图表和所有的核心功能，例如搜索、选项等等的入口。其还突出显示用户已经下载的内容(即“存储”和“库”)。

●Buzz—提供访问社区特征和音乐新闻的入口。

●列队(Lineup)—显示下载和收听乐曲的当前队列。

●播放(Playing)—显示当前正在播放的乐曲的详细资料。

主页标签和Buzz标签由多个以分级选项菜单结构排列的屏幕组成。

7.4.菜单和标签导航

用户使用操纵杆通过应用程序的标签和菜单导航。见图83。

7.5.更多菜单

7.5.1.访问功能

见图84。每个屏幕包括一个手机右手边软键上的更多(More)菜单，其提供访问与当前选择项和作为整体的屏幕有关的功能的入口。当前不可用的选项在该菜单上灰化，不能选择。

更多菜单可以通过用右手边的软键选择取消(Cancel)来再次关闭。

7.5.2.上下文有关选项

更多菜单中可以使用的选项对当前突出显示的项上下文有关。该表中列出了常用的更多菜单选项和选择的更多菜单选项执行的动作的说明。见图85和86。

请见附录2：详细列出的每个MusicStation选项可以使用的更多菜单选项的上下文有关菜单。

7.6.返回

见图87。屏幕导航历史被保留。用户可以在任何时间在任意给定的标签中按下左手边的软键返回前一屏幕。在例如索尼爱立信(Sony Ericsson)出产的手机上，如果手机具有硬返回键，则其也可以用于返回屏幕历史。

7.7.音乐回放

见图88。不同的键预先设定并关联到音乐回放功能，因此用户可以从应用程序的任何屏幕控制回放，而不必返回到播放(Playing)标签。例如，无论用户是否在用户界面内，[5]键都暂停和重新开始音乐回放。见图89。

7.8.帮助

见图90和91。用户可以通过按下[1]键察看键区帮助。该屏幕显示按压手机上的任何数字键所执行的动作，而不管用户在MusicStation中的位置。

7.9.键区锁定

见图92和93。键区通过用户按下并保持[^＊]键锁定。为了解锁键区，用户再次按下并保持[^＊]键。在导航键被锁定时，音乐将继续播放，但菜单选项或其他音乐播放控制键将不能使用，以防止意外使用。

7.10.最小化

见图94和95。应用程序还可以通过按下并保持[#]键最小化。为了停止音乐，用户必须重新打开MusicStation。

7.11.退出

见图96。当用户从更多菜单中选择关闭时，则如果正在播放音乐，他们就会被询问是否想要继续播放音乐。

●退出并保持音乐播放—MusicStation将最小化并移到手机的背景中。用户就可以继续使用手机的功能同时收听音乐。用户可以在任何时间返回MusicStation。

●退出并停止音乐—在这种情况下，MusicStation将停止音乐回放并完全退出。用户随后使用时需要重新启动MusicStation。

8.基本概念

8.1.列队(Lineup)

第三标签或者说列队对用户理解MusicStation来说是一个关键的概念。其提供用户当前音乐选择的永久察看。用户选择的任何用于播放(如果还不在手机上就默认为下载)的音乐被添加到列队中。用户可以选择任何专辑、播放列表或单曲并将其添加到列队中。

8.2.播放列表

在MusicStation用户界面内有多种类型的播放列表。

8.3.估级

见图98。MusicStation提供社区特征，包括为其用户提供建议。为了能使用户加入到该过程，MusicStation界面内的许多不同项都可以被估级。以下项可以被估级：

●乐曲

●专辑

●艺术家

●播放列表

●其他成员

用户通过在界面中选择项然后从更多(More)菜单中选择估级(Rate)选项对该项进行估级。用户为每个项有三个等级选择：

●我喜欢它(I love it)

●一般(Neutral)

●我讨厌它(I hate it)

从所有用户收集这些等级，由MusicStation用于为这些项生成星级。这些星可以在全部界面的不同的位置看到，并且给用户基准一个各项相对受欢迎的观点。用户估级也用于生成建议和图表，例如最佳播放列表(TopPlaylists)清单(获取新播放列表(Get New Playlists)屏幕)

8.4.屏幕更新

MusicStation包括被称为“智能背景下载器(Intelligent BackgroundDownloader)”的构件。该构件负责将所有的音乐和数据下载到手机中。其在背景中运行，并为播放列表发送音乐、为所有动态菜单发送内容。因为其在背景中运行，其可以向任何屏幕发送更新的内容而不干扰用户享受MusicStation。

例如，列在收件箱(Inbox)标签上的新艺术家可能会在用户收听音乐时更新，因此，当用户下一次转换到Buzz标签时，最新的艺术家已经在那里准备并等候用户了。

9.最高水平菜单

用户界面被分成四个标签。每个标签集中在MusicStation的一个特定的核心功能。

●主页(Home)—向用户提供访问MusicStation中所有可使用的内容，以及所有的核心功能，例如搜索、选项等等的入口。

●Buzz—提供访问社区特征和音乐新闻的入口。

●列队(Lineup)—显示用于收听的乐曲队列的当前队列。

●播放(Playing)—显示当前正在播放的乐曲的详细资料。

主页标签和Buzz标签由多个以分级选项菜单结构排列的屏幕组成。以下表格提供主页标签和Buzz标签的最高水平菜单中的选项列表，以及本文件详细对其进行说明的部分的相互对照。见图99和100。

列队(Lineup)和播放(Playing)标签无任何菜单。它们是关于当前音乐的单一固定视图。列队(Lineup)显示用户当前对下载和播放音乐的选择的永久察看。播放(Playing)标签只显示当前乐曲。

10.主页

10.1.播放列表

见图101。播放列表(Playlists)屏幕给出用户通向播放列表的入口。用户可以察看和管理他们的私人和共享播放列表。用户还可以使用获取新播放列表(Get New Playlists)选项察看和下载编辑/内容团队或其他用户提供的播放列表。

10.1.1.我的私人播放列表

私人播放列表是用户创建但未与MusicStation社区共享的那些播放列表。私人播放列表列在我的私人播放列表(My Private Playlists)标题下。用户可以决定通过选择私人播放列表然后从更多(More)菜单中选择共享(Share)选项来使任何这些播放列表公开。

10.1.2.我的共享播放列表

见图102。共享播放列表是用户与MusicStation社区共享的那些播放列表。共享播放列表列在我的共享播放列表(My Shared Playlists)标题下。用户可以决定通过选择共享播放列表然后从更多(More)菜单中选择使私人化(Make Private)选项来使任何这些播放列表私人化。

10.1.3.获取新播放列表

见图103。获取新播放列表(Get New Playlists)选项提供通向编辑播放列表(Editorial Playlists)、自动生成播放列表(Automatically GeneratedPlaylists)和来自其他用户的共享播放列表(Shared Playlist)的入口。用户可以察看、播放和估级任何这些播放列表。见图104。

这些屏幕上的列表由MusicStation每晚或每周更新。

10.1.4.创建播放列表

见图105。利用创建播放列表(Create playlist)选项，用户可以创建私人或共享播放列表。用户提供播放列表名称并从图片库中为播放列表选择图像。一旦创建，用户就可以利用在所有界面中发现的添加到播放列表(Add to Playlist)选项将乐曲添加到播放列表中。用户还可以在选择添加到播放列表(Add to Playlist)之后创建新的播放列表。

10.2.删除播放列表

用户可以提供突出显示播放列表并从更多(More)菜单中选择删除(Delete)来删除任何他们的私人或共享播放列表。

10.2.1.察看播放列表

见图106。用户可以察看播放列表内的乐曲。用户还会看到与该播放列表关联的图像、播放列表的总播放时间以及播放列表中的乐曲数。如果播放列表为共享播放列表，则其星级也会显示。

在每个播放列表的底部有所有乐曲(ALL TRACKS)选项，用户可以选择该选项来将播放列表中的所有乐曲添加到列队中。

10.2.2.估级播放列表

用户可以估级共享播放列表。所有用户提供并一起用于生成最佳播放列表(Top playlists)和你可能会喜欢(You might like)...列表的估级随后反馈到用户的获取新播放列表(Get New Playlists)屏幕上。见8.3部分。

10.3.艺术家

见图107。专辑(Albums)屏幕给出用户通向MusicStation目录中所有可用专辑的入口。用户可以察看他们过去曾经从中下载过的乐曲的艺术家。用户可以使用获取新艺术家(Get new artists)选项察看和收听一般的艺术家或该用户个人感兴趣的艺术家。

10.3.1.我的最佳艺术家

在艺术家(Artists)屏幕的我的最佳艺术家(My Top Artists)部分，用户可以察看他们已经从中下载乐曲的他们的艺术家的选择列表。该列表由用户已经下载的乐曲所属的艺术家组成。这向用户提供通向他们喜欢的艺术家的捷径。通常，他们已经下载了的乐曲的所属所有艺术家受到限制(取决于电话)，以确保其不至于过长。

10.3.2.获取新艺术家

见图108。获取新艺术家(Get new artists)选项提供通向已经由MusicStation利用用户的收听习惯和反馈自动或编辑生成的艺术家列表的入口。这些基于两个主要的分类：受欢迎的艺术家，例如最佳艺术家、最佳流行、最佳摇滚等等，以及建议的艺术家，例如你可能会喜欢。

这些屏幕上的列表由MusicStation每晚或每周更新。

见图109。

10.3.3.艺术家外形—察看艺术家

见图110。用户可以察看艺术家外形，包括图像、艺术家的MusicStation星级、被下载的乐曲数、被下载的乐曲清单以及这些被下载的乐曲的总播放时间。用户可以从该屏幕察看和播放该艺术家所有可以使用的乐曲或专辑。

10.3.4.艺术家外形—获取新乐曲

见图111。用户可以察看选择的艺术家的所有可用乐曲的清单。用户可以从该屏幕播放和估级乐曲。

10.3.5.艺术家外形—获取新专辑

见图112。用户可以察看选择的艺术家的所有可用专辑的清单。用户可以从该屏幕察看、播放和估级该专辑中的乐曲。

10.3.6.估级艺术家

用户可以利用更多(More)菜单中的估级(Rate)选项估级任何艺术家。见8.3部分。

10.4.专辑

见图113。专辑(Albums)屏幕给出用户通向MusicStation目录中所有可用专辑的入口。用户可以察看他们过去曾经从中下载过乐曲的专辑。用户可以使用获取新专辑(Get new albums)选项察看和收听一般的专辑或该用户个人感兴趣的专辑。

10.4.1.我的最佳专辑

在专辑(Albums)屏幕的我的最佳专辑(My Top Albums)部分，用户可以察看他们已经从中下载乐曲的他们的专辑的选择列表。该列表由用户频繁从中下载乐曲并收听的专辑组成。这向用户提供通向已下载的专辑的捷径。

10.4.2.获取新专辑

见图114。获取新专辑(Get new albums)选项提供通向已经由MusicStation利用用户的收听习惯和反馈自动或编辑生成的专辑列表的入口。这些基于两个主要的分类：受欢迎的专辑，例如最佳艺术家、最佳流行、最佳摇滚等等，以及建议的专辑，例如你可能会喜欢、刚发行的。用户可以很容易地任意播放或察看。

这些屏幕上的列表由MusicStation每晚或每周更新。

见图115。

10.4.3.专辑主页

见图116。用户可以察看专辑的详细资料，包括专辑上的乐曲数、专辑的星级和乐曲列表。用户可以播放专辑中的单个乐曲或所有乐曲。利用专辑主页底部的所有乐曲(ALL TRACKS)选项，用户可以选择播放专辑中的所有乐曲。

10.4.4.估级专辑

用户可以估级用户界面内的任何专辑。见8.3部分。

10.5.乐曲

见图117。专辑屏幕给出用户通向所有可以从MusicStation目录中获取的乐曲的入口。用户可以察看他们过去曾经下载过的乐曲的选择列表。用户还可以使用获取新乐曲(Get new tracks)选项察看和收听一般的乐曲或该用户个人感兴趣的乐曲。

10.5.1.我的最佳乐曲

在专辑(Albums)屏幕的我的最佳专辑(My Top Albums)部分，用户可以察看他们已经下载的乐曲的选择列表。该列表由用户频繁收听的乐曲组成。该列表中的所有乐曲可以立即收听。用户收听任何这些乐曲不需要网络覆盖。

10.5.2.获取新乐曲

见图118。获取新乐曲(Get new tracks)选项提供通向已经由MusicStation利用用户的收听习惯和反馈自动或编辑生成的乐曲列表的入口。这些基于两个主要的分类：受欢迎的乐曲，例如最佳乐曲，以及建议的乐曲，例如你可能会喜欢、刚发行的。

这些屏幕上的列表由MusicStation每晚或每周更新。

10.5.3.估级乐曲

用户可以估级任何乐曲。见8.3部分。

10.5.4.向播放列表添加乐曲

用户可以向播放列表添加任何乐曲。在此过程中，用户可以选择已有的播放列表或创建一个新的。见错误！未找到引用源。部分创建播放列表。

10.6.图表

10.6.1.图表列表

见图119。图表(Charts)屏幕提供从该服务的用户的收听和估级习惯生成的图表的清单。图表生效的选择包括每日、每周和每月。

10.6.2.图表详细资料

见图120。用户可以察看特定图表的详细资料，包括其名称、图表的总播放时间、用于图表的全部连续的乐曲∥艺术家列表，以及播放图表中的任何乐曲。

10.7.搜索

见图121。

10.7.1.艺术家搜索

见图122。用户可以通过将检索词输入搜索(Search for)菜单上的搜索(Search)文本框并选择艺术家(Artists)单选按钮来搜索MusicStation目录内的任何艺术家。用户之后就可以察看搜索得到的任何艺术家的外形。

10.7.2.乐曲搜索

见图123。用户可以通过将检索词输入搜索(Search for)菜单上的搜索(Search)文本框并选择乐曲(Tracks)单选按钮来搜索MusicStation目录内的任何乐曲。用户之后就可以播放搜索得到的任何乐曲。

10.7.3.专辑搜索

见图124。用户可以通过将检索词输入搜索(Search for)菜单上的搜索(Search)文本框并选择专辑(Albums)单选按钮来搜索MusicStation目录内的任何专辑。用户之后就可以察看播放搜索得到的任何专辑的外形。

10.8.播放最佳乐曲

见图125。主页菜单上的播放最佳乐曲(Play Top Track)选项从已经在手机上的乐曲列表中将随机乐曲添加到列队(Lineup)的末尾。如果列队(Lineup)是空的，则该乐曲将立即开始播放。该选项不需要网络覆盖，由于乐曲已经下载了。

10.9.选项

见图126。选项(Options)屏幕向用户提供通向一般信息和控制其MusicStation应用程序的选项的入口。

10.9.1.会员资格状态

见图127。该选项显示用户的会员资格状态。其将显示更新的详细资料，例如下一次更新的日期和时间、更新费用和更新频率。用户还可以利用取消会员资格(Cancel Membership)选项取消其会员资格。

下表说明会员资格处理的不同阶段。

10.9.2.关于

见图128。该屏幕显示有关MusicStation版本的信息。其还显示用户当前已经下载到他们手机上的乐曲的总数。

10.9.3.漫游选项

见图129。用户可以配置用于MusicStation的漫游特性。在电话漫游时，用户下载乐曲或MusicStation更新菜单项和图像时，用户将承受附加费用。

如果菜单和图片更新(Menu & picture updates)的漫游特性设置成询问(Ask)，将会向他们显示警告讯息，要求他们在对给定的通话漫游时同意/拒绝下载、更新和附加费用。见图130。

当用户漫游、并且对乐曲的漫游特性设置成询问(Ask)时，用户在试图下载乐曲时将会被显示警告讯息，要求他们在漫游时同意/拒绝下载、更新和附加费用。该行为，同意/拒绝将为当前通话配置设置。见图131。

10.9.4.语言选择

在具有确定的多语言的服务上，用户可以改变MusicStation语言。改变语言的时候，将会向用户提示重启MusicStation。确认该动作关闭MusicStation。见图132。

10.9.5.条件

该屏幕显示该MusicStation服务的普通和服务特定条件的WAP链接。见图133。

10.9.6.最大存储卡使用

用户可以选择MusicStation将为存储音乐和数据使用的存储卡的最大百分比。用户可以设定一个较低的值，用以为电话的其他用途(例如照片)留下更大的空间。

11.Buzz

见图134。用户可以选择创建Buzz外形。这允许他们能够参与MusicStation社区特征的全部设置。不过用户没用Buzz外形，他们就不能与其他成员通信。

用户可以从Buzz屏幕察看他们的外形、读取新闻文章以及访问他们收件箱(Inbox)中的讯息。

11.1.加入Buzz

见图135。当客户试图使用需要Buzz特征的社区特征时，他们就被重新导向加入Buzz(Join the Buzz)屏幕并被提示一个他们想要用来注册的会员名。他们可以输入一个名字并选择图像，这将形成他们的外形。输入的名字必须是唯一的。

如果会员名不可用，则会建议一个可选的，他们可以采用或修改。

用户可以在任何时间从我的外形(My Profile)屏幕编辑他们的外形。

他们还可以可选地选择图像并提供简短的醒目广告语。只要其他用户察看该用户的外形，这些项就会显示。

11.2 Buzz会员

11.2.1.我的外形

见图136。我的外形屏幕给用户提供通向MusicStation社区所有方面以及他们自己的个性化内容的入口。在他们创建外形之前，用户能够访问Buzz标签中的新闻项，并察看Cool会员和Buzz播放列表，但不能天界朋友或发送建议。

一旦他们已经注册，本屏幕将显示

●会员名称

●图像

●星级—表示其他用户如何估级他们

●收听—其他用户收听该会员的一个共享播放列表中的次数

●朋友数

●醒目广告语

从我的外形屏幕他们可以察看Cool会员、Buzz播放列表和他们的Buzz朋友列表。

11.2.2.编辑我的外形

注册为会员后的任何时间，用户都可以使用更多(More)菜单中的编辑我的外形(Edit My Profile)选项修改其会员外形的详细资料。见图137。

这允许用户修改他们的醒目广告语并改变他们的图像。这还允许他们指定他们是否想要他们的外形能被其他用户看见，以及是否想要他们的最佳乐曲(Top Tracks)列在他们的外形屏幕上。

11.2.3.Cool会员

见图138。我的外形屏幕上的Cool会员(Cool Members)选项向用户提供通向各种会员列表的入口。

用户可以点击这些列表中的任何会员来察看该会员的外形(11.2.4部分)。

11.2.4.Buzz播放列表

见图139。我的外形屏幕上的Buzz播放列表(Buzz Playlists)选项向用户提供通向各种播放列表的入口，包括编辑播放列表(EditorialPlaylists)、自动生成播放列表(Automatically Generated Playlists)和来自其他用户的共享播放列表(Shared Playlist)。用户可以察看、播放和估级任何这些播放列表。

见图140。这些屏幕上的列表由MusicStation每晚或每周更新。

11.2.5.我的朋友

见图141。我的外形屏幕上的我的朋友(My Friends)选项向用户提供通向他们添加为朋友和任何等待处理的交友请求的用户的列表的入口。见11.3部分获取有关朋友的更详细的信息。

11.2.6.察看另一会员的外形

见图142。该屏幕显示另一会员的详细资料。只有会员启用了编辑我的外形(Edit My Profile)屏幕上使其外形可见的选项，该会员的外形才能被其他会员看到。

会员外形屏幕显示会员的：

●会员名称

●图像

●星级

●收听(其他用户收听该会员的一个共享播放列表的次数)

●朋友数

●醒目广告语

●他们的共享播放列表的清单

●我的最佳乐曲(该用户的5首最佳乐曲)

用户从该屏幕可以：

●察看该会员的共享播放列表

●察看该会员的5首最佳乐曲并播放它们(该选项只有在其他会员在使用编辑我的外形(Edit my profile)选项配置他们的会员外形时启用了显示我的最佳乐曲(Show my top tracks)选项时才显示。见11.2.1部分)

●请求将该用户添加为朋友

●估级该会员

11.3朋友

Buzz会员可以向其他会员推荐项，为此他们还可以附加讯息。然而，他们只能对他们已经添加到他们的朋友列表中的会员这样做。用户可以通过向其他Buzz会员发送交友请求或确认其他会员发出的请求来添加朋友。

朋友列表可以从他们的我的外形屏幕察看(见11.3.2部分)。

所有建议可以在Buzz标签上的收件箱(Inbox)中察看。(见11.4部分)

11.3.1.请求将会员添加为朋友

见图143。无论会员列在用户界面中的何处，用户都可以选择更多(More)菜单中的添加为朋友(Add as Friend)选项以向该会员发送请求成为他们的朋友。用户可以输入讯息，该讯息与交友请求一起发送。为了发送讯息，用户选择更多(More)菜单中的发送(Send)选项。交友请求将发送到其他会员，该会员就有接受或拒绝请求的选项。

11.3.2.察看我的朋友列表

见图144。用户在任何时间都可以通过进入我的外形屏幕并选择我的朋友(My friends)选项察看他们的朋友列表。

11.3.3.察看我的待处理交友请求

见图145。用户可以在我的外形屏幕中可用的我的朋友(My friends)屏幕上的待处理交友请求(Pending friend requests)标题下察看他们已经发送但未收到回应的交友请求(见11.3.2部分)。

11.3.4.通过名称请求添加朋友

见图146。如果用户知道他们想要添加为朋友的会员的名称，他们可以通过使用他们的我的外形屏幕中的我的朋友(My friends)菜单上的通过名称添加朋友(Add friend by name)选项输入该名称来向该会员发送交友请求(见11.3.2.部分)。

11.3.5.通过电话号码请求添加朋友

见图147。如果用户知道他们想要添加为朋友的会员的电话号码，他们可以通过使用他们的我的外形屏幕中的我的朋友(My friends)菜单上的通过电话号码添加朋友(Add friend by phone no)选项输入该名称来向该会员发送交友请求(见11.3.2.部分)。

11.3.6.向朋友发送播放列表建议

无论播放列表列在MusicStation中的何处，用户都可以使用更多(More)菜单中的发送给朋友(Send to Friend)选项向一个或多个朋友发送向他们推荐该播放列表的讯息。推荐讯息到达该朋友的收件箱(Inbox)(11.4.3部分)。

11.3.7.向朋友发送艺术家建议

无论艺术家列在MusicStation中的何处，用户都可以使用更多(More)菜单中的发送给朋友(Send to Friend)选项向一个或多个朋友发送向他们推荐该艺术家的讯息。推荐讯息到达该朋友的收件箱(Inbox)(11.4.4部分)。

11.3.8.向朋友发送专辑建议

无论专辑列在MusicStation中的何处，用户都可以使用更多(More)菜单中的发送给朋友(Send to Friend)选项向一个或多个朋友发送向他们推荐该专辑的讯息。推荐讯息到达该朋友的收件箱(Inbox)(11.4.5部分)。

11.3.9.向朋友发送乐曲建议

无论乐曲列在MusicStation中的何处，用户都可以使用更多(More)菜单中的发送给朋友(Send to Friend)选项向一个或多个朋友发送向他们推荐该乐曲的讯息。推荐讯息到达该朋友的收件箱(Inbox)(11.4.6部分)。见图148。

11.4收件箱

收件箱显示从用户的朋友发来的讯息和建议，该朋友也是该MusicStation服务的用户。见11.3部分对MusicStation的朋友功能的简介。

讯息通过智能背景下载器下载到背景中，并显示在收件箱上，不需要用户的任何特定互动。

11.4.1.入站的交友请求讯息

见图149。当另一会员请求将该用户添加为朋友时，则交友请求将到达该用户的收件箱(Inbox)中。该用户可以用四种方式中一种对该请求做出回应。

该用户回应时，他们的回应将发到其他会员的收件箱中。这些回应在11.4.2部分说明。

11.4.2.对交友请求的回应

见图150。当该用户向另一会员发送交友请求时，该会员有接受或拒绝请求的选项。他们的回应返回到该用户并显示在收件箱(Inbox)中。对交友请求做出的三种可能的回应列于下表。

11.4.3.入站的来自朋友的播放列表建议

见图151。当朋友向该用户发送播放列表建议时(11.3.6部分)，该建议讯息将显示在该用户的收件箱(Inbox)中。用户可以打开讯息并点击讯息中的超链接来察看播放列表。

11.4.4.入站的来自朋友的艺术家建议

见图152。当朋友向该用户发送艺术家建议时(11.3.7部分)，该讯息将显示在该用户的收件箱(Inbox)中。用户可以打开讯息并点击讯息中的超链接来直接进入艺术家外形屏幕。

11.4.5.入站的来自朋友的专辑建议

见图153。当朋友向该用户发送专辑建议时(11.3.8部分)，该讯息将显示在该用户的收件箱(Inbox)中。用户可以打开讯息并点击讯息中的超链接来直接进入专辑屏幕。他们还可以点击艺术家名字来直接进入艺术家外形屏幕。

11.4.6.入站的来自朋友的乐曲建议

见图154。当朋友向该用户发送乐曲建议时(11.3.9部分)，该建议讯息将显示在该用户的收件箱(Inbox)中。用户可以打开讯息并点击讯息中的超链接来将该乐曲添加到他们的列队(Lineup)中。

11.5.新闻

11.5.1.编辑的艺术家的列表

新闻部分显示不断更新的新闻文章列表。典型地，将显示六篇文章，该六篇文章又分成两篇国际一般关注、两篇本地一般关注和两篇基于该用户的收听和估级习惯的故事。这种分法可以为特定服务的要求进行配置。

文章列表由智能背景下载器(Intelligent Background Downloader)在MusicStation正常使用过程中更新。文章在背景中被添加到该列表中，并且在用户下次导航至Buzz标签时可以立即被用户看到。

11.5.2.察看文章

见图155。为了察看文章，用户从列表中选择文章并点击操纵杆按钮或选择更多(More)菜单中的打开(Open)选项。文章主体文本显示在标题行和相关图像的下面。

11.5.3.文章中的超链接

见图156。故事可以包含指向MusicStation内其他屏幕的超链接。例如，新专辑发行的通告可以包括指向相关艺术家和专辑屏幕的链接。超链接在文章屏幕中以蓝色显示。用户可以通过选择超链接并点击操纵杆按钮直接导航至专辑或艺术家。在用户使用操纵杆上的上/下在文章中上下滚动时，活动的超链接在连续的超链接之间移动。

12.列队

见图157。列队(Lineup)是MusicStation客户机的中心概念。它是用户已经排列的用于收听的乐曲的当前列表。播放列表上的歌曲将显示在队列中。列队的内容在任何时间都可以在列队(Lineup)屏幕上察看。

当前乐曲是当前正在播放的列队(Lineup)中的乐曲。当前乐曲用左边的小蓝点突出显示。

见图158。当没有乐曲被添加到列队中时，显示播放最佳乐曲(Play toptrack)选项。该选项随机向列队中添加和播放最佳乐曲。最佳乐曲已经下载并将立即播放。

12.1.乐曲下载状态

见图159。尚未下载的乐曲将在背景中下载。当前正在下载的乐曲或者等待下载的乐曲以灰色字体显示。下载乐曲的进度以0-100％的百分数显示。

乐曲从列队中依次播放。如果到了尚未完成下载的乐曲，则回放将跳过该乐曲并转向下一个已经下载的乐曲。一旦该乐曲下载完成，则其可用于播放。

MusicStation智能化管理背景中乐曲的下载，以优化用户的体验，并确保音乐回放连续、用户能连续听到音乐流动。

乐曲每次下载一首，尽管取决于乐曲被如何添加到列队中以及用户是否被退出应用程序中断了下载，可以有多个显示部分下载状态的乐曲。

的下载乐曲的时候，用户可以收听已经下载的音乐，并且在剩下的MusicStation用户界面中四处导航。

部分下载的乐曲在MusicStation退出时保存，随后可以从离开的地方继续下载。

12.2.保存为播放列表

见图160。用户可以将当前列队保存到播放列表中。为了将当前列队保存为播放列表，用户从更多(More)菜单中选择保存为播放列表(Saveas playlist)。他们可以选择将当前列队保存为新的播放列表或将乐曲添加到已有的播放列表中。该保存的播放列表保存到手机上并在中心。

12.3.从列队中移除

见图161。用户可以从列队(Lineup)中移除乐曲。为了从列队(Lineup)中移除乐曲，用户选择乐曲然后从更多(More)菜单中选择移除(Remove)。如果用户移除了当前乐曲，则将播放当前播放列表中的下一首可用乐曲。

12.4.清除列队

见图162。用户可以清除当前列队(Lineup)，从中移除所有的乐曲。为了清除列队(Lineup)，用户从更多(More)菜单中选择清除(Clear)。音乐回放将停止。

12.5.在当前列队中跳到乐曲并播放

用户可以从当前列队(Lineup)中选择另一首乐曲进行播放。为此用户使用操纵杆导航到乐曲。用户可以通过按下操纵杆按钮或从更多(More)菜单中选择播放(Play)来开始乐曲。MusicStation将开始播放选中的乐曲。只有已下载的乐曲可以播放。

12.6.将音乐添加到列队

用户通过MusicStation的音乐目录导航，并且可以选择乐曲、专辑艺术家或播放列表以添加到列队(Lineup)中。

任何乐曲都可以通过用操纵杆选择乐曲而被添加到列队中。任何播放列表、专辑或乐曲都可以通过从更多(More)菜单中选择添加到列队(Addto Lineup)而被添加。

如果列队(Lineup)是空的，则该项将开始播放。如果列队已经包含了乐曲，则添加的项将排列到列队(Lineup)的末尾。用户可以通过转到列队(Lineup)标签察看他们已经添加的乐曲。

尚未下载的乐曲在它们被下载之前就添加到了列队(Lineup)中。MusicStation将智能化地在背景中管理项目的下载，允许用户享受连续的音乐流动。

其它用于将项目添加到列队(Lineup)中的选项在更多(More)菜单上提供。这些菜单例如是接下来播放(Play next)、尽快播放(Play ASAP)或现在播放(Play now)，将在以下详细说明。

如果用户向列队中添加必须要下载的乐曲，并且当前列队中没有其他乐曲，则用一个选项提示用户添加最佳乐曲进行立即播放。见图163。

12.6.1.添加到列队

用户在浏览MusicStation目录时，他们可以从更多(More)菜单中选择添加到列队(Add to Lineup)来将乐曲、播放列表、选定艺术家或专辑的乐曲添加到列队(Lineup)中。

12.6.2.接下来播放

用户在浏览MusicStation目录时，他们可以从更多(More)菜单中选择接下来播放(Play next)来将乐曲、播放列表、选定艺术家或专辑的乐曲插入到列队(Lineup)中当前正在播放的乐曲之后。

12.6.3.现在播放

用户在浏览MusicStation目录时，他们可以从更多(More)菜单中选择现在播放(Play now)来将已经下载的乐曲插入到列队(Lineup)中。当前正在播放的乐曲将被中断，并且将开始播放选定的乐曲，选定的乐曲将取代当前乐曲。

12.6.4.尽快播放(Play ASAP)

Play ASAP代表尽快播放(Play As Soon As Possible)。用户在浏览MusicStation目录时，他们可以从更多(More)菜单中选择尽快播放(PlayASAP)来将尚未下载的乐曲、播放列表、选定艺术家的乐曲或专辑插入到列队(Lineup)中。只要乐曲、播放列表、选定艺术家的乐曲或专辑一可以使用，就用其取代当前播放的乐曲。

用户在浏览MusicStation目录时，如果乐曲、播放列表、选定艺术家或专辑的乐曲尚未下载，他们就可以从更多(More)菜单中选择尽快播放(Play ASAP)。

13.播放

见图164。

13.1.1.播放屏幕

播放(Playing)标签显示当前正在播放的乐曲的详细资料。

13.1.2.播放行为

用户可以在播放(Playing)标签上执行以下动作。

附录2：上下文有关菜单

以下附录详细说明在MusicStation中查看菜单和对象时更多菜单上的可用选项。

Claims (50)

1.一种能使数字音乐内容下载到便携式无线计算装置并在其上使用的方法，该方法包含以下步骤：

(a)在无线装置上运行软件应用程序，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

2.根据权利要求1所述的方法，其特征在于，数字权限管理系统允许购买乐曲，使得即使订购服务终止乐曲依然能够播放。

3.根据上述任一权利要求所述的方法，其特征在于，用于订购服务的记账基础结构是控制无线网络的网络运营商提供的记账基础结构的一部分。

4.根据上述任一权利要求所述的方法，其特征在于，与无线装置关联的参数随无线装置的制造商和型号而变化。

5.根据上述任一权利要求所述的方法，其特征在于，参数确定特定版本的Java。

6.根据上述任一权利要求所述的方法，其特征在于，参数确定Java平台的哪个特定部分已经实施。

7.根据上述任一权利要求所述的方法，其特征在于，参数确定操作系统和固件的发布。

8.根据上述任一权利要求所述的方法，其特征在于，参数确定特定的提供装置的移动网络运营商。

9.根据上述任一权利要求所述的方法，其特征在于，参数确定装置的物理特征，包括屏幕大小、像素数、颜色深度、键盘控制、软键特征。

10.根据上述任一权利要求所述的方法，其特征在于，参数确定装置的计算性能。

11.根据上述任一权利要求所述的方法，其特征在于，参数确定一组可以通过Java显示的媒体文件和格式，包括装置上的音频、图片、视频和动画。

12.根据上述任一权利要求所述的方法，其特征在于，参数确定装置的存储限制。

13.根据上述任一权利要求所述的方法，其特征在于，参数确定一组装置的操作系统可以处理的媒体文件和格式。

14.根据上述任一权利要求所述的方法，其特征在于，参数确定装置如何处理网络连接。

15.根据上述任一权利要求所述的方法，其特征在于，参数确定装置的网络性能和处理，包括CSD、GPRS、2G、2.5G、3G、WAP、SMS、蓝牙、红外、Wi-Fi、WiMAX中的一个或多个。

16.根据上述任一权利要求所述的方法，其特征在于，便携式无线装置为移动电话。

17.根据权利要求16所述的方法，其特征在于，移动电话为2.5G装置。

18.根据权利要求16所述的方法，其特征在于，移动电话为3G装置。

19.根据上述任一权利要求所述的方法，其特征在于，应用程序呈现图形用户界面，在其中显示多个用户可选标签，每个标签都与应用程序的核心功能关联。

20.根据权利要求19所述的方法，其特征在于，每个标签在应用程序运行的任何时间都可以看到。

21.根据权利要求19或20所述的方法，其特征在于，一个标签与提供通向所有可用内容和搜索功能的主页功能相关联。

22.根据权利要求19-21所述的方法，其特征在于，如果选择，一个标签给出当前播放的乐曲的详细资料。

23.根据权利要求19-22所述的方法，其特征在于，如果选择，一个标签提供社区和新闻特征的入口。

24.根据权利要求19-23所述的方法，其特征在于，如果选择，一个标签显示用于收听和/或下载的乐曲的当前队列。

25.根据上述任一权利要求所述的方法，其特征在于，应用程序表现为图形用户界面，在其中多个屏幕显示上下文有关的“更多”菜单项，如果选择，即提供更多与当前选项和/或当前显示屏幕有关的功能的入口。

26.根据上述任一权利要求所述的方法，其特征在于，应用程序利用多任务上下文有关操纵杆进行控制。

27.根据权利要求26所述的方法，其特征在于，操纵杆的特定功能由其上的屏幕上的图标表示。

28.根据权利要求27所述的方法，其特征在于，操纵杆的操作由键区上的数字键复制。

29.根据权利要求27所述的方法，其特征在于，数字键5为上；0为下；7为左；9为右。

30.根据上述任一权利要求所述的方法，其特征在于，应用程序提供上下文适当获取功能，其中，相当于“获得新艺术家”的功能在菜单中与“艺术家”在同一水平上。

31.根据权利要求30所述的方法，其特征在于，相当于“获得新乐曲”的功能在菜单中与艺术家乐曲列表在同一水平上。

32.根据上述任一权利要求所述的方法，其特征在于，应用程序能使一个装置作为主回放装置，以使其他无线连接的便携式无线装置同时回放相同的乐曲。

33.根据权利要求32所述的方法，其特征在于，无线连接是短距离的无线连接，例如蓝牙。

34.根据上述任一权利要求所述的方法，其特征在于，应用程序提供专用的“播放”数字键，其总是触发返回到显示当前播放乐曲的播放屏幕。

35.根据上述任一权利要求所述的方法，其特征在于，应用程序提供可变的超时设定，不同的屏幕具有不同的超时设定。

36.根据权利要求35所述的方法，其特征在于，搜索屏幕从不跳回。

37.根据上述任一权利要求所述的方法，其特征在于，应用程序显示根据终端用户回放习惯过滤的目标新闻。

38.根据上述任一权利要求所述的方法，其特征在于，应用程序跟踪并向远程服务器反馈详细的终端用户数据。

39.根据权利要求38所述的方法，其特征在于，数据包括乐曲已经被收听了多久。

40.根据权利要求38所述的方法，其特征在于，数据包括什么乐曲被跳过、什么时候跳过的。

41.根据权利要求38-40所述的方法，其特征在于，数据本地高速缓存到装置并随后作为背负式传输通过无论如何发生的通信发回服务器。

42.根据权利要求38-41所述的方法，其特征在于，装置优先将数据发回，不等待期望无论如何发生的通信，除非用户超过设定时间未下载。

43.根据权利要求38-42所述的方法，其特征在于，数据用于丰富音乐建议引擎，该音乐建议引擎提供用于显示在装置上的乐曲建议。

44.根据上述任一权利要求所述的方法，其特征在于，应用程序显示共享播放列表。

45.根据上述任一权利要求所述的方法，其特征在于，应用程序显示用户生成的播放列表图表。

46.根据上述任一权利要求所述的方法，其特征在于，应用程序的所有功能在音乐回放过程中都有效。

47.根据权利要求46所述的方法，其特征在于，回放过程中有效的功能包括新闻获取，以及乐曲搜索、浏览和获取。

48.一种便携式无线计算装置，其能够使数字音乐内容被下载和使用，该装置包括：

(a)在无线装置上运行的软件应用程序，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；其中：

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；以及

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

49.一种软件应用程序，其能使数字音乐内容下载到便携式无线计算装置并在其上使用；

(a)应用程序在无线装置上运行，该应用程序无需终端用户输入而自动适应与无线装置相关联的参数；其中：

(b)该应用程序使终端用户能利用无线网络浏览并搜索远程服务器上的音乐内容；利用无线网络从该远程服务器下载音乐内容并播放和管理该下载的音乐内容；以及

(c)该应用程序包括数字权限管理系统，只要订购服务没有终止，其就能使不同乐曲不受限制合法下载到装置中并且能使这些存储在装置上的乐曲中的任一首都能播放。

50.利用权利要求49所述的软件应用程序下载的乐曲。

Images