CN101490680B

CN101490680B - 全局资产管理

Info

Publication number: CN101490680B
Application number: CN2007800264900A
Authority: CN
Inventors: M·J·多纳赫; M·D·伍德; S·M·弗里尔; G·L·马泽
Original assignee: Eastman Kodak Co
Current assignee: Apple Inc
Priority date: 2006-07-12
Filing date: 2007-07-12
Publication date: 2012-08-29
Anticipated expiration: 2027-07-12
Also published as: US20090030952A1; WO2008008448A3; EP2038778A2; WO2008008448A2; CN101490680A; JP2009544070A

Abstract

一种用于在装置、服务器和系统之中通过提供用户的数字资产的逻辑统一且聚集的视图来管理数据的系统和方法，该用户的数字资产包括源自任何系统节点或装置的元数据。本发明描述了通过使用清单来支持聚集的视图的方法。清单是包括关于用户的虚拟集合内的所有媒体资产的数据的文件/数据库。

Description

全局资产管理

相关申请的交叉引用

这是2006年7月12日提交的临时申请序号60/830,241的11A申请。

技术领域

本发明涉及用于在装置、服务器和系统之中管理数据的体系结构、服务和方法。本发明尤其涉及提供用户的包括源自任何系统节点或装置的元数据的数字资产的逻辑统一且聚集的视图(aggregated view)。

背景技术

数字资产包括被创建和下载到个人计算机(PC)存储器用于个人娱乐的图像、视频和音乐文件。典型地，这些数字资产当需要看、听或播放时被访问(access)。包括个人数字助理(PDA)、数字相机、个人计算机(PC)、媒体服务器、终端和网站在内的各种装置和因特网服务提供和利用这些资产。存储在这些装置或服务提供商上的资产的集合通常是松散耦合的，并且当前的同步过程一般在两个装置之间发生，例如媒体播放器和PC。采用松散耦合装置和服务的此环境的问题是任何装置或服务对数字资产的可访问性，需要维持多个登录、资产同步、无序和数据丢失。见于各种分布式数据库系统和专用的同步程序中的现有技术已经不同程度上成功地试图解决了这些问题。

发明内容

本发明的目的是通过提供聚集的视图(跨一个或多个节点)以及对所拥有和共享的所有媒体资产的访问来解决上述提及的问题中的若干问题。用户拥有或共享的所有数字/媒体资产被称为用户的虚拟集合。本发明描述了使用清单来支持虚拟集合的方法。清单是包括关于用户的虚拟集合内的所有媒体资产的数据的文件/数据库。支持虚拟集合的系统体系结构被定义为包括若干用于创建和维持虚拟集合的方法。

本发明的另一方面是数据结构、资产id和支持虚拟集合的组织。根据用户媒体生态系统(ecosystem)中的数字资产和装置增长的数目，为了良好的性能而设计了这些机制。版本矢量是用于复制数据库的公知技术，其已经以唯一的方式被应用于对虚拟集合进行管理。

本发明的另一方面包括用于将装置/集合增加到用户的虚拟集合以及将装置/集合从用户的虚拟集合去除的简单且有效的方法。此外，该体系结构和系统提供了用于恢复丢失数据和用于跨装置自动冗余的改进方法以改善可靠性和可用性。本系统使得能够对跨多个装置存储的媒体资产进行自动存档并跟踪CD/DVD名称和内容，以及提供自动增量更新。

附图说明

图1-用户的媒体生态系统。

图2-系统体系结构。

图3-用于虚拟集合的协调(reconciliation)的组件。

图4-用于资产库管理的组件。

图5-XML清单。

具体实施方式

已经特别参考本发明的特定实施例对本发明进行了详细描述，但应当理解的是，在本发明的精神和范围内可以实现变化和修改。

定义

资产-包括图片/静态图像、电影/视频、音频或多媒体表现的数字文件。对于每种类型的资产来说存在许多标准格式。

所有者-每个资产都有所有者。所有者负责组织和管理他们的资产。所有者可允许他人查看或者甚至修改他们所拥有的对象，但他们独自负责对所拥有的资产的访问进行控制并且另外对所拥有的资产进行管理。

集合-人们可看见的图像和其它资产的整个集。

