WikiPatents - Community Patent Review
Create Free Account  |  License or Sell Your Patent  |  WikiPatents Marketplace  |  WikiPatents Blog
Username:  Password:  
    
Advanced Search
Method and system for storing and accessing data in a compound document using object linking    
United States Patent5715441   
Link to this pagehttp://www.wikipatents.com/5715441.html
Inventor(s)Atkinson; Robert G. (Woodinville, WA); Bliss; Andrew L. (Bellevue, WA); Lafornara; Philip J. (Bellevue, WA); Ljubicich; Philip (Seattle, WA); Tilles; Alexander G. (Seattle, WA); Williams; Antony S. (Redmond, WA)
AbstractA method and system for interfacing an application program with a compound document storage system. The present invention provides an interface which an application program uses to manipulate compound documents. In a preferred embodiment, this interface is implemented in a multilayered architecture. The first layer provides methods which an application program uses to access a compound document using the functions of the second layer. The second layer maps requests to store data in the compound document to a storage format using the functions of the third layer. The third layer maps requests to write to a file to an arbitrary storage medium.
   














 Title Information Submit all comments and votes
 
Patent Text Patent PDF Print Page Summary File History
Plain text PDF images Print Summary File History
Drawing from US Patent 5715441
Method and system for storing and accessing data in a compound document using object linking - US Patent 5715441 Drawing
Method and system for storing and accessing data in a compound document using object linking
Inventor     Atkinson; Robert G. (Woodinville, WA); Bliss; Andrew L. (Bellevue, WA); Lafornara; Philip J. (Bellevue, WA); Ljubicich; Philip (Seattle, WA); Tilles; Alexander G. (Seattle, WA); Williams; Antony S. (Redmond, WA)
Owner/Assignee     Microsoft Corporation (Redmond, WA)
Patent assignment
All assignments
Publication Date     February 3, 1998
Application Number     08/474,100
PAIR File History     Application Data   Transaction History
Image File Wrapper   Patent Term   Fees
Litigation
Filing Date     June 7, 1995
US Classification     707/1 715/500 715/515
Int'l Classification     G06F 017/30
Examiner     Black; Thomas G.
Assistant Examiner     Rones; Charles
Attorney/Law Firm     Seed and Berry LLP
Address
Parent Case     CROSS-REFERENCE TO RELATED APPLICATION This application is a division of U.S. patent application Ser. No. 07/909,533, filed Jul. 6, 1992 now U.S. Pat. No. 5,506,983 issued on Apr. 9, 1996.
Priority Data    
USPTO Field of Search     395/600 395/703 395/148 395/161 395/612 395/621 395/335 395/601 395/614 395/611 395/777 395/602 395/761 364/419 364/523 364/300 364/148 370/469
Patent Tags     storing accessing data compound document object linking
   
Enter a comma (,) or semicolon (;) between multiple tag words/phrases.
Describe this patent:
 Amusing   
 Clever   
 Complex   
 Efficient   
 Historic   
 Important   
 Innovative   
 Interesting   
 Practical   
 Simple   
[no votes]
Patent WIKI

Share information and news about this patent, including information and news about the technology, inventors, company, ligation and licensing.
 References Submit all comments and votes
 
*references marked with an asterisk below are user-added references
 U.S. References
 
Add a new US reference:  
ReferenceRelevancyCommentsReferenceRelevancyComments
5634019
Koppolu
715/744
May,1997
[0 after 0 votes]		5613124
Atkinson
345/557
Mar,1997
[0 after 0 votes]
5537526
Anderson
715/515
Jul,1996
[0 after 0 votes]		5535319
Pascoe
715/524
Jul,1996
[0 after 0 votes]
5524202
Yokohama
707/104.1
Jun,1996
[0 after 0 votes]		5515536
Corbett
719/315
May,1996
[0 after 0 votes]
5506983
Atkinson
707/1
Apr,1996
[0 after 0 votes]		5479656
Rawlings, III
707/200
Dec,1995
[0 after 0 votes]
5467472
Williams

Nov,1995
[0 after 0 votes]		5448727
Annevelink
707/101
Sep,1995
[0 after 0 votes]
5437027
Bannon

