RU2348069C2 - Mechanism of modification application to files consisting of multiple parts - Google Patents

Abstract

FIELD: physics, computer technology.

SUBSTANCE: invention concerns system and method of modification application to files consisting of multiple parts. Method of implementing modification involves receiving request for access to a stream in file consisting of multiple parts, identification of modification list related to the stream upon receiving request, the list also included to file consisting of multiple parts, and implementation of listed modifications before implementing the request. If recoding is requested data are encoded, and if reading is requested data are decoded. Modification list depends on the order of required modifications and includes data structure with first stream including display for stream comparison to the name of modification list, second stream listing each stream modification, third stream for identification of information related to each listed modification.

EFFECT: possible automatic extraction of auxiliary objects, solution of problems arising therewith by a single addressing main object.

27 cl, 5 dwg

Description

This application is filed as a PCT application, filed May 17, 2003 by Microsoft, created and located in the United States, listing all countries except the United States.

BACKGROUND OF THE INVENTION

Modern computer systems typically store a large amount of data in multiple files. The file format can be one of several different formats compatible with various applications, for example, text editors, spreadsheets, etc. It is often necessary to transfer a file to another computer so that another user can see or manipulate the data in the file. Sometimes, when the file is too large, the file is converted (for example, compression) before the file is sent to another computer. Thanks to file compression, less bandwidth is required to send the file to another computer. In other cases, to protect data from access by unauthorized users, you can perform another conversion (for example, encryption).

Some of these transformations have special encoding methods and use a separate file (for example, a dictionary) to store information about a particular encoding method. This separate file should be used when accessing the converted file. In case of damage, loss or inaccessibility of this separate file, the converted file is useless. In addition, since some of these transformations define their own encoding methods for interleaving the encoded data and the processing information, the converted file is not to be shared or shared processed. In addition, prior to file conversion, modern conversions require that the data in the file be organized in sequential bytes. Ensuring that bytes in a file remain consistent requires a lot of overhead and is not viable for frequently edited files. Thus, although these transformations are very useful, the way they are implemented does not give users much freedom of action.

SUMMARY OF THE INVENTION

The present invention relates to a system and method for implementing transformations that provide users with increased flexibility. In general, the present invention provides a mechanism for storing transformation information associated with one or more transformations in a file consisting of multiple parts. A file consisting of multiple parts also contains data to which one or more transformations are applied. Thus, the present invention provides a file format for a file consisting of multiple parts, which allows applications accessing the file to easily access the converted data. According to the invention, multiple data transformations can form a chain. These data transformations that make up the circuit are called “data spaces.” Each data space has a unique order and type for the transformations that make up the chain. For example, two data spaces can specify the same transformations, but the order in which transformations are applied is different. Transformation information contains information about data spaces.

According to another aspect of the invention, a multi-part file contains multiple streams. Each stream can be associated with one of the data spaces. Thus, according to the present invention, some streams in a file consisting of multiple parts can be converted, while other streams can remain in their natural format. This ability to convert specific streams without having to convert the entire file consisting of multiple parts provides users with greater flexibility, for example, allows users to encrypt only relevant information in a file consisting of multiple parts (for example, when editing documents).

Thus, the present invention relates to a system and method for applying transformations to files consisting of multiple parts. A request is received to access the data stream in a file consisting of multiple parts. Upon receipt of the request, a list of transformations associated with the stream is identified. The list is also included in the file, consisting of multiple parts. The transformations specified in the list of transformations are performed on the data until the request is completed. If this is a write request, then the transforms encode the data. If it is a read request, then the transforms decode the data. The list of transformations depends on the order. The transformation list contains a data structure having a first stream, which includes a mapping (correspondence) matching the stream with the name of the transformation list. The second thread listing all the conversions for the thread. The third stream for each of these transformations that identifies the information associated with the transform.

Brief Description of the Drawings

Figure 1 is a functional block diagram of a computing device that can be used in implementations of the present invention.

