Secondary lazy-accessible serialization of electronic content

FIELD

0001This application relates to a method and system to enable as-needed loading of electronic content, and, in one example embodiment, to enable as-needed loading of electronic content from a serialization of differing granularity or format from an in-memory representation of the electronic content.

BACKGROUND

0002In recent years, a number of computerized applications for storing, retrieving, and displaying electronic content have come into wide use. With the advent of object-oriented and object-based paradigms throughout the software industry, the electronic content processed by such programs has been increasingly conceived in terms of a collection of separate objects, each object representing a particular content element, and the various objects structured to form the overall electronic content by being interconnected through a graph of linking data.

0003One example of electronic content conceived of as being composed of content elements encapsulated or described by objects is the ADOBE® Portable Document Format (PDF). In a PDF document, various content elements, such as pages, fonts, color descriptors, graphical elements, and so forth are represented by discrete objects within the document.

0004Representing electronic content as a collection of interconnected objects encapsulating content elements allows for comparatively efficient processing when the electronic content is to be written out to, or read in from, a serialized form such as for example a file providing random-access capability. However, if a new storage format, such as one in which the electronic content is divided into a number of separate serializations, is to be used, significant new programming code is typically needed to handle the translation between the new storage format and the internal data structure by which the content is rendered and/or edited. In addition, a storage format constructed of several serializations may not be conducive to on-demand or “lazy” loading. The inability to be able to do “lazy access” in rendering or otherwise making an electronic content accessible for in-memory manipulation typically causes the user to be made to wait for the entire electronic content to be loaded before being able to view, edit, or access any part of the content.

BRIEF DESCRIPTION OF DRAWINGS

0005Some embodiments are illustrated by way of example and not limitation in the Figures of the accompanying drawings in which:

0006<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example system for reading and writing electronic content to and from a second serialization, according to an example embodiment.

0007<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart illustrating a method for serializing a portion of a node-and-link data structure storing electronic content, according to an example embodiment.

0008<figref idref="DRAWINGS">FIGS. 3-5</figref> is a block diagram illustrating an example of the partial serialization of an example data structure, according to an example embodiment.

0009<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating a further process for serializing a portion of a node-and-link data structure, according to an example embodiment.

0010<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram providing a further illustration of a process of serializing a portion of a node-and-link data structure, according to an example embodiment.

0011<figref idref="DRAWINGS">FIGS. 8 and 9</figref> are flowcharts illustrating a method in which a portion of data structure serving as a binary search tree may be transformed into information contained in serialization omitting internal nodes, according to an example embodiment.

0012<figref idref="DRAWINGS">FIGS. 10, 11A</figref> and <b>11</b>B are block diagrams illustrating a process for serializing a portion of a node-and-link data structure in the form of a linked list into a serialization in which the information from which the linked list node-and-link representation may be reconstructed, according to an example embodiment.

0013<figref idref="DRAWINGS">FIGS. 12 and 13</figref> are flowcharts illustrating a method in which a portion of data structure structured as a linked list may be transformed into information in a tree-structured organization contained in a serialization, according to an example embodiment.

0014<figref idref="DRAWINGS">FIGS. 14 and 15</figref> illustrate an example of serializing an electronic document stored in a node-and-link representation into a group or package of seven interrelated serialization files, according to an example embodiment.

0015<figref idref="DRAWINGS">FIG. 16</figref> is a flowchart illustrating in overview a process for deserializing a portion of electronic content, according to an example embodiment.

0016<figref idref="DRAWINGS">FIG. 17</figref> is a further flowchart illustrating certain details of a process for deserializing a portion of electronic content, according to an example embodiment.

0017<figref idref="DRAWINGS">FIGS. 18-25</figref>, illustrate how the process of <figref idref="DRAWINGS">FIG. 16</figref> and/or the process of <figref idref="DRAWINGS">FIG. 17</figref> may be used in a process to construct a node-and-link data structure from a set of serializations, according to an example embodiment.

0018<figref idref="DRAWINGS">FIG. 26</figref> shows a diagrammatic representation of machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.

DETAILED DESCRIPTION

0019In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.

0020Embodiments may, for example, be implemented as a stand-alone application (e.g., without any network capabilities), a client-server application or a peer-to-peer (or distributed) application. Embodiments may also, for example, be deployed by Software-as-a-Service (SaaS), Application Service Provider (ASP), or utility computing providers, in addition to being sold or licensed via traditional channels.

0021Introduction

0022For the purposes of this specification, the term “electronic content” shall be taken to include any digital data that may be presented to or accessed by a consumer (e.g., visually or audibly presented) and may include an electronic document, page-descriptive electronic content such as a page-descriptive electronic document, media stream, web page, hypertext document, image, digital video, digital audio, an animation, merely for example. A “content element” shall include any part or share of electronic content that is defined or is discernable as a part or share. For example, a content element may be automatically discerned from a characteristic of the content element itself (e.g., a paragraph of an electronic document) or may be manually defined by a user (e.g., a user-selected collection of words in an electronic document, a user-selected portion of a digital image). Examples of content elements include portions of a page-descriptive document or other electronic document, such as, for example, pieces of electronic text or other material within the electronic document, portions of media streams such as sections of digital video or frames or sets of frames of digital video or digital audio, segments or frames of animations, and various elements presentable or accessible by users within electronic content, and the like. Content elements may include empty content, for example an electronic document may include a blank page; the content of the blank page, namely any data indicating its blankness, may in some embodiments be considered as a content element, namely an empty content element. Content elements may include format data such as, for example, position information describing the placement of other content element(s), or information specifying colors or fonts to be used in rendering other content element(s).

0023For the purposes of this specification, the term “page description language document” may include a page-descriptive document that is stored in one or more files or other storage units. Such files may, in an example embodiment, be coded in a language suited for describing a rendition of documents (e.g., in a manner in which the documents may be rendered into a set of print pages).

0024For the purposes of this specification, the term “rendering” includes presenting or making accessible electronic content or content elements to be perceived, viewed, or otherwise experienced by a user, or be made available for further processing, such as, for example, searching, digesting, printing, analyzing, distilling, or transforming by computational processes that need not include processing the intrinsic data structure describing the electronic content or content element. Whether a content element associated with an electronic content is included in the rendering of the electronic content may, by default, be determined by whether or not the content element is active.

0025For the purposes of this specification, the term “data structure representing electronic content” may include any arrangement of data into related and identifiable pieces to facilitate rendering and/or processing of the electronic content.

0026For the purposes of this specification, a “node-and-link representation” may include a data structure in which parts or segments of the electronic content are stored or otherwise associated with identifiable objects (e.g., nodes) and the relationships between the various content elements stored in the nodes are represented by links. The links may serve to connect or join nodes into a configuration and may correspond to relationships between the content elements stored at the respective nodes.

0027For the purposes of this specification, the term “inter-node link” may include a link in the node-and-link data structure between two nodes. In certain example embodiments, the two nodes may be stored within a memory randomly accessible by a computer.

0028For the purposes of this specification, the term “external link” may include data associated with a node that is stored as part of a data structure in a node-and-link representation, but which indicates that a second node to which the node is connected is constructible from a serialization. The external link may include data identifying the serialization from which the second node may be constructed and may include other data facilitating the construction and/or identification of the second node constructible from the serialization.

0029An inter-node link may be unidirectional, in which case it may be traversed by a computational process in one direction from a particular node (which may be termed the “source node”) to another node (which may be termed the “sink node”), or an inter-node link may be bidirectional—traversable starting from either of the nodes it connects. An inter-node or external link may be said to be “incident” to a node if it connects to that node. In some embodiments, links may be extrinsic to the data object describing the node, and in some embodiments, links may be part of the data object describing their source node.

0030For the purposes of this specification, the term “content portion” may include any portion of an electronic content, such as for example a combination, grouping, or collection, whether user-defined or not, of one or more content elements.

0031For the purposes of this specification, the term “semantically-defined content portion” may include a portion of an electronic content which may be comprised of one or more content elements that are related to one another according to some semantic, conceptual, symbolic, or semiotic relationship.

0032When a data structure representing electronic content is stored in a memory or other random access device, it may be desirable to write out the electronic content onto a storage medium, such as a disk in which files are arranged in a sequential data organization. This process of transforming from a data structure suitable for random access within a memory to a data structure suitable for storage on a computer-readable medium in a sequential or serial organized file may be termed “serializing” the data structure. The resulting file or other representation stored on the computer-readable medium may be referred to as a “serialization” of the data structure. Serialization may occur with respect to an entire data structure, or with respect to some part or portion of a data structure.

0033For the purposes of this specification, the phrase “constructible from a serialization”, as may be applied to one or more nodes, inter-node links, or external links, may indicate that, given a serialization, and in some embodiments, further information intrinsic or extrinsic to this serialization, the node(s) or link(s) may be constructed from information contained in the serialization. In this specification the term “reconstructible” is also used in contexts in which prior serializing of the node(s) or link(s) is also being discussed or alluded to.

0034In processing or otherwise accessing or carrying out computations with respect to a data structure organized in a node-and-link representation, the term “signifier node” may, for purposes of this specification, include a node that contains content elements or other data that either alone or in combination with data stored in other nodes permits a computer or other processing module to determine that the node is part of a sub-structure of the data structure corresponding to a piece of semantically-defined content, such as a semantically-defined content portion.

