HK1186551B - Techniques to automatically manage file descriptors - Google Patents

Description

Techniques for automatically managing file descriptors

Technical Field

The present invention relates to a technique for automatically managing file descriptors.

Background

A computer or server may store thousands of files. Thus, it becomes convenient to represent each file with some identification information such as the file name. In this way, the user can locate a particular file of interest. Over time, various techniques have evolved to more efficiently represent different types of files. For example, moving from a text-based representation to a graphics-based representation allows a file to be represented by different icons, one different icon for a word processing document, another different icon for a user spreadsheet document, and so forth. Each evolution in the file representation makes it much easier for a user to locate a given file.

However, recently both online and offline storage has made it possible for a single user to store or access many more (sometimes orders of magnitude) files than ever before. To provide finer distinctions between files, conventional file representation techniques have become using the actual content stored in the files to generate file representations. Computer files may store various types of digital media content. For example, a word processing document may include formatted text, numbers, pictures, tables, and the like. The file representation can now be built using some of the stored content, such as building a file icon with a picture pulled from the file. Despite these innovations, various file representation technologies have not kept pace with the growing level of file storage. Thus, it becomes increasingly difficult for a user to locate a file of interest. It is with respect to these and other considerations that the improvements of the present invention are needed.

Disclosure of Invention

The following presents a simplified summary in order to provide a basic understanding of some novel embodiments described herein. This summary is not an extensive overview, and it is not intended to identify key/critical elements or to delineate the scope of the invention. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Various embodiments are generally directed to techniques to manage electronic files. Some embodiments are particularly directed to techniques for automatically generating, managing, and updating file descriptors for electronic files. In one embodiment, for example, an apparatus may comprise a processor circuit and a file descriptor application running on the processor circuit to manage file descriptors for content files. The file descriptor application is arranged to receive a file descriptor request from a client application, generate a file descriptor or file descriptor construct information for a content file, and send a file descriptor response with the file descriptor or file descriptor construct information to the client application. Other embodiments are also described and claimed.

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the principles disclosed herein can be practiced, and all aspects and equivalents thereof are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.

Drawings

FIG. 1 illustrates an embodiment of a system for managing file descriptors.

FIG. 2 illustrates an embodiment of a first component for a file descriptor application.

FIG. 3 illustrates an embodiment of a second component for a file descriptor application.

FIG. 4 illustrates an embodiment of a third component for a file descriptor application.

FIG. 5 illustrates an embodiment of a second aspect of a third component for a file descriptor application.

FIG. 6 illustrates an embodiment of a third aspect of a third component for a file descriptor application.

FIG. 7 illustrates an embodiment of a fourth component for a file descriptor application.

FIG. 8 illustrates an embodiment of a centralized system for the system of FIG. 1.

FIG. 9 illustrates an embodiment of a distributed system for the system of FIG. 1.

FIG. 10 illustrates a logic flow of the system of FIG. 1.

FIG. 11 illustrates an embodiment of a computing architecture.

FIG. 12 illustrates an embodiment of a communication architecture.

Detailed Description

Embodiments are directed to techniques for automatically generating, managing, and updating enhanced file descriptors for electronic files. An electronic file may comprise any physically or logically defined collection of digital information. The file descriptor may include a user interface element for representing the electronic file. For example, a file descriptor of an electronic file may be implemented as a user interface element (e.g., an icon) having a defined size, shape, or geometry, as well as some descriptive information about the electronic file. File descriptors may allow a user to distinguish a file from other files and quickly determine whether a given file is of interest. When this occurs, the user may select a file descriptor to open the electronic file represented by the file descriptor to more closely examine the contents of the electronic file.

As described above, conventional file representation techniques may attempt to build file descriptors with content from the underlying electronic file. This type of file descriptor may sometimes be informally referred to as a "preview" or "thumbnail" because it gives the user a preview of the file's content. However, there are several problems associated with these types of file descriptors. For example, a file descriptor may present random content from a file. In another example, the file descriptor may randomly organize the file content. In yet another example, the file descriptor may utilize an older and outdated template. In yet another example, the file descriptor may include static content. In yet another example, a file descriptor may only utilize content explicitly found in a given file. In yet another example, the file descriptor may be generated locally by the client device or the operating system. These are only some examples of the disadvantages associated with conventional file descriptions, as well as other disadvantages.

In an attempt to address these and other problems, embodiments provide techniques for generating, managing, and updating an enhanced file descriptor. The enhanced file descriptors provide more meaningful information to the user, thereby allowing the user to more easily identify and select files of interest. The enhanced file descriptor is dynamic in nature. To the extent that the enhanced file descriptor utilizes content from a file, the enhanced file descriptor may be dynamically updated whenever content from the file is updated. In this way, the enhanced file descriptor may provide relevant and up-to-date information about the underlying file. The enhanced file descriptor may also use conversion techniques to transform content from a file from one form (or type) to another form (or type). For example, tabular data from a spreadsheet may be transformed by an enhanced file descriptor into a chart for presentation. The enhanced file descriptor may also be generated by a network device, server, or cloud-based service, rather than by a local client device or client application. This ensures economical deployment of file descriptor services compatible with legacy devices and applications and access to updated templates and content. As a result, embodiments may improve affordability, scalability, modularity, extendibility, or interoperability for an operator, device, or network.

With general reference to the concepts and nomenclature used herein, the detailed description that follows may be presented in terms of program procedures executed on a computer or network of computers. These process descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

A process is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and/or otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

Further, the manipulations performed are often referred to in terms, such as adding or comparing, that are generally associated with mental operations performed by a human operator. In most cases, this ability of a human operator is not necessary or desirable in any of the operations described herein that form part of one or more embodiments. Instead, the operation is a machine operation. Useful machines for performing the operations of the various embodiments include general purpose digital computers or similar devices.

Various embodiments are also directed to an apparatus or system for performing these operations. This apparatus may be specially constructed for the appropriate purposes, or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer. The processes presented herein are not inherently related to a particular computer or other apparatus. Various general-purpose machines may also be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the appropriate method steps. Suitable constructions for various of these machines will appear from the description given.

Reference will now be made to the drawings wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the subject invention. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

Fig. 1 shows a block diagram of a system 100. In one embodiment, the system 100 may include a computer-implemented system 100 having a software application 120 including one or more components 122-a. Although the system 100 shown in fig. 1 has a limited number of elements in a certain topology, it may be appreciated that the system 100 may include more or less elements in alternate topologies as desired for a given implementation.

