确保对长期存储的电子文档的访问的方法和系统

摘要

本发明涉及一种确保对长期存储的电子文档的访问的方法和系统。提供了用于确保对长期存储的电子文档的访问的机制。在一个实例中，一个或多个系统可提供自动确保对长期存储的电子文档的访问。在另一实例中，一种或多种方法可提供自动确保对长期存储的电子文档的访问。在另一实例中，一种或多种算法可提供自动确保对长期存储的电子文档的访问。

说明书

背景技术

一旦实现最初的内容管理系统（例如，IBM CONTENT MANAGER）， 通常会扫描重要文档并以位映射图形文件格式存储这些文档。目前，使用 相对较少的文件类型（例如，tiff、.jpg、.bmp）存储文档。这些较少的文 件类型一般仍可读（例如，被计算机或其它设备读取）。但是，在最近十 年内，越来越多文档开始直接以其本机格式存储（例 如，.123、.sam、.xls、.opd、pdf、doc、docx等）。将来，长期存储的不 同文件格式的范围可能显著增加。

图1和2是示出与传统文档支持相关的实例关系的示意图。

更具体地说，如图1所示，指南101一般将责任委托给用户103（但 是，用户103一般假设指南101将提供解决方案105（该解决方案是有关 如何访问文档的解决方案））。此外，指南101一般假设解决方案105存 在（但是，解决方案105可能仅在过去存在）。此外，用户103一般假设 解决方案105存在（但是，解决方案105可能仅在过去存在）。这样，如 图2所示，当解决方案不再存在时，该假设不成立。

此外，一旦创建文档，则文档一般仅通过文档扩展与兼容的程序关联 （例如，Microsoft Word的.doc、Open Document Format的.odf）。

发明内容

在一个实例中，本公开一般地涉及确保对长期存储的电子文档的访问 的领域（在各种具体实例中，所述访问可以是读取访问、写入访问和/或创 建访问）。

在一个实施例中，提供一种用于确保对长期存储的电子文档的访问的 方法，所述方法包括：针对多个文件类型中的每个文件类型，由处理器跟 踪能够访问每个所述文件类型的已安装软件程序的数量计数；由所述处理 器存储指示所跟踪的已安装软件程序数量的数据；由所述处理器判定用户 何时尝试卸载所跟踪的已安装软件程序之一；以及由所述处理器至少部分 地基于所存储的数据和卸载尝试的判定，向所述用户通知所尝试的卸载的 至少一个结果。

在另一实施例中，提供一种计算机可读存储介质，所述计算机可读存 储介质有形地包含可由计算机执行以确保对长期存储的电子文档的访问的 指令程序，当执行时，所述指令程序执行以下步骤：针对多个文件类型中 的每个文件类型，跟踪能够访问每个所述文件类型的已安装软件程序的数 量计数；存储指示所跟踪的已安装软件程序数量的数据；判定用户何时尝 试卸载所跟踪的已安装软件程序之一；以及至少部分地基于所存储的数据 和卸载尝试的判定，向所述用户通知所尝试的卸载的至少一个结果。

在另一实施例中，提供一种用于确保对长期存储的电子文档的访问的 计算机实现的系统，所述系统包括：跟踪元件，其被配置为针对多个文件 类型中的每个文件类型，跟踪能够访问每个所述文件类型的已安装软件程 序的数量计数；存储元件，其被配置为存储指示所跟踪的已安装软件程序 数量的数据；判定元件，其被配置为判定用户何时尝试卸载所跟踪的已安 装软件程序之一；以及通知元件，其被配置为至少部分地基于所存储的数 据和卸载尝试的判定，向所述用户通知所尝试的卸载的至少一个结果。

附图说明

当结合附图阅读下面的详细描述时，本发明的各种目标、特征和优点 将对本领域技术人员变得显而易见，这些附图是：

图1和2是示出与传统文档支持相关的实例关系的示意图；

图3是示出根据一个实施例的操作的实例时间线示意图；

图4是示出根据一个实施例的潜在长期益处的实例时间线示意图；

图5是示出根据一个实施例的操作的示意图；

图6示出根据一个实施例的系统的框图；

图7-9示出根据一个实施例的各种高级数据库模型实例；

图10示出根据一个实施例的图6中的阈值B活动的各种因素；

图11示出根据一个实施例的样例群体数据集的示意图；

图12-16示出根据一个实施例的与文件类型可读性相关的各种图形实 例（注意，在具体实现中，各区域可通过颜色而非这些图中的阴影来描绘）；

图17-22示出根据一个实施例的与文件类型可读性相关的各种驾驶舱 仪表板型（cockpit dashboard-type）实例（注意，在具体实现中，各区域 可通过颜色而非这些图中的阴影来描绘）；

图23示出根据一个实施例的操作的框图；

图24-26示出根据一个实施例的操作的框图；

图27-29示出根据一个实施例的可读性支持矩阵的多个实例屏幕截图；

图30示出根据一个实施例的方法的流程图；

图31示出根据一个实施例的系统的框图；

图32示出根据一个实施例的系统的框图。

具体实施方式

在一个实例中，一个或多个系统可提供自动确保对长期存储的电子文 档的访问。在另一实例中，一种或多种方法可提供自动确保对长期存储的 电子文档的访问。在另一实例中，一种或多种算法可提供自动确保对长期 存储的电子文档的访问。

此处描述用于确保只要实体内的文档存留，便可访问这些文档的机制。 传统技术解决了需要存储“何种文档”以及“存储多长时间”的问题。各 个公开的各实施例假设用户以当前的“技术水平”存储文档，因此，这些 实施例创建文档与用于创建/修改/读取文档的程序之间的链接。一旦创建链 接，公开的各种技术便可用于监视何时从各种计算设备卸载所链接的程序， 从而使得能够发出通知和/或采取直接操作（例如，当程序数减少到影响所 链接文档的可读性的点）。

