A distributed computer system.

This invention relates to distributed digital computer systems (including systems with heterogeneous operating environments) and, more particularly, to methods and devices that (1) enable users of such systems to store data-intensive files, e.g. create, manipulate, share, and practically limit digital voice and music files, "scanned" image files, and animated files or files with moving video, while (2) avoiding the need to make multiple copies of such files store and manage, and (3) reuse space allocated to such files when they are no longer needed.

Conventional distributed computer systems have limited users for alphanumeric and simple graphic communication (collectively referred to herein as "text communication"), although voice, video, and even music media are often more powerful and effective for interpersonal communication. Others have recognized the need to expand such systems sufficiently to support non-text communication as an alternative or addition to text communication. Considerable efforts and costs have been devoted to, for example, both the development of voice messaging systems and the development of multimedia systems for commenting on text with speech. Language is the non-text communication medium that has been widely studied for use in distributed computer systems, so this invention will be described in this context to provide a representative example. Nevertheless, it is understood that the broader aspects of this invention are applicable to other types of data-intensive non-text communications in distributed computer systems.

Various interesting and potentially important advantages flow from handling voice and other non-text media as data into a distributed computing environment. See Nicholson, "Integrating Voice in the Office World", Byte, Volume 8, No. 12, Dec. 1983, pages 177-184. It enables easy incorporation of non-text media into electronic mail messages and annotations related to ordinary text files, as well as prompts and other interactive messages provided by the computing environment user interface. In short, such handling allows users to manipulate and participate in the creation and participation of these non-text data files in much the same way as they handle conventional text files, and enables programmers to perform functions that include such non-text data files, implement generally in the same way that they implement functions that include text files.

However, voice and other non-text data files differ significantly from ordinary text data files. For example, classic workstations cannot record or play voice data files in analog form, so special facilities are required for this purpose. More importantly, voice data files are typically much larger than text files that contain the same words. Indeed, the recording of uncompressed speech with normal telephone quality consumes about 64 kbits of memory per second, which is several orders of magnitude larger than the storage capacity required for an equivalent passage of written text. Yet another factor to consider is that there are strict real-time requirements for voice transmission because unimportant pauses or word chopping when playing voice creates a perceptual problem that disrupts or negates the desire to communicate.

Users of distributed computer systems are occasionally in heterogeneous computing environments with various network services that are carried out using different transmission protocols. In addition, the traffic between such computing environments can be routed through a variety of public or private network operators, which can conceivably include different line switching schemes. Gateways have been developed to mediate text messaging between heterogeneous environments so that the value and utility of non-text communications in such systems may depend in large part on the ease with which non-text communications are communicated through such gateways can.

Others have addressed some of the problems that need to be solved to perform voice and similar non-text communications in distributed computing environments. The 'Sydis Information Manager' uses special workstations (called "VoiceStations") to record, edit and play back speech. See Nicholson, "Integrating Voice in the Office World," Byte, Vol. 8, No. 12, Dec. 1983, pages 177-184. A system for integrating voice and data for simple workstation applications has also been described, namely Ruiz, "Voice and Telephone Applications for the Office Workstation", Proceedings 1st International Conference on Computer Workstations, San Jose, Ca., November 1985, pages 158-163. Voice storage systems with facilities for recording, editing and playing back speech have been proposed, namely Maxemchuk, "An Experimental Speech Storage and Editing Facility", Bell System Technical Journal, Volume 58, No. 9, Oct. 1980, pages 1383-1396.

Even more to the point, there are systems that allow users to use documents that contain embedded references to non-text media objects that are in a common file service and collect the "waste" of those objects around them Reuse allocated storage space if there are no more documents or document filers that contain references to them. See Thomas et al., "Diamond: A Multimedia Message System Built on a Distributed Architecture", Computer, Volume 18, No. 12 Dec. 1985, pages 65-78. Systems such as the Diamond system that use embedded textual references to refer to voice, video, and various other types of non-textual data are sometimes referred to as "hypermedia systems". See Yankelovich et al., "Reading and Writing the Electronic Book," Computer, Vol. 18, No. 10, Oct. 1985 pages 15-60. Unlike most other proposed systems, the embedded references used by the Diamond system circumvent the need to include copies of the non-text data files (ie, voice files) in every document file to which they belong. However, the simple referral counting waste collection scheme of the Diamond system is incompatible with allowing references to internally stored objects to be included in documents or document filers that are stored outside of the system.

