EP1625510A1 - Mecanisme d'application de transformees a des dossiers en plusieurs parties - Google Patents

Mecanisme d'application de transformees a des dossiers en plusieurs parties

Info

Publication number
EP1625510A1
EP1625510A1 EP03731243A EP03731243A EP1625510A1 EP 1625510 A1 EP1625510 A1 EP 1625510A1 EP 03731243 A EP03731243 A EP 03731243A EP 03731243 A EP03731243 A EP 03731243A EP 1625510 A1 EP1625510 A1 EP 1625510A1
Authority
EP
European Patent Office
Prior art keywords
data
transform
stream
transforms
list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP03731243A
Other languages
German (de)
English (en)
Other versions
EP1625510A4 (fr
Inventor
Michael J. Hillberg
Roger Cheng
David B. Ornstein
Jason M. Cahill
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of EP1625510A1 publication Critical patent/EP1625510A1/fr
Publication of EP1625510A4 publication Critical patent/EP1625510A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/543—User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/542—Intercept

Definitions

  • Computer systems today typically store a large amount of data in several files.
  • the format for the files may be one of several different formats that are compatible with various applications, such as word processors, spreadsheets, and the like.
  • a transformation e.g., compression
  • By compressing the file less bandwidth is needed to send the data to the other computer.
  • another transformation e.g., encryption
  • Some of these transformations have specific encoding methods and use a separate file (e.g., dictionary) to store information about the specific encoding method.
  • the separate file must be used when accessing the transformed file. If the separate file becomes corrupted, lost, or otherwise unavailable, the transformed file becomes useless.
  • some of these transformations define their own specific encoding methods for interleaving encoded data and processing information, once the file is transformed, the file can not be shared or have common processing performed on it.
  • current transformations require that the data within the file to be arranged in contiguous bytes. Ensuring that the bytes for the file remain contiguous consumes a lot of overhead and is not viable for files that are edited quite often. Thus, while these transformations are very useful, the way in which they are implemented do not offer a versatile experience to users.
  • the present invention is directed at a system and method for implementing transformations that provide greater flexibility to users.
  • the present invention provides a mechanism for storing transformation information associated with one or more transformations within a multi-part file.
  • the multi-part file also contains the data upon which the one or more transformations are applied.
  • the present invention provides a file format for the multi-part file so that applications accessing the data may easily access the transformed data.
  • multiple data transforms may be chained together. These chained data transforms are referred to as a "data spaces".
  • Each data space has a unique order and type for the transforms that are chained together. For example, two data spaces may specify the same transforms, but specify a different order for applying the transforms.
  • the transformation information contains information about the data spaces.
  • the multi-part file contains a plurality of streams. Each stream may be associated with one of the data spaces. Thus, in accordance with the present invention some streams within the multi-part file may be transformed while other streams may remain in their native format. This ability to transform specific streams without requiring transformation of the entire multi-part file offers great flexibility to users, such as allowing the user to encrypt only the sensitive information within the multi-part file (e.g., redacting documents).
  • the present invention is directed at a system and method for applying transforms to multi-part files. A request is received to access a stream within a multi-part file. Upon receipt of the request, a list of transforms associated with the stream is identified. The list is also included within the multi-part file.
  • the transforms specified in the list of transforms are performed on data before completing the request. If the request is a write, the transforms encode the data. If the request is a read, the transforms decode the data.
  • the list of transforms is order dependent.
  • the list of transforms includes a data structure having a first stream that includes a map that correlates the stream with a name for the list of transforms. A second stream that lists each of the transforms for the stream. A third stream for each of the transforms listed that identifies information associated with the transform.
  • FIGURE 1 is a functional block diagram that illustrates a computing device that may be used in implementations of the present invention.
  • FIGURE 2 is a functional flow diagram generally illustrating an overview of a transformation process in accordance with the present invention.
  • FIGURE 3 is a graphical representation of an exemplary tree hierarchy that represents the transform metadata shown in FIGURE 2.
  • FIGURE 4 is a graphical depiction of the transformation process.
  • FIGURE 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a multi-part file, in accordance with one embodiment of the invention.
  • the invention provides a mechanism for applying transforms to multi-part files.
  • the mechanism provides a structure for specifying transformation information.
  • the transformation information and the transformed data co-exist within the same document.
  • the mechanism of the invention is preferably based on a multi-part file format that allows multiple types of streams within one document.
  • OLE Object Linking and Embedding
  • FIGURE 1 is a functional block diagram that illustrates a computing device that may be used in implementations of the present invention.
  • FIGURE 1 illustrates an exemplary computing device that may be used in illustrative implementations of the present invention.
  • computing device 100 typically includes at least one processing unit 102 and system memory 104.
  • system memory 104 may be volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.) or some combination of the two.
  • System memory 104 typically includes an operating system 105, one or more program modules 106, and may include program data 107. Examples of program modules 106 include a browser application, a finance management application, a word processor, and the like.
  • This basic configuration is illustrated in FIGURE 1 by those components within dashed line 108 Computing device 100 may have additional features or functionality.
  • computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape.
  • additional storage is illustrated in FIGURE 1 by removable storage 109 and non-removable storage 110.
  • Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • System memory 104, removable storage 109 and non-removable storage 110 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-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 100. Any such computer storage media may be part of device 100.
  • Computing device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc.
  • Output device(s) 114 such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.
  • Computing device 100 may also contain communication connections 116 that allow the device 100 to communicate with other computing devices 118, such as over a network.
  • Communication connections 116 are one example of communication media.
  • Communication media may typically be embodied by 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 includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct- wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
  • FIGURE 2 is a functional flow diagram generally illustrating an overview of components of an environment implementing the present invention. Illustrated is a multi-part file 202, preferably an OLE compound file.
  • the OLE document model is known in the art and is widely recognized as a mechanism for containing many disparate types of data within a single document.
  • the OLE compound file is used in conjunction with having several embedded files or other support content associated with a single document.
  • Each element in the compound file is stored in a manner such that it can be manipulated by the application that created the element.
  • Each element is stored as a stream, such as streams 204, 206, and 208 shown in FIGURE 2.
  • each stream may be one of several types. For instance, stream 1 204 may be a word processing document, stream2 206 may be a spreadsheet, and streamZ 208 may be a graphics file.
  • the streams 204-208 need not be contiguous. Rather, the streams 204-208 may be sector-based.
  • sector-based files refer to files having multiple chunks of data that are stored and that represent the entire stream. The multiple chunks may be stored contiguously, but typically are stored non-contiguously. In one embodiment, the chunks may be fixed size, such a fixed at 512 bytes. Alternatively, the chunks may be variably sized without departing from the scope of the present invention.
  • the present invention allows specified chunks of data 240 associated with a stream (e.g., stream 206) within the multi-part file 202 to be transformed without transforming other streams. Because the present invention allows specified streams to be transformed independent of other streams, the invention provides a great flexibility for securing and controlling data.
  • FIGURE 2 illustrates stream2 206 undergoing a transformation process.
  • Stream2 206 may represents a spreadsheet containing the costs associated with a particular item. Therefore, it may be desirable to secure this cost information so that unauthorized users can not view the costs.
  • the data 240 destined for stream2 206 undergoes a chain of transforms (i.e., transforms 220-224).
  • any number of transforms may be chained and may be chained in any order.
  • the specific transforms that are chained and the order in which the transforms are chained represent a data space 230.
  • a data space may specify one transform or may specify multiple transforms.
  • the last transform e.g., transform 224
  • FIGURE 3 is a graphical representation of one embodiment of a tree hierarchy that represents the transform metadata 210 shown in FIGURE 2.
  • the tree hierarchy may be included within the multi-part file in any manner compatible with the multi-part file.
  • compound files are commonly considered as a "file system within a file.”
  • Within the compound file is a hierarchy of "storages,” which are analogous to directories in a file system, and "streams,” which are analogous to files in a file system.
  • rectangular boxes represent the streams and ovals represent the storage.
  • the streams 204- 208 shown in FIGURE 2 are illustrated under the root 302 in this example hierarchy. Defining streams under the root is a common technique for compound file formats.
  • a special storage named " ⁇ 006DataSpaces" 310 off the root 302 stores the transform metadata 210.
  • the ⁇ 006DataSpace storage 310 contains a DataSpaceMap stream 320, a DataSpacelnfo storage 330, and a Transformlnfo storage 340.
  • the name chosen for the special storage " ⁇ 006DataSpaces" is written in context of the C Programming language.
  • the name begins with a single non-alphanumeric token and a token value of 6.
  • the name assigned to the special storage is arbitrary and depends on the user's implementation.
  • the DataSpaceMap stream 320 maps the streams (e.g., streams 204- 208) with their associated data space.
  • the DataSpaceMap stream 320 is a table having two columns: a stream reference column 322 and a DataSpaceName column 324.
  • the contents within the stream reference column 322 refer to one of the streams (e.g., streams 204-208) stored within the compound document.
  • the contents within the DataSpaceName refer to a specific data space that has been defined for the associated stream identified within the stream reference column 322.
  • One data space may be associated with any number of streams. For example, as shown in FIGURE 3, the data space identified as "DataSpaceName 1 " is associated with Stream 1 204 and Stream2 206.
  • the DataSpacelnfo storage 330 contains one or more
  • DataSpaceName streams (e.g., DataSpaceName stream 332 and 334).
  • the DataSpaceName stream is named in accordance with standard, compound-file short name conventions.
  • Each DataSpaceName stream 332 and 334 identifies a list 336 of transforms associated with the respective DataSpaceName stream 332 and 334.
  • each of the DataSpaceName streams 332 and 334 may be an ordered list of the transforms that make up the data space. Because transforms stack, the order within the list 336 is important.
  • the first transform 337 within the list 336 is referred to as the "bottom" transform, which means the transform 337 is closest to the bits in the underlying data stream (e.g., stream 204).
  • the last transform 339 within the list 336 is referred to as the "top" transform, which means the transform 339 is the closest to the consumer/producer of the data (e.g., an application).
  • the order specified in the list 336 determines the flow of data through the transforms.
  • the Transformlnfo storage 340 contains one or more Transformlnstance storages (e.g., Transformlnstance storage 342, 344, and 346). In one embodiment, the names of these substorages are the names of the transforms.
  • the ⁇ 006Primary stream 350 contains pertinent information about the specific transform, such as TransformClass Type 354 and TransformClass Name 356.
  • the TransformClass Type 354 denotes a particular transform class that implements a particular transform (e.g., LZ compression, Digital Rights Management (DRM) protection, and the like).
  • the TransformClass Name 356 is specified as a string that uniquely identifies the class (i.e., type) of the transform.
  • the string that identifies the class may be a class name for the class that implements the transform.
  • the TransformClass Type 354 specifies a type indicator that tells how to interpret the string specified in the TransformClass Name 356.
  • the ⁇ 006Primary stream 350 may also contain space for Transformlnstance Data 358.
  • the TransformlnstanceData 358 stores information specified to the transform specified by the TransformClass Name 356 and TransformClass Type 354. For example, if the transform is a compression transform, the TransformlnstanceData 358 may contain a window size and the like.
  • the TransformlnstanceData 358 may not allow sufficient space to store the necessary information.
  • the present invention allows transforms to store additional information in a TransformlnstanceData stream (e.g., TransformlnstanceData stream 370). This is allowed as long as there are no name collisions with the ⁇ 006Primary stream 350.
  • the nature of the TransformlnstanceData will vary depending on the type of transform. While the above tree hierarchy describes one embodiment of a document format for storing transformed data with its transformation information, those skilled in the art will appreciate that the hierarchy may be changed without impacting the operation of the present invention. Therefore, any tree hierarchy in which transformation information is stored along with the transformed data does not depart from the present invention.
  • FIGURE 4 is a graphical depiction of the transformation process in which the mechanism for formatting documents having transformed data in accordance with the present invention is used.
  • an application 400 attempts to read and write to the multipart file 202 described in FIGURE 2.
  • each instance of a transform class takes an IStream interface as input, and outputs the encoded (i.e., transformed) data to another IStream interface.
  • the transforms e.g., transforms 420 and 422
  • the transforms have been registered and the data space associated with stream 206 as already been specified, such as via application programming interfaces provided by OLE compound documents.
  • the application that created the stream 206 within multi-part document 202 was responsible for specifying which transforms to apply to the data. This may have occurred via an argument list, where each argument referred to a transform.
  • the read and write access is via an OS layer.
  • a write operation would have accessed stream2 206 via IStream interface 414.
  • one or more transforms may be inserted before the IStream interface 414.
  • Each transform e.g., transform 420 and 422 takes an IStream interface as input (IStream interface 410 and 412, respectively), and output their encoded (i.e., transformed) data to another IStream interface (IStream interface 412 and 414, respectively).
  • one or more inverse transforms e.g., inverse transforms 450 and 452
  • the number of inverse transforms is identical to the number of transforms in order for the data to be properly decoded so that the application can understand the data.
  • FIGURE 5 The manner in which the transforms are inserted between the application 400 and the stream 206 is now described in conjunction with FIGURE 5.
  • FIGURE 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a compound file, in accordance with the invention.
  • the process 500 begins at a starting block 501 where an application has requested an access to data within in stream of a multi-part file.
  • the transform information 210 has already been specified for the stream.
  • the DataSpaceName associated with the stream reference 322 is obtained.
  • the DataSpaceName may be a string or any other format.
  • the DataSpacelnfo storage is searched to identify the DataSpaceName stream associated with the DataSpaceName identified within the DataSpaceMap.
  • the DataSpaceName stream contains a list of transforms associated with this data space name.
  • a transform from within the list is identified. Depending on whether the access is a write or a read, the transform may encode the data or may decode the data, respectively.
  • the DataSpaceName stream lists each transform in a specific order. If the access is a write, the order is from top to bottom. If the access is a read, the order is from bottom to top.
  • the identified transform is applied.
  • the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.
  • process 300 may be implemented in various ways. For example, there may be a mapping directly from the stream name to a transform list (skipping the use of a data space). Thus, the present invention includes this and other embodiments for mapping the stream to its transform information.
  • Process 500 illustrates one such embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