个人集合-人们所拥有并管理的资产集被称为他们的个人集合。这些资产中的一些可以与其它个体共享，在这种情况下它们成为那些个体的扩展集合的一部分。它们仍被认为是所有者的个人集合的一部分。

扩展集合-人们所拥有的或者另外包括其它人或组具有的与他们共享的资产集的总资产集被称为他们的扩展集合。

管理集合-集合的所有者具有组织或另外重新布置所包含资产的逻辑视图以适合其自己的个人口味的能力。出于共享目的管理者具有向其它人授予不同的访问等级的职责。

GAM-全局资产管理(global asset management)。

再现(Rendition)-对预期呈现相同幻影(illusion)的用户透明地生成并维持的图像的内部表示(例如，系统将抽取图像的十分之一来在较低分辨率的装置上呈现相似视图)。这是为了系统的便利。

综述

随着数字摄影的到来和普及，用户以越来越多的方法来拍摄和使用越来越多的数字图片和视频。众多装置、系统、网络和服务已被创建，并已建立了所谓的用户的媒体生态系统。图1图示了用户的媒体生态系统10的各组件，该用户媒体生态系统10包括三个主要集线器或节点：用户的家庭媒体环境20、在线相片服务30和移动装置40。用户的家庭媒体环境20包括通常见于家庭中的媒体装置和网络，包括电视21、家庭办公PC 24、膝上型计算机22、打印机23和媒体盒(media box)25。媒体盒23一般连接至电视21并且提供用于观看的有线TV频道。媒体盒23还可以是家庭网络的一部分，该媒体盒23使得存储在家庭PC 24或膝上型计算机22上的媒体资产能够在家庭电视21上观看。用户的媒体生态系统10的另一主要节点包括经由因特网访问的在线相片服务30。家庭媒体环境20一般能够经由宽带或拨号连接连接到因特网。用户可访问经由PC选择的在线相片服务30，在该PC，经由因特网数字资产可以被上传、被存储于在线相片服务30服务器上、作为多种输出物的一部分被打印并且被与其它用户电子共享。移动装置40构成了用户的媒体生态系统10的第三主要节点并且包括诸如数字相机和照相手机之类的移动装置。所述装置允许用户位于任何地方来拍摄和查看图片。这些移动装置时常提供到用户的家庭媒体环境20中的装置和在线相片服务30的通信方法。照相手机能够经由至将数据桥接到在线相片服务30的相片服务的无线连接而连接到在线相片服务。在用户的媒体生态系统10内，用户可以拥有若干可以存储和访问数字资产的装置。本发明提供了一种自动和分布式系统，在该系统消费者在不具体知道这些资产驻留于哪个节点或如何检索它们的情况下，能够在任何时间并且从系统中的任何参与节点访问、查看、修改和使用源自其集合的资产具体。这种系统被称为全局资产管理(GAM)系统。用户拥有存在于一个或多个计算机、家庭设备、移动装置或在线服务上的数字资产(图像、视频等)。在优选实施例中，GAM系统提出了逻辑上统一、聚集的视图或“虚拟集合”的范例，所述视图或“虚拟集合”包括用户所知道的所有资产的元数据。在可替换实施例中，虚拟集合仅由所有资产的子集的元数据所构成会是有用的；如果集合非常大，会希望这样。GAM系统是自动分布式系统，在该系统，用户在不具体知道这些资产存在于哪个节点或如何检索它们的情况下，能够在任何时间并且从系统中的任何参与节点访问、查看、修改和使用源自他们的虚拟集合的资产。它提供了三种基本功能：访问、聚集和存留(persistence)。访问是指查看数字资产和位于远程连接的节点的相关元数据的能力。聚集是指将分布式资产的视图混合成独立于物理资产分布的整个集合的单个“虚拟化”视图的能力。存留是指当连接改变以及节点连接和断开连接时保持此虚拟化视图的记忆(memory)的能力。