Jul,1995
[0 after 0 votes]		5423034
Cohen-Levy
707/10
Jun,1995
[0 after 0 votes]
5371885
Letwin
707/205
Dec,1994
[0 after 0 votes]		5359708
Bloomer
715/524
Oct,1994
[0 after 0 votes]
5349658
O'Rourke
715/839
Sep,1994
[0 after 0 votes]		5339392
Risberg
715/762
Aug,1994
[0 after 0 votes]
5335290
Cullen

Aug,1994
[0 after 0 votes]		5317730
Moore
707/100
May,1994
[0 after 0 votes]
5280609
MacPhail
707/1
Jan,1994
[0 after 0 votes]		5269019
Peterson
707/205
Dec,1993
[0 after 0 votes]
5247520
Geise
370/469
Sep,1993
[0 after 0 votes]		5243518
Holt
715/500
Sep,1993
[0 after 0 votes]
5226145
Moronaga
711/202
Jul,1993
[0 after 0 votes]		5173853
Kelly
715/530
Dec,1992
[0 after 0 votes]
5146553
Noguchi
715/516
Sep,1992
[0 after 0 votes]		5093779
Sakurai
707/1
Mar,1992
[0 after 0 votes]
5029125
Sciupac
707/205
Jul,1991
[0 after 0 votes]		4933880
Borgendale
715/515
Jun,1990
[0 after 0 votes]
4907151
Bartlett
711/166
Mar,1990
[0 after 0 votes]		4899299
MacPhail
707/204
Feb,1990
[0 after 0 votes]
4739477
Barker
707/100
Apr,1988
[0 after 0 votes]		4723209
Hernandez

Feb,1988
[0 after 0 votes]
4536837
Olson
707/205
Aug,1985
[0 after 0 votes]		5185885
Dysart
707/100
Dec,1969
[0 after 0 votes]
 Foreign References
 Other References
 Market Review Submit all comments and votes
   
Market Size
Estimate the gross annual revenues of the relevant market sector:
> $10B
$5B - $10B
$2B - $5B
$500M - $2B
$100M - $500M
$10M - $100M
$1M - $10M
$500K - $1M
$100K - $500K
< $100K
[No votes]
$0
 
$0   $2.5B   $5B   $7.5B   $10B
Market Share
Estimate the percentage of the relevant market sector this invention will capture:
75% - 100%
50% - 74.99%
25% - 49.99%
10 - 24.99%
5 - 9.99%
2 - 4.99%
1 - 1.99%
< 1%
[No votes]
0.0%
 
0%   25%   50%   75%   100%
Reasonable Royalty
What percentage of gross sales should the inventor or assignee be paid?
75% - 100%
50% - 74.99%
25% - 49.99%
10 - 24.99%
5 - 9.99%
2 - 4.99%
1 - 1.99%
< 1%
[No votes]
0.0%
 
0%   25%   50%   75%   100%
Public's "Guesstimation" of Royalty Value
Market SizeN/A[No votes]
xMarket ShareN/A[No votes]
xReasonable RoyaltyN/A[No votes]
N/A
License Availablity
If you are NOT the owner or assignee, answer here:
Yes, license is available for purchase

No, license is not currently available



 [No votes]
License Availablity
If you ARE the owner or assignee, answer here:
Yes, license is available for purchase

No, license is not currently available



 [No votes]
Competitive Advantage
Does this invention have a significant competitive advantage over similar technologies?
Yes

No



 [No votes]
Most helpful competitive advantage comment
[No comments]
Commercial Alternatives
Are there viable commercial alternatives for this invention?
Yes

No



 [No votes]
Most helpful commercial alternative comment
[No comments]
 Technical Review Submit all comments and votes
 Claims Submit all comments and votes
 


We claim:

1. A method in a computer system for storing data in a data storage area, the computer system having an application program that invokes a first application interface layer for accessing the data, the method comprising the steps of:

under control of the application interface layer;

receiving from the application program a reference to a second intermediate interface, the intermediate interface having a plurality of functions for accessing the data storage area, one of the functions for resizing the data storage area;

receiving from the application program a request to access the data storage area;

in response to receiving the request, invoking one or more functions of the intermediate interface received from the application program to effect: the accessing and resizing of the data storage area; and