L'invention porte sur un système et un procédé d'application de transformées à des dossiers à plusieurs parties (202). A cet effet une demande d'accès à un flux intérieur de dossier en plusieurs parties est reçue. Lors de la réception, une liste de transformées associées au flux est identifiée (210). La liste est également comprise dans le dossier en plusieurs parties (202). Les transformées spécifiées dans la liste des transformées sont exécutées sur les données avant l'achèvement de la demande. Si la demande est écrite, la transformée code les données (414). Si la demande est lue, la transformée décode les données (430) et la liste des transformées dépend d'un ordre. La liste des transformées comporte une structure de données comprenant: un premier flux contenant une corrélation faisant correspondre le flux avec un nom de la liste des transformées; un deuxième flux établissant une liste des différentes transformées du flux; et un troisième flux pour celles des transformées de la liste identifiant des informations associées à la transformée.
EP03731243A 2003-05-17 2003-05-17 Mecanisme d'application de transformees a des dossiers en plusieurs parties Ceased EP1625510A4 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2003/015707 WO2004107198A1 (fr) 2003-05-17 2003-05-17 Mecanisme d'application de transformees a des dossiers en plusieurs parties

Publications (2)

Publication Number Publication Date
EP1625510A1 true EP1625510A1 (fr) 2006-02-15
EP1625510A4 EP1625510A4 (fr) 2008-03-12

