Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-05-28
2001-05-08
Banankhah, Majid A. (Department: 2755)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C707S793000
Reexamination Certificate
active
06230212
ABSTRACT:
TECHNICAL FIELD
The invention relates generally to a computer method and system for tracking links to objects, and, more specifically, to a method and system for resolving links to objects.
BACKGROUND OF THE INVENTION
Computer systems are often used to compose, store, retrieve, and update objects containing information. An application program such as a word processor or a spreadsheet is usually employed to perform these activities. Typically, a user composes an object by using an application program to input all of the contents of the object, using an input device such as a keyboard. As an example, if a user were to compose a report object containing several introductory paragraphs of text, a numerical table, and several conclusory paragraphs of text, the user would typically use a keyboard to type the introductory paragraph, the numerical table, and the conclusory paragraphs.
To facilitate the inputting of the contents of an object, a user may copy information from an existing object into the object being composed. This copying method has the advantage that it allows a user to avoid re-inputting information that has already been input. For example, when a user composes a report object and a ledger object already exists that contains the numerical table, the user may copy the numerical table from the ledger object into the report object instead of retyping the numerical table.
The copying method has the disadvantage that, when the numerical table is copied to the report object from the ledger object, the object loses its association with the ledger object. If the ledger object is then changed, the numerical table in the report object does not automatically change.
This loss of association disadvantage can be overcome by the use of object links. An object link (link) is a reference to a source object that is stored in a client object. The computer system treats the link as if the current contents of the source object are incorporated in the client object. When a user accesses the client object, the computer system encounters the link and then locates and accesses the source object. Locating the source object of a link is called resolving the link. When links are used, the current version of the source object is incorporated in the client object. The client object therefore has the benefit of any updates to the source object, even if they occurred after the link was created.
As an example of the use of links, a user can link a ledger object containing a numerical table of sales information into a report object containing a textual description of the sales information.
FIG. 1
is a diagram illustrating the use of a link. A report object
101
named report.doc contains a link
102
to a ledger object
103
named ledger.xls. When the report.doc object is displayed, the link to the ledger.xls object is resolved, allowing the contents of the ledger.xls object to be accessed and incorporated in the display
104
. Here, the ledger.xls object is the source object and the report.doc object is the client object.
Each link contains information used to locate where the source object is stored. Objects may be persistently stored in a variety of organizations on various storage devices. For example, a hierarchical file system stores objects as files. A hierarchical file system is a file system in which a root directory can contain files and subdirectories. Any subdirectory may contain files and further subdirectories. Thus, successive levels of subdirectories that descend from the root directory form a hierarchy. A pathname describes a location in the hierarchy, and each pathname refers to a file or subdirectory. For example, the pathname “\dos\copy.exe” describes a file named “copy.exe” contained in a directory called “dos”, which in turn is contained in the root directory. Hierarchical file systems typically store links as pathnames.
Pathnames are either absolute or relative. An absolute pathname contains information needed to locate a file with respect to the root directory. A relative pathname, on the other hand, contains information necessary to locate a file with respect to the location of some other file. A link containing a relative pathname specifies the location of the source object relative to location of the client object. When a source object is located in the same directory as the client object, the link contains the source object name prefaced by the characters “.\”. Therefore, if the report.doc and ledger.xls objects were located in the same directory, the pathname in the link would be “.\ledger.xls”. An absolute pathname is an ordered list of the subdirectories into which one must successively descend to reach the source object, beginning with the root directory. If the ledger.xls object is in a directory named “acme”, which in turn is in a directory called “companies” which in turn is in the root directory, the absolute pathname of the ledger.xls object is “\companies\acme\ledger.xls”.
FIG. 2
shows a conventional method for storing and resolving links. Client object
200
is a report object. It contains a link to a ledger object, which in turn contains the absolute pathname of the source object, “\companies\acme\ledger.xls”. As described above, this absolute pathname specifies a location in a file system hierarchy. The file system hierarchy contains directories
220
-
226
. Directory
226
is the \companies\acme directory, which contains the source object. Directory
230
is a detailed view of directory
226
. It contains a mapping of file names for files contained in the \companies\acme directory to file system identifiers. A file system identifier uniquely identifies a file in the file system. For example, directory
30
maps filename “report.doc” to file system identifier “<fsid1>” and filename “ledger.xls” to file system identifier “<fsid2>”. A file system identifier table
240
then maps each file system identifier to an access information block. Each access information block contains a list of the locations and the storage media, or “sectors” that contain the data that comprise a file. For example, the file system identifier table maps from the file system identifier “<fsid1>” to access information block
250
and from file system identifier “<fsid2>” to access information block
260
. Access information block
260
contains a list of the sectors that comprise the source file. Access information block
260
contains three references to comprise reference
263
, reference
264
, and reference
265
. These references refer to sectors
273
,
274
, and
275
of the media
270
, respectively.
Operating systems typically include commands that allow a user to move or rename an object. In a system supporting links between objects, the move or rename commands can be expanded to update the pathname in any link that refers to the moved or renamed object. However, operating systems also provide copy and delete commands that a user may use to move and rename objects. A user may rename an object by copying the object into the same directory and deleting the copied-from object. A user may move an object by copying the object into a different directory and deleting the copied-from object. Any time a user employs the copy and delete commands to move or rename a source object, any links to the source object may become impossible to resolve.
FIGS. 3A-3C
are block diagrams that illustrate the problem that occurs when the copy and delete commands are used to rename a source object. In
FIG. 3A
, the report.doc object
301
contains a link
302
to the ledger.xls object
303
. The link uses a relative pathname to refer to the ledger.xls object. If the link were resolved at this point, it would resolve correctly to the ledger.xls object. In
FIG. 3B
, the report.doc object, the ledger.xls object. and the link are unchanged. However the ledger.xls object has been copied to a growth.xls object
304
. At this point, the link would still resolve to the ledger.xls object, because it still contains t
Jung Edward Koo Young
Morel William Paul
Banankhah Majid A.
Courtenay III St. John
Klarquist Sparkman Campbell & Leigh & Whinston, LLP
Microsoft Corporation
LandOfFree
Method and system for the link tracking of objects does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for the link tracking of objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for the link tracking of objects will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2564948