现在参考图3，其中示出根据一个实施例的实例操作。

更具体地说，在当前时间（今天的时间T₁），（例如，在IBM的全 球纪录管理（WWRM）指南内）定义实体（例如，公司组织）内接受的 文件格式列表。所有长期存储文档的系统仅被允许存储具有这些所接受文 件格式的文档。

此外，在针对特定文件类型的常规文件类型支持结束时（参见T₂）— 即，一旦文件类型的支持到期—所有存储长期可应用文档的系统便实施无 法再上传任何具有此文件类型的新文件的限制。

此外，在常规支持结束（T₂）之后并且在保留时间结束（T₃）之前： 在常规支持结束之后的初期，有些用户仍能亲自打开文件类型。随着时间 流逝，越来越不可能这样做。如果用户无法打开文件，则用户将文件发送 到专用taskid/中心（参阅图5）。该taskid/中心：（a）具有可用基础结构 （例如，旧程序、知识、许可等）；和（b）以适当、支持的格式返回内容 （例如，打印输出、转换为较新的格式、作为支持的图像格式进行转换等）。

最后，再次参考图3，在特定文件类型支持结束时（T₄）：一旦达到 最大所需保留时段（例如，在IBM内，这可通过WWRM计算并触发可 应用WWRM的系统中已知的因素），该文件类型的支持便可最终结束。 例如，这可能是文件类型的常规支持结束之后的数十年。在一个特定实例 中，保留图5中的至少单个专用taskid/中心（或者为了备份，可能保留更 多）将使得大型实体能够访问全部所需的文档，并且还能使所需的基础结 构成本保持最低。

现在参考图4，其中示出根据一个实施例的潜在长期益处的实例时间 线示意图。更具体地说，如图所示，该实例针对文件格式LOTUS123假 设各个机制的实现回到1985年。该实例进一步假设将针对1994年签订的 长期租赁合同存储一份与审核相关的重要价格计算表（常规文件类型支持 2002年到期）。进一步如图所示，WWRM中定义的最大保留时段包括生 效的租赁合同的生命周期，以及保留代码增加的8年。这样，该特定实例 文档的生命周期持续23年。

现在参考图6，其中示出根据一个实施例的系统的框图。在该实施例 中，将认识到，电子文件类型变化不定。长期而言，没有人能够提前说明 哪些文件类型将在未来可用（今天很明显的事情，经过一段较长时间会变 得完全不同）。

因此，各种机制为实体提供控制对文件类型（例如，文件类型的可读 性）的访问的能力。为实体提供做出明智决策的能力。这包括能够（从文 件类型的角度来看）对即将到期的文件类型支持做出明智的风险评估。

在其它实例中，各种机制允许使用最小的所需磁盘空间。在其它实例 中，能够将双格式存储（即，将文档存储为一个以上的文件类型）限制为 最少。在其它实例中，能够将嵌入式查看器的使用限制为最少。

仍参考图6，将介绍根据一个实例的通用数据库模型。在该实例中： 需要每个用户的唯一标识符（例如，员工编号）在所有数据库中保持一致； 应用的可读性必须能够被精确地定义；用户组的命名需要一致（或至少跨 所有数据库一致地识别）；从文件类型存储库（FTR）601（可包括数据库）、 样本群体数据库603和工作站资产管理（WAM）605（可包括数据库）到 可读性管理数据库607的更新频率很低（例如，每周发生）。由于本质为 长期存储，因此可接受低更新频率。

在一个特定实例中，从上述数据库进行的更新不一定需要在运行时同 步。在另一特定实例中，后续的监视可每日运行（例如，由于存在不同的 非同步更新以及需要在卸载程序时以此处描述的方式及时通知用户）。

仍参考图6，将更详细地介绍文件类型存储库（FTR）601。在该实例 中，（i）FTR601存储来自所有内容管理存储库的所有文件类型信息（这 包括：文件类型扩展、每种文件类型的文档数量、存储库中每个已定义用 户组的文件类型关联（仅对于启用了记录管理的存储库）：每种文件类型 的保留结束（对于启用了非记录管理的存储库，假设“永远”））；（ii） 在单个表中，FTR601需要包含所维护的数据，这些数据涉及哪些文件类 型可被哪些应用读取（在一个实例中，关系应该是单向关系（例如，文件 类型-应用））—可通过这些声明的总和推导出相反声明—例如（但不限于）： （a）文件类型.csv可被以下程序读取：LOTUS SYMPHONY、APACHE  OPEN OFFICE、MS EXCEL、LOTUS1-2-3；（b）文件类型.doc可被以 下程序读取：MS WORD、LOTUS SYMPHONEY；（iii）应用的可读性 可以是“完全”或“有限”（例如，除了原始程序之外，也可以打开特定 文件类型，但是仅具有有限的能力来正确地解释所有功能（例如，LOTUS  SYMPHONEY可打开LOTUS1-2-3文件，但是其功能受限））；（iv） 为了达到高数据质量，应维护所有数据版本范围（从/至）（哪些应用可读 取哪些文件类型）。

仍参考图6，将更详细地介绍WAM—工作站资产管理605。在一个实 例中，WAM是跟踪工作站上的硬件和软件并将所跟踪的数据存储在存储 库中的工具。在另一实例中，WAM是企业可用于识别给定工作站上安装 哪个软件的硬件/软件数据库。在另一实例中，WAM拉回（判定）用户的 已安装程序（对于特定国家/地区，这可能需要是被动的“拉回”（例如， 仅拉回之前同意的应用列表））。