Figure 2 is a functional block diagram illustrating in general terms a conversion process according to the present invention.

FIG. 3 is a graphical representation of a tree hierarchy that represents the transformation metadata shown in FIG.

4 is a diagram of a conversion process.

5 is a flowchart illustrating a general process for accessing converted data in a file consisting of multiple parts, according to one embodiment of the invention.

Detailed Description of a Preferred Embodiment

The invention provides a mechanism for applying transformations to files consisting of multiple parts. The mechanism provides a structure for specifying transformation information. Transformation information and transformed data coexist in the same document. The mechanism contemplated by the invention is preferably based on a multi-part file format that allows for multiple types of streams in a single document. The inventors have determined that the compound file format according to the standard for object linking and embedding (OLE) is particularly suitable for implementing the invention. Thus, the invention is described below using a compound file format. However, it will be clear to those skilled in the art who have carefully studied the following description that other multi-file formats can implement the present invention with various modifications of the mechanism described below, adapted to other multi-file formats. Thus, it is obvious that embodiments of the invention are not limited to those described herein.

We first describe the invention with reference to one example illustrative computing environment in which embodiments of the invention may be implemented. Next, we describe a detailed example of one specific embodiment of the invention. Alternative embodiments may also be included with respect to certain details of a particular implementation.

Illustrative Computing Environment According to the Invention

Figure 1 shows a functional block diagram of a computing device that can be used in implementations of the present invention. Figure 1 shows an illustrative computing device that can be used in implementations of the present invention. 1, in a very general configuration, computing device 100 typically includes at least one processor 102 and system memory 104. Depending on the specific configuration and type of computing device 100, system memory 104 may be a volatile memory device (e.g., RAM ), non-volatile storage device (for example, ROM, flash memory, etc.) or any combination thereof. System memory 104 typically houses the operating system 105, one or more program modules 106, and optionally program data 107. Examples of program modules 106 may include a browser application (viewer), financial management application, text editor, etc. d. This basic configuration is represented in FIG. 1 by components surrounded by a dashed line 108.

Computing device 100 may have additional features or functions. For example, computing device 100 may also include additional storage devices with removable and / or stationary media, which can be magnetic disks, optical disks, or tape. Such additional storage devices are shown in FIG. 1 in the form of a storage device 109 with removable medium and a storage device 110 with a stationary medium. Computer storage media can include volatile and non-volatile, removable and stationary storage media that implement any method and any technology for storing information, such as computer-readable instructions, data structures, program modules or other data. System memory 104, storage device 109 with removable media and storage device 110 with stationary media are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROMs, digital versatile disks (DVDs) or other optical storage devices, magnetic tapes, magnetic tape, storage devices based on magnetic disks or other magnetic media, or any other medium that can be used to store useful information and which can be accessed by computing device 100. Any such computer storage medium for data may be included in the device 100.

Computing device 100 may also comprise an input device (a) 112, for example, a keyboard, mouse, pen, voice input device, tactile input device, etc. It may also comprise an output device (a) 114, for example a display, speakers, printer, etc. These devices are well known in the art and do not need additional description.

Computing device 100 may also include communication means 116, allowing device 100 to communicate with other computing devices 118, for example, over a network. Communications 116 are an example of communications media. Communication media typically implement computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and include any data delivery media. The term "modulated data signal" means a signal, one or more of whose characteristics changes in a certain way, which allows you to encode information in the signal. By way of example, but not limitation, communication media include wired media, such as a wired network or a direct wired connection, wireless media, such as acoustic, RF, infrared, and other wireless media. The term “computer-readable media” as used herein refers to both storage media and data transmission media.

Component Overview

