专利名称：模式化音频/视频数据的系统和方法
技术领域：
本发明一般涉及文件管理，尤其涉及基于丰富的模式集来存储和管理音频和视频数据的系统和方法。
背景技术：
过去几十年来计算机和电子相关的技术进步已经引领了计算机时代。例如，晶体管技术的进步已使得集成电路的制造能以事实上每年每平方英寸上的晶体管数量(晶体管密度)成两倍发展(摩尔定律)。这样的进步已导致在处理功率和传送速率(例如数据、控制和地址)上的巨大收获，以及组件/底板尺寸、功率消耗和成本的降低。此外，因特网和无线技术的进步已向用户提供了通过按键或鼠标的点击来实现几乎在世界上任何地方任何时间的访问。计算机设计者继续利用这种进步来开发更高性能、更可靠、更买得起的新一代计算系统。
前述和许多其它进步已对计算机进化为一种可便于和加速日常个人和商业行为的合算的、强大的、有效的机制作出了贡献。例如，当今的计算机已例行地应用于通信(例如电子邮件、即时消息、聊天室等的通信)、购买、销售、信息收集、分析、以及存档(例如文档管理)。此外，当今的计算机通常也用于比如访问股价(例如实时地)、获取气象预报、检索方向、流媒体视频、聆听音乐、获得逐局的体育赛事更新、以及玩游戏(例如在线地)。此外，计算机技术已被结合到各种系统中，诸如汽车、家庭保安、制造过程、蜂窝式电话、个人助理、以及餐具，以提供自动或半自动控制和/或监视的智能系统。
第三方供应商已使用这样的技术突破通过增加用户友好、灵活性、选项、个性化、可靠性、安全性和速度的应用程序来增强用户体验。通常这种增强都是通过代码(例如可执行文件、库等)的更改和/或添加来获取，这常常会引入其它文件和/或增大应用程序(例如文件的集聚)的尺寸。因而，采用最新技术来提供改进的第三方应用程序开发常常需要更大的盘空间。然而，存储器和其它硬件中的同步进步已提供了增大的磁盘容量和搜索时间速率，这可提供增大的应用程序尺寸和/或对递增数量的通过存储器存储的不同文件的检索。
应用程序开发通常包括对时间和金钱的大量投入以构成并创建在现有操作系统(OS)周围的应用程序。例如，开发者通常不得不理解OS体系结构的至少某些方面以便建立与OS通信以及利用OS计算能力的接口。此外，开发者常常为公共存储抽象(例如人、地点、时间和事件的表示)设计并生成唯一的数据存储器。结果，经多个第三方供应商的开发可导致重复或多余的开发努力，其中多个数据集在相应应用程序之外不能被共享和利用；与应用程序相关联的许多信息仍在仅为应用程序可访问的文件中被锁定，从而导致多组数据不可共享。
除了花费资源来理解并生成操作系统周围的应用程序之外，第三方开发者会面对文件系统或操作系统的更改(例如修订、路径等)或下一代操作系统可能会使应用程序呈现出不兼容性并因此不起作用的更大可能性。例如，寻址存储器的技术中(例如从16比特到64比特)的改变会向操作系统呈现出应用程序事实上不兼容。受影响的第三方供应商将不得不将更多的资源投入到理解操作系统的细微差别和复杂性，以及对现有应用程序的花样翻新或创建新的应用程序中，以了解道另一操作系统修订或生成可导致另一个不受支持的应用程序集。
发明内容
以下显示了本发明的简化归纳，以便提供对本发明一些方面的基本理解。该归纳不是本发明的广泛纵览。它并非旨在标识本发明的关键/重要元素或描绘本发明的范围。其唯一目的是用简化形式表示本发明的一些概念，作为后面呈现的更详细描述的序幕。
本发明提供用于一丰富文件管理系统的系统和方法，该文件管理系统可集成在平台内向第三方开发者提供一种有效开发可在操作环境内不同数据(例如音频和视频)上统一采用的任意应用程序(例如音频和视频)前端的机制。按照惯例，第三方供应商具有理解操作环境各方面的任务以便建立在操作系统内可进行通信和操作的应用程序。这种努力会消耗例如可更有效地用于应用程序前端开发的时间和资源。此外，来自在类似市场内(例如音乐播放器)竞争的不同第三方供应商的努力可导致不能共享的重复或多余工作，和/或许多不同的期间格式基本上仅仅只与相关联应用程序兼容。本发明可通过向第三方提供建立操作系统周围的应用程序的API来减少这样的努力。一般而言，所提供的API通常基于为诸如音频和视频数据的不同数据类型提供无缝操作的各种丰富模式。因而，第三方供应商可利用API并集中于建立可提高用户体验的应用程序前端，而新的文件系统管理不同的数据。
在本发明一方面中，提供了管理文件的系统。该系统包括协调诸如音频和/或视频文件信息的存储和检索的一个组件。该组件可采用几乎对所有类型数据相同的模式和/或与特定数据相关联(例如导出)的模式。利用这样的模式可提供对诸如视频、音频、文件等的不同数据在类似存储介质内的有效和结构化存储及管理，其中数据可进行无缝标识、区分和访问。
在本发明另一方面中，描述了一种数据管理系统。该系统采用各种模式(例如视频和音频)以便于存储和/或组织数据、查询数据和/或处理数据库内的数据。此外，系统可结合文件管理系统使用，其中几乎任何和所有的数据可基于相应的模式和/或其导出模式来存储。一般而言，当用户和/或应用程序提供数据用于存储，可获取并利用适当的模式以便于这样的存储，且当用户和/或应用程序请求数据时，可获取适当的模式以便于服务该请求。
在本发明另一方面中，提供了一种系统地存储和访问信息的系统。该系统包括可由用户和/或应用程序用来与系统交互的一个API。该API通常基于与数据相关联的模式(例如音频和视频)生成。然而，可以理解，一公共API可用于多类数据。该系统还包括便于数据存储和检索的智能。
在本发明的又一方面中，提供了采用与存储和管理文件相关的模式的各种方法。第一种方法包括接收文件(例如音频和/或视频)、获取一相关联模式(例如公用和专用)，并利用该模式在数据库内存储文件。第二种方法提供基于一个或多个模式生成的API。开发者可建立API周围的应用程序，其中用户和/或应用程序可通过适当的API传送信息。适当模式的示例包括普通的音频和视频相关模式。
在本发明的其它方面中，示出了示例性模式。该示例性模式包括介质、音频和视频模式。在许多示例中，音频和/或视频模式可从媒体模式中导出。
为实现前述及相关结果，本发明包括此后全面描述并在权利要求中特别指出的特征。以下描述和附图详细陈述了本发明的某些说明性方面和实现。然而，这些方面仅仅示出了本发明诸原理可在其中采用的各种方式的其中几种。结合附图参阅本发明的以下详细说明，本发明的其它目标、优点和新特征将变得显而易见。
图1根据本发明一方面示出一示例性文件管理系统。
图2根据本发明一方面示出一示例性的基于模式的文件系统。
图3根据本发明一方面示出一示例性数据管理系统。
图4根据本发明一方面示出系统地存储和访问信息的一示例性系统。
图5根据本发明一方面示出采用与管理数据库中文件有关的模式的一示例性方法。
图6根据本发明一方面示出便于与数据库用户交互的示例性方法。
图7根据本发明一方面示出模式之间的示例性关联。
图8示出其中可采用本发明诸新颖方面的示例性环境。
具体实施例方式 本发明涉及提供适用于存储并管理数据库内数据的一丰富文件管理的系统和文件。该系统和方法可结合操作系统用来向应用程序开发者提供界面以任意地生成在诸如音频和视频数据的不同数据上统一工作的应用程序。本发明可减少供应商通过定义模式以及提供API来与操作系统通过界面相连并通信的努力。因而，第三方供应商可集中于建立可提高用户体验的应用程序前端。
当用于本发明时，术语“组件”旨在指向计算机相关实体硬件、硬件和软件的组合、软件、或执行中的软件。例如，组件可以是，但不限于是，运行于处理器的过程、处理器、对象、可执行组件、执行线程、程序和/或计算机。作为说明，运行于服务器上的应用程序和服务器都可以是组件。一个或多个组件可驻留于执行的过程和/或线程中，且组件可在一台计算机上本地化和/或分布在两台或多台计算机之间。众所周知，线程可具有是与线程的执行相关联的易失性数据的相关联“上下文”。线程的上下文包括系统寄存器的内容和属于线程过程的虚拟地址。
现在本发明参照附图进行描述，其中类似标号被用来指向类似元件。在以下描述中，为了进行解释，陈述了许多特定细节以便提供对本发明的全面理解。然而，显然没有这些特定细节本发明也可得到实践。在其它实例中，众所周知的结构和装置以框图形式示出以便于描述本发明。
图1根据本发明一方面示出管理文件的系统100。系统100包括文件管理组件110、文件系统120和日志130。文件管理组件110可接收、存储和管理文件系统内的不同文件(例如音频、视频、图像、文档等)。此外，文件管理组件110可通过形成关系来建立与已存储信息的链接。这样的关系是可能的，因为不像在常规系统中，不同的信息可像实体而非独立数据一样进行管理。作为示例，各关系可提供一种将诸如作者、图片、图标等的信息链接到音频和/或视频数据的机制。前述内容提供了无需知道数据的内部结构就可在多种类型的数据(例如不同的)之上或其内进行信息共享和有效的查询。
一般而言，关系可用一个或多个联系项来建立。例如，作者关系可被建立并用来捕捉广泛的各类音频和/或视频作者。例如，相应的音乐家、作者、指挥、小提琴家、演员、导演等可被视为是录音的作者，而那些被列入电影致谢名单的人可被视为是视频作者，其中不同类型的作者可通过与关系相关联的角色进行彼此的区分。因而，音频或视频可与具有定义为“音乐家”的角色的联系项有关系，与具有定义为“作曲家”的角色的不同联系项有另一关系，与具有定义为“指挥”的角色的不同联系项有另一关系，等。可以理解，联系项还可包括个人信息，诸如电话号码、地址、以及电子邮件链接。
如上所述，联系项提供数据上的有效查询。例如，采用一联系项提供了对不同数据的查询以获取电影/录音的致谢名单。在另一示例中，查询可对与一特定艺术家相关联的所有著作的数据执行(例如，利用该艺术家的联系项并列举与其相关的所有作者关系。)。这样的查询可返回由该艺术家创作的歌曲、该艺术家演唱的歌曲、该艺术家创作的和/或有关该艺术家的书籍、该艺术家扮演的电影等。可以理解，与联系项的关系使能这种功能，且音频和/或视频数据可不包括这样的信息。该优点可在家庭视频中得以开发，其中该视频的导演和演员可以是亲属和/或朋友。
文件管理组件110还可查找、提供提交元数据，并使其与文件相关联，其中该提交元数据可包括指示这种元数据确实与文件相关联的置信程度的置信水平。例如，当接收一段音频录音时，文件管理系统组件110可建立具有各种置信水平的与提交元数据的关系。例如，文件管理组件110可基于一置信水平获取(例如通过一本地和/或远程源)被确定为与录音源相关联的录音元数据，并连同置信水平一起提供元数据。在本发明一方面中，一算法可用于查找并获取一段录音的元数据。用户和/或有关系统100采用的智能可从提交数据中选择适当元数据，其中任意或所有的提交和/或选定元数据可与录音一起存储。在另一示例中，可将用户请求或聆听一段录音通知其它录音相关介质。例如，用户可获得通知，有关艺术家表演乐曲的特别节目已安排在电视上播出。
要注意，元数据可通过捕捉对应于检索和/或计算元数据中不同步骤和/或阶段的状态的各种字段与生命周期相关联。例如，元数据可与跟踪元数据检索未获成功尝试的次数的字段相关联。这样的信息可被用来减少检索元数据的重复尝试。例如，可得以尝试的阈值次数，其中一旦达到阈值可中止检索尝试除非和/或直到接收到撤销信号。在另一示例中，元数据与定义相关于用来检索元数据的资源(例如网络连接)的限制，以及确定多快可获取元数据的优先级的字段相关联。
文件管理组件110还可便于解析录音及其源专辑之间的相关性。一般而言，录音通常包括有关其源专辑的至少某些信息(例如名字、标题、作者等)。然而在许多实例中，该信息尽管是合法的但在来自同一源的录音之间可以是不正确和/或更改的。例如，信息可能被拼错、曲解和/或改变。文件管理组件110可检索实际的专辑信息(例如名字、标题、作者等)以消除任何矛盾并存储原始或感知信息(从录音中)以及带有录音的实际信息(来自专辑)。例如，原始信息可被包括在与专辑相关联的关系的属性中。值得注意的是，原始信息可保留在音频录音中(例如当它被复制或移动时)，而实际信息可被获取并用来消除任何矛盾。
文件管理组件110还可使分级与文件相关联。一般而言，基于文件的类型(例如电影、录音等)，分级可与权威机构相关联(例如MPAA、RIAA、TV、用户等)并能反映各种规格(例如起源、质量、用户等)。这种分级可被各类文件利用。例如，分级可用来查询用户的“爱好”或根据用户的需要来提供用户的内容(例如音频、视频、书、图片等)。
文件管理组件110还可保留文件历史。文件历史可包括有关文件是否被编辑、文件被如何编辑、文件何时被编辑、文件何时经电子文件发送、文件经电子文件发送给谁等的信息。这样的历史可结合算法用来呈现智能决策。例如，可检索历史并用其来基于文件被访问的次数自动构建“爱好”列表，并在特定日期和时间以特定顺序自动执行文件。确定用户投入大量时间来编辑文件可表明该文件对用户是重要的且不应被删除。
文件管理组件110可命名并存储有关视频各子部分的其它信息。这样的能力可被用来例如指示电影的喜爱部分。例如，子部分可被命名为“我喜爱的部分”并包括诸如“其中……”的描述。在另一实例中，电影内容中代表性的电影部分可被标识。子部分可用来快速播放相应的电影部分。例如，可请求仅播放包括一特定演员的那些电影部分。
可以理解，前述内容是说明性且非限制的。本领域技术人员将理解并认为，各种其它文件管理功能，包括以下所述的各个新方面，可结合系统100执行。
图2根据本发明一方面示出一文件系统200。文件系统200包括可接收存储在数据库220中的输入的数据管理器210。该输入实际上可以是任何类型的电子数据，包括但不限于音频和/或视频数据。适当的音频数据的示例包括从CD截取的音频文件、从录音机生成的音频文件、经音频元件(例如声卡)录制的音频、来自专辑和/或录音带(例如卡、8-音轨、盘对盘等)的模拟音频、来自存储器(例如存储器棒和其它便携式存储器)的音频文件、下载的音频文件(例如经因特网)等。适当视频数据的示例包括来自DVD的数据、视频CD(VCD)、摄像机、数字摄像机、数码相机等。其它数据可包括图像、文档等。
数据管理器210可获取与来自模式库230相关联的一个模式(例如以下详细描述的介质、视频和音频模式)。例如，对于音频输入，数据管理器210可检索与来自模式库230的音频数据相关的模式。该模式可以是实质上可标识任何已知类型输入(例如文档、音频和视频)的公共或基本模式。在另一示例中，被检索的模式可以是基于与输入相关联的至少一个特征(例如属性)而专用和/或增强的公共模式的导出物。这样的导出物可包括对基本模式的过载和/或扩展。在又一示例中，模式可根据数据类型调整。
数据管理器210可利用丰富模式来便于输入在数据库220内的存储和组织。采用公共模式和/或从基本模式导出的模式提供不同数据(例如视频、音频、文档等)在类似存储介质中的存储，其中数据管理器210可无缝地标识、区分和访问不同数据。这种能力提供对常规文件系统的改进；并因而，文件通常仅可由生成文件的应用程序访问。
数据管理器210还可接收与对存储在数据库220内数据的请求相关的输入。例如，用户可执行音频播放器并选择要回放的录音或文件。数据管理器210可利用与录音相关联的模式以查找选定录音并提供对其的访问。类似地，在数据库220内存储的视频和其它数据可通过与该数据相关联的模式经数据管理器210访问。
可以理解，文件系统200可结合操作系统采用。该操作系统将使第三方供应商能将应用开发集中于生成改善用户体验的用于多媒体应用程序的丰富前端，而不是构建通常不能由各供应商共享的适当模式，并集中于使应用程序与操作系统通过界面相连。因而， 本发明新方面提供可用作供应商生成采用不同数据的任意应用程序的基础的可扩展平台。
图3根据本发明一方面示出管理数据的系统300。系统300包括与包括至少一视频模式330和一音频模式340的模式320相关联的数据库310。用户和/或应用程序可与数据库310交互以便存储和/或组织数据、查询和/或处理(例如编辑、移动和删除)数据库310中的数据，其中数据可包括例如不同的音频和/或视频信息。
模式320通常是可显示任何介质的的基本或一般模式，且视频模式330和音频模式340通常是可分别包括视频和音频数据的领域专用属性的模式320的扩展。注意，在本发明一方面中，视频模式330和音频模式340可基于一般模式320，且也可提供其它模式(未示出)。这种模式可结合中央文件系统或文件管理系统(例如结合操作系统)利用，其中实质上任何和全部文件都可基于相应模式和/或其导出模式进行存储，包括视频模式330和音频模式340。
一般而言，当用户和/或应用程序向数据库310传送要被存储在数据库310中的数据时，可获取适当的模式。例如，当诸如录音或一组录音的音频数据被传送到数据库310用于存储，模式320或音频模式340可被检索并用来便于以结构化方式存储音频数据。此外，用户和/或应用程序可在处理该已保存数据时利用模式。例如，如果用户和/或应用程序尝试编辑、删除、移动已存储的音频数据等，模式320和/或音频模式340可被检索并用来便于这样的处理。此外，模式可被检索并用来便于服务来用户和/或应用程序的查询，例如便于返回用于回放的音乐录音。
可以理解，适当的应用程序可包括任何已知的音频和/或视频应用程序，诸如各种介质播放器、音频播放器和视频播放器。此外，一个以上应用程序可同时采用一模式(例如基本模式320、视频模式330和音频模式340)，这可提供改进的效率和性能。可以理解，一个以上应用程序可由一个或多个系统中的一个或多个用户执行。
图4根据本发明一方面示出可被用来系统地存储和访问信息的系统400。系统400包括可由用户和/或应用程序用来与系统400交互的应用程序编程接口(API)410。在本发明一方面中，系统400可包括可基于一个或多个模式创建各个API的API发生器420。例如，API发生器420可基于由模式发生器430创建的音频模式来创建一音频API。模式发生器430可通过音频配置440和/或基本(例如介质)配置450来创建该模式。
在另一示例中，API发生器420可基于视频和/或一般模式创建一视频API，而视频和/或一般模式是基于基本配置450和/或视频配置460。在又一示例中，API发生器420能够创建实质上可用于任何类型数据的一公共(例如介质)API。用户和/或应用程序可采用这样的API来与数据库470传送/接收信息。例如，用户和/或应用程序可采用一适当API来存储和/或检索来自数据库470的音频和/或视频数据。
可以理解，一个以上应用程序可通过一个或多个系统的一个或多个用户执行。因而，基本上任何用户和/或应用程序都可通过API 410与数据库470通信。
智能组件480可被用来便于数据的存储和检索、模式生成和API生成、以及诸如自动化动作和呈现决策的各种其它实用程序。例如，智能组件480可便于使得录音与标题相关联。例如，用户可将若干录音存储到数据库470中，其中一个以上录音可源自类似源但包括源的标题的变体。例如，用户在截取录音后会拼错标题名字。智能组件480可便于解决这样的问题。例如，在本发明一方面中，智能组件可获取和/或推断类似变体并利用该变体来便于解决一问题。在本发明另一方面中，智能组件480可向用户和/或应用程序提示其它信息。此外，智能组件480可采用统计、概率、分类器和推断。
用户和/或应用程序可定义一配置，它可确定智能组件480所作的自动化和决策数量(例如从无到全部)。此外，智能组件480可利用历史信息来自定义自动化和决策的数量。例如，智能组件480可采用用户和/或应用程序已拒绝特定动作和/或由智能组件480呈现的决策的次数，其中大于阈值的数量可指示智能组件480不应采用全自动化。在本发明另一方面中，用户和/或应用程序可向智能组件480提供培训设置，使得智能组件480可从培训设置中学习。
一般而言，智能组件480推断指从经事件和/或数据捕捉的从一系列观察中推理或推断系统、环境和/或用户的状态。还有，推断可用来标识特定的环境或动作，或可产生例如状态上的概率分布。此外，该推断是或然性的，例如相关状态上概率分布的计算基于对数据和事件的考虑。推断也可指包括用来从一系列事件和/或数据中组成较高级别事件的方法的确定性或逻辑推理技术。这种推断导致了基于一系列观察事件和/或存储事件数据对新事件或行为的构建，不管这些事件在时间上是否紧密相关，及这些事件和数据是来自一个还是若干个事件和数据源。各种分类方法和/或系统(例如支持向量机器、神经网络、专家系统、贝叶斯信任网络、模糊逻辑、数据融合引擎等)可与本发明相关地结合执行自动和/或推断动作而被采用。
图5和6根据本发明一方面示出各方法。尽管为了简单解释，该方法被示为并描述为一系列动作，但可以理解和认为本发明并不受这些动作的顺序的限制，因为根据本发明某些动作可以不同顺序和/或与在此所示和所述的其它动作同时发生。例如，本领域技术人员将理解和认为方法可有选择地被表示为一系列相互关联的状态或事件，诸如在状态图中。此外，根据本发明实现一方法并不需要所有所示动作。
图5根据本发明一方面示出采用与文件管理系统相关的丰富模式集的方法500。继续到标号510，接收一文件。在本发明一方面中，所接收的文件可包括音频和/或视频数据并可由例如用户、应用程序或用户通过应用程序传送。
在标号520，检索与文件相关联的模式。例如，可检索实质上可表示任何已知类型文件的公共模式。在另一示例中，所检索的模式可对应于文件的格式。例如，模式是可用来便于存储音频文件的基于音频模式，或用来便于存储视频文件的基于视频模式。可以理解，这种基于格式的模式可从公共模式导出，并可用来专用和/或增强基于文件格式的公共模式。
在检索适当模式之后，在530模式可用来在数据库内存储文件。通常，模式提供相对数据库内其它信息系统地安排文件。可以理解，这样的模式以及其它模式可结合与操作系统相关联的文件系统来利用，其中实质上任何或全部文件可基于模式和/或其导出模式来存储。
图6示出根据本发明一方面便于数据库内文件管理的方法600。在标号610，生成便于用户和/或应用程序与数据库之间的交互的API。该API可被用来存储、处理、检索和/或从数据库去除文件。所使用的API可以是与文件无关或相关的。例如，一无关API实质上可被用于任何类型的文件，而相关API通常基于文件格式生成并随后在用该格式传送文件时采用。例如，基于音频文件的API可被用来传送音频文件，而基于视频文件的API可用来传送视频文件。
在620，用户和/或应用程序可调用API。例如，当用户/应用程序想要存储一视频文件，用户/应用程序可采用公共的或基于音频的API将文件传送给数据库。在另一示例中，用户/应用程序可传送处理存储文件的请求。例如，用户可请求改变文件名、位置、类型、保护等。在又一示例中，用户/应用程序可请求将文件从数据库中去除或删除。在另一示例中，用户/应用程序可查询数据库以检索一文件。
在630，数据库可获取相关联的公共和/或扩展(例如基于音频的)模式以便于服务用户/应用程序。例如，模式可被用来便于将文件模式化地存储在数据库中。在另一示例中，模式可被用来定义对文件任何处理的范围。在又一示例中，模式可用于结合在数据库中搜索文件。该模式可以是一般模式，它表示任何介质并可任选地包括可涉及例如视频和音频数据的领域特定属性的扩展。
当实现用户/应用程序的请求时，数据库可使用API来通知用户/应用程序。例如，数据库可传送确认或错误的代码。此外数据库可利用该API将文件返回给用户/应用程序。可以理解，适当的应用程序可包括任何已知应用程序(例如介质播放器、音频播放器和视频播放器)，其中一个或多个应用程序可并发采用一模式。此外，一个或多个应用程序可一个或多个系统的一个或多个用户执行。
模式 以下章节描述根据本发明一方面可采用的示例性介质、视频和音频模式(例如结合系统100-400和方法500-600)。可以理解，媒体模式可从核心(Core)模式(例如System.Storage.Core.Document)中导出，而视频和/或音频模式可从媒体模式(例如System.Storage.Media.Document)和/或项目(Item)模式(例如System.Storage.Item)中导出。此外，这样的模式可结合任何已知类型的数据一起采用，例如文档、图像、照片等。
媒体模式 媒体模式可采用以下模式System.Storage和System.Storage.Core。此外，媒体模式包括项目类型、扩展类型、关系类型、嵌套类型。前述类型在下面详细描述。
项目类驯 以下表格提供一示例性文档类型。一般而言，该类型可表示一视频文档，诸如录音、专辑等。通常它包括一个或多个文档的公共字段。它可从System.Storage.Core.Document导出。
扩展类型 以下表格提供示例性MeadataLifecycle类型。一般而言，该类型可表示寿命和其它状态跟踪。它可从System.Storage.Extension导出。
关系类型 以下表格提供示例性ContentDistributor类型。一般而言，该类型指内容(例如清样)的发行人。它可从System.Storage.Relationship导出。其源类型是System.Storage.Media.Document而其目标类型是System.Storage.Core.Contact。
EffectiveBackCoverArt类型可表示与媒体文档的后封面的图片链接。它可从Syste m.Storage.Relationship导出。其源类型是System.Storage.Media.Document而其目标类型是System.Storage.Core.Document。
EffectiveFrontCoverArt类型可表示与媒体文档的前封面的图片链接。它可从System.Storage.Relationship导出。其源类型是System.Storage.Media.Document而其目标类型是System.Storage.Core.Document。
MetadataProviderLogo类型可表示与元数据的原始供应商相关联的司标(例如AMG)。除前述内容之外，以下表格提供根据本发明一方面可采用的示例性类型。它可从System.Storage.Relationship导出。其源类型是System.Storage.Media.Document而其目标类型是System.Storage.Core.Document。
嵌套类型 以下表格提供了示例性ContentDistributorData类型。一般而言，该类型可表示与介质信息的内容发行者的联系项的链接。它可从System.Storage.Relationship导出。它可从System.Storage.NestedType导出。
以下表格提供示例性历史类型。一般而言，该类型可表示媒体文档的历史(例如何时它被编辑、它被如何编辑、它被邮寄给谁、它有没有被旋转、是否应用了过滤器、相关联的播放计数等)。它可从System.Storage.NestedType导出。
以下表格提供示例性分级类型。一般而言，该类型可表示由权威机构给予媒体文档的分级。例如，这种权威机构可包括视频的MPAA分级(例如PG13、NR、R、X和NC-17)、音频的RIAA分级(例如性描述歌词)、电视分级和/或用户专用分级。此外，分级可按起源、质量、用户专用等划分。通常，有两类分级字符串分级和数字分级。一般而言，该类型是抽象类型并可从System.Storage.NestedType导出。
以下表格提供示例性CustomRating类型。一般而言，该类型可表示由某些权威机构给予媒体文档的自由形式字符串的分级。如上所述，它可从System.Storage.Media.Rating导出。
以下表格提供示例性StarRating类型。一般而言，该类型可表示由某些权威机构给予媒体文档的数字分级。如上所述，它可从System.Storage.Media.Rating导出。
以下表格提供示例性URLReference类型。一般而言，该类型可表示指示类型URL的URL和类别。它可从Syste m.Storage.NestedType导出。
以下表格提供示例性MVString128类型。一般而言，该类型可表示多值字符串封装。它可从Syste m.Storage.NestedType导出。
以下表格提供示例性MVString256类型。一般而言，该类型可表示多值字符串封装。它可从System.Storage.NestedType导出。
视频模式 视频模式采利用以下模式Syste m.Storage；System.Storage.Media和System.Storage.Core。此外，媒体模式包括项目类型、扩展类型、关系类型、嵌套类型。前述类型如下进行详细描述。
项目类型 以下表格提供一示例性VideoRecord类型。一般而言，该类型可表示视频记录。它可从System.Storage.Media.Document导出。
以下表格提供一示例性RecordedTV类型。它可从System.Storage.Video.VideoRecord导出。
以下表格提供了示例性VideoClip类型。一般而言，该类型可表示一视频片断。它可从System.Storage.Item导出。
关系类型 片断类型可指视频记录的一个片断集。它可从System.Storage.Relationship导出。其源类型是System.Storage.Video.VideoRecord而其目标类型是System.Storage.Video.VideoClip。
嵌套类型 以下表格提供示例性VideoSubShot类型。一般而言，该类型可表示对视频记录的分拍摄。它可从System.Storage.NestedType导出。
音频模式 音频模式利用以下模式System.Storage；System.Storage.Media；System.Storage.Core和System.Storage.Image。此外，媒体模式包括项目类型、扩展类型、关系类型、嵌套类型。前述类型如下进行详细描述。
项目类型 以下表格提供一示例性CaChedAlbum类型。一般而言，该类型可表示包括若干乐曲的音频。它可从System.Storage.Media.Document导出。
以下表格提供一示例性VAudioRecord类型。一般而言，该类型可表示与音频记录相关联的元数据。该元数据可包括诸如文件尺寸、文件格式、使用的压缩类型等的信息。该类型可从System.Storage.Media.Document导出。
以下表格提供示例性Track类型。一般而言，该类型可表示包括音乐数据的音频乐曲。例如，它可对应于从CD中获取或存储在文件系统中的乐曲。它可从System.Storage.Audio.AudioRecord导出。
以下表格提供一示例性CachedTrack类型。一般而言，该类型可表示缓存音频乐曲的元数据。在本发明一方面中，CachedTrack类型可用来便于数据的标识。例如，用户可插入一CD，其中一个或多个可能乐曲被自动存储于CachedTrack中并提供给用户。用户可从对应于CD的列表中选择一乐曲(或提供一不同乐曲)。然后其它乐曲可从CachedTrack中移除，且该选择可提供给Audio.Track或Audio.PlatterTrack。因而，CachedTrack可表示一位置，用于可能乐曲信息的暂时存储。该类型可从System.Storage.Audio.AudioRecord导出。
以下表格提供一示例性PlatterTrack类型。一般而言，该类型可表示用于音频乐曲的元数据。这样的元数据可与数据一起保持，例如当乐曲从CD中获取时元数据可被包括在取得乐曲中。此外，元数据可用来识别数据。例如，可请求特定CD。如果提供了错误CD，当通过元数据确定时，用户可得到通知插入了错误CD。该类型可从System.Storage.Audio.AudioRecord导出。
以下表格提供一示例性PlayList类型。一般而言，该类型可表示一音频播放列表。它可从System.Storage.Media.Document导出。
以下表格提供一示例性RadioStation类型。一般而言，该类型可表示能够提供无线电流媒体的一无线电台。它可从System.Storage.Item导出。
以下表格示出了一示例性RadioStream类型。一般而言，该类型可表示由无线电台提供的无线电流媒体。例如，它可嵌于RadioStation项内。它可从System.Storage.Item导出。
以下表格提供一示例性ListeningHabits类型。一般而言，该类型可相对乐曲与用户相关联。例如，该项可专用于用户的音乐播放体验。它可在每个用户一个媒体数据上采用，具有“所有者”每个记录的ACL。它可从System.Storage.Item导出。
以下表格提供一示例性ListeningHabitslog类型。一般而言，该类型可相对乐曲与用户相关联。例如，该项可专用于用户对带有“所有者”每个记录的ACL的每个用户一媒体数据的音乐播放体验。它可包括与介质回放相关的多个实例(例如经过许多个月)。它可从System.Storage.Item导出。此外，应用程序可处理和/或清空数据并生成给出媒体收听习惯的自然时间衰变。它可从System.Storage.Item导出。
扩展类型 以下表格提供一示例性ArtistInformation类型。该类型可提供用于智能分组。它可从System.Storage.Extension导出。
关系类型 以下表格提供一示例性TrackAlbum类型。一般而言，该类型可表示从乐曲与相关联专辑的链接。例如，乐曲通常包括有关其源的信息。当接收到乐曲时，包括在乐曲中的信息可用来创建标识其源的感知关系。当标识实际源时，感知关系可被利用并使之与实际源相关联。该类型可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.AudioRecord而其目标类型是System.Storage.Audio.CachedAlbum。
以下表格提供示例SuggestedMetadata类型。一般而言，该类型可表示跟踪元数据的链接集。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.AudioRecord而其目标类型是System.Storage.Audio.CachedTrack。
以下表格提供示例性RadioStationContentDistributor类型。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.RadioStation而其目标类型是System.Storage.Core.Contact。
以下表格提供示例性RadioStationLocation类型。一般而言，该类型可表示节目源头的位置。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.RadioStation而其目标类型是System.Storage.Core.Location。
RadioStationLogo类型可表示与包括无线电台的台标图案的图像链接。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.RadioStation而其目标类型是System.Storage.Core.Document。
RadioStationStreams类型可表示无线电台可提供的流媒体的集合。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.RadioStation而其目标类型是System.Storage.Core.RadioStream。
Listeners类型可提供与听众的关系。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.ListeningHabits而其目标类型是System.Storage.Core.Contact。
ListenedTrack类型可提供与收听乐曲的关系。它可从System.Storage.Relationship导出。其源类型是System.Storage.Audio.ListeningHabits而其目标类型是System.Storage.Audio.Track。
嵌套类型 以下类型提供一示例性AutoDJ类型。一般而言，该类型结合算法可用来通过分析乐曲创建一个或多个播放列表。它可从System.Storage.NestedType导出。
以下表格提供一示例性PlayCounter类型。一般而言，该类型可用来跟踪乐曲播放的次数(例如每小时、每天等)。它可从System.Storage.NestedType导出。
图7示出上述模式之间的若干示例性关系。注意，可形成其它关系但为了简便未示出。如图所示，WINFS项目类型705可以是一基本类型。Core.Document类型710、Audio.RadioStatio类型715、Audio.RadioStrea类型720、以及Video.VideoClip类型725可从WINFS项目类型705导出。Media.Document类型730可从Core.Document类型710导出。
Audio.AudioRecord类型735可从Media.Document类型730导出。Audio.AudioRecord类型735可用于导出Audio.CachedAlbum类型740、Audio.Track类型745、Audio.PlatterTrack类型750、和Audio.CachedTrack类型755。一般而言，Audio.Track类型745对应于取得音频文件的元数据，Audio.PlatterTrack类型750对应于音频CD上的乐曲，而Audio.CachedTrack类型755对应于下载元数据。可建立使Audio.Track类型745或Audio.PlatterTrack类型750与Audio.CachedTrack类型755中的元数据相关联的SuggestedMetadata关系。
还有，History类型760和Ratings类型765可从Media.Document类型730导出。此外，Video.VideoRecord类型770可从Media.Document类型730导出，其中Video.RecordedTV类型775可从Video.VideoRecord类型770导出。
参照图8，用于实现本发明各方面的示例性环境810具有计算机812。计算机812具有处理单元814、系统存储器816、及系统总线818。系统总线818耦合系统组件包括但不限于将系统存储器816耦合到处理单元814。处理单元814可以是各种可用处理器的任一种。双微处理器和其它多处理器架构也可用作处理单元814。
系统总线818可以是若干类总线结构的任一种，包括存储器总线或存储器控制器、外围总线或外部总线、和/或使用各种可用总线结构任一种的本地总线，这些总线结构包括，但不限于，8比特总线、工业标准结构(ISA)、微信道结构(MSA)、扩展ISA(EISA)、智能磁盘设备(IDE)、VESA局部总线(VLB)、外围部件互连(PCI)、通用串行总线(USB)、高级图形端口(AGP)、个人计算机存储卡国际协会总线(PCMCIA)、和小型计算机系统接口(SCSI)。
系统存储器816具有易失性存储器820和非易失性存储器822。包含在计算机812元件间如起动时传送信息的基本例程的基本输入/输出系统(BIOS)，存储在非易失性存储器822上。作为说明且无限制，非易失性存储器822可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除ROM(EEPROM)或闪存。易失性存储器820包括作为外部高速缓存的随机存取存储器(RAM)。作为说明且非限制，RAM有多种形式可用，如同步RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数率SDRAM(DDR SDRAM)、增强SDRAM(ESDRAM)、同步链接DRAM(SLDRAM)、和直接Rambus RAM(DRRAM)。
计算机812还具有可移动/不可移动、易失性/非易失性计算机存储介质。图8示出了例如磁盘存储器824。磁盘存储器824包括，但不限于，象磁盘驱动器、软盘驱动器、磁带驱动器、Jaz驱动器、Zip驱动器、LS-100驱动器、闪存卡、或存储棒。另外，磁盘存储器824可具有单独存储介质或结合其它存储介质包括，但不限于，诸如光盘ROM设备(CD-ROM)、可记录光盘驱动器(CD-R驱动器)、可重写光盘驱动器(CD-RW驱动器)、或数字化通用盘ROM驱动器(DVD-ROM)的光盘驱动器。为便于磁盘存储器824与系统总线818的连接，通常可使用诸如接口826的可移动或不可移动接口。
应当理解，图8描述了作为用户和在适当操作环境810中描述的基本计算机资源间中间体的软件。这种软件包括操作系统828。可存储在磁盘存储器824中的操作系统828，其作用是控制和分配计算机系统812的资源。系统应用程序830得益于操作系统828通过存储在系统存储器816或磁盘存储器824中的程序模块832和程序数据834对资源的管理。可以理解，本发明可用各种操作系统或操作系统组合来实现。
用户通过输入设备836将命令或信息输入到计算机812中。输入设备836包括，但不限于，诸如鼠标、跟踪球、铁笔、触板、键盘、麦克风、操纵杆、游戏垫、卫星接收器、扫描仪、电视调谐器卡、数字相机、数字摄像机、网络相机等定点设备。这些和其它输入设备经系统总线818通过接口端口838与处理单元814相连。接口端口838包括例如串行端口、并行端口、游戏端口、和通用串行总线(USB)。输出设备840使用象输入设备836的某些相同类型端口。因此，例如USB端口可用来为计算机812提供输入，并将信息从计算机812输出到输出设备840。输出适配器842可提供用来说明象监视器、扬声器、和打印机的某些输出设备840与其它输出设备840之间需要特殊适配器。输出适配器842包括，作为说明且非限制，视频卡和声卡在输出设备840和系统总线818间提供了连接方法。应该注意的是，诸如远程计算机844的其它设备和/或设备系统都可提供输入和输出功能。
计算机812使用与一台或多台远程计算机如远程计算机844的逻辑连接在网络化环境中操作。远程计算机844可以是个人计算机、服务器、路由器、网络PC、工作站、基于微处理器的电子设备、对等设备或其它公共网络节点等等，而且通常包括所述与计算机812相关的许多或全部元件。为简化起见，仅存储器存储装置846与远程计算机844一起图示。远程计算机844经网络接口848与计算机812逻辑连接，然后通过网络连接850进行物理连接。网络接口848包括诸如局域网(LAN)和广域网(WAN)的构成通信网络。LAN技术包括光纤分布式数据接口(FDDI)、铜线分布式数据接口(CDDI)、以太网/IEEE 802.3、令牌环/IEEE 802.5等等。WAN技术包括，但不限于，点对点链接、象综合服务数字网(ISDN)及其各变种的电路交换网络、分组交换网络、和数字用户线路(DSL)。
通信连接850指向被用来将网络接口848连接到总线818的硬件/软件。尽管为了清晰地说明，通信连接850被示为位于计算机812内，但它也可在计算机812之外。与网络接口848连接所必需的硬件/软件具有，仅作为示例，诸如包括常用电话调制解调器、电缆调制解调器和DSL调制解调器之类的调制解调器、ISDN适配器、和以太网卡等内部和外部技术。
以上所述包括本发明的诸多示例。当然，为描述本发明而对每一能想到的组件或方法组合进行描述是不可能的，但本领域普通技术人员明白本发明的更多排列和组合是可能的。因此，本发明旨在包含所有这样的在所附权利要求书精神和范围内的变更、修改、和变化。另外，尽管本发明的特定特征可仅参照若干实现之一进行揭示，对于任一给定或特定应用这样的特征可按需地或有利地结合其它实现的一个或多个其它特征。此外，就用于具体实施方式
或权利要求书的术语“包含”而言，这种术语意在以类似于术语“包括”在权利要求书中作及物词的方式作包括意义解。
特别地并相对于由上述组件、装置、电路、系统等执行的各个功能，用于描述这些组件的术语(包括对“装置”的引用)旨在对应于(除非另有说明)执行所述组件的特定功能的、执行在本发明示例性方面中所述的功能(即使在结构上不等同于所揭示结构)的任何组件。这样，可以理解，本发明包括系统以及具有用于执行本发明各种方法的动作和/或事件的计算机可执行指令的计算机可执行介质。
权利要求
1.一种管理不同文件的平台，其特征在于，包括
一管理组件，以及
一多媒体文件系统，其中所述管理组件将所述不同文件作为所述多媒体文件系统内一个数据实体进行管理。
2.如权利要求1所述的权利要求，其特征在于，所述不同文件包括音频、视频、图像和文档文件的一个或多个。
3.如权利要求1所述的权利要求，其特征在于，所述管理组件通过形成与一个或多个联系项的关系来建立不同文件之间的链接。
4.如权利要求3所述的权利要求，其特征在于，所述管理组件利用与在不同文件之上和之内查询相关的所述一个或多个联系项。
5.如权利要求3所述的权利要求，其特征在于，所述一个或多个联系项包括与电话号码、地址以及与电子邮件相关的链接的一个或多个。
6.如权利要求1所述的权利要求，其特征在于，所述管理组件查找、关联并提议接收文件的元数据，所述提议元数据包括表示所述提议元数据对应于所述接收文件的置信度的信息。
7.如权利要求6所述的权利要求，其特征在于，所述提议元数据的至少之一由用户手动选择或由所述管理组件自动选择，并与所述文件相关联。
8.如权利要求1所述的权利要求，其特征在于，所述管理组件解析接收文件与所述接收文件的起源之间的关联。
9.如权利要求8所述的权利要求，其特征在于，所述管理组件存储与所述接收文件相关的起源和解析关联。
10.如权利要求1所述的权利要求，其特征在于，所述管理组件使一个或多个分级与文件相关联。
11.如权利要求10所述的权利要求，其特征在于，所述一个或多个分级包括起源、质量、以及用户分级的一个或多个。
12.如权利要求10所述的权利要求，其特征在于，所述一个或多个分级与音频、电影、以及电视分级的一个或多个相关联。
13.如权利要求10所述的权利要求，其特征在于，所述一个或多个分级被用于在所述不同文件上查询。
14.如权利要求1所述的权利要求，其特征在于，所述管理组件保持已存储文件的历史。
15.如权利要求14所述的权利要求，其特征在于，所述文件历史被用于智能决策以自动化对文件的执行、处理和访问的至少之一。
16.如权利要求1所述的权利要求，其特征在于，所述管理组件生成视频的一个或多个子部分，所述子部分与所述视频的相应部分相关联并用来返回到所述视频的相应部分。
17.一种基于模式管理不同音频和视频数据的至少之一的文件系统，其特征在于，包括
具有存储其上的模式的一模式库；以及
一数据管理组件，它利用所述模式来便于保存、处理并检索来自数据存储的不同音频和视频数据的至少之一。
18.如权利要求17所述的系统，其特征在于，所述模式包括媒体、音频、和视频模式的至少之一。
19.如权利要求18所述的系统，其特征在于，所述音频和视频模式从所述媒体模式和项目模式的至少之一导出。
20.如权利要求17所述的系统，其特征在于，所述模式向应用程序开发者提供一种框架以任意生成在所述不同音频和视频数据的至少之一之间和之内统一工作的应用程序。
21.如权利要求17所述的系统被结合到一操作系统内。
22.如权利要求17所述的系统，其特征在于，所述模式提供对存储在所述数据存储内的不同音频和视频数据的至少之一的无缝标识、区分和访问。
23.一种多媒体平台，其特征在于，包括
一数据库；
多个与音频和视频数据相关联的模式；以及
一组件，它利用所述多个模式来系统地存储和访问所述数据库内不同音频和视频数据的至少之一。
24.如权利要求23所述的系统，其特征在于，所述多个数据库模式包括与所述不同音频和视频数据的至少之一相关联领域的特定属性。
25.如权利要求23所述的系统，其特征在于，还包括通过统计、概率、推断和分类器的一个或多个便于对所述不同音频和视频数据的至少之一的存储和访问。
26.如权利要求23所述的系统，其特征在于，所述智能被用户配置成定义确定自动化程度的置信度。
27.一种便于音频和视频文件管理的API，其特征在于，包括
从应用程序接收不同音频和视频数据的至少之一；
获取与所述接收数据相关联的模式；以及
基于所述关联模式来系统地存储并管理所述接收数据。
28.如权利要求27所述的API，其特征在于，基于媒体、音频、和视频模式的一个或多个生成。
29.如权利要求27所述的API，其特征在于，被应用程序开发者用来任意创建在已存储数据之上和/或之内统一工作的应用程序。
30.如权利要求27所述的API被用于一应用程序。
31.一种模式化音频和视频文件的方法，其特征在于，包括
接收一音频或视频文件；
确定所述文件类型；
获取与所述被标识类型相关联的模式；以及
基于所述模式将所述文件存储在文件系统内。
32.如权利要求31所述的方法，其特征在于，还包括接收对已存储文件的请求并利用所述模式来查找并返回所述文件。
33.一种基于模式的丰富多媒体系统，其特征在于，包括
一模式集；以及
一组件，它利用所述模式集来管理数据库内的不同音频和视频数据。
34.如权利要求33所述的系统，其特征在于，所述模式集包括一媒体模式，它包括以下类型的一个或多个EffectiveBackCoverArt；EffectiveFrontCoverArt；MetadataProviderLogo；Document；MetadataLifecycle；ContentDistributor；ContentDistributorData；History；Rating；CustomRating；StarRating；URLReference；MVString128以及MVString256。
35.如权利要求34所述的系统，其特征在于，所述Document类型是一项目类型。
36.如权利要求34所述的系统，其特征在于，所述MetadataLifecycle类型是一扩展类型。
37.如权利要求34所述的系统，其特征在于，所述ContentDistributor、EffectiveBackCoverArt、EffectiveFrontCoverArt以及MetadataProviderLogo是关系类型。
38.如权利要求34所述的系统，其特征在于，所述ContentDistributorData、History、Rating、CustomRating、StarRating、URLReference、MVString128、以及MVString256类型是嵌套类型。
39.如权利要求33所述的系统，其特征在于，所述模式集包括一视频模式，它包括以下类型的一个或多个Clips；VideoRecord；RecordedTV；VideoClip；以及VideoSubShot。
40.如权利要求39所述的系统，其特征在于，所述VideoRecord、RecordedTV、以及VideoClip类型是项目类型。
41.如权利要求39所述的系统，其特征在于，所述Clips类型是一关系类型。
42.如权利要求39所述的系统，其特征在于，所述VideoSubShot类型是一嵌套类型。
43.如权利要求33所述的系统，其特征在于，所述模式集包括一音频模式，它包括以下类型的一个或多个RadioStationLogo；RadioStationStreams；Listeners，ListenedTrack；CachedAlbum；anAudioRecord；Track；CachedTrack；PlatterTrack；PlayList；RadioStation；RadioStream；ListeningHabits；Listeninghabitslog；ArtistInformation；TrackAlbum；SuggestedMetadata；RadioStationContentDistributor；RadioStationLocation；AutoDJ以及PlayCounter。
44.如权利要求43所述的系统，其特征在于，所述CachedAlbum、AudioRecord、Track、CachedTrack、PlatterTrack、PlayList、RadioStation、RadioStream、ListeningHabits以及Listeninghabitslog类型是项目类型。
45.如权利要求43所述的系统，其特征在于，所述ArtistInformation类型是扩展类型。
46.如权利要求43所述的系统，其特征在于，所述TrackAlbum、SuggestedMetadata、RadioStationContentDistributor、RadioStationLocation、RadioStationLogo、RadioStationStreams、Listeners、以及ListenedTrack类型是关系类型。
47.如权利要求43所述的系统，其特征在于，所述AutoDJ和PlayCounte类型是嵌套类型。
48.一种在两个或多个计算机组件之间传送的便于计算机系统内不同音频和视频数据的管理的数据包，其特征在于，包括
接收音频或视频数据的一组件、获取与所述接收数据相关联的模式的一组件、利用所述模式来系统地存储所述数据的一组件、利用所述模式来管理所述已存储数据的一组件。
49.一种存储文件管理系统的计算机可执行组件的计算机可读介质，其特征在于，包括
一模式库，它存储丰富的基于音频和视频的模式集；
一接口；以及
一组件，它通过所述接口接收音频和视频数据的至少之一，并从所述模式库获取管理所述接收数据的关联模式。
50.一种基于音频/视频存储并检索音频和视频文件的音频/视频管理系统，其特征在于，包括
一装置，用于接受音频和视频文件；
一装置，用于获取与所述音频和视频文件相关的模式；以及
一装置，用于利用所述模式来管理在数据库内的所述音频和视频文件。
全文摘要
本发明提供一种新颖的文件管理方法。该系统和方法包括可被结合到操作系统中以向应用程序开发者提供一种有效和功能强大的实用程序来建立应用程序的一种基于模式的文件管理技术。另外，系统和方法提供在操作环境内不同数据(例如音频和视频数据)上统一采用的应用程序。模式可包括与已知数据类型相关的基本模式，以及相对数据的一个或多个特征扩展基本模式的导出模式。模式可用于生成可由用户和/或应用程序使用来与文件系统交换信息的API。此外，系统和方法可包括可用于执行动作和/或作出决策的可配置智能，它可使过程自动化和/或便于数据存储和/或管理。
文档编号G06FGK101099148SQ200480003241
公开日2008年1月2日 申请日期2004年7月26日 优先权日2003年10月23日
发明者K·斯里尼亚斯, D·普拉斯蒂纳, A·E·瓦斯齐罗, C·K·布劳内尔, J·W·特雷尔 申请人:微软公司