仍参考图6，将更详细地介绍样本群体数据库603。在一个实例实现中， 针对受影响的内容管理存储库，从用于这些存储库的自动化访问管理工具 提取（例如，经由一个或多个链接）样本群体数据库603。如果到自动化 授权管理工具的链接不存在，则需要定义代表性用户组。

现在参考图6的点A处的处理（相对于GUI仪表板的信息加载）， 例如，注意下面各项：（v）来自工作站资产管理（WAM）、样本群体数 据库和文件类型存储库的数据被载入可读性管理数据库；（vi）可单独加 载来自文件类型存储库数据库的文件类型-可读程序表；（vii）得到的可读 性管理数据库包含至少四个表，如高级数据库模型中所示（参阅图7）； （viii）来自文件类型数据库（FTR）、样本群体数据库和工作站资产管理 （WAM）的入站更新的运行频率可以很低，例如每周一次（频率越大， 电子邮件到用户的周转时间便越短）；（ix）后续的有关用户信息管理的 监视可以每日运行—在一个实例中，载入信息存储库的所有数据信息加载 不必同步并且不必同时运行（即，数据加载可以不同的时间间隔运行）。

现在参考图6的点B（相对于提供给用户的信息），例如，注意下面 各项：（x）用户标识的基础是可读性管理数据库；（xi）可以从地址簿检 索用户电子邮件地址，其中唯一用户标识符（例如，员工编号）是搜索准 则；（xii）当用户尝试卸载或未卸载可读性所需的程序时，自动将声明结 果的电子邮件发送给用户（例如，他无法再读取属于哪个内容管理存储库 的多少文档）；（xiii）与文件类型的可读性信息组合之后，包含信息的电 子邮件还应该向用户显示备选项—完全或有限的备选项—以保持可读性 （该信息的基础来自文件类型存储库（FTR）中有关应用可读性的单独表 的相反声明）；（xiv）一旦经过阈值A，便将信息以电子邮件发送给仍安 装程序的用户。电子邮件应该强调保留已安装程序的重要性—进一步应该 表达当卸载程序时将产生哪些结果（例如，“当您卸载应用XYZ时，将 无法读取具有文件类型.abc的X文档（属于您的用户组DEF）”）。

在一个实例中，阈值A可以是用户/管理员可定义的数量和/或是可定 义的能读取给定文档的已安装程序实例的百分比（例如，阈值A可以是定 义图12所示的舒适区与风险区之间的界限的值）。在一个特定实例中，企 业可能需要被通知何时工作站上仅有50个剩余实例或剩余70%的给定程 序用户可读性。

现在参考图6中的点C（相对于新的/当前格式的数据输入），例如， 注意下面各项：（xv）合并样本群体数据库和工作站资产管理（WAM） 以生成有关哪些用户组已安装到哪一级别，何种程序提供何种可读性的信 息。新的/当前格式的可读性应该高于阈值A。

在另一与阈值A有关的实例中，可能需要警告企业（和/或特定程序的 用户）是否仅剩余为数不多的可读取给定文件的程序实例（可能还需要确 保给定的可读性级别）。在另一实例中，如果新程序在读取给定旧文件类 型方面存在向后可读性，则会增加可读取该文件类型的计算机数量（可能 使该数量高于阈值）。

在另一实例中，阈值A可根据以下方式设计：针对存储数据的数据库 执行标准查询。在一个特定实例中：对已安装应用XYZ的实例数量进行 计数；将该单独确定的数量百分比与预定的阈值进行比较；如果该数量高 于阈值，则不执行任何操作。如果该数量低于阈值，则执行已定义的操作。

现在参考图6中的点D（相对于低于阈值B的方法选择），例如，注 意下面各项：（xvi）应由保留管理员完成经过阈值B时的最终方法选择。 以下各方面会对最终的决策产生巨大影响：（i）可用的备选应用；（ii） 与到期日期关联的剩余文档数量；（iii）存储大小；以及（xvii）因素表可 能有助于保留管理员选择适当的操作（参阅图10）。

在一个实例中，阈值B可以类似于阈值A的方式实现。在一个特定实 例中，阈值B可由用户/管理员可定义的设备数和/或可定义的能够读取文 件类型的实例百分比确定（例如，阈值B可定义图12所示的风险区与危 险区之间的界限）。在一个特定实例中，一旦达到该值，便采取特定操作， 这与上面结合阈值A进行的描述非常相似。

在另一实例中，阈值B可根据以下方式设计：针对存储数据的数据库 执行标准查询。在一个特定实例中：对已安装应用XYZ的实例数量进行 计数；将该数量与预定的阈值进行比较；如果该数量高于阈值，则不执行 任何操作。如果该数量低于阈值，则执行已定义的操作。

在一个实例中，必须在实体级别上确保可读性。尽管可建立用户与文 件之间的有效双向链接，但是用户可能更改，从而可能需要针对实际用户 组的关联。

现在参考图7-9，其中示出根据一个实施例的各种高级数据库模型。更 具体地说，图7示出文件类型存储库（FTR）表701、文件类型存储库（FTR） 表703；工作站访问管理（WAM）表705；以及样本群体数据库表707。 用于联结这些表的关键属性被用圈环绕。这些表的联结还在图8中示出。 最后，图9示出图6中的“点C”的实例数据库模型。

现在参考图10，其中示出根据一个实施例的与图6中的阈值B活动相 关的各种因素。

现在参考图11，其中示出根据一个实施例的样本群体数据集的示意 图。在一个实例中，可基于不同粒度（例如，将存储库的所有用户作为整 体，或者细分为个体用户组）定义该数据集。