图2图示了用于全局资产管理相片系统的系统体系结构100。在线服务110节点包括资产库112、资产集合数据库111和GAM服务113集。资产集合数据库111是包含定位用户图像集所必需的所有信息的数据结构。它并不包含图像本身，所述图像在资产库112中或者高速缓存113于装置上。资产集合数据库111维持用户简档(profile)信息、维持在分布式资产库内定位数字资产的映射、维持以各种容器(container)的形式呈现数字资产的用户视图。资产库112是对数字资产的物理的、持久存储器。在资产集合数据库111中资产库中的所有图像都有参考(reference)。资产库112可包括简单文件系统或例如通过标准OS级别的机制访问的另一外部数据存储器。资产高速缓存器131是数字资产的临时存储器，已被GAM连接服务选择性地扩充(populate)以减少延迟并且通常促进在特定装置上容易访问。高速缓存的图像在资产集合数据库111中不被跟踪(track)。

在本地节点上的集合的目录结构可被实现在文件系统内以及用数据库来实现。关于集合的知识自身是被称为清单的资产，所述清单能够在节点之间交换。清单描述对集合内容进行组织的容器对象(例如相册、事件)并且为与每个容器相关联的资产项目(例如，图像、视频)提供参考，从而允许应用对(例如检索、复制)容器的数字内容进行操作。可采用开放式标准(例如，MPV，DIDL-Lite)来对清单进行编码以允许内容被定义并且在不同的产品之中传送。图5提供了样本清单文件的XML列表。

在可替换实施例中，节点可以将所有节点清单呈现为单独的分区(即不作为聚集的整体)。第二，节点不需要将源自另一节点的清单集成到其本地集合(即，不存留)中，这是因为用于该其它节点的分区仅在存在至它的网络连接时才被呈现。

此外，将通过“共享组”概念来支持用户团体。在GAM系统内好像共享组是虚拟人一样来处理它们。类似于将访问授予给个体，访问资产的许可也可被授予组。

这些节点之间的连接性将变化，一些大部分时间处于连接(“在线”)而一些则很少(“近线(nearline)”)。被系统跟踪的一些资产可处于档案中或其它“离线”位置或媒体中。GAM系统在所有情况下都提供对虚拟集合的最大访问。

除了简单查看资产集合外，用户会希望在各连接状态下对它们进行操作。他们将对它们进行改变、重组以及与他人共享。他们还想要通过将它们拷贝到可拆卸媒体同时在永久性记录中保留对它们的引用，来对个人或资产组进行存档。一些用户将利用系统的位置透明性(transparency)，而其它用户为备份、即时性(immediacy)或其它原因将想要通过在节点之间迁移资产来明确地对资产位置进行管理。当数字资产经历这些改变时，GAM系统对数字资产进行跟踪并且能够贯穿整个系统一致地且智能地传播这些改变。

该系统的主要组件包括连接服务，其负责监测GAM环境、识别协作节点并与它们共享数据。它负责共享GAM数据库更新、移动图像和其它资产并且通常提供如支持共享模型所需要的“后端”服务。GAM连接服务将负责在装置发现期间将特定节点的特性和能力公布给伙伴。

GAM系统包括将详细描述的若干组件。GAM系统的一个基本功能是在节点之间对清单的交换。为了访问远程节点的内容目录，协调服务返回远程节点的清单。清单中的元数据可通过便利交换的开放式标准予以编码。不要求应用将其它节点的内容加到它们的内容中，但应用应能够呈现分布于家庭内的内容的分区视图。

GAM系统能够提供用于所有节点上的内容的公共目录结构(即，聚集的视图)。该公共目录结构可驻留在文件(即像清单)中或应用数据库中。此外，GAM系统的所有节点可以当在家庭环境的任何地方进行改变时协调它们的内容并且记下(即存留)这些改变的效果。

图3在概念体系结构的层面描绘了相互作用的GAM系统组件和消息序列，该消息序列被交换以便经由清单协调来实现家庭内容的聚集和存留的视图。协调服务320可通过交换清单360获取所知在远程节点上的虚拟集合350。因此，不是仅将清单提供给应用340以作为在分区视图中的内容，协调服务封装了用于解释和解析(resolve)该清单版本的逻辑。为此，协调服务允许应用在启动时以及在定期调度时通过轮询远程节点将其虚拟集合的视图与家庭中的其它节点的视图相协调。对于发起协调(消息301、302、303)的节点来说，它发送对另一节点的清单的请求，接收另一节点的清单，对其所接收的清单进行解码，解析在其清单和其所接收的经解码清单之间的差异，并且使用数据访问服务来适当更新其虚拟集合的版本。对于对清单请求作出响应的节点(而其也可以发起与其它节点的协调)来说，它接收对其清单的请求，访问其虚拟集合的版本，对其清单进行编码(消息372)并发送其经编码的清单。