0035For example, suppose that an electronic document, including a table of contents and one or more pages, is stored in a memory in a node-and-link representation. Suppose further that it is desired to access the table of contents. In an example node-and-link representation, the table of contents may be stored within a number of nodes, with each table of contents entry stored in a separate node, and a single table of contents root node including data identifying it as the root node. In this example, where the semantically-defined content portion is the table of contents as a whole, the table of contents root node may serve as a signifier node to allow a computer to identify the portion of the electronic document corresponding to the table of contents by examining the table of contents root node, and thence following links attached or incident to that root node to access the table of contents entry nodes.

0036Thus, a computer may locate or distinguish the set of nodes in a node-and-link representation data structure that store a semantically-defined content portion by identifying a signifier node and the set of nodes connected either directly or indirectly to that signifier node. A semantically-defined content portion stored within a node-and-link representation may include one or more signifier nodes.

0037In the process of serializing an electronic content stored in a node-and-link representation, it may be desirable to divide the node-and-link representation into a number of components, each component corresponding to a semantically-defined content portion of the electronic content as a whole. These serializations may store the electronic content in representations differing from the node-and-link representation from which the serializations were derived. In some embodiments, the serializations may also be themselves structured in a node-and-link representation format that differs from the node-and-link representation from which the electronic content portions were previously serialized. In some other embodiments, the serializations may store the electronic content portions in a representation that is not substantially a node-and-link representation, but from which the original node-and-link representation may be reconstructed.

0038When a serialization is to be used to facilitate the reconstruction of the node-and-link representation from which it was originally derived or serialized, the serialization may include one or more types or fields of data that facilitate, either by themselves or in some embodiments, in combination with data stored in or associated with other serializations, such reconstruction. Some examples of such reconstruction-facilitating data may include information describing the content portion stored in the serialization, information describing the format of the serialization, information describing the content of the serialization, information serving as a header for the serialization, a type indication such as, for example, a file name extension that may indicate the type of the serialization, an identifier of the serialization such as, for example, a file name, and combinations of these types of information.

0039Example System for Secondary Electronic Content Serialization Reading and Writing

0040<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system for reading and writing electronic content to and from a second serialization, according to an example embodiment. The system of <figref idref="DRAWINGS">FIG. 1</figref> includes three components: a main application <b>100</b> such as an electronic document editing and rendering system, a storage device <b>104</b> such as a hard disk or other mass storage device, and a memory <b>102</b>. In some embodiments, the main application <b>100</b> such as, for example, a document editing and rendering application may include a number of components or modules. These modules include a rendering module <b>106</b>, an editing module <b>110</b>, a ‘document object model’-type application programmer interface (API) <b>108</b>, and a reader module <b>118</b>. In addition three other modules are illustrated in <figref idref="DRAWINGS">FIG. 1</figref>: a content processing module <b>130</b>, a serializing module <b>132</b> and a deserialization module <b>126</b>. These modules may be included within the main application <b>100</b>, or may be separate applications or processes that are callable or invocable by the main application <b>100</b> and/or by other applications. The system illustrated in <figref idref="DRAWINGS">FIG. 1</figref> may also include an output device <b>105</b>, such as for example a computer monitor, video card or other device or module capable of receiving data and presenting it, or preparing it to be presented to a user.

0041For purposes of illustration, the memory <b>102</b> may contain a node-and-link data structure <b>112</b> (indicated by a surrounding dashed oval), in a node-and-link representation including, for example, node <b>114</b>. The memory <b>102</b> may also contain a node lookup table <b>128</b>, whose function is described below.

0042The rendering module <b>106</b> may use the ‘document object model’-type API <b>108</b> to retrieve information describing electronic content from the memory <b>102</b>, such as electronic content stored in the data structure <b>112</b>. The rendering module <b>106</b> may process the data or information contained in the data structure <b>112</b> as accessed through the ‘document object model’—type API <b>108</b> and may, in some embodiments, process that information into a form suitable for presentation to a user, in order to relay information as formatted and/or processed to output device <b>105</b>. In some embodiments, the main application <b>100</b> may include an editing module <b>110</b> that may be used to edit the electronic content represented by the data structure <b>112</b>, with the resulting changes in the electronic content being updated into the data structure <b>112</b>, in some embodiments, via the ‘document object model’-type API <b>108</b>.

0043The editing module <b>110</b> may access the electronic content stored in data structure <b>112</b> both for reading, and for modification of the data structure <b>112</b>, via the ‘document object model’-type API <b>108</b>.

0044The reader module <b>118</b>, which may in some embodiments be part of the main application <b>100</b>, may be used for accessing one or more files <b>116</b> that may represent or store electronic content in a further node-and-link representation that is substantially similar to the node-and-link representation of the electronic content as it may be represented by the node-and-link representation data structure <b>112</b> as stored in memory <b>102</b>. The reader module <b>118</b> may serve to read from files formatted in such a node-and-link representation, such as file <b>116</b> and store the electronic content from those files into memory <b>102</b> in a node-and-link representation substantially similar to the node-and-link representation of the file from which the electronic content was read.

0045A content processing module <b>130</b>, which may in some embodiments be a part of the main application <b>100</b>, and a serializing module <b>132</b>, which may also be a part of the main application <b>100</b>, are in some embodiments responsible for storing electronic content represented in a node-and-link representation into a serialization formatted differently from the node-and-link representation <b>112</b> in which the electronic content may be stored in memory <b>102</b>. The content processing module <b>130</b> may in some embodiments access the data structure <b>112</b> representing an electronic content and identify, from the data structure <b>112</b>, a number of data structure portions representing semantically-defined content portions of the electronic content. The operations of the content processing module <b>130</b> are described in more detail below. The serializing module <b>132</b> may, with input from the content processing module <b>130</b>, serialize portions of the structure <b>112</b> into one or more serialization files <b>122</b> and <b>124</b> a different representation from the data structure <b>112</b>. These serialization files may be contained in a package <b>120</b>, stored, in some embodiments as sub-files of the package. The package <b>120</b> may be, for example, a compressed storage file, such as for example a ZIP or WinZip file, or a directory sub-tree of a directory hierarchy of the storage device <b>104</b>. Serialization files <b>122</b> and <b>124</b> may be stored on a storage device <b>104</b>.

0046In referring to <figref idref="DRAWINGS">FIG. 1</figref>, it will be appreciated that a number of pictorial conventions are present which are further utilized throughout this specification. Illustrations of node-and-link representation data structures are illustrated such as within the file <b>116</b> and within the memory <b>102</b> in which nodes are represented by circular glyphs (e.g., node <b>114</b>) while inter-node links are represented by arrows indicating the direction of the link or association. By contrast, serializations in which information is stored in a representation differing from the node-and-link data structures representing electronic content are shown using rectangular dashed nodes and dashed links to suggest that the nodes and links themselves are not explicitly stored as such in the files in which they are shown, but rather that information from which those nodes and links may be reconstructible, such as by deserialization module <b>126</b>, is stored in those files. For example, the package <b>120</b> includes two serialization files: the file <b>122</b> and the file <b>124</b>. The file <b>122</b> has the file name “X” while the file <b>124</b> has the file name “W”. A small dotted arrow that contains the letter “W” is illustrated in the file <b>122</b>. This arrow represents an external link between a node that is constructible from the data in file X and a node constructible from the file <b>124</b>. The processes for generating, and reconstructing node-and-link representation from serializations such as those illustrated in package <b>120</b> is described below.

0047Example Methods for Generating Serializations

0048In the following paragraphs, a number of example methods and processes are described for generating, for electronic content stored in data structures making use of node-and-link representations, one or more serializations, according to example embodiments. These serializations may use a different representation format from the node-and-link representation of the internally stored data structure.

0049There are a number of reasons why representations used in the serializations may be more appropriate to the serialization than the node and link representations. For example, a node and link representation may not be suitable a representation for some processing applications nor may it be suitable for a human to create or read. Node and link representations may be in a binary format, while a serialization may be in a more textual format and thus more amenable to text tools such as editors. For example, in an electronic document a paragraph of text may be more easily represented in a serialization by a string of characters (such as to facilitate human reading and editing) whereas in a machine-internal representation it may be more convenient (e.g., for purposes of rendering) store it as a node and link structure, for example, where each line of text is a node and the nodes are linked together to form the sequence of lines that forms or constitutes the paragraph being represented by the node and link structure.

0050Furthermore, there may be a strong desire by developers to represent as much information as possible in a markup language (as may be used in a serialization) such as the extensible markup language (XML) to facilitate processing of the serialization by common tools.

0051In some embodiments, node-and-link representations may contain information (e.g., inter-node links) that facilitate optimizing computational operations but may complicate manipulation. For example, a list of items may be represented in a node-and-link representation as a doubly-linked list of items to facilitate more rapid processing or searching in a computer memory where links may be maintained despite changes. On the other hand, in a serialization the list of items may be represented as a serial list without explicit links since the ease of editing the serialization rather than computational efficiency may be more of a factor in serializations.