wherein the application interface layer can receive references to different implementations of the intermediate interface from different application programs.

2. The method of claim 1 wherein the intermediate interface received from the application program includes a function for accessing the data storage area as an array of bytes.

3. The method of claim 2 wherein the intermediate interface received from the application program includes a function for locking a range of bytes of the array to prevent conflicting access to the range of bytes.

4. The method of claim 1 wherein the computer system has a file system, wherein the data storage area is a file, and the intermediate interface received from the application program includes functions that invoke the file system to effect the accessing of the data storage area.

5. An object storage computer system for storing objects into a data storage area of the computer system comprising:

a first application interface layer invocable by an application program, application interface layer providing a hierarchical organization for the storage of the objects, each object optionally having a subobject and optionally having object data, the application interface layer having a storage interface for enumerating; the subobjects of an object and for providing a stream interface for object data, the stream interface for accessing the object data;

a second intermediate layer invocable by the application interface layer, the intermediate layer for providing a linear organization for the storage of data, the intermediate layer having an access interface for accessing the data of the storage;

a third bottom layer invocable by the intermediate layer fear directly accessing the data storage area such that when an application program invokes the application interface layer, the application interface layer invokes the intermediate layer; and the intermediate layer invokes the bottom layer to directly access the data storage area and such that when an application program invokes the application interface layer, the application program specifies an implementation of the intermediate layer that is to be invoked by the application interface layer; and

wherein different application programs can specify different implementations of the intermediate layer.

6. The system of claim 5 wherein the intermediate layer includes a method for dynamically changing the size of an array representing the linear organization of the storage.

7. The system of claim 6 wherein the intermediate layer includes a method for locking a range of bytes in the array to prevent conflicting access to the locked range.

8. The system of claim 5 or 6 wherein the application interface layer includes methods for transactioning modifications to the data.

9. The system of claim 5 or 6 wherein the bottom layer is a file system.

10. The system of claim 9 wherein the file system uses a file allocation table.

11. The system of claim 5 or 6 wherein the application interface layer includes methods for storing data in a stream.

12. The system of claim 5 or 6 wherein the application interface layer provides methods for storing objects in a hierarchical manner.

13. A method in a computer system for accessing object data in a data storage area, the computer system having an application program, comprising:

under control of the application program, invoking a first application interface layer to access to object data, the application program providing to the application interface layer an implementation of a second intermediate layer, the application interface layer providing a predefined organization for the storage of the object data, the intermediate layer for providing a linear organization for the storage of object data;

under control of the application interface layer, invoking the intermediate layer to access the linear organization for the storage of object data;

under control of the intermediate layer invoking a third bottom layer for directly accessing the data storage area in which object data is stored; and

wherein different application program can specify different implementations of the intermediate layer to customize the accessing of the object data.

14. The method of claim 13 wherein the intermediate layer includes a method for dynamically changing the size of the linear organization.

15. The method of claim 13 wherein the intermediate layer includes a method for locking a range of bytes in the linear organization to prevent conflicting access to the locked range.

16. The method of claim 13 wherein the application interface layer includes methods for transactioning modifications to the data.

17. The method of claim 13 wherein the bottom layer is a file system.

18. The method of claim 17 wherein the file system uses a file allocation table.

19. The method of claim 13 wherein the application interface layer includes methods for storing data in a stream.

20. The method of claim 13 wherein the application interface layer provides methods for storing objects in a hierarchical manner.

21. A computer-readable medium containing instructions for causing a computer system to access object data in a data storage area by:

under control of the application program, invoking a first application interface layer to access object data, the application program providing to the application interface layer an implementation of a second intermediate layer, the application interface layer providing a predefined organization for the storage of the object data, the intermediate interface layer for providing a linear organization for the storage of object data and for providing for the resizing of the linear organization;

under control of the application interface layer, invoking the intermediate layer to access the linear organization;

under control of the intermediate interface layer, invoking a third bottom layer for directly accessing the data storage area in which object data is stored; and

wherein different application programs can specify implementations of the intermediate layer to customize the object data.

22. The computer-readable medium of claim 21 wherein the intermediate layer includes a method for dynamically changing the size of the linear organization.