数据抽象层被应用调用以反映其虚拟集合的版本的本地改变。它也被协调服务调用以反映在经由其清单所接收的其它节点上的改变。为此，数据访问服务提供了允许节点读取与虚拟集合相关联的元数据的访问器(accessor)集(消息373、374)，并且提供了允许节点修改与虚拟集合相关联的元数据的增变器(mutator)集(消息305、307、375、374)。如果节点上的虚拟集合是应用数据库，则该应用可直接访问数据库以反映局部改变。

为了提高GAM系统的节点之间的信息交换的效率，可使用采用版本矢量的算法。当虚拟集合中的资产数增长时，被交换的清单的大小将增加。家庭中的网络带宽可能将整个清单的移动抑制到可看到性能下降的点。当新的节点进入家庭域时，整个清单将总是必须被引入。对于现有的节点来说，仅发送在虚拟集合内已改变的信息而不是其整个内容。版本矢量可被用在用于跨分布式节点复制资产元数据的算法中。

协调服务通过交换节点版本矢量获取已知在远程节点上的虚拟集合的改变。针对按调度发起协调的节点的协调服务发送对另一节点的版本矢量的请求，接收另一节点的版本矢量，对该节点版本矢量进行解码，解析在其对象(object)版本矢量和其通过请求更新的元数据从其它节点所接收的经解码的节点版本矢量之间的差异，并且使用该数据访问服务来适当地更新其虚拟集合。

对于正对版本矢量请求进行响应的节点(而其也可以从修改其所拥有的视图正生成版本矢量)来说，它接收对其节点版本矢量的请求，访问其虚拟集合，对其节点版本矢量进行编码，并且发送其经编码的节点版本矢量。

当对虚拟集合的内容做出改变时，数据访问服务更新对象版本矢量。数据访问服务更新与其元数据已被修改的对象相关联的版本矢量，并且在虚拟集合内将版本矢量保存为所修改的对象的扩展。

用户可在任何时间在任何节点查看全局集合的视图。由于版本矢量算法是优化的复制协议，所以对于任何两个节点i和j来说，在任何给定的时间瞬间，它们的数据库D_i和D_j可能不同，并且由此呈现给用户的视图可能不同。然而，假设，足够的时间、在i和j之间连续的连接性以及不存在进一步的更新，则D_i和D_j将会聚(converge)成相同的值。

复制算法使用单个版本矢量来表示数据库的每个实例的状态。此每个数据库的版本矢量提供了方便的机制，由此节点能够快速确定一节点是否需要与另一节点同步。此外，该算法将版本矢量与每个对象相关联。注意，版本矢量只不过是时间戳阵列，其中每个时间戳都是正整数。节点的逻辑时间被跟踪为整数值；在节点每次更新其数据库时节点使其逻辑计时器增加(increment)。

该算法假定以下情况：

1.对于包括数据库D_i的每个节点n_i来说，是相关联的版本矢量VV_i。

2.数据库D_i表示如节点n_i所知的每个对象的最新状态。特别地，D_i是四元组{id(obj)，value(obj)，vv，ts}的阵列，其中id(obj)是对象的全局唯一标识符；value(obj)是对象的值，vv是与对象相关联的版本矢量，而ts是VV_i[i]在对象的值被最后更新或添加到节点i的数据库时的值。

3.对于k＝i，VV_i[k]表示节点i的当前逻辑时间；VV_i[i]在i对其数据库D_i进行任何改变之前增加。

4.对于k≠i，VV_i[k]表示从节点k，直接在点i最后与k同步时，或者作为与某其它节点同步的结果间接接收的信息的最高逻辑时间戳。

5.对于相同长度的两个版本矢量v₁和v₂，当且仅当对于所有的i，1≤i≤length(v₁)，V₁[i]不大于或等于V₂[i]时，v₁＜v₂；当且仅当对于所有的i，1≤i≤length(v₁)。V₁[i]不小于或等于V₂[i]时，v₁＞v₂；当且仅当对于所有的i，1≤i≤length(v₁)，V₁[i]＝V₂[i]时，v₁＝v₂；否则这两个版本矢量被称为不可比的。