Figure 2 shows a functional block diagram illustrating in General terms the components of the environment that implements the present invention. Illustrated file 202, consisting of multiple parts, preferably a composite file OLE. The OLE document model is well known in the art and is widely used as a mechanism for containing many disparate data types in a single document. Traditionally, an OLE compound file is shared with multiple embedded files or other support content associated with a single document. Each element of a compound file is stored so that the application that created the element can manipulate it. Each element is stored as a stream, for example, streams 204, 206 and 208 shown in FIG. According to the above, each thread can be one of several types. For example, stream 204 stream1 may be a text editor document, stream 206 stream2 may be a spreadsheet, and stream 208 streamZ may be a graphic file.

Until now, after requesting a conversion on a multiple-part file 202, it was required that all the components of the multiple-part file 202 (i.e., streams 204-208) be continuous and be processed together. However, according to the present invention, streams 204-208 do not have to be continuous. In contrast, flows 204-208 may be sector based. In the following discussion, sectorized files will be understood as files in which multiple pieces (chunks) of data are stored representing the whole stream. Multiple servings can be stored sequentially, but are usually not stored sequentially. In one embodiment, the portions may have a fixed size, for example 512 bytes. Alternatively, without departing from the scope of the present invention, it is possible to provide portions of variable size. When editing a stream, a new chunk of data can be created and stored in bytes that are not consecutive with respect to other chunks of data for the stream. Thus, sectorized files make it easy to edit the stream without the additional cost of ensuring that the stream remains uninterrupted.

As described in detail below, the present invention allows you to convert specific chunks of data 240 associated with a stream (eg, stream 206) in a multiple-part file 202 without converting other streams. Since the present invention allows these streams to be converted independently of other streams, the invention provides greater flexibility for data protection and data management. For example, FIG. 2 shows a stream 206 stream2 subjected to a conversion process. Stream 206 stream2 may be a spreadsheet containing the prices of specific products. Therefore, it may be desirable to protect this price information so that unauthorized users cannot see prices. Thus, data 240 directed to stream 206 stream2 is subject to a chain of transformations (i.e., transforms 220-224). One skilled in the art will appreciate that any number of transformations can make up a chain, and they can be placed in a chain in any order. The particular transformations forming the chain, and the order in which the transformations are placed in the chain, represent the data space 230. In general, a data space can specify a single transformation, or it can specify multiple transformations. In the above example, the last conversion (e.g., transformation 224) writes the converted data to stream 206 stream2, which can be placed on a disk (not shown). One embodiment for using the mechanism for applying transformations to files consisting of multiple parts is described in detail below with reference to FIG.

Consideration of a specific embodiment of the invention

FIG. 3 is a graphical representation of one embodiment of a tree hierarchy that represents the transformation metadata 210 shown in FIG. 2. In general, a tree hierarchy can be entered into a file consisting of multiple parts in any way compatible with a file consisting of multiple parts. The tree hierarchy for compound files is described below. In general, compound files are considered as a “file system inside a file”. The composite file has a hierarchy of “storages” similar to directories in the file system, and “streams” similar to files in the file system. 3, rectangles represent flows, and ovals represent vaults. Before proceeding to the description of the conversion metadata 210 corresponding to the present invention, note that streams 204-208 (shown in FIG. 2) are illustrated in this illustrative hierarchy under root 302. Defining streams under the root is a common technique for compound file formats.

Now consider in more detail the metadata 210 conversion provided by the present invention. Transformation metadata 210 is stored in a special storage called "\ 006DataSpaces" 310 from root 302. Storage 310 \ 006DataSpaces contains stream 320 DataSpaceMap, storage 330 DataSpaceInfo and storage 340 TransformInfo. For this embodiment, the name selected for the particular repository, "\ 006DataSpaces", is written in the context of the programming language C. Thus, in this embodiment, the name begins with a single non-alphanumeric marker and a marker value of 6. In general, the name assigned to a particular repository is arbitrary and depends on the user's implementation.