如此处描述的，为了评价特定文档的可读性，引入了“可读性指标” 这一概念。在各个实例中，该指标测量针对给定的文档总体（需要链接的 程序才能被读取）存在多少链接的程序。在一个实例中，如此处描述的， 文件的可读性指标应该理想地位于舒适区（在该实例中，风险区可接受， 但应避免危险区——否则将丧失读取文档的能力）。

此处描述的技术是为了：（a）避免进入危险区；（b）在进入危险区 之后离开危险区。

现在参考图12-16，其中示出与文件类型的可读性相关的各种图形实例 （图12示出概览，图13-16示出各种情景）。在这些实例中，可通过已安 装能够读取特定文档类型的所需程序的用户百分比测量文件类型的可读 性。可在不同级别上测量可读性。例如：（a）在常规实体级别上，（b） 向下挖掘每个情景，直到达到特定的文件类型/存储库/用户组—组合粒度级 别。经验法则：实体需要位于最高级别以具有良好的可读性百分比。可接 受针对更多粒度级别的较差可读性作为业务风险（相当于个体用户读取时 所需的时间更长或更繁琐，但是整体仍可用）。

在一个特定实例中，可读性可被分为三组：（a）舒适区：最充足的用 户可读取特定文件类型的文档。无需任何操作；（b）风险区：仍有大量用 户可读取特定文件类型，但是已有众多用户无法读取。这些用户需要帮助。 读取时间可能显著增加；（c）危险区：仅有很少用户能够读取。实体整体 处于丧失读取特定文件类型能力的危险中。需要采取操作。

如此处描述的，可打开特定文件类型的程序越多，该文件类型（例 如，.csv）的可读性就越高。在一个特定实例中，目标是在相应实体存储库 的最大文档保留期内，确保文件类型的可读性。随着可读性百分比的降低， 最终用户读取速度也会降低（这是可接受的，因为旧文档的读取频率通常 会减小）。

如此处描述的，提供了用于监视文件类型的可读性并能够按存储库、 用户组、所有用户和/或文档数量向下挖掘的机制。

现在参考图17-22，其中示出与文件类型的可读性相关的各种驾驶舱仪 表板实例。如图所示，可生成多个驾驶舱仪表板，其中示出给定实体的可 读性健康状况。

在一个特定实例中，向下挖掘的程度越深，便可获得越多用户友好的 驾驶舱仪表板。在另一特定实例中，可以接受向下挖掘视图中的特定区域 保持为红色，即危险区域（在这些图中示出为“X”），只要整个示意图 显示为绿色，即，舒适区域（在这些图中示出为“Y”（风险区域在这些 图中示出为“Z”——对应于黄色））。这例如可表示特定用户组无法再 读取给定文件类型（如果需要读取，则会出现询问是否需要帮助的弹出消 息并该消息被导向能够读取该给定文件类型的用户）。

图17-22示出各种驾驶舱仪表板的具体高级实例。在这些实例中，与 驾驶室仪表板关联的所有值可使用集合论（例如，个体用户可能已安装多 个应用，另外，个体用户可能属于多个组——由于这些交叉，可能需要应 用集合论（即，为了避免不正确的结果））。

现在具体参考图17，在该实例中，示出整个实体仪表板。该仪表板示 出针对文件类型整体的实体可读性健康状况。可根据该高级仪表板判断整 体可读性健康状况（尽管针对给定文件类型显示为绿色——在这些图中示 出为Y（即，位于舒适区），但是某些个体用户可能无法读取特定的文件 类型）。

现在具体参考图18，在该实例中，可使用将来剩余文档的近似数量帮 助判断（例如，由系统管理员判断）是否应转换文件类型（这也有助于确 定转换工作）。

现在具体参考图19（其示出y轴为剩余文档数-x轴为时间的图），在 该实例中，值可通过图形示出，从而显示哪个位置适合文件类型转换，哪 个位置可能出现业务风险（在一个特定实例中，每个文件类型可使用特定 的颜色示出；在另一特定实例中，可示出与每个特定文件类型关联的可读 性区域颜色）。

现在具体参考图20（其使用此处描述的命名“X”、“Y”、“Z”）， 在该实例中，可做出可读性声明，这些声明对于每种文件类型和文档存储 库用户而言更细化（在此方面，例如参考图20的实例和文件类型.bqy—— 不同的内容管理系统可以具有不同的用户组）。因此，在该实例中，可以 导致内容管理系统A的可读性区域处于风险区（例如，27%），而对于同 一文件类型，内容管理系统C的可读性区域可以位于舒适区（例如，63%）。

现在具体参考图21（其使用此处描述的命名“X”、“Y”、“Z”）， 在该实例中，可通过多种方式布置驾驶舱仪表板——例如，亮显有关可读 性健康状况的不同视角。

现在具体参考图22（其使用此处描述的命名“X”、“Y”、“Z”）， 在该实例中，驾驶舱仪表板例如可被向下挖掘到用户组可读性健康状况级 别（在某些国家/地区，进一步的粒度可能需要得到批准）。

现在参考图23，其中示出根据一个实施例的操作的框图。如图23所 示，此操作涉及事件“需要归档或暂停程序才能读取”的发生。更具体地 说，可看出，在步骤2301，在事件发生时检查文件类型存储库以查找完全 可读的程序。此外，在步骤2303，创建要归档或暂停的完全可读程序的建 议列表，在步骤2305，判定要归档或暂停哪个（哪些）程序。最后，在步 骤2307，归档或暂停程序（多个）。

