用于请求并查看预览移动通信设备上的表附件的预览的方法

摘要

描述了一种方法，用于在移动通信设备上预览表附件，并当识别出有兴趣的表内容时，查看和/或从附件服务器中检索整个表。在一个实施例中，在设备上呈现文档附件中得到的每一个表的小型的4×4行/列预览，所述预览具有被限制为请求设备显示能力的单元格内容文本信息。该限制避免了将大量单个单元格内容下载到设备的任意需要。因此，用户能够快速地识别对哪一个表感兴趣，然后请求以点播的方式从附件服务器下载完整的表。关于这一点，优选地，预览表自身还用作到存储在服务器上的完整的表的链接，以利于设备容易地进行检索，以便在电子表格中查看。

说明书

技术领域

下文总的来说针对在移动通信设备上显示内容，更具体地，针对一种在移动通信设备上预览表附件的方法。

背景技术

由于最近设备和移动基础设施所支持的多种服务和功能的增长，移动通信设备在商务和个人用途中正越来越普及。有时被称为移动站的手持式移动通信设备实质上是一种具有无线能力的便携式计算机，并具有各种各样的形式。这些形式包括个人数字助理(PDA)、蜂窝电话和智能电话。在其体积减小便于携带的同时，下载带宽和设备屏幕尺寸的限制对查看具有多个嵌入式表的大型文档带来了挑战，所述表具有大量列和行，用于以表格形式呈现信息。

对于支持附件查看的无线设备，这表示大量信息要下载、需要大量带宽及与其相关的成本。此外，在设备下载完整表的同时，用户必须等待较长的时间段。

由于移动通信设备具有有限的屏幕资源，本领域已知提供一种附件服务器(AS)，用于向无线设备用户传递“点播”的内容，以使带宽和设备CPU/存储器使用率最小化。当无线设备的用户查看使用表的文档附件时，典型地，附件服务器将文档文本(而不是整个表内容)连同可选择链接(例如[Table：N])一起下载到移动设备上的附件查看器(AV)。然后，如果希望，用户可以通过选择链接来检索整个表。通过仅下载文本和到表的链接并向用户提供用于检索或查看整个表附件的选项，由此这种现有架构符合上述点播设计原理。

不幸地，可选择链接(例如[Table：N])没有提供与表的实际内容相关的信息。一些文档大量使用表来呈现信息。实际上，在一些情况下，仅利用包含整个文本内容的表来创建整个文档。当通过前述点播架构在无线设备上进行查看时，仅用大量可选择表链接来表示这些类型的表中心文档。而没有其它任何文本信息。对于这些类型的文档，用户不能确认哪一个表包含与其相关的信息并且应当被检索。因此，否则需要用户检索文档中的一些表，以便识别感兴趣的任意表。因此，这种非相关附件部分的多个下载破坏了在可能的情况下提供点播检索的设计原理。

US2004/0133848公开了一种系统和方法，用于使移动电子设备能够有效地存取信息内容。服务器浏览器通过网络存取信息内容。检索所存取的信息内容并使其适于移动电子设备的呈现。串行器(serializer)根据客户机浏览器动态地格式化适当信息内容。客户机浏览器在移动电子设备上接收并呈现信息内容。对信息内容进行格式化，以便选择性地使查看内容所需的水平滚动最小。在不必保留上下文的情况下，选择性地去除水平滚动的必要性。独立地考虑、并且可以保留、调整大小或替代原始区域的每一个组件或子组件(例如框、表行、表单元格或嵌套表)。在上下文需要比屏幕的可查看区域更宽内容的情况下，保留水平滚动。

WO02/44953公开了一种在无线手持单元上显示表格数据的方法。当请求时，服务器可以提供有关表格数据和显示菜单的信息，以定义要在无线手持单元上显示的表格数据的片段。根据对该信息的无线订户的响应，以定制的方式提供表格数据。

发明内容