It is worthy to note that as used herein, "a," "b," "c," and similar designators are variables representing any positive integer. Thus, for example, if an implementation sets the value of a to 5, the complete set of components 122-a may include components 122-1, 122-2, 122-3, 122-4, and 122-5. The embodiments are not limited in this context.

The system 100 may include a file descriptor application 120. The file descriptor application 120 may be generally arranged to automatically generate, manage and/or update an enhanced file descriptor for one or more client applications. Although the file descriptor application 120 is described as an application program, it is understood that the functions and operations of the file descriptor application 120 may be utilized in any software component, including system programs, middleware programs, firmware programs, web services, and the like. Further, as discussed in more detail with reference to fig. 8, 9, the file descriptor application 120 may be implemented by a client device serving a local client application or a network device serving a remote client application over a network. The latter scenario may be implemented using various web technologies and cloud computing technologies accessible via any number of client devices and client applications.

The file descriptor application 120 can include a file descriptor extractor component 122-1. The file descriptor extractor component 122-1 may be generally arranged to extract various portions of multimedia content from the content file 112. Multimedia content may include any digital information element or digital content capable of being stored by the content file 112, such as text, numbers, symbols, images, pictures, video, audio, animation, and so forth. The file descriptor extractor component 122-1 may access the content file 112, for example, from the data store 124.

The content file 112 may include any digital information element or digital content generated by a software program, such as an application program, a web application, a web service, a client application, a server application, a system program, and so forth. Different software programs may generate different types of digital content. In this way, the digital content generated by different software programs may include different kinds of digital content. Examples of content files 112 may include, but are not limited to, application files such as word processing files, spreadsheet files, presentation files, Personal Information Manager (PIM) files, database files, publisher files, drawing files, note files, message files, project files, and so forth. Other examples of the content file 112 may include multimedia files such as audio files, image files, video files, audio/video (AV) files, animation files, game files, markup files, web page files, Social Network Service (SNS) files, and the like. Other examples of content files 112 may include web pages, social networking site feeds (e.g.,a feed source,Feeds, etc.), news feeds (e.g., Really Simple Syndication (RSS) feeds, news gathering web sites and portals, etc.), search engine results, web portal feeds, and other online content types. It may be appreciated that these are merely some examples of content files 112, and that the various embodiments are not limited to these examples.

In one embodiment, the content files 112 may include content files for a productivity suite of interrelated client application programs, server application programs, and web services designed for a particular operating system, such as MICROSOFT (R) for MICROSOFT CORPORATION of Redmond, Washington, USAIs/are as followsOFFICE productivity suite. Examples of client applications may include, but are not limited to: MICROSOFT WORD, MICROSOFTMICROSOFTMICROSOFTMICROSOFTMICROSOFTMICROSOFTMICROSOFT PROJECT、MICROSOFT PUBLISHER、MICROSOFTWORKSPACE、MICROSOFTMICROSOFT OFFICINTERCONNECT, MICROSOFT OFFICE PICTURE MANAGER, MICROSOFT SHAREPOINT DESIGNER, and MICROSOFT LYNC. Examples of server applications may include, but are not limited to: MICROSOFT SHAREPOINTSERVER, MICROSOFT LYNC SERVER, MICROSOFT OFFICE FORMS SERVER, MICROSOFT OFFICESERVER, MICROSOFT OFFICE PROJECT SERVER, MICROSOFT OFFICE PROJECTPORTFOLIO SERVER, and MICROSOFT OFFICEAnd (5) a SERVER. Examples of web services may include, but are not limited to: MICROSOFT WINDOWSMICROSOFT OFFICE WEBAPPLICATIONS, MICROSOFT OFFICE LIVE, MICROSOFT LIVE MEETING, MICROSOFT OFFICE EPODUCT WEB SITE, MICROSOFT UPDATE SERVER, and MICROSOFT OFFICE 365. Embodiments are not limited to these examples.

The file descriptor application 120 may include a file descriptor replacement component 122-2. The file descriptor replacement component 122-2 may be generally arranged to replace, transform, or otherwise replace one type of content stored by the content file 112 with another type of content. For example, the content file 112 of a spreadsheet application may store data in a tabular form. The file descriptor replacement component 122-2 can transform the tabular data into a chart representing the tabular data. The chart may then be used to construct a file descriptor 134 that represents the content file 112. In another example, the content file 112 of the word processing application may store "dog" in textual form. The file descriptor replacement component 122-2 may transform the text "dog" into a picture, image, or animation of the dog. The picture may then be used to construct a file descriptor 134 representing the content file 112.

The file descriptor application 120 may include a file descriptor assembly component 122-3. The file descriptor assembly component 122-3 may be generally arranged to generate, construct or otherwise assemble the file descriptor construct information 132 and/or the file descriptor 134 using one or more content portions extracted by the file descriptor extractor component 122-1 from the content file 112 as originally found in the content file 112 or as replaced by the file descriptor replacement component 122-2.

To assemble the file descriptor construct information 132 or the file descriptor 134 as appropriate, the file descriptor assembly component 122-3 may utilize the file descriptor model 126-b stored by the data store 124 to generate the file descriptor construct information 132 and/or the file descriptor 134. The file descriptor model 126-b may include templates for building or generating file descriptors 134. The file descriptor model 126-b may define an extraction rule set for what content is extracted from the content file 112, a formatting rule set that specifies the format, layout, or location of the extracted content, a presentation rule set that controls how the extracted content is presented to the user (e.g., font size, bold, underline, italics, style, etc.), a transformation rule set that details when and how the extracted content is transformed, and other rules that define how the custom file descriptor 134 can be generated. Different file descriptor models 126-b may be defined for different types of content files 112. For example, a first file descriptor model 126-1 may define how file descriptors 134 may be generated for a word processing document, while a second file descriptor model 126-2 may define how file descriptors may be generated for a spreadsheet document, and so on. In another example, the third and fourth descriptor models 126-3, 126-4 may be two alternative models for a single presentation document. Embodiments are not limited to the number or type of file descriptor models 126-b, and they may vary depending on implementation.

The file descriptor application 120 may include a file descriptor synchronizer component 122-4. The file descriptor synchronizer component 122-4 may be generally arranged to synchronize changes made to content portions of the content file 112 with corresponding content portions for the file descriptor 134. For example, if the file descriptor 134 utilizes a picture from the content file 112 and updates the picture in the content file 112 with a new picture, the file descriptor synchronizer component 122-4 will automatically detect the change and update the file descriptor 134 with the new picture. This may be accomplished, in part, by uniquely identifying each content portion common to the content file 112 and file descriptor 134, as described further below.