0052In addition, the organization of the information (e.g., describing an electronic content) in the serialization may be more suited to incremental load because, for example, the electronic content may be divided into multiple files based on expected access patterns in the process of rendering or otherwise processing the electronic content.

0053In addition, data import/export formats may be easier to generate in text-based formats,

0054<figref idref="DRAWINGS">FIG. 2</figref> is an overview flowchart of a method <b>200</b> to serialize a portion of a node-and-link data structure storing electronic content, according to an example embodiment. At block <b>202</b>, a portion of the data structure that represents a semantically-defined content portion of the electronic content represented by the data structure is selected. At block <b>204</b>, the selected portion of the data structure is serialized into a first serialization. The first serialization represents the portion of the data structure in a representation differing from the node-and-link representation of the portion of the data structure. The first serialization includes information facilitating the reconstruction of the node-and-link representation of the portion of the data structure.

0055It will be appreciated that the method <b>200</b> may be repeated several times with respect to a complete data structure representing an electronic content so that all of the semantically-defined content portions of the data structure are each stored, for example as separate serialization files, into a package <b>120</b> or other aggregation in a storage device <b>104</b>.

0056In some embodiments, block <b>202</b>, in which a portion of the data structure is selected, may include further intermediate processing. In some embodiments the content processing module <b>130</b> may traverse or otherwise examine the data structure and in so doing recognize content stored in one or more signifier nodes as being part of a semantically-defined content portion. Once the content processing module <b>130</b> has recognized one or more signifier nodes that signify the presence of a semantically-defined content portion, the content processing module <b>130</b> may identify the set of nodes connected either directly or indirectly to the signifier node(s). This set of nodes may include the information representing content elements that are semantically-related to the information in the signifier nodes. Finally, the content processing module <b>130</b> may identify a set of links (e.g., inter-node links and/or external links) that are incident to the set of nodes identified as connected to the signifier node(s). This portion of the data structure (which may include one or more signifier nodes, the set of other nodes connected indirectly or directly to the signifier nodes and the set of links incident to the set of nodes) may be taken to represent the portion of the data structure that contains a semantically-defined content portion. Once this portion has been selected, the serializing module <b>132</b> may serialize this portion.

0057The method <b>200</b> illustrated in <figref idref="DRAWINGS">FIG. 2</figref> may include, as part of the selection of a portion of the data structure in block <b>202</b>, the identification of the nodes that are included and excluded from the portion of the data structure that is to be serialized at block <b>204</b>. The portion of the data structure to be serialized may be written out into a serialization and in the process the nodes of the portion of the data structure that is serialized may be removed from the data structure as well as the inter-node links that connect nodes that were so removed. Nodes that are not in the portion that is to be serialized may have inter-node links that connect those nodes in the data structure. In the process of serializing the portion of the data structure, these ‘dangling’ inter-node links may replaced by external links in the remaining, not (yet) serialized portion of the data structure.

0058These external links serve to facilitate the reconstruction of nodes and inter-node links from a serialization when that serialization is read in from a storage device <b>104</b> by a deserialization module <b>126</b>.

0059<figref idref="DRAWINGS">FIGS. 3 through 5</figref> illustrate an example of the partial serialization of an example data structure, according to an example embodiment. A node-and-link representation data structure <b>300</b> is illustrated in <figref idref="DRAWINGS">FIG. 3</figref> as may be stored in memory <b>102</b>. Among the 11 nodes illustrated in the data structure <b>300</b> are node A <b>312</b>, B<b>314</b>, C<b>316</b>, D<b>310</b>, E<b>306</b> and F<b>308</b>.

0060Suppose, for purposes of example, the three nodes D <b>310</b>, E <b>306</b> and F <b>308</b> are included along with their incident links in a semantically-defined portion of the data structure <b>300</b> as indicated by the dashed oval <b>302</b>. Suppose further that the nodes A <b>312</b>, B <b>314</b> and C <b>316</b> are included in a second semantically-defined portion of the data structure indicated by the oval <b>304</b> along with the A to B and A to C inter-node links.

0061In the first operation of a process to serialize the data structure <b>300</b> it may be desirable to serialize the portion of the data structure indicated by oval <b>302</b>. This serialization may be carried out by the content processing module <b>130</b> and the serializing module <b>132</b> in a process, such as for example, method <b>200</b>.

0062In carrying out the serialization process of the data structure <b>300</b>, the content processing module <b>130</b> may select the portion of the data structure indicated by oval <b>302</b> as the portion to be serialized as a first operation in serializing all of data structure <b>300</b>. The serializing module <b>132</b> may then serialize the portion of the data structure indicated by oval <b>302</b>, with the content processing module <b>130</b> subsequently removing nodes D <b>310</b>, E <b>306</b> and F <b>308</b> from the data structure <b>300</b> and replacing the link from A to D with an external link.

0063The situation resulting from this first operation of the process of serializing the data structure <b>300</b> is illustrated diagrammatically in <figref idref="DRAWINGS">FIG. 4</figref>, according to an example embodiment. It will be appreciated that the portion of the data structure <b>300</b> that is indicated by ellipse <b>302</b> has been removed from the data structure <b>400</b>. While nodes A <b>404</b>, B <b>408</b> and C <b>406</b> remain as part of the data structure stored in memory <b>102</b>, it will be appreciated that nodes D <b>310</b>, E <b>306</b> and F <b>308</b> have been removed. The inter-node link between nodes A <b>312</b> and D <b>310</b> in <figref idref="DRAWINGS">FIG. 3</figref> has been replaced by the external link <b>420</b>. This external link may include file name data <b>422</b> that indicates a file containing information from which the nodes D, E and F may be reconstructed. External link data <b>424</b> that may facilitate the reconstruction of the node-and-link representation of a portion of electronic content stored in the file indicated by the file name data <b>422</b>. Serialization file XW <b>402</b> may include, for purposes of this example, information describing the portion of electronic content stored in serialization file XW. Serialization file XW <b>402</b> may include serialization data <b>412</b> which may include data facilitating the reconstruction of the node-and-link representation of the portion of electronic content stored in serialization file XW. Serialization data <b>412</b> may also include information that may be used to reconstruct the nodes D <b>310</b>, E <b>306</b> and F <b>308</b>. The information in serialization file XW <b>402</b> that may be used to reconstruct the nodes D, E, F is illustrated symbolically with rectangles <b>414</b>, <b>418</b> and <b>416</b> respectively with data necessary to reconstruct the inter-node links among these nodes illustrated by the dotted arrows.

0064As mentioned above, the depiction of the portion of the data structure <b>300</b> that was serialized into serialization file XW is shown using dashed rectangular nodes and dashed inter-node links to indicate that, although the information stored in serialization file XW is not formatted in a manner substantially similar to the node-and-link representation of the portion of the data structure, the node-and-link representation is reconstructable using data information stored in serialization file xw.

0065Having serialized the portion of the data structure <b>300</b> indicated by oval <b>302</b>, the serialization process of the data structure <b>400</b> may proceed with the serialization of the portion of the data structure indicated by oval <b>304</b>. In this example, the nodes A <b>404</b>, B <b>408</b> and C <b>406</b> and the inter-node links and external link <b>420</b> incident to these nodes are included in the portion of the data structure indicated by oval <b>304</b>. The content processing module <b>130</b> may select the nodes A <b>404</b>, B <b>408</b> and C <b>406</b> as being a portion of the data structure <b>400</b> representing a semantically-defined portion of the electronic content represented by the data structure as a whole (e.g., data structure <b>300</b>.) The serializing module <b>132</b> may serve to then serialize this portion of the data structure. The result of this selection and serialization process is illustrated in the example <figref idref="DRAWINGS">FIG. 5</figref>.

0066In <figref idref="DRAWINGS">FIG. 5</figref>, a serialization file XW <b>504</b> is shown, as in <figref idref="DRAWINGS">FIG. 4</figref>. In addition, a serialization file RS <b>506</b> is shown, which may be stored in a package <b>120</b> in storage device <b>104</b>, and includes a number of pieces of information. Serialization data <b>508</b> may include information useful for reconstructing the node-and-link representation of the information stored in serialization file RS <b>506</b> and serialization file RS <b>506</b> may also include information facilitating the reconstruction of nodes A <b>404</b>, B <b>408</b> and C <b>406</b> as indicated by the rectangles <b>510</b>, <b>512</b> and <b>514</b> respectively. Serialization file RS <b>506</b> may also include information <b>516</b> facilitating the reconstruction of the external link from a reconstructed node A that refers to serialization file XW <b>504</b>.

0067It will be appreciated that the nodes A, B and C are removed from the remainder of the original data structure <b>502</b>. In addition, it will be appreciated that the inter-node link in data structure <b>300</b> from the top node to node A <b>312</b> has been removed and replaced by the external link <b>517</b> that includes serialization identification data <b>518</b>. External link <b>517</b>, in this example, refers to serialization file RS <b>506</b> and includes reconstruction facilitation data <b>519</b> which may be used to facilitate reconstruction of the node-and-link representation from information stored in serialization file RS <b>506</b>.

0068An example of the kind of information stored in the reconstruction facilitation data <b>519</b> may be information identifying which node out of the various nodes reconstructable from the information in serialization file RS <b>506</b> to connect by an inter-node link to the top node. In this example, that would be a node corresponding to node A <b>312</b> of the original data structure <b>300</b>.