Stream 320 DataSpaceMap [mapping data spaces] displays (converts) streams (eg, streams 204-208) with the associated data space. In one embodiment, a DataSpaceMap stream 320 is a table having two columns: a stream reference column 322 and a DataSpaceName column 324 [data space names]. The contents of the stream reference column 322 refers to one of the streams (e.g., streams 204-208) stored in the master document. The content in the DataSpaceName refers to a specific data space that is defined for the corresponding stream indicated in the stream link column 322. One data space can be associated with any number of threads. For example, according to FIG. 3, the data space designated “DataSpaceName1” is associated with stream 204 stream1 and stream 206 stream2. Although the DataSpaceMap stream 320 is presented in tabular form in the above description, it will be apparent to those skilled in the art that other formats can be used to identify and map the stream to the data space.

Storage 330 DataSpaceInfo [data space information] contains one or more DataSpaceName streams (for example, streams 332 and 334 DataSpaceName). For the described embodiment, the DataSpaceName stream is named according to standard conventions for short compound file names. Each DataSpaceName stream 332 and 334 identifies a list of 336 transformations associated with a corresponding DataSpaceName stream 332 and 334. In one embodiment, each of DataSpaceName streams 332 and 334 may be a list of transformations forming a data space. Because the conversion stack, the order in list 336, is important. In one embodiment, the first transform 337 in list 336 is referred to as a “lower” transform, which means that transform 337 is located closest to the bits in the underlying data stream (eg, stream 204). The last transform 339 in list 336 is referred to as the “top” transform, which means that transform 339 is closest to the consumer / creator of the data (for example, the application). As described in detail below with reference to FIG. 4, the order specified in list 336 determines the passage of data through transformations.

Repository TransformInfo 340 [Transformation information] contains one or more TransformInstance repositories [Transformation instance] (for example, TransformInstance repository 342, 344 and 346). In one embodiment, the names of these stores are transform names. Each of the TransformInstance repositories 342, 344, and 346 has at least one thread named "\ 006Primary" 350 . Stream 350 \ 006Primary contains essential information about a particular transformation, for example TransformClassType 354 [type of transformation class] and TransformClassName 356 [name of transformation class]. The TransformClassType type 354 denotes a particular transformation class that implements a particular transformation (eg, LZ compression, digital rights management (DRM) protection, etc.). In one embodiment, TransformClassName 356 is specified as a string that uniquely identifies the class (i.e. type) of the transform. The string identifying the class may be the class name for the class that implements the conversion. The TransformClassType type 354 specifies a type identifier that indicates how to interpret the string specified in the TransformClassName name 356. Stream 350 \ 006Primary may also contain data space for TransformInstanceData 358 [transform instance data]. The TransformInstanceData data 358 stores information specified for the transformation specified by the TransformClassName name 356 and the TransformClassType type 354. For example, if the transform is a compression transform, then TransformInstanceData data 358 may contain window size or the like.

For some conversions, TransformInstanceData data 358 may not provide enough space to store the necessary information. Thus, according to a further refinement, the present invention allows the transform to store additional information in a TransformInstanceData stream (e.g., TransformInstanceData stream 370). This is valid as long as there are no name conflicts with stream 350 \ 006Primary. The nature of the transform instance data varies with the type of transform.

Although the above tree hierarchy describes one embodiment of a document format for storing converted data together with their conversion information, it will be apparent to those skilled in the art that the hierarchy may change without affecting the operation of the present invention. Therefore, any tree hierarchy in which conversion information is stored in conjunction with the converted data does not go beyond the scope of the present invention. Figure 4 shows a diagram of a conversion process that uses a formatting mechanism for documents having converted data in accordance with the present invention. In this illustrative conversion process, an application 400 attempts to read and write a multi-part file 202 described in FIG. 2. In general, each instance of the transformation class takes the IStream interface as input and outputs encoded (i.e., transformed) data to another IStream interface. Mappings (eg, mappings 420 and 422) are registered, and the data space is associated with a stream 206 that is already defined, for example, through application programming interfaces provided by OLE composite documents. For example, first, when creating stream 206, the application that created stream 206 in a multiple-part document 202 is responsible for indicating which transformations to apply to the data. To do this, you can use the argument list, where each argument refers to (refers to) the transformation.