The state of the art of interest, which concerns the waste collection of ordinary data files, has also been uncovered. The Cambridge File Server requires clients to take some action to prevent files from being trashed because it automatically deletes files that are not accessible from client-updated and server-maintained indexes. See Mitchell et. al., "A Comparison of Two Network-Based File Servers," Communications of the ACM, Volume 25, No. 4, April 1982, pages 233-245. A little less relevant, but still of interest as an example of how to build a highly reliable referral server is that in Liskov et al. described system "Highly-Available Distributed Services and Fault Tolerant Distributed Garbage Collection", Proceedings of Symposium on Principles of Distributed Computing, Alberta, Canada, August 1986, pages 29-39. The garbage collection scheme they envision requires all locations that store references to remotely stored shared objects to run locally a garbage collector, the purpose of which is to send information about distributed references to a common reference server.

Also of interest is Swinehart et al., "Adding Voice to an Office Computer Network", Proceedings of the IEEE GlobCom, Nov. 1983, pages 392-398. Swinehart et al. describe a specially designed processor that is connected to a telephone device and sends digitized speech, signaling and monitoring information in individual packets over an Ethernet LAN.

Also of interest is Terry et al., "Managing Stored Voice in the Etherphone System", ACN Transactions on Computer Systeme 6 (1): 3-27, February 1988.

At least two problems remain to be solved. Given the very large size of most non-text data files (e.g., voice data files), it is important that a method be developed to edit these files using simple databases without moving, copying, or decrypting the files (if must be saved in encrypted form) and to describe the results of the editing processes. A method of using simple databases is also needed to support a garbage collector that automatically reuses the memory space allocated to outdated non-text data files.

The invention is as claimed in claim 1.

According to the invention, a database of interest is maintained in a distributed computing system in order to satisfy the individual interests of users in centrally stored non-text media files, for example register digital voice-scanned image and video files, whereby uniquely named, parts list-like, permanent data structures are used to give users controlled access to the underlying non-text media files by means of embedded name references to such parts lists in ordinary message or text files to give, so a database of parts lists is also maintained. A garbage collector periodically enumerates the interest database to delete interest entries that have been invalidated. Old BOMs are deleted from the referral database when there are no more recorded interests that reference them, and non-text media files are deleted to reuse the space allotted to them when there are no more BOMs referencing them.

Further features and advantages of this invention will become apparent when the following detailed description is read in conjunction with the accompanying drawings.

Contents of the drawings:

Fig. Is a schematic drawing showing two local area networks connected on command by gateways and a communication channel, the networks being configured in accordance with this invention to support voice transmissions in addition to ordinary text transmissions.

Figure 2 is a workstation screen illustrating a suitable user interface for recording, editing and playing back voice files.

3 is a layered illustration of a voice manager for a local area network.

Fig. 4 is a graph showing the correlation of the language files with the data structures used to refer to them.

Figure 5 is a simplified functional flow diagram of an interest garbage collector.

Figure 6 is a simplified functional flow diagram of a voice string garbage collector.

Figure 7 is a simplified functional flow diagram of a voice file garbage collector.

8 is a simplified partial functional flow diagram for an integrated voice string / voice file garbage collector.

Figure 9 is a simplified partial functional flow diagram for an integrated interest / speech thread garbage collector.