根据一个方面，提供了一种方法，用于在移动通信设备上预览表附件，并且当识别出感兴趣的表内容时，查看和/或检索整个表。所述方法包括一种用于预览嵌入在存储于服务器的文档中的至少一个表的方法，包括：在所述服务器中创建表示所述文档的映射的图结构，包括表示每一个所述表的表组件；从移动通信设备向所述服务器发出对所述文档的请求，包括所述设备的显示能力的指示；在所述服务器中迭代所述图结构，针对每一个所述表组件，构造预览表组件并将其作为属性添加到外部组件引用命令中，其中所述预览表组件包括所述表的预定数目的行和列，具有被限制在所述显示能力内的单元格内容文本信息；以及将包括所述预览表组件的所述文档从所述服务器下载到所述移动通信设备，并进行显示。

在一个实施例中，在设备上呈现文档附件中得到的每一个表的小型的4×4行/列预览，所述预览具有被限制在请求设备显示能力内的单元格内容文本信息(例如，典型地，每单元格8-32个字符)，该限制避免了将大量单个单元格内容下载到设备的任意需要，否则该需要会破坏点播架构设计原理。

因此，这里所述的实施例允许用户快速地识别对哪一个表感兴趣，然后请求以点播的方式从附件服务器下载完整的表。关于这一点，优选地，预览表自身还用作到存储在服务器上的完整的表的链接，以利于设备容易地进行检索，以便在电子表格视图中查看。

其它方案和优点对于本领域技术人员是显而易见的，参考附图，下面将更详细地描述结构和操作，并限定其保护范围。

附图说明

通过参考附图，在下文中对优选实施例加以详细说明，其中：

图1是优选实施例可以实践的网络环境的方框图；

图2是根据现有技术的多个表附件的设备屏幕显示；

图3是示出了根据实施例的如图2所示多个表附件的预览的设备屏幕显示；

图4A和4B是分别示出了用于检索并查看图3的预览表附件的菜单命令选项的设备屏幕显示；

图5是示出了图4A和4B的检索表的设备屏幕显示；

图6是示出了文档对象模型(DOM)的基本结构的树形图；

图7示出了图6中DOM结构的顶层；

图8示出了用于字处理文档的一个典型DOM结构；

图9示出了用于表文档的一个典型DOM结构；

图10示出了用于包含图像子文档的字处理文档的典型DOM结构；

图11是示出了利用在移动通信设备上查看的附件来预览表附件的客户机侧处理的流程图；

图12是包含引用表组件的样本文档的DOM结构图呈现，所述引用表组件被添加到DOM结构中，作为外部组件引用(ECR)命令的属性；

图13是示出了用于将表组件构造为图12的引用表组件的预览，并将预览表组件作为属性添加到用于预览表附件的ECR命令上的服务器侧处理的流程图；

图14是图13的处理之后图12中文档的DOM结构图呈现；以及

图15是示出了用于利用其格式特性保持ECR命令和所附加的预览表组件以构造预览表的服务器侧处理的流程图。

具体实施方式

参考图1，示出了可以实践优选实施例的网络环境10。网络环境10包括至少一个移动通信设备12，这些移动通信设备通过无线网络/因特网14与服务器28进行通信，服务器28用于通过防火墙安全服务器29将文档附件下载到设备12。尽管为了演示目的只显示了一个服务器28，本领域的技术人员可以理解：网络环境10能够具有多个这种服务器，用作网络站点或图形下载站点的主机，提供诸如JPEG、TIFF、BMP、PNG、SGI、MP4、MOV、GIF、SVG等图像文件的存取访问。如本领域的技术人员所理解的，无线网络14包括GSM/GPRS、CDPD、TDMA、iDENMobitex、DataTAC网络，或者例如EDGE或UMTS的未来网络，或者是宽带网络，例如蓝牙和802.11的变体。

如上所述，对于使用嵌入表的文档，或对于仅利用表构造的文档，如图2所示，现有的“点播”架构显示了到表的一系列嵌入链接。这迫使用户检索每一个表，以便查看表内容，如果用户只需要来自一个或几个表的信息，则这是一种耗时/耗带宽的操作。

