用于分发文件的栅格网络的制作方法

专利名称：用于分发文件的栅格网络的制作方法
专利说明用于分发文件的栅格网络
背景技术：
这里将媒体所有者定义为那些拥有媒体内容的所有权的人，所述媒体内容诸如电影、电视、软件、书和音乐，目前还没有发现能够使用因特网的完全潜力来安全地、低成本、高质量的并且利用有效货币化的规则来广播他们的媒体的技术系统。继续需要“端到端系统”(即交付者到消费者)以具有有效的货币化规则和高安全性的低成本、交付网络来管理网络中可能的成千媒体所有者和成百万的用户。
目前，许多媒体所有者将电影文件和音频文件从网站或流服务器经由因特网“直接流动”到终端用户。这些文件，特别是视频文件，由于它们的数据的复杂特性而非常大。这类直接流动对于硬件和带宽成本都比较昂贵。另外，海量流动，例如同时直接流动到一百万用户，不只要求非常强大的企业硬件簇，而且消耗一百万次流动单个电影的带宽成本。
另外，与其它出口(outlet)(例如web入口，在线商人等)合作以提供媒体内容给终端用户的媒体所有者经常在每个联合组织(syndication)交易上花费谈判的精力和金钱，这造成对有利的联合组织的障碍。如果媒体所有者有权简单的配置、控制和管理联合组织系统，并且出口合作者可能更容易的使用和配置该联合组织，则媒体能够更容易分发，并且媒体所有者能控制货币化。
其它挑战涉及媒体编码和终端用户播放。对来自发起源或拷贝的媒体的编码是劳动和设备密集的，这导致高成本。另外，电影和音频播放器技术通常由有兴趣将诸如操作系统的其它软件和他们的播放器技术一起出售的商业实体发展和控制。因此，需要与操作系统平台无关并且设计为能在任何操作系统上作业(或者不要求操作系统)的媒体播放器，从而能够在个人计算机、机顶盒、博弈控制台、嵌入系统和蜂窝电话中使用。



通过附图中的例子说明本发明。应该理解附图是说明性的而不是限制性的。
图1提供了栅格网络的实施例的图示。
图2提供了媒体库(media vault)的实施例的图示。
图3提供了编码译码器的实施例的图示。
图4提供了联合组织馈给的实施例的图示。
图5提供了地理定位的超节点的实施例的图示。
图6提供了编码工作室(studio)的实施例的图示。
图7提供了媒体播放器的实施例的图示。
图8提供了客户端的实施例的图示。
图9提供了超节点协议的实施例的图示。
图10提供了用于播放来自栅格网络的电影文件的过程的实施例的图示。
图11提供了栅格系统的实施例的图示。
图12提供了在对数据文件请求的响应中使用的包的实施例的图示。
图13提供了作业券(job ticket)的实施例的图示。
图14提供了加密媒体文件的过程的实施例的图示。
图15提供了使用加密的媒体文件的过程的实施例的图示。
图16提供了媒体文件的实施例的图示。
图17A提供了媒体文件的段(segment)的实施例的图示。
图17B提供了媒体文件的哈希值(hash value)的实施例的图示。
图18提供了栅格网络的实施例的图示。
图19提供了请求媒体文件的过程的实施例的图示。
图20A提供了辅助请求媒体文件的过程的实施例的图示。
图20B提供了其中私有客户端辅助公共客户端的栅格网络的实施例的图示。
图21提供了实施例中的一组文件的图示。
图22提供了实施例中以期望格式提供文件的过程的图示。
图23提供了共享文件的系统的实施例的图示。
图24提供了实施例中接收文件流的过程的实施例的图示。
图25提供了紧急性表示的实施例的图示。
图26提供了栅格网络的实施例的图示。
图27提供了加密保护的实施例的图示。
图28提供了栅格网络实施例中的客户端实施例的图示。
图29提供了栅格网络的另一个实施例的图示。
图30提供了播种栅格网络的方法的实施例的图示。
图31提供了被播种的栅格网络的实施例的图示。
图32提供了可以用于实现栅格网络的网络的实施例的图示。
图33提供了栅格网络中可以使用的机器的实施例的图示。
图34提供了网络实施例中的客户端的实施例的图示。
图35提供了网络实施例中的服务器的实施例的图示。