Fig. 1 shows a distributed computer system 21 (only shown in the relevant part), which comprises a local area network (LAN) 22 with a gateway 23, which connects it to another LAN (not shown) directly or possibly via a switched communication device. In line with the usual configuration of CSMA / CD (ie Ethernet networks, the LAN 22 has a linear topology for connecting a plurality of workstations 24a and 24b, but it will be appreciated that it or any other LAN to which it is connected may have a different topology, for example a ring-like topology , Still other examples of the heterogeneous environment that may exist, assuming the diverse properties of commercially available workstations and LANs, will be apparent, so that it can be understood that the gateway 23 performs reformatting and time-updating functions required to read data from a LAN that operates in accordance with one transmission protocol to another LAN that operates in accordance with another transmission protocol. Additional gateways can be provided, if desired, to expand system 21 to include even more LANs (not shown).

In order to enable users to send and receive voice messages over the LAN 22 in addition to or instead of conventional text messages and data files that they exchange via their workstations 24a and 24b, there are microprocessor-based telephone devices 31a and 31b that are in the vicinity of the Workstations 24a and 24b are located, but are not physically connected to them. These telephone devices convert voice to the digital data format needed to comply with the transmission protocol of the LAN to which they are connected. The telephone devices 31a and 31b, for example, digitize, package and encrypt voice-quality speech for direct transmission via the Ethernet-like LAN 22. For a more detailed description of how this is done, see Swinehart et al., "Adding Voice to an Office Computer Network", Proceedings IEEE Globecom '83, Nov. 1983, and Swinehart et al., "An Experimental Environment for Voice System Development ", IEEE Office Knowledge Engineering Newsletter, Feb. 1987. As previously stated, telephone devices 31a and 31b are not directly connected to workstations 21a and 21b, since similar telephone devices can be used with different workstations, such as may be present in a heterogeneous environment.

In accordance with the invention, the system 21 includes a voice manager 34 connected to the LAN 22 to provide storage for voice, phone calls, music, and other sounds recorded with acceptable sound quality. Other specialized sources of, or sinks for, sound, e.g. a text / speech converter (not shown) that receives text strings and returns the corresponding speech data file for playback via one or more telephone devices 31a and 31b may be included in the speech manager 34 if desired.

A voice control server 35 provides control functions similar to those of a conventional business telephone system and directs the interactions between the other components of the system 21 while operating on voice. In accordance with its ordinary telephone system functions, the voice control server 35 allows voice dialogues between both two or more users and between each user and a voice file server 36 via the user phones 31a and 31b, the LANs 22 and, if appropriate, the gateway 23 to manufacture quickly. When such a dialog is established, the control server 35 also distributes a communication path identifier, DialogID, to all participants in the dialog, including the users' telephone devices and workstations involved, as well as to the voice file server 36 if it is activated to record the dialogue. As will be seen, this DialogID is used to identify the dialog in requests and reports that can be issued by the voice control server 35 or participants after the dialog ends.

All control required for voice transmissions is accomplished through a remote procedure call (RPC), protocol, which is preferably a secured protocol. See, for example, Birrell et al., "Implementing Remote Procedure Calls", ACM Transactions on Computer Systems, Volume 2, No. 1, Feb. 1984, pages 39-69, and Birell et al., "Secure Communications Using Remote Procedure Calls" , ACM Transactions on Computer Systems, Volume 3, No. 1, Feb. 1985, pages 1-14. Multiple implementations of the RPC protocol allow workstations 24a and 24b to be integrated for speech operations, even if they run programs and execute speech applications that are programmed using different programming environments. As will be seen, the reports issued by the voice control server 35 in response to the RPCs it receives in the course of a dialog keep participants informed of the relevant system realities that support the dialog.

The active participants in a dialogue exchange language using a suitable voice transmission protocol. Compare again the Swinehart article mentioned "Adding Voice to an Office Cauputer Network". During each dialogue, the entire language sent is encoded, preferably with secure encryption, for example DES electronic codebook (ECB) encryption, which is based on a randomly generated coding key that is output by the voice control server 35. See, e.g., National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPs), US Department of Commerce, Publication No. 46, January 1977. This key is distributed to the dialogue participants in response to the RPCs they issue), thereby enabling their telephone devices 31a and 31b to decrypt the dialogue.

In accordance with one or more important features of this invention, workstations 24a and 24b provide users with enhanced control over the language capabilities of system 21. FIG. 2 shows screen 41 of a typical workstation, e.g. workstation 24a, as it appears when the user has opened two windows 42 and 43, one commented on viewing text with references to a language passage as at 42, and another on viewing a graphical representation of a given speech passage as at 43. These language references are typically indicated by balloon-like symbols embedded in the text of the annotated document, such as at 44, so that any selected symbol can be "opened" to view its graphical representation, such as at 43, while it is played and / or edited. The graphical representation of speech suitably uses a linear chain of alternating light and dark Balkans to represent proportionally long intervals of speech and silence. Silence is determined via a threshold operation when the energy level of the speech drops below a predetermined threshold level, so it will be understood that such a term is used here in its relative sense.