现在参考图24-26，其中示出根据一个实施例的操作的框图。如这些图 24-26所示，此操作涉及优化文件类型的可读性支持标识。更具体地说，可 看出，在步骤2401，用户需要访问特定的文档，但是没有所需的程序。在 步骤2403，用户点击内容管理存储库中doc旁边的“查找可读性”按钮。 在步骤2405，构建可读性支持矩阵（另参阅图25）。在步骤2407，获取 可读性矩阵的值（另参阅图26）。在步骤2409，提示用户选择提供读取文 件帮助的另一用户（例如，参阅图27-29）。在步骤2411，需要帮助以读 取文件的用户判定是否请求帮助。在步骤2413，发送电子邮件（多个）。 在步骤2415，提供响应（多个）。最后，在步骤2418，执行协作。

现在参考图25，可看出，可通过步骤2501（获取各个位置）和步骤 2503（获取各个用户）构建可读性支持矩阵。

在一个特定实例中，可按以下方式构建可读性支持矩阵：用户John 希望在其计算机上读取一文件类型，但是他未安装可读取文件的程序。查 询数据库，从该数据库中存储的内容中找到谁的计算机仍安装有可读取 John需要打开的文件的程序。John所在公司中可能具有多个用户以及多 个计算机程序可打开此文件类型。为John提供具有用户和程序的可能矩 阵，该矩阵中包含能够为其打开该文件类型的用户和程序名。

现在参考图26，可看出，可读性支持矩阵的值可通过以下步骤获取： 步骤2601（获取有关哪些程序可读取文件的关联）；步骤2603（获取属于 同一用户组的用户）；步骤2605（获取属于具有可读性的同一用户组的用 户）；以及步骤2607（按位置排序）。最后在步骤2609，判定是迭代还是 结束。

现在参考图27-29，其中示出可读性支持矩阵的多个实例屏幕截图。更 具体地说，首先参考图27，可看出，可为用户提供图形用户界面以从中选 择联系多方中的哪一方来提供读取文件帮助（在该实例中，可为用户提供 向选定方发送电子邮件的选项，其中未示出可能帮助方的姓名（为保护隐 私），但是示出了位置）。

现在参考图28，其中示出类似于图27的实例可读性支持矩阵（在该 图28中，按响应速度过滤可能的帮助方——可提供指示每个可能的帮助方 的响应速度（例如，历史响应速度）的标记）。

现在参考图29，其中示出类似于图27的实例可读性支持矩阵（在该 图29中，按反馈分级过滤可能的帮助方——可提供指示每个可能的帮助方 的反馈值（例如，历史反馈值）的标记）。

在另一实例中，可维护可读性支持请求的跟踪历史，其目标是为用户 提供更好的反馈。

在另一实例中，可通知管理员何时出现帮助请求，在哪个位置出现和/ 或针对哪个用户组出现。管理员可在后续问题中询问帮助的作用。此过程 可为管理员提供以下信息：例如，是否需要在特定位置上和/或针对特定用 户组执行操作（例如，不考虑特定区中的可读性计算）。

在另一实例中，用于过滤和/或显示可能帮助方的输入参数可包括（但 不限于）：来自给定用户的响应速度、反馈分级和/或历史响应。在一个特 定实例中，基于输入参数的输出可包括权重列表。

在另一实例中，当发出读取文件帮助通知时，系统可记录：（a）帮助 者的响应（例如，接受/拒绝/无响应）；（b）请求与响应之间经过的时间； 和/或可选地记录请求者提供的反馈。在一个特定实例中，该数据可反馈回 分析引擎（例如，软件分析引擎）并用于在将来搜索中对可能的帮助者进 行分级。

现在参考图30，其中示出一种用于确保对长期存储的电子文档的访问 的方法。如该图30所示，该实施例的方法包括：在3001——针对多个文 件类型中的每个文件类型，由处理器跟踪能够访问每个所述文件类型的已 安装软件程序的数量计数；在3003——由所述处理器存储指示所跟踪的已 安装软件程序数量的数据；在3005——由所述处理器判定用户何时尝试卸 载所跟踪的已安装软件程序之一；以及在3007——由所述处理器至少部分 地基于所存储的数据和卸载尝试的判定，向所述用户通知所尝试的卸载的 至少一个结果。

在一个实例中，可按照任何适当的所需顺序执行上述任何步骤。

现在参考图31，在另一实施例中，提供一种用于确保对长期存储的电 子文档的访问的系统3100。该系统可包括以下元件：跟踪元件3101，其被 配置为针对多个文件类型中的每个文件类型，跟踪能够访问每个所述文件 类型的已安装软件程序的数量计数；存储元件3103，其被配置为存储指示 所跟踪的已安装软件程序数量的数据；判定元件3105，其被配置为判定用 户何时尝试卸载所跟踪的已安装软件程序之一；以及通知元件3107，其被 配置为至少部分地基于所存储的数据和卸载尝试的判定，向所述用户通知 所尝试的卸载的至少一个结果；禁止元件3109，其被配置为禁止所述用户 完成所尝试的卸载；提供元件3111，其被配置为向所述用户提供在访问给 定文件类型中的帮助源的指示；以及记录元件3113，其被配置为记录有关 所提供的帮助的历史数据。

在一个实例中，图31的各组件之间的通信可以是双向通信。在另一实 例中，该通信可通过因特网、内联网、局域网、广域网和/或任何其它所需 的通信信道执行。在另一实例中，每个组件可在操作上与其它每个组件相 连。在另一实例中，这些组件的部分或全部在图32所示类型的计算机系统 中实现。