0069Further processing of the remainder of the original data structure <b>502</b> may result in the complete serialization of the data structure <b>300</b> into three or more separate serialization files, including serialization file RS <b>506</b> and serialization file XW <b>504</b>.

0070<figref idref="DRAWINGS">FIG. 6</figref> illustrates a process for serializing a portion of a data structure, according to an example embodiment. The portion of electronic content represented in the portion of data structure indicated by oval <b>608</b> may be transformed into a different representation for storage into serialization file <b>604</b>, this transformation being indicated by the arrow glyph <b>610</b>.

0071The serialization file <b>604</b> may include information that may be used to reconstruct the nodes and links per se of the node-and-link representation of the portion of the electronic content. The serialization file <b>604</b> may also include information facilitating generally the reconstruction of the node-and-link representation as indicated in by blocks <b>612</b>. The dashed circle <b>606</b>, in the dashed rectangle, represents information indicating that the information depicted as the top rectangle in the serialization file <b>604</b> is to be reconstructed as the top node of the corresponding node-and-link representation of the portion of electronic content stored in serialized form in serialization file <b>604</b>.

0072<figref idref="DRAWINGS">FIG. 7</figref> shows a yet further diagrammatic illustration of the process of serializing a portion of a node-and-link data structure, according to an example embodiment. In <figref idref="DRAWINGS">FIG. 7</figref>, the transformation from a single node-and-link data structure into a serialization file of a portion of that data structure and an annotation of the remainder of the data structure to facilitate a reconstruction of the original node-and-link data structure is shown; this transformation is indicated by the arrow <b>710</b>. In the original data structure <b>702</b>, the top node B <b>704</b> and another node A <b>706</b> are identified. The oval <b>708</b> indicates the portion of the data structure that is, in this example, being serialized. As a result of processing by the content processing module <b>130</b> and the serializing module <b>132</b>, the serialization file RST <b>712</b> may be created including information facilitating the reconstruction of node A <b>706</b> (indicated by the dashed rectangle <b>720</b>) as well as the reconstruction of the node below node A and the inter-node link connecting them. The portion of the data structure <b>702</b> indicated by oval <b>708</b> has been removed as a result of the serializing of that portion of the data structure and the inter-node link from node B <b>704</b> to node A <b>706</b> has been replaced by an external link <b>714</b>. The external link includes serialization identification data <b>716</b>. The external link also includes, in this example, an indication of the reconstructed node out of the nodes reconstructible from serialization RST that is to be connected by an inter-node link to top node B. In this diagram, the indication is illustrated by the top node in the miniature icon <b>718</b> being filled, the top node at the miniature icon corresponding to the node reconstructible from the information in serialization file RST <b>712</b> indicated as block <b>720</b>.

0073Topologically Transforming Serialization Examples

0074<figref idref="DRAWINGS">FIGS. 8 through 11</figref> illustrate diagrammatically example ways in which portions of data structures representing electronic content in a node-and-link representation may be transformed into information contained in serializations in differing representations, according to example embodiments.

0075<figref idref="DRAWINGS">FIGS. 8 and 9</figref> illustrate a process to serialise a portion of a data structure representing electronic content in which the portion of the data structure is in the form of a binary search tree, according to an example embodiment.

0076<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example data structure in a node-and-link representation, the data structure indicated generally as <b>802</b>. The example data structure <b>802</b> includes a top (e.g., root) node <b>808</b> as well as a portion serving as a binary search tree indicated by the oval <b>803</b>. The nodes within the binary search tree portion are divided into leaf nodes labelled A, B, C, D <b>840</b> and four internal nodes <b>806</b>. In some embodiments, a binary (or other type of) search tree may be serialized into a linear list of the content elements searchable within the tree and reconstruct the internal nodes into memory <b>102</b> at such time as the serialized linear list of content elements is deserialized, for example, when the data structure representing electronic content with which the content elements are associated, is being reconstructed.

0077<figref idref="DRAWINGS">FIG. 9</figref> illustrates a serialization file TS <b>910</b> which may represent the results of serializing the portion of the data structure indicated by oval <b>803</b>, as it may be serialized by the serializing module <b>132</b>. In some embodiments, the information from which the actual electronic content carrying nodes A through E <b>804</b> of <figref idref="DRAWINGS">FIG. 8</figref> is reconstructible appears in <figref idref="DRAWINGS">FIG. 9</figref> at <b>914</b>. The serialization file TS <b>910</b> also includes information facilitating the reconstruction of the original (or equivalent) node-and-link search tree indicated by oval <b>803</b>. In some embodiments, this information may take the form of an indication that the serialization file TS <b>910</b> is an ordered list to be deserialized and reconstructed in node-and-link form as a search tree. This reconstruction facilitation information is indicated at <b>912</b>. <figref idref="DRAWINGS">FIG. 9</figref> also diagrammatically illustrates the remaining portion of the data structure <b>802</b> after the portion indicated by oval <b>803</b> has been serialized and, in some embodiments, removed from the remaining internal data structure <b>902</b>. The remaining internal data structure <b>902</b> includes the original top node (e.g., node <b>808</b>) as well as a newly generated external link <b>908</b>. This newly generated external link <b>908</b> may include serialization identification information <b>906</b> as well as, in some embodiments, other node-and-link reconstruction facilitation information <b>904</b>. For example in the binary search tree data structure portion indicated by oval <b>803</b>, the reconstruction facilitation data <b>904</b> may be used to indicate the particular binary search tree configuration to be used when reconstructing the binary search tree portion of the data structure from the serialization file TS <b>910</b>.

0078In some embodiments, the information in file TS <b>910</b> from which the content carrying nodes of the binary search tree may be reconstructed may be expressed in a markup language, such as for example, XML.

0079<figref idref="DRAWINGS">FIGS. 10, 11B</figref>, and <b>11</b>B illustrate another example of a process in which a portion of a node-and-link data structure is serialized into a different representation from the original node-and-link representation, according to an example embodiment. In <figref idref="DRAWINGS">FIG. 10</figref>, an example data structure <b>1002</b> is illustrated in which a top node <b>1004</b> is connected using bidirectional inter-node links through a two-way linked list including the nodes <b>1008</b> labelled D, E and F. The doubly linked list itself is indicated by the oval <b>1006</b>.

0080<figref idref="DRAWINGS">FIG. 11A</figref> illustrates an example serialization of the doubly linked list indicated by oval <b>1006</b> as it may be stored in a serialization file PQ <b>1110</b>. The serialization file PQ <b>1110</b> may include information <b>1114</b> from which the nodes of the two-way linked list may be reconstructed as well as an indication of the order in the list of those reconstructed nodes suggested by the dashed arrows within the example serialization file PQ <b>1110</b>. For example, the data contained in the nodes may be stored as within a list of markup language pairs ordered as they may be in a doubly-linked list reconstructible from the serialization file PQ <b>1110</b>. In addition, the serialization file PQ <b>1110</b> includes reconstruction facilitation data <b>1112</b> serving to indicate that the serialization file PQ <b>1110</b> may be interpreted so as to facilitate the reconstruction from the information contained in the serialization file PQ <b>1110</b> into a two-way linked list that includes a back pointer to the node to which the list is attached. In the process of serializing the portion of the data structure indicated by oval <b>1006</b>, the nodes D, E, and F may be removed, as well as the inter-node link from the top node <b>1004</b> to the node designated D. This inter-node link may be replaced by the external link <b>1108</b>. External link <b>1108</b> may include a serialization identification data item <b>1106</b> as well as a reconstruction facilitation data <b>1104</b>.

0081In the process of deserializing the serialization file PQ <b>1110</b>, the external link may be replaced by a link to the reconstructed node A as well as the addition of a back pointer from the reconstructed A back to the top node. The deserialization process is discussed in detail below.

0082<figref idref="DRAWINGS">FIG. 1B</figref> illustrates an alternative example serialization of the doubly linked list indicated by oval <b>1006</b> as it may be stored in a serialization file PQB <b>1130</b>. The serialization file PQB <b>1130</b> may include node data array <b>1134</b> from which the nodes of the two-way linked list may be reconstructed as well as an indication <b>1136</b> of the order in the list of those reconstructed nodes. In addition, the serialization file PQB <b>1130</b> includes reconstruction facilitation data <b>1132</b> serving to indicate that the serialization file PQB <b>1130</b> may be interpreted so as to facilitate the reconstruction from the information contained in the serialization file PQB <b>1130</b> into a two-way linked list that includes a back pointer to the node to which the list is attached.

0083<figref idref="DRAWINGS">FIGS. 12 and 13</figref> illustrate a process to serialise a portion of a node-and-link data structure in the form of a linked list into a serialization in which the information from which the linked list node-and-link representation may be reconstructed, according to an example embodiment.

0084<figref idref="DRAWINGS">FIG. 12</figref> illustrates a data structure <b>1202</b> which may be used to store electronic content in a node-and-link representation. The data structure <b>1202</b> includes a top node T <b>1204</b> and a linked list portion indicated by the oval <b>1205</b>. The linked list portion includes a list root node A <b>1206</b> and a series of linked list nodes B, C, D, E <b>1208</b>. The portion of the data structure indicated by oval <b>1205</b> may be serialized into the serialization file LM <b>1304</b> of <figref idref="DRAWINGS">FIG. 13</figref>.