换句话说，如果第一版本矢量的每个元素(element)小于或等于第二版本矢量的相应元素，则一版本矢量小于或等于另一版本矢量；使第一版本矢量严格小于第二版本矢量增加了第一版本矢量中的至少一元素严格小于第二版本矢量的相应元素的需求。如果两个版本矢量不可比，则这两个相关联的对象被同时更新，并且它们的值可能冲突。这种冲突的解决可能要求用户干预。

6.如以下算法中所描述的，维持与每个对象相关联的版本矢量；其与对象被最后更新的逻辑“时间”对应。

7.每个节点n_i维持节点S_i集；这表示当前的节点n_i集被认为是系统的一部分并且其与所述系统同步。

为执行同步操作，节点i执行如下：

mutexBegin(syncing)

for x＝1 to length(S_i){

d←S_i[x]

requestVersionVector(d)//ask node d for its version vector

VV_d←rcv Version Vector()//receive VV_d

if VV_i[d]＜VV_i[d]then

requestUpdaces(d，VV_i)

}

mutexEnd(syncing)

注意，如果VV_i[d]小于VV_d[d]，则自节点i最后与节点d通信以来节点d已经改变了其数据库。这可因为节点d已独自更新了一个或多个对象，或者因为节点d已接收了源自某其它节点的更新而发生。在互斥模块内执行该操作以在同步过程期间防止本地更新发生，并且在节点对另一节点的同步请求进行响应的同时阻止节点试图与另一节点同步。

方法requestUpdate如下执行：