Family

ID=33449011

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03731243A Ceased EP1625510A4 (fr) 2003-05-17 2003-05-17 Mecanisme d'application de transformees a des dossiers en plusieurs parties

Country Status (9)

Country Link
EP (1) EP1625510A4 (fr)
JP (1) JP4378342B2 (fr)
KR (1) KR100965709B1 (fr)
CN (1) CN100430916C (fr)
AU (1) AU2003241506B8 (fr)
BR (1) BR0306999A (fr)
CA (1) CA2470720C (fr)
MX (1) MXPA04007407A (fr)
WO (1) WO2004107198A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007139552A1 (fr) * 2006-05-31 2007-12-06 Citrix Systems, Inc. Systèmes et procédés pour déterminer le codage d'un jeu de caractères afin de décoder une soumission de requête dans une passerelle
US8255373B2 (en) 2008-10-24 2012-08-28 Microsoft Corporation Atomic multiple modification of data in a distributed storage system
US8886796B2 (en) 2008-10-24 2014-11-11 Microsoft Corporation Load balancing when replicating account data
US9996572B2 (en) 2008-10-24 2018-06-12 Microsoft Technology Licensing, Llc Partition management in a partitioned, scalable, and available structured storage
CN108337208B (zh) * 2017-01-19 2020-11-24 中国电信股份有限公司 基于云存储的数据保护方法、替换装置以及云存储系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0408132A1 (fr) * 1989-07-14 1991-01-16 Océ-Nederland B.V. Système pour traiter des données organisées en fichiers avec module de commande
US5742818A (en) * 1995-12-15 1998-04-21 Microsoft Corporation Method and system of converting data from a source file system to a target file system
WO2001037135A2 (fr) * 1999-11-16 2001-05-25 Informatica Corporation Systeme et procede de base de donnees

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3308770B2 (ja) * 1994-07-22 2002-07-29 三菱電機株式会社 情報処理装置および情報処理装置における計算方法
US20020001412A1 (en) * 1998-07-21 2002-01-03 Hewlett-Packard Company System for variable quantization in jpeg for compound documents
US6357042B2 (en) * 1998-09-16 2002-03-12 Anand Srinivasan Method and apparatus for multiplexing separately-authored metadata for insertion into a video data stream
SE513356C2 (sv) * 1998-11-20 2000-08-28 Ericsson Telefon Ab L M Förfarande och anordning för kryptering av bilder
US7644366B1 (en) * 1999-07-30 2010-01-05 Computer Associates Think, Inc. Method and system for displaying a plurality of discrete files in a compound file
US6529948B1 (en) * 1999-08-31 2003-03-04 Accenture Llp Multi-object fetch component
US20020003886A1 (en) * 2000-04-28 2002-01-10 Hillegass James C. Method and system for storing multiple media tracks in a single, multiply encrypted computer file
EP1189432A3 (fr) * 2000-08-14 2004-10-20 Matsushita Electric Industrial Co., Ltd. Un schéma hiérarchique d'encryption pour la distribution sûre de contenu prédéterminé

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0408132A1 (fr) * 1989-07-14 1991-01-16 Océ-Nederland B.V. Système pour traiter des données organisées en fichiers avec module de commande
US5742818A (en) * 1995-12-15 1998-04-21 Microsoft Corporation Method and system of converting data from a source file system to a target file system
WO2001037135A2 (fr) * 1999-11-16 2001-05-25 Informatica Corporation Systeme et procede de base de donnees

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MICROSOFT CORPORATION: THE COMPONENT OBJECT MODEL SPECIFICATION, 24 October 1995 (1995-10-24), pages 1-65, XP002466483 *
See also references of WO2004107198A1 *

