用于音乐管理的系统和方法

专利名称：用于音乐管理的系统和方法
技术领域：
本发明总体上涉及信息处理领域，更确切地说，涉及用于音乐管理的系统和方法。
背景技术：
随着信息技术的进步，已经根据用户的需求出现了许多新兴技术。多媒体服务管 理是在多媒体领域中的新兴技术之一。最近，用于回放音乐的音乐管理需求已经得到增长。 主要的重点在于音乐分发服务。这种服务使得用户能够在互联网上购买音乐数据时，在线 收听音乐。此外，可以基于不同的情绪、歌手、作曲家、语言等来将音乐分类。而且，用户可 能想在服务器上的公用位置处存储他/她喜爱的歌曲列表。有时用户可能想对某些歌曲进 行评级。这些评级可以用于在用户下一次请求音乐时，对待播放的歌曲进行选择。音乐管 理的一方面是具有完整、连续的音乐服务。例如，这些服务包括，歌曲评级、列出要播放的歌 曲、对用户喜爱歌曲的列表进行存储等。将音乐数据存储在用于分发的音乐分发服务器上。 用户可以使用客户端设备下载音乐数据。此外，在客户端设备处的用户所期望的各种服务 可以由音乐分发服务器提供。然而，当在音乐数据中的条目数目增加时，用户需要从大量音 乐数据的条目中搜索期望的音乐数据。从大量的音乐数据条目中搜索音乐数据的处理是耗 时并且复杂的。为了减少搜索音乐数据的时间/复杂度，传统的音乐管理方法使用诸如艺术家名 称、音乐作品标题、流派和年代等的分类来搜索期望的音乐数据。在音乐作品的标题或艺术 家的名称未知的情形下，该方法使用音乐的歌词或者音乐发行的年份。另一种传统音乐管 理系统使用基于对收听音乐时所感受到的图像和印象的敏感性信息的搜索。这些印象可以 是，例如，当收听者收听该音乐时对收听者情绪进行定义的“舒适”、“振奋”、“愉悦”等。然而，上述传统的音乐管理方法可能不总是允许对适合于用户的当前偏好的音乐 数据进行搜索。而且，从利用实时流协议——实时协议(RTSP-RTP)的预定义音乐信道对音 轨进行传送，并且利用HTTP协议来分离地获取音乐的元数据。这导致在客户端设备和音 乐分发服务器之间的大量消息交换。此外，在流传送期间遇到损坏的音乐数据的情形下， RTSP-RTP和HTTP消息交换的使用会导致同步问题。