0085A serialization file LM <b>1304</b> is illustrated as containing information from which the list root node A <b>1206</b> and the four nodes of the linked list B, C, D, E <b>1208</b> may be reconstructed. This information is stored in the serialization file LM <b>1304</b> in the example form of tree structure in which information, from which the nodes B, C, D, E <b>1208</b> are reconstructable, is illustrated as information items <b>1310</b>. The information items <b>1310</b> may be stored in a child-parent relationship with information item <b>1308</b>.

0086The serialization file LM <b>1304</b> may also include information facilitating reconstruction of the portion of the electronic content in a linked list node-and-link representation such as that indicated by oval <b>1205</b>. The reconstruction facilitation data <b>1306</b> in serialization file LM <b>1304</b> may be used to indicate that the information stored in serialization file <b>1304</b> is in the form of a linked list stored as a tree.

0087Once the portion of the data structure indicated by oval <b>1205</b> has been serialized into the serialization file LM <b>1304</b>, in some embodiments by the serializing module <b>132</b>, the list root node A <b>1206</b> and the linked list nodes <b>1208</b> may be removed from the data structure <b>1202</b> and the inter-node link from node T <b>1204</b> to node A <b>1206</b> may be replaced in the remaining part of the data structure <b>1302</b> by the external link <b>1312</b>. The external link <b>1312</b> may include similar information as described with respect to previous figures.

0088It will be appreciated that the storage of the portion of electronic content in a node-and-link representation into a serialization may be implemented by the use of a markup language such as XML to represent either implicitly or explicitly the content of the nodes and the inter-node links among them. For example in the serialization file LM <b>1304</b>, the file may include an opening XML tag containing the information describing or otherwise facilitating the reconstruction of list root node A <b>1206</b>, followed by four XML tags including information describing or facilitating the reconstruction of the linked list nodes B, C, D,E <b>1208</b>, followed by a closing markup language tag paired to the opening markup language tag that provides information for the reconstruction of the list root node A <b>1206</b>.

0089In the preceding several examples, the node-and-link data structures have been illustrated as including only a single inter-node link by which the portion of the data structure to be serialized is connected to the remainder of the data structure that is not yet to be serialized. It will be appreciated that, in some embodiments, multiple inter-node links may exist between various nodes in the portion of the data structure to be serialized and various nodes in the portion of the data structure that is not yet to be serialized. For example, a content processing module <b>130</b> may identify a particular portion of a node-and-link data structure corresponding to a semantically-defined portion of the electronic content which may be storable into a single serialized file. It may further be the situation that a number of nodes in the particular portion of the data structure may be linked to one or more nodes in the portion of the data structure not being serialized into that file. In that case, multiple external links may be generated and associated with the nodes that are linked to nodes in the portion of the data structure to be stored in a serialization file.

0090<figref idref="DRAWINGS">FIGS. 14 and 15</figref> illustrate an example of serializing an electronic document stored in a node-and-link representation in a memory <b>102</b> by a content processing module <b>130</b> and a serializing module <b>132</b> into a group or package of seven interrelated serialization files, according to an example embodiment. The original node-and-link data structure <b>1400</b> representing an electronic document is illustrated in <figref idref="DRAWINGS">FIG. 14</figref>. The nodes depicted in <figref idref="DRAWINGS">FIG. 14</figref> include a main document node <b>1402</b> that may serve as a root node for the node-and-link representation of the electronic document, and a number of nodes, <b>1408</b>, <b>1410</b>, and <b>1412</b> corresponding to pages of the electronic document. The page nodes <b>1408</b>, <b>1410</b> and <b>1412</b> depend as a linked list from a page tree root node <b>1406</b>. These page nodes <b>1408</b>, <b>1410</b> and <b>1412</b> are connected by inter-node links to various nodes representing content elements associated with the pages. For example, page 1 of the electronic document includes two paragraphs and correspondingly the node-and-link representation of the electronic document includes a node <b>1414</b> which may include the text of first paragraph and node <b>1416</b> which may include the text of the second paragraph, both paragraph nodes attached to the page 1 node <b>1408</b> via inter-node links. Similarly, the page 2 node <b>1410</b> may include inter-node links to three paragraph nodes <b>1418</b>, <b>1420</b> and <b>1422</b>. Page 3 of the electronic document may include an image and a table. Thus, the page 3 node <b>1412</b> may have a incident inter-node links to an image node <b>1424</b> containing image information, and to a table node <b>1426</b> storing the table.

0091In addition to the page structure, the electronic document represented by the data structure <b>1400</b> may include a table of contents node <b>1404</b> corresponding to the electronic document's table of contents. The table of contents of the example electronic document may include two entries. A first entry node <b>1428</b>, which may be used to allow a rendering of the electronic document to permit a user to navigate directly to a rendering of the first page of the document, and a second table of contents entry node <b>1430</b>, which may allow the user when viewing a rendering of the electronic document to navigate directly to page 3.

0092<figref idref="DRAWINGS">FIG. 15</figref> illustrates an example of how the electronic document stored in the node-and-link data structure <b>1400</b> may be serialized into seven serialization files, according to an example embodiment.

0093In <figref idref="DRAWINGS">FIG. 15</figref> various serialization files—file ABC <b>1502</b>, file DE <b>1504</b>, file JK <b>1506</b>, file FG <b>1508</b>, file PF<b>1</b><b>1510</b>, file PF<b>2</b><b>1512</b> and file PF<b>3</b><b>1514</b>—contain information allowing for the reconstruction of a portion of the node-and-link representation of the electronic document illustrated in <figref idref="DRAWINGS">FIG. 14</figref>. Each file in <figref idref="DRAWINGS">FIG. 15</figref> may be considered to describe a semantically-defined portion of the electronic documents, the node-and-link representation of which is illustrated in <figref idref="DRAWINGS">FIG. 14</figref>.

0094The serialization file ABC <b>1502</b> includes information <b>1522</b> for reconstructing the main document node <b>1402</b>, as well as information <b>1516</b> indicating that the file contains information facilitating the reconstruction of a main or root document node. The serialization file ABC <b>1502</b> also includes an indication <b>1520</b> of the table of contents top node as being reconstructible from the serialization file DE <b>1504</b>, as well as an indication <b>1518</b> of the page tree root node constructible from the serialization file FG <b>1508</b>.

0095The serialization file DE <b>1504</b> illustrates a serialization in which information describing a table of contents (which may be a semantically-defined portion of an electronic document) may be stored. Serialization file DE <b>1504</b>, includes information <b>1528</b> facilitating reconstruction of the table of contents node <b>1404</b> itself, as well as information <b>1530</b> and <b>1532</b> allowing for the reconstruction of the table of contents entry nodes <b>1428</b> and <b>1430</b>. It will be appreciated that the information facilitating reconstruction of the table of contents entry nodes is provided in terms of user-understandable page numbers rather than in a more abstract object identifier based scheme. The serialization file DE <b>1504</b> also includes information <b>1526</b> indicating the file name template (e.g., “PFn”, where n is the page number) that may be used to identify the serialization files containing the information for reconstructing the page nodes <b>1408</b>, <b>1410</b> and <b>1412</b>.

0096Table 1 illustrates an example XML text that may be stored within, and implement the content of, serialization file DE 1504. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="56PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="1" align="center">TABLE 1</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><toc></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry><entry page=“1”></entry></row><row><entry /><entry>Introduction</entry></row><row><entry /><entry></entry></entry></row><row><entry /><entry><entry page=“3”></entry></row><row><entry /><entry>Summary</entry></row><row><entry /><entry></entry></entry></row><row><entry /><entry><filenames prefix=“PF”/></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="56PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry></toc></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0097It will be appreciated that the XML text of Table 1 does not closely resemble the corresponding portion of the data structure <b>1400</b>. For example, the inter-node links that may be constructed between nodes <b>1404</b>, <b>1428</b> and <b>1430</b> are not present, nor are external links or inter-node links connecting node <b>1405</b> to node <b>1428</b> or <b>1412</b> to <b>1430</b>. However, in some embodiments, all of these links are constructible from the XML text of Table 1. Similarly, it will be appreciated that the table of contents entry identifiers (e.g., “ENTRY” “1”, “2”) found the data structure <b>1400</b> may be implicit in the XML text. Reconstruction facilitation data <b>1524</b> may, for example, be implemented via the <toc> tag pair.