In general operation, the file descriptor application 120 may run on a processor circuit (as shown in FIG. 11) to manage the file descriptors 134 of the content files 112. The file descriptor application 120 may be arranged to receive a file descriptor request 110 from a client application (as shown in fig. 9), generate a file descriptor 134 or file descriptor construct information 132 for the content file 112, and send a file descriptor response 130 with the file descriptor 134 or file descriptor construct information 132 to the client application. An entity of the client device (e.g., a client application, operating system, local file descriptor application, etc.) may then use the file descriptor construct information 132 to generate a file descriptor 134, or use the file descriptor 134 received with the file descriptor response 130 to represent the content file 112 on the client device.

FIG. 2 illustrates an embodiment of an operating environment 200 for the system 100. More specifically, the operating environment 200 illustrates exemplary operations for the file descriptor extraction component 122-1.

As described with reference to FIG. 1, the file descriptor application 120 may include a file descriptor extractor component 122-1. The file descriptor extractor component 122-1 may be used to retrieve the file descriptor model 126-b from the data store 124 to generate the file descriptor 134. A particular file descriptor model 126-b, such as file descriptor model 126-1, may be retrieved for a number of different reasons. For example, the file descriptor model 126-1 may be retrieved based on the file type of the content file 112, the client application that originally issued the file descriptor request 110, or the client device hosting the client application, among other factors.

The file descriptor extractor component 122-1 may extract one or more content portions 204-c from the content file 112 based on the file descriptor model 126-1. Content portion 204-c is any discrete or defined set of digital information stored by content file 112. As described above, the content file 112 may include digital information. The digital information may be grouped physically or logically based on a number of factors such as proximity, content type (e.g., text, pictures, charts, etc.), content formatting (e.g., sentences, paragraphs, sections, chapters, etc.), and the like. Additionally or alternatively, content portion 204-c may include information associated with content file 112, such as file names, file paths, metadata, descriptors, properties, attributes, and the like. As used herein, the content portion 204-c that has been extracted from the content file 112 may be referred to as an extracted content portion 208-s. For example, after performing the extraction operation, content portion 204-1 may be referred to as extracted content portion 208-1.

The file descriptor model 126-1 may include a file descriptor surface 222. The file descriptor surface 222 may comprise a two-dimensional (2D) or three-dimensional (3D) topological space having any defined size with a coordinate system and boundaries. The file descriptor surface 222 may generally have a size smaller than the presentation surface for the content file 112. Examples of presentation surfaces used by the content file 112 may include, but are not limited to: documents for word processing programs, slides for presentation programs, worksheets for spreadsheet programs, note pads for note pad programs, contact cards for personal information management Programs (PIMs), and other space typically used by application programs. In one embodiment, for example, the file descriptor surface 222 may have a size equal to 200 x 200 pixel space of an output device, such as an electronic display.

The file descriptor surface 222 may include various file descriptor tiles (tiles) 224-e defined or placed on the file descriptor surface 222 in a particular topology. The file descriptor tile 224-e may comprise a defined area of the file description surface 222 designed to present a discrete set of information, such as the content portion 204-c or the extracted content portion 208-s. The defined area may be of any size, dimension, or shape as desired for a given implementation. A given file descriptor surface 222 may have any number of file descriptor tiles 224-e, and each file descriptor tile 224-e may have a defined set (e.g., size, shape, size, geometry) to ensure that all file descriptor tiles 224-e fit the given size of the file descriptor surface 222. The definition of a file descriptor tile 224-e may change dynamically based on the following factors: a file descriptor surface 222, a collection of content portions 204-c or extracted content portions 208-s, an association between a content portion 204-c or extracted content portion 208-s and a file descriptor tile 224-e, characteristics of the display, characteristics of the device, user preferences, and other factors. The embodiments are not limited in this context.

The extracted content portions 208-s may be inserted into various file descriptor tiles 224-e of the file descriptor model 126-1 during an assembly operation, as described further below. As shown in FIG. 2, once the file descriptor extraction component 122-1 extracts the content portion 204-1 from the content file 112, the file descriptor assembly component 122-3 may insert the extracted content portion 204-1 into a corresponding file descriptor tile 224-1 of the file descriptor surface 222. The insertion of the content portion 204-2 into the file descriptor tile 224-2 may continue, and so on, until the file descriptor surface 222 has been completely filled, there are no remaining content portions 204-c of the content file 112, a timer expires, or some other termination condition occurs.

To extract the appropriate content portion 204-c of the content file 112, the file descriptor extraction component 122-1 may utilize instructions, rules, or algorithms provided by the file descriptor model 126-1. Additionally or alternatively, the file descriptor extraction component 122-1 may utilize proprietary content extraction algorithms designed for the file descriptor application 120.

The content extraction algorithm may contain a set of rules relating to the type of information retrieved from the content file 112. Different content extraction algorithms may be utilized for different file types. By way of example and not limitation, a content extraction algorithm may be described that is designed to extract content portions 204-c from content files 112, including word processing documents. However, it will be appreciated that similar principles as required for a given implementation may be used to design different content extraction algorithms for different file types. The embodiments are not limited in this context.

In one embodiment, for example, the content extraction algorithm may utilize three classes of information and associated rules, including content and attribute classes (e.g., paragraphs or attributes) from the content file 112, content object classes (e.g., images, embedded objects) of the content file 112, and content page classes within the content file 112, or some combination thereof. It will be appreciated that any number of classes or categories may be defined for a given content file type.

In one embodiment, an example of a content and attribute class may be shown in Table 1 as follows:

TABLE 1

content/Property	Description of the invention
		Title (Property)	Title attribute of document
Abstract	Summary of a document
		Filename	File name of document
Authors refer to	Author of document
		Title (first example of title Style)	First paragraph of application title style
The first N body paragraphs	The first N body paragraphs within a document
		Top N subtitles	First N paragraph subtitles used within a document

In one embodiment, an example of a content object class may be shown in Table 2 as follows:

TABLE 2

In one embodiment, an example of a content page class may be shown in Table 3 as follows:

TABLE 3

A content extraction algorithm may be used to retrieve the content portion 204-c from the content file 112 stored by the data store 124. The file descriptor assembly component 122-3 may then organize and format the extracted content portions 204-c to generate the file descriptors 134. For example, rules for a content extraction algorithm may specify: any text retrieved from within the document (such as the first N paragraphs) will preserve the style formatting specified within the document. Another rule may be: content attributes that are not actual text within the document will be formatted as normal styles as defined within the document. Yet another rule may be: if the entire text of content portion 204-c cannot fit the size of file descriptor tile 224-e, an ellipsis will be appended at the end of the text. These are merely some exemplary rules and other rules are possible. The embodiments are not limited in this context.