具体实施例方式 提供了用于分发文件的栅格网络的系统、方法和设备。该文档中所述的特定实施例表示本发明的实例，并且是说明性的而不是限制性的。不同实施例提供了用于端到端生产、使用-权限、数字权限、编码、压缩、内容管理、货币化联合组织、栅格网络交付和轻便播放器技术的系统。其它实施例可以提供这些功能的子集，并且可以提供其它功能。数字媒体交付潜在地可以通过如下措施提供，通过从分布式的每个播放器应用(本质上是每个客户端)形成和构成能够接收和重新发送数字媒体段的节点。联合的内容馈给可以允许内容供应商方便地将整个数字文件的库出售给分发合作者。一些实施例还提供对数字电影的编码和压缩，和管理加密的媒体文件的下载和共享的客户端技术。数字权限管理可以嵌入在这样的端到端平台的所有层中。
在实施例中，提供了一种系统。该系统包括具有验证功能的与网络耦合的第一服务器节点。该系统还包括具有完整文件的储藏库(repository)并且也与网络耦合的第二服务器节点。该系统进一步包括与网络耦合的一组客户端节点，该客户端节点具有本地文件储藏库。该客户端节点配置为通过该网络在对等(peer-to-peer)基础上共享完整文件的段。
在另一个实施例中，提供了一种方法。该方法包括通过对等连接从第一客户端请求媒体文件的段。该方法还包括在该请求中提供第一已验证的作业券。该方法也包括只要该第一已验证的作业券维持有效就通过对等连接从第一客户端接收媒体文件的段。
在另一个实施例中，提供了一种系统。该系统包括本地客户端。该本地客户端包括网络接口、储藏库接口、呈现接口(renderinginterface)、加密引擎、用户接口和控制模块。该系统还包括本地储藏库。本地客户端将通过网络接口与网络上的服务器交互，以接收文件访问的授权。本地客户端还将通过使用已验证的对等连接向和从本地储藏库传输文件的段，以及向和从其它系统上的其它客户端传输文件的段。
在另一个实施例中，提供了一种方法。该方法包括接收从栅格网络中的第一客户端请求段的邀请。该第一客户端通过防火墙与栅格网络耦合。该方法也包括用对段的请求响应请求段的邀请。该方法进一步包括响应于对段的请求从第一客户端接收段。
在另一个实施例中，提供了一种方法。该方法包括在第二客户端从栅格网络中的服务器接收关于第一客户端的信息。该第二客户端通过防火墙与该栅格网络耦合。该方法进一步包括向第一客户端发送请求段的邀请。该方法还包括从第一客户端接收对段的请求。
在另一个实施例中，提供了一种系统。该系统包括服务器。该服务器具有网络接口、本地储藏库接口和控制模块。该服务器还包括本地储藏库。服务器将与栅格网络的客户端交互。该服务器将进一步从栅格网络的客户端接收状态更新。
在另一个实施例中，提供了一种方法。该方法包括接收播种数据文件的请求。同样，该方法包括基于网络连接性选择栅格网络的客户端来接收该数据文件。进一步的，该方法包括响应于所述播种数据文件的请求向所选的栅格网络客户端发送该数据文件的段。
在另一个实施例中，提供了一种方法。该方法包括接收数据文件。该方法进一步包括确定该数据文件的哈希值。该方法还包括确定数据文件的分段。该方法另外包括加密数据文件的段。
在另一个实施例中，提供了一种方法。该方法包括接收数据文件的段。该方法还包括解密该数据文件的段。该方法进一步包括呈现该解密的数据文件的段。
在下文的说明中，为了解释的目的，陈述了许多特定细节以提供对本发明的彻底了解。但是，对本领域技术人员来说，显然无须这些特定细节也可以实施本发明。在其它实例中，以框图形式示出结构和设备，以避免模糊本发明。
说明书中对“一个实施例”或“实施例”的引用意味着联合该实施例描述的特定特征、结构或特性包括在本发明的至少一个实施例中。说明书中许多地方出现的术语“一个实施例”不必都指代相同的实施例，也不是相互排除其它实施例的独立或替代实施例。不同实施例中的特征和方面可以并入到其它实施例中，并且该文档中说明的实施例也可以无须所说明或描述的所有特征或方面而实施。
实施例可以解决以上确定的许多问题并且提供满足许多(如果不是所有)所确定的需要的系统和部件。另外，所述系统可以在单个统一平台上提供所有这些部件，该平台任何媒体所有者可以使用，任何出口合作者可以消费并且任何终端用户在期望的无论什么地方都能够浏览和观看。因而，不同实施例提供了用于编码、加密、建立使用权限和数字权限、内容管理、货币化联合组织、高速“按需”栅格网络交付、和轻便媒体播放器技术的端到端平台。为了本文档的目的，使用数字视频作为发明的系统的说明性例子，尽管应理解本发明不限于该例子。在不同实施例中，也可以流通(circulate)或提供数字音乐、书、软件、计算机游戏和其它媒体。
对于视频编码，一些实施例的系统使用自动“装备(harness)”，其允许技术员使用DVD媒体、胶片媒体、模拟媒体(诸如VHS磁带)将媒体“加载”到存储系统中。自动编码计算机在空闲时读取存储系统上的目录，以寻找新的媒体来获取并且开始编码。当该编码计算机具有新媒体文件的完全拷贝的时候，它将接着将其编码到期望的视频和音频编码译码器中，并且产生在双通道(two pass)编码系统中具有变化比特率的一组新的媒体文件。将媒体编码之后，随后将之存储在准备好交付给消费者的外部“运送(shipping)”存储阵列中。
一些实施例的数字媒体库系统从所述编码系统获得编码的媒体，并且将其导入具有成百千兆字节容量的存储阵列中。当它导入数字媒体文件的时候，它将媒体文件分割(fragment)成更小的段(例如，在一个实施例中是32KB-1MB“组块(chunk)”，在另一个实施例中是至少128KB的组块)，它使用最有效的加密法加密每个段，当前最有效的加密法是军用等级加密协议(128比特对称密钥加密)。可以使用不同形式的加密法和不同尺寸的组块来提供段。不同实施例的媒体库可以是“web使动的”，从而允许已验证的用户配置该组织、许可和每个媒体文件上的数字权限，包括每个媒体文件详细的批发和零售成本。媒体库可以用于其目录册(catalog)的一部分或所有对可信出口合作者的联合组织馈给。媒体库还可以连接到下面讨论的栅格网络(通常是对等网络)的“超节点”。
超节点，在一些实施例中是客户应用程序的“目录”，该目录允许客户端定位可能在它们的本地存储单元上保存有该媒体的一些小段的其它客户端。因而，在一些实施例中，超节点给客户端供应的信息允许它们将在计算设备的栅格上的这些相关的小段组合并且允许它们以正确排序并且连续的电影、书、音频、软件或游戏应用文件的形式适当的重新组合。超节点还可以给用户授权合适的加密密钥，以便在该客户应用程序有浏览那个媒体的许可时解锁该媒体。
不同实施例的媒体播放器应用具有通过合作者出口(网站，机顶盒，蜂窝电话或基于应用的个人计算机)启动(launch)的嵌入式协议，并且由此经由该超节点目录访问栅格网络。播放器应用自身很可能可以移动到任何数目的计算设备。
依照一个实施例，对出口合作者(诸如web入口和在线商人)的联合组织馈给由媒体库配置，其允许许多不同的出口合作者在高度可控、货币化和安全的媒体交付网络上访问该媒体库内容。联合组织可以在两个方向流动首先，媒体目录册交付给出口合作者，并且其次，从出口合作者交付有权访问媒体库上的媒体的已授权用户的列表。
依照实施例，栅格交付网络是成千或成百万(很多)客户应用程序的集合，这些客户应用程序都通过有效可控、慎重加密并且加速的媒体文件交付管线来共享、存储和消费媒体数据的段。该栅格在保证消费者(终端用户)高速、低成本访问媒体的过程中扮演关键角色。
图1提供了栅格网络的实施例。工作室110提供编码工作室的实施例。在编码工作室中，数字媒体由顾客(媒体供应商或媒体所有者)交付，以便数字操控进入网络。在传输到媒体库之前，压缩数字视频(例如通过私有编码译码器)，在测试实验室中测试、检查和净化数字应用，将数字音频转化到MP3格式，和净化数字文本或数据并且检查质量。在其它实施例中工作室也可以以其它方式实现。
媒体库130提供媒体库的示范实施例。每个顾客有权通过安全加密的WWW接口访问他们自己的安全媒体库以配置、上载和管理他们的媒体文件。媒体可以配置为不同级别的使用、数字权限、价格和成本控制、分类法(通过穷举记录详细描述)和图像(可以被上载以提供媒体的视觉图像)。可以配置完整(或只是部分的)媒体目录册，以便联合可信的出口合作者，这些合作者可以从一个到几千个。媒体库可以具有特殊的“出口合作者”网关，该网关使用密码保护和SSL加密的“SOAP web服务”严密保证安全，该网关允许可信的出口合作者允许或不允许它们的用户在该出口合作者的账户上下载媒体。媒体库还可以由下面所述的系统实施例上的超节点在世界范围内访问。当导入数字媒体的时候，媒体库将该数据分割成小的加密组块，以便经由栅格交付网络分发。除了可靠的用户、可靠的出口合作者和可靠的超节点外，媒体库可以对外部世界是不可访问的。
超节点140示出了地理定位超节点的实施例。如图所示，超节点与媒体库交互，以便从该媒体库安全下载数字媒体，从而经由栅格交付网络来分发。超节点位于世界各地，在一种系统中如同下面所解释的，用户将使用相关技术自动导航，以找到在地理上距离用户最近的超节点。这潜在允许快得多的因特网响应时间和更低的延迟。超节点管理数据从媒体库到用户的流通，包括元数据。超节点管理“作业券”，该“作业券”经由网络为用户授权短的可控的时间段。不具有有效“作业券”的客户端不被允许访问网络。超节点还管理“种子”的流通，种子是放到栅格网络上的电影的第一段，并且管理种子的智能传播，以允许网络的成千上万的客户端有效交互以便低成本地将电影流动到网络。超节点处理为了观看电影、听音频或下载软件应用程序而解锁数字媒体的段所需的数字密钥的验证和安全流通。为了报告的目的超节点还处理来自客户应用程序的关于网络使用的数据报告。这样的对超节点的说明在其它实施例中可以有所变化。
库接口120示出了视频点播库接口的实施例，该视频点播库接口可以是紧密受控并且高度安全的“内部网络”，其只能由可信用户利用规则变化的密码、基于IP(网际协议)的客户端验证、和其它复杂的授权技术来访问。在一个实施例中，整个内部网络由一个主“栅格控制”网络控制，该主“栅格控制”网络管理超节点之间和超节点与媒体库之间的验证，报告栅格的使用和所有危险系统中的系统健康。
馈给150示出了联合组织(syndication)馈给的实施例，该馈给是在输入同意可信公司分发他们的数据的顾客的配置上产生的。该可信公司可以称为“出口合作者”。联合馈给由媒体库所有者在媒体库上生成，并且经由FTP(文件传输协议)传送给出口合作者。出口合作者接收该联合馈给，其可以包括例如为成功建立网站或机顶盒应用或计算机应用以便成功分发这些数字文件所需的所有信息。联合馈给可以经由XML消费，并且因而可以包括解码该XML数据所必需的XML模式以及在他们的网站上向顾客展示产品所必需的图像。当终端用户在出口合作者网站上选择数字文件来消费(例如观看电影)，该出口合作者大概将首先为该用户配置在该媒体库消费该数据的许可。媒体库所有者可以在所收藏的每个文件上设置许可和价格。因而出口合作者同意它授权的每个用户下载媒体文件，并且招致该花费，内容所有者稍后对此开发票。
启动160示出了媒体文件的“web启动”的实施例，其也可以是“机顶盒启动”或“基于PC应用的启动”，也就是说用户在出口合作者处浏览了材料的目录册之后选取电影下载。本发明的客户应用程序配置浏览设备在用户选取数字文件观看的时候“启动”或“运行”自身。客户应用程序解码该启动数据，并且开始联系网络以便初始化电影的下载。
网络170示出了“视频点播”或栅格交付网络的实施例，该网络潜在是成千上万客户端计算机的集合，这些计算机互相连接并且通过因特网在分层网络上通信，该通信依照非常复杂的协议进行同样复杂的数据交换，下文将对此详细解释。单个客户应用程序可以是下载加密的数字文件，同时与该背景中透明的其它计算机共享加密的数字文件。为了该客户应用程序获知共享它需要的文件的其它客户端，该客户应用程序联系超节点服务器索取“节点列表”，该节点列表是很可能存储有该数据文件的重要部分并且也具有期望的连接速度的客户端的列表。在接收到该列表后，该客户应用程序开始使用TCP/IP(因特网主数据传输协议)联系其它客户端以初始化数据交换。客户端，甚至那些不能有效下载数字文件的客户端，一般配置为与其它客户端共享时钟。
图2是一个实施例中的媒体库的更详细的视图。在所示实施例中，库220示出的媒体库具有连接到它以执行功能的外部“群(group)”的三个主要群。第一群在项目240、250和260中显示。项目240、250和260示出了通过精巧的SSL和HTTP DIGEST密码验证过程连接到该媒体库的人类用户。在验证之后，用户被允许访问媒体库220。终端用户可以已经预设各种许可级别，以允许他们执行被信任进行的特定任务而不能进行其它任务。每个用户可以按粒度地被配置执行一些任务而不能执行另一些任务。因而媒体库上的每个功能可以被配置。三个主要的用户群可以是会计、目录册管理者和数字权限管理者。会计用户可以使用媒体库来制订使用报告(该使用报告用于针对媒体使用对出口合作者开账单)，监视网络的成本，和获得关于网络的重要统计信息。目录册管理者可以配置媒体库中的媒体，输入详细描述数字媒体的每个方面的数据，导入数字媒体，扫描图像和将图像上载到媒体库中，给媒体分配序列号，和管理其它用户的工作流。数字权限管理者可以货币化每个媒体文件的价格和成本，管理用户的使用权限，以及对可以由可配置的用户群下载的媒体分类质量和数量。
编码器210提供编码工作室的“导入”功能以便将数字媒体加载到媒体库。数据存储装置230示出了数据驻留的地方，在一个实施例中其可以在大存储区域硬盘网络阵列中，该阵列是冗余链接的，以便延迟灾难性的硬盘故障。为了类似目的，例如可以以分布式使用其它存储选项。
超节点280示出了实施例中的媒体库与单个超节点的交互。该媒体库可以连接到许多甚至几百个超节点，这些超节点可以通过栅格控制网络设备配置或者提供。超节点被配置与媒体库交互，以下载数字媒体描述记录，下载加密的媒体段以便在网络“播种”，并且验证用户的授权以便将使用那些数字媒体文件所必需的解密密钥安全地传送给客户应用程序。接口270示出了实施例中与媒体库的交互服务。接口270允许与外出的联合组织馈给交互，并且为媒体出口合作者提供进入的客户授权网关。
图3示出了用于编码数字电影的编码译码器“编码/解码”模块，数字电影是多个实施例中支持的多种文件类型之一。视频媒体必须进行转化和“压缩”，因为该媒体在原始状态很大。可以使用复杂的算法将该数据“压缩”成足够小的文件，以便提供在宽带因特网或其它网络上的快速传输。对于一种特定的编码译码器，该概念是将电影划分成连续的批，每一批是八个图片帧，并且将每一批的第一帧全部压缩。对于每一批，只对第二帧的与第一帧“有所改变”的数据编码。对该八个帧重复这个只对相对前继帧变化的数据压缩的过程。得到的文件是音频和视频数据的混合，这是比原始媒体数据更方便传输的形式。后继帧的变化或变量信息可以类似于例如MPEG编码中的变化信息。
为了编码数据，提供媒体文件310并且将其分裂为视频流320和音频流330。视频编码器350提供编码的(压缩的)视频数据并且音频编码器340提供编码的(压缩的)音频数据。结束模块370将编码的音频和视频数据合并成单个编码文件。在一个实施例中，在客户应用程序380将视频“解码”成实际电影文件，该实际电影文件在监视器、电视、手持设备或用户观看的其它显示技术上以大约每秒24图片帧的速率显示。所有这些允许传输和重新创建供用户390在潜在的远程位置观看的呈现的媒体文件360。
图4示出了联合组织馈给的细节，联合组织馈给在媒体库配置并且在一些实施例中当通过超节点410访问时可以是媒体库中包含的完整或部分目录册。可以基于许可级别、出租类型、媒体类型、种类(有或没有递归子分类)和多种顾客编程的过滤对完全目录册“过滤”。在XML馈给420中，可以看到通过使用文件传输协议(FTP)将XML馈给发送给出口合作者网站。出口合作者网站430按照规律的时间表(也是可配置的)在FTP服务器上接收该文件，并且使用该XML数据、XML模式和包含的图像建立网站、机顶盒、手持设备或PC应用，以允许他们的消费者用户浏览他们的用于观看的联合组织馈给中的该媒体。该馈给中的一些媒体可以设置为用户需要被给定的访问权限的许可级别，通常在货币费用交换中由出口合作者设置。例如，在用户向出口合作者网站430支付费用(450)之后，如果需要的话，该出口网站随后经由安全的“SOAP web服务”(460)与媒体库通信，该服务允许那些出口合作者给用户授予观看那些文件的许可。通常，媒体库410所有者随后将为出口合作者430开账单，理由是使用了他们的内容。其它金融安排当然也是可以的，例如，用户可以具有付清账户，每次它访问媒体服务时通过扣减费用减少该账户；或者用户可以具有信用卡账户，每次它访问媒体时对该账户收费。替代实施例中还可以有不同的安排。
传输(transfer)440示出了web启动，客户应用程序“运行”以开始通过栅格交付网络下载媒体文件。应用程序470是客户应用程序，在该情况下示出了其经由超节点410对媒体库检查它自己的验证480。如果验证被承认(基于许可级别、订阅状态或每浏览权支付)，那么随后给用户传送验证密钥(490)，以便解锁从该栅格交付网络下载(对等连接455，465，475)的加密的段，并且随后允许用户观看电影(495)。
图5示出了实施例中超节点与客户应用程序交互的机制。在“web启动”或类似事件之后，用户(客户端)随后被要求对超节点网络“解析域名”(520)。通过建好的“域名系统”，向用户交付在地理上与用户最接近的超节点的IP地址(540)，这允许用户连接到更快、更高速并且可能反应更迅速的服务器。所使用的DNS服务器(530)定制编程以执行这个少见的“地理学的”查找。为了举例说明的目的，解析出用户在地理区域中与超节点550，即日本东京的超节点最接近。客户端510随后进行下载元数据、获取“作业券”、下载种子(如果需要的话)、验证和获取解密密钥和向超节点返回使用情况数据报告的过程(过程模块570)。在网络580中，用户(客户端)从在回答作业请求时发现的栅格网络客户端下载电影560，该栅格网络客户端还包含当前共享该媒体文件的所有客户端的完整节点列表。
应注意到，经过该网络的所有文件由“主哈希(hash)”描述，在一个实施例中主哈希是使用160比特SHA1摘要(digest)算法产生的。数字媒体文件的每个“段”由类似的160比特的型式描述。因此在这些实施例中，每个段和每个主哈希是网络上用于下载的唯一“名字”。这也意味着可以使用该摘要算法产生哈希来“检验”该段是有效的。
图6示出了编码工作室，该编码工作室是工具和软件程序的复杂阵列，其承担数字化音频、视频、软件和数据媒体文件的密集任务，并且随后编码这些文件以便在栅格网络上使用。在接口620、630和640，编码工作室管理者接收视频，该管理者首先检查该电影并且将它们加载到数字化工作站650之中。可接受的视频格式是DVD、VHS和35mm库存电影胶片。使用商业软件来数字化该媒体，将“原始媒体文件”传送到“存储服务器”(660)之中，该存储服务器保存该数据以等待编码计算机完成一个编码会话。当编码器(670)做完一项作业，它立即联系存储服务器以查找等待编码的文件。该编码器随后将整个数字媒体文件拉入它的系统，并且开始将电影编码为适合通过网络传输的格式(图3)的复杂过程，对于每两个小时的电影媒体文件该过程可能花费长达10个小时。在编码器完成作业后，得到的编码的媒体被数字拷贝到存储服务器(660)。当存储服务器充满了等待被传输到媒体库的数字媒体文件，技术员680将该编码的文件拷贝到“sneakernet(运动鞋网络)”驱动器690，该驱动器实际上是用于通过步行、汽车或交付服务运送给顾客媒体库的冗余磁盘的外部阵列，顾客媒体库理论上可以位于世界上任何地方。
图7提供了播放器实施例的例子，一些实施例中集成到栅格网络客户端技术之中的用于视频播放的接口的典型实现方式。这些描绘从终端用户的视角示出视频播放器。该播放器应用在它的表现外观和感觉上自己采用了动态“皮肤(skin)”方法。当开始一部电影(参见下文的“VSI文件”)时，“皮肤”(并且因而播放器的外表)的选择得自卖主、媒体图书馆和该播放器给定的媒体元数据中包含的目标语言信息。这允许每个卖主并且每个场所(如果合适的话)定制。当客户端从一个媒体出口启动，它可能看起来与从另一个出口启动的客户端完全不同。例如，图7的Flixz皮肤为从那个网站启动的电影显示。出口合作者可以要求定制皮肤。如果皮肤在客户端计算机本地不存在，则客户端“取回”该皮肤，下载和安装它以备使用。图示的接口700包括商标710、窗口控制720、标题730、媒体显示屏740、状态条750和播放器控制760。
所示的视频播放器提供一般视频播放操控和功能，包括全屏切换、音量和静音选择、视频播放的播放、停止和定位功能。这些功能中的大部分由主机(hosting)视频系统技术处理。但是，涉及播放、停止和定位的功能的实现与底层的栅格网络实现有关系，因为他们要求播放器和该栅格网络引擎(客户端)之间的通信保持媒体的交付与播放同步。
尽管图中描绘的实现聚焦于视频播放的环境，对栅格网络平台唯一的部件对于其它类型的媒体和/或内容表示在原则上是相同的。这包括但是不限于音频格式，诸如书、设计图、照片集等大格式文档，用于创建硬拷贝媒体的ISO CD/DVD图像，可执行和/或可安装的软件应用程序，数字内容和表示的其它任何可视形式或格式。用于获得、检验和交付需要的媒体内容的过程对于所有媒体类型是相同的。安全性、会计核算的优点和对等传输的效率与媒体类型无关。为了帮助区分媒体表示的形式，最终结果呈现子系统只需要适当地对接(参见下文的表示接口部件)。基于时间的媒体，诸如音频和视频，要求用于同步和时间敏感性交付的额外服务。这些服务由栅格网络技术提供。
图8示出了一些实施例中在视频流播放器接口的情况下实现的栅格网络客户端的概念性概观图。尽管该概观图示出了这样的系统中可以发现的部件，但是这不是实现这样的系统的唯一选项，其它实施例可以使用类似或不同的实现。该栅格网络客户端的主要部件如下所述，并且可以发现在图中标示类似 VSI文件805对于每种媒体内容类型，存在相应的元数据文件。在该文档的命名法中，这些文件称为“VSI”文件。这些文件包含关于特定片断的媒体(例如电影)的信息并且包含关于媒体类型、卖主代码以及许可和出租类型的信息。这些文件还包含媒体可用的各种格式。这包括在不同的下载比特流和不同语言上的多种可能选择。
本地储备(store)875“本地储备”是用户的硬盘点储装置(客户端本地存储装置)的已经留出以备保存媒体段的一部分。媒体段被编码并且在它们的SHA1哈希名字下保存。构成媒体的特定片断的段在该媒体的SHA1哈希名字(该整个媒体文件的哈希)下记录。例行维护该本地储备区域，以便保持将所有媒体段的总尺寸“删减”到预定(并且是可配置的)的最大存储尺寸(在该实施例中通常是2GB)。
MemQueue870称为MemQueue的共享存储器区段提供两个独立的主要功能。第一，它可以作为缓存机制在存储器中而不是本地存储硬盘上保存一个或多个段，这是有效的机制。MemQueue 870共享存储器的另一个功能是用作IPC(内部处理通信)机制，通过该机制播放器的独立进程可以与栅格网络客户端通信。
表示接口(presentation interface)部件(VSISource.ax)810表示接口部件810是将栅格网络所交付的媒体翻译成适用于媒体呈现引擎的可用格式的中间部件。在图中详述的实施例中，这是在微软DirectShow滤波器部件的包装(VSISource.ax)中进行的。用于其它操作系统和/或其它视频呈现子系统的实现可以使用类似的主机适用的包装器(wrapper)来实现相同的栅格网络专用功能。
当对操作系统请求接收来自文件的数据，播放器请求用于流或以非常类似的方式表示媒体的数据。就是在这一层表示接口部件810进行与呈现引擎的主要对接。对数据的请求通过经由MemQueue870到栅格网络客户端的通信来履行，以确定本地储备中的哪个媒体段包含所请求的数据范围。使用该栅格网络客户端所提供的数字权限管理(DRM)编码密钥，该部件解密这些段并且返回所请求的数据。尽管已经从本地文件中获取数据，剩余的顺流呈现过程继续进行，并且将该媒体呈现给终端用户。在这样的实施例中，在任何时间点客户端系统上不存在能够直接呈现或拷贝的文件，从而提供潜在改善的安全性。另外，由于可以使用不同的包装器和编码译码器，基于可用的表示接口部件810呈现不同的格式以备显示或使用或存储(例如呈现DVD类型的媒体)可以是一个选项。
作业825栅格网络“作业”是经检验的媒体请求。栅格网络客户端通过使用从提供给它的VSI文件805获得的信息，通过在域名上执行DNS解析获得合适服务器的因特网IP地址。地理定位名字服务将提供最接近客户端的服务器。该栅格网络客户端随后将联系该服务器请求“作业券”830，以及和该客户端一样是本地的对等节点(peer node)的“节点列表”。作业券830是对等方(peer)用来检验连接的对等方是否已经被授权接收它请求的数据的时间受限的证明和密钥。该服务器还为该客户端提供组成该媒体文件的所有段哈希的列表。该段哈希的列表用于请求和检验在对等方之间传送的数据。
活动作业845作业可以在队列840中排队并且按顺序处理，或者可以被升级以便立刻下载。作业可以设置为以“不同步”模式或“同步”模式下载，“不同步”模式意味着段接收的顺序不重要，“同步”模式意味着段接收的顺序对于播放重要并且要求呈现播放器和栅格网络下载引擎之间额外的同步化。按照默认，作业以不同步模式排队。在典型的视频点播(video-on-demand)请求的情况下，新请求的作业被立刻激活，挂起任何当前活动的作业，并且将该新请求的作业立刻放入同步模式以便立刻播放。但是，该行为是可以依赖用户的需求和愿望以及交付上下文而调节的。
段管理器850，PeerXfer865，上载管理器860，下载管理器855图中如此标示的这些部件一起工作以提供核心的对等传输功能，以及与播种服务器的传输(如果需要的话)。该过程首先是与另一个对等方建立联系。这可以通过在服务器提供的节点列表中找到对等方并且初始化连接或者另一个对等方已经初始化与该客户端的连接而发生。可以建立几个同时连接。能够建立的连接的总数目是可配置的值，但是也受所记录的(例如在客户端或用户简档中)因特网连接的最大带宽限制。
一旦已经建立连接并且承认作业证明，将对等方连接起来以便交换(swapping)段，直到不再有维持连接的相互好处。段交易过程包括客户端向对等方请求所需的特定段，同时也传送该客户端哪些段可用(称为贡献列表)。作为响应，远程对等方发送所述请求的段的头部信息(如果可获得的话)，同时发送它自己的来自所提供的贡献列表的请求。它还传送它自己当前的贡献列表。这些交换在对等方之间继续，直到一方或两方都不再有能贡献给另一方的东西的时候为止。
在一侧(one-sided)交换中(这可能在一个对等方在还不具有这些段的另一个对等方之前下载电影的时候发生)，该领导对等方可以选择不中止该连接，尽管它当前不能从之获利，只要远远领先它自己的播放位置从而能舒适采用这样的姿态。如果两个对等方都舒适的领先他们的播放位置，那么段的顺序不再需要按照次序，并且该对等方之间的交换可以在更自由的基础上发生。通过使用请求远程对等方所具有的在所有连接的对等方之中“最稀有”的那些段的算法，促进了段在连接的对等方之间更平均的分配。这帮助保证段在栅格中的均匀分布，并且进一步减少了由于缺少特定段的对等方而迫使对等方联系种子服务器(seed server)的情况。
当段到达客户端时，对其进行处理以验证它的SHA1哈希与给定的段名相同。该检验保证该数据没有经历任何损害。表示接口部件810和段管理器850之间的相互关系特别重要。在播放期间，播放器不断地宣布它当前的播放位置。根据该信息，栅格网络能够确定关于下载段的顺序和优先度的“紧急性”的意识。如果存在不是远早于播放位置的空段，则在尽快接收这些段上设置强调。如果这个距离开始变得太短，和/或在连接的对等方之间只有有限的带宽可用，那么可以初始化到种子服务器的连接，以便维持目标下载速率不至中断电影播放。
如果播放位置距离开始运行空段只有瞬间，栅格网络客户端向播放器发送消息指导它暂停，并且在继续之前等待足够的缓存。如果存在领先于播放位置的足够一段时间的连续段，那么该栅格网络客户端能够更自由的在它自己的需求之前响应其它对等方的需求，包括从当前没有参加下载的它的本地储备响应对段的请求。这允许观看不同电影的对等方从不必在相同时间观看相同电影的客户端的本地储备受益。
段管理器850因而可以管理在客户端本地存储的段，并且与播放器交互以确定与播放的段相关的缓存的段的状态。PeerXfer865可以向和从其它对等方传输数据。上载管理器860可以管理按照需要向其它对等方的数据上载。类似的，下载管理器855可以管理按照需要从其它对等方的下载。因此，在设置和交互客户端的紧急性级别中可能涉及这四个部件中的每一个。
本地储备875盘点(inventory)和维护。本地储备875被周期性地盘点，并且如果开始变满，则删减其规模。盘点还用于向服务器报告储备中可用媒体的相对百分比，这样就可以跟踪具有可用的媒体文件的部分的那些客户端，并且将那些客户端排序以产生在智能模式中分发给其它对等方的节点列表。该盘点任务与栅格网络的其它功能并行执行，保持盘点账户和维护频繁更新，但是不延迟作为整体的应用程序的执行。该盘点数额在规律计划的报告提交期间报告，也在对新作业的请求期间报告。
报告890在规律的间隔-在一些实施例中是可配置的时间段但是通常是12小时或更多-客户端将报告890各种汇总和事务统计。该统计数据主要用于确定节点性能、分析该栅格中的弱点和识别那些是强客户端执行者的节点和不是强客户端执行者的节点。这帮助为对等方提供最佳的节点列表。使用计划定时器885将该数据报告给从服务器895。
自动更新栅格网络客户端还提供通过其能够自动交付软件新版本和更新该客户端的工具。在没有当前活动并且应用空闲的时间段内，请求查看在给定的当前版本和主机平台的情况下是否有新版本可用。如果有新版本，则默默下载和安装该新版本或补丁的安装程序，并且随后恢复程序。或者，可以通知用户新更新的到达，允许用户初始化实际安装。对于产品的发展特性，这样的自动机制很重要，并且是用户逐渐期望类似的复杂的产品具有的功能。
涉及使用栅格网络的视频点播的典型场景如下文所述。对该过程的描述参考图8播放器被给定VSI文件805进行处理。这通常通过从web浏览器(这里未示出)的移交完成，或者可以通过直接文件访问或其它方式完成。然后解析VSI文件805以获得从最近的服务器请求作业所需的信息。返回的节点列表和作业券用于同网络上的被认为具有该电影的一些部分的其它对等方建立联系。将该电影立即置入播放模式，并且从而开始流化，该流化以初始化播放所需的数据开始。
无论任何地方只要可能，从可用的多个对等方之一接收段。这样，无须主服务器的带宽消耗就可以分发媒体内容。在没有具有所需段的可用对等方的情况下，或者只有太少对等方存在，为了客户端能够维持最小比特率，将联系服务器，但是只联系所需的那么长时间。在这样的情况下，周期性地请求新的节点列表，以希望找到足够的对等方，从而打破对服务器的依赖。
在大部分环境中，将只有很少内容或者没有内容直接从超节点或种子服务器获取。但是，对于很少使用的媒体，或者新发布的媒体的最先用户，将比其它时间更依赖服务器。随着对等方继续彼此交易段，下载的段被写入该客户端的本地储备。这里播放器通过表示接口部件(VSISource.ax)810从储备读取数据，该数据是已解密的并且以供播放的最终形式表示。用户享受电影时可能移动播放位置来看电影的不同部分，并且因而改变“紧急性”并且栅格网络如此处理段请求。当电影放完，栅格网络客户端继续在后台运行，并且如上所述可用于继续服务其它对等方的请求。周期性的盘点和报告任务维持维护任务和报告任务的进行。
图9示出了实施例中在从服务器、客户端和对等方之间的操作。因而，图8的从服务器895能够给客户端815提供多种功能，同时客户端815还与对等方880交互以交换文件段。系统900的从服务器910提供诸如下载VSI文件915(文件标识符)，得到作业券920，下载种子925(播种的段)，响应授权请求930，和周期性报告935的功能。客户端程序940使用HTTP或SOAP协议与从服务器910的各种功能和相关模块对接，HTTP或SOAP协议可以不同方式扩展或应用。同样，客户端程序与对等方945交互，以便使用用于交换的作业券来交换媒体文件段，并且对于某些交换使用播种的文件段。客户端940周期性的报告它的状态，并且按照需要下载VSI文件或请求授权，以便初始化新的文件下载或检验另一个对等方的作业券。
图10提供播放来自栅格网络的电影文件的过程的实施例的图示。过程1000包括从网站请求电影或类似的媒体文件，接收该文件的标识符，请求该文件的券，提供支付信息，接收该文件的券，寻找该文件的段，和使用该文件。过程1000特别参考电影文件来描述，但是在其它实施例中其它类型的媒体文件或数据文件也可以与过程1000一起使用。过程1000和该文档中的其它过程实现为一组模块，该模块可以是例如过程模块或操作、具有相关功能或效果的软件模块、设计来履行该过程操作的硬件模块，或不同类型的模块的一些组合。这里所述的过程1000和其它过程的模块可以以诸如并行或串行模式重新排列，并且在不同实施例中可以重新排序、组合或再划分。
再次参考电影文件的特定例子，在模块1010，例如，对电影文件的请求可以通过诸如HTTP提交给网站。作为响应，在模块1020，网站提供电影标识符。在一个实施例中，电影标识符是该电影文件的哈希值，该哈希值可以是完美哈希，或近似完美哈希。一旦接收到电影标识符，在模块1030请求电影券(或作业券)。在模块1040，为了产生作业券，供应商或网站可以要求支付，并且支付信息可以通过诸如用户接口或经由用户简档来提供。例如，在用户具有正进行的订阅的情况下，用户简档可以指出该状态。可替代的，信用卡信息可以例如存储在某种形式的简档中，或者在购买的时候提供。
当接收了支付并且选择了标题，在模块1050接收电影券。电影券可以包括例如关于它何时有效、它用于那部电影和可以在哪里获得相关的电影文件的信息。下面进一步讨论示例的电影券实施例。在模块1060，初始化寻找电影段的过程。在栅格网络的机器内寻找与该券相关联的电影文件的段，找到的段在不同机器上并且潜在地以无序模式接收。在模块1070播放该电影。这可能响应于作为模块1060的部分接收到电影的足够早的段而发生，允许在播放电影的同时作为模块1070的部分接收另外的段。因而，模块1060和1070可以以并行模式运行，潜在地相互交互以确定即将到来的段是否可获得和需要哪些即将到来的段。
不同系统可以与电影券和电影或类似的作业券和媒体文件的组合联合使用。图11提供了栅格系统实施例的图示。系统1100包括网站、超节点、客户端A和B和网络。没有示出其它部件，诸如其它客户端和超节点。
系统1100包括网站1110，在该网站能够获得关于电影或其它媒体标题的信息。客户端(1130)A可以通过网络1150(其可以是例如万维网)访问网站1110。在网站1110找到一个标题之后，客户端A(1130)随后可以请求该相关电影，并且从网站1110接收该电影的标识符。另外，客户端A(1130)随后可以请求该电影的作业券，例如允许在客户端A(1130)观看该电影。这可能涉及对网站的支付或证实支付。
通常，作业券可以由超节点1120发放，在一些实施例中该超节点可以在地理上位于与客户端A(1130)相对接近的位置。超节点1120可以发放例如作为图12所示的数据包的一部分的作业券。图12提供了在对数据文件请求的响应中所使用的数据包的实施例的图示。数据包1200包括段列表、节点列表和实际作业券。因而，段列表1210可以提供例如段的列表(可以表示为段的哈希)以及段的总数值。
这样的结构可以允许，例如，跟踪是否已经接收到段。另外，这样的结构允许作为履行段请求的一部分的验证检查-接收对段的请求的客户端能够确定该请求是否包含正确的哈希值。类似的，可以根据该相关接收的段计算哈希值以便检验是否接收了正确的段。在一些实施例中，该哈希值可以是160比特哈希值，例如SHA1哈希值。在这种情形下，哈希值的纯粹数目允许接近完美的哈希-每个哈希值唯一标识讨论的段。另外，在一些实施例中，只有当哈希值与环绕文件(诸如电影文件)配对时，段的哈希值才是唯一的。因而，段的哈希值实际上包含电影文件的哈希值，每个段的哈希值表现为320比特哈希编码。
类似的，可以包括节点列表1220，例如，该节点列表1220提供具有目标电影媒体文件的段的节点的列表。另外，节点列表可以包括另一个字段，该字段具有关于给定节点上存在哪些段的编码数据。该数据可以由超节点1120维护，并且响应于客户端提交的数据来更新。
作业券1230可以包括多个不同字段。在一个实施例中，当请求新的作业时，将超节点发布的作业事务的唯一标识符、有效时间帧、超节点所创建的验证这两个信息片断的数字签名和签名证书的共有公共密钥的拷贝给予客户端。图13提供作业券的实施例的图示。标识符1310是发起超节点已知的唯一标识该作业请求的唯一标识符。时间帧1320可以包含可以授权该作业的段在对等方之间或从种子服务器交易的有效的“来往”次数。超节点已知的数字证书1350用于创建在标识符1310和时间帧1320中找到的信息的数字签名。该数字签名(1330)可以和所述证书的共有公共密钥(1340)一起使用来验证超节点发放了该作业券。当连接到(请求文件的)对等方，标识符1310和时间帧1320与数字签名1330一起发送。远程对等方或种子服务器能够验证该作业券信息从超节点发起，并且因此授权与该请求客户端交易段信息。
利用已验证的作业券1230，客户端A(1130)可以寻找相关电影文件的段。基于客户端B(1140)列出在节点列表1220上，可以将作业券1230提供给客户端B(1140)以请求段。客户端B(1140)可以利用超节点1120检验该券，并且随后将合适的段发送给客户端A(1130)。因而，可以建立客户端A(1130)和客户端B(1140)之间的对等(实际上是直接)耦合。该耦合可能仍然涉及通过网络1150的实际传输，但是可以将其示为更直接的连接。另外，段通常在进行中的基础上发送，直到客户端A(1130)信号通知它不再需要段。
图14提供了加密媒体文件的过程的实施例的图示。该过程广义包括哈希该文件(计算哈希值)和随后加密该文件的段。过程1400包括接收数据文件，计算该数据文件的哈希值，识别该数据文件的段，加密该段和存储加密的段。可以加密的文件类型包括各种类型的媒体文件，诸如电影、声音、动画、文本和其它文件。
过程1400可以在模块1410以接收数据文件以备加密开始。在模块1420，计算该文件的哈希值。该哈希值可以使用完美哈希过程计算，或者使用目的是近似模拟完美哈希的过程来计算。例如，在一个实施例中计算160比特哈希值。尽管这不必是完美哈希，但其可能足够接近，因为2^160提供了大量的唯一标识符。因而，为了实践的目的，该哈希值可以用作该文件的标识符。
计算标识符后，在模块1430标识文件的段。这可以简单到以预定的块尺寸划分文件的尺寸并且随后基于该预定的块尺寸对文件分段。或者，可以包括确定期望的块尺寸并且随后划分文件。在模块1440，对所述段加密。在一个实施例中，使用基于链-块-河豚(chain-block-blowfish)对称加密的过程对段加密，并且每个块部分地基于先前块的加密版本加密。将段加密后，在模块1450随后可以存储段以备稍后的分发。
已经存储段之后，人们随后可以请求段以便将它们以解密形式重新组合为文件。图15提供了使用加密的媒体文件的过程的实施例的图示。该过程包括请求文件，接收段，解密第一段随后解密后来的段，和继续接收和解密段。
过程1500在模块1510以使用哈希值作为标识符来请求文件开始。在模块1520接收该文件的段，并且在模块1520内接收到第一段。在模块1530，从而解密该文件内的第一段。这可能涉及该文件的哈希值，并且还可能涉及例如数字签名的一些形式。
在模块1540，解密该文件的下一个段。如果这在解密第一段后即刻发生，则该下一个段是第二段。但是，该下一个段可以预期是文件中在解密的上一个段紧后面的下一个段。在模块1550，判断是否还有更多段要解密。如果有，该过程移动到模块1560，在那里接收更多段(如果必要的话)并且随后移动回到模块1540以解密该下一个段。这可以重复，直到在模块1550判断没有更多段需要解密，在该点该过程在模块1570终止。该过程可以由于已经到达文件的末尾、文件已经关闭(大概不能访问)、没有接收到某个段或发生了错误而终止。
联合图14和图15的过程可以使用不同结构。图16提供了媒体文件实施例的图示。媒体文件1600是已经分段并且已经为其计算了哈希值的文件。因而，示出了基于整个文件的哈希值1610。哈希值1610因而可以是诸如图17B的值1750的值-可以作为标识符存储或传输的标量值。段1620示为文件1600中顺序的段。因而，段1620a首先到达，其后顺序跟随段1620b，1620c，1620d，1620e，最后是1620m和1620n。当加密文件1600的段的时候，首先加密段1620a，随后部分基于段1620a加密段1620b，等等。
在加密之后，可以存储段。图17A示出了媒体文件的段的实施例的图示。段1700包括头部1710，数据有效载荷1720和校验和1730。段1700的每个部分可以以加密过程开始。因而，头部1710可以包括诸如媒体文件标识符和段号的标识信息。数据有效载荷1720可以包括实际加密的数据(潜在具有在解密过程中与段的其它部分或外部数据交互的数据)。校验和1730可以提供一些形式的奇偶校验或段1700是否是它本身的更精细的指示。相反，图17B提供了媒体文件的哈希值的实施例的图示，该哈希值可以与例如标量数字值一样简单。
在栅格网络中，一些客户端是可以公共访问的，并且一些客户端隐藏在防火墙之后。图18提供了栅格网络的实施例的图示。系统1800包括(如图所示)第一客户端站点1810、第二客户端站点1820和它们之间的网络1830。这简化了整个栅格网络，栅格网络中可以存在多个客户端以及各种类型的服务器。客户端站点1810和1820是逻辑站点，它们可以不是表示单个物理地点。
客户端站点1810是公共客户端，如此命名是因为它比其它客户端相对容易访问，那里没有防火墙。客户端站点1810包括客户端1840和路由器1850，该路由器1850耦合到网络1830。另一方面，客户端站点1820是私有客户端，其具有介入的防火墙，防火墙阻挡未授权或未邀请的访问。客户端站点1820包括客户端1860、防火墙1870和路由器1880，它们都耦合到网络1830。防火墙1870阻挡对客户端1860的未授权的访问。
阻挡未授权或未邀请的访问可以(并且经常是)包括阻挡不是对先前的外发请求的响应的所有到来的请求。因而，如果客户端1840从客户端1860请求文件段，并且没有先前来自客户端1860的外发请求建立通过防火墙1870的路径，那么防火墙1870可以阻挡来自客户端1840的通信。尽管这提供了防御恶意软件的好处，但是禁止了未经请求的通信。潜在期望的是客户端1840和1860之间对等形式或类似结构的通信通道。
客户端1840可以通过网络1830初始请求媒体文件。图19提供了请求媒体文件的过程的实施例的图示。过程1900包括请求文件、接收段、发送更新的请求和从私有客户端接收请求。
在模块1910，过程1900以请求文件开始。随着请求发送给各对等方，在模块1920段到达，请求者开始接收文件的部分。在模块1930，基于已经接收到哪些部分，请求者随后可以发送修改的请求或对文件丢失部分的更新请求，并且关于已经请求了什么对服务器更新。另外，在模块1940，请求者可以接收请求以初始化来自私有客户端的通信。这些请求可以表明通知了私有客户端该请求者对文件的需求，并且邀请通过私有客户端防火墙的通信。
当公共客户端请求文件的时候，私有客户端反过来请求与该公共客户端的通信，以便提供路径从该公共客户端反过来请求文件。图20A提供了辅助媒体文件请求的过程实施例的图示。过程2000包括利用服务器更新状态、接收指令、联系公共客户端、接收请求和发送段。
过程2000以状态更新在模块2010开始。私有客户端将它的状态传送给服务器并且表示它可用于供应段。服务器大概有权访问关于该私有客户端具有哪些段的信息，并且能够确定该私有客户端是否应该供应段。在模块2020，基于该信息，该私有客户端从服务器接收到关于联系哪些其它客户端以便供应段的指令。
在模块2030，利用这些指令，该私有客户端初始化与所述公共客户端的通信，诸如通过请求与所述公共客户端所请求的文件相关的通信。响应于模块2030的通信，在模块2040，该私有客户端接收到来自公共客户端的对特定文件的段的请求。在模块2050，该私有客户端将段发送给公共客户端，并且该过程随后按需要重复足够长时间。注意到，该过程提出的段的通信以单向方式发生。但是，段从公共客户端传输回私有客户端也可能发生。这可能涉及相同文件或电影的段在两个方向上的传输，或者可以涉及例如多个文件的段在一个或两个方向上的传输。实际上，使私有客户端与公共客户端初始联系的该过程在不这样做就不发生通信的情况下帮助建立通信。
该帮助过程可以是令栅格网络起作用的有用部分。在栅格网络中，多个客户端可以为寻找段的单个客户端服务。因而，单个客户端可以从来自一到十六或更多的客户端的任何地方接收段。但是，多个客户端可能位于防火墙后面。因而，称为私有客户端的这些客户端对大部分公共客户端可能是不可访问的，从而切断了可用的栅格资源的重要部分。
称为私有客户端的在防火墙后面的客户端系统不能由寻找段的远程对等方直接联系。如果一个对等连接在请求前未被授权，则可以被拒绝。因此，超节点将不在广而告之给寻找连接机会的客户端的对等方列表中列出这些客户端。超节点提供的该节点列表通常只包括公共客户端节点。但是，这将可发现的资源的全部负担在该栅格的整个节点空间的该子集上共享，导致逊于最佳的配置。
为了解决该问题，辅助协议可以用于允许私有客户端初始化与认为对它们的资源感兴趣的公共可访问的客户端的连接。一旦已经建立连接，该连接的客户端可以为了该新的私有连接挑选释放一个它现有的公共连接。以此方式，将连接推给私有客户端希望“辅助”减轻该网络中公共节点上的负担，并且潜在地允许整个网络更有效的工作。
图20B示出了栅格网络中的辅助过程的实施例。客户端2015在防火墙后面并且因而不能由外部对等方公共寻址(私有客户端)。如果客户端2015确定它当前不忙于另一个作业并且在它的本地储备中有可以用于共享的资源，则它初始化与超节点2045的联系以便提供辅助服务。
辅助通知(2035)包含所述私有客户端能够有效共享的那些资产的简要目录。这可以是通过网络发送给超节点的数据包或其它类似的数据结构的形式。超节点2045随后识别出已知在积极交易这个媒体上的段的公共节点，并且通过响应2025将这些客户端的列表返回给私有客户端2015。
私有客户端2015随后可以通过连接请求2055初始化与该列表中的一个或多个公共节点的联系。接收公共客户端2065认识到该连接对等方2015是私有客户端，并且在确定该对等方2015确实能够提供当前需要的资源之后，接受该连接。它随后可以选择释放一个当前连接的公共对等方。
确定释放当前连接的公共对等方基于连接的对等方的整体可用性和接收段的当前紧急性需要。如果客户端能够负担得起为了新连接的私有对等方而释放公共对等方，它将会这么做。在这样情况下，私有对等方的连接2075取代先前的公共连接2085，并且与公共连接2085的通信停止。如果接收客户端2065确定它不能负担得起置换当前连接的公共节点(或者当前只连接了少量对等方)，则可以简单地将与新的私有客户端2015的连接2075添加到当前连接的对等方的列表中。
文件可以以多种不同格式提供，该格式与栅格网络中不同客户端的容量相一致。图21提供了一个实施例中的一组文件的图示。该组文件可以每一个具有不同格式，同时共享该栅格内使用的许多文件共有的其它特征。因而，每个文件包括标题、格式、哈希、段列表以及段(实际数据)。
例如，第一文件2110可以是以Windows Media格式(可从微软获得)编码电影“这是刺脊乐队(This is Spinal Tap)”的文件。因而，标题字段2140a可以以例如字符串或标题表中的索引来编码该标题“这是刺脊乐队”。格式字段2150a可以通过诸如名字(WindowsMedia)、类型(wmv)或诸如文件格式表中的索引的一些其它标识符来编码Windows Media(或特定编码译码器)的格式。哈希字段2160a将包括例如文件的实际数据的哈希。列表字段2170a包括文件的段的列表，诸如段的标量号码，其后跟随例如该段的压缩的逐位的表示。实际的段没有在图中示出，实际的段跟随所示的文件的头部。
第二文件2120可以类似地编码电影，可能是与文件2110相同的电影。但是，第二文件2120可以将该电影编码为例如Apple可用的Quicktime。因而，标题2140b类似于(潜在是相同地)标题2140a编码标题“这是刺脊乐队”。格式2150b将把格式编码为Quicktime、“mov”或索引。哈希2160b将包括文件2120的哈希，该哈希由于编码的差异很可能与文件2110的哈希不同。列表2170b将提供类似于列表2170a的列表，但是列表2170b对应于文件2120的段。同样，后面跟随实际的段(未示出)。
如所期望的，也可以编码第三文件2130。文件2130可以是完全不同的文件(例如“爱心熊历险记(The Cafe Bears Adventure)”)或相同电影的不同格式。然而该描述采用第三种格式，例如Real MediaPlayer的格式。标题2140c与标题2140a和2140b类似或相同。格式2150c将是例如RealMedia、“ram”或索引的编码。哈希2160c又是实际文件的哈希，并且因而可能与哈希2160a和2160b不同。类似的，列表2170c是类似于列表2170a和2170b的列表，其后跟随实际的段。
既然具有各种不同文件可用于满足对不同文件格式的需求，提供这些文件的过程可能有用。图22提供了实施例中提供期望格式的文件的过程的图示。过程2200包括请求文件、接收可获得格式列表、选择格式、接收券、请求段和接收该文件的段。因而，过程2200提供用于请求和接收期望格式的文件的客户端侧的过程。
当客户端请求标题-电影的标识符，该标题没有指出特定格式的时候，过程2200在模块2210开始。在模块2220，该客户端接收到所请求的标题的格式列表。在模块2230，该客户端选择期望的或需要的格式。格式的选择可以基于例如客户端和服务器之间的协商(基于容量自动选择格式)、基于用户的选择，或可以基于先前设置的默认选择。
响应于格式的选择，在模块2240接收该电影的券。该券可以是例如上文参考图12所描述的券。因而，可以预期该券包括，例如，哈希值、券何时有效的表示、段列表和数字签名或证书。在模块2250，客户端利用该券请求所述文件的段。作为响应，在模块2260，该客户端接收到段。如同可以预期的，该过程可以在模块2250和2260之间转换，这些模块潜在地并行运行或执行，直到电影完全接收到为止。
参考共享文件的示范性系统可能同样有用。图23提供了共享文件的系统的实施例的图示。系统2300包括超节点、种子服务器、客户端A-D和相关的储藏库。如图所示，共享单个电影文件，并且作为例子，客户端A 2330可以是寻找段和播放该电影文件的客户端。因而，客户端2330将从超节点2310接收到授权和作业券。客户端A 2330还将周期性的但是相对不频繁的(一个实施例中是每45分钟一次)向超节点2310报告它的状态。在所示的快照中，客户端A 2330具有所讨论的电影文件的20％，该部分存储在本地储藏库2335中。
因而，客户端A2335可以从客户端B 2340、客户端C 2350和客户端D 2360请求段。客户端B 2340在本地储藏库2345中具有所讨论文件的9％。客户端C2350在本地储藏库2355中具有所讨论文件的81％。客户端D 2360在本地储藏库2365中具有所讨论文件的27％。段、作业券的所有通信或其它通信以各种模式沿着网络2370发生。因而，对等连接可以沿着网络2370建立，或者广播消息可以沿着网络2370发出。特别的，客户端A 2330可以建立与客户端C 2350(例如)的对等连接并且开始共享段，或者至少接收段。
如果段在任何可访问的客户端上都不存在，则可以从种子服务器2320请求该段，该种子服务器在它的本地储藏库2325中保存有所谈论的该文件的100％。这优选是最后的手段，因为期望的是网络上对等方之间的共享。该请求也沿着网络2370传送。
虽然经常期望播放电影，电影如何播放可能对用户并不重要。但是，内容的所有者可能宁愿流化电影或其它长内容文件而不是将其作为完整文件传输。另外，存储限制可能使得存储整个文件困难。图24提供了实施例中接收文件流的过程的实施例的图示。过程2400包括请求文件、接收对应的作业券、请求该文件的段、接收缓存段、播放文件、确定该缓存在段上是否为低，增加低段状态的紧急性，继续接收段、确定播放是否结束、和丢弃段。
当客户端提交对文件流诸如电影文件的请求的时候，过程2400在模块2410开始。在模块2420，接收作业券，诸如参考图12所描述的作业券。在模块2430，客户端或用户利用该作业券通过栅格网络请求文件流的段。在模块2440开始接收缓存段。这些缓存段将包括组成顺序文件的开始的段，但是也可以包括后面的段，该后面的段可以被保存到需要为止。
当存在足够的缓存段，在模块2450，播放所述电影文件(或处理不同类型的顺序文件)。因而，具有了放在适当位置的充足的初始缓存之后，如同利用正常的流，该文件开始播放。但是，该文件的段是如同参考上面提到的文件段所述的那样加密和组织，而不是例如简单的未加密的数据包。该段通过类似于即时类型的解密过程解密，在播放它的时间将到来时解密段以便播放。因而，加密的段实际上通过解密和一般呈现(例如文件格式)的过程呈现给屏幕(电影)。
在模块2455，确定缓存是否运行到低位-很快将不存在足够的段来继续播放文件。如果是这样，在模块2460增加紧急性水平。该紧急性水平可以在各种设置中使用，例如简单文件请求或文件的播种。紧急性水平可以作为段请求的一部分或者因为其它目的而传送。在模块2465，不管紧急性水平，该过程继续接收段。如同可以预期的，给定该过程的流化特性，在模块2470，该文件的播放继续。在模块2480，确定是否已经到达文件的结尾。如果还没有到达结尾，该过程返回到模块2455来确定段状态并且随后继续模块2465和2470。如果已经到达文件的结尾，因为文件是流化的，该过程在模块2490终止。没有特别示出的是，在接近连续的基础上使用之后将呈现过的段丢弃。因而，加密的段保留，而未加密的段只保持足以显示(或其它使用)所讨论的段的时间。
紧急性提供了用于一般请求段并且特别是流化的有力工具。图25提供了紧急性表示的实施例的图示。紧急性水平可以位于紧急性水平2500的领域或范围内。如图所示，低紧急性2510提供了范围2500的一个端点。中紧急性2520提供了范围2500的中间部分。高紧急性2530提供了范围2500的另一个端点。实际紧急性水平可以编码为标量值-紧急性值2550。
在一个实施例中，低紧急性通常对应于以一般处理过程服务的请求，尽管紧急性水平仍然影响接收该请求的客户端的服务。在这样的实施例中，中紧急性的请求在低紧急性的请求之前被服务，并且可以例如插入到队列中的有利位置。另外，接近所述范围的高端的中紧急性请求可以接收额外的特殊处理并且可以例如在栅格网络内被加以监视。高紧急性请求可以触发不一般或特别的行为。例如，栅格网络中的种子服务器可以开始服务高紧急性请求，以避免例如缓存欠载运行的状况。另外，较高的紧急性水平可以触发服务器，导致更多辅助事务被引导到例如具有该较高紧急性水平的客户端。
参考例如栅格网络实施例的例子，可以理解文件的紧急性和流化。图26提供了栅格网络实施例的图示。网络2600包括整体网络、种子服务器、超节点和客户端A、B、C。网络2600代表各种栅格网络，而不提供这种网络的所有细节。
整体网络2610是诸如因特网或内部网的网络。超节点2620耦合到网络2610，该超节点可以是栅格网络2600的控制节点。种子服务器2630也耦合到网络2610，该种子服务器可以提供不同文件的段，并且有效地作为网络2600上段的储藏库。另外，客户端A 2640、客户端B2660和客户端C 2680耦合到网络2610。客户端A 2640已经耦合到段2650，段2650是客户端A 2640在本地存储装置上可访问的段的本地拷贝。类似的，客户端B 2660已经耦合到段2670，该段2670由客户端B 2660在本地存储装置上可访问。另外，客户端C 2680已经耦合到段2690，该段2690存储在客户端C 2680可访问的本地存储装置中。
因而，客户端A 2640可以请求文件流化。文件的段除了其它位置外可以位于客户端B 2660和客户端C 2680上。最初，客户端A 2640可以请求具有低水平紧急性的段，并且从客户端B 2660和客户端C2680接收返回的段。如果在播放该文件期间，客户端A 2640运行到段上的低位，它可以增加它的紧急性水平，并且继续请求段。利用该较高的紧急性水平，客户端B 2660和C 2680可以将来自客户端A 2640的该请求的优先次序排的较高。如果客户端A2640继续具有潜在的缓存欠载运行的问题，客户端A2640可以进一步增加它的紧急性水平。这可能导致种子服务器2630直接向客户端A 2640供应段。另外，超节点2620可以潜在地将辅助努力引导到客户端A 2640并且还可能例如取决于当该过程开始的时候可获得的段的整个风貌而引导种子服务器2630进行响应。
尽管栅格网络可以与流化的或拷贝的文件一起使用，但是文件的加密在两种情况下都很重要。图27提供了加密保护的实施例的图示。四个级别的保护潜在可用，包括传输、段、本地和播放器加密。加密栈2700表示加密的各级别或各层，该各级别中的一些或所有可以用于给定文件。
接下来参考加密的每一层，传输加密2710表示传输的段或数据包的加密-诸如通过一种形式或另一种形式的数字证书或数字签名。因而，当通过网络发送段时，无论段是任何形式，都可以对每个段加密。段加密2720指的是对文件中各个段的加密，诸如上文参考图14和15所述的。因而，可以将段作为完整的整个文件的一部分来加密，使得没有该整个文件的话段更难使用。
本地加密层2730指的是在本地储藏库中的加密。因而，如图28所述，可以将段存储在本地储藏库中，并且该储藏库中的存储可以涉及在任何其它加密上的加密步骤。播放器加密层2740指的是根据各媒体格式或播放器可用的加密选项。因而，媒体播放器可以自动加密某些格式的一些文件或所有文件，并且播放器能够解密该格式。没有已验证的媒体播放器，可能难于解密这样的文件。例如，由媒体播放器实现的DRM或数字权限管理可以提供这一层。
段，不管是加密的还是未加密的，在使用期间必须存储在某个地方。在某种意义上，客户端的栅格网络可以作为大存储网络，以分布的方式在该网络中的各处部分地存储文件。图28提供了栅格网络实施例中的客户端实施例的图示。每个客户端2800可以预期包括可执行部分和段储藏库部分，并且使用本地存储装置。可执行部分2810可以是包含在客户端中的代码的可执行部分，该代码实现了它的过程并且在由处理器或机器执行时完成它的功能。
段储藏库部分2820可以是客户端在本地存储装置中实现的储藏库，用于存储在文件播放和与其它客户端的交换中使用的段。在一个实施例中，段储藏库2820是加密的数据存储，其设计为仅能由客户端2800以有意义的方式访问。因而，段可以存储在段储藏库2820中，并且可以只能由可执行部分2810以有意义的方式获取。既然大部分段存储在段储藏库2820中，由于整个储藏库的加密，这可能使得一些人难于获得对段的未授权的访问。另外，少量段可以存储在本地存储装置2830中，该本地存储装置2830与段储藏库2820分离。这可以称为存储器高速缓存-在不同存储器中保持一些段(不必是特定的快速存储器)。通过在储藏库外保存少量段，这意味着简单地拷贝储藏库不意味着拷贝了整个文件-将存在缺口。另外，由于储藏库和个体段两者的加密，该情形类似于拼图，在此各片的形状不确定，因此确定哪些拼图片可用可能特别有挑战性。但是，应注意，该系统中不需要实现存储器高速缓存。
考虑实际栅格网络实施例可以进一步说明该网络和它的客户端的一些相关方面。图29提供了栅格网络的另一个实施例的图示。栅格网络2900示为具有超节点的集合、种子服务器和客户端。网络2900是诸如因特网或内部网的网络，该网络与各客户端和服务器耦合。
超节点2910是网络2900内与网络2990耦合的超节点。超节点2910监督栅格网络2900的一些操作并且维护栅格网络2900的其它部分的一些简档信息。因而，超节点2910可以维护关于该栅格网络上各个客户端的简档信息，并且可以还维护关于该栅格网络上的文件的信息。客户端的简档信息可以指示该客户端存储什么数据和该客户端与网络2990的连接是什么类型和该客户端在网络上(大体)位于哪里。关于文件的简档信息可以包括关于例如哪些节点具有文件的哪些段、文件类型和文件的段的数目。超节点2910图示为具有本地存储装置2913，这些简档和其它管理数据可以存储在该本地存储装置2913。超节点2930和超节点2950也耦合到网络2990，它们也提供相似的服务。
种子服务器2920与所述超节点一起也耦合到网络2990。种子服务器2920可以在本地存储装置2923中维护文件的段。另外，种子服务器2920可以通过将来自文件的段发送给不同客户端来在网络中播种文件的段。该播种可以通过发送出文件的段以便主动创建网络中分布形式的文件拷贝来处理。另外，在一些情况下，来自文件的段可以由种子服务器响应于来自客户端的请求而供应。但是，种子服务器的供应可能是不利的选项，因为努力令网络管理客户端之间段的交易和交换。分别具有本地存储装置2943和2963的种子服务器2940和2960也耦合到网络2990。
客户端2915、2925、2965、2975也耦合到网络2990。客户端A(2925)示为具有本地存储装置2928，而客户端B(2915)示为具有本地存储装置2918，客户端C(2965)示为具有本地存储装置2968，客户端D(2975)示为具有本地存储装置2978。可以预期每个客户端在本地存储装置中具有来自多个文件的一些段。当一个客户端寻找一个文件的段，超节点可以提供存储有相关段的客户端的列表，然后所述客户端可以请求这样的段。
给定所示的网络技术，客户端可以进行段的对等传输。为了监视网络，超节点2910可以从客户端2915、2925、2965、2975请求周期性的更新。这允许在不要求与各客户端的周期性试连的情况下维护网络状态。另外，诸如服务器2920的种子服务器可以以对等方式在网络中播种。类似的，如果必须的话，种子服务器2920可以服务来自客户端的对段的紧急请求。另外，对请求的服务可以基于使用已知服务用已知方式对最接近节点做出的判断-从而避免太多网络拥塞。因而，超节点不仅能为客户端提供哪些客户端拥有哪些段的列表，而且能提供关于每个客户端相对特定客户端多接近的指示。如果客户端A(2925)接近网络中的客户端B(2915)，并且距离客户端C(2965)和客户端D(2975)较远，那么请求客户端B(2915)可能是有利的。类似的，例如，如果在网络中客户端A(2925)接近种子服务器2920并且远离种子服务器2960，那么客户端A可以由种子服务器2920而不是种子服务器2960播种。
潜在地种子服务器可以在任何地方提供-种子服务器不需要物理上接近机器只要它在网络中在逻辑上接近即可(以网络跳跃来测量)。因而，种子服务器能够有利地放置以实现与许多客户端的接近。另外，大部分主要网络遵从这样的原则，网络内的带宽(从网络上的一个位置到该相同网络上的另一个位置)相对便宜，网络外的带宽(允许来自或去往另一个网络上的位置的连接)昂贵。这是如何处理和定价主要网络之间的网络交换的结果。
因而，在多种不同网络上提供种子服务器可能是有利的。这允许给定网络上的种子服务器服务来自该相同给定网络上的客户端的请求。另外，利用每个网络上的多个种子服务器，能够在每个网络的种子服务器内实现负载平衡和错误容忍。因而，栅格网络运营商可以在各网络上放置种子服务器，并且随后通知该网络运营商将主要或排外的专用于该各网络的栅格网络带宽。这潜在地允许为栅格网络运营商和基础网络运营商节省成本。有趣地，一些物理位置允许在小的物理空间内放置许多不同网络上的服务器，诸如网络会聚的地方，例如加利福尼亚的圣何塞和华盛顿的西雅图。
当初始共享文件的时候，在栅格网络播种能够提供很好的结果。例如，一个电影发布到栅格网络而没有进行播种，可能导致对该电影的需求即刻达到高峰，此时只有种子服务器可用于访问该文件段。图30提供了在栅格网络播种的方法实施例的图示。人们可以在预期的高峰(诸如初始授权观看该电影)之前，利用该文件的拷贝在网络上播种。过程3000包括接收文件、预测分发、将该文件散布到选定的种子服务器、将该文件散布到选定的客户端和更新该网络中相关的简档。
当在模块3010接收到文件，可以预期该文件被发布或授权以便在此之后很快发布。但是，在模块3020，可以进行关于文件的分发的预测。该预测可以基于分发经常如何发生的模板(例如，科幻电影可以以一种已知方式分发，历史文献以另一种方式分发)。可替代的，该预测也可以基于例如媒体所有者想发生什么(并且愿意为此付出代价)。因而，该预测可以包括指示应该将文件散布到哪里来用于播种或预发布的目的。
在模块3030，将所述文件播种到种子服务器-将其拷贝到联系模块3020的预测分发所识别的服务器。这可以基于地理的(实际或逻辑的)位置、服务器的带宽和其它考虑。类似的，在模块3040，将该文件全部或部分散布到选定的客户端。这可以类似地基于例如网络中的位置。另外，这可以基于观察到的客户端的活动，诸如观看相关电影的可能性，带宽和连接属性，是否愿意扮演种子客户端，当前存储文件的混合，和其它考虑。将文件播种到服务器和客户端两者之后，更新该网络内的简档(诸如在超节点)。这允许在观察到播种完成之后发生实际的文件发布或授权。注意到，由于这样的简档的更新，可以通过简单检查在超节点的简档来监视播种，允许对可能相对最新的(由于连续的简档更新)播种过程的快照，而无需为了状态试连每个客户端。
为了进一步理解播种，网络的另一个示范实施例可能有帮助。图31示出了播种的栅格网络的实施例的图示。系统3100是播种了两个不同电影的客户端、种子服务器和超节点的网络。在这个实施例中，例如可以用“这是刺脊乐队”的拷贝和“巴尼冒险记(Barney’s BigAdventure)”的拷贝播种。
网络3110是诸如因特网的网络。提供监督和管理功能的超节点3120耦合到网络3110。种子服务器3130和其相关的储藏库3135也耦合到网络3110。如图所示，种子服务器3130在它的储藏库3135中拥有每个电影的拷贝-每个电影的100％的段。
客户端1(3140)耦合到网络3110并且具有储藏库3145。储藏库3145具有第一个电影的6％的段和第二个电影的20％的段。客户端2(3150)同样耦合到网络3110并且具有储藏库3155，该储藏库3155拥有第一个电影的30％和第二个电影的10％。客户端3(3160)耦合到网络3110并且具有储藏库3165，该储藏库3165拥有第一个电影的70％和第二个电影的15％。最后客户端4(3170)耦合到网络3110并且具有储藏库3175，该储藏库3175包括第一个电影的9％和第二个电影的45％。
超节点3120的储藏库3125跟踪关于每个客户端(1-4)上有哪些段的信息。在一个实施例中，所有客户端周期性地报告它们的状态，包括关于它们的加密段数据储备的内容的信息。在一个实施例中，这每45分钟发生，但是也可以使用其它定时器间隔。尽管示出了每个客户端上每个电影的百分比，但是没有示出存在哪些段。在储藏库3125中可以为每个客户端存储该客户端上文件的百分比。另外，为了说明的目的，假定每个电影文件以相同顺序在每个客户端储藏库(3145，3155，3165，3175)中存储。实际情况不是必须如此，可以实施随机访问存储(并且可以优选随机访问存储)。当发生该两个文件的段的共享，客户端3可以是“这是刺脊乐队”的很好的资源，但是是“巴尼冒险记”的无价值的资源。客户端4情况可能相反。
应注意“巴尼冒险记”的完整拷贝也不是必须存在，而“这是刺脊乐队”的一些副本必须基于每个电影的百分比。但是，段可以在整个网络中复制或者只在种子服务器上出现，这取决于播种的喜好和网络的应用。另外，注意该附图提供了网络快照的图示，并且在这样的快照后可能发生段的传输，导致在随后的快照后处于不同的网络状态。
图32提供了可以用于实现栅格网络的网络的实施例的图示。图33提供了可以在栅格网络中使用的机器的实施例的图示。下面对图32-33的描述目的是提供对适用于执行上文和此后所描述的本发明的方法的设备硬件和其它操作部件的概览，而不是为了限制应用环境。类似的，所述硬件和其它操作部件可以适用于作为上述设备的一部分。本发明可以利用其它系统配置来实施，包括个人计算机、多处理器系统、基于微处理器的或可编程的消费电子设备、网络PC、小型计算机、大型计算机和类似设备。本发明还可以在分布式计算环境中实施，其中任务由通过通信网络链接的远程处理设备执行。
图32示出了通过诸如因特网的网络3205以及蜂窝网络和相关的蜂窝设备耦合在一起的若干计算机系统。这里使用的术语“因特网”指的是使用特定协议的网络，该特定协议诸如TCP/IP和可能的其它协议，比如用于构成万维网网页(web)的超文本链接标示语言(HTML)文档的超文本传输协议(HTTP)。因特网的物理连接和因特网的协议与通信过程是本领域技术人员公知的。
对因特网3205的访问通常由因特网服务供应商(ISP)提供，诸如ISP 3210和3215。诸如客户端计算机系统3230、3250、3260的客户端系统上的用户通过诸如ISP 3210和3215的因特网服务供应商获得对因特网的访问。对因特网的访问允许所述客户端计算机系统的用户交换信息、接收和发送电子邮件和浏览文档，诸如已经以HTML格式准备的文档。这些文档通常由web服务器提供，诸如被认为在因特网“上”的web服务器3220。这些web服务器经常由诸如ISP 3210的ISP提供，尽管可以在没有ISP系统的情况下建立计算机系统并且将之连接到因特网。
Web服务器3220通常是至少一个计算机系统，该计算机系统作为服务器计算机系统运行并且配置为利用万维网的协议运行并且耦合到因特网。可选的，web服务器3220可以是为客户端系统提供对因特网的访问的ISP的一部分。Web服务器3220被示为耦合到服务器计算机系统3225，该服务器计算机系统3225自身耦合到web内容3295，web内容3295可以被认为是媒体数据库的形式。尽管图32中示出了两个计算机系统3220和3225，web服务器系统3220和服务器计算机系统3225可以是一个计算机系统，该计算机系统具有提供web服务器功能和服务器计算机系统3225所提供的服务器功能的不同的软件部件，下文将对服务器计算机系统3225进一步描述。
蜂窝网络接口3243一方面提供蜂窝网络和对应的蜂窝设备3244、3246和3248之间的接口，另一方面提供蜂窝网络和网络3205之间的接口。因而，蜂窝设备3244、3246和3248可以与网络3205连接并且交换诸如电子邮件、内容或HTTP格式的数据的信息，该蜂窝设备可以是包括蜂窝电话、双向传呼机、个人数字助理或其它类似设备的个人设备。蜂窝网络接口3243与计算机3240耦合，该计算机3240通过调制解调器接口3245与网络3205通信。计算机3240可以是个人计算机、服务器计算机等并且作为网关服务。因而，计算机3240可以与客户端计算机3250和3260类似，或者与例如网关计算机3275类似。然后可以通过由接口3243、计算机3240和调制解调器3245提供的连接上载或下载软件或内容。
客户端计算机系统3230、3250和3260每一个可以具有合适的web浏览软件，观看由web服务器3220提供的HTML页。ISP 3210提供通过调制解调器接口3235到客户端计算机系统3230的因特网连通性，该调制解调器接口可以认为是客户端计算机系统3230的一部分。该客户端计算机系统可以是个人计算机系统、网络计算机、web电视系统或其它这样的计算机系统。
尽管如图32所示，ISP 3215类似地为客户端系统3250和3260提供因特网连通性，该连接与更直接连接的计算机系统不同。客户端计算机系统3250和3260是通过网关计算机3275耦合的LAN的一部分。尽管图32将接口3235和3245笼统地示为“调制解调器”，这些接口的每一个可以是模拟调制解调器、ISDN调制解调器、电缆调制解调器、卫星传输接口(例如“直接PC”)，或用于将计算机系统与其它计算机系统耦合的其它接口。
客户端计算机系统3250和3260通过网络接口3255和3265耦合到LAN 3270，该网络接口可以是以太网接口或其它网络接口。LAN3270也耦合到网关计算机系统3275，该网关计算机系统3275可以为该局域网提供防火墙和其它因特网相关服务。这个网关计算机系统3275耦合到ISP 3215，以便提供到客户端计算机系统3250和3260的因特网连通性。该网关计算机系统3275可以是传统的服务器计算机系统。Web服务器系统3220也可以是传统的服务器计算机系统。
可替代的，服务器计算机系统3280可以通过网络接口3285直接耦合到LAN 3270，以便给客户端3250、3260提供文件3290和其它服务，而不需要通过网关系统3275连接到因特网。图33示出了可以用作蜂窝电话的个人设备(3244、3246或3248)或类似的个人设备的一个例子。这样的设备可以用于执行取决于实现的许多功能，诸如电话通信、双向传呼机通信、个人组织或类似功能。图33的系统3300也可以用于实现其它设备，诸如个人计算机、网络计算机或其它类似系统。计算机系统3300通过通信接口3320与外部系统对接。在蜂窝电话中，这个接口通常是用于与蜂窝网络通信的无线电接口，并且还可以包括用于与立即可获得的个人计算机一起使用的一些形式的有线接口。在双向传呼机中，该通信接口3320通常是用于与数据传输网络通信的无线电接口，但是类似的可以包括有线或有支架的接口。在个人数字助理中，通信接口3320通常包括有支架的或有线的接口，并且还可以包括一些形式的无线电接口，诸如蓝牙或802.11接口，或者例如蜂窝无线电接口。
计算机系统3300包括处理器3310，处理器3310可以是传统的微处理器，诸如因特尔奔腾微处理器或Motorola power PC微处理器、Texas Instruments数字信号处理器，或两种类型的处理器的某种组合。存储器3340通过总线3370耦合到处理器3310。存储器3340可以是动态随机存取存储器(DRAM)，并且也可以包括静态随机存取存储器(SRAM)，或者也可以包括FLASH EEPROM。总线3370将处理器3310耦合到存储器3340，还耦合到非易失存储装置3350，显示控制器3330，和输入/输出(I/O)控制器3360。注意到显示控制器3330和I/O控制器3360可以集成在一起，并且该显示器也可以提供输入。
显示控制器3330以传统方式控制显示设备3335上的显示器，该显示设备通常是液晶显示器(LCD)或类似的平板、小外形格局显示器(small form factor display)。所述输入/输出设备3355可以包括键盘或输入笔和触摸屏，并且有时候可以扩展到包括硬盘驱动器、打印机、扫描仪和其它输入和输出设备，包括鼠标或其它指示设备。该显示控制器3330和I/O控制器3360可以利用传统的公知技术实现。数字图像输入设备3365可以是耦合到I/O控制器3360的数字相机，以便允许来自该数字相机的图像输入该设备3300。
非易失存储装置3350通常是FLASH存储器或只读存储器，或两者的某些组合。在某些实施例中也可以使用磁性硬盘、光盘或大量数据的存储装置的其它形式，尽管这样的设备的外形格局通常排除了作为设备3300的永久性部件安装。更合适的，另一个计算机上的海量存储设备通常与该设备3300的更有限的存储装置联合使用。在设备3300中，在软件执行期间，经常通过直接存储器存取过程将该数据的一些写入存储器3340。本领域的技术人员将立刻认识到术语“机器可读介质”和“计算机可读介质”包括可以由处理器3310访问的任何类型的存储设备并且还包括编码数据信号的载波。
设备3300是具有不同结构的多种可能设备的一个例子。例如，基于因特尔微处理器的设备经常具有多条总线，一条总线可以是用于外围设备的输入/输出(I/O)总线并且一条总线直接连接处理器3310和存储器3340(经常称为存储器总线)。所述总线通过桥部件连接在一起，桥部件执行由于不同总线协议而进行的任何必要的翻译。
另外，设备3300由操作系统软件控制，该操作系统软件包括诸如硬盘操作系统的文件管理系统，该文件管理系统是操作系统软件的一部分。具有其相关文件管理系统的操作系统软件的一个例子是来自华盛顿州雷蒙德的微软公司的名为Windows