0098The serialization file FG <b>1508</b> includes information facilitating reconstruction of the page tree root node <b>1406</b> and inter-node linkage to page nodes <b>1408</b>, <b>1410</b> and <b>1412</b>. The information <b>1544</b> which may facilitate the reconstruction of page tree root node <b>1406</b> as well as the information <b>1542</b> indicating that the serialization file FG <b>1508</b> relates to a page tree root node are illustrated as being included in serialization file FG <b>1508</b>. In addition, the pages of the document are represented by page number information <b>1546</b>. The serialization file FG <b>1508</b> also includes information <b>1540</b> to facilitate the identification of page node serialization file names, similar to that described above with respect to serialization file DE <b>1504</b>. Two of the serialization files—PF<b>1</b><b>1510</b> and PF<b>2</b><b>1512</b>—may include information (e.g., information <b>1550</b>) for reconstructing a page node as well as information <b>1552</b> and <b>1554</b> which may contain the text of the paragraphs to be reconstructed into paragraph nodes (e.g., node <b>1414</b> and node <b>1416</b>). Serialization file PF<b>1</b><b>1510</b> and serialization file PF<b>2</b><b>1512</b> may include information <b>1548</b> and <b>1556</b>, respectively, indicating that the serialization contained in the files describes pages of an electronic document. Serialization file PF<b>3</b><b>1514</b> from which page 3 node <b>1412</b> may be reconstructed is shown as having a different structure from the other two page serialization files illustrated; serialization file PF<b>3</b><b>1514</b> includes a reference <b>1560</b> to an image file containing an image which is to be included in a rendering of the page corresponding to page 3 node <b>1412</b>.

0099Table 2 illustrates an example XML text that may be stored within, and implement the content of, serialization file PF<b>1</b><b>1510</b>. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="1" align="center">TABLE 2</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><page></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><tbody valign="top"><row><entry /><entry><paragraph></entry></row><row><entry /><entry>Now is the time for all good men . . .</entry></row><row><entry /><entry></paragraph></entry></row><row><entry /><entry><paragraph></entry></row><row><entry /><entry>It is now past the time for all good men . . .</entry></row><row><entry /><entry></paragraph></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row><entry /><entry></page></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0100Similarly to Table 1 above, Table 2 illustrates that an XML textual representation of nodes <b>1405</b>, <b>1414</b>, and <b>1416</b> may be serialized into a single serialization having a different structure than the corresponding portion of data structure <b>1400</b>. For example, the inter-node links connecting node <b>1414</b> and node <b>1416</b> to node <b>1405</b> are absent in the XML representation, as is an explicit indication of page number or paragraph number. In some embodiments, during construction of a data structure from serialization files, the page number may be assigned based on data found in serialization file FG <b>1508</b> and paragraph numbers may be assigned based on the order of paragraphs found in serialization file PF <b>1</b><b>1510</b>.

0101Serialization file JK <b>1506</b> may include data that facilitates the reconstruction of an image stored in an image node <b>1424</b> and included within the third page of the electronic document. Serialization file JK <b>1506</b> includes information <b>1534</b> indicating that the content of the serialization may be taken to represent an image. Serialization file JK <b>1506</b> is also shown as including the image data <b>1538</b> itself.

0102Example Processes For Reconstructing Node-and-link Data Structures From Serialization Files

0103When an electronic document or other electronic content stored in a number of serialization files such as those illustrated in <figref idref="DRAWINGS">FIG. 15</figref> is to be reconstructed in memory <b>102</b> in a node-and-link data structure, such as for example <b>1400</b>, a main application <b>100</b> making use of a rendering module <b>106</b> may use deserialization module <b>126</b> to carry out the deserialization of one or more serialization files (e.g., <b>122</b> and <b>124</b> as shown in <figref idref="DRAWINGS">FIG. 1</figref>) to generate a data structure <b>112</b>. In some embodiments, this process may be carried out in what may be termed a “lazy” manner, in which the entire data structure representing the electronic content in the node-and-link representation is not entirely reconstructed immediately but is rather reconstructed in stages as the rendering process, such as carried out by rendering module <b>106</b>, traverses the node-and-link data structure (such as in the process of rendering the electronic content represented within the data structure). In some embodiments, this traversal may be accomplished by the use of the ‘document object model’-type API <b>108</b>.

0104In such lazy access node-and-link data structure construction processes, the main application may begin the process constructing a node-and-link data structure by requesting that a deserialization module access a package <b>120</b> or other mass storage directory structures to retrieve the serialization associated with the top or root node of the data structure to be reconstructed. This top node or other initial portion of the data structure may then be constructed from the serialization containing information facilitating the construction of that initial portion of the data structure. Once the initial portion of the data structure has been reconstructed from a serialization, the rendering module <b>106</b> may begin rendering (or otherwise processing) the electronic content such as an electronic document.

0105As the rendering module <b>106</b> begins to render the electronic document for which the initial portion of the data structure has been constructed, the rendering module <b>106</b> may occasionally attempt to reference a portion of the electronic content for which the corresponding portion of the data structure has not yet been constructed from a serialization. At that point the deserialization module <b>126</b>, perhaps in response to an invocation by the rendering module <b>106</b>, or perhaps through invocation by the ‘document object model’-type API <b>108</b>, may deserialize a serialization file describing the newly requested portion of the electronic content.

0106For example, by way of illustration, suppose that a user wished to view the electronic document stored in the seven serialization files illustrated in <figref idref="DRAWINGS">FIG. 15</figref>. At the beginning of the document rendering process, the rendering module <b>106</b> may determine that the initial portion of the data structure representing the electronic document to be rendered may be constructed from the serialization file ABC <b>1502</b>. The rendering module <b>106</b> may request the deserialization module <b>126</b> to access serialization file ABC <b>1502</b> and construct the main document node <b>1402</b> with the references to the table of contents serialization file DE 1504 and to the pages serialization file FG <b>1508</b> being inserted into the data structure as external links. Next, suppose the rendering module <b>106</b> determined that it was necessary to render the table of contents into the rendering of the electronic document. In that case, the rendering module <b>106</b> may request the table of contents node be retrieved from memory <b>102</b>, such as via the ‘document object model’-type API <b>108</b>. However, at this point in the construction of the node-and-link representation of the electronic document, a table of contents node would not yet be present in the data structure. However, an external link referencing the table of contents file, such as for example serialization file DE <b>1504</b>, would be present and the information contained in the external link in conjunction with information in the table of contents node serialization file DE <b>1504</b> may be used to construct not only the table of contents node <b>1404</b>, but also the table of contents entry nodes <b>1428</b> and <b>1430</b> with a table of contents entry node <b>1428</b> and <b>1430</b> including external links facilitating (in conjunction with the corresponding page serialization files) construction of, and connection to, page nodes <b>1408</b>, <b>1410</b> and <b>1412</b>.

0107Proceeding in this manner, the rendering module <b>106</b> in cooperation with the deserialization module <b>126</b> and the ‘document object model’-type API <b>108</b>, may construct an entire electronic document as a node-and-link data structure in memory <b>102</b> from the seven serialization files of <figref idref="DRAWINGS">FIG. 15</figref>. This construction may be carried out in operations in a lazy manner in which portions of the data structure containing several nodes are constructed from serializations as the information contained in those serializations to construct the nodes is required.

0108<figref idref="DRAWINGS">FIG. 16</figref> shows a flowchart illustrating in overview a method <b>1600</b> for deserializing a portion of electronic content, according to an example embodiment.

0109At block <b>1602</b>, a first node in a data structure in a node-and-link representation (in which the data structure represents electronic content) may be selected, where the data structure includes a first external link that references a serialization and the first external link is associated with or incident to the first node. In some embodiments, this selection may be carried out by rendering module <b>106</b>. In some embodiments, as facilitated by the ‘document object model’-type API <b>108</b>, the first node may be a node that is in memory, but has an external link incident to it. The external link may reference a serialization, from which a node requested by the rendering module <b>106</b>, may be constructed. In other words, the rendering module <b>106</b> or other component of the main application <b>100</b> may be requesting access to a particular node (e.g., for the purpose of processing or rendering) that the rendering module <b>106</b> expects is a part of data structure <b>112</b>, but which in fact was not yet reconstructed from a serialization file.

0110For example, the rendering module <b>106</b> may be processing a particular node (e.g., the ‘first node’ mentioned in block <b>1602</b> which may be termed ‘node A’ for purposes of discussion), and may need to access an expected node B that the rendering module <b>106</b> expects to be connected by an inter-node link to node A. Thus, the process of constructing node B from a serialization, node A may be selected by the rendering module <b>106</b> in the sense of being selected by the rendering module <b>106</b> as the node A from which a particular child node B is expected to be joined to by an inter-node link. However, when a child node B requested by a rendering module <b>106</b>, is in fact not present in data structure <b>112</b>, but is constructable from a serialization, an external link may be associated with node A.

0111At block <b>1604</b>, a serialization that is referenced by the external link is accessed, in some embodiments, by the deserialization module <b>126</b>. At block <b>1606</b>, the data structure <b>112</b> in memory <b>102</b> may be augmented, which may be carried out by the deserialization module <b>126</b>. As part of the augmenting of the data structure, at block <b>1608</b> the deserialization module <b>126</b> may construct several, or in some embodiments, all of the nodes that are constructible from the serialization referenced by the external link.

0112At <b>1610</b>, a target node may be selected from among the new nodes. This target node is the child node (e.g., node B in the above discussion) of the first node (e.g., node A in the above discussion) and may be the node which the rendering module <b>106</b> needs to access to continue the rendering process of the electronic content represented by the data structure <b>112</b>. At block <b>1612</b> the target node may be inserted into the data structure <b>112</b>, along with the other new nodes constructed at block <b>1608</b>.