23. The computer-readable medium of claim 21 wherein the intermediate layer includes a method for locking a range of bytes to prevent conflicting access to the locked range.

24. The computer-readable medium of claim 21 wherein the application interface layer includes methods for transactioning modifications to the data.

25. The computer-readable medium of claim 21 wherein the bottom layer is a file system.

26. The computer-readable medium of claim 25 wherein the file system uses a file allocation table.

27. The computer-readable medium of claim 21 wherein the application interface layer includes methods for storing data in a stream.

28. The computer-readable medium of claim 21 wherein the application interface layer provides methods for storing objects in a hierarchical manner.
 Description Submit all comments and votes
 


TECHNICAL FIELD

This invention relates to a method and system for data storage and, more particularly, to a method and system for storing and accessing data in a compound document.

BACKGROUND OF THE INVENTION

Computer operating systems typically include a sub-system called a file system. A file system stores data in files. A file system provides an application programming interface (API) to facilitate accessing data stored on disk or other long-term storage medium. A file system API provides various functions that are invoked by an application program to access the data. Application programs control the internal format of a file and determine which data to store in which files. A file system typically allows files to be grouped into directories. Each directory may contain many files and many sub-directories. The sub-directories may also contain files and other sub-directories. A file system that groups files into directories and sub-directories is referred to as hierarchical file system.

Many application programs need to access various types of data. For example, word processing programs may combine data that is in text, graph, and spreadsheet format into a single document. A text format is known as the native format for word processing programs. A user of a word processing program may specify that graph or spreadsheet data that is stored in a file is to be included in the document. To do so, word processing programs may import data from files generated by a graph program or a spreadsheet program. Word processing programs typically need to know not only the internal format of the graphic and spreadsheet files, but also how to display or print the graph and spreadsheet data.

The marketability of a word processing program is enhanced by its ability to import data stored in many formats. However, it can be very time-consuming and expensive to adapt a word processing program to access data in a specific non-text format. To adapt to a word processing program, the developer would need a complete description of the specific format and then develop code to print, display, and possibly store the data. The effort needed to adapt a word processing program to a specific format is increased when the format is defined by another vendor. The vendor may not publish a complete specification of the format or may change the format without notice. Consequently, an application program developer may choose to support only a few of the more popular file formats other than the native file format.

One solution that has been suggested is that word processing programs invoke the application program that generated the data in the specific non-text format to display or print the non-text data that is part of a word processing document. For example, if a document incorporates a graph, then the word processing program would invoke the graph program that generated the data to print or display the graph or to perform some other task using the data. However, unless the graph program was developed specifically to be invoked by a particular word processing program, it may not be practicable to invoke the graph program. Graph programs typically expect data to be stored in a certain format and in a file with only graph data.

Several approaches have been suggested to allow a word processing program to invoke other programs to print, display, or otherwise process non-text data that is part of a word processing document. A first approach modifies each of the programs that generate the non-text data so that they know the internal format of the word processing document, can retrieve the non-text data from the document, and can process the retrieved data. This approach can be expensive because the programs would need to know the internal format for each word processing program.

A second approach stores each component of the word processing document in a separate file. Using this approach, data would be stored in the native format of each application program. Thus, the application program could be invoked to process the native data directly. However, this second approach jeopardizes the integrity of the word processing document. Users typically can delete a file using the operating system commands. A user could delete one of the files that is part of a word processing document. The word processing document would then have a link to a deleted file.

The problems encountered become complicated when the non-text data incorporated can additionally include other non-text data belonging to different programs. This situation is referred to as the arbitrary nesting of data. For example, a word processing document can contain a spreadsheet table which in turn contains a sound annotation. If a user wishes to edit the sound annotation, the word processing program invokes the spreadsheet program and tells it to invoke the sound editor. The sound editor must be able to locate its non-text data.

Additional complications occur if a user, by virtue of conceptually placing non-text data in a word processing document, expects to be able to edit the non-text data and only permanently save the changes when the user decides to save the changes to the word processing document. The programs invoked to process the non-text data must coordinate any changes made with the word processing program.

One approach is to modify each program to support a flag telling the program to save all changes to a designated temporary file. The word processing program