如图3所示，这里所述的表预览特征以“文档查看”方式向用户在移动设备12上呈现表内容的小型预览。具体地，表预览特征显示了嵌入表的前4列/行，以便快速地向用户提供表的内容的印象。为了查看完整的表，预览中的“Table Link”报头用作可选择链接，并且如图4A所示，当点击设备12的轨迹轮时，“Retrieve”从菜单中是可用的。然后，如图4B所示，利用“View”命令可以以“电子表格查看”方式查看完整的表。

最后，如图5所示，在已经从附件服务中成功地检索之后，可以以电子表格查看方式查看完整的表。

在开始表预览特征的客户机侧和服务器侧应用程序的详细说明之前，这里将提供针对要在移动设备12上查看的文档附件的文档对象模型(DOM)结构的描述。

在优选实施例中，对于一个特定的文档类型，附件服务器28利用文件分析蒸馏器(file-parsing distiller)建立存储器内的文档对象模型(DOM)结构，代表该文档类型的一个附件。文档DOM结构被存储在服务器28的高速缓存存储器中，并且能够双向迭代。

如图6所示，基于图的文档DOM结构包括节点和叶。在图中，节点用作叶和节点的双亲，而叶是一个分支的端点。每个节点和叶能够具有一组属性，以规定其本身的特性。例如，一个段节点能够包括规定其校准、格式、文档TOC的入口等的属性。此外，每个节点和叶都具有一个唯一的标识符，被称为DOM ID，以便在文档DOM结构中识别其本身。

文档DOM结构被划分成三部分：顶层、组件(component)和引用。顶层是指文档的根结构，而在组件中构建主文档，引用表示内部或外部子文档部分的文档参考。在下文中详细分析每个部分。

被称为“文档”的文档DOM结构的根节点包含多个子节点，被称为“内容”，每个“内容”代表文档内容的不同方面。每个“内容”节点包含一个或多个“容器”节点，用于存储各种文档全局属性。“容器”节点的子节点是组件，组件存储了文档结构和导航信息。当附件服务器28第一次针对附件文档建立DOM结构时，顶层结构是一个单一的父一子链，如图7所示。

由附件服务器28定义组件的三种类型：文本组件、表组件和图像组件，在一个文档中分别代表了文本、表和图像。下面对文本和表组件进行详细说明，而图像组件结构是一样的。

组件包含命令节点等级。每个命令代表一个物理实体、一个特性或文档中定义的一个引用。对于文本组件，物理实体命令是页、节、段、正文段、注释、脚注和尾注命令，它们根据名称定义了包含在对应文档中的实体。文本组件的特性命令是字体、正文颜色、正文背景颜色、超链接开始/停止和书签命令。文本组件只有一个引用命令，被称为文本引用命令，被用于引用在文档主体中定义的子文档。通常，文本组件的子是页或节命令节点，依次包含一组段命令节点。段命令可以包含用于保持命令类型的一个或多个节点。

利用下面的样本文本文档，其对应的文档DOM结构如图8所示：

  第一段  带有粗体红色的第二正文段

如图8所示说明，作为文本组件的子的节命令包含2个段命令。第一段命令包含一个正文段命令，并且添加该段的正文内容，作为正文段命令的属性。由于段中的文本特性是非常丰富的，第二段命令具有相对更复杂的结构。当每次改变文本特性(字体、文本颜色等)时，创建对应的文本特性命令，并且将改变值作为一个属性被添加到该命令中。随后的正文段命令记录具有与属性相同的文本特性的文本。随着文档结构变得更丰富和更复杂，更多与类型对应的命令被创建，并且文档特性被作为属性添加到这些命令中。

表组件具有与文本组件一样的三种类型的命令，但是命令的名称不同。图9中示出了用于以下样本表格文档的文档DOM结构：

如图9所示，表组件具有表、表行和表单元格的物理实体类型命令，其中表单元格命令可以包含用于文本组件的所有可用命令。在上面示例中，表命令的第一个子表格行命令具有由值0定义的属性“索引”。这表示所指的表行在表中被定义为第一行。图9中最左边的表单元格命令的属性具有相同的含义。