As an introduction to a description of the voice and other sound editing functions that users can perform using their workstations 24a and 24b, it will be helpful to briefly review the basic functions RECORD, PLAY and STOP that users can access go through. When a user issues a RECORD instruction, the voice control server 35 issues a DialogID that identifies a transmission path for connecting the user phone device to the voice file server 36. The voice manager 34 responds to the DialogID by allocating space on the voice file server 36 to record a new voice file and by giving such a voice file a unique name, VoiceStrangID. After that, the recording continues until the user issues a STOP instruction. While the recording is taking place, the speech manager also accumulates a count to determine the length of the speech strand, VR, in suitable time units, eg 1/8000 seconds per unit. In response to the STOP statement, all recording or playback operations that are then in progress or scheduled for the session identified by the given DialogID are immediately stopped. The PLAY statement is similar to the RECORD statement except that it is initiated by a user who issues a speech string ID and a specified interval that either the whole speech string or a specified interval thereof at an appropriate resolution (in this case 0.1 ms) Are defined. The voice control server 35 responds to the PLAY instruction by issuing a DialogID to establish a transmission path from the voice file server 36 to the user telephone device, and the voice manager 34 causes the voice file server 36 to select the user-selected interval of the selected VF, as by the user-specified VRs (ID, interval) are determined to send.

Typically, the RECORD and PLAY functions are performed asynchronously with remote procedure calls that return after they have been scheduled by the voice file server 36. Scheduled operations are generally performed in order to enable the voice manager 34 to use a straightforward report generation procedure to keep users up to date on the statue of their requirements. The voice manager 34 gives, for example suitably return a RequestID if each is scheduled. Operation is started and completed to thereby enable it to make calls to each user involved in such an operation, which calls typically look like this:

REPORT [RequestID, {started / ended / flushed out]].

Speech threads, VRs, the recorded speech files, VFs, or part. and identifying combinations thereof are immutable, but can be used by users to create new unalterable VRs by applying the normal editing functions of their worksations 24a and 24b. To aid editing, a DESCRIBE (VoiceRopeID) operation can be called to cause the voice manager 34 to return to the requestor's workstation a list of time intervals that the non-silent bursts of speech (as used herein "speech burst" is a consequence) of speech samples limited by a predetermined minimum interval of silence) of the specified VR. This speech burst list is again used to generate the graphical representation of the speech bursts and the intervening intervals of silence of the selected VR, as shown in window 43 of FIG. 2. Preferably, a lookup table of the speech bursts associated with all speech files, VFs, recorded on the speech file server 36 is maintained to reduce the overhead involved in compiling the speech burst list for a given speech string.

The conventional text editing functions that can be applied directly to voice string editing are:

CONCATENTATE [SprachStrangID 1, SprachStrangID 2, ...] - returns a new speech ID to create a new VR which is the concatenation of existing VRs;

SUBSTRING [speech string ID 1, interval] - returns a new speech string ID to create a new VR consisting of a specified section of an existing VR;

REPLACE [speech string ID 1, interval, speech string ID 2,] returns a new speech string ID to create a new speech string using the existing speech string ID 2. for a specified interval of the existing voice string ID & sub1; is used, whereby a connection of the functions CONCATENATE and SUBSTRING is carried out.

LENGTH [SprachStrangID) - returns a length to determine the length of an existing VR in suitable time units, eg ms.

These functions are typically available to voice manager 34 via RPC calls.

Access controls can be overlaid on the VRs to control playback access to their underlying VFs and limit editing of the VRs. These access control lists can contain names of individuals or groups. See Birrell et al., Grapevine: "An Exercise in Distributed Computing", Communications of the ACM, Volume 25, No. 4, April 1982, pages 260-274. Such access controls can, for example can be set up and changed by the producer of a given VR at any time by calling: PERMIT [SprachStrangID, Players, Editors] to restrict access to the specified VR to the named players and the named editors. A suitable default for the access control mechanism would either allow unrestricted access to the VR or restrict access to its creator.