现在参考图32，该图示出根据本发明的一个实施例的计算系统3200 的硬件配置。如图所示，该硬件配置至少具有一个处理器或中央处理单元 （CPU）3211。CPU3211通过系统总线3212与随机存取存储器（RAM） 3214、只读存储器（ROM）3216、输入/输出（I/O）适配器3218（用于将 磁盘单元3221和磁带驱动器3240之类的外围设备连接到总线3212）、用 户接口适配器3222（用于将键盘3224、鼠标3226、扬声器3228、麦克风 3232和/或其它用户接口设备连接到总线3212）、通信适配器3234（用于 将系统3200连接到数据处理网络、因特网、内联网、局域网（LAN）等）， 以及显示适配器3236（用于将总线3212连接到显示设备3238和/或打印机 3239（例如，数字打印机等））互连。

如此处描述的，提供机制以确保可采用以下技术读取文档：（1）在卸 载应用时通知用户结果（例如，向给定用户提供有关多少程序可用于读取/ 执行用户系统上的一个或多个文档的指示，该指示包括有关在用户删除给 定程序的情况下执行/访问文档的风险评估）；（2）跟踪在基础用户群体 上安装的软件程序数量；（3）创建文档与程序之间的链接（例如，创建一 个或多个文档与一个或多个使用文档的程序之间的链接）；（4）跟踪可读 性程序与基础用户群体中文件数量之间的链接；（5）优化能够帮助以当前 格式呈现文档的最终用户列表（例如，使用适当的程序）；和/或（6）记 录有关所提供的帮助的历史数据。

在一个特定实例中，在卸载应用时通知用户结果的机制（参阅上面的 （1））包括：（A）用户选择从其工作站卸载文档呈现应用；（B）执行 检查以判定该程序是否位于观察列表中（例如，通过此处描述的链接技术）； （C）如果应用位于观察列表上，则通知用户删除应用的暗示。

在一个特定实例中：（A）如果应用位于舒适区，则允许在没有中断 的情况下发生卸载；（B）如果应用位于风险区，则提示用户重新考虑卸 载操作（如果用户的工作站上不再安装该程序（例如，因为他更换了工作 站），则以电子邮件通知用户考虑再次安装该程序）；（C）如果应用位 于危险区，则阻止卸载（例如，假设为公司资产）。

在一个特定实例中，跟踪在基础用户群体上安装的软件程序数量的机 制（参阅上面的（2））包括：（A）每个用户工作站上的软件代理检测是 否存在查看目标文档的应用；（B）软件代理更新维护查看目标文档的应 用的安装位置数据的数据库。

在另一特定实例中，假设文档存储库系统存在，则跟踪在基础用户群 体上安装的软件程序数量的机制（参阅上面的（2））包括：（A）监视用 户何时将新文件添加到文档存储库；（B）当添加新文档时：（i）检测其 文件类型（例如，.doc、.fdf、.odf）；（ii）检测每个用户工作站上的已注 册扩展数据库以判定哪些程序可处理该文档类型；（iii）轮询每个用户的 操作系统（OS）以查找程序度量（例如，程序名称、安装日期）并发送到 中央数据库；（iv）可选步骤——使用可根据卸载请求查询的元数据标记 卸载的程序，以便执行操作来通知最终用户（参阅此处描述的通知技术）。

在一个特定实例中，创建文档与程序之间的链接的机制（参阅上面的 （3））包括以下项（操作系统可能需要其它功能来支持这些步骤）：（A） OS监视新文件在文件系统中的创建；（B）当创建新文档时，OS：（i） 将描述哪个程序创建文件的元数据添加到文档的“程序阵列”，如果没有 用于创建文件的程序，则记录与该文件类型关联的默认程序；（ii）将描述 程序安装位置的元数据添加到文档的“程序阵列”（例如，识别用户、机 器、IP地址等）；（iii）将文件名称（例如，具有本地或远程路径）添加 到存储在程序内（或以其他方式与程序关联）的“文档阵列”（或者，在 另一实施例中，递增嵌入的阵列中的文件创建计数器）；（B）当修改或 删除了现有文档时：（i）扫描显示哪个程序创建该文档的元数据；（ii） 适当地更新程序的“文档阵列”——在已存储的情况下，更新路径/位置； 在删除文档的情况下，删除路径/位置；（D）当修改或删除了现有程序时： （i）扫描程序的“文档阵列”并确定适当的操作；（a）如果程序被删除， 则检查文档阵列是否为空——如果不空，则实施“在卸载程序时通知用户 结果的方法”；（b）如果允许卸载程序，则分析程序的“文档阵列”并更 新每个链接的文档的“程序阵列”以指示该程序已被卸载。

在一个特定实例中，跟踪可读性程序与基础用户群体中文件数量之间 的链接的机制（参阅上面的（4））包括：（A）中央服务将查询文档存储 库中的文档并扫描每个文档的“程序阵列”元数据以：（i）确定哪个（哪 些）程序链接到每个文档；（ii）确定这些程序的位置（其存储在“程序阵 列”中）；（iii）确定这些程序的安装状态（其存储在“程序阵列”中）； （B）返回报告，该报告显示与所收集的度量相关的统计信息（例如，文 档与唯一程序安装数量的比率等）。

在一个特定实例中，优化能够帮助以当前格式呈现文档的最终用户列 表的机制（参阅上面的（5））包括：（A）检索能够读取给定文件类型的 程序列表；（B）使用访问管理工具，应用搜索准则来选择可访问文档的 用户群体；（C）使用工作站资产管理工具，根据上面的步骤确定哪个用 户已安装所需的文档读取程序；（D）应用任何适当的排序并为请求者提 供结果矩阵。

在一个特定实例中，记录与所提供的帮助相关的历史数据的机制（参 阅上面的（6））包括：（A）将帮助查看文档的请求发送给用户；（B） 跟踪用户响应（例如，接受/拒绝/无响应）；（C）跟踪请求与解决之间经 过的时间；（D）收集来自请求者的有关其体验的反馈；（E）使用所收集 的历史数据对可能请求者进行更好的分级以用于将来请求。