文档有时包括子文档，例如图像、表、文本框等。这里所述的DOM结构利用引用命令来指向这种子文档的图。因此，对于以下样本文档，附件服务器28产生如图10所示的DOM结构：

除了2个引用命令的属性外，图10所示的结构与上文中图8和图9讨论的是相同的。附件服务器28在“样本三”中构建了一个图像，作为分离的图像组件，包含在其自己的DOM分级中的全部的图像数据。在主文档的DOM结构中，这2个引用命令的“Ref”属性的数值指向图像组件，如虚线所示，因此DOM结构将文档的所有部分连接在一起。

现在返回到优选实施例，当从服务器组件(附件服务器(AS)28)请求文档附件转换时，在请求操作时，客户机组件(设备12上的附件查看器(AV)应用程序)向服务器通知其设备和特征特定能力，例如屏幕尺寸、颜色能力和功能性支持。这允许服务器28能够进行对于请求设备12的响应，使带宽使用最优，以及使设备CPU/存储使用率最小，同时保留设备呈现能力(例如，不将颜色呈现数据返回单色设备，反之亦然)。

对于表预览功能，作为附件转换请求的一部分，客户机(AV)通知服务器28，能够示出表预览并且还能够向请求设备12提供分辨率和颜色信息。

如果设备支持，此信息使服务器28能够根据请求设备屏幕信息以及预览表颜色信息向设备12返回UCS(通用内容流)数据，优选地，所述UCS数据包含了针对4×4行/列预览的预览表信息，其中将各个单元格内容限制在8-32字符之间。还将针对完整表的DOM ID返回到设备12上的AV，这允许用户如果需要时请求完整的表以便在电子表格视图中进行查看。

图11示出了设备侧请求处理的流程图。在步骤110，用户通过用户接口的适当操作向设备12请求附件(例如，电子邮件的附件)的完整内容。作为响应，在步骤115，针对配置用于设备显示宽度、高度以及设备能够显示的颜色数目文档附件的第一数据块(例如，典型是3K)，设备AV向AS服务器28发出文档请求。

如果下载请求成功(步骤120的“是”分支)，则客户机侧AV确定表预览是否被包含在第一部分(例如，3K下载数据)中。如果没有(步骤125)，设备显示正常的文本内容(步骤130)。

然后，AV发出对于文档附件的附加数据块的其它任意请求(步骤135处“是”)，处理返回到步骤120。否则，如果已经下载了整个文档(步骤135“否”)，则处理终止(步骤140)。

如果请求从服务器28上的AS下载数据块的请求不成功(即，步骤120处，“否”)，则产生错误标志并显示错误消息(步骤145)，随后处理终止(步骤140)。

在步骤125，如果表预览被包含在所下载的数据块中，如图3所示，则AV显示表预览，并与表链接中的完整表的DOM ID(存储在服务器28中)进行关联(步骤150)。如果数据块中的附加内容(表预览以外的)可用于查看(步骤155)，则显示附加内容(步骤130)。否则，处理流程分路到步骤135。

现在转向服务器侧处理，当文档服务器28接收到包含嵌入表的文档时，如果存储器内DOM结构高速缓存中不存在针对该文档的DOM结构，首先构造所述DOM结构。将文件中的每一个嵌入表构造为外部表组件，并将其添加到DOM结构中，作为外部组件引用(ECR)命令的属性，如下文详细所述。

图12中示出了用于包含嵌入表的以下样本文档的对应DOM结构，其中为了简化图，该DOM结构不包含用于嵌入表的详细图呈现：

如图12所示，将表组件作为属性“Ref”添加到外部组件引用命令(ECR)，所述表组件是主文档的DOM图结构中的节点。

在步骤135，图13的服务器侧处理开始，以便通过整个文档DOM结构130进行迭代。假设DOM结构的非迭代剩余部分仍包含命令(步骤140)，迭代下一个命令(步骤145)。否则，处理结束(步骤150)。如果处理遇到ECR命令(步骤155)并且正引用的组件是表(步骤160)，则处理构造表组件(步骤165)，作为引用表组件的预览。将该预览表组件作为属性添加到ECR命令中(步骤170)，如图14所示。