As you will see, VRs have the wi important advantage that they can be shared by many users and included in multiple normal text documents to give authorized users access to the underlying VFs without copying, data-intensive non-text VFs or must be saved in several places. According to an important feature of this invention, users are also free to store documents containing VRs on-line or off-line depending on their individual needs and desires.

To give the user this freedom while ensuring that space on the file server 36 occupied by outdated VFs is regained in time, there is an interest based garbage collector that identifies and deletes outdated VFs, as described in more detail below , Preferably, these user interests are user and class specific so that they can be created and automatically deleted based on each user's usual directory operations, each user being responsible for uniquely identifying their own personal interest in a given class. If, for example a user enters a document that contains a VR in his document or letter directory, an RPC can be initiated to register the user's interest in this VR in the voice manager 34 in the following form: RETAIN [voice string ID, class, interest, user ID ].

This procedure registers the interest of a specified user in a given VR through a given class (eg file note or message). This operation is idempotent, so that subsequent calls with the same arguments only register an interest in a given language string. There is also a FORGET [language string ID, class, interest] procedure that is occasionally performed by an RPC that is issued to the language manager 34 when the user deletes the document or message containing the VR (as opposed to Moving them to another on-line or off-line directory) and otherwise called as a result of a waste collection process to be described below. A LOOKUP procedure can also be provided that returns an unordered list of language strings associated with a single interest to facilitate normal system administration functions.

The interest class attributes of the interest mechanism called by the user are typically arbitrary text string values. However, the form of the interest value is preferably class-specific, so that each class controls its own namespace of interests by using a hierarchical, flat or other form of identification for its interest values. The class of interest, on the other hand, usually identifies the way language strands are used for a single application. For example, a "file comment" class can be used to indicate that a document shared in a named file is commented on by a set of language strands, using the field of interest to provide the file name. Likewise, a "message" class can indicate that an electronic letter message refers to recorded language, the field of interest containing the unique task stamp provided by the messaging system of the individual letter message containing such a reference.

Voice manager 34 (FIG. 1) is typically logically layered, as shown in FIG. 3, to provide a simple but robust means of implementing the voice string editing features described above and managing user interests in such voice strands and their underlying language files to deliver. The voice file server 36 must be able to maintain a 64 kbit / s uninterrupted data transfer rate for voice and support the playback of arbitrarily scheduled sequences of speech file sections, providing adequate buffering to avoid perceptible pauses between successive sequences, but this Requirements are relatively moderate and, given the current state of the art, are easily met.

A simple database system 41 is provided to implement the language strands and their associated interests. For this purpose, the database system 41 stores the language strands (VRs) as unchangeable piece tables, which refer to unchangeable files and / or file segments, provides elementary query and update options and supports the sharing of the VRs among the many users who can use them. to refer to the language files below. Any database system that meets these moderate requirements would suffice. Such a system stores, for example, each entry as a sequence of attributes expressed as key / value pairs in a prescription protocol, for example as described by Gray, "Notes on Database Operating Systems" in Bayer et al., Operating Systems: an Advanced Course, Springer-Verbig, 1978, pages 393-481. Unlike most database systems, where the data is only logged until it is passed to a more permanent location and written, however, the pre-write log within database system 41 is the permanent source of the data (hh, once written, the data is never emotional). Therefore, B-tree indexes can be formed by direct reference to the prescription log to map the values ​​of one or more keys to the appropriate locations in the log files. Similar methods have been used to construct protocols for electronic mail systems. See Donahue et al., "Walnut: Storing Electronic Mail in Databases," Xerox Palo Alto Research Center, Technical Report CSL-85-9, Nov. 1985. See also Lampson, "Hints for Computer System Design", Proceedings Ninth Symposium on Operating System Principles, Bretton Woods, Nem Hampshire, Oct. 1983, pages 33-48.

The minimum data structure to represent a voice string consists of [voice file ID, key, interval] tuples. Additional attributes can be included for SprachStrangID, identity of the producer, access control lists and total length of the Sprachstrang. This means that a typical database log entry for a voice string can have the following form:

SprachStrangID: Hugo.pa # 575996078

Producer: Hugo.pa

Length: 80000