In some cases, the content extraction algorithm may define a set of rules for creating the file descriptor 134 from a combination of content and attribute classes, content object classes, and content page classes, sometimes referred to as a "mashup". This provides a highly customized file descriptor 134 that is structured to represent the content of the content file 112.

In one embodiment, examples of different class combinations may be shown in table 4 as follows:

TABLE 4

The content extraction algorithm may also provide rules that limit the file descriptors 134 to a single class or types in a class. For example, a rule may be defined to use only content from the content file 112 in the form of text, or content objects from the content file 112 in the form of images.

The content extraction algorithm may still further provide rules for generating a list of multiple versions of the file descriptor 134 for presentation to the user for final selection. For example, a rule may generate P versions of file descriptor 134, with P representing any positive integer (e.g., P10). The list of multiple versions of file descriptors 134 may be generated according to the example given in table 5 below:

TABLE 5

At some point before, during, or after the extraction operation, the file descriptor extractor component 122-1 may assign a content portion identifier 206-d to each of the content portions 204-c or the extracted content portions 208-s of the content file 112. Alternatively, each content portion 204-c of the content file 112 may be pre-assigned to a content portion identifier 206-d. The content portion identifier 206-d uniquely identifies the corresponding extracted content portion 208-s. In addition, each of the extracted content portions 208-s corresponds to a file descriptor tile 224-e of the file descriptor surface 222 of the file descriptor 134. In this manner, when changes are made to the content portion 204-c as stored by the content file 112, the file descriptor synchronizer component 122-4 can identify the corresponding extracted content portion 208-s used by the file descriptor 134 in order to perform update operations on the file descriptor 134.

Fig. 3 illustrates an embodiment of an operating environment 300 for the system 100. More specifically, the operating environment 300 illustrates exemplary operations for the file descriptor replacement component 122-2.

As described with reference to FIG. 1, the file descriptor application 120 may include a file descriptor replacement component 122-2. The file descriptor replacing component 122-2 may be operative to replace the content portion 204-c from the content file 112 with a substitute content portion 304-f to form an extracted content portion 208-s. The substitute content portion 304-f may include a content portion that serves as a replacement, substitute, or substitute for the content portion 204-c.

In one embodiment, the substitute content portion 304-f may be a static portion that was previously created and stored by the data source. In this case, the file descriptor replacement component 122-2 may select a stored substitute content portion 304-f that is appropriate for the extracted content portion 204-c. Examples of suitable data sources for substitute content portions 304-f may include, but are not limited to: another content portion 204-c from the same or a different content file 112, an alternate content portion 304-f stored by the data store 124, or some other data source.

In one embodiment, the substitute content portion 304-f may be automatically and dynamically generated from the extracted content portion 204-c. To dynamically generate the substitute content portion 304-f, the file descriptor replacement component 122-2 may utilize instructions, rules, or algorithms provided by the file transformation model 308-g. The file transformation model 308-g may be designed for different content files 112, content portions 204-c of content files 112, content types, content formats, client applications, and so forth.

In operation, it is assumed that file transformation model 308-1 is specifically designed for spreadsheet applications. Assume further that the file descriptor extractor component 122-1 extracts the content portion 204-3 from the content file 112 of the spreadsheet application. The file descriptor extraction component 122-1 detects that the content portion 204-3 is tabular data. The file descriptor extraction component 122-1 may notify the file descriptor replacement component 122-2. The file descriptor replacement component 122-2 may retrieve the substitute content portion 304-3 or the file transformation model 308-1 from the data store 124. In the former case, the file descriptor replacement component 122-2 may replace the content portion 204-3 with the stored replacement content portion 304-3. In the latter case, file descriptor replacement component 122-2 may use file transformation model 308-1 to generate substitute content portion 304-3 from content portion 204-3. File transformation model 308-1 may include a set of rules or program instructions for transforming tabular data into a bar graph. The file descriptor replacing component 122-2 can replace the content portion 204-3 with the generated replacement content portion 304-3. The substitute content portion 304-3 becomes the extracted content portion 208-3. The bar graph may then be used to construct a file descriptor 134 representing the content file 112.

Fig. 4 illustrates an embodiment of an operating environment 400 for the system 100. More specifically, the operating environment 400 illustrates exemplary operation of the file descriptor assembly component 122-3 in assembling the file descriptor 134.

The file descriptor assembly component 122-3 may be operative to generate a file descriptor 134 from one or more extracted content portions 208-s from the content file 112 based on the file descriptor model 126-b. The file descriptor assembly component 122-3 may take the extracted content portion 208-s and any substitute content portions 304-f and insert them into the appropriate file descriptor tile 224-e. To facilitate assembly, the file descriptor assembly component 122-3 may receive as input information about the file descriptor tile 224-e from the file descriptor model 126-b. This information may include information such as location, size, shape, dimensions, geometry, boundaries, adjacent file descriptor tiles 224-e, conjoined file descriptor tiles 224-e, and the like. For example, if the extracted content portion 208-s is too large for the current size of the file descriptor tile 224-1, the file descriptor assembly component 122-3 may use information about adjacent or joined file descriptor tiles 224-2, 224-3 to determine whether the current size of the file descriptor tile 224-1 may be increased to accommodate the larger portion and whether the current size of the file descriptor tiles 224-2, 224-3 may be decreased accordingly. The file descriptor assembly component 122-3 can implement various fitting algorithms for accommodating these scenarios.

Fig. 5 illustrates an embodiment of an operating environment 500 for the system 100. More specifically, the operating environment 500 illustrates exemplary operations of the file descriptor assembly component 122-3 in assembling the file descriptor construct information 132.

In addition to assembling the actual file descriptor 134, the file descriptor assembly component 122-3 may also be used to generate file descriptor construct information 132 for use by a client application (or another entity) to generate the file descriptor 134 for the content file 112.

In one embodiment, the file descriptor construct information 132 may include all of the information needed to assemble the file descriptor 134. For example, the file descriptor construct information 132 may include a file descriptor model 126-b having a file descriptor surface 222 and one or more file descriptor tiles 224-e arranged to present one or more extracted content portions 208-s from the content file 112. The file descriptor structure information 132 may also include the actual extracted content portion 204-c.

Once assembled, the file descriptor application 120 may then send file descriptor construct information 132 to either the local client application or the remote client application. The local or remote client application may use the received file descriptor construct information 132 to generate a file descriptor 134 for the content file 112.

Fig. 6 illustrates an embodiment of an operating environment 600 for the system 100. More specifically, the operating environment 600 illustrates exemplary operations of the file descriptor assembly component 122-3 in assembling the file descriptor construct information 132.