在其它实例中，可结合文件托管服务使用各实施例。例如，使用不会 施加文件类型限制的文件托管服务（例如，DROPBOX）存储文档的用户 可能需要保持其文档的可读性。保持可读性的可能变型包括（但不限于）： （a）服务提供读取文档所需的软件的临时可下载许可。在这种情况下，服 务提供者维护所需软件的一个或多个许可。当请求者通过软件完成操作或 者经过预定时段时，软件许可到期，已安装版本变得不可用或者自动删除， 许可被返回到池；（b）服务提供对读取文档所需的软件的云实例的访问。 在这种情况下，服务提供者维护所需软件的一个或多个许可。当请求软件 时，服务提供者供应软件的一个实例并使其可用于请求者。当请求者通过 软件完成操作或经过预定时段时，软件实例被删除并且许可被返回到池； （c）服务提供者充当请求者与读取者之间的代理，该读取者具有所需软件 的实例并愿意将此能力提供给请求者。请求者与读取者将就访问文档的条 件达成一致。进一步地，还可以分析是否存在请求者与读取者之间的现有 关联。

在其它实例中，可提供物理工具（例如，硬件组件）的扩展。

如此处描述的，各种实施例可被任何适当的实体使用。在一个实例中， 此类实体可使用一个或多个企业内容管理系统（例如，IBM Content  Manager和/或IBM FileNet P8）。在另一实例中，此类实体可使用/维护 一个或多个档案。

如此处描述的，在各实施例下：用户可信任文档将在整个文档生命周 期内可读；解决方法具有一般特性，与具体的文件格式无关；和/或解决方 法仅需全局地建立一次（也可能为了备份而建立二次）。

如此处描述的，各实施例提供有效双向链接和/或嵌入式查看器。

如此处描述的，各实施例允许电子文档在产品过时之后的很长时间内 可读（例如，20-100年）。通过智能监视，可采取操作以使读取长期存储 的文档所需的程序数高于给定用户社区中已定义的阈值。如果已安装程序 的数量低于另一已定义的阈值，则可采取适用于永久查看选项（例如，转 换或嵌入式查看器）的操作。在各实例中，这些技术使文件大小存储要求 保持最低（因为，在一个实例中，在达到给定阈值之前，文档不进行转换）。 在各实例中，只要给定文档具有良好的可读性指标，这些技术便允许文档 存储采取本机格式。在各实例中，这些技术防止以另一格式额外地存储所 有文档（因此，与其它方法相比，此类技术可需要显著较少的长期存储容 量）。

在一个实施例中，一种实施方式（涉及两个相互协调的元件）如下所 示：在实体内，建立有关哪些当前文件类型需要长期可读的指南；当供应 商/发布者对特定文件类型的常规支持结束时（或在实体定义（例如，基于 公司理性）的另一时间处），应该向实体内的所有长期存储库报告该特定 文件类型的支持结束。在一个特定实例中，可使用中央功能读取不支持的 文件类型并将采取支持格式的文档返回给用户。

如此处描述的，各实施例可在以下上下文中执行操作：（a）计算机： 软件；（b）计算机：存储或存储管理；（c）消费设备或电器：媒体软件： 内容应用；（d）软件：数据访问、分析和交付；（e）文档和Web内容管 理；和/或（f）信息管理：企业内容管理系统。

如此处描述的，各实施例可提供：GUI仪表板；监视；和/或归档后的 文件转换。

如此处描述的，各实施例可提供：在识别到实际的或已尝试的程序卸 载之后（例如，在更改工作站之后），向用户发送电子邮件（和/或以其它 方式通知，例如通过警告消息或提示）；使用户知道结果（例如，如果用 户知道结果，该用户便能够并愿意重新安装程序，这样可读性再次提升）。

如此处描述的，各实施例可维护可读性，而不考虑谁创建给定文档（例 如，文档创建者不一定是长期需要再次读取该文档的用户）。

在一个实施例中，提供一种用于确保对长期存储的电子文档的访问的 方法，所述方法包括：针对多个文件类型中的每个文件类型，由处理器跟 踪能够访问每个所述文件类型的已安装软件程序的数量计数；由所述处理 器存储指示所跟踪的已安装软件程序数量的数据；由所述处理器判定用户 何时尝试卸载所跟踪的已安装软件程序之一；以及由所述处理器至少部分 地基于所存储的数据和卸载尝试的判定，向所述用户通知所尝试的卸载的 至少一个结果。

在一个实例中，在包括以下之一的用户群体上执行所述跟踪：（a）与 给定组织关联的多个用户中的全部用户；以及（b）与给定组织关联的多个 用户的子集。

在另一实例中，访问每个所述文件类型包括以下操作中的至少一个： （a）读取具有给定文件类型的文档；（b）写入具有给定文件类型的文档， 以及（c）创建具有给定文件类型的文档。

在另一实例中，通过使用至少一个软件代理做出所述判定。

在另一实例中，向所述用户通知所尝试的卸载的至少一个结果包括向 所述用户指示所述用户将不再具有访问给定文件类型的能力。

在另一实例中，所述方法还包括由所述处理器禁止所述用户完成所尝 试的卸载。

在另一实例中，所述方法还包括由所述处理器向所述用户提供在访问 给定文件类型中的帮助源的指示。

在另一实例中，所述方法还包括由所述处理器记录有关所提供的帮助 的历史数据。