Read and write access is through the OS level. To date, the write operation has provided access to stream 206 stream2 through the IStream interface 414. However, according to the present invention, one or more transforms can be inserted in front of the IStream interface 414. Each transform (for example, transform 420 and 422) takes the IStream interface as input (IStream interface 410 and 412, respectively) and outputs its encoded (i.e., converted) data to another IStream interface (IStream interface 412 and 414, respectively) .

Similarly, when an application 400 tries to read stream 206 stream2 in a multiple-part file 202, one or more inverse transforms (for example, inverse transforms 450 and 452) can be inserted. The number of inverse transforms is equal to the number of transformations so that the data is decoded correctly and thus the application can understand the data. Now, with reference to FIG. 5, we describe how the transforms are inserted between the application 400 and the thread 206.

5 is a logical flowchart illustrating the overall process of accessing converted data in a composite file according to the invention. Process 500 begins with an initial step 501 where an application requests access to data in a file stream consisting of multiple parts. Conversion information 210 for the stream is already set.

At the decision-making stage, a determination is made whether the stream is a member of the data space. Referring to FIG. 3, for one embodiment, this determination is made by searching the mapping of the data spaces for a stream reference 322 that identifies the requested stream. If the link 322 to the stream associated with the stream is not found, then no transforms are specified for the stream, and processing ends. In this case, the application accesses the data in the same way as before the present invention. If the data space mapping contains a link 322 to the stream, processing proceeds to step 504.

Step 504 denotes obtaining a data space name associated with a link 322 to the stream.

At step 506, a search is performed in the DataSpaceInfo store (data space information) using the data space name (DataSpaceName) obtained in step 504 to identify the DataSpaceName stream associated with the data space name specified in the data space map (DataSpaceMap). The DataSpaceName stream contains a list of transformations associated with this data space name.

At step 508, a transformation is identified from the list. Depending on whether read or write access is made, the conversion may encode data or decode data, respectively. The DataSpaceName stream lists all the transformations in a specific order. If access is for recording, then the order will be from top to bottom. If access is for reading, then the order will be from bottom to top.

Step 510 denotes the application of the identified transformation. When applying a transform, the transform instance data is used to correctly transform the data. If access is made for recording, then a (coding) conversion is applied. If access is made for reading, then the inverse (decoding) conversion is applied.

At decision block 512, a determination is made whether the data space contains any additional transformations included in the chain. To do this, you can see if list 336 refers to any other conversion instances. If the last transformation in the data space was applied, then the last transformation outputs the data, and the process ends. If there is another transformation in the list, then the processing returns to step 508 and continues, as described above, until the last transformation is applied.

In addition, it will be apparent to those skilled in the art that the functions provided by process 300 can be implemented in various ways. For example, there may be a mapping of the stream name directly to the list of transformations (with the omission of using the data space). Thus, the present invention includes this and other embodiments for mapping a stream to its conversion information. Process 500 illustrates one such embodiment.

The foregoing description of the invention, examples and data provide a complete description of the production and use of the composition of the invention. Since multiple embodiments of the invention are possible within the spirit and scope of the invention, the invention is defined by the claims below.

Claims (27)