As described with reference to fig. 5, the file descriptor assembly component 122-3 may be used to generate file descriptor construct information 132 for use by a client application (or another entity) to generate a file descriptor 134 for the content file 112. In one embodiment, the file descriptor construct information 132 may include only a portion of the information needed to assemble the file descriptor 134. The client may access any additional information needed to assemble the file descriptor 134, such as the content file 112.

As shown in FIG. 6, the file descriptor construct information 132 may include a file descriptor model identifier 604, at least one file descriptor tile identifier 606-h for identifying a file descriptor tile 224-e on the file descriptor surface 222 of the file descriptor model 126-b, and at least one content portion identifier 206-d for identifying a content portion 204-c in the content file 112 corresponding to the file descriptor tile 224-e identified by the file descriptor tile identifier 606-h.

Alternatively, the file descriptor construct information 132 may be limited to only the file descriptor model 126-b or the file descriptor model identifier 604. The former case may be desirable, for example, when the file descriptor application 120 is implemented in a client-server environment where the client device includes or is not updatable with the latest set of inaccessible file descriptor models 126-d. In this case, the file descriptor construct information 132 may include the latest file descriptor model 126-b appropriate for a given content file 112. The latter case may be desirable, for example, to reduce network traffic or for a low bandwidth connection of the server device and the client device fingertips.

Once assembled, the file descriptor application 120 may then send file descriptor construct information 132 to either the local client application or the remote client application. The local or remote client application may use the received file descriptor construct information 132 to generate a file descriptor 134 for the content file 112. For example, the client application may match the content portion identifier 206-d embedded in the received file descriptor construct information 132 with the content portion identifier 206-d in the content file 112. The client application may utilize the client version of the file descriptor application 120 to extract and assemble the content portions 204-c with matching content portion identifiers 206-d.

Fig. 7 illustrates an embodiment of an operating environment 700 for the system 100. More specifically, the operating environment 700 illustrates exemplary operation of the file descriptor synchronizer component 122-4 in synchronizing the content portion 204-c in the file descriptor 134.

The file descriptor synchronizer component 122-4 may be used to synchronize changes to the content portion 204-c of the content file 112 with the corresponding extracted content portion 208-s of the content file 112 of the file descriptor 134. This may be performed using a push model or a pull model.

In the push model, a change event 702-j may occur for the content portion 204-c of the content file 112. The change event 702-j may include any modifications made to the content portion 204-c, such as content changes, format changes, style changes, content edits, content deletions, and the like. The file descriptor synchronizer component 122-4 detects the change event 702-j (or is notified) and initiates a synchronization operation to synchronize any changes made to the content portion 204-c with the corresponding extracted content portion 208-s of the file descriptor 134. For example, assume that the file descriptor includes an extracted content portion 208-1 corresponding to the content portion 204-1 of the content file 112. Assume further that the content portion 204-1 is a non-underlined phrase such as "Class Trip To the zoom". It is further assumed that the user changes the format of the content portion 204-1 from "Class Trip to the zoom"Class Trip To The Zoo". The change includes a change event 702-1. The file descriptor synchronizer component 122-4 can detect the change event 702-1 by periodically monitoring the private or public storage location of the content file 112. Alternatively, the client application may notify the file descriptor synchronizer component 122-4 of the change event 702-1. Once aware of the change event 702-1, the file descriptor synchronizer component 122-4 can push the change to a client application (or some other entity) that in turn executes a change update event 704-1 for the extracted content portion 208-1 of the file descriptor 134 such that the content portion 204-1 and the extracted content portion 208-1 are substantially identical to one another. Similarly, a change event 702-2 to content portion 204-2 may result in a change update event 704-2 for extracted content portion 208-2. The synchronization operation may continue in a similar manner for other change events 702-j.

Instead of using a push model to push changes to the client application, the file descriptor synchronizer component 122-4 may instead use a pull model in which it sends the client a request to generate a new file descriptor 134. The client application may then send a new file descriptor request 110 with the updated content file 112, and the file descriptor application 120 may generate a new file descriptor 134 in response to the new file descriptor request 110. In this sense, the client application utilizes the file descriptor synchronizer component 122-4 to "pull" changes.

Another example of a pull model may include using a particular trigger to identify the time at which a new file descriptor request 110 is sent. Examples of triggers may be timer-based periodic triggers, on-demand triggers (e.g., user requests), or event-based triggers based on user actions detected by a client device or client application. For example, a timer may be used to automatically request updates to the file descriptor 134 on a periodic basis. In another example, a user may manually request an update to the file descriptor 134. In yet another example, the client application may detect when changes are made to the content file 112 and use the changes as event-based triggers to generate a new file descriptor request 110. The file descriptor synchronizer component 122-4 can update a particular extracted content portion 208-s or the entire file descriptor 134.

Fig. 8 illustrates a block diagram of a centralized system 800. The centralized system 800 may implement some or all of the structure and/or operations of the system 100 in a single computing entity, such as entirely within a single device 820.

Device 820 may comprise any electronic device capable of receiving, processing, and transmitting information for system 100. Examples of electronic devices may include, but are not limited to: an ultra-mobile device, a Personal Digital Assistant (PDA), a mobile computing device, a smart phone, a telephone, a digital telephone, a cellular telephone, an electronic book reader, a cellular telephone, a one-way pager, a two-way pager, a messaging device, a computer, a Personal Computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server array or server farm, a web server, a network server, an Internet server, a workstation, a minicomputer, a mainframe computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor system, processor-based system, consumer electronics, programmable consumer electronics, gaming devices, televisions, digital televisions, set top boxes, wireless access points, a base station, a subscriber station, a mobile subscriber center, a radio network controller, a router, a hub, a gateway, a bridge, a switch, a machine, or a combination thereof. The embodiments are not limited in this context.

The device 820 may use the processing component 830 to perform processing operations or logic for the system 100. The processing component 830 may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include: devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Digital Signal Processors (DSP), Field Programmable Gate Array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include: software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, Application Program Interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

Device 820 may use communication component 840 to perform communication operations or logic for system 100. Communications component 840 may implement any well-known communications techniques and protocols, such as techniques suitable for use with packet-switched networks (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), circuit-switched networks (e.g., the public switched telephone network), or a combination of packet-switched networks and circuit-switched networks (using suitable gateways and translators). Communications component 840 may include various types of standard communications elements, such as one or more communications interfaces, Network Interface Cards (NICs), radios, wireless transmitters/receivers (transceivers), wired and/or wireless communications media, physical connectors, and so forth. By way of example, and not limitation, communication media 812, 842 includes wired communication media and wireless communication media. Examples of wired communications media may include a wire, cable, wire, Printed Circuit Board (PCB), backplane, switch fabric, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communication media may include acoustic, Radio Frequency (RF) spectrum, infrared and other wireless media.