0113At block <b>1614</b>, an inter-node link may be inserted into the data structure connecting the first node and the target node. This inter-node link may correspond to, and in some embodiments, may replace the external link. The target node has at this point in the method <b>1600</b> been inserted into the data structure, along with an inter-node link from the first node allows this target node to be retrieved or accessed from the data structure <b>112</b> by the rendering module <b>106</b>. Accordingly, the rendering module <b>106</b> is able to continue the rendering process using electronic content included in the target node and in other new nodes added to the data structure <b>112</b> at block <b>1612</b>.

0114<figref idref="DRAWINGS">FIG. 17</figref> shows a further flowchart illustrating certain details in a method <b>1700</b> to deserialize a portion of electronic content, according to an example embodiment. As in the method <b>1600</b>, the method <b>1700</b> begins with the selection at block <b>1702</b> of a first node to which a first external link is associated. This first node may be the parent node (e.g., node A of the above discussion) of a node (e.g., node B of the above discussion) that is not present in data structure (e.g., <b>112</b>) but which the rendering module <b>106</b> needs to access and which may be constructible from a file indicated by the first external link. (Note to self: discuss first node in context of later examples).

0115At block <b>1704</b>, the serialization referenced by the first external link may be accessed by the deserialization module <b>126</b>. At block <b>1706</b>, the data structure may be augmented, a process that may be also carried out by the deserialization module <b>126</b>. The process of augmenting the data structure illustrated in block <b>1706</b> includes several operations. At block <b>1708</b> the new nodes constructible from the serialization may be constructed, in some embodiments, by deserialization module <b>126</b>. At <b>1710</b>, inter-node links among the new nodes may be constructed based on, for example, information in the serialization. At <b>1712</b>, any external links associated with the new nodes may be constructed. These new external links associated with the new nodes may be constructed from the information in the serialization and may reference other serializations that have not yet been deserialized, or may reference serializations from which nodes have already been constructed and added to the data structure.

0116At <b>1714</b> the newly constructed nodes, which may be termed new nodes and the newly reconstructed links (both inter-node links constructed at block <b>1710</b> and external links constructed at block <b>1712</b>), may be inserted into the data structure. At block <b>1716</b>, an inter-node link may be inserted into the data structure that links from the first node to the newly constructed target node.

0117At block <b>1718</b>, inter-node links may be added to the data structure that corresponded to external links constructible from the serialization that reference nodes in the data structure that had already been constructed prior to the execution of method <b>1700</b> (e.g., “back-pointing external links”). These back-pointing external links, so called since they are incident to newly-constructed nodes and reference serializations from which nodes earlier constructed and residing in the data structure prior to the execution of the method <b>1700</b>, may be replaced by corresponding back-pointing inter-node links. The identification of the earlier-constructed nodes to which a back-pointing inter-node link are to reference may be made based on the nature of the newly-added node to which they are to be incident and information in the back-pointing external link and may be facilitated by node lookup table <b>128</b>, whose function is discussed in detail below.

0118In some embodiments, the augmenting of the data structure at block <b>1706</b> based on the information contained in the serialization, and in some embodiments, in the first external link present in the data structure before the execution of method <b>1700</b>, may include other processing. For example, there may be multiple external links (incident to existing nodes) exist in the data structure before the processing shown in method <b>1700</b> that indicate that the target node should be connected to those existing nodes by an inter-node link. If that is the case, those external links may be removed from the data structure and replaced with inter-node links to link the existing nodes to the newly-constructed target node. Similarly, if a serialization includes information indicating that a node newly constructed from the serialization should be connected to an already-existing node via an inter-node link, the existing link may be connected to the newly constructed node.

0119Node-and-link Electronic Content Representation Reconstruction Examples

0120In the sections that follow, an example of a process for constructing a data structure representing electronic content in a node-and-link representation is described. The following example illustrations, <figref idref="DRAWINGS">FIGS. 18 through 25</figref>, illustrate how the method <b>1600</b> and/or method <b>1700</b> may be used in a process to construct a data structure <b>112</b> in memory <b>102</b> from a set of serializations, such as for example serialization file <b>122</b> and serialization file <b>124</b>, which may be contained in a package <b>120</b>, such as for example a directory hierarchy, compressed-directory file, e.g., a ZIP file, according to an example embodiment.

0121<figref idref="DRAWINGS">FIG. 18</figref> illustrates three serializations in the form of three serialization files, file ABC <b>1802</b>, serialization file XYZ <b>1816</b> and serialization file JKL <b>1818</b>. File ABC includes information for constructing three nodes. This information includes the information <b>1806</b> for constructing node A, <b>1808</b> for node B <b>1808</b> and <b>1810</b> for node C. The serialization file ABC <b>1802</b> is shown as also including information <b>1804</b> indicating that the node-describing information is to be used to reconstruct the linked list whose first (e.g., list root) node is A followed by nodes B and C, even though the information describing nodes A, B and C in serialization file ABC <b>1802</b> is, for purposes of this example, organized in the form of a tree. Within serialization file ABC <b>1802</b> are also included information <b>1814</b> and information <b>1812</b> describing external links associated with nodes B and C, which may be constructed when serialization file ABC <b>1802</b> is deserialized. Although not indicated in the illustration in <figref idref="DRAWINGS">FIG. 18</figref>, serialization file ABC <b>1802</b>, may in this example be taken to be the first or initial serialization to be deserialized in the process of constructing a full node-and-link representation of the electronic content stored in the three serialization files of <figref idref="DRAWINGS">FIG. 18</figref>. Example serialization file ABC <b>1802</b> includes information <b>1814</b> which may be used to reconstruct an external link that references serialization file XYZ <b>1816</b> and information <b>1812</b> which may be used to reconstruct an external link that references serialization file JKL <b>1818</b>, from which nodes to be connected to nodes B and C, respectively, may be constructed.

0122Serialization file XYZ <b>1816</b> includes information designated collectively as <b>1822</b> facilitating constructing three nodes. Serialization file XYZ <b>1816</b> also includes external link information <b>1824</b> that may be used to generate an external link incident to a node E constructible from serialization file XYZ <b>1816</b>. Serialization file XYZ <b>1816</b> further includes information <b>1820</b> indicating that the three nodes are to be constructed into a two-way list and to include a back pointer from the first reconstructed node to the node to which it is linked.

0123Serialization file JKL <b>1818</b> includes information <b>1828</b> facilitating constructing a single node (e.g., node G) as well as information <b>1826</b> indicating that the serialization file JKL <b>1818</b> includes only a single node.

0124<figref idref="DRAWINGS">FIGS. 19 through 25</figref> discuss how the processes illustrated in <figref idref="DRAWINGS">FIGS. 16 and 17</figref> may be used in the process of constructing a node-and-link representation of the electronic content stored in the three example serialization files of <figref idref="DRAWINGS">FIG. 18</figref>.

0125<figref idref="DRAWINGS">FIG. 19</figref> illustrates an initial data structure <b>1902</b> which may be constructed by deserialization module <b>126</b> from the serialization file ABC <b>1802</b>. It will be appreciated that the tree-like representation of the node information shown in serialization file ABC <b>1802</b> has been constructed into, for example, memory <b>102</b>, as a linked list structure having a linked list root node A and a linked list of nodes B and C. In addition, information <b>1814</b> and <b>1812</b> in serialization file ABC <b>1802</b> has been used to construct two external links <b>1910</b> and <b>1906</b>. The external links <b>1906</b> and <b>1910</b> may include information (<b>1912</b> and <b>1908</b>, respectively) identifying the files that contain information facilitating reconstruction of the nodes which are to be connected to nodes B and C via inter-node links. It will be appreciated that only one node is constructible from serialization file JKL <b>1818</b> and a distinguished node, namely node D, is constructible from serialization file XYZ <b>1816</b>.

0126In the process of constructing the initial data structure <b>1902</b>, in some embodiments a deserialization module <b>126</b> may maintain a node lookup table <b>128</b> within memory <b>102</b>. This node lookup table may be used to map from descriptive data (e.g., names or other data having conceptual or human-understandable meaning, such as “page 2”, “first paragraph”) to symbolic data (such as memory addresses, pointers, object references, symbolic node names, or the like) identifying node objects. For example, a first serialization may include information to facilitate reconstructing a particular node which may be termed node N<b>1</b>. Node N<b>1</b> may contain information describing a particular page of an electronic document, and when constructed from a serialization and stored into memory may, for example, be stored at location 0xAF01C1999D3 in memory. On the other hand, information in serializations describing other nodes to be linked to node N<b>1</b>, may refer to node N<b>1</b> as “page 7”. In this example, node lookup table <b>128</b> may include an entry mapping the conceptual identification or description “page 7” to the node object stored at location 0xAF01C1999D3. Thus, in the process of constructing nodes from information in serializations that refer to “page 7” as a related node, an inter-node link (e.g., to replace an external link stored in the data structure incident to a node being rendered) connecting those later-constructed nodes to the earlier-constructed node N<b>1</b> may, for example, be generated by looking up the memory location in the node lookup table <b>128</b>.