根据本发明，在其中，在所有的单独的视图里相同参考符号表示相同或功能类似元件；并且与下文具体描述一起被包含在说明书中并形成说明书的部分的所附附图被用于 进一步阐释各种实施例，并且解释各种原则和优势。图1示出了在其中可以实践本发明的各种实施例的示例性环境；图2示出了根据本发明的示例性网络设备的框图；图3示出了根据本发明实施例的呼叫流程图；以及图4是示出了根据本发明实施例的用于音乐管理的方法的流程图。本领域的技术人员应当理解的是，附图中元件是出于简明和清楚目的而示出的，并且不需要按比例来进行绘制。例如，在附图中的某些元件的尺寸相对于其他元件可能被 夸大，以有助于改善对本发明的实施例的理解。
具体实施例方式在具体描述根据本发明各种实施例的用于音乐管理的具体系统之前，应注意的 是，本发明主要与音乐管理相关的方法步骤的组合有关。因此，在附图中适当之处通过传统 符号来表示系统组件和方法步骤，其仅示出了与本发明的理解相关的那些具体细节，以避 免因对于利用此处描述的那些本领域的技术人员而言显而易见的细节模糊了本发明。在本文献中，术语“包括(comprises) ”、“包括(comprising)，，或其任何其他变体 旨在涵盖非排他性包含，从而包括元件列表的处理、方法、物件或装置不仅包含那些元件， 而是可以包含未明确列出或在这种处理、方法、物件或装置中所固有的其他元件。处在“包 括(comprises…a) ”之前的元件在没有更多约束的情况下，不排除在包括该元件的处理、方 法、物件或装置中存在额外的相同元件。本文献中所使用的术语“另一个(another)”被定 义为至少第二个或更多。此处所使用的术语“包含(includes) ”和/或“具有(having)”被 定义为包括。在此处的描述中，给出了多个特定的示例，以提供对本发明各种实施例的透彻理 解。包含的这些示例仅是阐释性目的，并且其目的并非是穷尽所有或以任何方式来限制本 发明。应注意的是，在本发明的精神和范围内，各种等效修改是可能的。然而，本领域的技 术人员应当认识到，在使用或不使用如在本描述中提及装置、系统、构件、方法、组件的条件 下，都可以实践本发明的实施例。对于一个实施例而言，提供了一种通过使用实时流协议(RTSP)，在通信网络中提 供多媒体服务的方法。该通信网络包含客户端设备和网络设备。在网络设备处的所述方法 包含从客户端设备接收对于服务的请求。此外，在网络设备处的所述方法包含基于该请求， 将属性集合和与所述属性集合的每个属性相对应的子属性传送至客户端设备。每个属性和 每个子属性与一个或多个数据文件相关。此外，在网络设备处的所述方法包括对与一个 或多个数据文件相关的元数据集合进行基本上持续地传送，直到来自客户端设备的干预为 止。基于客户端设备对传送的子属性和属性集合的响应，来选择一个或多个数据文件的每 个数据文件。就另一实施例而言，提供了一种网络设备。该网络设备包含接收模块，该接收模块 用于在通信网络中从客户端设备接收多媒体服务的请求。而且，该网络设备包含传送模块。 该传送模块被构造成基于请求，将属性集合和与所述属性集合的每个属性相对应的子属性 传送至客户端设备。每个属性和每个子属性与一个或多个数据文件相关联。此外，该传送 模块被构造成对与一个或多个数据文件相关的元数据进行基本持续地传送，直到来自客户 端设备的干预为止。基于客户端设备对传送的属性集合的响应，来选择该一个或多个数据 文件的每个数据文件。术语“基本持续地”指的是相对于元数据被传送的时间而进行的元数据的持续传 送。在元数据中的数据条目可以具有在其他数据值之间的一个或多个零数据值。在下文中， 相对于元数据传送有关的上述定义，采用术语“基本持续地”的用法。本发明提供了对于在用于多媒体服务分发的传统方法中所遇到的同步问题的解决方案。本发明主动传送用于一个或多个数据文件的元数据。在传统方法中，一个或多个 数据文件的每个数据文件的元数据只能由客户端设备来请求。图1示出了其中可以实践本发明的各个实施例的示例性环境100。环境100可以包含网络设备102和至少一个客户端设备104。在下文，为简明起见，将该至少一个客户端 设备104称为客户端设备104。网络设备102向客户端设备104提供多媒体服务。在此，将 网络设备102和客户端设备104表示为框图。网络设备102可以是能够用于服务器用途的 任何电子设备。客户端设备104可以是能够与被表示为网络设备102的服务器进行通信的 任何电子设备。网络设备102的示例包括，但不限于，流服务器、流管理服务器、计算机和集 成服务器。此外，网络设备102可以是两个或更多个服务器的组合。客户端设备104的示 例包括，但不限于，计算机、移动电话、音乐播放器、无线电接收机等。例如，本(Ben)可以是客户端设备104的用户，他希望收听“枪与玫瑰”乐队的60 年代的歌曲音轨。对于该音乐服务而言，Ben可以使用客户端设备104将请求发送至网络 设备102。网络设备102可以将服务列表发送至客户端设备104。Ben可以选择他希望使 用的服务，并且基于他的选择，网络设备102可以将子属性和属性集合发送给他。这些子属 性对应于属性集合的每个属性。然后，他可以选择属性“音乐发行年份”和“摇滚”。他的选 择的子属性可以是“60年代”和“枪与玫瑰”。Ben还可以选择他想收听的歌曲音轨的数目。 网络设备102可以将选择的歌曲音轨传送至客户端设备104。因此，Ben可以通过利用多媒 体音乐服务，收听在他的客户端设备上选择的歌曲。此外，客户端设备104和网络设备102 可以通过利用在本领域中已知的标准通信协议进行通信。就一个实施例而言，标准通信协 议可以是实时流协议(RTSP)。图2示出了根据本发明实施例的网络设备102的框图。网络设备102是将多媒体 服务提供给客户端设备104的服务器。网络设备102可以是专用服务器、计算机或具有两 个或多个服务器的组合的集成服务器、能够作为服务器的无线设备、能够作为服务器的有 线设备等。网络设备102包含接收模块202和传送模块204。接收模块202可以从客户端 设备接收对于多媒体服务的请求。就一个实施例而言，多媒体服务可以是音乐服务。例如， 用户可以通过使用客户端设备，向网络设备102请求音乐服务。用户可以请求在网络设备 102处可用的，具有诸如流派的特定属性的歌曲列表。为了描述本发明，请求客户端设备可 以是客户端设备104。就一个实施例而言，客户端设备104可以通过使用实时流协议(RTSP)与网络设 备102通信。典型地，RTSP通信方法可以被用于对在例如互联网的通信网络上的流媒体进 行控制。在RTSP通信方法中，RTSP命令可以由客户端设备104发送，以请求来自网络设备 102的用于多媒体数据文件的子属性和属性集合。在接收到RTSP请求之后，网络设备102 可以根据RTSP通信方法，将子属性和属性列表传送至客户端设备104。此外，基于由客户端 设备104进行的属性和子属性的选择，网络设备102选择一个或多个多媒体数据文件。此 夕卜，网络设备102可以基本持续地将对应于该一个或多个数据文件的元数据集合传送至客 户端设备104。根据RTSP方法，通过使用GET_PLAYLIST_ATTRIBUTE (获取播放列表属性)命令， 客户端设备104可以发送对于多媒体服务的请求。接收模块202接收对于多媒体服务的请 求。就一个实施例而言，接收模块202可以被构造成接收从客户端设备104至网络设备102的所有后续的通信。传送模块204可以被构造成响应于多媒体请求，将音乐数据传送至客 户端设备104。就一个实施例而言，传送模块204可以基于对多媒体服务的请求，将子属性 和属性集合传送至客户端设备104。子属性对应于属性集合的每个属性。例如，如果请求是 关于歌曲列表的，则传送模块将提供具有像流派、标题、艺术家名称、音乐发行年份等的属 性的歌曲列表。子属性可以对应于这些属性的每个。例如，用于音乐发行年份的子属性可 以是60年代、70年代等。此外，每个属性和子属性与一个或多个数据文件相关。每个数据 文件对应于一首歌曲。就一个实施例而言，客户端设备104被要求在建立会话时，仅将根据 RSTP方法的GET_PLAYLIST_ATTRIBUTE (获取播放列表属性)命令发送一次。而且，网络设 备102可以在会话开始时，仅将子属性和属性集合传送一次。会话可以被定义为客户端设 备104和网络设备102之间的互动，其包含多媒体服务的请求和后续的服务。此外，传送模块204可以被构造成对与一个或多个数据文件相关的元数据集合进 行基本持续地传送，直到存在来自客户端设备104的干预为止。元数据是被用于处理数据 文件的基本数据。例如，在数据文件为歌曲的情形下，歌曲的元数据可以包含对于处理数据 文件是必要的并且使得用户能够通过媒体播放器播放该歌曲的数据。就一个实施例而言， 传送模块204可以在相关子属性和属性集合传送之后对元数据进行传送。基于客户端设 备104对于传送的子属性和属性集合的响应，选择用于其的元数据被传送的一个或多个数 据文件。例如，当客户端设备104请求60年代的歌曲时，传送模块204可以传送在60年代 发行的一个或多个歌曲以及它们的元数据。此外，传送模块204可以基本持续地传送数据 文件和相关元数据，直到存在来自客户端设备104的用户的干预。当存在利用DESCRIBE_ PLAYLIST(描述播放列表)方法的来自客户端设备104的干预时，网络设备102发送对于 DESCRIBE_PLAYLIST (描述播放列表)的响应。就一个实施例而言，DESCRIBE_PLAYLIST (描 述播放列表)方法具有客户端设备104已经于预的特定数据文件的信息。例如，在音乐服 务中，DESCRIBE_PLAYLIST(描述播放列表)方法将提供与客户端设备104已经干预的歌曲 相关的信息。在传送信息之后，网络设备102恢复用于随后数据文件的元数据的传送。对 于DESCRIBE_PLAYLIST (描述播放列表)的响应提供了与媒体类型相关的信息、在编码该媒 体中所使用的比特率以及其他媒体特定信息。本发明建议在DESCRIBE_PLAYLIST(描述播 放列表)响应中还提供元数据信息。为了描述清楚起见，在下文中，已经将由网络设备102根据客户端设备104的请求 所提供的术语“多媒体服务”与术语“音乐服务”可互换地使用，其中，“音乐服务”是特定类 型的多媒体服务。图3示出了根据本发明实施例的网络设备102和客户端设备104之间的呼叫流 程图。在客户端设备104处的用户可以从网络设备102请求该用户所期望的多媒体服务。 通过将客户端设备104用于多媒体服务，用户可以发起与网络设备102的会话。为了发起 用于接收多媒体服务，例如，音乐服务的会话，客户端设备104将服务发起请求302发送至 网络设备102。就一个实施例而言，服务发起请求302可以是根据RTSP通信方法的GET_ PLAYLIST_ATTRIBUTE (获取播放列表属性)命令。该GET_PLAYLIST_ATTRIBUTE (获取播放 列表属性)命令可以被用于请求网络设备102以获取子属性和属性集合。就另一实施例而 言，服务发起请求302可以作为对网络设备102的指示，该指示表示客户端设备104支持 RTSP通信方法。
响应服务发起请求302，网络设备102将确认消息304传送至客户端设备104。就 一个实施例而言，确认消息304可以是服务确认消息，以确认来自客户端设备104的服务发 起请求302的接收。就另一实施例而言，确认消息304可以是向客户端设备104提供网络 设备102处可用的多媒体服务列表的消息。就另一实施例而言，确认消息304的传送可以 表示网络设备已经被准备，以提供服务发起请求302。就另一实施例而言，在接收了确认消息304之后，客户端设备将第一响应306发送 至网络设备102。就一个实施例而言，第一响应306可以作为对网络设备102的指示，该指 示表示客户端设备104已准备好从网络设备102接收数据。就另一实施例而言，第一响应 306可以是根据RTSP通信方法的GET_PLAYLIST_ATTRIBUTE (获取播放列表属性)命令。该 GET_PLAYLIST_ATTRIBUTE(获取播放列表属性)命令可以被用于请求网络设备102以获取 子属性和属性集合。就又一实施例而言，第一响应306可以被包含在服务发起请求302中。 在某些情形下，服务发起请求302和第一响应306可以包含与在服务期间由网络设备102 传送的歌曲音轨的数目相关的信息。就某些实施例而言，如果歌曲音轨的数目没有在服务 发起请求302或者第一响应306中指定，那么网络设备102选择默认数目的音轨用于传送。 此外，如果客户端设备104不选择任何属性，那么网络设备102选择预定义的属性集合的数 据文件。此外，网络设备102传送预定义的属性集合的元数据。此外，网络设备102传送属性-内容308至客户端设备104。就一个实施例而言， 基于来自客户端设备104的服务发起请求302和第一响应306中的一个，属性_内容集合 308可以提供子属性集合和与每个属性相对应的子属性。对于由客户端设备104所请求的 音乐服务，子属性和属性集合可以是具有像流派、标题、艺术家名称、音乐发行年份等属性 的歌曲列表。子属性可以对应于这些属性的每个。例如，用于音乐发行年份的子属性可以 是60年代、70年代等。此外，每个属性和子属性与一个或多个数据文件相关。每个数据文 件可以对应于一首歌曲。因此，通过使用属性-内容308，网络设备102可以对子属性和属 性集合进行传送。在接收到属性-内容308之后，客户端设备104发送第二响应310至网络设备102。 就一个实施例而言，第二响应310可以是确认属性-内容308的接收的确认消息。就另一 实施例而言，第二响应310可以是DESCRIBE_PLAYLIST (描述播放列表)方法。DESCRIBE_ PLAYLIST(描述播放列表)可以是由客户端设备104所选择的子属性和属性集合。基于客 户端设备104的这种选择，网络设备102可以发送数据-内容312。就又一实施例而言，基 于向客户端设备104传送的属性-内容308，第二响应310可以表示对歌曲和数据文件的特 定集合的选择。就又另一实施例而言，客户端设备104不需要将第二响应310发送至网络 设备102。此外，网络设备102可以传送数据-内容312至网络设备104。就一个实施例而言， 网络设备102基本上持续地对数据-内容312进行传送，直到存在来自客户端设备104的 干预为止。数据_内容312可以包含用于与在属性_内容308中传送的子属性和属性集合 相关的一个或多个数据文件的元数据集合。基于来自客户端设备104的服务发起请求302 和第一响应306，可以选择一个或多个数据文件。就一个实施例而言，通过使用数据-内容 312传送的用于一个或多个数据文件的元数据集合可以是会话描述协议(SDP)文件。就另 一个实施例而言，数据-内容312可以是根据RTSP通信方法的DESCRIBE_PLAYLIST(描述播放列表)方法。DESCRIBE_PLAYLIST(描述播放列表)方法可以提供与有客户端设备104 所期望的数据文件相关的信息。例如，DESCRIBE_PLAYLIST(描述播放列表)方法可以包含 与用于歌曲音轨集合的元数据和流统一资源定位器(URL)相关的信息。此外，客户端设备104可以发送服务请求314至网络设备102。服务请求314可以是例如流媒体请求。就一个实施例而言，服务请求314可以是在数据-内容312的传送 期间来自客户端设备104的干预。该干预可以发送指示至网络设备102，以发送与元数据 相关的数据文件的描述，在该指示传送期间，服务请求314被发送。例如，当接收用于歌曲 音轨“son of a gim(枪之子)”的元数据时，客户端设备104的用户可以通过使用服务请 求314来发送干预。在接收到该干预之后，网络设备102可以通过使用流媒体内容316来 发送被请求的歌曲音轨的描述。对另一实施例而言，服务请求314可以发送指示至网络设 备102以开始对音乐进行流传送。在该实施例中，网络设备102可以通过利用流媒体内容 316将音乐流传送至客户端设备104。例如，流媒体内容316可以开始向客户端设备104流 传送数据文件。通过利用流传送的数据文件和接收到的元数据，客户端设备104可以处理 该接收到的数据文件。此外，网络设备102保持基本持续地将元数据集合传送至客户端设 备 104。在某些情形下，从网络设备102传送至客户端设备104的任何数据文件可能有错 误或者可能被损坏。结果，客户端设备104可能无法处理损坏的数据文件。根据用于多媒 体服务分发的传统方法，这可能导致在客户端设备104和网络设备102之间的同步问题。 传统地，因为传统方法没有采用基本持续地将元数据传送至客户端设备104，所以客户端设 备必须将用于每个数据文件的元数据的独立请求发送至网络设备。在这种情形下，当数据 文件损坏时，用于后续的数据文件的元数据对于客户端设备104而言可能是不可用的。结 果，由于相应元数据的不可用，使得后续的数据文件可能不被处理。本发明主动地对用于该 一个或多个数据文件的每个数据文件的元数据进行基本持续地传送。在该情形下，当遇到 损坏的数据文件时，客户端设备104不需要独立地请求用于随后的数据文件的元数据。此 夕卜，在数据文件损坏的情况下，客户端设备104能够处理随后的数据文件，因为随后数据文 件的元数据被网络设备102主动地传送至客户端设备104。此外，元数据信息可以作为SDP 文件而被发送，其消除了客户端设备104为与每个数据文件相关的其他信息发送额外的请 求的需求。例如，在音乐服务的情形下，其他信息可以是与在客户端设备104处播放的歌曲 音轨相关的图片、专辑艺术等。图4是示出了根据本发明实施例的用于音乐管理的方法的流程图。为了描述该方 法，将参考图1、2和3，虽然显而易见的是该方法还可以应用在任何其他适当的系统中。在 步骤402，开始用于音乐管理的方法。在步骤404，网络设备102从客户端设备104接收用 于发起多媒体服务的请求。就一个实施例而言，多媒体服务可以是音乐服务。就另一实施 例而言，来自客户端设备104的请求可以是服务发起请求302。网络设备102和客户端设备 104之间的通信可以是通过使用RTSP通信方法的通信。就一个实施例而言，对于多媒体服 务的请求可以是根据RTSP通信方法的GET_PLAYLIST_ATTRIBUTE (获取播放列表属性)命 令。在步骤406，网络设备102可以将子属性和属性集合传送至客户端设备104。子属 性对应于该属性集合的每个属性。基于来自客户端设备104的请求，可以对属性集合进行传送。此外，每个属性和子属性与一个或多个数据文件相关。就一个实施例而言，该数据文 件可以是歌曲或音乐文件。此外，对于由客户端设备104所请求的音乐服务，子属性和属性 集合可以是具有像流派、标题、艺术家名称、音乐发行年份等的属性的歌曲列表。子属性可 以对应于这些属性的每个。例如，用于音乐发行年份的子属性可以是60年代、70年代等。 因此，在步骤406，可以由网络设备102传送用于歌曲列表的子属性和属性集合。在步骤408，网络设备102基本持续地对与一个或多个数据文件相关的元数据集 合进行传送，直到存在来自客户端设备104的干预。基于对来自客户端设备104的子属性 和属性集合的响应，可以选择一个或多个数据文件。例如，如果客户端设备104对于音乐服 务的响应是60年代的歌曲，那么，该一个或多个数据文件可以是在60年代中发行的那些歌 曲。就一个实施例而言，元数据可以作为SDP文件而被传送。元数据是用于处理数据文件 的基本数据。本发明的各个实施例提供了一种或多种优点。本发明可以由能够支持RTSP/RTP 通信方法的任何通信设备来实现。而且，因为客户端设备104不需要发送用于每个数据文 件的元数据的独立请求，所以来自网络设备102的对于客户端设备104的服务请求有更快 的响应。此外，由于元数据基本上持续地被从网络设备102传送至客户端设备104，在它们 之间交换的消息的数目被显著减少。而且，因为对于由技术演进导致的RTSP通信方法的各 种变化具有容易的适应性，所以本发明为通信设备提供了更大的灵活性。应理解的是，此处所描述的用于音乐管理的系统和方法可以包括一个或多个传统 处理器，以及控制该一个或多个处理器的唯一存储的程序指令，从而与某些非处理器电路 联合，实现此处所描述系统的功能的某些、绝大多数或全部。非处理器电路可以包含，但不 限于，信号驱动器、时钟电路、电源电路和用户输入设备。由此，这些功能可以被解释为用于 在通信网络中传送消息的方法和系统的步骤。可选地，这些功能的某些或全部可以由不具 有存储的程序指令的状态机来实现，或者以一个或多个专用集成电路(ASIC)来实现，在专 用集成电路(ASIC)中，每项功能或者这些功能的某些的组合被实现为定制逻辑。当然，也 可以使用这两种方法的组合。由此，用于这些功能的方法和装置此处已经作了描述。可预期的是，尽管在例如可用时间、当前技术和经济考虑的驱动下，本领域的技术 人员可能付出了显著努力和做出许多设计选择，但是当在此处所公开的概念和原则的指导 下时，其将能够以最少的实验，容易地生成这种软件指令、程序和IC。在前文的描述中，已经结合特定实施例描述了本发明及其益处和优点。然而，本 领域的技术人员应当理解的是，在不脱离如下文的权利要求所阐明的本发明的范围的条件 下，可以做出各种修改和改变。因此，本说明书和附图应被视为阐释性而非限制性，并且所 有这种修改应被包含在本发明的范围内。这些益处、优点、问题解决方案和可能导致任何益 处、优点或解决方案出现或变得更为明显的任何元件，不应被视为任何或所有权利要求的 关键、必需或本质特征或元件。本发明仅由随附的权利要求所定义，随附的权利要求包含在 本发明审查期间所作的任何修正，以及如所发布的那些权利要求的所有等同内容。遵照37CF. R. § 1. 72 (b)，提供“公开摘要”，37CF. R. § 1. 72(b)要求允许读者快速 确定该技术公开的本质的摘要。应理解的是，提交的摘要将不被用于解释或限制权利要求 的范围或含义。此外，在前文的“具体实施方式
”中，可以看出，在单个实施例中将各种特征 归纳在一起是出于简化本公开的目的。这种公开的方法不应被解释为反映如下的目的，即，所声明的实施例要求比在每项权利要求中所明确表述的特征更多的特征。相反，如下列权 利所反映的，发明的主题的特征少于单个公开的实施例的所有特征。因此，下列权利要求由 此被包含在具体实施方式
中，而每项权利要求作为独立声明的主题而存在。
权利要求
一种通过使用实时流协议(RTSP)在通信网络中提供多媒体服务的方法，所述通信网络包括客户端设备和网络设备，在所述网络设备处的所述方法包括从所述客户端设备接收对于所述服务的请求；基于所述请求，将属性集合和与所述属性集合的每个属性相对应子属性传送至所述客户端设备，其中，所述每个属性和每个子属性与一个或多个数据文件相关；以及基本持续地传送与所述一个或多个数据文件相关的元数据集合，直到来自所述客户端设备的干预为止，其中，基于所述客户端设备对所述传送的子属性和属性集合的响应，来选择所述一个或多个数据文件的每个数据文件。
2.根据权利要求1所述的方法，还包括在接收到所述请求之后，将确认消息从所述网 络设备传送至所述客户端设备。
3.根据权利要求2所述的方法，还包括在传送所述子属性和属性集合之前，在所述网 络设备处从所述客户端设备接收对于所述确认消息的第一响应。
4.根据权利要求3所述的方法，还包括基于来自所述客户端设备的所述第一响应，对 所述第一或多个数据文件进行分类。
5.根据权利要求1所述的方法，还包括在持续传送所述元数据集合之前，在所述网络 设备处从所述客户端设备接收对于所述传送的子属性和属性集合的第二响应。
6.根据权利要求4所述的方法，其中，当所述客户端设备未从所述属性集合中选择属 性时，对于预定的属性集合持续地传送元数据集合。
7.根据权利要求1所述的方法，其中，所述服务是音乐服务。
8.根据权利要求1所述的方法，其中，所述元数据文件集合是会话描述协议(SDP)文件。
9.根据权利要求1所述的方法，还包括在所述网络设备处从所述客户端设备接收流媒 体请求。
10.一种网络设备，包括接收模块，所述接收模块用于在通信网络中从客户端设备接收对于多媒体服务的请 求；以及传送模块，所述传送模块被构造成用于基于所述请求，将属性集合和与所述属性集合的每个属性相对应的子属性传送至所述 客户端设备，其中，每个属性和每个子属性与一个或多个数据文件相关；以及基本持续地传送与所述一个或多个数据文件相关的元数据集合，直到来自所述客户端 设备的干预为止，其中，基于所述客户端设备对所述传送的属性集合的响应，来选择所述一 个或多个数据文件的每个数据文件。
11.根据权利要求10所述的网络设备，其中，所述多媒体服务是音乐服务。
12.根据权利要求10所述的网络设备，其中，从包括流服务器和流管理服务器的组中 选择所述网络设备。
13.根据权利要求10所述的网络设备，其中，所述元数据集合是会话描述协议(SDP)文件。
14.根据权利要求10所述的网络设备，其中，所述传送器进一步被构造成在接收到所 述请求之后，将确认消息传送至所述客户端设备。
15.根据权利要求14所述的网络设备，其中，所述接收模块被构造成用于在传送所述 子属性和属性集合之前，从所述客户端设备接收对于所述确认消息的第一响应。
16.根据权利要求10所述的网络设备，其中，所述接收模块被构造成用于在持续传送 所述元数据集合之前，从所述客户端设备接收对于所述传送的子属性和属性集合的第二响应。
17.根据权利要求10所述的网络设备，其中，所述接收模块被构造成用于从所述客户 端设备接收流媒体请求。
全文摘要
提供了一种通过使用实时流协议(RTSP)在通信网络中提供多媒体服务的网络设备(102)和方法。该通信网络包含客户端设备(104)和网络设备。在网络设备处的方法包括从客户端设备接收(404)对于服务的请求。而且，该方法包含基于该请求，将属性集合和与该属性集合的每个属性相对应的子属性传送(406)至客户端设备。每个属性和每个子属性与一个或多个数据文件相关。此外，该方法包括基本连续地传送(408)与一个或多个数据文件相关的元数据，直到来自客户端设备的干预为止。基于客户端设备对传送的子属性和属性集合的响应，来选择一个或多个数据文件的每个数据文件。
文档编号G06F12/16GK101803292SQ200880107388
公开日2010年8月11日 申请日期2008年9月10日 优先权日2007年9月18日
发明者安库尔·梅罗特拉, 布哈瓦纳·巴特, 纳温·帕帕纳 申请人:摩托罗拉公司