Device 820 may communicate with other devices 810, 850 over communication media 812, 842, respectively, using communication signals 814, 844 via communication component 840. Devices 810, 850 may be internal or external to device 820, as desired for a given implementation.

In this implementation, the file descriptor application 120 of the system 100 may be implemented in a single device, such as a client device or a network device. For example, the file descriptor application 120 may be located on a client device along with the client application 802. The client application 802 may request services from the file descriptor application 120 to generate file descriptors 134 for various content files 112 managed by the client application 802. For example, the client applications 802 can include a productivity suite of interrelated client applications, server applications, and web services designed for a particular operating system, such as MICROSOFT (R) for MICROSOFT (R) manufactured by MICROSOFT CORPORATION of Redmond, WashingtonIs/are as followsOFFICE productivity suite, as described above. In another example, client application 802 can include a system program, such as an operating system for device 820. In this case, the client application 802 may request file descriptor services from the file descriptor application 120 for file management operations such as file presentation, navigation, selection, and the like. In yet another example, the file descriptor application 120 may be located with the client application 802 on a network device such as a server, web server, enterprise server, or cloud server. In this case, both the client application 802 and the system 100 may access the cloud-based service via one or both devices 810, 850. Examples of such implementations may include, but are not limited to: MICROSOFT WINDOWSMICROSOFT OFFICE WEBAPPLICATIONS, MICROSOFT OFFICE LIVE, MICROSOFT LIVE MEETING, MICROSOFT OFFICE EPODUCT WEB SITE, MICROSOFT UPDATE SERVER, and MICROSOFT OFFICE 365.

Fig. 9 shows a block diagram of a distributed system 900. Distributed system 900 may distribute portions of the structure and/or operation of system 100 across multiple computing entities. Examples of distributed system 900 may include, but are not limited to, a client-server architecture, a layer 3 architecture, an N-layer architecture, a tightly coupled or clustered architecture, a peer-to-peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems. The embodiments are not limited in this context.

Distributed system 900 may include client devices 910 and server devices 950. In general, the client device 910 and the server device 950 may be the same as or similar to the client device 820 described with reference to FIG. 8. For example, client device 910 and server device 950 may each include a processing component 930 and a communication component 940 that are the same as or similar to processing component 830 and communication component 840, respectively, described with reference to fig. 8. In another example, devices 910, 950 may communicate over communication medium 912 using communication signals 914 via communication component 940.

The client device 910 can include or employ one or more client programs that operate to perform methods in accordance with the described embodiments. For example, in one embodiment, the client device 910 may implement the client application 802 as described with reference to FIG. 8.

The server device 950 may include or employ one or more server programs that operate to perform methods in accordance with the described embodiments. For example, in one embodiment, server device 950 may implement file descriptor application 120 of system 100.

In this implementation, the client application 802 of the client device 910 may send a file descriptor request 110 for a content file 112 to the server device 950 over the network in the form of a communication signal 914. The client application 802 may initiate the file descriptor request 110 using a push model or a pull model as described above. In one embodiment, the file descriptor request 110 may include a content file 112. In one embodiment, the file descriptor request 110 may include a content file identifier that may be used by the file descriptor application 120 to retrieve the content file 112 from the data store 124 or a network storage device. The file descriptor application 120 may generate the file descriptor construct information 132 and/or the file descriptor 134 as described above and send the file descriptor response 130 with the file descriptor construct information 132 and/or the file descriptor 134 to the client device 910 via the communication signal 914. Upon receiving the file descriptor construct information 132, the client application 802 or an operating system of the client device 910 may assemble or generate the file descriptor 134 to represent the content file 112. Upon receiving the file descriptor 134, the client application 802 or an operating system of the client device 910 may render the file descriptor 134 to represent the content file 112.

Included herein is a set of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, e.g., in the form of a flow chart, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with the present invention, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

FIG. 10 illustrates one embodiment of a logic flow 1000. Logic flow 1000 may be representative of some or all of the operations executed by one or more embodiments described herein.

In the embodiment illustrated in FIG. 10, the logic flow 1000 may receive a file descriptor request from a client application to generate a file descriptor for a content file at block 1002. For example, the file descriptor application 120 of the system 100 may receive the file descriptor request 110 from the client application 802 to generate the file descriptor 134 of the content file 112.

The logic flow 1000 may retrieve a file descriptor model for the file descriptor at block 1004. For example, the file descriptor extractor component 122-1 may retrieve the file descriptor model 126-1 for the file descriptor 134 from the data store 124.

The logic flow 1000 may extract one or more content portions from the content file based on the file descriptor model at block 1006. For example, the file descriptor extractor component 122-1 may extract one or more content portions 204-c from the content file 112 based on the file descriptor model 126-1. The file descriptor extractor component 122-1 may also identify one or more extracted content portions 208-s from the content file 112 by utilizing a previously assigned content portion identifier 206-d or by assigning a content portion identifier 206-d to an extracted content portion. The content portion identifier 206-d may be used to synchronize updates to the file descriptor 134.

During the extraction operation, the file descriptor extractor component 122-1 may determine that the content portion 204-c should be replaced with another content portion. In this case, the file descriptor extraction component 122-1 may notify the file descriptor replacement component 122-2. The file descriptor replacement component 122-2 may replace the content portion 204-c from the content file 112 with the replacement content portion 304-f. The file descriptor replacement component 122-2 may retrieve the substitute content portion 304-f from the data store 124 or generate the substitute content portion 304-f at runtime. The file descriptor replacement component 122-2 may replace the content portion 204-c with a substitute content portion 304-f, which substitute content portion 304-f then becomes the extracted content portion 208-s.

The logic flow 1000 may generate a file descriptor response to the file descriptor request at block 1008 that includes file descriptor construct information or file descriptors generated using the file descriptor model and the extracted content portions. For example, the file descriptor assembly component 122-3 may generate a file descriptor response 130 to the file descriptor request 110, the file descriptor response 130 including the file descriptor construct information 132 or the file descriptor 134 generated using the file descriptor model 126-1 and the extracted content portion 208-s.