在另一实施例中，提供一种计算机可读存储介质，所述计算机可读存 储介质有形地包含可由计算机执行以确保对长期存储的电子文档的访问的 指令程序，当执行时，所述指令程序执行以下步骤：针对多个文件类型中 的每个文件类型，跟踪能够访问每个所述文件类型的已安装软件程序的数 量计数；存储指示所跟踪的已安装软件程序数量的数据；判定用户何时尝 试卸载所跟踪的已安装软件程序之一；以及至少部分地基于所存储的数据 和卸载尝试的判定，向所述用户通知所尝试的卸载的至少一个结果。

在一个实例中，在包括以下之一的用户群体上执行所述跟踪：（a）与 给定组织关联的多个用户中的全部用户；以及（b）与给定组织关联的多个 用户的子集。

在另一实例中，其中访问每个所述文件类型包括以下操作中的至少一 个：（a）读取具有给定文件类型的文档；（b）写入具有给定文件类型的 文档，以及（c）创建具有给定文件类型的文档。

在另一实例中，通过使用至少一个软件代理做出所述判定。

在另一实例中，向所述用户通知所尝试的卸载的至少一个结果包括向 所述用户指示所述用户将不再具有访问给定文件类型的能力。

在另一实例中，其中当执行时，所述指令程序还执行以下步骤：禁止 所述用户完成所尝试的卸载。

在另一实例中，当执行时，所述指令程序还执行以下步骤：向所述用 户提供在访问给定文件类型中的帮助源的指示。

在另一实例中，当执行时，所述指令程序还执行以下步骤：记录有关 所提供的帮助的历史数据。

在另一实施例中，提供一种用于确保对长期存储的电子文档的访问的 计算机实现的系统，所述系统包括：跟踪元件，其被配置为针对多个文件 类型中的每个文件类型，跟踪能够访问每个所述文件类型的已安装软件程 序的数量计数；存储元件，其被配置为存储指示所跟踪的已安装软件程序 数量的数据；判定元件，其被配置为判定用户何时尝试卸载所跟踪的已安 装软件程序之一；以及通知元件，其被配置为至少部分地基于所存储的数 据和卸载尝试的判定，向所述用户通知所尝试的卸载的至少一个结果。

在一个实例中，在包括以下之一的用户群体上执行所述跟踪：（a）与 给定组织关联的多个用户中的全部用户；以及（b）与给定组织关联的多个 用户的子集。

在另一实例中，访问每个所述文件类型包括以下操作中的至少一个： （a）读取具有给定文件类型的文档；（b）写入具有给定文件类型的文档， 以及（c）创建具有给定文件类型的文档。

在另一实例中，通过使用至少一个软件代理做出所述判定。

在另一实例中，向所述用户通知所尝试的卸载的至少一个结果包括向 所述用户指示所述用户将不再具有访问给定文件类型的能力。

在另一实例中，所述系统还包括禁止元件，其被配置为禁止所述用户 完成所尝试的卸载。

在另一实例中，所述系统还包括提供元件，其被配置为向所述用户提 供在访问给定文件类型中的帮助源的指示。

在另一实例中，所述系统还包括记录元件，其被配置为记录有关所提 供的帮助的历史数据。

在其它实例中，可以以任何适当的所需顺序执行此处描述的任何步骤。

所属技术领域的技术人员知道，本发明的各个方面可以实现为系统、 方法或计算机程序产品。因此，本发明的各个方面可以具体实现为以下形 式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、驻留软 件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电 路”、“模块”或“系统”。此外，本发明的各个方面还可以实现为在一 个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质 中包含计算机可读的程序代码。

可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可 以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质 例如可以是—但不限于—电、磁、光、电磁、红外线、或半导体的系统、 装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子 （非穷举的列表）包括：具有一个或多个导线的电连接、便携式计算机盘、 硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程 只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器 （CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。 在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质， 该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括例如在基带中或者作为载波一部分传 播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号 可以采用多种形式，包括—但不限于—电磁信号、光信号或上述的任意合 适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任 何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指 令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包 括—但不限于—无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操 作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言— 诸如Java、Smalltalk、C++等，还包括常规的过程式程序设计语言—诸如 “C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上 执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在 用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器 上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网 络—包括局域网（LAN）或广域网（WAN）—连接到用户计算机，或者， 可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。

此处参照根据本公开实施例的方法、装置（系统）和计算机程序产品 的流程图和/或框图描述本公开的各个方面。应当理解，流程图和/或框图的 每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令 实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其它可 编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过 计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/ 或框图中的一个或多个方框中规定的功能/动作的装置。

也可以把这些计算机程序指令存储在计算机可读介质中，这些指令使 得计算机、其它可编程数据处理装置、或其它设备以特定方式工作，从而， 存储在计算机可读介质中的指令就产生出包括实现流程图和/或框图中的 一个或多个方框中规定的功能/动作的指令的制造品（article of  manufacture）。

也可以把计算机程序指令加载到计算机、其它可编程数据处理装置、 或其它设备上，使得在计算机、其它可编程装置或其它设备上执行一系列 操作步骤，以产生计算机实现的过程，从而使得在计算机或其它可编程装 置上执行的指令提供实现流程图和/或框图中的一个或多个方框中规定的 功能/动作的过程。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法 和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程 图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述 模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的 可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功 能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际 上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及 的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和 /或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬 件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

需要指出，上述内容描述了本发明的一些目标和实施例。本发明可用 于许多应用。因此，尽管描述了特定的布置和方法，但是本发明的意图和 概念也适合于并适用于其它布置和应用。所属领域的技术人员理解，在不 偏离本发明的精神和范围的情况下，可实现对所公开实施例的修改。所描 述的实施例应该被视为仅为了阐述本发明的某些特征和应用。通过以不同 的方式应用所公开的发明或以本领域熟悉的方式修改本发明，可实现其它 有利的效果。此外，此处公开的所有实例均旨在作为示例而非限制。