Play access: Sprachprojekt ^ .pa

Edit access: none

LanguageFileID: 235

Key: 17401121062B 10300460467B

Interval: 0 80000

Such an entry can be used to construct an index that allows language strand structures to be recovered efficiently by their SprahhStrangIDs. It also allows maintaining an index of voice file IDs that are useful for waste collection, as described in more detail below.

As will be remembered, more complex speech strands can be constructed using the aforementioned speech string editing process. For example, as shown in Fig. 4, two simple speech strings VR & sub1; and VR & sub2; with the following structures:

VR1 = <Voice file ID: VF 1, key: K 1, interval: [start: 0, length: 4000]>

VR2 <Language file ID: VF 2, key: K 2, interval: [start: 500, length: 2000]>

in this case the operation creates:

REPLACE [Base: VR 1, interval: [Start: 1000, length: 1000], with: VR 2)

a new speech strand VRs with the structure:

VR 3 : (Voice file ID: VF 1, key: K 1, interval:

[Start: 0, Length: 1000],

Language file ID: VF 2, key: K 2, interval:

[Start: 500, Length: 2000]

Language file ID: VF 1, key: K 1, interval:

[Start: 2000, length: 2000]>

If one briefly revises the management and editing of digitally recorded speech and other data-intensive non-text data with which this invention can be used, it will be remembered that when speech is to be recorded, the speech manager 34 calls the speech file server 36, one generate new VF and save the language that arrives via a specified dialog with a given DialogID as the content of this new VF. After the end of the recording, the voice manager 34 adds a simple VR to the voice string database in the database system 41 to present the newly recorded VF. The encoding key assigned by the voice control server 32 to encode the dialog is stored in the voice string database entry so that this key is carried along with the voice file ID during all subsequent editing operations involving one or more intervals of VR becomes. The language file will, too. Editing, neither moving nor copying once once in a VF &amp; sub1; is recorded.

When a VR is played, the voice manager 34 first recovers the VR structure from the database system 41. If the trusted identities of all participants in the playback of the VR match all of the access controls associated with the VR, the voice manager 34 continues the playback process by distributing the coding key (s) to the participants for the specified intervals of the VFs associated with the given VR and causes the voice file server 36 to play these VF intervals in the correct order. As previously stated, the voice file server 36 has a sufficiently large output buffer to allow two or more VF intervals to be played without introducing any pauses between them.

The VRs advantageously have a flat structure to increase playback performance, ie a single database access is sufficient to determine the complete structure of a given VR because each VR references its associated VFs directly. Alternatively, complex VRs could be shared as sections of other VRs in a tree organized database with VRs representing sections of VFs in the leaves of the tree. This approach would reduce the processing costs of editing VRs, but would increase the number of database accesses needed to play complex VRs that represent two or more specified sections of the same or different VFs. In other words, it is a compromise to optimize the VR database structure for a single application pattern.

As will be seen, once all VRs referencing a given VF have been deleted, no VR will ever refer to that particular VF again, thus the storage space on the voice file server 36 to which that VF is allocated is used Deleting the VF for subsequent reuse is advantageously recovered. A straightforward query of the voice string database within the database system 41 is sufficient to determine whether any VRs still exist that refer to a given VF. However, it is more difficult to determine whether a given VR can be deleted or not. The "interests" operations described above are therefore the key that allows Vrs and their associated VFs to be automatically recovered.

The users are required to store their VR interests in a known location, for example in an interest database within the database system 41. These stored interests then serve as proxy for the VR references that the user submits, thereby providing a logical basis for distinguishing between validly referenced active VRs and unreferenced outdated VRs. A referral debilitation mechanism, e.g. a specified timeout period can, if desired, be included in a separate interest, so it will be understood that VR obsolescence occurs when there are no existing valid references to the given VR, including unexpired timeouts.

It was previously stated that when a RETAIN procedure is called, an entry is added to the interest database, provided that the entry does not already exist. The database entry includes the SprachStrangID, the class of interest, an interest value and the identification of the user, which allows interest database queries based on one of these attributes. Unfortunately, it is sometimes impractical to modify existing workstations and file servers to automatically invoke the RETAIN and its complementary FORGET procedure to save and delete user interests on a given VR when documents or messages containing references to that VR are be entered in the user directories or removed from them. However, it is feasible to include an additional program in the operating system of each user, which is called automatically when the user moves a file containing a VR reference from the temporary storage of the workstation to a file server for permanent storage, a call of the following type is output for each speech string referenced in a file:

RETAIN [VRID: SprachStrangID, class "file comment,

Interest: Commented file name ",

User: Trusted Name]

Therefore, a normal file server directory counting operation can be performed at any later time to determine, for any given user interest, whether the user-named case of the Datel (eg, Annotated File Name ") containing the VR reference to which the given interest relates, still exists or not. The applications of each user determine the class or classes of the interests registered by such a user, and these interests are given user-defined values ​​(for example "commented file name" for the interest class "file comment"). This means that the individual users for the assignment of unique values, e.g. different version numbers to which different interests are responsible that they wish to enter within a given class of interests.

To automatically locate obsolete interests and remove them from the interest database, the implementer of any interest class can register a procedure of the following type with the language manager 34:

IS GARBAGE [SprachStrangID, interest] - {Yes / No}

This procedure determines in a class-specific manner whether a given interest still applies to a specific VR or not. For the aforementioned file comment class, for example, this procedure only returns "yes" if the user-specified value of the interest parameter no longer exists on any file server anywhere within the distributed computer system 21.

5, language manager 34 suitably includes an interest verifier that periodically enumerates the interest database, 51-54, and calls the class-specific IS GARBAGE procedure (if one has been entered) for each interest, 55-54. 56. The IS GARBAGE procedure for each interest class can use different criteria to determine whether an entry within the given class is valid or not, 57. The procedure can eg check the entry against intrinsic debilitation criteria, eg the expiry of a predetermined timeout period and the compatibility with an access control list. It can also issue a directory query to the file servers of the distributed computer system 21 to determine whether the interest value specified for the examined entry (eg "commented file name") still exists on one or more file servers. If it is determined that the given interest is invalid for some reason, a FORGET [SprachStrangID, class, interest] procedure is called, 58 to remove it from the interest database, 59.

6, the voice manager 34 also has a voice thread garbage collector that periodically enumerates the voice thread database 71-74 so that orphaned VRs are removed therefrom, 75. Desirably, provision is made to at least provide VRs for some or all classes intrinsically protected for a finite period of time after their creation, 76 so that interested users have an acceptable opportunity to register an interest in them. In the absence of such intrinsic protection, however, a given VR is removed from the speech database unless it is determined at 77 that the VR being examined is still referenced by at least one valid interest in the interest database.

As shown in Figure 7, a separate voice file garbage collector can be included in voice manager 34, which periodically enumerates the voice file database, 81-84, so that the VFs found at 85 no longer have VRs referencing them , 86, thereby reclaiming the space on the voice file server 36 (Fig. 1) that was allocated to them.

Alternatively, as shown in Fig. 8, the voice file garbage collector can be integrated with the voice string garbage collector so that these functions are performed simultaneously. For example, if it is determined that a given VR has been orphaned at 77 in Figure 6, the VFs referenced by the orphaned VR can be enumerated, 91-93. This makes it possible to compare each of these FVs against the voice string database to see if they are referenced by any other VRs, 94 so that orphaned VFs are deleted, 95. After all VFs referenced by an orphan VR , have been examined, the VR is cleared, 75, and the process then goes back to continue enumerating the VRs with the next VR, 72 in FIG. 6.

Likewise, as shown in Fig. 9, the voice string garbage can be integrated with the interest garbage collector. Each entry in the interest database references a single VR, so if it is determined that a given interest is invalid, 57 in FIG. 5, the interest database may be examined 96 in FIG. 9 to determine whether it contains other interests that refer to the VR associated with the invalid interest, 97. If no other reference to the given VR is found, both the VR and the invalid interest entry are deleted, 98 and 99 respectively. On the other hand, if there are other interests referring to the VR, only the invalid interest is deleted before the process returns to continue the interest database enumeration with the next interest, 52 in FIG. 5.

In view of the foregoing, it will now be understood that the present invention provides a powerful and effective waste collector for hypermedia applications of distributed computing systems.