The file descriptor assembly component 122-3 may generate file descriptor construct information 132 for use by the client application 802 to generate the file descriptor 134 for the content file 112. In one embodiment, the file descriptor construct information 132 may include the file descriptor model 126-1 and one or more extracted content portions 208-s extracted from the content file 112. In one embodiment, the file descriptor construct information may include the file descriptor model identifier 604 of the file descriptor model 126-1, one or more file descriptor tile identifiers 606-h of the file descriptor tile 224-e of the file descriptor model 126-1, and one or more content portion identifiers 206-d from the content file 112 corresponding to the extracted content portion 208-s of the file descriptor tile 224-e.

The file descriptor assembly component 122-3 may generate the file descriptor 134 from one or more extracted content portions 208-s from the content file 112 based on the file descriptor model 126-1. For example, the file descriptor assembly component 122-3 may insert each of the extracted content portions 208-s into a corresponding file descriptor tile 224-e of the file descriptor surface 222. The file descriptor assembly component 122-3 may use a fitting algorithm as described above to make any adjustments to the inserted portions.

The logic flow 1000 may send a file descriptor response to the client application at block 1010. For example, file descriptor application 120 may send file descriptor response 130 to client application 802.

Once file descriptor 134 is generated by file descriptor application 120 or client application 802, changes made to content portion 204-c of content file 112 may be propagated to file descriptor 134. The file descriptor synchronizer component 122-4 may synchronize changes to the content portion 204-c of the content file 112 with the corresponding extracted content portion 208-s of the content file 112 represented by the file descriptor 134. This ensures that the content portion 204-c of the content file 112 and the extracted content portion 208-s of the file descriptor 134 are synchronized and remain substantially the same. As a result, the file descriptor 134 continues to accurately represent the underlying content file 112 in substantially real-time.

FIG. 11 illustrates an embodiment of an exemplary computing architecture 1100 suitable for implementing the various embodiments described above. In one embodiment, the computing architecture 1100 may comprise or be implemented as part of a computing device. Examples of electronic devices may include those described with reference to fig. 8, and so on. The embodiments are not limited in this context.

As used in this application, the terms "system" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution, examples of which are provided by the exemplary computing architecture 1100. For example, a component may be, but is not limited to being, a process running on a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Further, the components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve a one-way or two-way exchange of information. For example, a component may communicate information in the form of signals communicated over the communications media. This information may be implemented as signals assigned to the respective signal lines. In these allocations, each message is a signal. However, other embodiments may alternatively employ data messages. These data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

Computing architecture 1100 includes various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth. The embodiments, however, are not limited to implementation by the computing architecture 1100.

As shown in FIG. 11, the computing architecture 1100 includes a processing unit 1104, a system memory 1106, and a system bus 1108. The processor unit may be any of various commercially available processors including, but not limited to:anda processor;application, embedded and secure processors;andanda processor; IBM anda Cell processor;Core(2)anda processor; and the like. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing unit 1104.

The system bus 1108 provides an interface for system components including, but not limited to, the system memory 1106 to the processing unit 1104. The system bus 1108 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. An interface adapter may be connected to the system bus 1108 via a socket architecture. Exemplary socket architectures may include, but are not limited to: accelerated Graphics Port (AGP), card bus, (extended) industry Standard architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, peripheral component interconnect (extended) (PCI (X)), PCI express, Personal Computer Memory Card International Association (PCMCIA), and so forth.

The computing architecture 1100 may comprise or implement various articles of manufacture. An article of manufacture may comprise a computer-readable storage medium to store logic. Examples of a computer-readable storage medium may include any tangible medium capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

The system memory 1106 may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), Random Access Memory (RAM), dynamic RAM (dram), double data rate dram (ddram), synchronous dram (sdram), static RAM (sram), programmable ROM (prom), erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, Solid State Drives (SSD)), and any other type of media suitable for storing information. In the illustrated embodiment shown in FIG. 11, the system memory 1106 can include non-volatile memory 1110 and/or volatile memory 1112. A basic input/output system (BIOS) can be stored in the non-volatile memory 1110.

The computer 1102 may include various types of computer-readable storage media in the form of one or more relatively low-speed memory units, including an internal (or external) Hard Disk Drive (HDD)1114, a magnetic Floppy Disk Drive (FDD)1116 for reading from and writing to a removable magnetic disk 1118, and an optical disk drive 1120 for reading from or writing to a removable optical disk 1122 (e.g., a CD-ROM or DVD). The HDD 1114, FDD 1116 and optical disk drive 1120 can be connected to the system bus 1108 by a HDD interface 1124, an FDD interface 1126 and an optical drive interface 1128, respectively. The HDD interface 1124 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units 1110, 1112, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. In one embodiment, the one or more application programs 1132, other program modules 1134, and program data 1136 can include, for example, various applications and/or components of system 100.

A user can enter commands and information into the computer 1102 through one or more wired/wireless input devices, e.g., a keyboard 1138 and a pointing device, such as a mouse 1140. Other input devices may include: infrared (IR) remote controls, Radio Frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retinal readers, touch screens (e.g., capacitive touch screens, resistive touch screens, etc.), trackballs, trackpads, sensors, pointing devices, and the like. These and other input devices are often connected to the processing unit 1104 through an input device interface 1142 that is coupled to the system bus 1108, but can be connected by other interfaces, such as a parallel port, IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

A monitor 1144 or other type of display device is also connected to the system bus 1108 via an interface, such as a video adapter 1146. The monitor 1144 may be internal or external to the computer 1102. In addition to the monitor 1144, a computer typically includes other peripheral output devices, such as speakers, printers, etc.

The computer 1102 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s) 1148. The remote computer(s) 1148 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1102, although, for purposes of brevity, only a memory/storage device 1150 is illustrated. The logical connections depicted include wired/wireless connectivity to a Local Area Network (LAN)1152 and/or larger networks, e.g., a Wide Area Network (WAN) 1154. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer 1102 is connected to the LAN 1152 through a wired and/or wireless communication network interface or adapter 1156. The adapter 1156 may facilitate wired and/or wireless communication to the LAN 1152, which may also include a wireless access point disposed thereon for communicating using the wireless functionality of the adapter 1156.

When used in a WAN networking environment, the computer 1102 can include a modem 1158, or is connected to a communications server on the WAN1154, or has other means for establishing communications over the WAN1154, such as by way of the Internet. The modem 1158, which can be internal or external and a wire and/or wireless device, is connected to the system bus 1108 via the input device interface 1142. In a networked environment, program modules depicted relative to the computer 1102, or portions thereof, can be stored in the remote memory/storage device 1150. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