和

的操作系统家族和它们的相关文件管理系统。具有其相关文件管理系统的操作系统软件的另一个例子是

操作系统和其相关的文件管理系统。该文件管理系统通常存储在非易失存储装置3350中并且致使处理器3310执行操作系统所要求的各种动作，以便输入和输出数据以及在存储器中存储数据，包括在非易失存储装置3350上存储文件。其它操作系统可以由设备制造商提供，并且那些操作系统通常具有设备专用功能，该设备专用功能不是类似设备上的类似操作系统的一部分。同样，为了特定的设备能力，可以令

或

操作系统适应特定设备。
在一些实施例中，设备3300可以集成到单个芯片或芯片组上，并且通常适合小的外形格局以便用作个人设备。因而，处理器、总线、板上存储器和显示器/I-O控制器都集成到单个芯片上也是寻常。可替代的，功能可以划分到具有点到点互连的几个芯片上，致使从实际设备或相关图表的角度观察总线在逻辑上是显而易见的但是在物理上不是明显的。
详细描述的一些部分以算法和对计算机存储器内的数据比特的操作的符号表示来给出。这些算法说明和表示是数据处理领域的技术人员将他们的工作实质最有效地传达给该领域其它技术人员所用的措施。这里算法通常被认为是导致期望结果的自相一致(self-consistent)的操作序列。操作是那些对物理量的物理操控。这些量通常(但不是必须)采用能够被存储、传输、组合、比较和其它操控的电或磁信号的形式。主要为了通用的原因，已经证明，有时将这些信号称为比特、值、元素、符号、字母、期限、数字等是方便的。
但是头脑中应该明白，所有这些术语和类似术语应该与合适的物理量相关联并且只是应用到这些量的方便标签。除非特别说明，否则从下面的讨论将明白，在整个说明书中，使用诸如“处理”、“估计”、“计算”、“确定”或“显示”或类似词的术语的讨论指的是计算机系统或类似的电子计算设备的动作或处理，该动作或处理将该计算机系统的寄存器或存储器中以物理(电子)量表示的数据操控或转换为在计算机系统存储器或寄存器或其它这样的信息存储装置、传输或显示设备内以物理量类似表示的其它数据。
在一些实施例中，本发明还涉及用于执行这里的操作的设备。该设备可以是为所需目的特别构造，或者可以包括通用目的计算机，该通用目的计算机可选择地由该计算机中存储的计算机程序激活或重新配置。这样的计算机程序可以存储在计算机可读存储介质中，例如但是不限于，任何类型的磁盘(包括软盘、光盘、CD-ROM、和磁光盘)，只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁卡或光卡、或任何其它类型的适合存储电子指令的介质，并且它们每一个耦合到计算机系统总线。
这里提出的算法和显示器不是固有地与任何特定计算机或其它设备相关。依照这里的教义，各种通用系统可以与程序一起使用，或者可以证明构建用于执行所需方法步骤的专门设备更方便。下面的说明将出现用于各种这样的系统的所需结构。另外，本发明不是参考任何特定的编程语言描述的，因而可以使用不同的编程语言来实现各实施例。
尽管可以使用网络部件的多种不同实现方式和相关的机器，但是可以证明一种示范性实现方式是有利的。图34提供了网络实施例中的客户端实施例的图示。系统3400包括客户端3405，以及用户I/O、视频和音频控制、本地存储装置和网络接口。
客户端3405包括控制模块3440、网络接口3410、本地存储接口3415、呈现接口3420、加密引擎3425和用户接口3430。网络接口3410与网络端口3490协作耦合到栅格网络。本地存储接口3415存储和取回本地存储装置(储藏库)3450的数据。
呈现接口3420将文件的段呈现为可用格式，诸如可以被显示、播放(发声)或存储。例如，呈现接口3420与视频控制器3460和音频控制器3470交互，以激活显示器3465和扬声器3475。另外，呈现接口3420可以致使呈现的段通过本地存储接口3415在本地写入。加密引擎3425解密(并且如果需要的话，加密)段和相关数据。用户接口3430与用户I/O控制器3480交互。用户I/O控制器3480可以与例如，用户输入设备3485和视频(3460)和音频(3470)控制器交互。控制模块3440控制客户端3405的其它部件。
类似的，可以使用各种服务器实现方式，并且一种示范性实现方式可能是有利的。图35提供了网络实施例中的服务器实施例的图示。服务器3500包括网络接口、网络控制模块、存储接口、加密引擎、用户接口和控制模块。网络接口3510与栅格网络和任何基础网络对接。网络控制模块3520提供控制功能，并且可以为栅格网络提供控制信号。这样的控制信号和功能可以，例如，发放作业券、切断对恶意的或不工作的客户端的访问，或引导客户端辅助其它客户端。
存储接口3540与本地存储装置3560交互，存储和取回关于网络和其中的客户端的信息。加密引擎3560加密和解密数据，诸如当检验来自客户端的数据包的身份的时候。用户接口3550允许用户与服务器3500交互，诸如允许检查统计或覆盖配置。控制模块3530控制服务器3500的其它部件和帮助实现它们之间的通信。
本领域的技术人员将理解，尽管为了举例说明的目的描述了系统和方法的特定例子和实施例，在不偏离本发明的情况下可以进行各种修改。例如，本发明的实施例可以应用于许多不同类型的数据库、系统和应用程序。另外，一个实施例的特征可以结合到其它实施例中，即使那些特征在本文档中没有在单个实施例中一起描述。
权利要求
1.一种系统，包括
与网络耦合的具有验证功能的第一服务器节点；
也与所述网络耦合的具有完整文件的储藏库的第二服务器节点；和
与所述网络耦合的具有文件的本地储藏库的一组客户端节点，所述客户端节点被配置为通过所述网络在对等基础上共享完整文件的段。
2.权利要求1所述的系统，其中
该组客户端节点中的客户端节点只有在该客户端节点确定请求的段不能从该组客户端节点中的另一客户端节点有效获得时才从第二服务器节点请求该段。
3.权利要求2所述的系统，其中
所述完整文件编码数字电影的数据。
4.权利要求2所述的系统，其中
所述完整文件编码数字电子书的数据。
5.权利要求2所述的系统，其中
所述完整文件编码数据库的数据。
6.权利要求2所述的系统，其中
该组客户端节点中的客户端节点在跨越网络交换段之前从第一服务器节点请求和接收验证。
7.一种系统，包括
包含网络接口、储藏库接口、呈现接口、加密引擎、用户接口和控制模块的本地客户端；和
本地储藏库；
其中所述本地客户端将通过网络接口与网络上的服务器交互以接收对文件访问的授权，以及
使用已验证的对等连接向和从本地储藏库传输文件的段以及向和从其它系统上的其它本地客户端传输文件的段。
8.权利要求7所述的系统，其中
本地客户端将所述段呈现为可用于通过显示器与用户交互的格式。
9.权利要求7所述的系统，其中
本地客户端将解密来自本地储藏库的段。
10.权利要求7所述的系统，进一步包括显示器。
11.权利要求7所述的系统，进一步包括
与显示器和本地储藏库耦合的处理器，
该处理器执行本地客户端。
12.权利要求7所述的系统，其中
本地储藏库包括文件段的加密存储。
13.权利要求12所述的系统，其中
所述文件段是来自多个媒体文件的段。
14.权利要求13所述的系统，其中
所述媒体文件是电影文件。
15.权利要求7所述的系统，进一步包括
用于显示视频数据的装置。
16.一种方法，包括
通过对等连接从第一客户端请求媒体文件的段；
在该请求中提供第一已验证的作业券；
只要所述第一已验证的作业券保持有效就通过对等连接从第一客户端接收所述媒体文件的段。
17.权利要求16所述的方法，进一步包括
通过对等连接，利用第二已验证的作业券从第二客户端接收对电影文件的段的请求。
18.权利要求17所述的方法，进一步包括
通过利用服务器检验第二已验证的作业券的真实性来响应所述对电影文件的段的请求；以及
通过借助于对等连接将段传输到第二客户端来进一步响应所述对电影文件的段的请求。
19.权利要求16所述的方法，进一步包括
从第三客户端接收对对等连接的特定请求，该第三客户端通过防火墙耦合到网络；
响应来自第三客户端的所述特定请求，并且建立对等连接；以及
与第三客户端交换文件段。
20.权利要求16所述的方法，进一步包括
解密所述电影文件的段；以及
呈现解密的电影文件的段以便显示给用户。
21.权利要求16所述的方法，进一步包括
解密所述电影文件的段；
在本地储藏库的本地文件中存储解密的电影文件的段；以及
呈现本地文件的解密的段以便显示给用户。
22.权利要求16所述的方法，其中
所述方法以机器可读介质中包含的一组指令来具体实施，所述指令由处理器执行，使得处理器执行该方法。
全文摘要
在实施例中提供了一种系统。该系统包括与网络耦合的具有验证功能的第一服务器节点(3130)。该系统还包括也与网络耦合的具有完整文件的储藏库的第二服务器节点(3120)。该系统进一步包括与网络耦合的具有文件的本地储藏库的一组客户端节点(3150)。该客户端节点被配置为通过网络在对等连接的基础上共享完整文件的段。在另一个实施例中提供了一种方法。该方法包括通过对等连接从第一客户端请求媒体文件的段。该方法还包括在该请求中提供第一已验证的作业券。该方法还包括只要该第一已验证的作业券保持有效就从所述第一客户端通过对等连接接收所述媒体文件的段。
文档编号G06F15/16GK101297281SQ200680026423
公开日2008年10月29日 申请日期2006年5月22日 优先权日2005年5月20日
发明者A·埃蒙德, S·奥默特 申请人:栅格网络公司