0127Suppose, for the purpose of illustration, that in <figref idref="DRAWINGS">FIG. 19</figref> the node designated A is the root of an electronic document and that the nodes designated B and C are page 1 and page 2 of that electronic document. Thus, descriptive information for the nodes B and C may be used to look up the identification of those nodes in the table <b>1904</b>, illustrating in this example the node lookup table <b>128</b>. As more nodes are added to the initial data structure <b>1902</b>, such as by the deserialization module <b>126</b>, the table <b>1904</b> may expand.

0128<figref idref="DRAWINGS">FIG. 20</figref> illustrates a further operation in the process of constructing a node-and-link data structure based on the electronic content stored in the serialization files of <figref idref="DRAWINGS">FIG. 18</figref>, according to an example embodiment. In <figref idref="DRAWINGS">FIG. 20</figref>, for purposes of illustration, suppose that the rendering of the electronic content which may be an electronic document has proceeded to the point of rendering page 1 data for which is stored in the node <b>2010</b>, symbolically identified as node B. Suppose for purposes of illustration that the rendering module <b>106</b> was in the process of rendering the content at node <b>2010</b>, such as a page of an electronic document. The fact that the rendering module <b>106</b> was in the process of rendering or otherwise processing the node <b>2010</b> is indicated by the star-shaped glyph <b>2012</b> adjacent to the node <b>2010</b>. In the process of rendering the content of the node <b>2010</b>, the rendering module <b>106</b> may try (for example, by using the ‘document object model’-type API <b>108</b>) to access nodes expected to be connected to node <b>2010</b>, which may, for example, include the content elements to be included in the rendering of the page represented by node <b>2010</b>. In some embodiments, the ‘document object model’-type API <b>108</b> may determine that the requested node representing the first content element included in the page is not yet in the data structure <b>2002</b>, but that the external link <b>1910</b> shown in <figref idref="DRAWINGS">FIG. 19</figref> indicates a serialization file XYZ <b>1816</b> from which the page content element-containing nodes may be constructed. In that case, the ‘document object model’-type API <b>108</b> may cause the deserialization module <b>126</b> to deserialize the needed serialization to insert the needed node (as well as other nodes constructible from that serialization) and links into the data structure. In some embodiments, the document object module type API <b>108</b>, upon receiving a request from the rendering module <b>106</b> for a particular node such as a content element in a particular page that has not yet been constructed and stored in the data structure <b>2002</b>, may return the external link to the rendering module <b>106</b>. The rendering module <b>106</b> may then cause deserialization module <b>126</b> to attempt to construct and insert the needed nodes and inter-node links into the data structure <b>2002</b>. Finally, in either variation of the process, the rendering module <b>106</b> may continue the rendering of the electronic document once nodes and links that include the needed content elements have been constructed and inserted into the data structure.

0129In <figref idref="DRAWINGS">FIG. 20</figref>, it will be observed that external link <b>1910</b> has been removed from the portion of the data structure <b>2002</b> thus far constructed and that three new nodes labelled D, E and F <b>2008</b> have been constructed from the information <b>1822</b> from serialization file XYZ <b>1816</b>. The identification of these new nodes represented here by the D, E and F labels have been added along with the descriptions of the three new nodes to the table <b>128</b> maintained by the deserialization module <b>126</b> that is shown in its newly expanded state as table <b>2004</b>.

0130<figref idref="DRAWINGS">FIG. 21</figref> illustrates the continuation of the diagrammatic example that began with <figref idref="DRAWINGS">FIG. 18</figref>. At <figref idref="DRAWINGS">FIG. 21</figref> the initial data structure <b>2102</b> which may represent the initial part of an electronic content in the node-and-link representation is illustrated. The three new nodes identified as nodes D, E and F of this example are also shown as part of fragment <b>2110</b>; the new nodes D, E and F, having been constructed from information <b>1822</b> in serialization file XYZ <b>1816</b>, have been connected by inter-node links according to the information <b>1820</b> indicating that the nodes constructible from the serialization file XYZ <b>1816</b> are to be treated as a two-way linked list. In addition, an external link <b>2112</b> whose construction was facilitated by external link information <b>1824</b> has been made incident to node E.

0131<figref idref="DRAWINGS">FIG. 22</figref> illustrates the next operation of the construction process for the data structure representing the electronic content in a node-and-link representation that is shown in the three serialization files of <figref idref="DRAWINGS">FIG. 18</figref>, according to an example embodiment. In <figref idref="DRAWINGS">FIG. 22</figref>, two new inter-node links—inter-node link <b>2206</b>, the inter-node link corresponding to the previous external link <b>1910</b> incident to node B, and back pointing inter-node link <b>2204</b> from newly constructed node D to node B—have been generated so as to form data structure <b>2202</b> by connecting data structure <b>2102</b> and fragment <b>2110</b>.

0132The data structure having been thus augmented with the nodes D, E and F and their associated inter-node and external links, the processing or rendering of the electronic content may continue, the content elements stored or associated with nodes D, E and F at this point being available to the rendering module <b>106</b>.

0133The external links within a data structure (such as <b>2202</b>) may be resolved and replaced with inter-node links as the nodes and links constructible from the serializations to which they point are needed (by e.g., rendering module <b>106</b>) in a lazy type process. In some embodiments, the deserialization module <b>126</b>, in determining that a serialization file just deserialized includes information describing one or more external links, may immediately attempt to deserialize the serialization files identified by those external links. This deserialization may include attaching the newly constructed nodes and inter-node links to the data structure recursively. This may have the effect that the entire node-and-link representation of the electronic content stored in one or more serializations is deserialized in a single deserialization process prior to electronic content processing or rendering.

0134<figref idref="DRAWINGS">FIG. 23</figref> illustrates a next operation in the deserialization process of the electronic content stored in the three serialization files of <figref idref="DRAWINGS">FIG. 18</figref>, according to an example embodiment. In <figref idref="DRAWINGS">FIG. 23</figref>, for purposes of illustration, the rendering module <b>106</b> may at this point be processing node E <b>2308</b> as indicated by the star glyph <b>2314</b> and in so doing, need to access a child node of node <b>2308</b> providing, for example, an image. In response, the deserialization module <b>126</b> may access the serialization file JKL <b>1818</b> as referenced by the external link <b>2310</b> containing file identification data <b>2312</b>. The deserialization module <b>126</b> may then construct the node G <b>2306</b> from the information <b>1828</b> in serialization file JKL <b>1818</b>. The deserialization module <b>126</b> may also enter the description to node identification entry into the node lookup table <b>128</b> which in its yet further expanded form is illustrated at <b>2304</b>.

0135<figref idref="DRAWINGS">FIG. 24</figref> shows the next operation in the process in which the node G is connected by an inter-node link to node E.

0136Finally, in <figref idref="DRAWINGS">FIG. 25</figref> the processing or rendering of the data structure <b>2502</b> has proceeded to the point where node C <b>2504</b> is to have its child node processed. It will be observed that in the previous <figref idref="DRAWINGS">FIG. 24</figref> that node C has an external link indicating that its child node is constructible from the serialization file JKL <b>1818</b>. In addition, the external link may indicate that the node to be constructed from serialization file JKL <b>1818</b> is an image. At this point in the process of constructing the data structure <b>2502</b>, the deserialization module <b>126</b> may simply be able to look up the description “JKL image” in the table <b>2304</b> and determine that the node of interest has already been constructed and inserted into the data structure and that the external link <b>2402</b> may be removed and simply replaced by an inter-node link <b>2508</b>, thus allowing the processing to continue including processing node G as a child node of node C <b>2504</b> within the node-and-link data structure <b>2502</b>.

0137At this point, the node-and-link representation of the electronic content stored in the three serialization files of <figref idref="DRAWINGS">FIG. 18</figref> may be considered complete.

0138Computer Systems for Carrying Out Example Processes

0139<figref idref="DRAWINGS">FIG. 26</figref> shows a diagrammatic representation of machine in the example form of a computer system <b>2600</b> within which a set of instructions, for causing the machine to perform any one or more of the methodologies, methods, processes, or procedures discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

0140The example computer system <b>2600</b> includes a processor <b>2602</b> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory <b>2604</b> and a static memory <b>2606</b>, which communicate with each other via a bus <b>2608</b>. The computer system <b>2600</b> may further include a video display unit <b>2610</b> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system <b>2600</b> also includes an alphanumeric input device <b>2612</b> (e.g., a keyboard), a user interface (UI) navigation device <b>2614</b> (e.g., a mouse), a disk drive unit <b>2616</b>, a signal generation device <b>2618</b> (e.g., a speaker) and a network interface device <b>2620</b>.

0141The disk drive unit <b>2616</b> includes a machine-readable medium <b>2622</b> on which is stored one or more sets of instructions and data structures (e.g., software <b>2624</b>) embodying or utilized by any one or more of the methodologies or functions described herein. The software <b>2624</b> may also reside, completely or at least partially, within the main memory <b>2604</b> and/or within the processor <b>2602</b> during execution thereof by the computer system <b>2600</b>, the main memory <b>2604</b> and the processor <b>2602</b> also constituting machine-readable media.

0142The software <b>2624</b> may further be transmitted or received over a network <b>2626</b> via the network interface device <b>2620</b> utilizing any one of a number of well-known transfer protocols (e.g., HTTP).

0143While the machine-readable medium <b>2622</b> is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

0144Although an embodiment of the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

0145Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

0146The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.