requestUpdates(d，VV_i){

sendRequest(d，i，VV_i)

do{

getUpdate()

}while not AllUpdatesReceived and not timedOut

if allUpdatesReceived{

//update our complete VV to reflect the updates made by other nodes that we

//received via node d.

VV_d←rcvVersionVector()

for x＝1 to length(VV_i){

if VV_d[x]＞VVi[x]then{

VV_i[x]←VV_d[x]

}

方法requestUpdate向节点d发送更新请求，指定它想要自时间戳VV_d[i]以来已经发生的所有更新。然后它每次一个更新地接收它们。一旦已接收了所有更新，就更新本地版本矢量使得所有元素至少与它们在节点d的版本矢量中一样高。通过执行此更新，该节点将能够从其它节点仅仅接收其所需要的新的更新。然而，如果更新过程被过早终止，则本地节点不能执行该步骤。

一旦接收到sendRequest所生成的消息，接收者(recipient)就执行：

receiveRequest(recipient，requestor，VV){

sendUpdates(requestor，VV)

}

接收者所执行的方法sendUpdates实现以下：

sendUpdatcs(requestor，VV){

mutexBegin(syncing)

i←myId() //i here refers to the local recipient node，the one sending the updates

foreach obj in D_i{

if obj.ts＞VV[d]and not(obj.vv≤VV)then

updateSet←updateSet+obj

}

sort(updateSet)//sort by obj.ts

foreach obj in updateSet{

sendUpdate(requestor，i，obj)

}

sendVersionVector(requestor，VVi)

mutexEnd(syncing)

}

sendUpdates使用互斥(mutex)来避免必须管理在过去的更新正被传送时发生的本地更新的复杂性。发送者仅考虑obj.ts大于该节点的请求者的版本矢量项(entry)的那些对象；这些是自该节点与请求者最后通信的时间以来已潜在地改变的对象。obj.ts值的目的是优化确定可能需要被发送给另一节点的候选对象的过程。时间戳是简单的标量值并且与全版本矢量相比可能高效得多。

发送者实际上仅将其版本矢量不小于或等于请求节点的版本矢量的那些对象发送给请求者；这防止了发送者把接收者已经从其它节点接收的数据进行发送。该更新按照其时间戳的次序被发送。这是为了确保如果一个或两个节点在传输过程期间崩溃，且其随后重启，没有更新被丢失。特别是，对于发送者来说，接收者的版本矢量项将与其已接收的最高更新相对应。

为了改善性能，sendUpdate可能对更新进行缓冲并且用更大的组来发送它们。一旦所有的更新都已被发送，节点然后发送其当前的版本矢量。该版本矢量自节点响应于对其版本矢量的原始请求而已发送其版本矢量的时间以来可能已予以提升(advance)。

通过方法getUpdate来接收更新，该getUpdate调用receiveUpdate来读取下一个传送的更新：

getUpdate(){

receiveUpdate(i，d，obj)

doUpdateObject(obj，false)

else if(obj.vv＞D_i[obj.id].vv)then

doUpdateObject(obj，false)

else if(obj.vv≤D_i[obj.id].vv)then

//continue to use my local value；it’s more recent

else

//we have a conflict

status←resolveConflict(obj)

VV_i[d]←obj.ts

}

首先检查所接收的更新以确信它们不与本地改变相冲突。如果所接收的对象的版本矢量值严格大于本地对象的版本矢量，则所接收的值是更新的；本地节点必须将其值更新成该值。通过调用具有被指定为false的第二参数的doUpdateObject，doUpdateObject将保存对象的版本矢量。这将防止节点不必要地将该对象的值发送给已经看到该更新的节点。相反，如果所接收的对象的版本矢量小于或等于本地对象的版本矢量，则本地节点不需要更新其对象拷贝。正常情况下，由于发送者一般不试图发送这种对象，所以这种情况不应发生，但是如果一节点在中止的(aborted)先前更新操作之后请求源自另一节点的更新则其可能发生。如果两个版本矢量是不可比的，则所述值冲突，并且必须使用冲突解析器(resolver)来解析冲突。函数resolveConflict试图自动或经由用户干预来解析冲突。

resolveConflict(obj){

if conflictIsResolveable(obj)then

obj.vv←pairwiseMax(obj.vv，Di[obj.id].vv)

doUpdateObject(obj，true)

return true

else

return false

}

如果该冲突是可解析的，则该版本矢量被设置成两个版本矢量的成对的最大值，其中该节点的版本矢量中的项随后增加，因此所解析的值将被传播给其它节点。

通过doUpdateObject来实现实际更新：

doUpdateObject(obj，updateObjVV){

VV_i[i]++

if(obj ∈D_i)then

D_i[id].value←obj.value

D_i[id].vv←obj.vv

D_i[id].ts←VV_i[i]

else

D_i←D_i∪{obj.id，obj.value，obj.vv，VV_i[i]}

if(updateObjVV)then

D_i[id].vv←VV_i[i]

}

本地节点时间戳VV_i[i]总是增加，并且该对象的时间戳总是被设置成该值。该对象的版本矢量可能或不能被更新，这取决于标志updateObjVV的值。如果正简单地用从另一节点接收的对象的值更新数据库，则该对象的版本矢量不被更新——该节点简单地保存相关联的版本矢量。否则会导致该对象被视为已被本地改变更新——必须被向回传播到包括发送所改变的值的那个节点在内的其它节点的那个。

然而，如果更新是冲突解析的结果，则版本矢量被更新。

本地更新被以下处理：

localUpdateObject(obj){

mutexBegin(synching)

VV_i[i]++

D_i[id].value ←obj.value

D_i[id].vv←VV_i

D_i[id].ts←VV_i[i]

mutexEnd(synching)

}

该算法有意在本质上是单向的(one way)；为了在两个节点之间出现完全同步，每个节点将分别运行该算法。当节点重新连接到其它节点的网络时，它必须与每个其它节点联系以获得所有未决的(pending)的更新。对于消费者成像应用来说，节点数目很可能小，并且因而期望这不是重大问题。

如果用户在两个不同节点上更新相同的资产并且系统不能运行在更新之间的该协议，则可能出现冲突。在这种情况下，冲突将在算法运行时被检测。注意，我们本来能够与每个资产的元数据字段(field)单独的版本矢量相关联，而不是仅具有该资产的单个版本矢量。如果系统明了处于元数据水平的版本，则用户会能够在不引起冲突的情况下更新相同资产的不同元数据项。

尽管版本矢量已被广泛地用于消息传递系统中并且用于实现经复制的数据库，但是它们还尚未被点对点的文件共享所采用。该算法使用版本矢量向端用户提供对其内容的位置透明的访问。用户可从他们的家庭媒体服务器、无线相机或其它便携式装置或者通过在线服务来访问和管理他们的内容。尽管用户并非总是可以获得高分辨率的资产再现，但是该方案允许用户执行以下普通操作：浏览、导航和组织他们的集合，并且查看系统实施者(implementer)或用户已选择复制的、低分辨率再现的资产。

图4描述了相互作用的GAM组件和被交换以便实现数字资产操作和在节点之间的移动(即检索操作)的消息序列。

在用户的家庭环境中的节点上运行的应用必须能够检索、更新、存储和拷贝数字资产而不管相应的文件驻留在的节点。资产访问服务440接受来自应用460的请求以对数字资产执行操作，包括：检索以便编辑或打印(消息401)、在编辑和保存之后更新、在增加或编辑并保存为(save as)之后存储、拷贝、围绕对用户的应用上的数据访问服务的使用控制逻辑(消息408-409)、定位在虚拟集合中的数字资产的一些再现，并且将库服务430用于位于虚拟集合470之外的数字资产的再现。库服务430提供了对位于存储服务器上的数字资产的详细目录(inventory)的访问。它还表示接收者节点上可能需要远程满足对数字资产的请求的组件。对于发起数字资产管理的节点来说，库服务430接受管理数字资产的请求(消息420)、满足对用户的应用节点的一些请求(即检索、更新、存储)，并且通过访问家庭环境中的另一节点来满足其它请求(即检索、复制)(消息404-405)。

如果从另一节点接收了数字资产文件，库服务就存储资产文件并且更新其虚拟集合(消息403、409)。

对于对数字资产管理请求进行响应的节点来说，它接受管理数字资产的请求、查找该数字资产(消息494、405、491)并且将该数字资产文件转送给请求节点(消息492-493)。存档、备份和恢复服务使用库服务来支持它们在节点内和在节点之间移动数字资产。

节点需要在协调和资产移动期间向其它节点发送请求并且从其它节点接收回复。消息抽象层使得理解传输细节的责任与协调服务和库服务相分离。随后，消息抽象层能够使其传输绑定与对于节点间通信所要求的格式和协议(例如，套接字(socket)、FTP、web服务)相适配。消息服务代表想要与其它节点交换内容的发送节点传送请求并且代表必须返回所请求的内容的接收节点接收消息。

任何给定节点将理解其自身属性，但将在其域内发现其它节点并且动态地请求它们的简档。连接服务通过简档来识别关于节点的信息。节点简档是元数据模型中的实体并且在请求时被交换。节点简档仅通过节点定义了已知的静态属性、先验知识(priori)。这些属性包括服务和能力(例如，与清单一起存储节点)以及如何联系它(例如，协议、凭证)。

GAM系统可在安全之内结合(incorporate)若干领域，包括全局用户帐户、对跨用户和组的数字资产的访问控制(即，权限)和当信息在节点之间移动时交换信息的保护。

事件服务提供存档和备份/恢复功能。在防护系统(safeguard againstsystem)未能释放空时或其它原因时，备份和存档操作将对数据库和数字资产进行拷贝。

存档是指将数字资产移动到某可靠的可能“离线”的存储媒体以确保资产的拷贝在所有时间持久可用的动作。在随后的某时间能够检索该资产，一种通常要求特殊的操作和常常手动的用户干预的操作。离线资产的位置将在资产数据库中被永久跟踪。任何存档的资产信息将被保留，即使所述资产被另一版本取代的情况也是如此。存档操作能够跨节点进行。用户能够通过从应用内的明确动作来将存档的资产向回移动到该系统中。

相反，出于在系统故障之后恢复集合的具体目的，备份将对用户的集合(数据库和库内容二者)的某部分进行拷贝。实际上上，它是在给定时间点的节点的“快照”。备份集中的资产对正常操作将是不可访问的，而存档的资产将按其原始上下文予以保留。由于用户的集合能够跨若干节点，所以备份整个集合将是艰巨的工作。因此，备份将在逐个节点(node-by-node)的基础上进行操作。然而，通过使用“自动拷贝”，用户将能够建立他们的系统使得单个资源丰富的节点能够用作所有资产的集合点。备份该节点将具有备份用户的整个集合的效果。用户将能够基于GAM所支持的标准组织方案和备份装置来选择备份间隔、完全或增量备份以及备份范围。所备份的资产(数据库内容或数字资产)将具有其最后的备份时间和记录在GAM数据库中的数据。在备份之后，恢复操作将通过目标节点上的任何GAM信息来拷贝备份集，将其恢复到其在备份时间处的确切状态。

还应当理解的是，本发明并不局限于特定图示的实施例，并且在不脱离本发明的范围的情况下可进行各种修改和改变，本发明由所附权利要求书来限定。

部分列表

10-用户的媒体生态系统

20-用户的家庭媒体环境

21-电视

22-膝上型计算机

23-打印机

24-办公PC

25-媒体盒

30-在线相片服务

40-移动体

41-数字相机

42-手机(phone cam)

100-系统体系结构

110-在线服务

111-资产集合数据库

112-资产库

113-GAM服务

120-家庭系统

130-消费者手持装置

131-资产高速缓存器

140-零售服务

150-后端办公(back office)支持

160-基本服务

170-额外付费服务

180-元数据交换方案

300-节点1

301-协调视图(view)

302-检查节点

303-请求清单

304-创建和发送清单

305-改变视图

306-数据访问请求

307-虚拟集合更新

310-连接服务

320-协调服务

330-数据访问服务

340-家庭应用

350-虚拟集合

360-集合清单

370-节点2

371-连接服务请求

372-创建和发送清单

373-获得视图请求

374-虚拟集合更新

375-改变视图请求

376-协调请求

400-节点1

401-检索请求

402-获得资产

403-放置文件

404-检查节点请求

405-请求文件

406-资产文件检索

407-放置信息

408-获得信息请求

409-访问/更新虚拟集合

410-文件存储

420-连接服务

430-库服务

440-资产访问服务

450-数据访问服务

460-家庭应用

470-虚拟集合

480-资产文件

490-节点2

491-获得文件请求

492-检查节点请求

493-发送资产文件

494-获得信息请求

495-获得信息请求

496-读虚拟集合请求

497-资产访问请求

Claims

1.一种用于在网络中管理用户的资产的系统，包括：多个节点，每个节点都具有同样的存储在该节点中的资产集合数据库以及存储在该节点中的相应的清单，所述资产集合数据库具有针对用户的每个资产的项，并且所述清单具有针对所述资产的项，资产集合数据库和清单里的每个项包括关于所述资产和所述资产的位置的元数据。

2.如权利要求1所述的系统，其中所述多个节点耦合于通信网络中。

3.如权利要求1所述的系统，其中节点包括家庭环境中的装置、在线相片服务或移动装置。

4.如权利要求3所述的系统，其中家庭环境中的装置包括电视、个人电脑、打印机、PDA、照相机或媒体盒。

5.如权利要求1所述的系统，其中资产包括静态图像、视频、音频或多媒体表现。

6.一种用于对网络上所提供的多个节点中每个节点中所存储的资产集合数据库进行更新的方法，每个资产集合数据库具有与用户所拥有的每个资产相对应的项，所述项描述关于所述资产和每个资产的位置的元数据，所述方法包括步骤：

建立从第一节点到第二节点的通信连接；

从所述第二节点提供其清单的版本矢量，所述清单包括针对所述资产的节点项，所述节点项描述有关其相应资产和其相应资产的位置的元数据，所述版本矢量包括清单的更新；

根据所述版本矢量对所述第一节点的资产集合数据库进行修改。

7.如权利要求6所述的方法，其中所述多个节点耦合于通信网络中。

8.如权利要求6所述的方法，其中节点包括家庭环境中的装置、在线相片服务或移动装置。

9.如权利要求8所述的方法，其中家庭环境中的装置包括电视、个人电脑、打印机、PDA、照相机或媒体盒。

10.如权利要求6所述的方法，其中资产包括静态图像、视频、音频或多媒体表现。

11.如权利要求6所述的方法，其中每个节点的清单还包括针对与每个资产相关联的一个或多个元数据项目的不同的项，并且其中额外的版本矢量与每个项相关联，并且其中所述版本矢量被用于确定来自所述第二节点的清单的哪些更新应被应用到所述第一节点的清单。

12.如权利要求6所述的方法，其中将所述第二节点的版本矢量与所述第一节点的清单的版本矢量相比较以确定所述第一节点的清单是否需要被更新。