Also Published As

Publication number Publication date
AU2003241506B2 (en) 2009-11-26
CN1615477A (zh) 2005-05-11
BR0306999A (pt) 2005-02-09
MXPA04007407A (es) 2005-02-17
CA2470720C (fr) 2011-10-18
EP1625510A4 (fr) 2008-03-12
CN100430916C (zh) 2008-11-05
CA2470720A1 (fr) 2004-11-17
AU2003241506B8 (en) 2010-01-07
KR100965709B1 (ko) 2010-06-24
JP2006526191A (ja) 2006-11-16
KR20060037217A (ko) 2006-05-03
JP4378342B2 (ja) 2009-12-02
WO2004107198A1 (fr) 2004-12-09
AU2003241506A1 (en) 2005-01-21

Similar Documents

Publication Publication Date Title
US7523221B2 (en) Mechanism for applying transforms to multi-part files
US7496586B1 (en) Method and apparatus for compressing data in a file system
US7631022B2 (en) Information processing apparatus and recording medium
US7188118B2 (en) System and method for detecting file content similarity within a file system
US7716445B2 (en) Method and system for storing a sparse file using fill counts
US7293150B2 (en) Method and system for creating and restoring an image file
EP1586988A2 (fr) Appareil de traitement d'information, méthode de traitement d'information, programme et support d'enregistrement utilisé à cet effet
US10726147B2 (en) File encryption support for FAT file systems
US6775678B1 (en) Data structure and method of storing a digital document
US20070156768A1 (en) System and method for managing dynamic document references
TW200408980A (en) System and method for managing file names for file system filter drivers
JP2016509309A (ja) データを格納および取得するための方法およびシステム
JP2008537259A (ja) 資源間の関係の効率的記述
US20130339717A1 (en) Virtualized Boot Block with Discovery Volume
US7415480B2 (en) System and method for providing programming-language-independent access to file system content
US20110271064A1 (en) Storage device and method for accessing the same
CA2470720C (fr) Mecanisme d'application de transformations a des fichiers en plusieurs parties
JP2005108239A (ja) 階層的データ構造体にデータを記憶する記憶システム
US7412450B1 (en) Method and apparatus for identifying tampering of data in a file system
US7437528B1 (en) Gang blocks
CN105243090A (zh) 一种独占文件的获取方法和系统
RU2348069C2 (ru) Механизм применения преобразований к файлам, состоящим из множественных частей
US7603568B1 (en) Method and apparatus for self-validating checksums in a file system
Wirth et al. Sequential input and output

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051104

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20080212

17Q First examination report despatched

Effective date: 20080729

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20100708