The computer 1102 is operable to communicate with wired and wireless devices or entities using the IEEE802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE802.11 via over-the-air modulation techniques). This includes at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth^TMWireless technologies, etc. Thus, the communication may be a predefined structure as for a conventional network, or simply an ad hoc (ad hoc) communication between at least two devices. Wi-Fi networks use radio technologies called IEEE802.11x (a, b, n, g, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

FIG. 12 illustrates a block diagram of an exemplary communication architecture 1200 suitable for implementing various embodiments described above. The communications architecture 1200 includes various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, power supplies, and so forth. Embodiments, however, are not limited to implementation by the communications architecture 1200.

As shown in FIG. 12, the communication architecture 1200 includes one or more client(s) 1202 and a server 1204. The client 1202 may implement the client device 910. The server 1204 may implement a server device 950. The client(s) 1202 and the server(s) 1204 are operatively connected to one or more respective client data store(s) 1208 and server data store(s) 1210 that can be employed to store information local to the respective client(s) 1202 and server(s) 1204, such as cookies and/or associated contextual information.

The client(s) 1202 and the server(s) 1204 can communicate information between each other using a communication framework 1206. The communications framework 1206 may implement any well-known communications techniques and protocols. The communications framework 1206 may be implemented as a packet-switched network (e.g., a public network such as the internet, a private network such as an enterprise intranet, and so forth), a circuit-switched network (e.g., the public switched telephone network), or a combination of packet-switched and circuit-switched networks (using suitable gateways and translators).

The communications framework 1206 may implement various communications interfaces arranged to accept, communicate, and connect to a communications network. A network interface may be considered a specialized form of input-output interface. The network interface may employ connection protocols including, but not limited to: direct connections, Ethernet (e.g., thick, thin, twisted pair 10/100/1000Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE802.11 a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, and the like. Also, multiple network interfaces may be used in conjunction with various communication network types. For example, multiple network interfaces may be employed to allow communication over broadcast, multicast, and unicast networks. If the processing requirements dictate a greater amount of speed and capacity, a distributed network controller architecture can similarly be used to pool (pool), load balance, and otherwise increase the communication bandwidth required by the clients 1202 and the servers 1204. The communication network may be any one or combination of wired and/or wireless communication networks including, but not limited to: direct interconnects, secure custom connections, private networks (e.g., intranet), public networks (e.g., internet), Personal Area Networks (PAN), Local Area Networks (LAN), Metropolitan Area Networks (MAN), and nodes on the internet for operational tasks (OMNI), Wide Area Networks (WAN), wireless networks, cellular networks, and other communication networks.

Some embodiments may be described using the expression "one embodiment" and "an embodiment" along with their derivatives. The terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. Furthermore, some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and/or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

It is emphasized that the abstract of the disclosure is provided to 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. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "characterized by". Moreover, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Claims (13)

1. An apparatus for automatically managing file descriptors, comprising:

a processor circuit; and

a file descriptor application running on the processor circuit to manage file descriptors for content files, the file descriptor application being arranged to

A file descriptor request is received from a client application,

generating a file descriptor or file descriptor construct information for a content file using a file descriptor model, wherein the file descriptor provides a preview of the content file and the file descriptor construct information is used by the client application to generate the file descriptor,

synchronizing changes to content portions of the content file with corresponding content portions for the file descriptor, an

Sending a file descriptor response with the file descriptor or file descriptor construct information to the client application.

2. The apparatus of claim 1, wherein the file descriptor application includes a file descriptor extractor component to retrieve the file descriptor model for the file descriptor, extract one or more content portions from the content file based on the file descriptor model, and identify each of the extracted content portions with a content portion identifier, wherein each of the extracted content portions corresponds to a file descriptor tile of a file descriptor surface of the file descriptor.

3. The apparatus of claim 1, the file descriptor application comprising a file descriptor replacement component to replace the extracted content portion from the content file with a replacement content portion.

4. The apparatus of claim 1, the file descriptor application comprising a file descriptor assembly component to generate the file descriptor from one or more extracted content portions from the content file based on the file descriptor model.

5. The apparatus of claim 1, wherein the file descriptor application comprises a file descriptor assembly component to generate file descriptor construct information for use by the client application to generate file descriptors for the content files, the file descriptor construct information comprising the file descriptor model having a file descriptor surface arranged to present one or more extracted content portions from the content files and one or more file descriptor tiles.

6. The apparatus of claim 1, wherein the file descriptor application comprises a file descriptor assembly component to generate file descriptor construct information for use by the client application to generate a file descriptor for the content file, the file descriptor construct information comprising a file descriptor model identifier, at least one file descriptor tile identifier to identify a file descriptor tile of the file descriptor model, and at least one content portion identifier to identify a content portion of the content file corresponding to the file descriptor tile identified by the file descriptor tile identifier.

7. The apparatus of claim 1, wherein the file descriptor application includes a file descriptor synchronizer component to synchronize changes to content portions of the content file with corresponding extracted content portions of the content file of the file descriptor.

8. A computer-implemented method for automatically managing file descriptors, comprising:

receiving a file descriptor request from a client application to generate a file descriptor for a content file, wherein the file descriptor provides a preview of the content file;

generating, by a processor circuit, a file descriptor response to the file descriptor request;

synchronizing changes to content portions of the content file with corresponding extracted content portions of the content file of the file descriptor; and

sending the file descriptor response to the client application.

9. The computer-implemented method of claim 8, comprising:

retrieving a document descriptor model for the document descriptor;

extracting content portions from the content file based on the file descriptor model; and

generating a substitute content portion for the extracted content portion of the content file.

10. The computer-implemented method of claim 8, comprising generating file descriptor construct information for use by the client to generate a file descriptor for the content file, the file descriptor construct information comprising a file descriptor model and one or more extracted content portions from the content file.

11. The computer-implemented method of claim 8, comprising generating file descriptor construct information for use by the client to generate a file descriptor for the content file, the file descriptor construct information comprising a file descriptor model identifier for a file descriptor model, one or more file descriptor tile identifiers for file descriptor tiles of the file descriptor model, and one or more content portion identifiers from the content file corresponding to the extracted content portion of the file descriptor tile.

12. The computer-implemented method of claim 8, comprising:

generating the file descriptor from one or more extracted content portions from the content file based on a file descriptor model; and

sending a file descriptor response having file descriptor construct information or the file descriptor to the client.

13. A computer-implemented system for automatically managing file descriptors, comprising:

means for receiving a file descriptor request from a client application to generate a file descriptor for a content file, wherein the file descriptor provides a preview of the content file;

means for generating, by a processor circuit, a file descriptor response to the file descriptor request;

means for synchronizing changes to content portions of the content file with corresponding extracted content portions of the content file of the file descriptor; and

means for sending the file descriptor response to the client application.