1. A computer-implemented method for performing transformations on data, comprising the steps of receiving a request for access to a stream in a file consisting of multiple parts, the file consisting of multiple parts including streams and data spaces, each data space defining a list of transformations to be applied in a given order to the data inside the stream, identify the data space that is associated with the stream, and this data space is identified from the file, consisting of multiple parts, and perform transformations on the data in the order specified in the list of transformations before completing the processing of the request. 2. A computer-implemented method according to claim 1, characterized in that the file consisting of multiple parts includes a composite OLE file. 3. The computer-implemented method according to claim 1, characterized in that when identifying the data space, a search is made for displaying the data space for the stream, the display of data spaces providing a correlation between the stream and the name of the data space associated with the data space. 4. A computer-implemented method according to claim 1, characterized in that said list includes the type and name of each transformation indicated in the list. 5. A computer-implemented method according to claim 1, characterized in that the list further includes transform instance data for one of the transforms indicated in the list, wherein the transform instance data provides essential information for decoding data transformed by this single transform. 6. A computer-implemented method according to claim 1, characterized in that the request is a request to write a piece of data, and at least one conversion is performed on said piece of data to create encoded data that is recorded in a data storage medium. 7. A computer-implemented method according to claim 6, characterized in that the data portion is not adjacent to other data portions previously recorded in the data storage medium for this stream. 8. A computer-implemented method according to claim 6, characterized in that the portion of data is a portion of a fixed size in relation to other pieces of data for the stream. 9. A computer-implemented method according to claim 1, characterized in that the list includes a compression transform and an encryption transform. 10. A computer-implemented method according to claim 1, characterized in that the request is a request to read a piece of data, and at least one transform performs an inverse transform on a piece of data extracted from the stream to provide decoded data to the requestor. 11. A computer system having a mechanism for applying transformations to files consisting of multiple parts, comprising a processor, a memory allocated for a plurality of computer-executable instructions loaded into memory for execution by a processor, the computer-executing instructions performing a method comprising the steps of
receive a request for access to a stream in a file consisting of multiple parts, the file consisting of multiple parts includes streams and data spaces, with each data space defining a list of transformations to be applied in a given order to the data inside the stream,
identifying said list of transformations associated with the stream, the list being identified from a file consisting of multiple parts, and
perform transformations in the order specified in the list of transformations on the data before completing the processing of the request. 12. The computer system according to claim 11, characterized in that the file, consisting of multiple parts, includes a composite OLE file. 13. The computer system according to claim 11, characterized in that when identifying a list of transformations, a search is made for displaying a data space for a stream, said data space mapping providing a correlation between the stream and the data space name associated with said data space. 14. The computer system according to claim 11, characterized in that the list of transformations includes the type and name of each transformation indicated in the list. 15. The computer system according to claim 11, characterized in that the list further includes transform instance data for one of the transforms indicated in the list, and the transform instance data provides essential information for decoding data converted by this one transform. 16. The computer system according to claim 11, characterized in that the request is a request to write pieces of data, and at least one conversion is performed on the piece of data to create encoded data that is written to the data storage medium. 17. The computer system according to clause 16, wherein the piece of data is not adjacent to other pieces of data previously recorded in the data storage medium for the stream. 18. The computer system according to clause 16, wherein the piece of data is a piece of a fixed size in relation to other pieces of data for the stream. 19. The computer system according to claim 11, characterized in that the list includes a compression transform and an encryption transform. 20. The computer system according to claim 11, characterized in that the request is a request to read a piece of data, and at least one transform performs the inverse transform on a piece of data extracted from the stream to provide decoded data to the requestor. 21. A computer-readable medium, the data structure of which contains encoded data, comprising a first stream including a display that correlates a stream in a file consisting of multiple parts with a name for a list of transformations to be applied in a given order to said stream,
a second stream that lists each of the transforms for said stream, and a third stream for each of the transforms, the third stream identifying information associated with the transform. 22. Machine-readable medium according to item 21, wherein the data structure is included in a file consisting of multiple parts. 23. Machine-readable medium according to item 21, wherein the name for the list of transformations can be correlated with many streams in a file consisting of multiple parts. 24. Machine-readable medium according to item 21, wherein the list of transformations depends on the order. 25. The computer-readable medium of claim 21, wherein the information identifies the class name and class type for conversion. 26. The computer-readable medium of claim 25, wherein the information further identifies instance data associated with the conversion. 27. The computer-readable medium of claim 26, wherein the transform includes a compression transform, and instance data includes a window size for compressing the transform.

Images