预览表组件只包含有关引用表的部分信息。默认地，如上所述，预览表优选地最多只具有原始表的4行和4列，每一个表单元格包括最多16个字符。但是，本领域的技术人员可以理解，表的行、列以及表单元格字符的数目是可配置的，可以在转换请求中动态地进行设置。此外，在预览表组件中保留表格式信息。

在构造了预览表组件之后，如上所述，将其作为属性添加到原始ECR命令中。在转换请求的响应和得到DOM图构造期间，附件服务器28利用其格式特性保持ECR命令和所附加的预览表组件。图15的流程图描述了以下步骤：利用所需格式特性，保持图14的文档DOM结构中的ECR命令和所附加的预览表组件。

在变量的初始化(140)之后，如图14所示，服务器处理迭代从ECR命令中提取的引用表组件(步骤145)。假设保留了要迭代的命令(步骤150)，确定下一个命令是表行命令(步骤160)，表单元格命令(步骤165)、正文段命令(步骤170)，或确定表单元格字符索引(m_iCharIndex)是否小于每一个表单元格中字符的最大数目(kiMaxCellChar)。如果这些确定的每一个结果都是“否”，则处理流程返回步骤150。另一方面，如果不存在其它命令，则处理结束(步骤155)。

如果下一个命令是表行命令(步骤160)，在步骤180确定表行索引(m_iRowIndex)是否超出了预览表中行的最大数目(kiMaxRow)。如果没有，则创建表行命令，并将来自原始表行命令的属性复制到新表行命令中(步骤185)，递增表行索引(m_iRowIndex)(步骤190)，并复位表单元格索引(m_iCellIndex)和表单元格字符索引(m_iCharIndex)(步骤195)，并将新命令添加到预览表DOM结构等级中(步骤200)。

如果下一个命令是表单元格命令(步骤165)，在步骤210确定表单元格索引(m_iCellIndex)是否超出了预览表中单元格的最大数目(kiMaxCell)。如果没有，则创建表单元格命令，并将来自原始表单元格命令的属性复制到新表单元格命令中(步骤215)，递增表单元格索引(m_iCellIndex)(步骤220)，并复位表单元格索引(m_iCellIndex)(步骤225)，并将新命令添加到预览表DOM结构等级中(步骤200)。如果在步骤210中表单元格索引(m_iCellIndex)没有超出预览表中单元格的最大数目(kiMaxCell)，则处理流程返回步骤150。

如果下一个命令是正文段命令(步骤170)，在步骤230确定表单元格字符索引(m_iCharIndex)是否小于每一个单元格中字符的最大数目(kiMaxCellChar)。如果是，则创建正文段命令(步骤235)，在步骤140复制来自原始正文段命令的文本，要复制的文本量是原始正文段中的字符数与(kiMaxCellChar-m_iCharIndex)中较小的一个。在步骤245，将复制的文本作为属性添加到新正文段命令中，其中m_iCharIndex.+＝复制的字符的数目。然后，将新命令添加到预览表DOM结构等级(步骤200)。在步骤230，如果表单元格字符索引(m_iCharIndex)不小于每一个单元格中字符的最大数目(kiMaxCellChar)，则处理流程返回步骤150。

如果在步骤175表单元格字符索引(m_iCharIndex)小于每一个单元格中字符的最大数目(kiMaxCellChar)，则创建与原始文档中相同类型的命令(步骤250)。然后，将该新命令添加到预览表DOM结构等级中(步骤200)。

总而言之，由于在DOM结构中高速缓存用于表组件的预览表，作为对应ECR命令的属性，略微增大了存储器消耗。然而，通过消除对于重复文件转换请求的表组件的额外迭代，略微减少了处理时间。

通过阅读优选实施例的该描述，本领域的技术人员可以设想变体和可选实施例。

确信所有这种变体和可选实施例处于所附权利要求的范围之内。